Sei sulla pagina 1di 17

BACKUP & RECOVERY

14

INDICE

Definizioni e concetti di recovery interni


Generazione di redo entries 2 System Change Number 2 Redo log switching 2 Checkpoints 2 Definizioni e concetti di recovery interni 3 Log History 3 Struttura dei Control Files, Data Files e Log Files

Tipi di recovery

4
5

Tipi di Recovery 5 Block Recovery 5 Redo Application (crash recovery o Instance recovery) Media Recovery 5

Tecniche di backup
Backup a freddo (offline) Backup a caldo (Online)

6
7 8

Tecniche di Recovery

Metodi di recovery al punto di Failure 10 Database recovery 10 Recovery di tablespace 11 Recovery di data file 11 Perdita di un datafile NON del SYSTEM tablespace ma con Rollback Segment online Metodo di recovery incompleto 13 Recover until time 13 Recover until change 13 Recover until cancel 13 Creazione di controlfile e datafile 14

12

Definizioni e concetti di recovery interni

Definizioni e concetti di Recovery interni

Per recovery si intende il recupero di una situazione consistente della base dati, in maniera pi o meno automatica, al verificarsi di una situazione scorretta (errore) Le strutture che supportano questa attivit sono rollbacks (per la before image), redo log(per before e after image), e processi di sistema

Generazione di redo entries


Allinterno dei redo log vengono registrati i cambiamenti che avvengono allintero database. Tra questi bisogna includere anche i cambiamenti che avvengono allinterno dei segmenti di rollback ed escludere ci che avviene nei segmenti temporanei. Ogni entry dei redo porta indicazioni a basso livello di quello che avviene nei blocchi Oracle (indirizzo, versione del blocco, operazione effettuata) questa entit viene chiamata vettore. Linsieme di vettori generati da ogni singola operazione atomica che viene effettuata sul database prende il nome di redo record. E garantita latomicit di questa entit allinterno di ogni redo log.

System Change Number


Il System Change Number (SCN) sostanzialmente il clock della base dati, si tratta di una sequenza crescente di valori che ad ogni transazione registrata nel redo log viene incrementata di ununit. Il suo valore viene riportato in tutte le strutture della base dati (control file, data file e redo log) dai processi dellistanza. Vi sono valori di SCN che assumono un significato particolare: Low SCN e High SCN sono rispettivamente il primo valore e lultimo che vengono registrati allinterno di un singolo redo log considerati 2 redo log successivi, il valore di low SCN del secondo redo log pari al valore di High SCN del primo incrementato di un unit. Nella vista di sistema v$log_history sono visibili questi due valori per ogni redo log Stop SCN il valore che viene registrato nei controlfile e nellheader dei datafile nel momento in cui il tablespace relativo viene messo in stato di offline.

Redo log switching


Si tratta delloperazione che effettua il processo LGWR nel momento in cui un redo log saturo e si rende necessario utilizzarne un altro. Questa azione scatenata dai seguenti eventi: Non c pi spazio nel redo log corrente Il comando alter system switch logfile viene dato dal DBA. Il processo di switch segue i seguenti passi: 1. Selezione di un redo log libero linformazione contenuta nei controlfile, se ce n pi di uno, Oracle sceglie quello inutilizzato da pi tempo. 2. Il buffer dei log viene scaricato nel redo corrente e per tutto il tempo in cui ci avviene non vengono generate altre redo entries da nessun processo (il tempo brevissimo, nel caso non lo fosse il db si porterebbe in uno stato di hang). 3. Vengono scritte le informazioni di switch nei control file e datafile header e chiuso il log 4. Viene aperto il nuovo log.

Checkpoints
Levento di checkpoint forza il flush dei buffer allinterno dei datafile. Dopo questo evento il contenuto dei log non pi necessario per un eventuale instance recover. Un checkpoint pu essere scatenato dalle seguenti situazioni Redo log switching Dal DBA tramite listruzione alter system checkpoint Ogni volta che un redo log raggiunge un numero di redo entries pari al valore del parametro LOG_CHECKPOINT_INTERVAL

Ogni volta che trascorso un tempo pari al valore del parametro LOG_CHECKPOINT_TIMEOUT dallultimo checkpoint Definizioni e concetti di recovery interni

Log History
Il valore MAXLOGHISTORY contenuto allo interno del controlfile indica il numero di log archiviati (vedi archiving dei redo log) che il controlfile ricorda con i relativi SCN per una eventuale recovery. Questo parametro e possibile impostarlo soltanto alla creazione del database e alla ricreazione dei controlfile (vedi creazione dei controlfile)

Struttura dei Control Files, Data Files e Log Files


Control files
Allo interno dei control files le informazioni sono suddivise in 5 parti 1. Nella prima sezione sono contenute le informazioni relative al database (numero dei data files, dei log files, thread di redo aperti ) 2. Nella seconda parte vi sono informazioni specifiche per i redo thread (in configurazione classica, quindi non in parallel server, il numero di thread aperti e pari a 1 e le informazioni di conseguenza riguardano solo questo thread), come il numero di gruppi e lattuale gruppo attivo. 3. La terza parte contiene informazioni per ogni log member (dimensione del log file, pathname completo, log sequence number relativo, low e high SCN, thread di appartenenza). 4. La quarta parte contiene le informazioni sui datafile: il nome comprensivo di path assoluto, la dimensione in blocchi Oracle. 5. La quinta parte contiene le informazioni riguardanti la storia dei redo log

Data files
Il primo blocco dei data files contiene lheader del datafile stesso, nel quale sono contenute le stesse informazioni presenti nei control files relativamente al datafile in questione. In aggiunta vi linformazione relativa allo stato di backup del data file (vedi backup a caldo). I restanti blocchi sono i blocchi dei dati. Ogni blocco dei dati contiene un suo personale header con le informazioni relative: indirizzo del blocco, il tipo di blocco (blocco di unindice, di una tabella ecc.), la versione del blocco, la quale cambia ogni volta che il blocco viene inserito in cache per essere modificato.

Log files
Il primo blocco del log file lheader, il quale contiene il sequence number del log, il thread number,i valori di slow e high SCN e alcuni flag che indicano lo stato del thread.

Tipi di recovery

Tipi di Recovery

Block Recovery
Viene eseguito automaticamente da Oracle durante le normali attivit del database. E completamente trasparente allutente.

Non si tratta della recover di un blocco di data file ma della sua immagine nei buffer della memoria. Il verificarsi della necessit di recuperare un blocco dovuto sostanzialmente a due differenti situazioni, la morte di un processo che stava modificando il buffer dei dati oppure lo scoprire la corruzione logica di un blocco nella cache. Nel primo caso si tratta della necessit di recuperare limmagine precedente del buffer, la quale contenuta nei log file, nel secondo di ricostruire limmagine ultima disponibile del blocco, ed anche questa informazione contenuta nei log file. Non vi mai la necessit di scorrere pi dellultimo log file in quanto allo switch stato fatto un flush dei blocchi su disco. Il processo che si occupa di questo tipo di recovery il PMON.

Redo Application (crash recovery o Instance recovery)


Quando per un qualsiasi motivo listanza del database muore (caduta della macchina su cui attiva, mancanza di corrente ecc.) il database allo startup successivo dovr effettuare un crash recovery. Lazione di recovery avviene nel momento in cui il database passa dallo stato di mount allo stato di open. Fino a quando il crash recovery non terminato il database non viene aperto. Lazione di crash riproducibile dal DBA tramite il comando shutdown abort, il quale ha leffetto di non aggiornare lo stop SCN con il valore corrente e, ancora pi importante, di non effettuare il Checkpoint. Nel momento in cui listanza Oracle risale, controlla come essa sia stata chiusa, se lo stop SCN non stato aggiornato esso ha un valore pari ad infinito. Nel caso che questi non sia aggiornato ad un valore diverso da infinito, listanza Oracle controlla il valore dello start SCN (deve essere 0). Se lo start SCN contiene un valore diverso da 0, allora chiaro che si tratta di un crash recovery. Di solito lo start SCN ha un valore maggiore di 0, dato che il numero di SCN un progressivo assoluto per il database in questione, mentre lo stop SCN viene posto al valore raggiunto dallultima transazione confermata(COMMIT), ad ogni checkpoint, per essere riportato ad infinito nel redo log file successivo, aperto dopo il checkpoint. In pratica il redo log file che ha subito il checkpoint avr start SCN e stop SCN diversi da 0, il redo log file che viene aperto dopo il checkpoint avr lo start SCN = stop SCN del precedente redo log file + 1, e lo stop SCN a infinito. La situazione di consistenza viene recuperata leggendo i redo log attivi e riapplicando il loro contenuto al database (roll farward), questi portano il database in uno stato di consistenza come lo era prima che listanza subisse il crash. Unica differenza la morte dei processi che stavano modificando i buffer. Quindi per ottenere il database in uno stato consistente ancora necessario eseguire il rollback di tutte le transazioni non committate che erano state effettuate prima del crash.(roll backward), ma che avevano provocato laggiornamento dei blocchi dei datafiles. Questultima situazione riguarda blocchi aggiornati ma relativi a transazioni non confermate, che per devono abbandonare la cache dei dati a favore di altre transazioni che richiedono spazio. A questo punto i datafile vengono aggiornati con dati nuovi ma non confermati, quindi opportuno memorizzare la Before Image di questi aggiornamenti sui Redo Log File, per essere eventualmente utile in caso di crash per la fase di roll backward, altrimenti i datafiles conterrebbero dati inconsistenti in quanto non confermati.

Media Recovery
La meccanica del media recovery identica a quella del crash recovery, ma richiede lintervento esplicito del DBA. Ogni volta che si subisce la perdita di una delle strutture fisiche della base dati (rottura di un disco, cancellazione accidentale dei data file, ecc.) Oracle non in grado di operare. Tra i casi in cui necessario eseguire un media recover ci sono: Lutilizzo di un controlfile di backup causa la perdita di quello corrente e di tutte le sue copie, o la chiusura di un data file senza il checkpoint (offline immediate) sono situazioni in cui il media recovery necessario. Il media recovery pu richiedere non solo lapplicazione di tutti i redo log presenti ma anche le immagini che i redo avevano prima di essere ricoperti. Per questo motivo Oracle permette di archiviare le vecchie copie dei redo in file del tutto identici ad essi che vengono chiamati log archive o pi banalmente archive.

Tecniche di backup

Tecniche di Backup

Le diverse tecniche di backup garantiscono un certo livello di sicurezza ed una certa velocit di ripristino in caso di necessit di recover. Non sempre la tecnica che garantisce la perfetta ricostruzione del database quella migliore, potrebbe rivelarsi pi utile eseguire il recover in tempi brevissimi piuttosto che salvare tutti i dati. Queste considerazioni sono alla base delle scelte che un DBA deve prendere e devono essere prese in funzione delle esigenze del committente. Di seguito si vagliano i metodi di backup fisico, propedeutici alla successiva trattazione del recovery.

Backup a freddo (offline)


Il backup offline una copia di tutte le strutture fisiche del database effettuata tramite utility di sistema. Per ottenere una copia consistente del database fondamentale che il database sia stato fatto scendere in shutdown normal/transactional/immediate e non in abort. I vantaggi di un backup a freddo sono nella rapidit in fase di successiva recovery. Lo svantaggio che per essere effettuato necessario rendere la base dati indisponibile fino al completamento delloperazione (anche ore). Il backup a freddo ha due alternative, lutilizzo o meno degli archive. La scelta se operare archiviando i redo o meno pu essere presa alla creazione del database specificando nella clausola di create la parola chiave archivelog, o quando il database si trova in stato di mount ma non open specificando il comando:

Alter database archivelog


In questa situazione il redo log che gi stato riempito non viene reso disponibile per il suo riutilizzo fino a quando non viene archiviato. Se LGWR non pu scrivere le entries allinterno dei redo, Oracle non permette nessunaltra operazione sul db che entra quindi in uno stato di hang. Larchiviazione dei redo pu essere automatica o manuale. Specificando semplicemente i comandi prima descritti ci si porta in una situazione di archiviazione manuale, si quindi in una situazione di stallo potenziale del db. Un db in fase di hang pu essere liberato forzando larchiving manuale di redo (alter system archivelog all) o ripulendo (sconsigliatissimo) i log senza archiviarli (alter system clear unarchived log group) Pi semplice risulta abilitare larchiviazione automatica tramite il comando alter database archivelog start o specificando allinterno dellinit.ora il parametro ARCHIVE_LOG_START = TRUE. I file di archive verranno prodotti allinterno del path specificato nel parametro ARCHIVE_LOG_DEST presente nel parameter file (init.ora) e avranno il formato definito attraverso il parametro ARCHIVE_LOG_FORMAT. Il processo Oracle che si occupa dellarchiviazione automatica dei redo log si chiama ARCH.

In noarchivelog
Il risultato delloperare con questo metodo lottenimento di una fotografia del database in un determinato istante, ovviamente a database chiuso, cio dopo shutdown dellistanza. Un eventuale recovery utilizzando questa tipo di backup prevede la perdita di tutti i dati immessi nellistanza dal momento del backup al momento del failure. Tendenzialmente il backup a freddo viene effettuato su quei sistemi come i Datawarehouse, in cui i dati sono facilmente riproducibili e sono caratterizzati da una forte elaborazione che tende a produrre quantit enorme di archive in poco tempo, creando problemi di contenimento dei dati sulle strutture della macchine, dischi, tape, oltre a produrre un tempo di restore molto alto. Tendenzialmente quindi viene utilizzato il backup a freddo in ambienti non predisposti allarchiving. Nei Datawarehouse spesso si usa caricare i dati con SQL*Loader ma con lopzione di NOLOGGING il che significa che per il caricamento di quei dati non viene generato alcun Redo Log. Altrettanto efficace pu essere definire i Tablespace, in cui i dati verranno inseriti, con attributo NOLOGGING.

Tecniche di Backup

In archivelog
In questo modo si riesce a recuperare la situazione fino al momento del failure. Il recupero pu riguardare tutti i datafile corrotti, limportante che vi sia almeno una copia del control file, anche se copia di vecchia data, basta indicare al recover che si tratta di un control file di backup, e i Redo Log File correnti, per il ripristino delle transazioni pi recenti.

Backup a caldo (Online)


Il backup a caldo, ovvero a database aperto e disponibile allutenza, pu essere effettuato solamente se il database in archivelog. La tecnica di backup consiste nei seguenti punti: 1. congelare il contenuto di un tablespace mediante il comando alter tablespace begin backup, 2. effettuarne una copia tramite le utility di sistema dei datafile relativi al tablespace 3. riportare il tablespace in situazione di normale funzionamento con il comando alter tablespace end backup 4. ripetere le operazioni dal passo 1 per tutti i tablespace 5. copiare i controlfile.

Il tablespace continua in ogni caso ad essere aggiornato dalle transazioni, come qualsiasi altro tablespace aperto, lunico congelamento riguarda la header dei relativi datafile, che mantengono lultimo numero di SCN che avevano prima del congelamento, anche in presenza di checkpoint durante la fase di copia. Il datafile che viene copiato con lutility un datafile sporco, in quanto permettendo contemporaneamente sia la copia dello stesso che gli aggiornamenti dovuti alle transazioni, probabile che non si tratti di aver copiato dei dati consistenti. Ma laccortezza di considerarlo al momento del SCN congelato, permette che leventuale ripristino riparta dalla transazione, situata sui log archive, SCN congelato + 1. Durante la fase di congelamento del tablespace, tutte le informazioni relative ad esso vengono redirette sui redo log, generando un overhead di dati nel loro interno. Per questo motivo importante non mettere in begin backup tutti i tablespace contemporaneamente.

Tecniche di Recovery

Tecniche di Recovery

Tutti i metodi descritti di seguito trattano casi di media failure, il crash recovery si visto che unoperazione che esula dallintervento esplicito del DBA. Il media failure prevede sempre lapplicazione di almeno un elemento (i controlfile, un datafile) obsoleto rispetto al resto delle strutture del database il quale viene aggiornato attraverso le redo entries. Oracle si accorge della necessit di effettuare un media recovery quando il Checkpoint Counter presente nel controlfile non uguale al Checkpoint Counter presente nel data file. La recover partir sempre dal valore di Checkpoint Counter pi basso tra tutti. Da notare che il Checkpoint Counter viene aggiornato per quei datafiles che si trovano in begin backup da parte del loro Tablespace, con ci si evitano eventuali richieste di recover per datafiles che durante la copia abbiano subito dei checkpoint.

Disponibilit di log
La possibilit di applicare le diverse tecniche di recovery fisico fortemente vincolata dalla disponibilit o meno degli archive dei redo log. Un database in noarchive log, ad esempio, non potr mai essere recoverato fino al punto di failure, ma solamente al punto in cui stato eseguito il backup (point in time recovery). Allo stesso modo, un database in archivelog del quale non si abbia la completa successione degli archive dal backup al punto di failure, recoverabile solamente fino al punto in cui la successione interrotta.

Metodi di recovery al punto di Failure


Come detto, per riottenere il database consistente fino ad un attimo prima del punto di failure, necessario avere a disposizione il backup del database e tutti gli archive prodotti dal backup al failure. A questo punto possibile scegliere se applicare la recover fino allultimo timestamp o fermarsi prima. Questo paragrafo tratta il primo caso. Oracle mette a disposizione diversi metodi per effettuare il recover, il quale, a parit di risultato, deve sempre essere il pi breve possibile, in modo da rendere nuovamente utilizzabile il database. I metodi dipendono quindi dalla gravit del danno che il database ha subito, nel caso il danno si riduca ad un unico datafile sicuramante meglio, avendone la possibilit, recoverare solamente esso piuttosto che lintero database (si pensi alla quantit minore di redo che devono essere riapplicati). I metodi che Oracle mette a disposizione sono sostanzialmente tre: database recovery tablespace recovery datafile recovery di seguito verranno discussi i tre metodi.

Database recovery
Il recovery di tutto il database consiste nellapplicazione del contenuto dei redo log (e se fosse necessario degli archive) su tutti i datafile del database. E necessario che almeno un elemento tra datafile e controlfile sia relativo allistante del failure. Partendo dal caso pi semplice, ovvero con i control file attuali si vuole analizzare cosa comporta questo genere di recovery. Come primo passo necessario effettuare un restore da sistema operativo dei datafile danneggiati (o volendo anche tutti i datafile) e posizionare nel path specificato dal parametro LOG_ARCHIVE_DEST gli archive dei redo log prodotti dal momento del backup in poi. In seguito necessario far partire il database in mount in modo che possa leggere i controlfile (startup mount) Dopodich necessario impartire il comando di recover database. Essendo una recover su tutto il database necessario che il database non sia contemporaneamente acceduto dagli utenti , per questo il comando viene accettato solamente a database in stato di mount. Ad ogni applicazione di redo log (o archive) Oracle restituisce il prompt per lasciare alloperatore la scelta se fermare la recover a questo stadio, applicare il prossimo redo (o archive) oppure procedere automaticamente fino al termine della recovery. Essendo un complete recover il comando ideale AUTO seguito da invio Al termine delloperazione di recover sar necessario aprire il database (alter database open). Durante questa fase Oracle eseguir ancora il roll backward prima di rendere disponibile il database a tutti. I vantaggi nelloperare in queste condizioni sono tutti del DBA, infatti il database chiuso, e completamente disponibile alle sue necessit. Per di pi Oracle, se messo nelle condizione per farlo (archive nel path specificato), in grado di effettuare da solo tutte le operazioni fino al termine della fase di roll farward. Tecniche di Recovery

Gli svantaggi derivano dalla indisponibilit del database allutenza che in alcuni casi potrebbe portare ad un non rispetto delle specifiche di servizio pattuite (vedi database funzionanti 24 ore su 24, 7 giorni su 7). Nel caso in cui una delle strutture perse,tra le altre, siano i control file, lunica via di recover quella del database completo. I passi da eseguire sono: Restore di una copia il pi possibile recente dei controlfile e dei datafile eventuali Impartire il comando startup mount. Impartire il comando recover database using backup controlfile Applicare i redo log fino al punto di failure con le tecniche gia viste nel caso precedente Aprire il database con lopzione di reset dei logs (alter database open resetlogs), necessaria in quanto le informazioni dei controlfile non sono contenute nei log e quindi continuerebbe ad esserci un disallineamento tra le informazioni contenute nei control e le informazioni contenute nei redo. In effetti se lunica struttura persa sono i controlfile il metodo migliore per recoverare il database ricearli direttamente. Si vedr pi avanti come.

Recovery di tablespace
Nel caso in cui tutti i data file persi siano relativi ad un unico tablespace si pu decidere di recoverare solamente esso rendendo disponibile allutenza il resto del database. Essendo il tablespace un unit logica essa solamente visibile in stato di open del database, pertanto aprire il database anche lunico modo per eseguire una recover di questo tipo. Ovviamente eseguire la recover del tablespace possibile solo se il tablespace non potenzialmente raggiungibile dallutenza, quindi possibile solo se il tablespace offline. I passi per eseguire questa tipo di recover sono i seguenti: Restore dei datafile relativi al tablespace e degli archive necessari. Apertura del database con il comando alter database open Chiusura del tablespace relativo (alter tablespace tablespace_name offline normal o immediate) Esecuzione della recover con il comando recover tablespace tablespace_name Riapertura del tablespace con il comando alter tablespace tablespace_name online I vantaggi di questo recover sono nella disponibilit del database allutilizzo durante la fase di recover e la possibilit di isolare dal database una fetta logica di esso, secondo quella che la visione di un database dalla parte di chi lo utilizza. Svantaggi sono limpossibilit di recoverare il tablespace system o un tablespace con rollback segment online, non essendo possibile metterli in uno stato di offline, limpossibilit di operare a database chiuso, e limpossibilit di effettuare una recovery parziale in un punto del passato, pena il disallineamento temporale della base dati e la potenziale inconsistenza.

Recovery di data file


La tecnica precedente trae vantaggi di velocit rispetto al recovery completo che sono maggiormente evidenziati da questa tecnica. Nel caso il datafile che necessita di recover sia solo uno o siano pochi e di tablespace differenti pu tornare utile recoverare solo questi piuttosto che tutto il database o tutte e sole le tablespaces implicate. Essendo il datafile una struttura fisica possibile che la recover avvenga in stato di offline del database ma non fondamentale. Seguiamo i passi necessari per la recover nel caso in cui lo si voglia fare a database aperto: Restore del datafile corrotto o perso e degli archive necessari Startup mount per leggere i controlfile Messa in offline del data file per le ragioni del caso precedente(alter database datafile file_name offline) Apertura del database. Recover del database con il comando recover datafile file_name Messa in online del data file alter database datafile online

Essendo aperto anche il tablespace che possiede questo data file gli unici oggetti che non saranno disponibili sono quelli che sono memorizzati tutti o in parte allinterno del data file. Ogni volta che vi sar un tentativo di accesso ad essi verr restituito un errore. Tecniche d i Recovery I vantaggi di questo metodo sono tutti nella velocit di recover e nella possibilit di scegliere se operare online o offline. Gli svantaggi sono nella impossibilit di eseguire un recovery parziale e nellimpossibilit di recoverare i datafile del tablespace system o un tablespace con rollback segment online, qualora si operi a database online.

Perdita di un datafile NON del SYSTEM tablespace ma con Rollback Segment online
Simuliamo in questo esempio la perdita di un datafile con Rollback Segment (RBS03) online al momento del crash. Ammettiamo ch euna transazione utilizzi quel Rollback Segment: Da una finestra sql*Plus: SQL > connect scott/tiger@bd3_beq SQL > set transaction use rollback segment RBS03; SQL > insert into EMP values (1000,Rossi,CLERK,7788,02-may-00,1000,null,10); Da una finestra DOS, lanciamo Server Manager, cio svrmgrl: SVRMGR > set instance bd3_beq SVRMGR > shutdown abort SVRMGR > exit Rinominiamo il file dove si trova il rollback segment RBS03 in modo che sia cos indisponibile. Da una finestra DOS, lanciamo Server Manager, cio svrmgrl: SVRMGR > set instance bd3_beq SVRMGR > startup mount pfile = SVRMGR > alter database datafile file dove si trova il rollback segment RBS03 offline; (oppure offline drop se siamo in noarchivelog) SVRMGR > alter database open; SVRMGR > select * from scott.emp; ORA-00376: file # cannot be read at this time ORA-01110: data file # : file dove si trova il rollback segment RBS03 (infatti Oracle non sa se la transazione sia stata committed o rolled back) Rinominiamo il file dove si trova il rollback segment RBS03 come era prima, in modo che sia ora disponibile. Da una finestra DOS, lanciamo Server Manager, cio svrmgrl: SVRMGR > recover tablespace RBS; (ammettiamo si chiami RBS il tablespace ospitante il file)

SVRMGR > alter tablespace RBS online;

SVRMGR > select * from scott.emp; Ora FUNZIONA ! Tecniche di Recovery

Metodo di recovery incompleto


Si accennato diverse volte alla possibilit di operare una recover incompleta, fermandosi in un certo punto del passato piuttosto che raggiungere il punto di failure. Eseguire una simile operazione porta comunque a d un disallineamento di alcune informazioni contenute in alcune strutture, il quale va sanato con un operazione esplicita che se non effettuata data non permette la riapertura del database. Le condizioni necessaria per poter effettuare la recovery in un punto nel passato utilizzare data file che siano non pi recenti del punto che si prescelto. Ed almeno un elemento del db, tra datafile e controlfile, che sia non pi vecchio del punto che si prescelto. I redo log non sono importanti. Al termine delloperazione di roll forward necessario aprire il database con il comando alter database open resetlogs, in quanto il contenuto dei redo log non pi allineato (presumibilmente pi recente) con il contenuto desiderato dei datafile. I metodi per ottenere questo risultato sono tre e sono descritti qui di seguito.

Recover until time


Permette di fermare la recover ad un istante temporale ben preciso. E utile quando ad esempio per errore si sia droppata una tabella i cui dati servono fino allultimo inserito e si conosce il momento preciso in cui si effettuata la drop. Supponendo di volersi fermare alle ora 14:33 del giorno 22 gennaio del 2000 si eseguir il comando Recover database until time 2000-01-22:14:33:00 La sequenza di operazioni necessarie e: Restore dei datafile Alter database mount Recover database until time 2000-01-22:14:33:00 Alter database open resetlogs Backup del database

Recover until change


Permette di fermare la recover ad un ben determinato valore di SCN, ha il vantaggio di essere ancora pi precisa della precedente e lo svantaggio che la ricerca del valore di SCN desiderato pu essere lunga e laboriosa. Supponendo di volersi fermare prima del valore SCN di 65341 si eseguir il comando Recover database until change 65340 La sequenza di operazioni necessarie Restore dei datafile Alter database mount Recover database until change 65340 Alter database open resetlogs Backup del database

Recover until cancel


Permette di fermare la recover allultimo redo log (archive log) applicato. E molto utile quando la sequenza di archive interrotta a causa della indisponibilit di uno di essi, o quando un redo log corrotto e le informazioni in esso contenute non sono pi valide. E unopzione che a differenza elle altre due esprimibile solo durante una recover interattiva.

Nel momento che Oracle ha applicato un redo log restituisce il prompt perch loperatore possa scegliere tra le diverse opzioni disponibili Continuare con il prossimo archive suggerito INVIO Cambiare archive full name dellarchive + INVIO Continuare automaticamente con la sequenza di default AUTO + INVIO Terminare il recover CANCEL + INVIO La recover until cancel prevede luso delle prime due opzioni fino al momento in cui verr eseguita la quarta opzione. Tecniche di Recovery E importante che anche questo recover , una volta ultimato sia seguito da un backup completo della base dati.

Creazione di controlfile e datafile


Molte volte piuttosto che operare un vero e proprio recover necessario, o pi semplicemente utile, ricreare le strutture del database. Come e perch ricreare i redo log un argomento che esula dalla teoria del backup e recovery. Come ricreare un controlfile o un datafile invece parte degli argomenti trattati. Controlfile Per vari motivi, se possibile, meglio ricreare il controlfile piuttosto che applicare una recover da un controlfile di backup, primo fra essi lopportunit di non dover eseguire un resetlogs al termine del recover. Il comando per ricreare un controlfile segue la seguente sintassi: CREATE CONTROLFILE [REUSE] [SET] DATABASE [dbname] LOGFILE filespec [, filespec, ] RESETLOGS | NORESETLOGS DATAFILE filespec [, filespec, ] [MAXLOGFILES integer] [MAXLOGMEMBERS integer] [MAXLOGHISTORY integer] [MAXDATAFILES integer] [MAXINSTANCES integer] [ARCHIVELOG | NOARCHIVELOG] Quando si ricrea un controlfile necessario non dimenticare nessun datafile (logfile), o sbagliarne le specifiche porta a spiacevoli conseguenze e a recover ben pi complesse. Per ovviare alla facilit con cui si commettono errori possibile ottenere uno script di create con le caratteristiche del database tramite il comando alter database backup controlfile to trace il risultato un file di trace che viene scritto allinterno del path specificato dal parametro USER_DUMP_DEST nellinit.ora Se il controlfile viene ricreato specificando la parola chiave NORESETLOGS il suo SCN viene allineato con quello attuale del database (contenuto nei redo log) e non necessario aprire successivamente il database tramite un resetlogs, se invece viene specificato RESETLOGS si dovr per forza eseguire un resetlogs allopen del db. Datafile La creazione di un datafile diventa necessaria quando in una sequenza temporale si sono verificate le seguenti situazioni Backup database Creazione di un tablespace/datafile Media failure Restore Ovviamente avendo un backup precedente alla creazione del/dei data file al momento del recover si ha i controlfile con registrato allinterno un datafile che si perso e che nel backup non esiste. Il datafile una struttura fisica e non contenuta

nei redo log, le informazioni in esso memorizzate si. Per evitare che la recover non vada a buon fine necessario portarsi in uno stato di mount e eseguire il comando alter database create datafile filename e dopo iniziare il recovery. Lo stesso vale quando a causa della perdita di un disco la restore non pu essere eseguita nello stesso posto, tutti i datafile interessati devono essere rinominati perch rispecchino i nuovi path. La sequenza in questo caso Restore su un disco differente Alter database mount Alter database rename file old_filename to new_filename Recover database