ODU (Oracle Database Unloader) e' un'utility che accede direttamente ai datafile Oracle e consente di recuperare i dati anche nel caso in cui la base dati sia irrimediabilmente corrotta. ODU e' un'alternativa al programma DUL utilizzato direttamente da Oracle su problematiche analoghe.
Non bisognerebbe mai arrivare in una condizione in cui e' necessario l'utilizzo di ODU.
E' assolutamente necessario utilizzare gli strumenti Oracle per effettuare
backup sia fisici che logici e controllarne la corretta esecuzione.
Quando una base dati Oracle non riesce a ripartire vi sono diverse
impostazioni, documentate o fornite dal supporto Oracle, per avviare
comunque la base dati e quindi accedere ai dati.
Se tutte le alternative sono fallite allora siete messi davvero molto male...
il rischio di aver perso irrimediabilmente tutti i dati e' molto elevato.
Serve un miracolo, o quasi! L'utilizzo di ODU ha un costo di licenza significativo e puo' essere lanciato su una sola base dati per un periodo di tempo limitato (eg. 30 giorni) [NdE Anche gli angeli dei database mangiano fagioli].
ODU e' un programma in C disponibile come compilato per le principali piattagorme.
Fondamentalmente ODU opera direttamente su datafile
di Oracle analizzando la struttura interna dei blocchi
di dati e del data dictionary.
Bastano poche informazioni per recuperare una base dati con ODU.
I parametri interni di configurazione della base dati
(dimensione del blocco dati, versione di database, ...) vanno
impostati in un file di configurazione.
E' inoltre necessario ricavare l'elenco dei datafile da recuperare.
Oltre a questo ogni ulteriore informazione e' utile.
Ad esempio: la struttura della base dati, versioni di dettaglio e patch,
quali sono gli utenti, la dimensione delle tabelle,
l'utilizzo di funzionalita' particolari quali LOB, TDE, partitioning, UDT, ...
L'attivita' di recupero dipende dal tipo di corruzione presente.
Se il ODU riesce a recuperare il tablespace di SYSTEM allora puo' accedere
al data dictionary ed a recuperare in modo piu' semplice le strutture ed i dati.
ODU puo' anche recuperare un singolo datafile indovinando i datatype
delle colonne e recuperando cosi' comunque alcuni dati.
Nei casi piu' gravi (eg. rottura fisica di un disco) e' opportuno incrociare i dati ottenuti
dall'estrazione dei blocchi di dati e degli indici per quantificare il numero di righe
non piu' recuperabili.
ODU opera anche su ASM sia nel caso in cui l'ASM e' attivo sia
nel caso in cui non si riesca riattivare l'ASM.
In questo ultimo caso e' necessario complilare un file di configurazioen specifico
con gli estremi dei device interessati.
Vediamo ora la pratica!
I passi sono:
installazione,
configurazione,
odu.
Per installare la versione trial basta scaricarla dal sito oracleODU
e decomprimerla su una directory a piacere.
ODU e' disponibile in versione trial.
La versione trial e' utilizzabile senza costi aggiuntivi ma ha un paio di limitazioni:
non opera su ASM e, per ogni tabella, salva solo il primo blocco di dati.
Per provare se ODU e' in grado di recuperare la base dati corrotta si puo' utilizzare
la versione di prova.
Per utilizzare ODU e' necessario un minimo di configurazione.
Vanno determinati i datafile e configurato il file di parametri della base dati.
Determinare i datafile e' facile (la query funziona anche con un DB in stato di mount):
In pratica e' necessario compilare un file control.txt che contenga i nomi di tutti i datafile come in questo esempio (non serve compilare tutto):
#ts fno rfno filename block_size is_big_file header_offset blocks 0 0 0 /usr/lib/oracle/xe/oradata/XE/system.dbf 0 0 0 /usr/lib/oracle/xe/oradata/XE/undo.dbf 0 0 0 /usr/lib/oracle/xe/oradata/XE/sysaux.dbf 0 0 0 /usr/lib/oracle/xe/oradata/XE/users.dbf 0 0 0 /oracle/oradata/DATA1.DBF 0 0 0 /oracle/oradata/DATA2.DBF 0 0 0 /oracle/oradata/IDX1.DBF
Il secondo file da configurare e' config.txt che viene gia' fornito con ODU e su cui sono necessarie poche variazioni per adattarlo all'ambiente di esecuzione:
byte_order little block_size 8192 block_buffers 1024 db_timezone -7 client_timezone 8 asmfile_extract_path /usr/local/amm/odu/asmfile data_path data lob_path /usr/local/amm/odu/data/lob charset_name US7ASII ncharset_name AL16UTF16 output_format text lob_storage infile clob_byte_order big trace_level 1 delimiter | unload_deleted no file_header_offset 0 is_tru64 no record_row_addr no convert_clob_charset yes use_scanned_lob yes trim_scanned_blob yes lob_switch_dir_rows 20000 db_block_checksum yes db_block_checking yes rdba_file_bits 10 compatible 10Il parametro COMPATIBLE e' la versione di Oracle: questo e' il parametro principale. I parametri DATA_PATH, LOB_PATH e ASM_EXTRACT_PATH vanno fatti puntare a directory esistenti con gli opportuni diritti per l'utenza che esegue ODU. Se sono noti e' opportuno impostare CHARSET_NAME ed NCHARSET_NAME. Il parametro OUTPUT_FORMAT puo' essere impostato a DMP per ottenere i dati in formato EXP/IMP [NdE v.8]. Gli altri parametri hanno valori di default adatti alla maggioranza delle condizioni.
Ora che tutte le impostazioni sono terminate e' possibile utilizzare interattivamente
il ODU per estrarre i dati dalla base dati corrotta.
Il primo passo e' accedere al data dictionary.
Se il tablespace SYSTEM viene acceduto da ODU
e' possibile scaricarlo su file.
I file generati sono: user.odu obj.odu tab.odu lob.odu lobfrag.odu ind.odu col.odu
Quando il data dictionary e' riconosciuto le operazioni successive con ODU sono molto facili:
I dati vengono estratti in formato SQL*Loader.
Vengono generati automaticamente per ogni tabella recuperata un file .sql con la DDL
di creazione, un file .ctl per il caricamento dei dati da SQL*Loader ed un file .txt con
i dati. Il nome dei file e' OWNER_TABLE.sql.
Nel caso di presenza di LOB vengono utilizzati file esterni lobXXX.dat
posti nella directory indicata dal file config.txt e
caricati in automatico da SQL*Loader.
Ora che abbiamo fatto una prova e visto se e come funziona possiamo
recuperare la base dati.
Per fare questo la versione trial, utilizzata fino ad ora,
non e' sufficiente poiche' scarica su file
solo la prima parte dei dati (tipicamente un solo blocco).
E' necessario richiedere una licenza (a pagamento!) ed utilizzare
la versione completa. Ma questo... lo vediamo nel prossimo capitolo!
I passi sono: acquisizione licenza, scaricamento dati, caricamento dati.
La versione enterprise di ODU si installata come la versione trial. Pero' per funzionare e' necessaria una licenza. Per richiedere la licenza bisogna lanciare il comando save control:
Nel caso in cui sia utilizzato l'ASM e' necessario compilare il file asmdisk.txt per indicare ad ODU i device assegnati alla base dati. Una volta configurato correttamente tutti i parametri e' possibile recuperare gli oggetti come gia' descritto in precedenza.
Se il tablespace SYSTEM non e' recuperabile ODU non puo' riconoscere gli schema ed i nomi delle tabelle e delle colonne. In questo caso i passi saranno
-- --Generated by ODU,for table "DEMO"."MYTEST" -- OPTIONS(BINDSIZE=8388608,READSIZE=8388608,ERRORS=-1,ROWS=50000) LOAD DATA INFILE 'DEMO_MYTEST.txt' "STR X'0a'" APPEND INTO TABLE "PIEMME"."VBDATA_DATI" FIELDS TERMINATED BY X'7c' TRAILING NULLCOLS ( "AKEY" , "PROGRESSIVO" , "DATA_OPERAZIONE" DATE "yyyy-mm-dd hh24:mi:ss", "ORA_OPERAZIONE" CHAR(5), "NOMEFILE" CHAR(200), LOBFN_00010 FILLER CHAR(64), "FILE_DATI" LOBFILE(LOBFN_00010) TERMINATED BY EOF, LOBFN_00011 FILLER CHAR(64), "NOTE" LOBFILE(LOBFN_00011) TERMINATED BY EOF, "DATA_LAVORAZIONE" DATE "yyyy-mm-dd hh24:mi:ss" )
Se tutto e' stato configurato correttamente l'utilizzo di ODU in modalita' interattiva non e' complesso:
DUL e' il programma di Oracle le cui funzionalita' sono state replicate da ODU. DUL non viene distribuito ed e' utilizzato soltanto dal personale Oracle in situazioni di emergenza.
Un documento introduttivo alle problematiche di recupero dei dati su Oracle e' Attivita' di recovery sull'RDBMS Oracle.
Altri documenti di questo tipo su questa pagina
Titolo: ODU
Livello: Hack
Data:
14 Febbraio 2014
Versione: 1.0.0 - 14 Febbraio 2014
Autore: mail [AT] meo.bogliolo.name, Riccardo Gabriele