Backup&Recovery

Published on May 2016 | Categories: Documents | Downloads: 60 | Comments: 0 | Views: 470
of 17
Download PDF   Embed   Report

Uploaded from Google Docs

Comments

Content

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

1

3

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

9

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
All’interno dei redo log vengono registrati i cambiamenti che avvengono all’intero database. Tra questi bisogna includere anche i cambiamenti che avvengono all’interno 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. L’insieme di vettori generati da ogni singola operazione atomica che viene effettuata sul database prende il nome di redo record. E’ garantita l’atomicità di questa entità all’interno 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 un’unità. Il suo valore viene riportato in tutte le strutture della base dati (control file, data file e redo log) dai processi dell’istanza. Vi sono valori di SCN che assumono un significato particolare: • Low SCN e High SCN sono rispettivamente il primo valore e l’ultimo che vengono registrati all’interno 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 nell’header dei datafile nel momento in cui il tablespace relativo viene messo in stato di offline.

Redo log switching
Si tratta dell’operazione 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 l’informazione è 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
L’evento di checkpoint forza il flush dei buffer all’interno 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 l’istruzione 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 dall’ultimo 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 l’attuale 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 l’header del datafile stesso, nel quale sono contenute le stesse informazioni presenti nei control files relativamente al datafile in questione. In aggiunta vi è l’informazione 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 un’indice, 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 è l’header, 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 all’utente.

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 l’immagine precedente del buffer, la quale è contenuta nei log file, nel secondo di ricostruire l’immagine ultima disponibile del blocco, ed anche questa informazione è contenuta nei log file. Non vi è mai la necessità di scorrere più dell’ultimo 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 l’istanza del database muore (caduta della macchina su cui è attiva, mancanza di corrente ecc.) il database allo startup successivo dovrà effettuare un crash recovery. L’azione 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. L’azione di crash è riproducibile dal DBA tramite il comando shutdown abort, il quale ha l’effetto di non aggiornare lo stop SCN con il valore corrente e, ancora più importante, di non effettuare il Checkpoint. Nel momento in cui l’istanza 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, l’istanza 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 dall’ultima 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 l’istanza 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 l’aggiornamento dei blocchi dei datafiles. Quest’ultima 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 l’intervento 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: L’utilizzo 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 l’applicazione 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 dell’operazione (anche ore). Il backup a freddo ha due alternative, l’utilizzo 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 all’interno dei redo, Oracle non permette nessun’altra operazione sul db che entra quindi in uno stato di hang. L’archiviazione 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 l’archiving manuale di redo (alter system archivelog all) o ripulendo (sconsigliatissimo) i log senza archiviarli (alter system clear unarchived log group) Più semplice risulta abilitare l’archiviazione automatica tramite il comando alter database archivelog start o specificando all’interno dell’init.ora il parametro ARCHIVE_LOG_START = TRUE. I file di archive verranno prodotti all’interno 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 dell’archiviazione automatica dei redo log si chiama ARCH.

In noarchivelog
Il risultato dell’operare con questo metodo è l’ottenimento di una fotografia del database in un determinato istante, ovviamente a database chiuso, cioè dopo shutdown dell’istanza. Un eventuale recovery utilizzando questa tipo di backup prevede la perdita di tutti i dati immessi nell’istanza 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 all’archiving. Nei Datawarehouse spesso si usa caricare i dati con SQL*Loader ma con l’opzione 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, l’importante è 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 all’utenza, 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, l’unico congelamento riguarda la header dei relativi datafile, che mantengono l’ultimo numero di SCN che avevano prima del congelamento, anche in presenza di checkpoint durante la fase di copia. Il datafile che viene copiato con l’utility è 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 l’accortezza di considerarlo al momento del SCN congelato, permette che l’eventuale 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 è un’operazione che esula dall’intervento esplicito del DBA. Il media failure prevede sempre l’applicazione 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 all’ultimo 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 l’intero 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 nell’applicazione 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 all’istante 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 all’operatore 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 dell’operazione 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 nell’operare 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 all’utenza 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, l’unica 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 l’opzione 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 l’unica 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 all’utenza il resto del database. Essendo il tablespace un unità logica essa è solamente visibile in stato di open del database, pertanto aprire il database è anche l’unico modo per eseguire una recover di questo tipo. Ovviamente eseguire la recover del tablespace è possibile solo se il tablespace non è potenzialmente raggiungibile dall’utenza, 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 all’utilizzo 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 l’impossibilità di recoverare il tablespace system o un tablespace con rollback segment online, non essendo possibile metterli in uno stato di offline, l’impossibilità di operare a database chiuso, e l’impossibilità 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 all’interno 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 nell’impossibilità 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 dell’operazione 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 all’ultimo 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 all’ultimo 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’ un’opzione 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é l’operatore possa scegliere tra le diverse opzioni disponibili • Continuare con il prossimo archive suggerito INVIO • Cambiare archive full name dell’archive + INVIO • Continuare automaticamente con la sequenza di default AUTO + INVIO • Terminare il recover CANCEL + INVIO • La recover until cancel prevede l’uso 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 l’opportunità 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 all’interno del path specificato dal parametro USER_DUMP_DEST nell’init.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 all’open 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 all’interno 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

Sponsor Documents

Recommended

No recommend documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close