Backup&Recovery

5/7/2018 Backup&Recovery - slidepdf.com

http://slidepdf.com/reader/full/backuprecovery 1/17

BACKUP & RECOVERY

14



INDICE

Definizioni e concetti di recovery interni 1

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 3

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

Tecniche di backup 6 Backup a freddo (offline) 7 Backup a caldo (Online) 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 12 Metodo di recovery incompleto 13

Recover until time 13 Recover until change 13 Recover until cancel 13

Creazione di controlfile e datafile 14



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, alverificarsi 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ò cheavviene 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 chead 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 logconsiderati 2 redo log successivi, il valore di low SCN del secondo redo log è pari al valore di High SCN del primoincrementato 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 vienemesso 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 dihang).

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 deiredo 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 (vedicreazione 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 questothread), 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 presentinei control files relativamente al datafile in questione. In aggiunta vi è l’informazione relativa allo stato di backup del datafile (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 incache 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 highSCN 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 correnteecc.) 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 ilcrash 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 lostop 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 essoha un valore pari ad infinito. Nel caso che questi non sia aggiornato ad un valore diverso da infinito, l’istanza Oraclecontrolla il valore dello start SCN (deve essere 0). Se lo start SCN contiene un valore diverso da 0, allora è chiaro che sitratta 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 inquestione, mentre lo stop SCN viene posto al valore raggiunto dall’ultima transazione confermata(COMMIT), ad ognicheckpoint, 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 apertodopo 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. Unicadifferenza è 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 abbandonarela 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 datiinconsistenti 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, cancellazioneaccidentale 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 filesenza 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 tuttoidentici 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 dinecessità di recover. Non sempre la tecnica che garantisce la perfetta ricostruzione del database è quella migliore, potrebberivelarsi 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 delleesigenze 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 shutdownnormal/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 completamentodell’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 ildatabase 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 nonviene archiviato. Se LGWR non può scrivere le entries all’interno dei redo, Oracle non permette nessun’altra operazione suldb 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 portain 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 logsenza 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 facilmenteriproducibili 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 restoremolto 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 datafilecorrotti, 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 è inarchivelog. 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’unicocongelamento riguarda la header dei relativi datafile, che mantengono l’ultimo numero di SCN che avevano prima delcongelamento, 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 copiadello 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 dallatransazione, 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 itablespace contemporaneamente.



Tecniche di Recovery




Tutti i metodi descritti di seguito trattano casi di media failure, il crash recovery si è visto che è un’operazione che esuladall’intervento esplicito del DBA. Il media failure prevede sempre l’applicazione di almeno un elemento (i controlfile, undatafile) 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ù bassotra tutti.Da notare che il Checkpoint Counter viene aggiornato per quei datafiles che si trovano in begin backup da parte del loroTablespace, 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 degliarchive dei redo log. Un database in noarchive log, ad esempio, non potrà mai essere recoverato fino al punto di failure, masolamente al punto in cui è stato eseguito il backup ( point in time recovery). Allo stesso modo, un database in archivelog delquale 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 seapplicare 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 dannoche 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 essereriapplicati). 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) sututti 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 accettatosolamente 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 altermine 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 disponibilealle sue necessità. Per di più Oracle, se messo nelle condizione per farlo (archive nel path specificato), è in grado dieffettuare da solo tutte le operazioni fino al termine della fase di roll farward.




Gli svantaggi derivano dalla indisponibilità del database all’utenza che in alcuni casi potrebbe portare ad un non rispettodelle 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 leinformazioni 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. Sivedrà 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 essorendendo disponibile all’utenza il resto del database. Essendo il tablespace un unità logica essa è solamente visibile in statodi 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 raggiungibiledall’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à diisolare 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 unarecovery 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 questatecnica. Nel caso il datafile che necessita di recover sia solo uno o siano pochi e di tablespace differenti può tornare utile recoveraresolo 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 chesono 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 deltablespace 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.


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.


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 deidatafile. 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 ilmomento 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 diverseopzioni 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 deldatabase. Come e perché ricreare i redo log è un argomento che esula dalla teoria del backup e recovery. Come ricreare uncontrolfile 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 aspiacevoli conseguenze e a recover ben più complesse. Per ovviare alla facilità con cui si commettono errori è possibileottenere 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_DESTnell’init.oraSe il controlfile viene ricreato specificando la parola chiave NORESETLOGS il suo SCN viene allineato con quello attualedel database (contenuto nei redo log) e non è necessario aprire successivamente il database tramite un resetlogs, se inveceviene 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 conregistrato 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 inuno 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 datafileinteressati 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

Documents

Backup&Recovery