Sharepoint och SQL Server 2005 Mirroring - Möjligheter och begränsningar

Målgrupp: Sharepoint Administratörer och SQL DBA
Nivå: 200
Kräver kännedom om: SQL Server 2005 Mirroring, WSS3.0 och MOSS 2007

Microsoft introducerade med SQL server 2005 en ny lösning för högtillgänglighet av databaser, så kallad ”database mirroring”. Jag kommer i fortsättningen att kalla det DBM för enkelhetens skull. DBM blev inte supporterad förrän SP1 för SQL server 2005. Innan DBM fanns det ett antal andra lösningar för högtillgänglighet, bland annat "Database Clustring" och "Log shipping". Styrkan i DBM är att den sätts på databasnivå och inte servernivå och kräver därmed inte likadan hårvara på noderna. Bland nackdelarna kan räknas att DBM kräver en tredje server, ett så kallad vittne, detta om lösningen ska köras i högtillgänglighetsläge. DBM stöds endast i SQL server 2005 standard-, developer- och Enterprise edition, medan vittnestjänsten kan exekveras i alla versioner. En annan förutsättning för DBM är att applikationen stödjer ADO 2.0. DBM fungerar endast för de databaser som är i ”Full Recovery Model” och antal databaser som speglas bör ligga strax under 10 databaser för varje server, annars kommer prestandan att bli lidande. För mer information om DBM surfa till länken nedan:
http://go.microsoft.com/fwlink/?LinkId=83566&clcid=0x409

Innan jag går in på hur Sharepoint kan dra nytta av DBM, låt oss ta en titt på de databaser som finns i respektive version av Sharepoint.

Windows SharePoint Services 3.0 (WSS 3.0)använder sig av följande databaser:
• En konfiguration databas (CONFDB)
• En innehållsdatabas för Central Administration (CACDB)
• En eller flera innehålls databaser (CONTDB)
• En sökdatabas (Search) - (SDB)

Microsoft Office SharePoint Server 2007 (MOSS 2007) använder sig av följande databaser:
• En konfiguration databas (CONFDB)
• En innehållsdatabas för Central Administration (CACDB)
• En eller flera innehålls databaser (CONTDB)
• En eller flera databaser för delade tjänster, så kallade "Shared Services Provider" (SSPDB)
• En sökdatabas (Search) - (SDB)

Alla databaser ska speglas individuellt. CONTDB och SSPDB är de två databastyper som drar störst nytta av DBM. CONFDB och CACDB innehåller specifika referenser om platser och konfigurationer, vilket gör de mindre attraktiva för DBM. Microsoft rekommenderar inte i dagsläget att man speglar SDB. Detta för att vid en svängning till andra noden och vid omkoppling av SDB, söker sökmotorn genom hela databasen på nytt (Recrawl), vilket är samma som att bygga sökdatabasen från början, dvs. man vinner inget på att svänga SDB. Microsoft rekommenderar administratörer att använda sig av de inbyggda verktygen i Sharepoint för att backa och återläsa SDB.

Det andra som man ska tänka på är att CONFDB och CACDB är så tätt integrerade med varandra. Därför skall dessa databaser ligga på samma fysiska nod och svängas samtidigt vid en manuell förfarande.
databas spegling är endast användbart i ett MOSS 2007 farm, med en front-end server och en eller flera back-end databaser.
Okej, låt oss anta att vår första nod i DBM, dvs. den så kallade Principal har gått ner och andra noden det så kallade Mirror har tagit över databaserna och blivit aktivt. I denna stund då jag sammanställer detta dokument, finns ingen inbyggd funktion i varken WSS 3.0 eller MOSS 2007 som automatisk känner av att databasen har svängt. Därför behövs lite handpåläggning för att få det att fungera. Detta kan göras antingen manuellt eller automatiskt. För att skripta detta kolla länken nedan, vilken visar hur olika händelser i DBM kan fångas och automatiseras:
http://go.microsoft.com/fwlink/?LinkId=83691&clcid=0x409

CONFDB och CACDB
För att uppmärksamma WSS eller MOSS att CONFDB och CACDB har svängt till andra noden följ följande steg PÅ ALLA FRONT-END WEBBSERVRAR:
1. Se till att alla SQL logins finns i båda noderna. För att kopiera dessa mellan noderna kolla länken nedan:
http://go.microsoft.com/fwlink/?LinkId=93747&clcid=0x409
Om inte dessa logins finns i alla noder, kommer du inte att kunna komma åt CACDB.

2. Kör följande rad av kod på varje Fron-End webbserver:
stsadm.exe -o renameserver -oldservername -newservername
För en detaljerad beskrivning av Stsadm kommandot surfa till länken nedan:
http://technet2.microsoft.com/Office/en-us/library/188f006d-aa66-4784-a65b-a31822aa13f71033.mspx?mfr=true

3. Starta om alla Front-End webbservrar.

CONTDB
För att uppmärksamma WSS eller MOSS att en eller flera CONTDB har svängt till andra noden, medan CONFDB och CACDB ligger kvar på samma nod, följ följande steg ENDAST PÅ EN FRONT-END WEBBSERVER:
Klicka på Start  Programs  Administrative Tools  SharePoint 3.0 Central Administration.
1. I Central Administration site, Klicka på Application Management.

2. I Application Management sidan, I avsnittet för SharePoint Web Application Management delen, klicka på Content databases.

3. I Manage Content Databases sidan, klicka på den CONTDB som har svängt.

4. I Manage Content Database Settings page, i Remove Content Database delen, bocka i Remove content database och klicka sedan på OK.

5. I Manage Content Databases sidan, klicka på Add a content database.

6. Ange information om den CONTDB som du nyss tog bort, men ersätt Database Server med den nya databasnoden, dvs. Den som aktiv för stunden.

7. Repetera stegen 4-7 för varje CONTDB som har svängt till en ny nod.

Du kan även använda dig av följande kommando:

1. För att ta bort fallerade CONTDB:

stsadm -o deletecontentdb -url "" -databasename "" -databaseserver ""

2. För att lägga tillbaks CONFDB:

stsadm -o addcontentdb -url "" -databasename " " -databaseserver ""

SSPDB
För att uppmärksamma MOSS att SSPDB har svängt till andra noden, följ följande steg ENDAST PÅ EN FRONT-END WEBBSERVER MEN FÖR VARJE DATABAS SOM HAR SVÄNGT:

stsadm –o editssp –title –ssplogin –ssppassword - sspadminsite

OBS! Username kan skrivas I följande format: Domain\Username