Implementera Log Shipping i SQL Server
Förord
Log shipping innebär att man kan synkronisera flera servrar med hjälp av
transaktionsloggarna. Man kan alltså ha en backupserver i händelse av en
krasch. Det blir också möjligt att ha enbart läsbara databaservrar som kan
avlasta huvudservern från SELECT-frågor. Du kan också läsa mer om Log Shipping i Books Online,
Administering SQL Server, Managing Servers, Log Shipping.
Använda VB vid implementering av SQL Server Log Shipping
av Dean Thompson
Log Shipping är ett Disaster Recovery verktyg (DR = ung. reparationsverktyg för katastrofer) som ger dig möjligheten att ha en snabbt tillgänglig ”färsk backup”.
Idén är att om ditt existerande system skulle stanna eller krascha, har du en backup SQL Server och databas tillgänglig för att ta över med relativt uppdaterad information. Om din databas är avgörande för ditt företag, som till exempel i en anropscentral ger log shipping en otrolig möjlighet att försäkra att affärerna inte behöver stanna upp länge.
Som ett exempel; förra året var centrala Houston översvämmat och de flesta byggnader var oåtkomliga. Företag som hade implementerat log shipping på fjärr-DR-sajter kunde fortsätta att använda sina affärsapplikationer några minuter efter att de hade tappat kontakten med sina primära databaser. I denna situation skulle en enkel klusterlösning varit helt ineffektiv.
Grunderna
Att implementera log shipping är en konceptuellt enkel uppgift.- Skapa databasen på fjärrservern (servrarna).
- Ge fjärrdatabasen endast läsrättighet.
- Skapa en full databasbackup på produktionsservern.
- Kopiera backup-filen för databasen till fjärrservern (servrarna).
- Återställ databasen på fjärrservern.
- Vid de intervall som krävs för att svara mot dina affärsbehov ska du sen:
- Utföra en backup av en transaktionslogg på din primära databas.
- Kopiera backuploggen till fjärrservern.
- Lägga in loggen på fjärrdatabasen (det kommer inte att fungera om den databasen inte har tilldelats endast läsrättighet, eller om något arbete som har förändrat databasen har utförts).
- Utföra en backup av en transaktionslogg på din primära databas.
Du kanske märker att du måste göra en full backup och återställa ganska ofta. Vanligtvis brukar jag schemalägga att full backup och återställning ska inträffa ungefär en gång i veckan under lågsäsong. Dina tidsscheman kan variera beroende på om det finns tillgängligt utrymme och hur många fulla databasbackuper som du vill behålla. Dessutom, om du utför backup på en transaktionslogg var 15:e minut kan antalet filer bli ganska många och kan göra en manuell återställning ohanterlig.
Skriva en VB Log Shipping Applikation
I denna del ger jag ett exempel på en log shipping applikation som använder en ADO-koppling för att generera backupfilerna och utföra återställningarna. Applikationen är endast för demonstrationssyfte. Du får gärna använda koden, men jag rekommenderar starkt fullständig testning för att den ska passa i din miljö. Jag tar inget ansvar för skador eller fel vid användning av koden.SQL Server 2000 Enterprise Edition har en inbyggd Log Shipping Wizard. Om du använder Enterpriseversionen rekommenderar jag starkt att du använder den wizard som finns. Den är mycket mer flexibel än den exempelapplikation som jag har och mycket grundligare testad.
Ladda ner exempelkoden
Några beslut
Om jag ska vara ärlig så kunde den mesta av denna funktionalitet ha varit skriven i en DTS eller VBScript och Windows Scripting Host. Men den miljö som jag ursprungligen skapade detta verktyg för använde en äldre version av SQL Server som inte innehöll DTS, och serverbestämmelserna tillät inte att WSH eller liknande teknologier installerades.Fördelen med att använda VB är naturligtvis att det inte ens behöver köras från en SQL Server. Det kan lätt schemaläggas att använda AT-kommandon från en Windows NT/2000 host.
Ett av de svåraste besluten som du måste fatta när din log shipping applikation ska skapas är om du vill utföra transaktionslogg backuperna till en enstaka fil eller till flera individuella. Jag föredrar individuella filer eftersom det ger en viss, direkt visuell feedback på hur dina transaktionsloggbackuper har lyckats, och kan göra kodandet av en manuell återställning lite mer intuitiv. Men det finns fördelar hur man än väljer så du måste betänka dina affärsbehov innan du fattar ett beslut. Exempelkoden använder en metod för individuella filer, men har dock viss kod som hanterar flera backuper per fil.
I exempelkoden kontrollerar jag först registret för information om produktionsservern och backupservrarna. Dessutom hämtar jag formatet för filnamnen som vi kommer att skapa. Formatet ska vara ett giltigt datumformat. Ändring till standard kan också orsaka problem eftersom inga andra format har testats, så du behöver testa alla ändringar som du gör.
Ett tilläggsval som du kanske vill anropa är att utföra en DBCC CHECKDB på produktionsdatabasen innan backup utförs.
Om du kör en tidigare version än SQL Server 7.0 bör du fundera över detta område eftersom problem i databasen kommer att återskapas i måldatabasen.
Anslutning till servrarna
Att ansluta till SQL Server genom att använda ADO och OLE-DB är väldigt enkelt. Vi skapar helt enkelt en sträng med passande anslutningsparametrar, inklusive Provider (SQLOLEDB.1), Data Source(Servernamn), UserID och Password. För att förebygga konflikter vid återställningen är den initiala databasen satt till Masterdatabasen.
strConn = "Provider=SQLOLEDB.1;Persist SecurityInfo=True"& _
";Initial Catalog= Master;"& _
";Data Source=" & strServer & _
";Password= "& strPass & _
";User ID=" & strUser
När du väl har skapat strängen ska du tilldela den som ConnectionString-parametern för ADODB.Connection object.Next, sätta ConnectionTimeOut-parametern till 0. Detta förebygger att anslutningen i sig själv avslutas, inte de faktiska SQL-exekveringarna.
Nu är det bara att öppna anslutningen.
Exekvera Backupen
När vi väl har en anslutning behöver vi skapa SQL-satsen för att utföra databas- eller transaktionsloggbackupen. Om filen redan existerar väljer jag att använda WITH INIT-valet. Det förhindrar mig från att skriva över de backuper som redan kan finnas på filen. Här är koden för att skapa uppgifterna för SQL:
strSQL = "BACKUP DATABASE " & sDatabase & _
" TO DISK='" & sFilename & "' "
If Not FileExists(sFilename) Then
strSQL = strSQL+ " WITH INIT"
End If
strSQL = "BACKUP TRANSACTION " & sDatabase & _
" TO DISK='" & sFilename & "' "
If Not FileExists(GetSetting(App.ProductName, m_sServer, "NetDmpDev")) Then
strSQL = strSQL+ " WITH INIT"
End If
Om du använder en tidigare version än SQL Server 7.0 kommer du att vilja ändra ovanstående SQL till att använda DUMP DATABASE respektive DUMP TRANSACTION.
Exekveringen av koden är ganska okomplicerad. Du anropar helt enkelt anslutningsobjektets exekveringsmetod med frågan som en parameter. För att hjälpa loggningen av data lade jag till några händelser under exekveringen av frågan. Att fånga ADO-händelser kräver att antingen ett klassobjekt eller ett Formobjekt används. Högst upp i klassen lade jag till koden Private WithEvents connEvent AS ADODB.Connection. med den koden där placeras nya händelser i din klass och utförs genom ADO-anslutningen.
Jag använde WillExecute, InfoMessage och ExecuteComplete för att fånga start, exekvering och avslutning av meddelanden från ADO.
Kopiera filerna
Nästa steg är att kopiera filerna till fjärrservern (servrarna). Detta steg är relativt enkelt eftersom FileCopyfunktionen fungerar med UNC-namn. Det enda klagomålet som jag har på denna funktion är att den inte använder CopyFileEx API-funktionen och fångar händelser när filen är kopierad. Olyckligtvis skulle implementering av API-anropet ha krävt för lång tid och gett en dålig belöning så jag använde inte det här. En intressant förändring i denna kod skulle vara att lägga till FTP-möjligheter till filkopieringsrutinen.Det bör noteras att kopiering av filerna inte absolut behövs över ett LAN eftersom SQL Server kan göra backupfiler över ett nätverk. Men kopiering av filerna kan ge samma nytta. Den primära nyttan är att du kommer att ha fler än en kopia av filerna tillgänglig i händelse av en katastrof.
Återställ databasen
Återställning av databasen fungerar i stort sett på samma sätt som utförandet av en databasbackup. Vi skapar helt enkelt en anslutning, definierar SQL-satsen att återställa databasen och exekverar SQL-satsen. Som ett extra steg finns ett val att utföra en DBCC CHECKDB på måldatabasen efter att en återställning har ägt rum. För tidigare versioner än SQL server 7.0 är detta en nödvändighet.Du kommer att märka att det finns två olika versioner av de filvägar som används i denna demoapplikation. Den första är UNC-versionen, och den används för att kopiera filerna över nätverket. Den andra är den lokala vägen som mer använder en drivrutinsklassificering än en UNC. Anledningen till att denna kod lades till var för att öka prestandan en smula.
Om en UNC används måste SQL Server köra förfrågningar genom nätverkslagret för att komma åt fildatan. Generellt kommer det att bli en viss tillbakagång i prestandan som ett resultat av den tillagda omvägen. Men du kanske tycker att det är lättare att bibehålla inställningarna i registret om du använder UNC för information om en väg.
Av respekt till SQL-satsen för att återställa databasen utelämnade jag en viktig del om du ska lagra flera backuper per fil. Om det finns flera backuper i en fil behöver du spåra aktuellt backupnummer och sedan lägga till det i slutet av SQL-satsen genom att använda WITH FILE = nummersyntax. Som hjälp för att spåra numret på backuperna i en fil skapade jag funktionen GetBackupCountInFile i klassen clsLoadData. Det finns mer information tillgänglig om WITH FILE =syntax i Books Online.
Några andra detaljer
Ta bort gamla filerNär du väl framgångsrikt har börjat använda Log Shipping, kommer det inte ta lång tid att bygga upp ett ganska stort antal backupfiler på dina servrar. I vissa fall, kanske du inte vill behålla filerna i någon längre tid. Funktionen FileCleanup i modulen modMain, kontrollerar datumen på filerna och tar bort alla filer som är större än n dagar gammal, vilket specificeras i registerinställningarna. Specificera bara 0 om du inte vill behålla några filer på en server.
Batch SQL återställning
Medan jag testade denna applikation fann jag mig själv tillbringa hemskt mycket tid med att återställa backuperna för hand. Så, hellre än att manuellt skriva ut backupen och återställa uppgifterna började logga dem allteftersom de exekverades, även om exekveringen resulterade i ett misslyckande. Detta var en oerhörd hjälp, när backupfilerna fortfarande fanns (lär från mitt misstag och sätt inte DelFile registrets inställningar till 0 förrän du har kört detta i några veckor och vet att det fungerar). Rutinen för att skapa loggen finns i klassen clsLoadData som Dump2SQL.
Avslutningskod
Det enklaste sättet att exekvera detta program är att köra det från SQL Agent som en schemalagd uppgift. För att feltesta kontrollerar SQL Server avslutningskoden från processen. Typiska VB applikationer tar inte upp fel i koden, oavsett deras tillstånd när de avslutas. För att rätta till det använda jag ExitProcess API anrop, som tillfredställer det behovet väldigt bra, tills du debuggar i VB, om du kör ExitProcess-anropet i VB-miljön kommer VB att stängas ner tillsammans med de ändringar som du gjort medan du stegat igenom koden (ett annat tråkigt moment i utvecklingen av denna kod). Så du kanske vill placera kompilatorvillkor runt alla anrop till denna funktion.
Slutsats
Det finns många olika grepp som du kan ta för att skapa en stabil Log Shipping lösning. Denna exempelapplikation är inte avsedd att passa alla företagsbehov, så du bör utvärdera den noggrant innan du använder den i ditt företag. Men den är funktionell och åtminstone ge dig en stabil grund. När tiden tillåter kommer jag att göra modifieringar i koden för att ge större feltolerans och ny rapporteringsfunktionalitet.
0 Kommentarer