Administrace Oracle: Zálohování a obnova databáze Jiří Toušek
Zálohovací strategie • •
RMAN backups (zálohování pomocí Recovery Manageru) User-Managed Backup and Recovery (vše ostatní) o Import / Export utilities o zálohování fyzických souborů databáze o …
RMAN podporuje verze databáze 8.0 a vyšší. Pro tyto verze doporučuje Oracle používat raději RMAN než user-managed zálohy, nicméně user-managed zálohy jsou stále považovány za dobře použitelnou alternativu k RMAN zálohám.
Konzistentní a nekonzistentní zálohy Záloha může být konzistentní nebo nekonzistentní. Konzistentní zálohu lze vyrobit, pokud je databáze zavřená (closed) a při jejím zavírání nedošlo k chybě. Záloha databáze za jejího provozu, záloha databáze po pádu nebo záloha databáze zavřené pomocí SHUTDOWN ABORT bude nekonzistentní. Konzistentní záloha nepotřebuje po obnovení media recovery, k obnovení dat k okamžiku zálohy tedy nejsou potřeba redo logy. Po obnovení nekonzistentní zálohy je nutné provést media recovery, která pomocí redo logů uvede databázi do konzistentního stavu. (slovník:
backup = záloha restore = obnovení fyzických souborů databáze media recovery = uvedení databáze do konzistentního/aktuálního stavu za použití informací z redo logů)
Důležité soubory • • • •
data files – vlastní data databáze control file – soubor s globálním nastavením databáze; obsahuje seznam datových souborů, archivovaných logů,… log files o archived logs – archivované redo logy o current logs – redo logy aktuálně používané databází server parameter file (SPFILE) – soubor s nastavením parametrů databáze (ALTER DATABASE SET …)
Recovery Manager Recovery Manager je aplikace ve formě commandline nástroje i wizzarda. Umožňuje jednoduše zálohovat nejdůležitější součásti databáze, spravuje historii záloh.
Backup příkazy: LIST BACKUP OF DATABASE; – vypíše seznam záloh databáze; podobně LIST BACKUP OF CONTROLFILE; a další BACKUP DATABASE; – zazálohuje všechny datové soubory databáze, control file a případně server parameter file BACKUP DATABASE PLUS ARCHIVELOG; – zazálohuje také redo logy (archivuje current logs a potom zálohuje archived logs) Pozn.: Ani použití tohoto příkazu nezaručí kompletní zálohu všech dat databáze. Často jsou její součástí i externí soubory a podobně. Je proto vhodné zároveň zálohovat soubory se síťovým nastavením, hesly, důležité soubory operačního systému a také soubory v Oracle home.
Restore & recovery Poměrně intuitivní, v nejjednodušším případě (po připojení pomocí RMAN a případném zvolení zálohy): STARTUP MOUNT RESTORE DATABASE; RECOVER DATABASE; ALTER DATABASE OPEN
# mountuje DB, ale neotevírá ji # data restore # media recovery # otevře databázi
http://download-east.oracle.com/docs/cd/B10501_01/server.920/a96566/toc.htm
User-Managed Backup and Recovery „Všechno kromě použití Recovery Manageru“ • •
zálohování logických částí – pomocí utilit Import / Export; pro zálohování typicky nepříliš vhodné, protože není možné takovou zálohu pomocí redo logů přivést do aktuálního (nebo aspoň o něco aktuálnějšího) stavu zálohování fyzických součástí – kopírování souborů pomocí nástrojů OS
Proč / kdy používat user-managed zálohy? • • • •
při správě databází verze 7 a nižší – neumí RMAN při správě sítě databází starších i novějších, pokud chceme jednotnou metodu zálohování při přechodu ze starší verze DB na novou, pokud nechceme okamžitě psát nové zálohovací skripty protože jsme matfyzáci a chceme „do toho líp vidět“ – na user-managed zálohování se lépe chápe, jak zálohy a celá datová infrastruktura Oracle funguje
User-Managed backups Následující tabulka ukazuje základní typy záloh a jejich provedení bez použití RMAN: Backup Object Datafiles Archived logs
Backup Method Operating system utility Operating system utility
Control files
SQL statement
Initialization parameter file Network and password files Logical objects (tables, indexes, PL/SQL units) (převzato z dokumentace)
SQL statement Operating system utility Export utility
Example % cp df3.f df3.bak % cp log_1_23.arc log_1_23.bak SQL> ALTER DATABASE BACKUP CONTROLFILE TO cf1.bak SQL> CREATE PFILE = init.ora.bak FROM SPFILE; % cp tnsnames.ora tnsnames.bak % export SYSTEM/manager TABLE=hr.emp FILE=emp.dmp
Konzistentní záloha Pokud si můžeme dovolit odstavit databázi po dobu zálohování, je toto optimální řešení. Postup: 1. pokud databáze běží, vypněte ji (v SQL*Plus příkazem SHUTDOWN NORMAL|IMMEDIATE|TRANSACTIONAL) (pokud databáze byla vypnuta v důsledku chyby nebo příkazu ABORT, otevřete ji a pokuste se ji vypnout normálně) 2. udělejte zálohu datových souborů, control files, inicializačních souborů a dalších – záloha logů není u konzistentní zálohy nutná % cp /disk1/oracle/dbs/*.dbf /disk2/backup % cp /disk1/oracle/dbs/*.cf /disk2/backup % cp /disk1/oracle/network/admin/*.ora /disk2/backup
% cp /disk1/oracle/rdbms/admin/*.ora /disk2/backup 3. znovu otevřete databázi (např. v SQL*Plus: STARTUP) Pozn.: Konzistentní záloha jednotlivých tablespaces je také možná – v tom případě je databáze otevřená (open) a jen příslušný tablespace je offline.
Záloha online databáze Zálohovat tablespaces lze i za provozu, je však nutné po dobu zálohy přepnout tablespace do režimu BACKUP. V tomto režimu se všechny změny píší pouze do redo logu a do datových souborů se zapíší až po skončení BACKUP režimu. Pozn.: Online zálohu lze provést, jen pokud databáze běží v ARCHIVELOG módu. V NOARCHIVELOG módu lze provádět jen konzistentní zálohy. Postup: 1. zjistěte jména souborů příslušných danému tablespace: SELECT TABLESPACE_NAME, FILE_NAME FROM SYS.DBA_DATA_FILES WHERE TABLESPACE_NAME = 'users'; 2. přepněte tablespace do režimu BACKUP (bez toho nebude záloha použitelná!): SQL> ALTER TABLESPACE users BEGIN BACKUP; 3. zazálohujte příslušné datové soubory: % cp /oracle/dbs/tbs_21.f /oracle/backup/tbs_21.backup % cp /oracle/dbs/tbs_22.f /oracle/backup/tbs_22.backup 4. ukončete BACKUP režim: SQL> ALTER TABLESPACE users END BACKUP; nebo SQL> ALTER DATABASE END BACKUP; 5. archivujte současné logy: SQL> ALTER SYSTEM ARCHIVE LOG CURRENT; 6. zazálohujte archivované logy (nutné – jde o nekonzistentní zálohu) Pozn.: tablespaces je možné zálohovat paralelně, tj. vložit více BEGIN BACKUP příkazů naráz a po zazálohování provést najednou zase příslušné END BACKUP příkazy (nebo zavolat END BACKUP na celou DB).
Pokud zapomenete END BACKUP příkaz nebo databáze během zálohování spadne, při dalším startu se odmítne databáze přepnout do open módu, dokud neopustí všechny tablespaces BACKUP režim. Ve stejném stavu se totiž nachází i po obnovení ze zálohy. Pokud se databáze nachází v tomto stavu, je nutné zjistit, zda došlo k chybě při zálohování, či zda byla obnovena ze zálohy. V prvním případě je nutné provést ALTER DATABASE END BACKUP; (ukončí BACKUP režim pro všechny tablespaces), v druhém případě příkaz SQL*Plus RECOVER DATABASE (viz postup při obnově DB).
Online záloha control file Zálohu control file je vhodné udělat po každé strukturální změně databáze (např. přidání tablespace). ALTER DATABASE BACKUP CONTROLFILE TO '/oracle/backup/cf.bak' REUSE;
User-Managed Restore Obnovení databáze je nutné provést, pokud došlo k fyzickému poškození souborů databáze. Pokud došlo k poškození jen některých datových souborů a databáze stále běží, je možné zjistit, které soubory je nutné obnovit, dotazem SELECT * FROM V$RECOVER_FILE; (podmínkou je aktuální control file). Jména odpovídajících souborů a tablespaces lze zjistit pomocí pohledů V$DATAFILE a V$TABLESPACE: SELECT r.FILE# AS df#, d.NAME AS df_name, t.NAME AS tbsp_name, d.STATUS, r.ERROR, r.CHANGE#, r.TIME FROM V$RECOVER_FILE r, V$DATAFILE d, V$TABLESPACE t WHERE t.TS# = d.TS# AND d.FILE# = r.FILE#
Potřebné soubory Zde je seznam souborů, které je nutné obnovit pro následnou media recovery • control file o nejlépe aktuální, případně co nejnovější získaný příkazem „ALTER DATABASE BACKUP CONTROLFILE …“, eventuelně control file zazálohovaný společně s datovými soubory při offline záloze
•
•
datové soubory + všechny logy od okamžiku zálohy do současnosti o pokud některý datový soubor chybí, ale jsou k dispozici všechny logy od jeho vzniku, je možné jej znovu vytvořit o pokud chybí některé logy, lze provést pouze obnovy s neúplnou data recovery (návrat do času před prvním chybějícím logem) další soubory o ostatní soubory se následného media recovery přímo neúčastní, v případě jejich poškození je však bude pravděpodobně také nutné obnovit nebo znovu vytvořit
Obnovení a recovery částí běžící databáze Databáze je online, poškození se tedy týká datových souborů. Postup: 1. odpojte chybné datové soubory: ALTER TABLESPACE users OFFLINE IMMEDIATE; 2. zkopírujte příslušné datové soubory ze zálohy 3. proveďte recovery příslušného tablespace (SQL*Plus): RECOVER TABLESPACE users 4. znovu zpřístupněte tablespace: ALTER TABLESPACE users ONLINE;
Obnovení celé databáze Poškozené soubory nahraďte příslušnou zálohou, viz seznam potřebných souborů. Preferováno je zkopírování záloh na původní místo, pokud to není možné, lze použít i náhradní umístění. Podmínkou úspěšného obnovení je existence datových souborů a logů. Pokud není k dispozici aktuální verze control file, bude obnovení náročnější (systém nebude znát cesty k datovým souborům, archivovaným redo logům apod.). Pokud chybí jakákoliv záloha control file, je možné (při dobré znalosti databáze) tento soubor vytvořit znovu. Pokud nebyly při obnovení databáze k dispozici všechny soubory v ideální verzi (starý control file apod.), doporučuje se ihned po úspěšné media recovery provést úplnou zálohu.
User-Managed Media Recovery Media recovery je proces, při němž jsou obnovené datové soubory aktualizovány do nejnovějšího možného stavu pomocí dat z archivovaných redo logů (a případně aktivních redo logů).
Recovery online databáze Viz předchozí kapitola.
Kompletní recovery offline databáze Předpoklady: • všechny soubory potřebné pro kompletní recovery jsou obnoveny ze zálohy • máte administrátorská práva • neběží incomplete recovery session • jste připojen k databázi přes dedikované připojení Postup: 1. připojte se a namountujte, ale neotvírejte, databázi: STARTUP MOUNT 2. zjistěte statut datových souborů: SELECT NAME,STATUS FROM V$DATAFILE; 3. všechny soubory, které mají být zotaveny, musí být online – pokud některé nejsou: ALTER DATABASE DATAFILE '/oracle/dbs/tbs_10.f' ONLINE; 4. proveďte recovery • doporučený postup je použít SQL*Plus příkaz RECOVER DATABASE nebo RECOVER AUTOMATIC DATABASE (automaticky najde a použije potřebné logy) • kromě RECOVER DATABASE lze použít RECOVER TABLESPACE tsname nebo RECOVER DATAFILE 'filename' • alternativou je SQL příkaz ALTER DATABASE RECOVER, použití SQL*Plus je však obvykle jednodušší 5. otevřete databázi: ALTER DATABASE OPEN;
Nekompletní recovery offline databáze Typicky při chybějící záloze log souboru. První tři kroky jsou stejné jako u kompletní zálohy, jen obnovené soubory se liší – budou pravděpodobně chybět některé logy, datové soubory tablespaces vytvořených po datu, ke kterému budeme recovery dělat, nejsou potřeba. Recovery se provádí jedním z příkazů: RECOVER DATABASE UNTIL CANCEL RECOVER DATABASE UNTIL TIME '2000-12-31:12:47:30' RECOVER DATABASE UNTIL CHANGE 10034; (případně při použití záložního control file vygenerovaného příkazem „ALTER DATABASE BACKUP CONTROLFILE …“ použijte variantu „…USING BACKUP CONTROLFILE“) Ve variantě „… UNTIL CANCEL“ po aplikování posledního redo logu proveďte příkaz CANCEL. Po provedení nekompletní recovery je nutné databázi zpřístupnit příkazem ALTER DATABASE OPEN RESETLOGS; - ten zajistí, že nepoužité logy nebudou aplikovány, updatuje conrtol file, smaže obsah aktivních redo logů a resetuje log sequence number.
Recovery databáze v NOARCHIVELOG módu V NOARCHIVELOG módu nejsou archivovány logy, každá recovery tedy bude nekompletní. Kvůli absenci logů dokonce recovery ani neudělá žádné změny, přesto je ji nutné formálně provést: 1. proveďte obnovu databáze (typicky jediná možnost je obnova z co nejnovější konzistentní zálohy, případně aplikace záloh provedených pomocí utility Export) – je nutné obnovit všechny soubory, ne jen ty poškozené 2. namountujte databázi, přiveďte datové soubory online 3. proveďte formálně nekompletní recovery: RECOVER DATABASE UNTIL CANCEL CANCEL 4. otevřete databázi s RESETLOGS: ALTER DATABASE OPEN RESETLOGS;
Oblíbený scénář s DROP TABLE Na oblíbeném příkladu, kdy uživatel omylem smaže tabulku, si ukažme použití usermanaged backup & restore pro něco jiného než obnovu při poškození souborů databáze. V jednom z minulých referátů byl popsán postup obnovy ztracené tabulky pomocí FLASHBACK, zde je postup pomocí záloh a obnovení z nich: 1. Je-li to možné, nechte reálnou (produkční) databázi obsahující chybu běžet 2. zazálohujte současný stav databáze pro případ, že by se při následujících krocích „někde stala chyba“ 3. obnovte zálohu databáze na náhradní (dočasné) místo 4. proveďte na dočasné databázi nekompletní recovery do okamžiku těsně před smazáním tabulky 5. vyexportujte ztracená data z dočasné databáze použitím utility Export 6. použijte utilitu Import k navrácení dat do reálné databáze 7. zastavte dočasnou databázi a smažte ji
http://download-east.oracle.com/docs/cd/B10501_01/server.920/a96572/toc.htm
