记录一次ORA-600[13013]处理过程

在一次数据库的异常处理完成后,发现alert日志中出现ORA-600[13013]错误

Thu Mar 08 23:29:37 2012
Errors in file /opt/oracle/diag/rdbms/chf/chf/trace/chf_smon_24137.trc  (incident=38681):
ORA-00600: internal error code, arguments: [13013], [5001], [518], [4198427], [170], [4198427], [17], [], [], [], [], []
Incident details in: /opt/oracle/diag/rdbms/chf/chf/incident/incdir_38681/chf_smon_24137_i38681.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Non-fatal internal error happenned while SMON was doing flushing of monitored table stats.
SMON encountered 1 out of maximum 100 non-fatal internal errors.

trace文件中信息
从这里可以看出是对sys.col_usage$表进行update操作导致该错误发生

Dump continued from file: /opt/oracle/diag/rdbms/chf/chf/trace/chf_smon_24137.trc
ORA-00600: internal error code, arguments: [13013], [5001], [518], [4198427], [170], [4198427], [17], [], [], [], [], []
========= Dump for incident 38681 (ORA 600 [13013]) ========
*** 2012-03-08 23:29:37.400
dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)
----- Current SQL Statement for this session (sql_id=3c1kubcdjnppq) -----
update sys.col_usage$ set   equality_preds    = equality_preds    + decode(bitand(:flag,1),0,0,1),   equijoin_preds    = equijoin_preds    + decode(bitand(:flag,2),0,0
,1),   nonequijoin_preds = nonequijoin_preds + decode(bitand(:flag,4),0,0,1),   range_preds       = range_preds       + decode(bitand(:flag,8),0,0,1),   like_preds
    = like_preds        + decode(bitand(:flag,16),0,0,1),   null_preds        = null_preds        + decode(bitand(:flag,32),0,0,1),  timestamp = :time where obj# = :ob
jn and intcol# = :coln

MOS中关于ORA-600 [13013]描述

Format: ORA-600 [13013] [a] [b] {c} [d] [e] [f]
Arg [a] Passcount
Arg [b] Data Object number
Arg {c} Tablespace Decimal Relative DBA (RDBA) of block containing the row to be updated
Arg [d] Row Slot number
Arg [e] Decimal RDBA of block being updated (Typically same as {c})
Arg [f] Code

验证MOS中描述

SQL> select dbms_utility.data_block_address_file(4198427) rfile,
  2  dbms_utility.data_block_address_block(4198427) blocks
  3  from dual;
     RFILE     BLOCKS
---------- ----------
         1       4123
SQL> SELECT OWNER, SEGMENT_NAME, SEGMENT_TYPE, TABLESPACE_NAME, A.PARTITION_NAME
  2    FROM DBA_EXTENTS A
  3   WHERE FILE_ID = &FILE_ID
  4     AND &BLOCK_ID BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1;
Enter value for file_id: 1
old   3:  WHERE FILE_ID = &FILE_ID
new   3:  WHERE FILE_ID = 1
Enter value for block_id: 4123
old   4:    AND &BLOCK_ID BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1
new   4:    AND 4123 BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1
OWNER SEGMENT_NAME SEGMENT_TY TABLESPACE PARTI
----- ------------ ---------- ---------- -----
SYS   COL_USAGE$   TABLE      SYSTEM
--和trace文件中异常表一致
SQL>  select object_type,object_name from dba_objects where object_id=518;
OBJECT_TYPE         OBJECT_NAME
------------------- ------------------------------
TABLE               COL_USAGE$
--也和trace文件中异常表一致

分析异常表

SQL> ANALYZE TABLE sys.COL_USAGE$ VALIDATE STRUCTURE CASCADE;
ANALYZE TABLE sys.COL_USAGE$ VALIDATE STRUCTURE CASCADE
*
ERROR at line 1:
ORA-01499: table/index cross reference failure - see trace file
SQL> select index_name,COLUMN_NAME,COLUMN_POSITION FROM DBA_IND_COLUMNS
2    WHERE TABLE_NAME='COL_USAGE$';
INDEX_NAME      COLUMN_NAM COLUMN_POSITION
--------------- ---------- ---------------
I_COL_USAGE$    OBJ#                     1
I_COL_USAGE$    INTCOL#                  2
SQL> set autot trace exp
SQL>  SELECT /*+ FULL(t1) */ OBJ#,INTCOL#
  2   FROM sys.COL_USAGE$ t1
  3   MINUS
  4   SELECT /*+ index(t I_COL_USAGE$) */ OBJ#,INTCOL#
  5   FROM sys.COL_USAGE$ t where OBJ# is not null or INTCOL# is not null;
no rows selected
--无记录返回
Execution Plan
----------------------------------------------------------
Plan hash value: 399371572
------------------------------------------------------------------------------------
| Id  | Operation           | Name         | Rows  | Bytes | Cost (%CPU)| Time
   |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |              |  4262 | 76716 |    27  (71)| 00:00:01 |
|   1 |  MINUS              |              |       |       |            |          |
|   2 |   SORT UNIQUE       |              |  4262 | 38358 |     9  (12)| 00:00:01 |
|   3 |    TABLE ACCESS FULL| COL_USAGE$   |  4262 | 38358 |     8   (0)| 00:00:01 |
|   4 |   SORT UNIQUE NOSORT|              |  4262 | 38358 |    18   (6)| 00:00:01 |
|*  5 |    INDEX FULL SCAN  | I_COL_USAGE$ |  4262 | 38358 |    17   (0)| 00:00:01 |
------------------------------------------------------------------------------------
--验证表两个sql是否正确(一个全表扫描,另个index 快速扫描)
SQL>  SELECT /*+ index(t I_COL_USAGE$) */ OBJ#,INTCOL#
  2   FROM sys.COL_USAGE$ t where OBJ# is not null or INTCOL# is not null
  3   MINUS
  4  SELECT /*+ FULL(t1) */ OBJ#,INTCOL#
  5   FROM sys.COL_USAGE$ t1;
      OBJ#    INTCOL#
---------- ----------
4294951004          2
4294951004          3
4294951004          4
4294951004         26
4294951004         27
4294951037          4
4294951037          5
4294951037          6
4294951037          9
4294951037         10
4294951840         11
      OBJ#    INTCOL#
---------- ----------
4294951840         12
4294951906          4
4294952709          3
4294952867          4
4294952867          9
16 rows selected.
--证明index中的记录比表中多了16条

解决问题并验证

SQL> alter index sys.I_COL_USAGE$ rebuild online;
Index altered.
SQL>  SELECT /*+ FULL(t1) */ OBJ#,INTCOL#
 FROM sys.COL_USAGE$ t1
  2    3   MINUS
  4   SELECT /*+ index(t I_COL_USAGE$) */ OBJ#,INTCOL#
  5   FROM sys.COL_USAGE$ t where OBJ# is not null or INTCOL# is not null
  6  ;
no rows selected
SQL>  SELECT /*+ index(t I_COL_USAGE$) */ OBJ#,INTCOL#
  2   FROM sys.COL_USAGE$ t where OBJ# is not null or INTCOL# is not null
  3   MINUS
  4  SELECT /*+ FULL(t1) */ OBJ#,INTCOL#
  5   FROM sys.COL_USAGE$ t1;
no rows selected

这次出现此问题的原因是因为在更新语句中使用索引找到一条记录,然后到表中去查询时该记录不存在,出现此错误,一般解决方法是重建索引
官方关于ORA-600[13013]说明

使用_allow_resetlogs_corruption打开无归档日志rman备份库

rman还原恢复操作

--还原数据库
RMAN> restore database;
--恢复数据库
RMAN> recover database;
Starting recover at 2012-03-08 21:20:45
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=65 device type=DISK
starting media recovery
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 03/08/2012 21:20:47
RMAN-06053: unable to perform media recovery because of missing log
RMAN-06025: no backup of archived log for thread 1 with sequence 2936 and starting SCN of 25991695 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 2935 and starting SCN of 25991652 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 2934 and starting SCN of 25991649 found to restore
……………………
RMAN-06025: no backup of archived log for thread 1 with sequence 2902 and starting SCN of 25991156 found to restore
这里报日志缺少,实际上是备份的数据库文件后,没有备份归档日志,归档日志全部丢失

进行不完全恢复

SQL> recover database until cancel;
ORA-00279: change 25991194 generated at 03/08/2012 20:33:58 needed for thread 1
ORA-00289: suggestion : /opt/oracle/oradata/archivelog/chf/1_2902_752334071.dbf
ORA-00280: change 25991194 for thread 1 is in sequence #2902
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/opt/oracle/oradata/chf/system01.dbf'
ORA-01112: media recovery not started
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/opt/oracle/oradata/chf/system01.dbf'

查看相关SCN

SQL> select file#,to_char(checkpoint_change#,'999999999999') from v$datafile;
     FILE# TO_CHAR(CHECK
---------- -------------
         1      25992214
         2      25992214
         3      25992214
         4      25992214
         5      25992214
         6      25992214
         7      25992214
         8      25992214
         9      25992214
        10      25992214
        11      25992214
     FILE# TO_CHAR(CHECK
---------- -------------
        13      25992214
        14      25992214
13 rows selected.
SQL> select file#,online_status,to_char(change#,'999999999999') from v$recover_file;
     FILE# ONLINE_ TO_CHAR(CHANG
---------- ------- -------------
         1 ONLINE       25991194
         2 ONLINE       25991194
         3 ONLINE       25991194
         4 ONLINE       25991194
         5 ONLINE       25991194
         6 ONLINE       25991194
         7 ONLINE       25991194
         8 ONLINE       25991194
         9 ONLINE       25991194
        10 ONLINE       25991194
        11 ONLINE       25991194
     FILE# ONLINE_ TO_CHAR(CHANG
---------- ------- -------------
        13 ONLINE       25991194
        14 ONLINE       25991194
13 rows selected.
SQL> select file#,to_char(checkpoint_change#,'999999999999') from v$datafile_header;
     FILE# TO_CHAR(CHECK
---------- -------------
         1      25991194
         2      25991194
         3      25991194
         4      25991194
         5      25991194
         6      25991194
         7      25991194
         8      25991194
         9      25991194
        10      25991194
        11      25991194
     FILE# TO_CHAR(CHECK
---------- -------------
        13      25991194
        14      25991194
13 rows selected.
--发现数据文件scn和控制文件不一致,重建控制文件,然后查询相关scn
SQL> select file#,to_char(checkpoint_change#,'999999999999') from v$datafile;
     FILE# TO_CHAR(CHECK
---------- -------------
         1      25991194
         2      25991194
         3      25991194
         4      25991194
         5      25991194
         6      25991194
         7      25991194
         8      25991194
         9      25991194
        10      25991194
        11      25991194
     FILE# TO_CHAR(CHECK
---------- -------------
        13      25991194
        14      25991194
13 rows selected.
SQL> select file#,online_status,to_char(change#,'999999999999') from v$recover_file;
     FILE# ONLINE_ TO_CHAR(CHANG
---------- ------- -------------
         1 ONLINE       25991194
         2 ONLINE       25991194
         3 ONLINE       25991194
         4 ONLINE       25991194
         5 ONLINE       25991194
         6 ONLINE       25991194
         7 ONLINE       25991194
         8 ONLINE       25991194
         9 ONLINE       25991194
        10 ONLINE       25991194
        11 ONLINE       25991194
     FILE# ONLINE_ TO_CHAR(CHANG
---------- ------- -------------
        13 ONLINE       25991194
        14 ONLINE       25991194
13 rows selected.
SQL> select file#,to_char(checkpoint_change#,'999999999999') from v$datafile_header;
     FILE# TO_CHAR(CHECK
---------- -------------
         1      25991194
         2      25991194
         3      25991194
         4      25991194
         5      25991194
         6      25991194
         7      25991194
         8      25991194
         9      25991194
        10      25991194
        11      25991194
     FILE# TO_CHAR(CHECK
---------- -------------
        13      25991194
        14      25991194
13 rows selected.
--此时所有scn均一致

尝试打开数据库

SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/opt/oracle/oradata/chf/system01.dbf'
SQL> recover database using backup controlfile until cancel;
ORA-00279: change 25991194 generated at 03/08/2012 20:33:58 needed for thread 1
ORA-00289: suggestion : /opt/oracle/oradata/archivelog/chf/1_2902_752334071.dbf
ORA-00280: change 25991194 for thread 1 is in sequence #2902
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/opt/oracle/oradata/chf/system01.dbf'
ORA-01112: media recovery not started
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/opt/oracle/oradata/chf/system01.dbf'

使用隐含参数打开数据库

SQL> create pfile='/tmp/pfile' from spfile;
File created.
-------/tmp/pfile中加上----------
_allow_resetlogs_corruption= TRUE
---------------------------------
SQL> startup mount pfile='/tmp/pfile' force
ORACLE instance started.
Total System Global Area  622149632 bytes
Fixed Size                  2230912 bytes
Variable Size             419431808 bytes
Database Buffers          192937984 bytes
Redo Buffers                7548928 bytes
Database mounted.
SQL> alter database open resetlogs;
Database altered.
SQL> select open_mode from v$database;
OPEN_MODE
--------------------
READ WRITE

总结
这次的试验没有多少实际意义,但是可以说明几个问题:
1.所有的数据文件的scn都一致,甚至和控制文件的也一致,数据库不一定可以open成功
(怀疑是数据文件中的scn大于data header scn)
2.对于这样的问题,如果使用bbed修改所有数据文件header的scn不知道是否可以解决
3.如果rman只备份了数据文件而没有任何一个归档日志,数据库通过隐含参数还是可以open,抢救数据

找回ASM中数据文件

很多时候由于asm不能正常启动,导致数据丢失。下面提供两种方法找回asm中的数据文件
一.使用AMDU工具
AMDU是Oracle 11g里自带的一个免费的工具,用于分析ASM磁盘组的元数据以及从不能mount的磁盘组中往外抽取数据文件“NOTE:553639.1 Placeholder for AMDU binaries and using with ASM 10g”明确指出:AMDU也可用于10g,并提供了可用于10g的AMDU的各个操作系统的版本供大家下载。
1.设置LD_LIBRARY_PATH

rac1-> export LD_LIBRARY_PATH=/tmp/amdu

2.查看asm磁盘信息

rac1-> ./amdu -diskstring '/dev/raw/raw*'
amdu_2012_03_05_03_17_19/
rac1-> cd amdu_2012_03_05_03_17_19/
rac1-> ls
report.txt
rac1-> more report.txt
-*-amdu-*-
******************************* AMDU Settings ********************************
ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1
System name:    Linux
Node name:      rac1
Release:        2.6.9-89.0.0.0.1.ELhugemem
Version:        #1 SMP Tue May 19 04:38:38 EDT 2009
Machine:        i686
amdu run:       05-MAR-12 03:17:19
Endianess:      1
--------------------------------- Operations ---------------------------------
------------------------------- Disk Selection -------------------------------
 -diskstring '/dev/raw/raw*'
------------------------------ Reading Control -------------------------------
------------------------------- Output Control -------------------------------
********************************* DISCOVERY **********************************
----------------------------- DISK REPORT N0001 ------------------------------
                Disk Path: /dev/raw/raw23
           Unique Disk ID:
               Disk Label:
     Physical Sector Size: 512 bytes
                Disk Size: 156 megabytes
** NOT A VALID ASM DISK HEADER. BAD VALUE IN FIELD blksize_kfdhdb **
----------------------------- DISK REPORT N0002 ------------------------------
                Disk Path: /dev/raw/raw11
           Unique Disk ID:
               Disk Label:
     Physical Sector Size: 512 bytes
                Disk Size: 156 megabytes
** NOT A VALID ASM DISK HEADER. BAD VALUE IN FIELD blksize_kfdhdb **
----------------------------- DISK REPORT N0003 ------------------------------
                Disk Path: /dev/raw/raw32
           Unique Disk ID:
               Disk Label:
     Physical Sector Size: 512 bytes
                Disk Size: 156 megabytes
** NOT A VALID ASM DISK HEADER. BAD VALUE IN FIELD blksize_kfdhdb **
----------------------------- DISK REPORT N0004 ------------------------------
                Disk Path: /dev/raw/raw31
           Unique Disk ID:
               Disk Label:
     Physical Sector Size: 512 bytes
                Disk Size: 156 megabytes
** NOT A VALID ASM DISK HEADER. BAD VALUE IN FIELD blksize_kfdhdb **
----------------------------- DISK REPORT N0005 ------------------------------
                Disk Path: /dev/raw/raw12
           Unique Disk ID:
               Disk Label:
     Physical Sector Size: 512 bytes
                Disk Size: 156 megabytes
** NOT A VALID ASM DISK HEADER. BAD VALUE IN FIELD blksize_kfdhdb **
----------------------------- DISK REPORT N0006 ------------------------------
                Disk Path: /dev/raw/raw2
           Unique Disk ID:
               Disk Label:
     Physical Sector Size: 512 bytes
                Disk Size: 1976 megabytes
               Group Name: DATA
                Disk Name: DATA_0001
       Failure Group Name: DATA_0001
              Disk Number: 1
            Header Status: 3
       Disk Creation Time: 2012/03/01 22:32:39.289000
          Last Mount Time: 2012/03/05 02:10:02.771000
    Compatibility Version: 0x0a100000
         Disk Sector Size: 512 bytes
         Disk size in AUs: 1976 AUs
         Group Redundancy: 1
      Metadata Block Size: 4096 bytes
                  AU Size: 1048576 bytes
                   Stride: 113792 AUs
      Group Creation Time: 2012/03/01 22:32:39.221000
  File 1 Block 1 location: AU 0
----------------------------- DISK REPORT N0007 ------------------------------
                Disk Path: /dev/raw/raw1
           Unique Disk ID:
               Disk Label:
     Physical Sector Size: 512 bytes
                Disk Size: 3137 megabytes
               Group Name: DATA
                Disk Name: DATA_0000
       Failure Group Name: DATA_0000
              Disk Number: 0
            Header Status: 3
       Disk Creation Time: 2012/03/01 22:32:39.289000
          Last Mount Time: 2012/03/05 02:10:02.771000
    Compatibility Version: 0x0a100000
         Disk Sector Size: 512 bytes
         Disk size in AUs: 3137 AUs
         Group Redundancy: 1
      Metadata Block Size: 4096 bytes
                  AU Size: 1048576 bytes
                   Stride: 113792 AUs
      Group Creation Time: 2012/03/01 22:32:39.221000
  File 1 Block 1 location: AU 2
******************************* END OF REPORT ********************************

从这里可以得到信息如下:
1)只有/dev/raw/raw1和raw2是有效的asm磁盘
2)磁盘组只有DATA

3.找出数据文件信息

rac1-> ../amdu -diskstring '/dev/raw/raw*'  -dump 'DATA'
amdu_2012_03_05_03_19_38/
rac1-> cd amdu_2012_03_05_03_19_38/
rac1-> ls
DATA_0001.img  DATA.map  report.txt
rac1-> strings DATA_0001.img |grep DATAFILE
DATAFILE
DATAFILE
DATAFILE
DEVDB/DATAFILE/SYSTEM.256.776817753
DEVDB/DATAFILE/SYSAUX.257.776817753
DEVDB/DATAFILE/UNDOTBS1.258.776817753
DEVDB/DATAFILE/USERS.259.776817753
DEVDB/DATAFILE/UNDOTBS2.267.776817909

从这里可以得出数据文件的file号(第一位数字)

4.恢复数据文件

rac1-> ../../amdu -diskstring '/dev/raw/raw*' -extract 'DATA.259'
amdu_2012_03_05_03_27_21/
rac1-> cd amdu_2012_03_05_03_27_21/
rac1-> ls -l
total 5148
-rw-r--r--  1 oracle oinstall 5251072 Mar  5 03:27 DATA_259.f
-rw-r--r--  1 oracle oinstall    6468 Mar  5 03:27 report.txt
rac1-> dbv file=DATA_259.f
DBVERIFY: Release 10.2.0.1.0 - Production on Mon Mar 5 03:28:00 2012
Copyright (c) 1982, 2005, Oracle.  All rights reserved.
DBVERIFY - Verification starting : FILE = DATA_259.f
DBVERIFY - Verification complete
Total Pages Examined         : 640
Total Pages Processed (Data) : 15
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 2
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 26
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 597
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Highest block SCN            : 442362 (0.442362)

二.使用aulasm工具
1.配置ASM使用磁盘

[root@rac1 oracle]# more disk
/dev/sdb1
/dev/sdb2

2.使用aulasm

[root@rac1 oracle]# ./aulasm_linux32_trial.bin
AUL : AnySQL UnLoader(MyDUL) for Oracle ASM, release 2.0.0
(C) Copyright Lou Fangxin 2011-2012 (AnySQL.net), all rights reserved.
ASM> help
  SET        -- set options (BLOCK_SIZE, AU_SIZE, F1B1_DISK, F1B1_AU)
  OPEN       -- open data file
  ADD        -- add disk with customized disk num (disk, path)
  LIST       -- list opened disks information (to)
  LSAU       -- list file of given AU (disk, au, count)
  FILE       -- list all file entries in ASM (file, [disk, au, block]).
  ALIAS      -- list all alias entries in ASM (file, [disk, au, block]).
  EXTENT     -- list or adjust variable extent (level, au, count).
  FMAP       -- list file extent (file, [disk, au, block], to)
  DUMP       -- dump file extent (file, [disk, au, block], offset, to)
  COPY       -- copy file to os  (file, [disk, au, block], to)
  QUIT/EXIT  -- exit the program.
ASM> open disk
2012-03-05 03:32:48
2012-03-05 03:32:48
ASM> list
2012-03-05 03:32:49
Total Disks = 2, ausize=1048576, blksize=4096
 disk     size block disk name        disk group   disk path
===== ======== ===== ================ ============ ========================
    0     3137  4096 DATA_0000        DATA         /dev/sdb1
    1     1976  4096 DATA_0001        DATA         /dev/sdb2
f1b1disk = 0, f1b1au = 2, score=256, compat=0x0a100000
file=(1,0,2,1), disk=(2,0,2,2), alias=(6,0,2,6)
2012-03-05 03:32:49
ASM> alias
2012-03-05 03:33:15
    file          inc parent fstblk flag  refer alias
======== ============ ====== ====== ==== ====== ==========================
      -1           -1      0      0    4      1 DEVDB
      -1           -1      0      1    4      2 DATAFILE
      -1           -1      0      1    4      3 CONTROLFILE
      -1           -1      0      1    4      4 ONLINELOG
      -1           -1      0      1    4      5 TEMPFILE
      -1           -1      0      1    4      6 PARAMETERFILE
      -1           -1      0      1    4      7 ARCHIVELOG
     256    776817753      1      2   18     -1 SYSTEM
     257    776817753      1      2   18     -1 SYSAUX
     258    776817753      1      2   18     -1 UNDOTBS1
     259    776817753      1      2   18     -1 USERS
     267    776817909      1      2   18     -1 UNDOTBS2
     261    776817829      1      3   18     -1 Current
     260    776817829      1      3   18     -1 Current
     262    776817833      1      4   18     -1 group_1
     263    776817835      1      4   18     -1 group_1
     264    776817837      1      4   18     -1 group_2
     265    776817841      1      4   18     -1 group_2
     268    776818011      1      4   18     -1 group_3
     269    776818013      1      4   18     -1 group_3
     270    776818015      1      4   18     -1 group_4
     271    776818017      1      4   18     -1 group_4
     266    776817859      1      5   18     -1 TEMP
     272    776818021      1      6   18     -1 spfile
      -1           -1      1      7    4      8 2012_03_01
      -1           -1      1      7    4      9 2012_03_03
      -1           -1      1      7    4     10 2012_03_05
     273    776818747      7      8   18     -1 thread_1_seq_2
     274    776819571      7      8   18     -1 thread_1_seq_3
     275    776819721      7      8   18     -1 thread_2_seq_1
     276    776820331      7      8   18     -1 thread_1_seq_4
     277    776992321      7      9   18     -1 thread_1_seq_5
     278    776992321      7      9   18     -1 thread_2_seq_2
     279    777089437      7     10   18     -1 thread_1_seq_6
2012-03-05 03:33:15
ASM> fmap file 259
2012-03-05 03:34:49
fid=259, disk=0, au=56, block=3
siz=5, ecnt=6, eeof=6, flags=17, type=12, alias=109,-1
     extid  disk       auid  cnt flg chk
========== ===== ========== ==== === ===
         1     0        428    1   0 135
         2     1        408    1   0 178
         3     0        429    1   0 134
         4     1        409    1   0 179
         5     0        430    1   0 133
         6     1        410    1   0 176
2012-03-05 03:34:49
ASM> copy file 259 to user_259
2012-03-05 03:35:01
2012-03-05 03:35:01
[root@rac1 oracle]# ll
total 6252
-rwxr-xr-x  1 root   root       84619 Mar  6  2012 aulasm_linux32_trial.bin
-rw-r--r--  1 root   root          20 Mar  5 02:52 disk
-rw-r--r--  1 root   root     6291456 Mar  5 03:35 user_259
[root@rac1 oracle]# su - oracle
rac1-> dbv file=user_259
DBVERIFY: Release 10.2.0.1.0 - Production on Mon Mar 5 03:35:27 2012
Copyright (c) 1982, 2005, Oracle.  All rights reserved.
DBVERIFY - Verification starting : FILE = user_259
DBVERIFY - Verification complete
Total Pages Examined         : 640
Total Pages Processed (Data) : 15
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 2
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 26
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 597
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Highest block SCN            : 442362 (0.442362)

通过dbv验证,两个数据文件(文件大小有出入,可能在对待未格式化数据块上,两者处理有出入)可以基本上确定一致,证明两种方法都可以从异常的ASM中获取数据文件

三.总结与比较
1.AMDU完全免费,aulasm超过16块硬盘需要收费
2.AMDU操作相对于aulasm麻烦一点,但是整体还是可以接受
3.获取到asm中的数据文件后恢复数据内容或者open库,那都是容易的事情
如果因为磁盘头损坏太多或者其他原因,以上方法都不能实现抽取asm磁盘组中数据文件,参考:asm disk header 彻底损坏恢复

expdp中PARALLEL和DUMPFILE关系

今天有朋友在说PARALLEL设置为n(大于1),DUMPFILE为一个文件(不包含%U),会出现什么样的情况。下面通过实验来说明这个问题
1.当并发数比较大时(这里实验使用4),expdp会报ORA-39095错误

[oracle@node1 tmp]$ expdp chf/xifenfei DUMPFILE=xifenfei.dmp TABLES=t1 PARALLEL=4
Export: Release 11.2.0.3.0 - Production on Wed Mar 7 20:48:52 2012
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining,
Oracle Database Vault and Real Application Testing options
Starting "CHF"."SYS_EXPORT_TABLE_01":  chf/******** DUMPFILE=xifenfei.dmp TABLES=t1 PARALLEL=4
Estimate in progress using BLOCKS method...
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 5.362 GB
Processing object type TABLE_EXPORT/TABLE/TABLE
Processing object type TABLE_EXPORT/TABLE/INDEX/INDEX
ORA-39095: Dump file space has been exhausted: Unable to allocate 8192 bytes

2.并发数较少时(实验为2),通过attach观察
2.1)执行expdp导出

[oracle@node1 tmp]$ expdp chf/xifenfei DUMPFILE=xifenfei.dmp TABLES=t1 PARALLEL=2
Export: Release 11.2.0.3.0 - Production on Wed Mar 7 20:49:15 2012
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining,
Oracle Database Vault and Real Application Testing options
Starting "CHF"."SYS_EXPORT_TABLE_02":  chf/******** DUMPFILE=xifenfei.dmp TABLES=t1 PARALLEL=2
Estimate in progress using BLOCKS method...
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 5.362 GB
Processing object type TABLE_EXPORT/TABLE/TABLE
Processing object type TABLE_EXPORT/TABLE/INDEX/INDEX
. . exported "CHF"."T1"                                  4.647 GB 51080958 rows
Processing object type TABLE_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
Master table "CHF"."SYS_EXPORT_TABLE_02" successfully loaded/unloaded
******************************************************************************
Dump file set for CHF.SYS_EXPORT_TABLE_02 is:
  /opt/oracle/diag/rdbms/chf/chf/trace/xifenfei.dmp
Job "CHF"."SYS_EXPORT_TABLE_02" successfully completed at 20:52:23

2.2)在导出过程中,使用attach观察expdp工作情况

[oracle@node1 trace]$ expdp chf/xifenfei attach=SYS_EXPORT_TABLE_02
Export: Release 11.2.0.3.0 - Production on Wed Mar 7 20:49:38 2012
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining,
Oracle Database Vault and Real Application Testing options
Job: SYS_EXPORT_TABLE_02
  Owner: CHF
  Operation: EXPORT
  Creator Privs: TRUE
  GUID: BAA7964815021C96E0438C09A8C04319
  Start Time: Wednesday, 07 March, 2012 20:49:16
  Mode: TABLE
  Instance: chf
  Max Parallelism: 2
  EXPORT Job Parameters:
  Parameter Name      Parameter Value:
     CLIENT_COMMAND        chf/******** DUMPFILE=xifenfei.dmp TABLES=t1 PARALLEL=2
  State: EXECUTING
  Bytes Processed: 0
  Current Parallelism: 2
  Job Error Count: 0
  Dump File: /opt/oracle/diag/rdbms/chf/chf/trace/xifenfei.dmp
    bytes written: 4,096
Worker 1 Status:
  Process Name: DW00
  State: EXECUTING
  Object Schema: CHF
  Object Name: T1
  Object Type: TABLE_EXPORT/TABLE/TABLE
  Completed Objects: 1
  Total Objects: 1
  Worker Parallelism: 1
Worker 2 Status:
  Process Name: DW02
  State: EXECUTING
  Object Schema: CHF
  Object Name: T1
  Object Type: TABLE_EXPORT/TABLE/TABLE_DATA
  Completed Objects: 1
  Total Objects: 1
  Completed Rows: 16,104,279
  Worker Parallelism: 1
Export> status
Job: SYS_EXPORT_TABLE_02
  Operation: EXPORT
  Mode: TABLE
  State: EXECUTING
  Bytes Processed: 0
  Current Parallelism: 2
  Job Error Count: 0
  Dump File: /opt/oracle/diag/rdbms/chf/chf/trace/xifenfei.dmp
    bytes written: 4,096
Worker 1 Status:
  Process Name: DW00
  State: EXECUTING
  Object Schema: CHF
  Object Name: T1
  Object Type: TABLE_EXPORT/TABLE/TABLE
  Completed Objects: 1
  Total Objects: 1
  Worker Parallelism: 1
Worker 2 Status:
  Process Name: DW02
  State: EXECUTING
  Object Schema: CHF
  Object Name: T1
  Object Type: TABLE_EXPORT/TABLE/TABLE_DATA
  Completed Objects: 1
  Total Objects: 1
  Completed Rows: 35,425,534
  Worker Parallelism: 1
Export> status
Job: SYS_EXPORT_TABLE_02
  Operation: EXPORT
  Mode: TABLE
  State: COMPLETING
  Bytes Processed: 4,989,989,105
  Percent Done: 100
  Current Parallelism: 2
  Job Error Count: 0
  Dump File: /opt/oracle/diag/rdbms/chf/chf/trace/xifenfei.dmp
    bytes written: 4,990,009,344
Worker 1 Status:
  Process Name: DW00
  State: WORK WAITING
Worker 2 Status:
  Process Name: DW02
  State: WORK WAITING

3.最终结论
3.1)如果并发设置过大,在导出过程中直接报错
3.2)如果导出文件数量少于并发数时,多于并发将不会工作。

LNNVL函数使用

LNNVL官方解释
LNNVL provides a concise way to evaluate a condition when one or both operands of the condition may be null. The function can be used only in the WHERE clause of a query. It takes as an argument a condition and returns TRUE if the condition is FALSE or UNKNOWN and FALSE if the condition is TRUE. LNNVL can be used anywhere a scalar expression can appear, even in contexts where the IS [NOT] NULL, AND, or OR conditions are not valid but would otherwise be required to account for potential nulls. Oracle Database sometimes uses the LNNVL function internally in this way to rewrite NOT IN conditions as NOT EXISTS conditions. In such cases, output from EXPLAIN PLAN shows this operation in the plan table output. The condition can evaluate any scalar values but cannot be a compound condition containing AND, OR, or BETWEEN.

LNNVL官方解释翻译
lnnvl用于某个语句的where子句中的条件,如果条件为true就返回false;如果条件为UNKNOWN或者false就返回true。该函数不能用于复合条件如AND, OR, or BETWEEN中。

模拟测试环境

SQL> create table xifenfei(name varchar2(20),year number);
Table created.
SQL> insert into xifenfei values('xifenfei2001',2001);
1 row created.
SQL> insert into xifenfei values('xifenfei2002',2002);
1 row created.
SQL> insert into xifenfei values('xifenfei2003',2003);
1 row created.
SQL> insert into xifenfei values('xifenfei2004',2004);
1 row created.
SQL> insert into xifenfei values('xifenfei2005',2005);
1 row created.
SQL> insert into xifenfei values('xifenfei2006',2006);
1 row created.
SQL> insert into xifenfei values('xifenfei2007',2007);
1 row created.
SQL> insert into xifenfei values('xifenfei2008',null);
1 row created.
SQL> insert into xifenfei values('xifenfei2009',2009);
1 row created.
SQL> insert into xifenfei values('xifenfei2010',2010);
1 row created.
SQL> insert into xifenfei values('xifenfei2011',2011);
1 row created.
SQL> commit;
Commit complete.
SQL> select * from xifenfei;
NAME                       YEAR
-------------------- ----------
xifenfei2001               2001
xifenfei2002               2002
xifenfei2003               2003
xifenfei2004               2004
xifenfei2005               2005
xifenfei2006               2006
xifenfei2007               2007
xifenfei2008
xifenfei2009               2009
xifenfei2010               2010
xifenfei2011               2011
11 rows selected.

几种情况测试说明

--年份小于2009(lnnvl表示年份大于或者2009包含null)
SQL> select * from xifenfei where lnnvl(year<2009);
NAME                       YEAR
-------------------- ----------
xifenfei2008
xifenfei2009               2009
xifenfei2010               2010
xifenfei2011               2011
--year不为null(lnnvl表示年份为null)
SQL> select * from xifenfei where lnnvl(year is not null);
NAME                       YEAR
-------------------- ----------
xifenfei2008
--年份为null(lnnvl表示年份不为null)
SQL> select * from xifenfei where lnnvl(year is  null);
NAME                       YEAR
-------------------- ----------
xifenfei2001               2001
xifenfei2002               2002
xifenfei2003               2003
xifenfei2004               2004
xifenfei2005               2005
xifenfei2006               2006
xifenfei2007               2007
xifenfei2009               2009
xifenfei2010               2010
xifenfei2011               2011
10 rows selected.
--年份为12345(lnnvl表示年份不为12345)
SQL> select * from xifenfei where lnnvl(year =12345);
NAME                       YEAR
-------------------- ----------
xifenfei2001               2001
xifenfei2002               2002
xifenfei2003               2003
xifenfei2004               2004
xifenfei2005               2005
xifenfei2006               2006
xifenfei2007               2007
xifenfei2008
xifenfei2009               2009
xifenfei2010               2010
xifenfei2011               2011
11 rows selected.
--年份不为12345(lnnvl表示年份为12345或者null)
SQL> select * from xifenfei where lnnvl(year !=12345);
NAME                       YEAR
-------------------- ----------
xifenfei2008

Configuring an active standby pair with one subscriber

Step 1: Create the DSNs for the master and the subscriber databases

[master1]
DRIVER=/u01/TimesTen/tt1122/lib/libtten.so
DataStore=/u01/TimesTen/replicate//master1
DatabaseCharacterSet=ZHS16GBK
ConnectionCharacterSet=ZHS16GBK
PermSize=64
[master2]
DRIVER=/u01/TimesTen/tt1122/lib/libtten.so
DataStore=/u01/TimesTen/replicate//master2
DatabaseCharacterSet=ZHS16GBK
ConnectionCharacterSet=ZHS16GBK
PermSize=64
[subscriber1]
DRIVER=/u01/TimesTen/tt1122/lib/libtten.so
DataStore=/u01/TimesTen/replicate/subscriber1
DatabaseCharacterSet=ZHS16GBK
ConnectionCharacterSet=ZHS16GBK
PermSize=64

Step 2: Create a table in one of the master databases

[oracle@xifenfei info]$ ttIsql master1
Copyright (c) 1996-2011, Oracle.  All rights reserved.
Type ? or "help" for help, type "exit" to quit ttIsql.
connect "DSN=master1";
Connection successful: DSN=master1;UID=oracle;DataStore=/u01/TimesTen/replicate//master1;DatabaseCharacterSet=ZHS16GBK;ConnectionCharacterSet=ZHS16GBK;DRIVER=/u01/TimesTen/tt1122/lib/libtten.so;PermSize=64;TypeMode=0;
(Default setting AutoCommit=1)
Command>  CREATE TABLE tab (a NUMBER NOT NULL,
       >    b CHAR(18),
       >    PRIMARY KEY (a));

Step 3: Define the active standby pair

Command>  CREATE ACTIVE STANDBY PAIR master1, master2
       >    SUBSCRIBER subscriber1;

Step 4: Start the replication agent on a master database

Command>  CALL ttRepStart;

Step 5: Set the state of a master database to ‘ACTIVE’

Command>  CALL ttRepStateSet('ACTIVE');

Step 6. Create a user on the active database

Command> CREATE USER terry IDENTIFIED BY terry;
User created.
Command>  GRANT admin TO terry;

Step 7: Duplicate the active database to the standby database

[oracle@xifenfei info]$ ttRepAdmin -duplicate -from master1 -host xifenfei -uid terry -pwd terry  "dsn=master2"

Step 8: Start the replication agent on the standby database

[oracle@xifenfei info]$ ttIsql master2
Copyright (c) 1996-2011, Oracle.  All rights reserved.
Type ? or "help" for help, type "exit" to quit ttIsql.
connect "DSN=master2";
Connection successful: DSN=master2;UID=oracle;DataStore=/u01/TimesTen/replicate//master2;DatabaseCharacterSet=ZHS16GBK;ConnectionCharacterSet=ZHS16GBK;DRIVER=/u01/TimesTen/tt1122/lib/libtten.so;PermSize=64;TypeMode=0;
(Default setting AutoCommit=1)
Command>  CALL ttRepStart;

Step 9. Duplicate the standby database to the subscriber

[oracle@xifenfei info]$ ttRepAdmin -duplicate -from master2 -host xifenfei -uid terry -pwd terry  "dsn=subscriber1"

Step 10: Start the replication agent on the subscriber

[oracle@xifenfei info]$ ttIsql subscriber1
Copyright (c) 1996-2011, Oracle.  All rights reserved.
Type ? or "help" for help, type "exit" to quit ttIsql.
connect "DSN=subscriber1";
Connection successful: DSN=subscriber1;UID=oracle;DataStore=/u01/TimesTen/replicate/subscriber1;DatabaseCharacterSet=ZHS16GBK;ConnectionCharacterSet=ZHS16GBK;DRIVER=/u01/TimesTen/tt1122/lib/libtten.so;PermSize=64;TypeMode=0;
(Default setting AutoCommit=1)
Command>  CALL ttRepStart;

Step 11: Insert data into the table on the active database

[oracle@xifenfei info]$ ttIsql master1
Copyright (c) 1996-2011, Oracle.  All rights reserved.
Type ? or "help" for help, type "exit" to quit ttIsql.
connect "DSN=master1";
Connection successful: DSN=master1;UID=oracle;DataStore=/u01/TimesTen/replicate//master1;DatabaseCharacterSet=ZHS16GBK;ConnectionCharacterSet=ZHS16GBK;DRIVER=/u01/TimesTen/tt1122/lib/libtten.so;PermSize=64;TypeMode=0;
(Default setting AutoCommit=1)
Command> INSERT INTO tab VALUES (1,'Hello');
1 row inserted.
Command> commit;

Setp 12:Verify that the insert is replicated to master2 and subscriber1

[oracle@xifenfei info]$ ttIsql master2
Copyright (c) 1996-2011, Oracle.  All rights reserved.
Type ? or "help" for help, type "exit" to quit ttIsql.
connect "DSN=master2";
Connection successful: DSN=master2;UID=oracle;DataStore=/u01/TimesTen/replicate//master2;DatabaseCharacterSet=ZHS16GBK;ConnectionCharacterSet=ZHS16GBK;DRIVER=/u01/TimesTen/tt1122/lib/libtten.so;PermSize=64;TypeMode=0;
(Default setting AutoCommit=1)
Command> select * from tab;
< 1, Hello              >
1 row found.
Command> exit
Disconnecting...
Done.
[oracle@xifenfei info]$ ttIsql subscriber1
Copyright (c) 1996-2011, Oracle.  All rights reserved.
Type ? or "help" for help, type "exit" to quit ttIsql.
connect "DSN=subscriber1";
Connection successful: DSN=subscriber1;UID=oracle;DataStore=/u01/TimesTen/replicate/subscriber1;DatabaseCharacterSet=ZHS16GBK;ConnectionCharacterSet=ZHS16GBK;DRIVER=/u01/TimesTen/tt1122/lib/libtten.so;PermSize=64;TypeMode=0;
(Default setting AutoCommit=1)
Command> select * from tab;
< 1, Hello              >
1 row found.

Configuring an active standby pair with one subscriber

tempfile真正文件号

1.发现问题
这里看到文件号为201,但是查询了v$datafile和v$tempfile视图都没有文件号为201

SQL> select username,segtype,segfile#,segblk#,extents,segrfno# from v$sort_usage;
USERN SEGTYPE     SEGFILE#    SEGBLK#    EXTENTS   SEGRFNO#
----- --------- ---------- ---------- ---------- ----------
SYS   SORT             201     260745        650          1
SEGFILE#  NUMBER  File number of initial extent
SEGRFNO#   NUMBER  Relative file number of initial extent
SQL> SELECT FILE#,RFILE# FROM V$DATAFILE;
     FILE#     RFILE#
---------- ----------
         1          1
         2          2
         3          3
         4          4
         5          5
         6          6
         7          7
         8          8
         9          9
        10         10
        11         11
     FILE#     RFILE#
---------- ----------
        13         13
        14         14
13 rows selected.
SQL> SELECT FILE#,RFILE# FROM V$TEMPFILE;
     FILE#     RFILE#
---------- ----------
         1          1

2.查看v$sort_usage的原始表

SELECT USERNAME,
       USERNAME,
       KTSSOSES,
       KTSSOSNO,
       PREV_SQL_ADDR,
       PREV_HASH_VALUE,
       PREV_SQL_ID,
       KTSSOTSN,
       DECODE(KTSSOCNT, 0, 'PERMANENT', 1, 'TEMPORARY'),
       DECODE(KTSSOSEGT,
              1,
              'SORT',
              2,
              'HASH',
              3,
              'DATA',
              4,
              'INDEX',
              5,
              'LOB_DATA',
              6,
              'LOB_INDEX',
              'UNDEFINED'),
       KTSSOFNO,
       KTSSOBNO,
       KTSSOEXTS,
       KTSSOBLKS,
       KTSSORFNO
  FROM X$KTSSO, V$SESSION
 WHERE KTSSOSES = V$SESSION.SADDR
   AND KTSSOSNO = V$SESSION.SERIAL#
   and inst_id = USERENV('Instance')

这里没有发现有用信息,只是知道X$KTSSO.KTSSOFNO是v$sort_usage.SEGFILE#,通过v$sort_usage视图是查询临时表空用来排序的数据文件使用情况。所以把问题定位在v$tempfile视图中,检查它为什么没有显示文件号为201的文件

3.查看v$tempfile视图

SELECT TF.TFNUM,
       TO_NUMBER(TF.TFCRC_SCN),
       TO_DATE(TF.TFCRC_TIM,
               'MM/DD/RR HH24:MI:SS',
               'NLS_CALENDAR=Gregorian'),
       TF.TFTSN,
       TF.TFRFN,
       DECODE(BITAND(TF.TFSTA, 2), 0, 'OFFLINE', 2, 'ONLINE', 'UNKNOWN'),
       DECODE(BITAND(TF.TFSTA, 12),
              0,
              'DISABLED',
              4,
              'READ ONLY',
              12,
              'READ WRITE',
              'UNKNOWN'),
       FH.FHTMPFSZ * TF.TFBSZ,
       FH.FHTMPFSZ,
       TF.TFCSZ * TF.TFBSZ,
       TF.TFBSZ,
       FN.FNNAM
  FROM X$KCCTF TF, X$KCCFN FN, X$KCVFHTMP FH
 WHERE FN.FNFNO = TF.TFNUM
   AND FN.FNFNO = FH.HTMPXFIL
   AND TF.TFFNH = FN.FNNUM
   AND TF.TFDUP != 0
   AND BITAND(TF.TFSTA, 32) <> 32
   AND FN.FNTYP = 7
   AND FN.FNNAM IS NOT NULL
   and inst_id = USERENV('Instance')

从这里可以看出v$tempfile.file#出自X$KCCTF.TFNUM

4.继续查看X$KCCTF表

SQL> desc X$KCCTF
 Name                                      Null?    Type
 ----------------------------------------- -------- -------------
 ADDR                                               RAW(8)
 INDX                                               NUMBER
 INST_ID                                            NUMBER
 TFNUM                                              NUMBER
 TFAFN                                              NUMBER
 TFCSZ                                              NUMBER
 TFBSZ                                              NUMBER
 TFSTA                                              NUMBER
 TFCRC_SCN                                          VARCHAR2(16)
 TFCRC_TIM                                          VARCHAR2(20)
 TFFNH                                              NUMBER
 TFFNT                                              NUMBER
 TFDUP                                              NUMBER
 TFTSN                                              NUMBER
 TFTSI                                              NUMBER
 TFRFN                                              NUMBER
 TFPFT                                              NUMBER
 TFMSZ                                              NUMBER
 TFNSZ                                              NUMBER

这里发现一列TFAFN,初步怀疑这个才是真正的绝对文件号。

5.证明X$KCCTF.TFAFN是绝对文件号

SQL> select TFAFN,TFNUM from X$KCCTF;
     TFAFN      TFNUM
---------- ----------
       201          1

如果证明X$KCCTF.TFAFN才是真正的文件号,而TFNUM是临时文件的文件号

6.temp file绝对文件号结论
再进一步可以知道,实际上,为了分离临时文件号和数据文件号,Oracle对临时文件的编号以db_files为起点,所以临时文件的绝对文件号应该等于db_files+file#。

SQL> show parameter db_files;
NAME                                 TYPE        VALUE
------------------------------------ ----------- --------
db_files                             integer     200

记录oracle 9i for linux安装过程中几个错误

最近因为一个测试环境需要oracle 9i,我在Oracle linux 4.8上安装,竟然遇到几个问题记录下:
1.运行runInstaller提示如下错误

[oracle@xifenfei Disk1]$ ./runInstaller
[oracle@xifenfei Disk1]$ Initializing Java Virtual Machine from /tmp/OraInstall2012-03-04_09-32-16PM/jre/bin/java. Please wait...
Error occurred during initialization of VM
Unable to load native library: /tmp/OraInstall2012-03-04_09-32-16PM/jre/lib/i386/libjava.so:
symbol __libc_wait, version GLIBC_2.0 not defined in file libc.so.6 with link time reference

解决方法:打上p3006854_9204_LINUX.zip补丁

[root@xifenfei tmp]$ unzip p3006854_9204_LINUX.zip
Archive:  p3006854_9204_LINUX.zip
   creating: 3006854/
  inflating: 3006854/rhel3_pre_install.sh
  inflating: 3006854/README.txt
[root@xifenfei 3006854]# cd 3006854
[root@xifenfei 3006854]# chmod +x rhel3_pre_install.sh
[root@xifenfei 3006854]# ./rhel3_pre_install.sh
Applying patch...
Ensuring permissions are correctly set...
Done.
Patch successfully applied

2.在Linking Oracle9i到63%时入到如下错误

解决办法:在/usr/bin目录下有gcc 和 gcc32两个文件,执行 mv gcc gcc296 和 mv gcc32 gcc,完成之后,retry安装界面

[root@xifenfei tmp]# cd /usr/bin
[root@xifenfei bin]# ls gcc*
gcc  gcc32  gcc4
[root@xifenfei bin]# mv gcc gcc296
[root@xifenfei bin]# mv gcc32 gcc

3.执行netca/dbca报如下错误

[oracle@xifenfei Disk1]$ dbca
/u01/oracle/jre/1.1.8/bin/../lib/i686/green_threads/libzip.so: symbol errno,
version GLIBC_2.0 not defined in file libc.so.6 with link time reference (libzip.so)
Unable to initialize threads: cannot find class java/lang/Thread
Could not create Java VM
[oracle@xifenfei Disk1]$ netca
/u01/oracle/jre/1.1.8/bin/../lib/i686/native_threads/libzip.so: symbol errno,
version GLIBC_2.0 not defined in file libc.so.6 with link time reference (libzip.so)
Unable to initialize threads: cannot find class java/lang/Thread
Could not create Java VM

解决办法:在环境变量中加上LD_ASSUME_KERNEL=2.4.1

vi .bash_profile --加上下面语句
export LD_ASSUME_KERNEL=2.4.1
source ~/.bash_profile

利用oradebug释放被删除文件空间

在很多时候,检查系统时候发现,由于某个Oracle的trace文件导致磁盘空间告警,因为业务需要不能让数据库down下来。这个时候你想到的方法可能是直接删除掉这个trace文件,如果是win系统,那恭喜你这样做可以解决问题;如果是linux/unix系统,那就等着事故的发生吧。在linux/unix中,如果直接rm掉oracle进程的某个文件(该进程还存在),文件句柄不会释放,即磁盘使用空间不会释放。可以通过df命名看到磁盘的空间释放释放。下面通过对lgwr进程的一系列操作,使用oradebug来释放oracle进程句柄,从而达到释放oracle某个被删除的trace文件的磁盘空间
一、查找lgwr进程的trace文件

[oracle@localhost /]$ cd $ORACLE_BASE/admin/$ORACLE_SID/bdump
[oracle@localhost bdump]$ pwd
/opt/oracle/admin/mcrm/bdump
[oracle@localhost bdump]$ ls -l|grep lgwr
-rw-r----- 1 oracle oinstall 32133 Dec 22 21:00 mcrm_lgwr_3485.trc
-rw-r----- 1 oracle oinstall  3713 Oct  8 07:13 mcrm_lgwr_3489.trc
-rw-r----- 1 oracle oinstall 22507 Mar  3 06:00 mcrm_lgwr_3598.trc
-rw-r----- 1 oracle oinstall  8441 Sep 15 10:29 mcrm_lgwr_4963.trc
[oracle@localhost bdump]$ ps -ef|grep lgwr
oracle    1056 30718  0 21:10 pts/3    00:00:00 grep lgwr
oracle    3598     1  0  2011 ?        00:04:10 ora_lgwr_mcrm
[oracle@localhost bdump]$ df |grep /opt
/dev/sda6             37798668  33312588   2534988  93% /opt
[oracle@localhost bdump]$ du -s .
948     .

从这里得出几点结论:
1.当前lgwr进程的spid为:3598
2.当前lgwr进程产生的trace文件大小为:22507B
3.包含该trace文件的分区大小使用大小为:33312588KB
4.bdump目录大小为:948KB

二、删除lgwr进程对应trace文件

[oracle@localhost bdump]$ rm mcrm_lgwr_3598.trc
[oracle@localhost bdump]$ du -s .
924     .
[oracle@localhost bdump]$ df |grep /opt
/dev/sda6             37798668  33312588   2534988  93% /opt
[oracle@localhost bdump]$ ls -l /proc/3598/fd|grep lgwr
l-wx------ 1 oracle oinstall 64 Mar  3 20:54 2 -> /opt/oracle/admin/mcrm/bdump/mcrm_lgwr_3598.trc (deleted)

从这里得出结论:
1.bdump目录当前大小变为:924KB(大约等于948KB-22507B)
2.包含该trace文件的分区大小使用大小依然为:33312588KB(没有因为删除trace文件而释放空间)

三、释放被删除trace文件空间

[oracle@localhost bdump]$ sqlplus / as sysdba
SQL*Plus: Release 10.2.0.4.0 - Production on Sat Mar 3 21:12:41 2012
Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> !ls -l /proc/3598/fd|grep lgwr
l-wx------ 1 oracle oinstall 64 Mar  3 20:54 2 -> /opt/oracle/admin/mcrm/bdump/mcrm_lgwr_3598.trc (deleted)
SQL>  oradebug setospid 3598
Oracle pid: 6, Unix process pid: 3598, image: oracle@localhost.localdomain (LGWR)
SQL> oradebug flush;
Statement processed.
SQL> oradebug close_trace;
Statement processed.
SQL> !ls -l /proc/3598/fd|grep lgwr
SQL> !df |grep /opt
/dev/sda6             37798668  33312564   2535012  93% /opt
SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

从这里可以得出结论:
1.包含该trace文件的分区大小使用大小为:33312564KB(大约等于948KB-22507B)
2./proc/spid/fd下面的句柄已经释放
3.总这里可以看出使用oradebug可以真正释放oracle进程磁盘使用空间

Getting ORA-01476 during execution of DBMS_STATS.GATHER_SCHEMA_STATS

alert日志

Fri Jan 27 22:00:09 2012
GATHER_STATS_JOB encountered errors.  Check the trace file.
Fri Jan 27 22:00:09 2012
Errors in file /oracle10/admin/ocs/bdump/ocs1_j001_29138.trc:
ORA-01476: divisor is equal to zero

trace内容

Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining
and Real Application Testing options
ORACLE_HOME = /oracle10/app/product/db/10.2.0
System name:    HP-UX
Node name:      ocsdb1
Release:        B.11.23
Version:        U
Machine:        ia64
Instance name: ocs1
Redo thread mounted by this instance: 1
Oracle process number: 60
Unix process pid: 29138, image: oracle@ocsdb1 (J001)
*** ACTION NAME:(GATHER_STATS_JOB) 2012-01-27 22:00:09.308
*** MODULE NAME:(DBMS_SCHEDULER) 2012-01-27 22:00:09.308
*** SERVICE NAME:(SYS$USERS) 2012-01-27 22:00:09.308
*** SESSION ID:(988.31342) 2012-01-27 22:00:09.307
ORA-01476: divisor is equal to zero
*** 2012-01-27 22:00:09.417
GATHER_STATS_JOB: GATHER_TABLE_STATS('"OCS_SM"','"HLP_SMS_SEND"','""', ...)
ORA-01476: divisor is equal to zero

错误原因
oracle unpublished Bug 5645718

解决方法
1.Setting event 38041 at level 16

sql> connect / as sysdba
sql> alter system set events '38041 trace name context forever, level 16';

2.Patch 6319761