ODU

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].

Architettura e funzionamento

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.

Una prima prova...

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):

set trimspool on pagesize 0 linesize 256 feedback off column name format a200 spool control.txt select ts#, file#, rfile#, name from v$datafile; spool off

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 10
Il 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.

./odu ODU> unload dic

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:

./odu ODU> unload table SCOTT.EMP ODU> unload user PM

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!

Facciamo sul serio!

I passi sono: acquisizione licenza, scaricamento dati, caricamento dati.

License

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:

./odu ODU> save control
Viene generato il file oductl.txt che e' necessario inviare ad OracleODU per ottenere la licenza valida per il database utilizzato. OracleODU restituira' il file oductl.dat che contiene la licenza e va posto nella stessa directory in cui e' stato installato ODU.

Download

Il comando principale per ottenere su file i dati contenuti nella base dati corrotta e' gia' stato riportato in precedenza: UNLOAD. Vi sono pero' casi piu' complessi che richiedono passi ulteriori prima di procedere al download dei dati.

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


Per ogni tabella recuperata si generano tre file: 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. Ecco un esempio completo di un file .ctl: 
--
--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"
)

Upload

Procedere al caricamento dei dati ottenuti con ODU e' un'operazione di ordinaria amministrazione che naturalmente va eseguita su una base dati correttamente funzionante.
Il comando SQL*Loader e' sqlldr e lanciato senza parametri riporta le opzioni. Le piu' comunemente utilizzate sono control=OWNER_TABLE.ctl e parfile. Naturalmente bisogna disporre di spazio sufficiente per ricaricare i dati.

Se tutto e' stato configurato correttamente l'utilizzo di ODU in modalita' interattiva non e' complesso:

./odu ODU> UNLOAD TABLE Owner.Table; ODU> UNLOAD USER Owner;

Note

Glider 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 Hack

Titolo: ODU
Livello: Hack (5/5)
Data: 14 Febbraio 2014
Versione: 1.0.0 - 14 Febbraio 2014
Autore: mail [AT] meo.bogliolo.name, Riccardo Gabriele