Fractured Block

lunedì 14 maggio 2012 alle 14:25 | Pubblicato su Backup and Recovery | Lascia un commento

Sono passati quasi quattro anni da quando ho scritto questo post e questo post sulla corruzione dei blocchi in Oracle, da allora non mi sono capitati molti di questi casi (per fortuna) ma stamattina ricontrollando l’esito del backup su un database di test, versione 10.1.0.5, ho trovato il seguente e poco simpatico messaggio:

RMAN-03009: failure of backup command on d1 channel at 05/13/2012 09:26:14
ORA-19566: exceeded limit of 0 corrupt blocks for file /opt/oracle/oradata/TEST/sysaux01.dbf

poteva andare peggio, poteva essere uno dei file contenente dati dell’applicazione, pur essendo un ambiente di test sarebbe stata una discreta scocciatura, perché in realtà essendo appunto un database di test era un po’ che non controllavo il backup e oggi lo stavo controllando perché avevo trovato venerdì scorso un problema sullo script e il backup non veniva fatto da chissà quanto tempo…

Era un po’ che non gestivo un problema simile e quindi mi ci è voluto un attimo per fare mente locale, poi sono andato a controllare i log ed ho trovato questo messaggio:

Sun May 13 09:22:27 2012
Hex dump of (file 3, block 61228) in trace file /opt/oracle/admin/TEST/udump/test_ora_722.trc
Corrupt block relative dba: 0x00c0ef2c (file 3, block 61228)
Fractured block found during backing up datafile
Data in bad block:
type: 6 format: 2 rdba: 0x00c0ef2c
last change scn: 0x0000.02b00c3e seq: 0x2 flg: 0x04
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x00000001
check value in block header: 0xf844
computed block checksum: 0x54a3
Reread of blocknum=61228, file=/opt/oracle/oradata/TEST/sysaux01.dbf. found same corrupt data
Reread of blocknum=61228, file=/opt/oracle/oradata/TEST/sysaux01.dbf. found same corrupt data
Reread of blocknum=61228, file=/opt/oracle/oradata/TEST/sysaux01.dbf. found same corrupt data
Reread of blocknum=61228, file=/opt/oracle/oradata/TEST/sysaux01.dbf. found same corrupt data
Reread of blocknum=61228, file=/opt/oracle/oradata/TEST/sysaux01.dbf. found same corrupt data

Per capire la reale estensione del problema ho provato ad usare l’utility dbverify che però non mi ha dato più informazioni se non il fatto che a quanto pare l’unico blocco corrotto pareva essere il 61228. Ho provato con il comando RMAN BACKUP VALIDATE e interrogando la vista V$DATABASE_BLOCK_CORRUPTION ho avuto conferma che il blocco corrotto era una solo.


SYS@TEST AS SYSDBA> select * from v$database_block_corruption;

FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
---------- ---------- ---------- ------------------ ---------
 3 61228 1 0 FRACTURED

Ho provato allora da che oggetto del database fosse occupato tale blocco e con una certa sorpresa ho scoperto che quel blocco non era attualmente occupato da alcun oggetto. Ho provato con il comando BLOCKRECOVER di RMAN essendo un db enterprise edition ma non avendo a disposizione un backup è stato un tentativo alquanto inutile. Mi sono dovuto ripassare i miei appunti, verificando che le procedure che mi ricordavo si applicavano a blocchi utilizzati, da tabelle o indici, altrimenti ad esempio anche il package DBMS_REPAIR non è di alcuna utilità. Poi facendo una piccola ricerca sul supporto Oracle (MOS) sono capitato sulla nota .4574221 e ho provato come suggerito a fare un “RESIZE” del datafile interessato. Ho poi riprovata a lanciare sia il comando RMAN BACKUP VALIDATE che l’utility dbverify constatando di aver risolto il problema. In realtà a posteriori ho qualche dubbio, oracle mi permette di “restringere” un datafile solo se in coda di sono blocchi mai utilizzati, non appena un blocco viene utilizzato, anche se successivamente rilasciato (ad esempio droppando una tabella) il blocco risulta utilizzato e non riuscirò a “restringere” il file oltre quel blocco, quindi se l’operazione di restringimento ha risolto il problema mi vien da pensare che il blocco fosse in quell’area del file contenente blocchi ancora mai utilizzati…in effetti poi ho verificato un’altra cosa su questo database il parametro RMAN BACKUP OPTIMIZATION è OFF.

Lascia un commento »

RSS feed for comments on this post. TrackBack URI

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

Crea un sito o un blog gratuitamente presso WordPress.com.
Entries e commenti feeds.

%d blogger cliccano Mi Piace per questo: