La palestra del DBA

giovedì 13 settembre 2007 alle 13:43 | Pubblicato su Backup and Recovery | 2 commenti

Oggi mi sono trovato per l’ennesima volta alle prese con il database di un cliente presso cui regolarmente i server vanno giu a causa di black-out elettrici. Dove siano i gruppi di continuità è un mistero, sta di fatto che sistematicamente quanto il server va giu in questo modo il database Oracle risulta danneggiato.

Purtroppo a causa della connessione difficoltosa e della solita concitazione ho perso parte dell’output durante le operazioni di ripristino, quindi per quanto riguarda la parte iniziale riporterò a memoria.

Per quanto riguarda il sistema si tratta di una delle nostre più diffuse configurazioni, 9i (9.2.0.6) Standard Edition su Windows. Il primo errore che il database dava in fase di mount segnalava che i controlfile 1 e 2 erano disallineati (ORA-00214), ci sono tre copie del control file, come proposto per defaulta da DBCA alla creazione del databasa. Questo errore è già capitato altre volte, in alcuni casi è bastato prendere la terza copia, e usare quella come base per ricreare le tre copie. In questo caso ero in grado di fare il mount ma durante l’open ricevevo l’errore:

“ORA-00338: log 2 del thread 1 è più recente del control file”

Allora ho provato con un’altra copia del controlfile, ma usando quello che nel primo messaggio di errore data un numero di sequenza più alto ottenevo:

“ORA-01122: il file di database 1 non ha superato la verifica
ORA-01110: il file di dati 1: ‘…system01.dbf’
ORA-01207: il file è più recente del control file – control file vecchio

Ora, come detto ho perso il log di tutte le mie operazioni quindi non ricordo bene, credo di aver provato scioccamente a fare un “alter database open resetlogs” dopo aver ripristinato la terza copia del controlfile (premetto che prima di iniziare tutte queste manovre ho avuto la possibilità di fare una copia di tutti i file del database come si presentavano prima dei miei interventi, in modo da essere al riparo dalle mie scicchezze). Qui la mia memoria si perde, credo di aver provato un recupero incompleto per poter effettuare l’open resetlogs, poi ho addirittura provato a eliminare gli online redo logs: tutte operazioni fallite. Alla fine ho deciso di non perdere ulteriormente tempo e di ripristinare il backup che stava sul disco, qui ho appurato che nessuna copia dei control file funzionava (mi dava un errore che ora non ricordo). Quindi procedura di recovery completa, partendo dai control file.

Qui è avvenuto il fatto nuovo, il restore di un datafile falliva:


RMAN-03002: failure of restore command at …
ORA-19612: file di dati 6 non ripristinato a causa di missing or corrupt data

Fortunatamente si trattava di un datafile parte di una tablespace che conteneva solo indici, alché ho pensato: “bene, butto via la tablespace, apro il database ricreo la tablespace e ricreo gli indici”.

E’ una procedura che non avevo mai avuto occasione di provare e con RMAN non è banale. Provando a fare il drop della tablespace coinvolta con il database in mount Oracle si lamenta che il database deve essere aperto, per aprire il database occorre fare il recovery, se si prova afare il recovery tramite RMAN, RMAN si lamenta che bisogna ripristinare il file mancante:


RMAN-03002: failure of recover command at …
RMAN-06094: datafile 6 must be restored

quindi mi sono trovato nella classica situazione del cane che si morde la coda. Un’altra nota: avendo ripristinato anche i controlfile dal backup l’unico tipo di recovery accettato da RMAN è “RECOVERY DATABASE”.

Ho dovuto arrangiarmi a tentativi con le procedure di recovery da SQL*Plus.

Ho provato a mettere offline il file ma RMAN si lamentava comunque.

A questo punto ho messo offline tutti i datafile della tablespace degli indici:


SQL> alter database datafile x offlien;
SQL>alter database recover database using backup controlfile;
alter database recover database using backup controlfile
*
ERRORE alla riga 1:
ORA-00289: suggerimento : D:\ORACLE\ORADATA ….ARCH07139.001
ORA-00280: MODIFICA xxx per thread 1 è nelle sequenza #7139

A questo punto:


SQL> alter database recover logfile ‘d:\oracle\oradata …arc07139
….

fino alla fine, quindi:


SQL> alter database recover cancel;

Così non ha funzionato ancora, cercando di aprire il database:

SQL> alter database open resetlogs;
alter database open resetlogs
*
ERRORE alla riga 1;
ORA-01113: necessario recupero di dischi per il file ‘1’
ORA-01110: file di dati 1: ‘D:\…. SYSTEM01.DBF’

facendo:


SQL> recover database recover database until cancel using backup controlfile;

….

SQL> alter database recover cancel;

A questo punto ho dovuto rifare:

alter database datafile x offline drop;

per tutti i datafile della tablespace degli indici, finalmente l’open resetlogs ha funzionato.

Conclusioni

Si tende spesso a sottovalutare la complessità delle procedure di backup e recovery. Quando non ci sono problemi e durante i test che è possibile fare le cose sono tutto sommato semplici (non banali). Uno dei motivi per cui mi rifiuto di perdere tempo con le procedure guidata dall’Enterprise Manager (o Database Control) avendo già una discreta dimestichezza con l’uso diretto da linea di comando di RMAN è che secondo me è difficile gestire situazioni particolari. Sospetto che in una situazione come quella sopra da un’interfaccia grafica non sarebbe stato facile risolvere il problema, mi immagino già il laconico messaggio di errore che può comparire quando RMAN si lamenta che non riesce a ripristinare un datafile. Si tratta di una delle mille situazioni che possono capitare ma che è impossibile prevedere a priori.

Questa esperienza ha evidenziato delle lacune che ancora ho io e probabilmente delle lacune presenti su RMAN (almeno versione 9.2). Non appena avrò a disposizione la macchina di test voglio proprio cercare di simulare la situazione in cui mi sono trovato e imparare la procedura corretta da seguire per il ripristino.

P.S. (12/10/2007)

E’ evidente dalla mia narrazione che la mia inesperienza su quel tipo di operazione, cioè il ripristino di un database senza un datafile, mi ha portato a fare un po’ di confusione. Tutto sommato spero non mi capiti più, infatti in questo caso è andata bene che il file perso era un file di indici e non di dati, se si fosse trattato di dati avrei dovuto prendere un backup precedente e utilizzare tutti gli archive log. In ogni modo sono riuscito a fare un test e ragionando con calma e cercando sul metalink ho trovato la semplice soluzione.

Le operazioni da fare per ripristinare un database senza un datafile e facendo un recovery incompleto (se si sono persi gli online redo tocca farlo incompleto) sono:

    1. ripristino controlfile
    2. mount del database
    3. metto offline il datafile con non voglio o non posso ripristinare: :”alter database datafile 5 offline; “
    4. faccio il recover del database: recover database using backup controlfile until cancel;
    5. Qui viene il bello, se cerco di aprire il database:
SQL> alter database open resetlogs;alter database open resetlogs*

ERROR at line 1:

ORA-01245: offline file 5 will be lost if RESETLOGS is done

ORA-01110: data file 5: '/opt/oracle/oradata/testdb/indx01.dbf'

Qui mi ha aiutato una vecchia discussione trovata su un forum del metalink, in sostanza occorre fare:

<pre>alter database datafile '/opt/oracle/oradata/testdb/indx01.dbf' offline drop;
  1. a questo punto è possibile aprire il database:
    SQL> alter database open resetlogs;Database altered.

2 commenti »

RSS feed for comments on this post. TrackBack URI

  1. Ho letto la tua analisi (di qualche anno fa) e sicuramente sei piu ferrato di me.
    Volevo chiederti cosa avresti fatto nella situazione (sicuramente piu semplice) che è capitata a me.
    Non sono sicura di aver seguito la procedura ottimale, infatti non sono riuscita a recuperare il db.
    Il server windows in questione (non di produzione ma di sviluppo e test) qualche volta ha subito interruzioni di corrente.. il risultato è che qualche giorno fa il db non partiva da servizio windows. Quindi ho provato a farlo partire a mano da sqlplus.
    TI premetto che il db non è in archivelog mode.
    Quando ho provato ad aprirlo mi diceva che il controlfile era piu vecchio del datafile system. (Stessa cosa per gli altri controlfile)
    Quindi ho ricreato il controlfile con lo script ottenuto dallo statement “alter database backup control file to trace”
    Ho provato a ricreare il controlfile con l’opzione noresetlogs, ma non me lo permetteva perchè diceva che gli serviva almeno un thread attivo (ma i redolog online li avevo tutti!).
    Poi ho fatto una serie di altri tentativi, tra cui ricreare il controlfile con l’opzione resetlogs. Ovviamente non avendo il db in archivelog mode non avevo nè backup nè gli archived log file per effettuare il ripristino o un recover.

    Sarei felice di sapere se e cosa avrei potuto fare per recuperare il db in questione.

    grazie, Cinzia

    • Ciao, non mi ricordo di aver mai affrontato una simile situazione, però si potrebbe simulare. Mi verrebbe da dire che se ricrei il controlfile non c’è alternativa al RESETLOGS ma non escludo ci sia qualche eccezione ma mi chiedo come potrebbe fare a riallineare i file senza i redo. Se riesco a fare una prova e rinfrescarmi la memoria provo a fare un nuovo post.


Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

Blog su WordPress.com.
Entries e commenti feeds.

%d blogger cliccano Mi Piace per questo: