Alt for ofte ser jeg folk, der stiller spørgsmål om sikkerhedskopieringsstrategier, de bør anvende til deres databaser. Det ser aldrig ud til at fejle, ethvert spørgsmål af denne art, som jeg er stødt på i en række forskellige fora, inkluderer aldrig deres gendannelseskrav. Jeg har ofte stødt på at overveje dine gendannelseskrav, før jeg designer din backupstrategi. Når der trykkes på krav, vil jeg ofte få backup krav for eksempel:
- Sikkerhedskopier må ikke indføre nedetid
- Behov for at kunne sikkerhedskopiere arkiverede genoptagelogfiler
- Sikkerhedskopier skal skrives til båndet
Disse krav er gode, men efter min mening bør du aldrig designe din backup-strategi uden først at dokumentere dine gendannelseskrav og indhente administrationsforekomst.
Så her er nogle spørgsmål, som jeg stiller mig selv, når jeg designer en backup-strategi. Bemærk, at disse spørgsmål alle er fokuseret på genopretningssiden af tingene.
- Hvor meget datatab har jeg råd til, når jeg gendanner databasen? Nul tab af data? Er en times datatab acceptabelt efter gendannelse af databasen?
- Er jeg nødt til at rulle frem alle transaktioner, dvs. udføre en gendannelse på tidspunktet?
- Bliver jeg nødt til at gendanne indholdet af et skema, mens de andre skemaer forbliver intakte?
- Hvor lang tid har jeg til at få databasen op at køre efter en fejl?
- Hvilken slags fejl skal jeg komme mig efter? Det er klart, at jeg skal være i stand til at gendanne fra en komplet serverfejl eller tab af en disk. Men har jeg brug for at være i stand til at komme mig efter menneskelige fejl som en person, der ved et uheld slettede en tabel?
- Vil jeg blive bedt om at gendanne sikkerhedskopien til andre servere som led i at opdatere udviklingen eller teste databaser fra en kopi af produktionen?
Hvis du spørger de fleste mennesker i Oracle-fællesskabet i disse dage, vil de fortælle dig, at du skal bruge RMAN til at sikkerhedskopiere din database. RMAN er et fantastisk produkt og er for mange ting bedre end den gamle brugeradministrerede varme eller kolde backup. Nogle Oracle DBA'er vil fortælle dig, at du skal bruge RMAN til at udføre hot backups og køre din produktionsdatabase i arkivlogtilstand. Ved at gøre det vil du dække mange af de gendannelsesscenarier, som du sandsynligvis vil stå over for. Men hvad nu hvis dit svar på spørgsmål 4 er, at du har 1 time til at komme op at køre igen, og din database er 10 TB stor. Held og lykke med at forsøge at lave en komplet gendannelse af en 10TB database på 1 time med RMAN. Og RMAN vil ikke være i stand til at hjælpe med spørgsmål 3, da RMAN ikke sikkerhedskopierer på skema-niveau.
Der er mange værktøjer til DBA’s rådighed til at sikkerhedskopiere og gendanne data i databasen. Disse værktøjer inkluderer, men er ikke også begrænsede:
- Oracle's Recovery Manager (RMAN)
- Oracle brugeradministrerede sikkerhedskopier
- Oracle eksport/import eller datapumpe
- Diskbaserede snapshots
- Diskbaseret replikering
- Oracles Data Guard
Hvilken bruger du så? Nå, hver har sine fordele og ulemper. Når du kender dine gendannelseskrav, begynder værktøjerne til at sikkerhedskopiere din database at blive klarere. Og du skal muligvis bruge mere end ét sikkerhedskopieringsværktøj for at opfylde alle dine gendannelseskrav. Hvis du som et forslag bruger RMAN med Archive Log-tilstand og intet andet, og din leder kommer til dig og siger "du skal have denne 10TB-database op og køre igen om 1 time!" dit job kan meget vel være på spil.
Hvilket fører til det næste punkt, dokumenter dine gendannelseskrav og få dem ind i din Service Level Agreement (SLA). Når du skriver og kontrollerer SLA'en, kan din ledelse sige, at de ønsker nul datatab. Det er på dette tidspunkt, at du kan bringe fordele og ulemper op ved at implementere en løsning med nul datatab ... og også nævne omkostningerne! Mange virksomheder vægrer sig ved de høje omkostninger ved en løsning uden datatab, men for andre virksomheder er omkostningerne små sammenlignet med den økonomiske byrde ved at miste enhver transaktion. Det er her, prutning og byttehandel kommer i spil. Hvis ledelsen insisterer på en nul-datatabsløsning, så er de nødt til at finde på midlerne til at støtte det, fordi RMAN (gratis) ikke vil levere det. Når først du har dine gendannelseskrav dokumenteret i SLA'en, så vil det være svært for ledelsen at bede dig om at gendanne noget, som din backupstrategi ikke er designet til at understøtte. Hvis SLA'en er på plads, og de beder dig om at gendanne hver enkelt transaktion, og din backupstrategi ikke tillader det, så har du et dokument, der siger, at der aldrig var behov for nul datatab, og dette kan hjælpe med at redde dit job.
Når det er sagt, når du har dine gendannelseskrav dokumenteret i SLA'en, skal du sørge for, at din backupstrategi giver dig mulighed for at udføre alle gendannelsesscenarier, der er dokumenteret i SLA'en. Dit job kan afhænge af det. Hvis SLA'en siger nul datatab, og du ikke implementerer Data Guard, selvom ledelsen var villig til at finansiere det, kan de måske opsige dig, fordi du ikke fulgte dit job op.
Endelig er ingen backup/gendannelsesstrategi komplet, medmindre den er grundigt testet. Du bør teste alle nødvendige gendannelsesstrategier for at sikre, at du kan opfylde alle krav, der er angivet i SLA'en. Testning bør udføres ikke mindre end én gang om året af to årsager...den ene sikrer, at ændringer i systemet ikke påvirker din evne til at udføre en påkrævet genopretning negativt, og to, holder dig opdateret om, hvordan du udfører genopretning, så hvis du skal gøre det for alvor, fumler du ikke efter proceduren. Under test kan du opdage, at din backupmetodologi understøtter gendannelsesscenarier, som er påkrævet, men som er gode at have, hvis du har brug for dem.
Og jeg kan ikke sige det nok...Test, test og test!