i åpningskapitlet I Craig Mullins bok, Databaseadministrasjon, sier han «på mange måter er business today data». Innenfor de fleste organisasjoner er personen som er ansvarlig for å beskytte data databaseadministratoren … deg.

Det er riktig; hele virksomheten er i dine dyktige hender, kjører på den serveren som aldri krasjer, med alle de sluttbrukerne som aldri gjør feil ved bruk av applikasjoner, bygget av de utviklerne som skriver feilfri kode første gang, hver gang, med hjelp av den nye co-op som har’ sa ‘ privilegier takket være sjefen din.

OK. Slutt å gråte. Det er ting du kan gjøre for å beskytte SQL Server data under omsorg og en av de viktigste kjører vanlige database backup.

Sikkerhetskopier

Microsoft, I SQL Server Books Online, definerer sikkerhetskopier som:

en kopi av data som brukes til å gjenopprette og gjenopprette data etter en systemfeil

SQL-Sikkerhetskopier kan opprettes på flere måter og kan inkludere alle eller noen av dataene, samt en del av transaksjonsloggen. Mens denne artikkelen er fokusert på 2005 syntaks, de fleste av begrepene gjelder for 2000. Dette er et stort tema. I beste fall skal jeg skrape overflaten og gi deg nok informasjon, slik at du ikke begynner å gråte igjen. Etter å ha lest dette, bør du kunne sette opp et rimelig sett med sikkerhetskopier for systemet ditt.

Gjenopprettingsmodeller

forretningsbehovene definerer en databasegjenopprettingsmodell for å kunne begynne å arbeide med sikkerhetskopier. I hovedsak definerer en gjenopprettingsmodell hva du skal gjøre med transaksjonsloggdataene.

det er tre gjenopprettingsmodeller: Full, Enkel Og Bulk Logget. Disse er ganske enkle å definere:

• Enkel-i enkel gjenopprettingsmodus er transaksjonsloggen ikke sikkerhetskopiert, slik at du bare kan gjenopprette til den nyeste fulle eller differensielle sikkerhetskopien.
• Full-i full gjenopprettingsmodus sikkerhetskopierer du databasen og transaksjonsloggen slik at du kan gjenopprette databasen til et hvilket som helst tidspunkt.
• Masselogget modus for masselogget, de fleste transaksjoner lagres i transaksjonsloggen, men noen masseoperasjoner som masselast eller indeksoppretting logges ikke.

de to mest brukte modusene Er Enkle og Fulle. Ikke nødvendigvis anta at, selvfølgelig, du alltid trenger Å bruke Full gjenoppretting for å beskytte dataene. Det er en forretningsbeslutning. Virksomheten skal fortelle deg om du trenger å gjenopprette til et tidspunkt, eller hvis du bare trenger den siste fulle sikkerhetskopien. Det kommer til å definere hvis dataene er utvinnbare på andre måter, for eksempel manuell oppføring, eller hvis du har til å beskytte så mye som mulig som det kommer over ledningen. Du bruker Enkel gjenoppretting hvis du har råd til å miste dataene som er lagret siden den siste fulle eller differensielle sikkerhetskopien og / eller du bare ikke trenger gjenoppretting til et tidspunkt. I Enkel modus må du gjenopprette alle sekundære lese / skrive filgrupper når du gjenoppretter den primære. Du bruker Enkle hovedsakelig på sekundære databaser som ikke er en absolutt viktig del av virksomheten eller rapporteringssystemer, med lesetilgang så det er ikke en transaksjonslogg å bekymre seg uansett. Du bruker Full Hvis hver bit av dataene er viktig, må du gjenopprette til et tidspunkt, eller vanligvis i tilfelle AV svært store databaser (VLDB), må du gjenopprette individuelle filer og filgrupper uavhengig av andre filer og filgrupper.

med Både Enkle og full gjenoppretting modeller, kan du nå kjøre En Kopi-Bare backup som lar deg kopiere databasen til en sikkerhetskopifil, men påvirker ikke loggen, differensiell backup tidsplaner eller innvirkning utvinning til et tidspunkt. Jeg skal prøve å bore ned på så mange av disse emnene som mulig gjennom artikkelen, men ikke filene og filgruppene.

Arbeide Med Enkel Gjenoppretting

nok snakk. La oss komme ned til å kjøre sikkerhetskopier. La oss anta at Vi er I Enkel gjenoppretting på en liten til mellomstor database. Jeg skal bruke AdventureWorks for alle prøveskriptene. For å sette den til enkel gjenoppretting:

din enkleste backup strategi er å kjøre, med jevne mellomrom, FØLGENDE SQL Server backup kommando, som vil utføre en full backup av databasen:

Hva er det med all skrivingen du spør? Har VI IKKE GUI verktøy for å håndtere arbeidet for oss? Ja, de fleste enkle sikkerhetskopier kan utføres ved HJELP AV SQL Server Management Studio. Men hvis du vil lære og forstå hva Management Studio gjør for deg, eller hvis du vil ha litt finkornet kontroll over hva som er sikkerhetskopiert, hvordan og hvor, må du bryte ut tastaturet og legge bort musen.

kommandoen ovenfor vil utfelle en grunnleggende backup til disk. De Fleste DBAs jeg kjenner backup til fil og deretter skrape filene på et bånd eller et annet medium. Dette er fordi filer på disken er enkel og rask å gjenopprette, mens media kan noen ganger være litt av en smerte. For eksempel har vi vanligvis to til tre dager igjen av sikkerhetskopier på våre filsystemer for umiddelbar gjenoppretting. Vi går bare til tapesystemene hvis vi trenger å kjøre gjenoppretting for eldre sikkerhetskopier.

Hva gjorde denne kommandoen? Det gjorde en kopi av alle de engasjerte data i databasen. Det kopierte også uforpliktet loggoppføringer. Disse brukes under gjenoppretting for å enten forplikte eller tilbakekalle endringer som skjedde i dataene under sikkerhetskopieringen.

Kopier bare sikkerhetskopier

sikkerhetskopiering av en database påvirker Vanligvis andre sikkerhetskopierings-og gjenopprettingsprosesser. For eksempel etter å ha kjørt den forrige kommandoen, vil eventuelle differensielle sikkerhetskopier (en sikkerhetskopi som bare kopierer data endret siden siste sikkerhetskopi) bruke dette som utgangspunkt for dataendringer, ikke sikkerhetskopien du kjørte i går kveld. SOM nevnt tidligere, INTRODUSERER SQL 2005 et nytt konsept for sikkerhetskopier, COPY_ONLY backup, som tillater oss å holde fra å avbryte syklusen:

Allerede har vi funnet en av de mer granulære øyeblikk når Ledelsen Studio ikke ville hjelpe deg. Hvis du vil ha en kopi bare backup, må du bruke kommandolinjen.

Differensiell sikkerhetskopiering

La oss anta et øyeblikk at vi fortsatt er i enkel gjenoppretting, men vi har å gjøre med en større database, si noe over 100 GB i størrelse. Full backup kan faktisk begynne å bremse ned prosessen litt. I stedet, etter samråd med virksomheten, har vi besluttet å gjøre en ukentlig full backup og daglig differensiell sikkerhetskopiering. Differensielle sikkerhetskopier bare sikkerhetskopier datasidene som er endret siden siste fullstendige sikkerhetskopiering. Følgende ER SQL backup-kommandoen for å utføre en differensiell backup:

Nå, hvis vi måtte gjenopprette denne databasen, ville vi først gå til den siste fulle sikkerhetskopien, gjenopprette det, og deretter gjenopprette differensielle sikkerhetskopier i rekkefølge (mer om det senere).

Det finnes en rekke andre backup alternativer som jeg ikke vil være detaljering her. Les bøkene på nettet for å se detaljer OM BLOCKSIZE, EXPIREDATE, RETAINDAYS, PASSORD, NAVN, STATISTIKK og så videre.

Du kan også kjøre en setning som vil sjekke integriteten til en database backup. Det kontrollerer ikke integriteten til dataene i en sikkerhetskopi, men det bekrefter at sikkerhetskopien er formatert riktig og tilgjengelig.

Full gjenoppretting og logg sikkerhetskopier

vi har primært jobbet med en database som var I Enkel gjenopprettingsmodus (dette pleide å bli kalt Truncate Log on Checkpoint). I denne modusen sikkerhetskopierer vi ikke transaksjonsloggene for senere gjenoppretting. Hver backup under denne mekanismen er en database backup. Logg backup er rett og slett ikke mulig.

du har imidlertid bare beskyttet dataene fra den siste gode sikkerhetskopien, enten full eller differensiell. La oss endre våre forutsetninger. Nå har vi å gjøre med en stor, virksomhetskritisk applikasjon og database. Vi ønsker å kunne gjenopprette denne databasen opp til siste minutt. Dette er et veldig viktig punkt. I teorien, siden loggoppføringene blir lagret og sikkerhetskopiert, er vi beskyttet opp til feilpunktet. Noen feil kan imidlertid føre til korrupsjon av loggen, noe som gjør gjenoppretting til et tidspunkt umulig. Så, vi må finne ut hva rimelig minimum tid mellom logg backup vil være. I dette tilfellet kan vi leve med ikke mer enn 15 minutter igjen av tapte data.

Så, la oss starte med å sette vår database I FULL gjenopprettingsmodus:

så, på en planlagt basis, i dette tilfellet hvert 15. minutt, kjører VI SQL backup-kommandoen for transaksjonsloggen:

dette skriptet vil backup begått transaksjoner fra transaksjonsloggen. Den har markører i filen som viser start og stopp tid. Det vil avkorte loggen når den er fullført, og rense ut fra transaksjonsloggen de forpliktede transaksjonene som er skrevet til sikkerhetskopifilen. Hvis DET er nødvendig, kan du bruke MED no_truncate-setningen til å hente data fra transaksjonsloggen uavhengig av databasetilstanden, forutsatt at den er tilkoblet og IKKE I NØDSTATUS. Dette er for nødhjelp bare.

Merk at VI ikke bruker init-setningen i dette tilfellet, men du kan gjøre det hvis du velger. Når du gjør logg backup, har du alternativer:

1. Kjør alle sikkerhetskopiene til en enkelt fil, hvor de stabler og alt du trenger å gjøre, på gjenoppretting (dekket senere), er å sykle gjennom dem.
2. Navn sikkerhetskopiene unikt, sannsynligvis ved hjelp av dato og klokkeslett i strengen.

i det sistnevnte tilfellet sier sikkerhet, bruk INIT fordi du utøver maksimal kontroll over hva som blir sikkerhetskopiert hvor, og du vil kunne vite nøyaktig hva en sikkerhetskopi er, når den ble tatt og hvorfra basert på navnet. Dette er enda et sted hvor drifts backup fra kommandolinjen gir deg mer kontroll enn GUI. Vi har brukt begge tilnærmingene i våre systemer av forskjellige grunner. Du kan bestemme hva som er best for din teknologi og forretningsbehov.

De fleste alternativene som er tilgjengelige for sikkerhetskopiering av databasen, er inkludert I Log backup, inkludert COPY_ONLY. Dette vil tillate deg å fange opp et sett med transaksjonsdata uten å påvirke loggen eller neste planlagte logg backup. Dette ville være nyttig for å ta produksjonsdata til et annet system for feilsøking etc.

hvis du har databasen satt TIL FULL Gjenoppretting, må du kjøre logg backup. Noen ganger glemmer folk og transaksjonsloggen vokser til det punktet at den fyller opp harddisken. I dette tilfellet kan du kjøre:

Feste NO_LOG til loggen backup, og ikke angi en plassering for loggen, fører til at den inaktive delen av loggen som skal fjernes, og det gjør dette uten en logg oppføring selv, og dermed beseire hele harddisken. Dette anbefales absolutt ikke fordi det bryter loggkjeden, serien av loggbackups som du vil gjenopprette databasen til et tidspunkt. Microsoft anbefaler at du kjører en fullstendig sikkerhetskopi umiddelbart etter bruk av denne erklæringen. Videre advarer de om at denne uttalelsen kan bli avskrevet i en fremtidig utgave.

Gjenopprette Databaser

like viktig SOM SQL Server-sikkerhetskopier er, og de er viktige, de er ubrukelige uten evnen til å gjenopprette databasen.

Gjenopprette en full database backup

Gjenopprette en full database backup er så enkelt som det var å lage:

Det er egentlig så enkelt-med mindre, som vi vi sikkerhetskopierer alt til en fil som om det var en backup-enhet. I så fall må du spesifisere hvilken fil i «enheten» du har tilgang til. Hvis du ikke vet hvilken fil, må du generere en liste:

Dette vil gi deg den samme listen som jeg viste ovenfor Fra Management Studio. Så nå, hvis vi ønsket å gjenopprette den andre filen i gruppen, COPY_ONLY backup, vil du utstede følgende kommando:

Dessverre, hvis du følger med, kan du oppleve at du nettopp har generert denne feilen:

hva dette betyr er at databasen er i full gjenopprettingsmodus, men du har ikke sikkerhetskopiert «loggens hale», noe som betyr transaksjonene som er angitt siden sist du kjørte en sikkerhetskopi. Du kan overstyre dette kravet hvis du endrer forrige syntaks til:

det er første gang vi har stablet med klausuler (MED FIL=2 og MED ERSTATT er representert SOM MED FIL=2, ERSTATT), MEN det blir ikke det siste. Les gjennom bøkene på nettet. De FLESTE AV DE MED klausul uttalelser kan brukes i kombinasjon med de andre.

hva skjer Hvis vi vil gjenopprette til en annen database enn originalen? For eksempel ønsker vi å lage en kopi av databasen vår fra en egen sikkerhetskopi. Kanskje vi vil flytte den ned til en produksjonsstøtteserver hvor vi skal gjøre noe arbeid på det, skilt fra produksjonskopien av databasen. Hvis vi tar den enkle tilnærmingen, vel, prøv dette:

I dette tilfellet bør du se en hel rekke feil knyttet til filer som ikke blir overskrevet. Du kan virkelig opprette nye databaser fra sikkerhetskopier, men hvis du gjør det på en server med den eksisterende databasen, må du endre plasseringen av de fysiske filene ved hjelp av de logiske navnene. For å vite de logiske navnene på filene for en gitt database, kjør dette før du prøver å flytte filene:

Dette kan da brukes til å identifisere de riktige logiske navnene for å generere dette skriptet:

Gjenopprette en differensiell backup

den siste metoden er å bruke differensiell backup. Dette krever to trinn. Først vil vi gjenopprette databasen, men med en vri og så bruker vi differensial backup:

Det meste av dette er trolig selvforklarende basert på hva vi allerede har dekket. Den ene rynken er inkluderingen AV NORECOVERY-søkeordet. Svært enkelt, under en gjenoppretting, kan transaksjoner ha startet under sikkerhetskopieringen. På slutten av en gjenoppretting rulles fullførte transaksjoner frem til databasen og ufullstendige transaksjoner rulles tilbake. Innstilling NORECOVERY holder transaksjoner åpne. Dette gjør det mulig for neste sett med transaksjoner som skal hentes fra neste backup i rekkefølge.

vi arbeider hovedsakelig med enkle sikkerhetskopier og gjenoppretter i denne artikkelen, men en mer avansert gjenoppretting i 2005 gjør det mulig å gjenopprette sekundære filgrupper mens databasen er online. Den primære filgruppen må være online under operasjonen. Dette vil være mer nyttig for svært store databasesystemer.

Gjenopprette SQL Server-databaser til et tidspunkt

Gjenopprette logger er ikke mye vanskeligere enn differensial database gjenopprette som vi nettopp fullført. Det er bare litt mer involvert i å gjenopprette til et øyeblikk. Forutsatt at du sikkerhetskopierer loggene til en enkelt fil eller enhet:

Ellers går du bare og får filnavnene du trenger. Først kjøre databasen gjenopprette, ta vare å la den i en ikke-gjenopprettet tilstand. Folg dette opp med en serie logggjenoppretter til et tidspunkt.

Nå har vi en database som er opp til den nøyaktige, siste forpliktede transaksjonen kl 14:30: 29 den 23.oktober. Husk at under flere trinn gjenoppretter som dette, må du forlate databasen i en gjenopprettingsstatus. DET betyr å legge NORECOVERY til hver setning til du har fullført gjenopprettingsprosessen. HVIS DU av en eller annen grunn har lagt NORECOVERY til alle dine uttalelser, eller du bare stopper i midten, og ønsker å få databasen tilbake på nettet, kan du bruke denne setningen til å fullføre prosessen:

Øyeblikksbilder For Databaser

SQL Server 2005 introduserte begrepet et øyeblikksbilde, eller en skrivebeskyttet, statisk visning av en database. Øyeblikksbilder opprettes primært for å levere en skrivebeskyttet versjon av en database for rapporteringsformål. Imidlertid fungerer de på samme måte som sikkerhetskopier. Den ene primære forskjellen er at alle uforpliktet transaksjoner er rullet tilbake. Det er ingen mulighet for å rulle fremover, fange logger, etc., som sikkerhetskopier gir, og det brukes heller ikke MANGE SQL Server-ressurser i det hele tatt. I stedet brukes diskteknologi til å lage en kopi av dataene. På grunn av dette er de mye raskere enn sikkerhetskopier både for å opprette og gjenopprette.

MERK:
for mer informasjon om Sql 2005 Snapshot, se http://www.simple-talk.com/sql/database-administration/sql-server-2005-snapshots/.

en god bruk av øyeblikksbilder, i tillegg til rapportering, kan være å opprette en før vedlikehold etter at du allerede har fjernet alle aktive brukere (og deres transaksjoner) fra systemet. Selv om øyeblikksbilder ikke støtter volatiliteten til live-sikkerhetskopier, gjør deres hastighet og enkel gjenoppretting et flott verktøy for rask gjenoppretting fra en mislykket utrulling. Øyeblikksbilder lagres på serveren, så du må sørge for at du har tilstrekkelig lagringsplass.

syntaksen er annerledes fordi du ikke sikkerhetskopierer en database; du oppretter en ny:

Nå vil det være tilgjengelig for skrivebeskyttet tilgang. Siden vi først og fremst er opptatt av å bruke dette som en backup mekanisme, la oss inkludere metoden for å gå tilbake en database til en database snapshot.

identifiser først stillbildet du vil bruke. Hvis det er mer enn en på en database som du skal gå tilbake, må du slette alle unntatt den du bruker:

Deretter kan du gå tilbake databasen ved å kjøre EN GJENOPPRETTINGSERKLÆRING (blandede metaforer, ikke bra):

Sånn ja. På systemet mitt, kjører databasen øyeblikksbilder Av Adventureworks tok 136 ms. full backup tok 5,670 ms. gjenopprettingen av snapshot tok 905ms og databasen gjenopprette tok 13,382 ms. Å innlemme dette i en produksjonsutrullingsprosess kan føre til betydelige fordeler

Igjen, det er verdt Å merke seg at det er noen advarsler for å bruke øyeblikksbildet. Du må ha nok diskplass for en ekstra kopi av databasen. Du må være forsiktig med å håndtere øyeblikksbilder, siden det meste av syntaksen ligner det som brukes av databaser selv. Sist, mens det er øyeblikksbilder knyttet til en database, kan du ikke kjøre en gjenoppretting fra en databasebackup av den databasen.

Anbefalte fremgangsmåter

måten du utfører sikkerhetskopier av databaser på, bør ikke være en teknisk beslutning. Det bør dikteres av virksomheten. Små systemer med lave transaksjonsrenter og / eller rapporteringssystemer som lastes regelmessig, trenger bare en full database backup. Mellomstore systemer og store systemer blir avhengig av hvilken type data som er klart for å bestemme hvilke typer sikkerhetskopiering som kreves.

for et mellomstort system vil en daglig backup med loggbackup i løpet av dagen trolig svare på de fleste datakrav i tide.

for en stor database er den beste tilnærmingen å mikse og matche sikkerhetskopiene for å sikre maksimal gjenopprettbarhet i minimal tid. For eksempel, kjør en ukentlig full backup. To ganger om dagen i løpet av uken, kjør en differensiell backup. Hvert 10. minutt i løpet av dagen, kjør en logg backup. Dette gir deg et stort antall gjenopprettingsmekanismer.

for svært store databaser må du komme inn i å kjøre filgruppe og filbackups fordi det ikke er mulig å gjøre en full backup eller til og med en differensiell sikkerhetskopi av hele databasen. En rekke tilleggsfunksjoner er tilgjengelige for å hjelpe på dette området, men jeg vil ikke gå inn i dem her.

Du bør ta deg tid til å utvikle noen skript for å kjøre sikkerhetskopier og gjenoppretter. En navnekonvensjon slik at du vet hvilken database, fra hvilken server, fra hvilken dato, i hvilken spesifikk backup og format vil være svært bidrar til sunn fornuft. En felles plassering for sikkerhetskopier, logg, full eller inkrementell, bør defineres. Alle ansvarlige bør ha opplæring i både sikkerhetskopiering og gjenoppretting og feilsøking på samme måte. Det er mange måter å gjøre dette på, men Du kan finne noen forslag I Pop sikkerhetskopierer Og Pop Gjenoppretter.

den virkelige testen er å kjøre backup mekanismer og deretter kjøre en gjenoppretting. Prøv deretter en annen type gjenoppretting, og en annen, og en annen. Pass på at du ikke bare har gjort due diligence i å definere hvordan du sikkerhetskopierer systemet, men at du har gjort det ekstra trinnet for å sikre at du kan gjenopprette disse sikkerhetskopiene. Hvis du ikke har praktisert dette og dokumentert øvelsen og deretter testet dokumentet, er du faktisk ikke klar for en katastrofe.

Sammendrag

Sikkerhetskopier i bedriften din bør være som å stemme i Chicago, tidlig og ofte. Det er ganske enkelt å sette opp grunnleggende sikkerhetskopier. Legge på logg backup og differensialer er lett også. Utforsk alternativene for å se hvordan du legger til sikkerhetskopier og gjenoppretting av fil og filgruppe for å øke hastigheten på sikkerhetskopiene og gjenopprettingene, som begge vil øke systemtilgjengeligheten og oppetiden. Hold en felles navnestandard. Vær forsiktig når du bruker øyeblikksbilder, men absolutt ansette dem. Lagre filene dine på en standard plassering mellom servere. Øv din inngang. Til slutt, for å virkelig få sikkerhetskopiene dine til å synge, last ned En gratis prøveversjon av RED Gate ‘ S SQL Backupâ ¢. Det gir høy ytelse komprimering og nettverk elastisitet for å gjøre prosessen med å skrive eller kopiere sikkerhetskopier over flaky nettverk feiltolerant.