Maar al te vaak zie ik mensen vragen stellen over back-upstrategieën die ze voor hun databases moeten gebruiken. Het lijkt nooit te mislukken, elke vraag van dit soort die ik op verschillende forums ben tegengekomen, bevat nooit hun herstelvereisten. Ik heb vaak stomverbaasd dat ik rekening heb gehouden met uw herstelvereisten voordat u uw back-upstrategie ontwerpt. Als ik op vereisten druk, krijg ik vaak back-upvereisten, bijvoorbeeld:
- Back-ups mogen geen uitvaltijd veroorzaken
- Moet een back-up kunnen maken van gearchiveerde redo-logs
- Back-ups moeten naar tape worden geschreven
Deze vereisten zijn goed en wel, maar naar mijn mening moet u uw back-upstrategie nooit ontwerpen zonder eerst uw herstelvereisten te documenteren en beheervoorvallen te verkrijgen.
Dus hier zijn enkele vragen die ik mezelf stel bij het ontwerpen van een back-upstrategie. Merk op dat deze vragen allemaal gericht zijn op de herstelkant.
- Hoeveel gegevensverlies kan ik me veroorloven als ik de database herstel? Geen gegevensverlies? Is een uur gegevensverlies acceptabel na herstel van de database?
- Moet ik transacties doorsturen, d.w.z. een herstel op een bepaald tijdstip uitvoeren?
- Moet ik de inhoud van het ene schema herstellen terwijl ik de andere schema's intact laat?
- Hoe lang heb ik om de database in gebruik te nemen na een storing?
- Van welke fouten moet ik herstellen? Het is duidelijk dat ik moet kunnen herstellen van een volledige serverstoring of verlies van een schijf. Maar moet ik kunnen herstellen van menselijk falen, zoals iemand die per ongeluk een tafel heeft verwijderd?
- Moet ik de back-up terugzetten naar andere servers als onderdeel van het vernieuwen van ontwikkel- of testdatabases vanuit een productiekopie?
Als je de meeste mensen in de Oracle-gemeenschap tegenwoordig vraagt, zullen ze je vertellen om RMAN te gebruiken om een back-up van je database te maken. RMAN is een geweldig product en is in veel opzichten beter dan de oude, door gebruikers beheerde warme of koude back-ups. Sommige Oracle DBA's zullen u vertellen dat u RMAN moet gebruiken om hot backups uit te voeren en uw productiedatabase in archieflogmodus te laten draaien. Door dit te doen, dekt u veel van de herstelscenario's waarmee u waarschijnlijk te maken zult krijgen. Maar wat als uw antwoord op vraag 4 is dat u 1 uur hebt om weer aan de slag te gaan en uw database 10 TB groot is. Veel succes bij het proberen om een volledige herstel van een 10TB-database in 1 uur met RMAN uit te voeren. En RMAN kan niet helpen met vraag 3, aangezien RMAN geen back-up maakt op schemaniveau.
De DBA beschikt over veel tools voor het maken van back-ups en het herstellen van gegevens in de database. Die tools omvatten, maar zijn ook niet beperkt tot:
- Oracle's Recovery Manager (RMAN)
- Door gebruikers beheerde back-ups van Oracle
- Oracle export/import of Data Pump
- Op schijf gebaseerde snapshots
- Op schijf gebaseerde replicatie
- Oracle's Data Guard
Dus welke gebruik je? Nou, elk heeft zijn voor- en nadelen. Zodra u uw herstelvereisten kent, worden de tools om een back-up van uw database te maken duidelijker. En mogelijk moet u meer dan één back-uptool gebruiken om aan al uw herstelvereisten te voldoen. Als u, zoals de een of andere suggestie, RMAN gebruikt met de modus Archieflogboek en niets anders, en uw manager komt naar u toe en zegt:"u moet deze 10TB-database binnen 1 uur weer up-and-running krijgen!" je baan staat misschien op het spel.
Dat leidt tot het volgende punt:documenteer uw herstelvereisten en neem ze op in uw Service Level Agreement (SLA). Bij het schrijven en controleren van de SLA kan uw management zeggen dat ze geen gegevensverlies willen. Het is op dit moment dat u de voor- en nadelen kunt noemen van het implementeren van een oplossing voor gegevensverlies zonder gegevens... en ook de kosten kunt noemen! Veel bedrijven zijn huiverig voor de hoge kosten van een oplossing voor gegevensverlies zonder gegevens, maar voor andere bedrijven zijn de kosten laag in vergelijking met de financiële last van het verliezen van een transactie. Dit is waar het afdingen en ruilen in het spel komen. Als het management aandringt op een oplossing zonder gegevensverlies, dan moeten ze met het geld komen om dit te ondersteunen, omdat RMAN (gratis) het niet gaat leveren. Als uw herstelvereisten eenmaal in de SLA zijn vastgelegd, zal het voor het management moeilijk zijn om u te vragen iets te herstellen waarvoor uw back-upstrategie niet is ontworpen. Als de SLA van kracht is en ze vragen u om elke afzonderlijke transactie te herstellen en uw back-upstrategie staat dit niet toe, dan heeft u een document waarin staat dat nul gegevensverlies nooit nodig was en dit kan u helpen uw taak te redden.
Dat gezegd hebbende, moet u ervoor zorgen dat uw back-upstrategie u in staat stelt om elk herstelscenario uit te voeren dat in de SLA is gedocumenteerd, zodra uw herstelvereisten zijn gedocumenteerd in de SLA. Je baan kan ervan afhangen. Als de SLA zegt dat er geen gegevens verloren gaan en u Data Guard niet implementeert, ook al was het management bereid dit te financieren, dan kunnen ze u misschien ontslaan omdat u uw werk niet voldeed.
Ten slotte is geen enkele back-up-/herstelstrategie compleet tenzij deze grondig is getest. U moet elke vereiste herstelstrategie testen om ervoor te zorgen dat u kunt voldoen aan alle vereisten die in de SLA worden vermeld. Testen moeten om twee redenen niet minder dan één keer per jaar worden uitgevoerd:ten eerste zorgt ervoor dat wijzigingen aan het systeem geen negatieve invloed hebben op uw vermogen om een vereist herstel uit te voeren en twee om u op de hoogte te houden van het uitvoeren van herstel, zodat als je het echt moet doen, ben je niet aan het zoeken naar de procedure. Tijdens het testen zult u ontdekken dat uw back-upmethodologie herstelscenario's ondersteunt die nodig zijn, maar handig zijn als u ze nodig hebt.
En ik kan het niet genoeg zeggen….Test, test en test!