i åbningskapitlet i Craig Mullins bog, databaseadministration, siger han “på mange måder er forretning i dag data”. Inden for de fleste organisationer er den person, der er ansvarlig for at beskytte data, databaseadministratoren… dig.

det er rigtigt; hele virksomheden er i dine dygtige hænder og kører på den server, der aldrig går ned, med alle de slutbrugere, der aldrig laver fejl ved hjælp af applikationer, bygget af de udviklere, der skriver fejlfri kode første gang, hver gang, med den dygtige hjælp fra det nye co-op, der har ‘sa’ privilegier takket være din chef.

okay. Hold op med at græde. Der er ting, du kan gøre for at beskytte serverdata under din pleje, og en af de vigtigste er at køre regelmæssige databasebackups.

sikkerhedskopier

Microsoft definerer sikkerhedskopier som:

en kopi af data, der bruges til at gendanne og gendanne data efter en systemfejl

sikkerhedskopier kan oprettes på en række måder og kan inkorporere alle eller nogle af dataene såvel som en del af transaktionsloggen. Mens denne artikel er fokuseret på 2005 syntaks, de fleste af begreberne gælder for 2000. Dette er et stort emne. I bedste fald vil jeg ridse overfladen og give dig nok information, så du ikke begynder at græde igen. Efter at have læst dette, skal du være i stand til at oprette et rimeligt sæt sikkerhedskopier til dit system.

Gendannelsesmodeller

for at begynde at arbejde på Sikkerhedskopier definerer forretningsbehovet en databasegendannelsesmodel. I det væsentlige definerer en gendannelsesmodel, hvad du skal gøre med transaktionslogdataene.

der er tre gendannelsesmodeller: fuld, enkel og Bulk logget. Disse er ret nemme at definere:

• enkel-i simpel gendannelsestilstand sikkerhedskopieres transaktionsloggen ikke, så du kun kan gendanne til den seneste fulde eller differentielle sikkerhedskopi.
• Full – i fuld gendannelsestilstand sikkerhedskopierer du databasen og transaktionsloggen, så du kan gendanne databasen til ethvert tidspunkt.
• Bulk logget ind bulk logget tilstand, de fleste transaktioner gemmes i transaktionsloggen, men nogle bulkoperationer såsom bulkbelastninger eller oprettelse af indeks logges ikke.

de to mest anvendte tilstande er enkle og fulde. Antag ikke nødvendigvis, at du selvfølgelig altid skal bruge fuld gendannelse for at beskytte dine data. Det er en forretningsbeslutning. Virksomheden vil fortælle dig, hvis du har brug for at komme sig til et tidspunkt, eller hvis du blot har brug for den sidste fulde backup. Det vil definere, om dine data kan gendannes på andre måder, såsom manuel indtastning, eller hvis du er nødt til at beskytte så meget som muligt, da det kommer over ledningen. Du bruger simpel gendannelse, hvis du har råd til at miste de data, der er gemt siden den sidste fulde eller differentielle sikkerhedskopi, og/eller du bare ikke har brug for gendannelse til et tidspunkt. I simpel tilstand skal du gendanne alle sekundære læse / skrive-filgrupper, når du gendanner den primære. Du bruger Simple hovedsagelig på sekundære databaser, der ikke er en absolut vital del af virksomheden eller rapporteringssystemerne, med skrivebeskyttet adgang, så der ikke er en transaktionslog at bekymre sig om alligevel. Du bruger fuld hvis hver bit af dataene er afgørende, skal du gendanne til et tidspunkt, eller normalt i tilfælde af meget store databaser (VLDB) skal du gendanne individuelle filer og filgrupper uafhængigt af andre filer og filgrupper.

med både enkle og fulde gendannelsesmodeller kan du nu køre en sikkerhedskopi, der kun er kopi, som giver dig mulighed for at kopiere databasen til en sikkerhedskopifil, men påvirker ikke loggen, differentielle sikkerhedskopieringsplaner eller påvirkningsgendannelse til et tidspunkt. Jeg vil forsøge at bore ned på så mange af disse emner som muligt gennem artiklen, men ikke filerne og filgrupperne.

arbejde med Simple Recovery

nok snak. Lad os komme ned til at køre sikkerhedskopier. Lad os antage, at vi er i simpel opsving på en lille til mellemstor database. Jeg har tænkt mig at bruge eventyrværker for alle prøven scripts. For at indstille den til simple recovery:

din enkleste backup strategi er at køre, med jævne mellemrum, følgende Server backup kommando, som vil udføre en fuld backup af databasen:

Hvad er der med al den skrivning, du spørger? Har vi ikke GUI-værktøjer til at håndtere arbejdet for os? Ja, de fleste enkle sikkerhedskopier kan udføres ved hjælp af Server Management Studio. Men hvis du vil lære og forstå, hvad Management Studio gør for dig, eller hvis du vil have en finkornet kontrol over, hvad der er sikkerhedskopieret, hvordan og hvor, så bliver du nødt til at bryde tastaturet ud og lægge musen væk.

ovenstående kommando udfælder en grundlæggende sikkerhedskopi til disk. De fleste DBA ‘ er jeg kender backup til fil og derefter skrabe filerne på et bånd eller et andet medie. Dette skyldes, at filer på disken er enkle og hurtige at gendanne, mens medier undertiden kan være lidt af en smerte. For eksempel har vi generelt to til tre dages sikkerhedskopier på vores filsystemer til øjeblikkelig gendannelse. Vi går kun til båndsystemerne, hvis vi har brug for at køre gendanner til ældre sikkerhedskopier.

Hvad gjorde denne kommando? Det lavede en kopi af alle de engagerede data i databasen. Det kopierede også uforpligtede logposter. Disse bruges under gendannelse til enten at begå eller tilbageføre ændringer, der opstod i dataene under sikkerhedskopieringsprocessen.

kopier kun sikkerhedskopier

normalt påvirker sikkerhedskopiering af en database andre sikkerhedskopierings-og gendannelsesprocesser. For eksempel efter at have kørt den forrige kommando, bruger alle differentielle sikkerhedskopier (en sikkerhedskopi, der kun kopierer data, der er ændret siden den sidste sikkerhedskopi) dette som udgangspunkt for dataændringer, ikke den sikkerhedskopi, du kørte i går aftes. Som tidligere nævnt introducerer 2005 et nyt koncept til sikkerhedskopier, COPY_ONLY backups, som giver os mulighed for at holde fra at afbryde cyklussen:

vi har allerede fundet et af de mere granulære øjeblikke, hvor Ledelsesstudiet ikke ville hjælpe dig. Hvis du kun vil have en kopi backup, skal du bruge kommandolinjen.

Differential backups

lad os antage et øjeblik, at vi stadig er i simpel opsving, men vi har at gøre med en større database, siger noget over 100 GB i størrelse. Fuld sikkerhedskopiering kan faktisk begynde at bremse processen lidt. I stedet, efter konsultation med virksomheden, vi har besluttet at lave en ugentlig fuld sikkerhedskopi og daglige differentielle sikkerhedskopier. Differentielle sikkerhedskopier sikkerhedskopierer kun de datasider, der er ændret siden den sidste fulde sikkerhedskopi. Følgende er kommandoen backup for at udføre en differentiel backup:

nu, hvis vi skulle gendanne denne database, ville vi først gå til den sidste fulde sikkerhedskopi, gendanne den og derefter gendanne differentielle sikkerhedskopier i rækkefølge (mere om det senere).

der er en række andre sikkerhedskopieringsmuligheder, som jeg ikke beskriver her. Læs bøgerne online for at se detaljer om blokstørrelse, udløbsdato, TILBAGEHOLDELSESDAGE, adgangskode, navn, statistik, og så videre.

du kan også køre en erklæring, der kontrollerer integriteten af en databasebackup. Det kontrollerer ikke integriteten af dataene i en sikkerhedskopi, men det kontrollerer, at sikkerhedskopien er formateret korrekt og tilgængelig.

fuld gendannelse og log sikkerhedskopier

vi har primært arbejdet på en database, der var i simpel gendannelsestilstand (dette plejede at blive kaldt Truncate Log on Checkpoint). I denne tilstand sikkerhedskopierer vi ikke transaktionsloggene til senere gendannelse. Hver backup under denne mekanisme er en database backup. Log sikkerhedskopier er simpelthen ikke muligt.

du har dog kun beskyttet dataene fra den sidste gode sikkerhedskopi, enten fuld eller differentieret. Lad os ændre vores antagelser. Nu har vi at gøre med en stor, missionskritisk applikation og database. Vi ønsker at være i stand til at gendanne denne database op til det seneste minut. Dette er et meget vigtigt punkt. I teorien, da logposterne gemmes og sikkerhedskopieres, er vi beskyttet op til punktet for enhver fejl. Nogle fejl kan dog forårsage korruption af loggen, hvilket gør genopretning til et tidspunkt umuligt. Så vi er nødt til at bestemme, hvad den rimelige minimumstid mellem log-sikkerhedskopier vil være. I dette tilfælde kan vi leve med ikke mere end 15 minutter værd af tabte data.

så lad os starte med at sætte vores database i fuld gendannelsestilstand:

derefter kører vi på en planlagt basis, i dette tilfælde hvert 15. minut, kommandoen backup for transaktionsloggen:

dette script vil sikkerhedskopiere forpligtede transaktioner fra transaktionsloggen. Det har markører i filen, der viser start-og stoptid. Det vil afkorte loggen, når den er fuldført, rengøring ud fra transaktionsloggen de engagerede transaktioner, der er blevet skrevet til backup-fil. Hvis det er nødvendigt, kan du bruge erklæringen med NO_TRUNCATE til at indsamle data fra transaktionsloggen uanset databasens tilstand, forudsat at den er online og ikke i en NØDSTATUS. Dette er kun til nødsituationer.

Bemærk, at vi ikke bruger init-erklæringen i dette tilfælde, men du kan gøre det, hvis du vælger det. Når du laver log-sikkerhedskopier, har du muligheder:

1. Kør alle sikkerhedskopier til en enkelt fil, hvor de stables, og alt hvad du skal gøre, på gendannelse (dækket senere), er at cykle gennem dem.
2. navngiv sikkerhedskopierne entydigt, sandsynligvis ved hjælp af dato og klokkeslæt i strengen.

i sidstnævnte tilfælde siger sikkerhed, brug INIT, fordi du udøver maksimal kontrol over, hvad der bliver sikkerhedskopieret hvor, og du vil være i stand til at vide nøjagtigt, hvad en sikkerhedskopi er, hvornår den blev taget og hvorfra baseret på navnet. Dette er endnu et sted, hvor betjening af sikkerhedskopier fra kommandolinjen giver dig mere kontrol end GUI. Vi har brugt begge tilgange i vores systemer af forskellige årsager. Du kan beslutte, hvad der er bedst for din teknologi og forretningsmæssige krav.

de fleste af de muligheder, der er tilgængelige for databasebackup, er inkluderet i Log backup, inklusive COPY_ONLY. Dette giver dig mulighed for at fange et sæt transaktionsdata uden at påvirke loggen eller den næste planlagte log-sikkerhedskopi. Dette ville være praktisk til at tage produktionsdata til et andet system til fejlfinding osv.

hvis du har din database indstillet til fuld gendannelse, skal du køre log-sikkerhedskopier. Nogle gange glemmer folk, og transaktionsloggen vokser til det punkt, at den fylder diskdrevet. I dette tilfælde kan du køre:

vedhæftning af NO_LOG til logbackupen og ikke angivelse af en placering for loggen, får den inaktive del af loggen til at blive fjernet, og det gør det uden en logindtastning selv og dermed besejre hele diskdrevet. Dette anbefales absolut ikke, fordi det bryder logkæden, den række log-sikkerhedskopier, hvorfra du vil gendanne din database til et tidspunkt. Microsoft anbefaler at køre en fuld sikkerhedskopi umiddelbart efter brug af denne erklæring. Desuden advarer de om, at denne erklæring kan blive forældet i en fremtidig udgivelse.

Gendannelse af databaser

lige så vigtige som sikkerhedskopier af servere er, og de er vigtige, de er ubrugelige uden evnen til at gendanne databasen.

Gendannelse af en fuld databasebackup

Gendannelse af en fuld databasebackup er så simpelt som det var at oprette:

det er virkelig så simpelt-medmindre vi sikkerhedskopierer alt til en fil, som om det var en backup-enhed. I så fald skal du angive, hvilken fil i “enheden” Du får adgang til. Hvis du ikke ved, hvilken fil, skal du generere en liste:

dette vil give dig den samme liste som jeg viste ovenfor fra Management Studio. Så nu, hvis vi ønskede at gendanne den anden fil i gruppen, COPY_ONLY backup, ville du udstede følgende kommando:

desværre, hvis du følger med, kan du opleve, at du lige har genereret denne fejl:

hvad dette betyder er, at din database er i fuld gendannelsestilstand, men du har ikke sikkerhedskopieret “logens hale”, hvilket betyder de indtastede transaktioner siden sidste gang du kørte en sikkerhedskopi. Du kan tilsidesætte dette krav, hvis du ændrer den forrige syntaks til:

det er første gang, vi har stablet med klausuler (med FILE=2 og med REPLACE er repræsenteret som med FILE=2, REPLACE), men det vil ikke være det sidste. Læs gennem bøgerne online. De fleste af de med klausul udsagn kan bruges i kombination med de andre.

Hvad sker der, hvis vi vil gendanne til en anden database end originalen? For eksempel ønsker vi at lave en kopi af vores database fra en separat sikkerhedskopi. Måske vil vi flytte det ned til en produktionssupportserver, hvor vi skal gøre noget arbejde på det, adskilt fra produktionskopien af databasen. Hvis vi tager den enkle tilgang, så prøv dette:

i dette tilfælde skal du se en hel række fejl i forbindelse med filer, der ikke overskrives. Du kan virkelig oprette nye databaser fra sikkerhedskopier, men hvis du gør det på en server med den eksisterende database, skal du ændre placeringen af de fysiske filer ved hjælp af de logiske navne. For at kende de logiske navne på filerne for en given database, køre dette før du forsøger at flytte filerne:

dette kan derefter bruges til at identificere de relevante logiske navne for at generere dette script:

Gendannelse af en differential backup

den sidste metode er at anvende differential backup. Dette kræver to trin. Først gendanner vi databasen, men med en drejning, og så anvender vi differential backup:

det meste af dette er sandsynligvis selvforklarende baseret på det, vi allerede har dækket. Den ene rynke er inkluderingen af nøgleordet NORECOVERY. Meget enkelt, under en gendannelse, kan transaktioner være startet under sikkerhedskopieringsprocessen. I slutningen af en gendannelse rulles afsluttede transaktioner frem i databasen, og ufuldstændige transaktioner rulles tilbage. Indstilling NORECOVERY holder transaktioner åbne. Dette gør det muligt at hente det næste sæt transaktioner fra den næste sikkerhedskopi i rækkefølge.

vi beskæftiger os hovedsageligt med enkle sikkerhedskopier og gendanner i denne artikel, men en mere avanceret gendannelse i 2005 gør det muligt at gendanne sekundære filgrupper, mens databasen er online. Dens primære filgruppe skal være online under operationen. Dette vil være mere nyttigt for meget store databasesystemer.

Gendannelse af SERVERDATABASER til et tidspunkt

Gendannelse af logfiler er ikke meget vanskeligere end den differentielle Databasegendannelse, som vi lige har afsluttet. Der er bare en hel del mere involveret i at genoprette til et øjeblik i tiden. Forudsat at du sikkerhedskopierer dine logfiler til en enkelt fil eller enhed:

ellers skal du bare gå og få de filnavne, du har brug for. Kør først databasegendannelsen, og pas på at lade den være i en ikke-gendannet tilstand. Følg dette op med en række loggen gendanner til et tidspunkt.

nu har vi en database, der er op til den nøjagtige, sidste forpligtede transaktion kl 14:30:29 den 23.oktober. Husk, under multi-trins genskaber som dette, er du nødt til at forlade databasen i en inddrive status. Det betyder at tilføje NORECOVERY til hver sætning, indtil du har afsluttet gendannelsesprocessen. Hvis du af en eller anden grund har tilføjet NORECOVERY til alle dine udsagn, eller du bare stopper i midten og gerne vil bringe databasen tilbage online, kan du bruge denne erklæring til at afslutte processen:

Database snapshots

Server 2005 introducerede konceptet med et øjebliksbillede eller en skrivebeskyttet, statisk visning af en database. Snapshots oprettes primært for at levere en skrivebeskyttet version af en database til rapporteringsformål. De fungerer dog på samme måde som sikkerhedskopier. Den ene primære forskel er, at alle uforpligtede transaktioner rulles tilbage. Der er ingen mulighed for at rulle fremad, fange logfiler osv., at sikkerhedskopier giver, og der bruges heller ikke meget mange serverressourcer. Snarere bruges diskteknologi til at oprette en kopi af dataene. På grund af dette er de meget hurtigere end sikkerhedskopier både for at oprette og gendanne.

Bemærk:
For flere detaljer om snapshot fra 2005, se http://www.simple-talk.com/sql/database-administration/sql-server-2005-snapshots/.

en god brug af snapshots ud over rapportering kan være at oprette en før vedligeholdelse, efter at du allerede har fjernet alle de aktive brugere (og deres transaktioner) fra systemet. Mens snapshots ikke understøtter volatiliteten i live-sikkerhedskopier, er deres hastighed og lette gendannelse et godt værktøj til hurtig gendannelse fra en forkert udrulning. Snapshots gemmes på serveren, så du skal sørge for, at du har tilstrækkelig lagerplads.

syntaksen er anderledes, fordi du ikke sikkerhedskopierer en database; du opretter en ny:

nu vil det være tilgængeligt for skrivebeskyttet adgang. Da vi primært beskæftiger os med at bruge dette som en backupmekanisme, lad os inkludere metoden til at vende en database tilbage til et databasebillede.

Identificer først det øjebliksbillede, du vil bruge. Hvis der er mere end en i en database, som du vil vende tilbage, skal du slette alle undtagen den, du bruger:

derefter kan du gendanne databasen ved at køre en GENDANNELSESERKLÆRING (blandede metaforer, ikke gode):

sådan. På mit system tog det 136 ms at køre databasens snapshots af eventyrværker. den fulde sikkerhedskopi tog 5.670 ms.gendannelsen af snapshot tog 905ms, og databasegendannelsen tog 13.382 ms. Inkorporering af dette i en produktionsudrulningsproces kan resultere i betydelige fordele

igen er det værd at bemærke, at der er nogle advarsler ved at bruge snapshot. Du skal have nok diskplads til en anden kopi af databasen. Du skal være forsigtig med at håndtere snapshots, da det meste af syntaksen ligner den, der bruges af databaser selv. Sidst, mens der er snapshots knyttet til en database kan du ikke køre en gendannelse fra en database backup af denne database.

bedste praksis

den måde, hvorpå du udfører databasebackups, bør ikke være en teknisk beslutning. Det skal dikteres af virksomheden. Små systemer med lave transaktionsrater og/eller rapporteringssystemer, der indlæses regelmæssigt, har kun brug for en fuld databasebackup. Mellemstore systemer og store systemer bliver afhængige af den type data, der forvaltes for at bestemme, hvilke typer backup der kræves.

for et mellemstort system ville en daglig sikkerhedskopi med log-sikkerhedskopier i løbet af dagen sandsynligvis svare på de fleste datakrav rettidigt.

for en stor database er den bedste tilgang at blande og matche sikkerhedskopierne for at sikre maksimal genindvindelighed i minimal tid. Kør for eksempel en ugentlig fuld sikkerhedskopi. To gange om dagen i løbet af ugen skal du køre en differentiel backup. Hvert 10.minut i løbet af dagen skal du køre en log-sikkerhedskopi. Dette giver dig et stort antal genoprettelsesmekanismer.

for meget store databaser skal du komme i gang med at køre filegroup og file backups, fordi det muligvis ikke er muligt at lave en fuld sikkerhedskopi eller endda en differentiel sikkerhedskopi af den fulde database. En række yderligere funktioner er tilgængelige for at hjælpe på dette område, men jeg vil ikke gå ind i dem her.

du bør tage dig tid til at udvikle nogle scripts til at køre dine sikkerhedskopier og gendanner. En navngivningskonvention, så du ved, hvilken database, fra hvilken server, fra hvilken dato, i hvilken specifik sikkerhedskopi og format vil være meget befordrende for din sundhed. En fælles placering for sikkerhedskopier, log, fuld eller Inkremental, bør defineres. Alle ansvarlige bør trænes i både backup og recovery og fejlfinding det samme. Der er mange måder at gøre dette på, men du kan finde et par forslag i Pop sikkerhedskopier og Pop gendanner.

den virkelige test er at køre dine backup mekanismer og derefter køre en gendannelse. Prøv derefter en anden type gendannelse, og en anden og en anden. Vær sikker på, at du ikke kun har gjort due diligence med at definere, hvordan du sikkerhedskopierer systemet, men at du har gjort det ekstra trin for at sikre, at du kan gendanne disse sikkerhedskopier. Hvis du ikke har praktiseret dette og dokumenteret praksis og derefter testet dokumentet, er du faktisk ikke klar til en katastrofe.

Resume

sikkerhedskopier i din virksomhed skal være som at stemme i Chicago, tidligt og ofte. Opsætning af grundlæggende sikkerhedskopier er ret simpelt. Tilføjelse på log sikkerhedskopier og differentialer er nemt så godt. Udforsk mulighederne for at se, hvordan du tilføjer sikkerhedskopier af filer og filgrupper og gendanner for at øge hastigheden på dine sikkerhedskopier og gendanner, som begge øger systemtilgængeligheden og opetiden. Hold en fælles navngivningsstandard. Vær forsigtig, når du bruger snapshots, men brug dem bestemt. Gem dine filer på en standardplacering mellem servere. Øv dine inddrivelser. Endelig, for virkelig at få dine sikkerhedskopier til at synge, skal du hente en gratis prøveversion af Red Gate ‘ s Backupkr. Det tilbyder højtydende komprimering og netværksbestandighed for at gøre processen med at skrive eller kopiere sikkerhedskopier på tværs af flaky netværk fejltolerant.