Il mistero di ORA-00333

lunedì 12 gennaio 2015 alle 12:18 | Pubblicato su 11g, Backup and Recovery, Diario | 3 commenti

Un paio di nostri database server si appoggiano a una NAS, usando iscsi, per lo spazio disco. Uno è un server linux e l’altro window, entrambi hanno dei dischi iscsi su questa Nas esterna e su questi dischi ci sono dei database di sviluppo e test interni. Ogni tanto, per svariati motivi capita che la NAS ha un mancamento, in questa situazione quello che accade sulla macchina linux è che il filesystem, quanto la NAS si riprende, viene automaticamente rimontato in modalità read-only, cosa che naturalmente non piace ad Oracle. Sulla macchina Windows il disco sembra venga rimontato normalmente, ciò nonostante Oracle non la prende comunque bene.

Questa mattina è successo di nuovo, in precedenza è andata sempre abbastanza bene, sulla macchina linux basta fermare Oracle, smontare e rimontare in modalità read-only il disco e riavviare Oracle, sulla macchina Windows basta solo riavviare Oracle, fino ad oggi tali passi erano stato sufficienti. Stamattina però le cose sono andate storte, sulla macchina Windows i due database segnalavano in fase di apertura l’errore

ORA-00333: errore lettura redo log blocco 34873 conteggio 7758

Naturalamente cambiavano i numeri di “blocco” e “conteggio”, quello su linux data un errore di disallineamento dei controlfile:

ORA-00214: control file
‘/opt/oracle/storage/recovery_area/marte112/control02.ctl’ version 1093680
inconsistent with file ‘/opt/oracle/storage/data/marte112/control01.ctl’
version 1093666

Quest’ultimo problema l’ho  affrontato copiando il file con il numero di versione più alto sopra l’altro. Fatto ciò anche qui in fase di apertura del database ho ricevuto il messaggio:

ORA-00333: redo log read error block 55748 count 8192

Ho cercato di mantenere la calma e vedere cosa si poteva fare. Per due database avevo a disposizione un backup della notte prima, quindi ero abbastanza tranquillo, per l’altro non c’è backup per motivi di spazio e perché non è così importante. Ho fatto delle ricerce sull’errore, senza capire però effettivamente la sua origine, perché parrebbe dovuto al fatto che si sia corrotto un online redolog, però facendo una ricerca su internet si trova, anche sul forum Oracle come soluzione un recovery incompleto e la successiva apertura del database con l’opzione RESETLOGS. Messa così la cosa ha senso, si ferma il recovery senza applicare il redo contenuto negli online redo, che a quanto pare sono corrotti e si riesce a far ripartire il database perdendo solo quanto contenuto negli online redolog.

Le cose però non stanno proprio così, perché quello che ho fatto io è stato di applicare anche il redo degli online redolog:

SQL> recover database until cancel;
ORA-00279: change 10685641157734 generated at 01/11/2015 01:14:20 needed for
thread 1
ORA-00289: suggestion :
/opt/oracle/storage/recovery_area/MARTE112/archivelog/2015_01_12/o1_mf_1_28964_%
u_.arc
ORA-00280: change 10685641157734 for thread 1 is in sequence #28964

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/opt/oracle/storage/data/marte112/redo02.log
Log applied.
Media recovery complete.
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open

SQL> alter database open noresetlogs;
alter database open noresetlogs
*
ERROR at line 1:
ORA-00333: redo log read error block 55748 count 8192

 

Ecco, siccome questo era uno dei database di cui avevo il backup ho deciso di fare un piccolo azzardo, pensando non fosse tanto azzardato, ho cercato di aprire il database con l’opzione NORESETLOGS, così da vedere cosa succedeva. Il punto è che il mio recovery mi sembrava completo, non incompleto, perché aveva terminato da solo, non in seguito a un mio “CANCEL”, il redo che ho indicato era l’unico che dalla vista V$LOG risultava attivo e contenente la sequenza richiesta dalla procedura di recovery (gli altri due risultavano anche archiviati), quindi in questa fase Oracle è riuscito ad aprire e leggere l’online redolog senza problemi, senza darmi ORA-00333, come mai? Io non l’ho capito.

Torniamo adesso al mio azzardo/esperimento di aprire il database con l’opzione NORESETLOGS, i miei successivi tentativi sono stati questi:

SQL>  alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01139: RESETLOGS option only valid after an incomplete database recovery

SQL> recover database until cancel;
ORA-10879: error signaled in parallel recovery slave
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: ‘/opt/oracle/storage/data/marte112/system01.dbf’

SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: ‘/opt/oracle/storage/data/marte112/system01.dbf’

 

Al che ho cominciato a preoccuparmi perché mi scocciava dover ripristinare tutto il backup. Al che ho deciso di fare un disperato tentativo, disperato perché per la verità senza cognizione di causa:

SQL>  recover database using backup controlfile until cancel;
ORA-00279: change 10685641181646 generated at 01/11/2015 03:06:33 needed for
thread 1
ORA-00289: suggestion :
/opt/oracle/storage/recovery_area/MARTE112/archivelog/2015_01_12/o1_mf_1_28964_%
u_.arc
ORA-00280: change 10685641181646 for thread 1 is in sequence #28964

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/opt/oracle/storage/data/marte112/redo02.log
Log applied.
Media recovery complete.
SQL> alter database open resetlogs;

Database altered.

 

Ho cioè deciso di provare il recovery incompleto aggiungendo l’opzione “using backup controlfile”, e mi è andata bene 🙂

Il mio controlfile era sempre lo stesso, non era stato ripristinato da un backup. Che cosa significhi veramente la clausola “using backup controlfile” non sono sicuro di averlo ancora capito bene, la migliore spiegazione che ho trovato è questa. Però mi sfugge cosa abbia fatto il mio primo tentativo si recovery… mi piacerebbe capirne di più

P.S.

naturalmente sugli altri due database è stato più semplice, è bastato usare subito  l’opzione RESETLOGS

Annunci

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.

Recovery Area Usage

mercoledì 14 dicembre 2011 alle 14:55 | Pubblicato su 11g, Backup and Recovery | 1 commento
Tag:

Da anni ormai sto rifinendo e testando degli script di backup di Oracle fatti da me pescando idee qua e la. In realtà la base di partenza fu uno script di shell passatomi da un consulente Oracle, script funzionante su Oracle 9iR2 ma probabilmente elaborato a sua volta per Oracle 8. Nel corso degli anni come dicevo ho apportato e continuo a fare modifiche e migliorie; avendo cominciato l’anno scorso a installare database versione 11gR2 ho apportato ulteriori modifiche, a parte le migliorie una in particolare è stata una modifica obbligata da una modifica portata dalla nuova release del database.

Con la versione 10g Oracle ha introdotto la cosiddetta “Recovery Area”, che io solitamente uso per gli Archive Log.  Essendo la gestione degli Archive Log una cosa importante, nel mio script di backup è inclusa una parte che controlla l’occupazione di spazio degli archive log ed eventualmente ne fa il backup o la cancellazione onde prevenire blocchi del database. Per fare tale controllo il mio script utilizza una query sulla vista V$FLASH_RECOVERY_AREA_USAGE, in particolare la query è:


select round(percent_space_used) from v$flash_recovery_area_usage where file_type='ARCHIVELOG';

Oggi scopro che tale vista non è più documentata in 11gR2, è sostituita da V$RECOVERY_AREA_USAGE, la vista con il vecchio nome però esiste ancora e infatti il mio script scritto per 10gR2 apparentemente funzionava anche su 11gR2. Dico apparentemente perché qualcuno in Oracle ha avuto la bella idea di fare un cambiamento ben più importante, cambiando la descrizione riportata nel campo FILE_TYPE per gli archive log da “ARCHIVELOG” a “ARCHIVED LOG”.  Nulla di che se non il fatto che la query utilizzata nella mia vecchia versione dello script on funzionava più, ragion per cui ho inaugurato la versione 11.2 del mio script di gestione dei backup su piattaforma linux.

Standby Database per Oracle Standard Edition

mercoledì 17 dicembre 2008 alle 17:58 | Pubblicato su Backup and Recovery, Installation and Configuration | 18 commenti
Tag: , , ,

Alcuni giorni fa ho scritto un post in cui descrivevo un’implementazione artigianale ed ingenua di una soluzione di “alta affidabilità” o “disaster recovery”. La soluzione da me implementata si basava su export/import dello schema database di interessa da una macchina all’altra.  Sono contento di aver scritto tale post, ma soprattuto sono grato ad Alessandro per avermi segnalato un link a un documento  di Niall Lichtfield (il documento sta ancora sul vecchio sito di Niall) in cui si parla di una soluzione “Data Guard” per Oracle Standard Edition.

Confesso che tempo fa gia un’altra persona mi aveva detto di aver messo in piedi una soluzione Data Guard “manuale” su Oracle database Standard Edition. Non ho mai approfondito la cosa perchè mi sembrava una cosa poco pulita (nel senso al limite della “legalità”). L’accenno al fatto che una implementazione manuale di “Data Guard” può essere fatta su Standard Edition nella presentazione di Niall mi  ha spinto a fare una ricerca approfondita. Sono partito dal listino dove in realtà non ho trovato niente.  Alla fine sono andato sulla documentazione e con mia grande soddisfazione ho trovato questo.  Quindi Oracle dichiara espressamente che l’implementazione manuale di uno Standby Database è possibile su Standard Edition. A questo punto ho deciso si fare dei test, essendo una cosa che sicuramente sul lavoro mi servirà.

Siccome sulla documentazione Oracle si da spazio solo all’implementazione “Enterprise” di “Data Guard” ho cercato su internet qualche documento ed ho trovato questo interessante articolo su http://www.databasejournal.com.

Sospesi i test con Oracle 11g ho clonato la macchina virtuale con Oracle 10gR2 che ho usato per altri test e seguito le semplici istruzioni riportate sull’articolo, ho fatto un po’ di controlli incrociati con il documento e gli script di Niall Lichtfield e la documentazione della 10gR2. Ad esempio nell’articolo c’è l’indicazione di eseguire il comando

ALTER SYSTEM ARCHIVE LOG START;

cosa che con 10g non è più necessaria e deprecata (il comando non da errore ma non fa nulla, rif)

Una cosa che mi capita è che il “recover” dell’istanza di standby da sempre errore:

SQL> alter database recover automatic standby database until cancel;
alter database recover automatic standby database until cancel
*
ERROR at line 1:
ORA-00279: change 16718544 generated at 12/17/2008 12:00:44 needed for thread 1
ORA-00289: suggestion : /opt/oracle/oradata/inarchivelogs/1_619_645973149.dbf
ORA-00280: change 16718544 for thread 1 is in sequence #619
ORA-00278: log file ‘/opt/oracle/oradata/inarchivelogs/1_619_645973149.dbf’ no
longer needed for this recovery
ORA-00308: cannot open archived log
‘/opt/oracle/oradata/inarchivelogs/1_619_645973149.dbf’
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

Il numero di sequenza che cerca è quello del log corrente sull’istanza primaria. Credo che sia normale, perchè per il resto funziona tutto, infatti, prima di questo recorery (e dopo aver creato l’istanza di standby, tra l’altro con un backup a freddo copiando semplicemente tutti i datafile) ho lanciato sull’istanza principale

SQL> @?/rdbms/admin/utlsampl.sql

Che crea lo schema SCOTT e dopo il recovery sulla istanza di standby:

SQL> alter database recover cancel;

Database altered.

SQL> alter database open read only
2  /

Database altered.

SQL> conn scott/tiger
Connected.
SQL> select count(*) from user_tables;

COUNT(*)
———-
4

Infine ho fatto una prova di “switch-over”, infatti il segreto di ogni buona politica di backup è un test di ripristino. Nell’articolo di Databasejournal.com la fa facile, dicendo che basta applicare tutto il redo mancante e poi aprire in modalità read write. Io non ho trovato subito  un modo diretto per aprire in modalità read write il datbase. Seguendo le indicazioni del manuale non funziona  (credo dipenda sempre dal fatto che nel manuale è descritta solo la gestione automatica):

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

SWITCHOVER_STATUS
——————–
NOT ALLOWED

Ci sono riuscito ripristinando i controlfile di partenza, facendo un recovery incompleto e aprendo con l’opzione RESETLOGS (gli online redolog non li avevo copiati).

Tutti gli altri tentativi di aprire il database in modalità read write con i controlfile usati per lo standby mi davano:

ORA-01666: control file is for a standby database

Cercando meglio ho trovato la soluzione, qui.

SQL> alter database ACTIVATE STANDBY DATABASE;

Database altered.

SQL> alter database open;

Database altered.

SQL> conn scott/tiger
Connected.
SQL> create table pluto (a number);

Table created.

Qui, dice che è meglio non usare ALTER DATABASE ACTIVATE STANDBY DATABASE perché si rischia di perdere dati, ma sospetto che nella gestione manuale non vi siano molte alternative.

L’unico difetto di questa tecnica di “alta affidabilità” o “disaster recovery” come la si vuole classificare, è secondo me il fatto che la seconda istanza non può essere usata, se non in modalità read-only.  Non ho indagato a fondo, ma immagino che sia possibile usare solo physical standby database e non logical standby database con la Standard Edition.

I BACKUP SET di RMAN

giovedì 30 ottobre 2008 alle 30:46 | Pubblicato su Backup and Recovery | Lascia un commento
Tag: , , , , ,

In questi giorni ho un po’ approfondito la mia conoscenza di RMAN. I dettagli di questo potente strumento di backup fornito da Oracle sono veramente tanti e infatti per anni ho utilizzato una consolidata procedura di backup senza conoscere alcuni dettagli di cui in questo post parlerò e soprattuto senza avere problemi.

RMAN è ingrado di produrre due tipi di backup, le copie e i backup set. Le copie sono copie identiche dei datafile o degli archivelog o del control file che non sono ottimizzate. Le copie hanno due vantaggi, uno è che possono essere ripristinate anche senza RMAN (vantaggio da poco direi) e il loro ripristino è più efficente perché consiste solo in una copia. Al contrario i backup set sono in formato proprietario, quindi leggibili e ripristinabili solo con RMAN, essi però sono ottimizzati nel senso che Oracle non include nei backup set quei blocchi dei datafile mai utilizzati; quindi un backup set di un database con file grandi ma con pochi dati (perchè nuovo, in genere) può risultare molto piccolo. Questo vantaggio probabilmente si paga un pochino con una minor efficenza nel ripristino, infatti oracle deve “ricostruire” i datafile.

Vi sono altre due differenze fra le copie immagine e i backup set: i backup set possono essere creati sia su disco che su tape e da Oracle 10g (solo Enterprise Edition) possono essere compressi; le copie possono essere fatte solo su disco e la loro compressione non è supportata da RMAN.

Un backup set, stando al manuale, è la più piccola unità di un backup, nel senso che se la crezione di un backup set fallisce tale backup set non è valido. Una procedura di backup può creare più backup set ed ogni backup set consiste in uno o più file, chiamati backup piece.

Una delle caratteristiche dei Backup Set è che contengono solo file con dimensione del blocco omogeneo, quindi, ad esempio se nel database vi sono tablespace con dimensione del blocco diverse, ad esempio 8k e 16k  vengono creati due backup set distinti.  Sui manuali non ho trovato riferimento a questa caratteristica, ma solo un riferimento al caso del control file; da questo e da un mio test ho desunto quanto ho detto.

RMAN utilizza il concetto di “channel” la cui definizione per me non è mai stata chiara. Credo che sia il modo di chiamare lato RMAN i processi server che fisicamente scrivono i backup. RMAN permette di migliorare le prestazioni dei backup parallelizzando le operazioni sfruttando più channel. In sostanza nella creazione di un backup, attraverso algoritmi suoi RMAN crea tanti backup set quanti sono i channel allocati e li scrive in parallelo. L’utilità è facilmente comprensibile se si pensa all’utilizzo di due tape drive. Qui devo devo dire che non avendo mai approfondito prima pensavo che tale parallelizzazione avvenisse a livello di backup piece invece RMAN non è in grado di parallelizzare la scrittura di più backup piece per un backup set. Credo che l’unica vera utilità del backup piece sia quella di poter spezzare il backpup in file di dimensione arbitrariamente piccola. Infatti la dimensione di un backup set può essere limitata con la configurazione del parametro MAXSETSIZE (configurazione che può essere memorizzata con il comando CONFIGURA MAXSETSIZE …) il valore di questo limite però non può essere inferiore alla dimensione di alcun datafile, altrimenti la creazione del backup set fallisce.

RMAN> backup datafile 4 maxsetsize 500 M;

Starting backup at 30-OCT-08
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 10/30/2008 16:41:38
RMAN-06183: datafile or datafile copy larger than MAXSETSIZE: file# 4 /opt/oracle/oradata/test102/users01.dbf

RMAN fa un controllo prima di iniziare.

Come di vede dall’esempio il maxsetsize può essere anche specificato direttamente con il comando di backup. Stando al manuale questo parametro può essere utile se si vuole avere garanzia che ogni backup set stia su una cassetta.

Più interessante (e per un po’ è stato misterioso per me) è il parametro FILESPERSET, che purtroppo però non è configurabile in modo permanente con il comando CONFIGURE di RMAN. Esso è solo utilizzabile come parametro del comando backup, limita il numero di file del database che vengono inclusi in un backup set. La prima conseguenza di ciò è quella di limitare l’uso di risorse di RMAN limitando il “multiplexing” ovvero la caratteristica per cui Oracle legge contemporanemante da più file quando crea un backup set e “mischia” i blocchi dei vari file dentro il backup set. Questa caratteristica in teoria è un po’ obsoleta in quanto superata dal parametro RATE e DURATION (che se non erro sono nuovi in 10g).

Per quanto rigurda la parallelizzazione, nei mie test di backup su disco, con allocazione automatica dei canali ho visto che l’unica configurazione che influisce è CONFIGURE DEVICE TYPE DISK PARALLELISM … per il resto rimando al manuale per i dettagli.

In diverse parti dei manuali, ad esempio qui e qui si dice che per default oracle mette 4 datafile per backup set e 16 archivelog per dataset. Però dai miei test ciò non risulta e nella definizione di FILESPERSET si parla di 64, non so se mi sfugge qualcosa o se c’è un errore nella documentazione.

Con questo post ho cercato di riordinarmi le idee su quello che ho appreso di nuovo riguardo i backup set di RMAN. Ripeto, i dettagli sulle configurazioni e sull’utilizzo di RMAN sono molti, non a caso vi sono migliaia di pagine di Manuali, però un passo alla volta si riesce ad avere una panoramica sempre più ampia.

I tempfile in Oracle 10gR2

mercoledì 22 ottobre 2008 alle 22:33 | Pubblicato su Backup and Recovery, Diario | 3 commenti
Tag: , ,

Studiando per l’OCP ieri ho notato una cosa particolare che mi ha fatto accendere una lampadina. Sulla guida di studio, dove si parla del ripristino della tablespace TEMP c’è un estratto di un errore che fa riferimento a un file con id 201.

Oggi  ho fatto un paio di prove su un db preparato appositamente, la prima volta ho provato a spegnere il db, a a cancellare il file della tablespace TEMP e riaprire il db. Ciò che accade è molto bene, e in effetti lo avevo gia notato con le prove di ripristino di un backup: Oracle ricrea automaticamente il file, questo si vede dall’alert.log-

Wed Oct 22 15:51:51 2008
Re-creating tempfile /opt/oracle/oradata/test102/temp01.dbf

Volevo però simulare una corruzione del file, allora ho fatto la seguente operazione, a db fermo:

[oracle@testrman test102]$ dd if=/dev/zero of=/opt/oracle/oradata/test102/temp01.dbf bs=1024 count=12 skip=1
12+0 records in
12+0 records out

Ho riaperto il db e anche in questo caso non ho avuto segnalazioni:

SQL*Plus: Release 10.2.0.4.0 – Production on Wed Oct 22 15:58:04 2008

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

Connected to an idle instance.

SQL> startup
ORACLE instance started.

Total System Global Area  432013312 bytes
Fixed Size                  2084552 bytes
Variable Size             306184504 bytes
Database Buffers          117440512 bytes
Redo Buffers                6303744 bytes
Database mounted.
Database opened.

Qualcosa però è successo, infatti nell’alert:

Wed Oct 22 15:58:13 2008
Cannot re-create tempfile /opt/oracle/oradata/test102/temp01.dbf, the same name file exists
Wed Oct 22 15:58:13 2008
Errors in file /opt/oracle/admin/test102/bdump/test102_dbw0_3713.trc:
ORA-01157: cannot identify/lock data file 201 – see DBWR trace file
ORA-01110: data file 201: ‘/opt/oracle/oradata/test102/temp01.dbf’
ORA-27046: file size is not a multiple of logical block size
Additional information: 1

Insomma, Oracle si è accorto che il file era corrotto ma giustamente ha aperto comunque il database.

SQL> select * from dba_temp_files;
select * from dba_temp_files
*
ERROR at line 1:
ORA-01157: cannot identify/lock data file 201 – see DBWR trace file
ORA-01110: data file 201: ‘/opt/oracle/oradata/test102/temp01.dbf’

La cosa strana, almeno per me è il fatto che Oracle parli di “file 201”. Ho applicato una procedura di ripristino:

SQL> alter tablespace temp add tempfile  ‘/opt/oracle/oradata/test102/temp02.dbf’ size 128 m;

Tablespace altered.

SQL> alter tablespace temp drop tempfile ‘/opt/oracle/oradata/test102/temp01.dbf’;

Tablespace altered.

SQL> select * from dba_temp_files;

FILE_NAME
——————————————————————————–
FILE_ID TABLESPACE_NAME                     BYTES     BLOCKS STATUS
———- —————————— ———- ———- ———
RELATIVE_FNO AUT   MAXBYTES  MAXBLOCKS INCREMENT_BY USER_BYTES USER_BLOCKS
———— — ———- ———- ———— ———- ———–
/opt/oracle/oradata/test102/temp02.dbf
2 TEMP                            134217728      16384 AVAILABLE
2 NO           0          0            0  133169152       16256

A questo punto volevo verificare una cosa, allora ho ripetuto l’esperimento, ho ricorrotto il file a mano e riavviato il database:

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> exit

[oracle@testrman test102]$ dd if=/dev/zero of=/opt/oracle/oradata/test102/temp02.dbf bs=1024 count=12 skip=1
12+0 records in
12+0 records out
[oracle@testrman test102]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.4.0 – Production on Wed Oct 22 18:23:54 2008

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

Connected to an idle instance.

SQL> startup
ORACLE instance started.

Total System Global Area  432013312 bytes
Fixed Size                  2084552 bytes
Variable Size             306184504 bytes
Database Buffers          117440512 bytes
Redo Buffers                6303744 bytes
Database mounted.
Database opened.
SQL> !tail -40  /opt/oracle/admin/test102/bdump/alert_test102.log
LGWR: STARTING ARCH PROCESSES COMPLETE
ARC1 started with pid=16, OS id=5859
Wed Oct 22 18:24:02 2008
ARC0: Becoming the ‘no FAL’ ARCH
ARC0: Becoming the ‘no SRL’ ARCH
Wed Oct 22 18:24:02 2008
ARC1: Becoming the heartbeat ARCH
Wed Oct 22 18:24:02 2008
Thread 1 opened at log sequence 568
Current log# 2 seq# 568 mem# 0: /opt/oracle/oradata/test102/redo02.log
Successful open of redo thread 1
Wed Oct 22 18:24:02 2008
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Wed Oct 22 18:24:02 2008
SMON: enabling cache recovery
Wed Oct 22 18:24:03 2008
Successfully onlined Undo Tablespace 1.
Wed Oct 22 18:24:03 2008
SMON: enabling tx recovery
Wed Oct 22 18:24:03 2008
Cannot re-create tempfile /opt/oracle/oradata/test102/temp02.dbf, the same name file exists
Wed Oct 22 18:24:03 2008
Errors in file /opt/oracle/admin/test102/bdump/test102_dbw0_5837.trc:
ORA-01157: cannot identify/lock data file 202 – see DBWR trace file
ORA-01110: data file 202: ‘/opt/oracle/oradata/test102/temp02.dbf’
ORA-27046: file size is not a multiple of logical block size
Additional information: 1
Database Characterset is AL32UTF8
Opening with internal Resource Manager plan
where NUMA PG = 1, CPUs = 1
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
QMNC started with pid=17, OS id=5861
Wed Oct 22 18:24:07 2008
Completed: ALTER DATABASE OPEN

Ebbene, la cosa per me curiosa è il fatto che in realtà interrogando DBA_TEMP_FILES o V$TEMPFILE viene indicato come id del file 1,2, ecc, ma in realtà sembra che internamente oracle sommi 200 a tale id.

La cosa mi ha interessato particolarmente perchè tempo fa su un database accadde che lato applicazione avevamo alle volte un errore Oracle che faceva appunto riferimento al file con id 201 e non riuscivamo a capire di cosa si trattasse. Il bello è che aprii anche una chiamata (TAR o SR) sul metalink, ma nessuno mi seppe dire che si trattava del tempfile.

Panoramica sulla tecnologie Flashback di Oracle

lunedì 13 ottobre 2008 alle 13:24 | Pubblicato su Backup and Recovery, Installation and Configuration | 1 commento
Tag: , , ,

Nel mio percorso di studio e ripasso per l’OCP oggi scrivo un post di introduzione alle tecnologie di flashback implementate e disponibili nella versione 10gR2 del database Oracle.

Comincio con il spiegare di cosa si tratta: in sostanza si tratta di una serie di strumenti che ha come obbiettivo principale quello di facilitare le operazioni di ripristino di dati corrotti a causa di errori umani logici, ad esempio un drop table sbagliato o peggio errori applicativi che hanno fatto transazioni sbagliate. Questi strumenti vanno tutti sotto la categoria “flashback” in quanto permettono o di vedere come erano i dati nel passato, o come sono cambiati o di ripristinare i dati o l’intero database com’era nel passato.

Le tecnologie flashback sono cinque:

  1. Flashback Database (solo enterprise edition)
  2. Flashback Drop
  3. Flashback Versions (forse anche in standard, ma devo verificare)
  4. Flashback Transaction (solo enterprise edition)
  5. Flashback table (solo enterprise edition)

Flashback Database (Rif. Manuale: Concepts, Backup and Recovery Basics)

Va attivata esplicitamente, a database in stato mounted. Quando è attivata questa modalità un processo di background, chiamato “flashback writer (RVWR)” scrive nella flash recovery area (FRA) dei log che in sostanza registrano le modifiche al blocchi (tipo l’UNDO). La conservazione di questi log è basata sul parametro DB_FLASHBACK_RETENTION_TARGET che deve essere obbligatoriamente settato e serve ad indicare un obbiettivo (target) di tempo di flashback da manterenerein FRA. Quindi settando ad esempio DB_FLASHBACK_RETENTION_TARGET=1440 (il default, in minuti, pari a un giorno) si chiede al RVWR di aver come obbiettivo il mantenimento su disco dei log per poter riportare indietro il database fino al giorno prima.

Le possibilità di flashback hanno dei limiti, specificati nel manuale, però la potenzialità di questo strumento è alta. E’ da capire il reale impatto di questa caratteristica sulle prestazioni,  di sicuro non nullo.

Flashback DROP

Questa funzionalità implementa un cestino delle tabelle. Da oracle 10g quando si fa DROP TABLE X; la tabella non viene realmente droppata ma viene messa in un cestino che funziona a livello di tablespace (ogni tablespace ha un suo cestino). Per eliminare direttamente una tabella la sintassi SQL di oracle è stata estesa e si deve scrivere DROP TABLE X PURGE; Il cestino è consultabile con le viste USER/DBA_RECYCLEBIN dove si vede che le tabelle vengono rinominati con nomi strani. Il cestino può essere svuotato con comandi come “PURGE RECYCLEBIN”. Vi sono poi varianti del comando purge come “PURGE TABLE x”, PURGE TABLESPACE y” ecc.

Flashback Transaction Query (Rif. Man. “Administrators Guide“)

Questa funzionalità si basa sul gia esistente UNDO e permette con una semplice estensione dell’SQL di interrogare i dati indietro nel tempo. La disponibilità di questi dati dipende dal’UNDO, quindi dai parametri UNDO_RETENTION ed eventualmente dal fatto che sulla tablespace di UNDO utilizzata sia configurato il “retention guarantee“. Un esempio di utilizzo di questa funzionalità, direttamente dal manuale è:

SELECT versions_startscn, versions_starttime,
       versions_endscn, versions_endtime,
       versions_xid, versions_operation,
       name, salary
  FROM employees
  VERSIONS BETWEEN TIMESTAMP
      TO_TIMESTAMP('2003-07-18 14:00:00', 'YYYY-MM-DD HH24:MI:SS')
  AND TO_TIMESTAMP('2003-07-18 17:00:00', 'YYYY-MM-DD HH24:MI:SS')
  WHERE name = 'JOE';

Come si vede dall’esempio oltre all’estensione della select con la parte … VERSIONS, ci sono anche delle pseudocolonne (versions_%) che danno informazione sulla “versione” del dato.

Flashback Transaction Query (Rif. Man. “Application Developers“)

Questa funzionalità permette di interrogare una vista di sistema, FLASHBACK_TRANSACTION_QUERY, dalla quale si ottengono tutte le informazioni relative alle ultime transazioni eseguite (i cui dati si trovano ancora nell’UNDO) compreso l’istruzione SQL per “annullare” ogni singola istruzione di ogni transazione (UNDO). Riporto sono un piccolo esempio di utilizzo, per maggiori approfondimenti rimando al manuale:

SELECT xid, logon_user FROM flashback_transaction_query
     WHERE xid IN (SELECT versions_xid FROM employees VERSIONS BETWEEN TIMESTAMP
      TO_TIMESTAMP('2003-07-18 14:00:00', 'YYYY-MM-DD HH24:MI:SS') AND
      TO_TIMESTAMP('2003-07-18 17:00:00', 'YYYY-MM-DD HH24:MI:SS'));

Flashback Query
Nel manuale su cui studio per l’OCP non se ne parla perchè evidentemente non fa parte del manuale, vi è però un’altra funzionalità di backup, già introdotto con Oracle 9, flashback query. Effettivamente forse non se ne parla perchè le nuove funzionalità l’hanno sorpassata, questa funzionalità è simile alla “flashback versions” in quanto permette di vedere i dati come erano nel passato con la sintassi SQL “SELECT… AS OF”, ad esempio:

SELECT * FROM employees AS OF TIMESTAMP
   TO_TIMESTAMP('2004-04-04 09:30:00', 'YYYY-MM-DD HH:MI:SS')
   WHERE last_name = 'Chung';

Conclusioni

Devo confessare che non ho mai avuto necessità di utilizzare veramente nessuna di tutte queste belle funzionalità. Quella più interessante mi pare quella di Flashback Database per la quale a dire il vero intravedo una possibilità di uso reale, ma sono perplesso su due aspetti, uno quello delle prestazioni, due quello della gestione dei log. Tempo fa su una installazione di test attivai la funzionalità di flashback database e mi trovai un po’ in difficoltà perchè non riuscivo a liberare rapidamente lo spazio occupato da questi log nella flash recovery area. Tramite RMAN è possibile salvarli solo su nastro e se non ricordo male non era possibile cancellarli se non erano stati salvati prima (era una 10.1, con ASM, poi non ho più provato). Quindi probabilmente il modo più veloce di fare spazio è abbassare drasticamente il parametro FLASHBACK_RETENTION_TARGET e lasciare che Oracle automaticamente liberi lo spazio che gli serve.

Esercitarsi con RMAN

venerdì 11 luglio 2008 alle 11:05 | Pubblicato su Backup and Recovery | Lascia un commento
Tag: , , ,

Grazie agli incredibili consigli di “Google Reader”  (ma come farà? mi stupisce sempre) che da poche settimane uso con grande soddisfazione, ieri sono ricapitato dopo molto tempo sul blog di Alejandro Vargas . Consiglio a tutti di dare un’occhiata all’archivio del suo blog, vi si possono trovare un sacco di informazioni interessanti. In particolare, ricollegandomi ad un mio post di qualche giorno fa (“introduzione a oracle recovery manager (RMAN)“), se qualcuno ha voglia (o bisogno) di esercitarsi con RMAN consiglio di leggersi il post “Oracle Recovery Manager (RMAN) Hands On Practice“. In questo post Alejandro Vargas ribadisce il concetto che RMAN è uno strumento molto potente e complesso, che può essere facile da usare ma anche difficile. Soprattutto l’autore mette a disposizione un corposo documento PDF con una bella esercitazione pratica su RMAN. Manca solo purtroppo il link agli script per ricreare l’ambiente di esercitazione, ma con un po’ di sforzo mi sembra che nel pdf si trovi tutto il necessario.

Flash Recovery Area

martedì 8 luglio 2008 alle 08:03 | Pubblicato su Backup and Recovery | Lascia un commento
Tag: , ,

La flash recovery area è una nuova caratteristica introdotta con Oracle 10g. Si tratta di una area sul disco, configurabile dinamicamente, dove Oracle per default mette tutti i file di backup e relativi alle funzionalità “flasback” (ad esempio i flashback logs). Ad esempio se viene configurata una flash recovery area (attraverso i parametri DB_RECOVERY_FILE_DEST E DB_RECOVERY_FILE_DEST_SIZE) il parametro LOG_ARCHIVE_DEST_10 implicitamente assume il valore di “USE_DB_RECOVERY_FILE_DEST” se non è stato settato esplicitamente alcun altro LOG_ARCHIVE_DEST_n.

Se la Flash recovery area viene definita durante la creazione del database DBCA mette in automatico anche una copia degli online redo log e del controlfile in essa.

La flash recovery area si basa su OMF (Oracle Managed Files) per l’organizzazione dei file al suo interno e può essere piazzata ovunque possa essere usato OMF, filesystem o ASM.

Il parametro DB_RECOVERY_FILE_DEST definisce dove questa area deve trovarsi, quindi può essere un percorso su filesystem (ad esempio /u01/oracle/fra) oppure un diskgroup ASM (ad esempio +DG_RECO). Il parametro DB_RECOVERY_FILE_DEST_SIZE definisce una dimensione massima (controllata da Oracle) per questa area. Attenzione, quando questa quota viene raggiunta Oracle cerca di liberare spazio, ad esempio cancellando backup che secondo le politiche di “retention” sono obsoleti. Se non è più in grado di liberare spazio gli archive log finiscono qua dentro il database ferma le transazioni.

RMAN prevede un comando per fare il backup completo della recovery area:

RMAN>BACKUP RECOVERY AREA;

Tale backup può essere fatto solo su tape.

Ricreazione del Controlfile e missing datafiles

martedì 8 luglio 2008 alle 08:51 | Pubblicato su Backup and Recovery | Lascia un commento
Tag: , ,

Studiando per la certificazione (e si sono un po’ lungo)  ho scoperto un’altra cosa nuova. Se ricreo il controlfile e dimentico di mettere qualche datafile nello script di creazione, Oracle al momento dell’apertura del database fa un controllo incrociato tra le informazioni del controlfile e quelle del dizionario dati, in questa fase può essere che appunto trovi nel dizionario dati dei datafile che nel controlfile non ci sono. In questo caso quello che accade è ben descritto nell’alert.log:

“Tablespace ‘USERS16K’ #5 found in data dictionary,
but not in the controlfile. Adding to controlfile.
File #5 found in data dictionary but not in controlfile.
Creating OFFLINE file ‘MISSING00005’ in the controlfile.

Questa situazione è facilmente riscontrabile se si ricrea il controlfile usando lo script creato con l’istruzione “ALTER DATABASE BACKUP CONTROLFILE TO TRACE” mentre una o più tablespace sono in modalità “READ ONLY”: in questo caso Oracle non include nello script di creazione del controlfile i datafile appartenenti alla tablespace in modalità READ ONLY. Questo comportamente pare dovuto al fatto che oracle ritenga che essendo la tablespace in modalità  READ ONLY non abbia bisogno di recovery …

In ogni caso, nel mio ambiente di test (10.2.0.4) nel trace compare anche

ALTER DATABASE OPEN RESETLOGS;
— Files in read-only tablespaces are now named.
ALTER DATABASE RENAME FILE ‘MISSING00004’
TO ‘/opt/oracle/oradata/test102/users01.dbf’;
— Online the files in read-only tablespaces.
ALTER TABLESPACE “USERS” ONLINE;
— Commands to add tempfiles to temporary tablespaces.
— Online tempfiles have complete space information.
— Other tempfiles may require adjustment.
ALTER TABLESPACE TEMP ADD
TEMPFILE ‘/opt/oracle/oradata/test102/temp01.dbf’
SIZE 20971520  REUSE AUTOEXTEND ON NEXT 655360 ;

Facendo questo questi test mi sono trovato di fronte ad un’altra situazione interessante: ho simulato la perdita completa del database, e disponevo solo di un backup completo del database stesso fatto con RMAN  e di tutti gli archived logs. Inizialmente pensavo di poter ricreare i controlfile con lo script generato con il trace, ma non è così, infatti:

SQL> CREATE CONTROLFILE  DATABASE “TEST102” RESETLOGS  ARCHIVELOG
2      MAXLOGFILES 16
3      MAXLOGMEMBERS 3
4      MAXDATAFILES 100
5      MAXINSTANCES 8
6      MAXLOGHISTORY 292
7  LOGFILE
8    GROUP 1 ‘/opt/oracle/oradata/test102/redo01.log’  SIZE 50M,
9    GROUP 2 ‘/opt/oracle/oradata/test102/redo02.log’  SIZE 50M,
10    GROUP 3 ‘/opt/oracle/oradata/test102/redo03.log’  SIZE 50M
11  — STANDBY LOGFILE
12  DATAFILE
13    ‘/opt/oracle/oradata/test102/system01.dbf’,
14    ‘/opt/oracle/oradata/test102/undotbs01.dbf’,
15    ‘/opt/oracle/oradata/test102/sysaux01.dbf’,
16    ‘/opt/oracle/oradata/test102/users01.dbf’,
17    ‘/opt/oracle/oradata/test102/users16k01.dbf’
18  CHARACTER SET AL32UTF8
19  ;
CREATE CONTROLFILE  DATABASE “TEST102” RESETLOGS  ARCHIVELOG
*
ERROR at line 1:
ORA-01503: CREATE CONTROLFILE failed
ORA-01565: error in identifying file ‘/opt/oracle/oradata/test102/system01.dbf’
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

Quindi ho capito perchè in automatico RMAN quando viene fatto il backup della tablespace SYSTEM include anche il controlfile.

Si tratta di cose che per chi è esperto possono essere banali, ma i dettagli e le situazioni che si possono presentare sono talmente tanti che qualcosa può sempre sfuggire. Per conto mio ho sempre cercato di essere superprevidente nelle mie politiche di backup, quindi vi è sempre un backup esplicito del controlfile. Anche perchè in 9i mi pare non vi fosse il modo (almeno documentato) di registrare un backup sul control file se questo era stato ricreato. Quindi perdendo il control file  si perdevano anche le info dei backup (a meno di non usare un recovery catalog come consigliato da Oracle). In 10g, anche ricreando un controlfile o ripristinandone uno vecchio, è possibile registrare i backup fatti e quindi utilizzarli. Ripeto: preferisco essere iperprevidente ed evitare di trovarmi in situazioni simili.

Pagina successiva »

Blog su WordPress.com.
Entries e commenti feeds.