I tempfile in Oracle 10gR2

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.

3 pensieri su “I tempfile in Oracle 10gR2

  1. Sandro

    Ciao,
    il 13 ed 14 scorso sono stato al seminario di Kyle Hailey “Advanced Oracle 10g Performance Analysis and Tuning” tenuto da Kyle Hailey: ebbene ha spiegato proprio ciò ovvero che l’id dei tempfile è dato da DB_FILES + TmpFile#. Ciò deriva dal fatto TmpFileNumber potrebbe essere lo stesso di un File# permanente.

Lascia un commento