Oracle备份恢复 – 第20页

ORA-600 kdsgrp1

在硬件恢复,断电,redo异常等恢复case中ORA-600 [kdsgrp1]是一个比较常见的错误,这里该出来官方关于该错误的解释说明和处理方法

RROR:
  Format: ORA-600 [kdsgrp1]
VERSIONS:
  versions 10.1 and above
DESCRIPTION:
 This error was introduced in 10g with the fix to Bug 2442351, it provides
 for an extra health check on a block, we detected a null row header,
 see Note:2442351.9 for more information.
 Error may be caused by:
 Case 1. A row referenced in an index that does not exist in the table.
 Case 2. An non-existent rowid pointed to by a chained row.
 Trace Examples:
 Case 1. Mismatch between table and index:
====================================================
 Trace file has:
 row 02433566.13 continuation at
 file# 9 block# 210278 slot 20 not found
 The file=9 block=210278 is rdba=0x02433566 which was taken from an index:
 row#3[7549] flag: ------, lock: 0, len=85, data:(6):  02 43 35 66 00 14
 But the slot 20 does not exist in the table block:
 tab 0, row 1, @0x1e62
 tl: 2 fb: --HDFL-- lb: 0x3
 tab 0, row 12, @0x191a
 tl: 2 fb: --HDFL-- lb: 0x1
 tab 0, row 17, @0x1675
 tl: 2 fb: --HDFL-- lb: 0x2
 tab 0, row 21, @0x1459
 tl: 2 fb: --HDFL-- lb: 0x4
 ORA-1499 may be produced by analyze:
 analyze table <table name> validate structure cascade;
 Case 2. A row points to another rowid which does not exist (Chained row does not exist).
============================================================================================
 Trace file has:
 row 1186b11a.ffffffff continuation at
 file# 70 block# 441621 slot 1 not found
 It means that row with rdba 0x1186b11a continues in file# 70 block# 441621 slot 1.
 But the information in file# 70 block# 441621 slot 1 does not exist.  It is:
 tab 0, row 16, @0xd7f    ---> This is the slot with the problem.
 tl: 29 fb: -------- lb: 0x0  cc: 11
 nrid:  0x1186bd15.1      ---> It points to rdba=0x1186bd15 slot 1
(file# 70 block# 441621 slot 1) but that row does not exist in that block.
 For this case ANALYZE TABLE .. VALIDATE STRUCTURE is not detecting this logical corruption
Referece Bug 6858313
Run an export (exp) or Full Table Scan to identify if there is a permanent invalid chained row.
 Workaround for Case 2:
 The row producing the ORA-600 [kdsgrp1] can be skipped by setting the Event 10231
 Note that a testcase has concluded that event 10231 does not skip rows in an Index Organized Table (IOT)
 when there is an invalid nrid as explained in Case 2.  It only works for regular tables.
 Event 43810 skip corrupt block in IOT?s (10.2.0.4)
nor  parameter _index_scan_check_skip_corrupt (11g) work for this case 2 on IOTs either.
FUNCTIONALITY:
  Kernel Data layer Seek/Scan
IMPACT:
  PROCESS FAILURE
  POSSIBLE PHYSICAL CORRUPTION

ORA-600 2663

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：ORA-600 2663

在大家熟悉的ORA-600 2662错误中还有一个类似的ORA-600 2663的错误,以下是对该2663的解释说明

ERROR:
  Format: ORA-600 [2663] [a] [b] {c} [d]
VERSIONS:
  versions 10.1 to 11.1
DESCRIPTION:
  A data block SCN is ahead of the current SCN.
  The ORA-600 [2663] occurs when an SCN is compared to the dependent SCN
  stored in a UGA variable.
  If the SCN is less than the dependent SCN then we signal the ORA-600 [2663]
  internal error.
ARGUMENTS:
  Arg [a]  Current SCN WRAP
  Arg [b]  Current SCN BASE
  Arg {c}  dependent SCN WRAP
  Arg [d]  dependent SCN BASE
FUNCTIONALITY:
  Kernel Cache Redo File Redo Generation
IMPACT:
  INSTANCE FAILURE
  POSSIBLE PHYSICAL CORRUPTION
SUGGESTIONS:
  There are different situations where ORA-600 [2663] can be raised.
  It can be raised on startup or duing database operation.
  If not using RAC, Real Application Clusters,, check that 2 instances
  have not mounted the same database.
  Check for SMON traces and have the alert.log and trace files ready
  to send to support.
  Check the SCN difference [argument d]-[argument b].
  If the SCNs in the error are very close, then try to shutdown and startup
  the instance several times.
  In some situations, the SCN increment during startup may permit the
  database to open. Keep track of the number of times you attempted a
  startup.

ORA-600 2662

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：ORA-600 2662

在数据库恢复中,ORA-600 2662我想是很多人都非常熟悉的错误,下文是对于该错误的一些解释
ORA-600 2662解释说明

ERROR:
  Format: ORA-600 [2662] [a] [b] {c} [d] [e]
VERSIONS:
  versions 6.0 to 12.1
DESCRIPTION:
  A data block SCN is ahead of the current SCN.
  The ORA-600 [2662] occurs when an SCN is compared to the dependent SCN
  stored in a UGA variable.
  If the SCN is less than the dependent SCN then we signal the ORA-600 [2662]
  internal error.
ARGUMENTS:
  Arg [a]  Current SCN WRAP
  Arg [b]  Current SCN BASE
  Arg {c}  dependent SCN WRAP
  Arg [d]  dependent SCN BASE
  Arg [e]  Where present this is the DBA where the dependent SCN came from.

出现ORA-600 2662可能的原因

  (1) doing an open resetlogs with _ALLOW_RESETLOGS_CORRUPTION enabled
  (2) a hardware problem, like a faulty controller, resulting in a failed
      write to the control file or the redo logs
  (3) restoring parts of the database from backup and not doing the
      appropriate recovery
  (4) restoring a control file and not doing a RECOVER DATABASE USING BACKUP
      CONTROLFILE
  (5) having _DISABLE_LOGGING set during crash recovery
  (6) problems with the DLM in a parallel server environment
  (7) a bug

ORA-600 2662解决方法

   (1) if the SCNs in the error are very close, attempting a startup several
       times will bump up the dscn every time we open the database even if
       open fails. The database will open when dscn=scn.
   (2)You can bump the SCN either on open or while the database is open
      using Event:ADJUST_SCN
      Be aware that you should rebuild the database if you use this
      option.

ORA-600 999 异常恢复

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：ORA-600 999 异常恢复

有网友数据库启动报ORA-600 999错误,无法正常open,让我们介入分析,帮忙恢复其中部分数据
数据库启动报ORA-600 999

Sun Jul 31 23:09:36 2016
SMON: enabling cache recovery
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is ZHS16GBK
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_smon_3356.trc  (incident=179779):
ORA-00600: internal error code, arguments: [999], [0x7FFAE748013], [], [], [], [], [], [], [], [], [], []
Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_179779\orcl_smon_3356_i179779.trc
No Resource Manager plan active
Starting background process QMNC
Sun Jul 31 23:09:37 2016
QMNC started with pid=20, OS id=5068
ORACLE Instance orcl (pid = 13) - Error 600 encountered while recovering transaction (7, 1).
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_smon_3356.trc:
ORA-00600: internal error code, arguments: [999], [0x7FFAE748013], [], [], [], [], [], [], [], [], [], []
Completed: alter database open
Sun Jul 31 23:09:38 2016
db_recovery_file_dest_size of 8680 MB is 0.00% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Trace dumping is performing id=[cdmp_20160731230939]
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_smon_3356.trc  (incident=179785):
ORA-00600: internal error code, arguments: [999], [0x7FFAE748013], [], [], [], [], [], [], [], [], [], []
ORACLE Instance orcl (pid = 13) - Error 600 encountered while recovering transaction (7, 1).
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_smon_3356.trc:
ORA-00600: internal error code, arguments: [999], [0x7FFAE748013], [], [], [], [], [], [], [], [], [], []
Sun Jul 31 23:09:41 2016
Starting background process CJQ0
Sun Jul 31 23:09:41 2016
CJQ0 started with pid=25, OS id=2572
Process debug not enabled via parameter _debug_enable
Trace dumping is performing id=[cdmp_20160731230942]
PMON (ospid: 3948): terminating the instance due to error 474
Sun Jul 31 23:09:48 2016
opiodr aborting process unknown ospid (2592) as a result of ORA-1092
Sun Jul 31 23:09:48 2016
ORA-1092 : opitsk aborting process
Sun Jul 31 23:09:52 2016
Instance terminated by PMON, pid = 3948

设置_offline_rollback_segments数据库启动正常

Sun Jul 31 23:18:13 2016
ALTER DATABASE OPEN
Thread 1 opened at log sequence 16
  Current log# 1 seq# 16 mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO01.LOG
Successful open of redo thread 1
SMON: enabling cache recovery
Successfully onlined Undo Tablespace 5.
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is ZHS16GBK
No Resource Manager plan active
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_smon_4372.trc  (incident=182188):
ORA-00600: internal error code, arguments: [kdBlkCheckError], [3], [224], [38508], [], [], [], [], [], [], [], []
Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_182188\orcl_smon_4372_i182188.trc
Doing block recovery for file 3 block 224
Resuming block recovery (PMON) for file 3 block 224
Block recovery from logseq 16, block 2945 to scn 15431544
Recovery of Online Redo Log: Thread 1 Group 1 Seq 16 Reading mem 0
  Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO01.LOG
Trace dumping is performing id=[cdmp_20160731231815]
Block recovery stopped at EOT rba 16.2952.16
Block recovery completed at rba 16.2952.16, scn 0.15431543
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_smon_4372.trc:
ORA-00607: Internal error occurred while making a change to a data block
ORA-00600: internal error code, arguments: [kdBlkCheckError], [3], [224], [38508], [], [], [], [], [], [], [], []
Sun Jul 31 23:18:19 2016
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_smon_4372.trc  (incident=182189):
ORA-00600: internal error code, arguments: [kdBlkCheckError], [3], [224], [38508], [], [], [], [], [], [], [], []
Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_182189\orcl_smon_4372_i182189.trc
Starting background process QMNC
Sun Jul 31 23:18:19 2016
QMNC started with pid=20, OS id=4920
Doing block recovery for file 3 block 224
Resuming block recovery (PMON) for file 3 block 224
Block recovery from logseq 16, block 2945 to scn 15431544
Recovery of Online Redo Log: Thread 1 Group 1 Seq 16 Reading mem 0
  Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO01.LOG
Block recovery completed at rba 16.2952.16, scn 0.15431545
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_smon_4372.trc:
ORA-00607: Internal error occurred while making a change to a data block
ORA-00600: internal error code, arguments: [kdBlkCheckError], [3], [224], [38508], [], [], [], [], [], [], [], []
Starting background process SMCO
Sun Jul 31 23:18:19 2016
SMCO started with pid=21, OS id=3176
Sun Jul 31 23:18:20 2016
Trace dumping is performing id=[cdmp_20160731231820]
Completed: ALTER DATABASE OPEN

尝试删除异常回滚段

Sun Jul 31 23:15:07 2016
drop rollback segment "_SYSSMU7_1101470402$"
Sun Jul 31 23:15:07 2016
Corrupt Block Found
         TSN = 2, TSNAME = UNDOTBS1
         RFN = 3, BLK = 224, RDBA = 12583136
         OBJN = -1, OBJD = -1, OBJECT = , SUBOBJECT =
         SEGMENT OWNER = , SEGMENT TYPE =
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_5300.trc  (incident=181035):
ORA-00600: 内部错误代码, 参数: [kdBlkCheckError], [3], [224], [38508], [], [], [], [], [], [], [], []
Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_181035\orcl_ora_5300_i181035.trc
Doing block recovery for file 3 block 224
Resuming block recovery (PMON) for file 3 block 224
Block recovery from logseq 14, block 8682 to scn 15397854
Recovery of Online Redo Log: Thread 1 Group 2 Seq 14 Reading mem 0
  Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO02.LOG
Block recovery completed at rba 14.8688.16, scn 0.15397855
ORA-607 signalled during: drop rollback segment "_SYSSMU7_1101470402$"...
Corrupt Block Found
         TSN = 2, TSNAME = UNDOTBS1
         RFN = 3, BLK = 224, RDBA = 12583136
         OBJN = -1, OBJD = -1, OBJECT = , SUBOBJECT =
         SEGMENT OWNER = , SEGMENT TYPE =

从这里看,我们可以确定file 3 block 224异常,导致删除回滚段异常.和mos官方给出来的案例类似,由于undo坏块导致数据库报ORA-600 999错误

mos中ORA-600 999报错信息
官方的益处ORA-600[999]报错,也是由于undo坏块引起和本文的报错基本上一致
ORA-600-999

因为只要部分数据,直接屏蔽回滚段,数据库不再crash,导出需要对象即可

_ALLOW_RESETLOGS_CORRUPTION

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：_ALLOW_RESETLOGS_CORRUPTION

我相信_ALLOW_RESETLOGS_CORRUPTION 这个参数一定很多人都熟悉,是redo异常恢复的杀手锏之一,以下文章是来自官方的解释

DB_Parameter _ALLOW_RESETLOGS_CORRUPTION
========================================
This documentation has been prepared avoiding the mention of the complex
structures from the code and to simply give an insight to the 'damage it could
cause'.  The usage of this parameter leads to an in-consistent Database with no
other alternative but to rebuild the complete Database.  This parameter could
be used when we realize that there are no stardard options available and are
convinced that the customer understands the implications of using the Oracle's
secret parameter.  The factors to be considered are ;--
1. Customer does not have a good backup.
2. A lot of time and money has been invested after the last good backup and
   there is no possibility for reproduction of the lost data.
3. The customer has to be ready to export the full database and import it
   back after creating a new one.
4. There is no 100% guarantee that by using this parameter the database would
   come up.
5. Oracle does not support the database after using this parameter for
   recovery.
6. ALL OPTIONS including the ones mentioned in the action part of the error
   message have been tried.
By setting _ALLOW_RESETLOGS_CORRUPTION=TRUE, certain consistency checks are
SKIPPED during database open stage.  This basically means it does not check
the datafile headers as to what the status was before the shutdown and how it
was shutdown.  The following cases mention few of the checks that were skipped.
Case-I
------
Verification that the datafile present has not been restored from a BACKUP
taken before the database was opened successfully by using RESETLOGS.
ORA-01190: control file or data file %s is from before the last RESETLOGS
    Cause: Attempting to use a data file when the log reset information in
           the file does not match the control file.  Either the data file or
           the control file is a backup that was made before the most recent
           ALTER DATABASE OPEN RESETLOGS.
   Action: Restore file from a more recent backup.
Case-II
-------
Verification that the status bit of the datafile is not in a FUZZY state.
The datafile could be in this state due to the database going down when the
 - Datafile was on-line and open
 - Datafile was not closed cleanly (maybe due to OS).
ORA-01194: file %s needs more recovery to be consistent
    Cause: An incomplete recover session was started, but an insufficient
           number of logs were applied to make the file consistent.  The
           reported file was not closed cleanly when it was last opened by
           the database.  It must be recovered to a time when it was not
           being updated.  The most likely cause of this error is forgetting
           to restore the file from a backup before doing incomplete
           recovery.
   Action: Either apply more logs until the file is consistent or restore the
           file from an older backup and repeat recovery.
Case-III
--------
Verification that the COMPLETE recover strategies have been applied for
recovering the datafile and not any of the INCOMPLETE recovery options.
Basically because the complete recovery is one in which we even apply the
ON-LINE redo log files and open the DB without reseting the logs.
ORA-01113: file '%s' needs media recovery starting at log sequence # %s
    Cause: An attempt was made to open a database file that is in need of
           media recovery.
   Action: First apply media recovery to the file.
Case-IV
-------
Verification that the datafile has been recovered through an END BACKUP if the
control file indicates that it was in backup mode.
This is useful when the DB has crashed while in hot backup mode and we lost
all log files in DB version's less than V7.2.
ORA-01195: on-line backup of file %s needs more recovery to be consistent"
    Cause: An incomplete recovery session was started, but an insufficient
           number of logs were applied to make the file consistent.  The
           reported file is an on-line backup which must be recovered to the
           time the backup ended.
   Action: Either apply more logs until the file is consistent or resotre
          the database files from an older backup and repeat recovery.
In version 7.2, we could simply issue the ALTER DATABASE DATAFILE xxxx END
BACKUP statement and proceed with the recovery.  But again to issue this
statement, we need to have the ON-LINE redo logs or else we still are forced to
use this parameter.
Case-V
------
Verification that the data file status is not still in (0x10) MEDIA recovery
FUZZY.
When recovery is started, a flag is set in the datafile header status flag to
indicate that the file is presently in media recovery.  This is reset when
recovery is completed and at times when it has not been reset we are forced to
use this paramter.
ORA-01196: file %s is inconsistent due to a failed media recovery session
    Cause: The file was being recovered but the recovery did not terminate
           normally.  This left the file in an inconsistent state.  No more
           recovery was successfully completed on this file.
   Action: Either apply more logs until the file is consistent or restore the
           backup again and repeat recovery.
Case-VI
-------
Verification that the datafile has been restored form a proper backup to
correspond with the log files.  This situation could happen when we have
decided that the data file is invalid since its SCN is ahead of the last
applied logs SCN but it has not failed on one of the ABOVE CHECKS.
ORA-01152: file '%s' was not restored from a sufficientluy old backup"
    Cause: A manual recovery session was started, but an insufficient number
           of logs were applied to make the database consistent.  This file is
           still in the future of the last log applied.  Note that this
           mistake can not always be caught.
   Action: Either apply more logs until the database is consistent or
           restore the database file from an older backup and repeat
           recovery.

使用_ALLOW_RESETLOGS_CORRUPTION 参数需谨慎,因为该参数可能导致数据库逻辑不一致,甚至可能把本来很简单的一个恢复弄的非常复杂甚至不可恢复的后果,建议在oracle support支持下使用.另外使用该参数resetlogs库之后,强烈建议通过逻辑方式重建库

数据库恢复的敏感性—重建控制文件使用不合适数据文件

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：数据库恢复的敏感性—重建控制文件使用不合适数据文件

有客户数据库由于某种原因无法open,请求我们技术支持.通过检查alert日志发现数据库是由于ORA-600 kccpb_sanity_check_2错误.并且他们已经重建控制文件,通过我们的Oracle数据库异常恢复检查脚本(Oracle Database Recovery Check)
datafile 6 异常
wrong-file1

wrong-file-redo

通过这里我们发现datafile 6 数据文件头是干净的,而且对应的redo seq为5270,而其他文件头都是fuzzy,而且对应的redo为295902613.这里怀疑datafile 6 可能是错误的.当然对于这样scn相距比较大的情况,我们可以通过隐含参数,修改scn等方法强制让该库起来(或者该文件online),但是从现在看到的情况,文件很可能异常,这样强制恢复,可能没有实际意义.
分析alert日志
alert-log

这个里面可以发现是先删除了sde表空间,然后创建了同一个表空间,只是数据文件路径不一样了.而且正好在seq为5270的地方操作的.现在出现datafile 6异常的原因已经清楚,就是创建数据控制文件的时候,使用了错误的数据文件导致.

完美恢复数据库

D:\>sqlplus / as sysdba
SQL*Plus: Release 10.2.0.1.0 - Production on 星期六 7月 30 16:31:01 2016
Copyright (c) 1982, 2005, Oracle.  All rights reserved.
连接到:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options
SQL> shutdown immediate;
ORA-01109: 数据库未打开
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> STARTUP NOMOUNT
ORACLE 例程已经启动。
Total System Global Area 5133828096 bytes
Fixed Size                  2011360 bytes
Variable Size            2382368544 bytes
Database Buffers         2734686208 bytes
Redo Buffers               14761984 bytes
SQL> CREATE CONTROLFILE REUSE DATABASE "LANDDB" NORESETLOGS  ARCHIVELOG
  2      MAXLOGFILES 16
  3      MAXLOGMEMBERS 3
  4      MAXDATAFILES 100
  5      MAXINSTANCES 8
  6      MAXLOGHISTORY 292
  7  LOGFILE
  8    GROUP 1 'F:\ORADATA\LANDDB\ONLINELOG\O1_MF_1_4JCM05KL_.LOG'  SIZE 50M,
  9    GROUP 2 'F:\ORADATA\LANDDB\ONLINELOG\O1_MF_2_4JCM064D_.LOG'  SIZE 50M,
 10    GROUP 3 'F:\ORADATA\LANDDB\ONLINELOG\O1_MF_3_4JCM06PG_.LOG'  SIZE 50M
 11  DATAFILE
 12    'F:\ORADATA\LANDDB\DATAFILE\O1_MF_SYSTEM_4JCLYY6T_.DBF',
 13    'F:\ORADATA\LANDDB\DATAFILE\O1_MF_UNDOTBS1_4JCLYY8S_.DBF',
 14    'F:\ORADATA\LANDDB\DATAFILE\O1_MF_SYSAUX_4JCLYY7B_.DBF',
 15    'F:\ORADATA\LANDDB\DATAFILE\O1_MF_USERS_4JCLYY98_.DBF',
 16    'F:\ORADATA\LANDDB\DATAFILE\FUJIAN',
 17    'D:\data\sde.dbf'
 18  CHARACTER SET ZHS16GBK
 19  ;
控制文件已创建。
SQL> recover database;
完成介质恢复。
SQL> alter database open;
数据库已更改。
SQL>

这个库比较幸运,客户发现异常之后,里面停止了有风险性的操作(比如使用_allow_resetlogs_corruption参数,resetlogs库等),使得数据完美恢复0丢失.如果条件允许最好使用老的控制文件来重建新控制文件,而不要通过人工去系统中找数据文件来实现恢复,这样很可能有遗落或者使用错误的数据文件

kfed找出来asm 磁盘组中数据文件别名对应的文件号—amdu恢复

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：kfed找出来asm 磁盘组中数据文件别名对应的文件号—amdu恢复

前段时间有多个朋友问我,在amdu中,如果数据文件命名不是omf的方式,该如何找出来数据文件的asm file_number,从而实现通过amdu对不能mount的磁盘组中的数据文件进行恢复,这里通过测试给出来处理方法.根据我们对asm的理解,asm file_number 6为asm file的别名文件记录所在地,我们通过分析kfed这些au中的记录即可获得相关数据文件的别名对应的asm文件号

模拟各种别名

D:\app\product\10.2.0\db_1\bin>sqlplus / as sysdba
SQL*Plus: Release 10.2.0.3.0 - Production on 星期三 7月 27 22:48:48 2016
Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.
连接到:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production
With the Partitioning, OLAP and Data Mining options
SQL> select name from v$datafile;
NAME
--------------------------------------------------------------------------------
+DATA/ora10g/datafile/system.256.914797317
+DATA/ora10g/datafile/undotbs1.258.914797317
+DATA/ora10g/datafile/sysaux.257.914797317
+DATA/ora10g/datafile/users.259.914797317
SQL> create tablespace xifenfei
  2  datafile '+data/xifenfei01.dbf' size 10M;
表空间已创建。
SQL> alter tablespace xifenfei add
  2  datafile '+data/ora10g/datafile/xifenfei02.dbf' size 10m;
表空间已更改。
SQL> alter tablespace xifenfei add
  2  datafile '+data/ora10g/xifenfei03.dbf' size 10m;
表空间已更改。
SQL> select name from v$datafile;
NAME
--------------------------------------------------------------------------------
+DATA/ora10g/datafile/system.256.914797317
+DATA/ora10g/datafile/undotbs1.258.914797317
+DATA/ora10g/datafile/sysaux.257.914797317
+DATA/ora10g/datafile/users.259.914797317
+DATA/xifenfei01.dbf
+DATA/ora10g/datafile/xifenfei02.dbf
+DATA/ora10g/xifenfei03.dbf
已选择7行。

分析磁盘组和别名信息

SQL> select name from v$asm_disk;
NAME
------------------------------
DATA_0000
DATA_0001
SQL> select path from v$asm_disk;
PATH
-----------------------------------------
H:\ASMDISK\ASMDISK1.DD
H:\ASMDISK\ASMDISK2.DD
SQL> SELECT NAME,FILE_NUMBER FROM V$ASM_ALIAS where file_number<>4294967295;
NAME                           FILE_NUMBER
------------------------------ -----------
SYSTEM.256.914797317                   256
SYSAUX.257.914797317                   257
UNDOTBS1.258.914797317                 258
USERS.259.914797317                    259
XIFENFEI.266.918341361                 266
XIFENFEI.267.918341389                 267
xifenfei02.dbf                         267
XIFENFEI.268.918341409                 268
Current.260.914797381                  260
group_1.261.914797385                  261
group_2.262.914797385                  262
group_3.263.914797387                  263
TEMP.264.914797393                     264
spfile.265.914797421                   265
spfileora10g.ora                       265
xifenfei03.dbf                         268
xifenfei01.dbf                         266
已选择17行。
SQL> SELECT NAME,FILE_NUMBER FROM V$ASM_ALIAS;
NAME                           FILE_NUMBER
------------------------------ -----------
ORA10G                          4294967295
DATAFILE                        4294967295
SYSTEM.256.914797317                   256
SYSAUX.257.914797317                   257
UNDOTBS1.258.914797317                 258
USERS.259.914797317                    259
XIFENFEI.266.918341361                 266
XIFENFEI.267.918341389                 267
xifenfei02.dbf                         267
XIFENFEI.268.918341409                 268
CONTROLFILE                     4294967295
Current.260.914797381                  260
ONLINELOG                       4294967295
group_1.261.914797385                  261
group_2.262.914797385                  262
group_3.263.914797387                  263
TEMPFILE                        4294967295
TEMP.264.914797393                     264
PARAMETERFILE                   4294967295
spfile.265.914797421                   265
spfileora10g.ora                       265
xifenfei03.dbf                         268
xifenfei01.dbf                         266
已选择23行。

从sql查询,我们可以确定xifenfei0n.dbf对应的文件号分别为:xifenfei01.dbf==>266,xifenfei02.dbf==>267,xifenfei03.dbf==>268

通过kfed file 6所在位置

www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD |grep f1b1
kfdhdb.f1b1locn:                      2 ; 0x0d4: 0x00000002
kfdhdb.f1b1fcn.base:                  0 ; 0x100: 0x00000000
kfdhdb.f1b1fcn.wrap:                  0 ; 0x104: 0x00000000
www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD aun=2 blkn=6|grep kfffde|more
kfffde[0].xptr.au:                   26 ; 0x4a0: 0x0000001a
kfffde[0].xptr.disk:                  0 ; 0x4a4: 0x0000
kfffde[0].xptr.flags:                 0 ; 0x4a6: L=0 E=0 D=0 S=0
kfffde[0].xptr.chk:                  48 ; 0x4a7: 0x30
kfffde[1].xptr.au:           4294967295 ; 0x4a8: 0xffffffff
kfffde[1].xptr.disk:              65535 ; 0x4ac: 0xffff

从这里我们可以确定别名的au只有一个位于disk 0, au 26(0x1a)的位置
通过kfed分析别名

www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD aun=26 |more
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                           11 ; 0x002: KFBTYP_ALIASDIR
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                       0 ; 0x004: blk=0
kfbh.block.obj:                       6 ; 0x008: file=6
kfbh.check:                  1563703526 ; 0x00c: 0x5d3438e6
kfbh.fcn.base:                     3461 ; 0x010: 0x00000d85
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kffdnd.bnode.incarn:                  1 ; 0x000: A=1 NUMM=0x0
kffdnd.bnode.frlist.number:  4294967295 ; 0x004: 0xffffffff
kffdnd.bnode.frlist.incarn:           0 ; 0x008: A=0 NUMM=0x0
kffdnd.overfl.number:        4294967295 ; 0x00c: 0xffffffff
kffdnd.overfl.incarn:                 0 ; 0x010: A=0 NUMM=0x0
kffdnd.parent.number:                 0 ; 0x014: 0x00000000
kffdnd.parent.incarn:                 1 ; 0x018: A=1 NUMM=0x0
kffdnd.fstblk.number:                 0 ; 0x01c: 0x00000000
kffdnd.fstblk.incarn:                 1 ; 0x020: A=1 NUMM=0x0
kfade[0].entry.incarn:                1 ; 0x024: A=1 NUMM=0x0
kfade[0].entry.hash:         2080305534 ; 0x028: 0x7bfef17e
kfade[0].entry.refer.number:          1 ; 0x02c: 0x00000001
kfade[0].entry.refer.incarn:          1 ; 0x030: A=1 NUMM=0x0
kfade[0].name:                   ORA10G ; 0x034: length=6
kfade[0].fnum:               4294967295 ; 0x064: 0xffffffff
kfade[0].finc:               4294967295 ; 0x068: 0xffffffff
kfade[0].flags:                       4 ; 0x06c: U=0 S=0 S=1 U=0 F=0
kfade[0].ub1spare:                    0 ; 0x06d: 0x00
kfade[0].freeblock:                   0 ; 0x06e: 0x0000
kfade[1].entry.incarn:                1 ; 0x070: A=1 NUMM=0x0
kfade[1].entry.hash:         3085841201 ; 0x074: 0xb7ee3331
kfade[1].entry.refer.number: 4294967295 ; 0x078: 0xffffffff
kfade[1].entry.refer.incarn:          0 ; 0x07c: A=0 NUMM=0x0
kfade[1].name:           xifenfei01.dbf ; 0x080: length=14
kfade[1].fnum:                      266 ; 0x0b0: 0x0000010a
kfade[1].finc:                918341361 ; 0x0b4: 0x36bcc6f1
kfade[1].flags:                      17 ; 0x0b8: U=1 S=0 S=0 U=0 F=1
kfade[1].ub1spare:                    0 ; 0x0b9: 0x00
kfade[1].freeblock:                   0 ; 0x0ba: 0x0000
kfade[2].entry.incarn:                0 ; 0x0bc: A=0 NUMM=0x0
kfade[2].entry.hash:                  0 ; 0x0c0: 0x00000000
kfade[2].entry.refer.number:          0 ; 0x0c4: 0x00000000
kfade[2].entry.refer.incarn:          0 ; 0x0c8: A=0 NUMM=0x0
kfade[2].name:                          ; 0x0cc: length=0
kfade[2].fnum:                        0 ; 0x0fc: 0x00000000
kfade[2].finc:                        0 ; 0x100: 0x00000000
kfade[2].flags:                       0 ; 0x104: U=0 S=0 S=0 U=0 F=0
kfade[2].ub1spare:                    0 ; 0x105: 0x00
kfade[2].freeblock:                   0 ; 0x106: 0x0000
www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD aun=26 |grep name
kfade[0].name:                   ORA10G ; 0x034: length=6
kfade[1].name:           xifenfei01.dbf ; 0x080: length=14
kfade[2].name:                          ; 0x0cc: length=0
kfade[3].name:                          ; 0x118: length=0
kfade[4].name:                          ; 0x164: length=0
www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD aun=26 blkn=1|more
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                           11 ; 0x002: KFBTYP_ALIASDIR
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                       1 ; 0x004: blk=1
kfbh.block.obj:                       6 ; 0x008: file=6
kfbh.check:                   239000469 ; 0x00c: 0x0e3edb95
kfbh.fcn.base:                     3536 ; 0x010: 0x00000dd0
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kffdnd.bnode.incarn:                  1 ; 0x000: A=1 NUMM=0x0
kffdnd.bnode.frlist.number:  4294967295 ; 0x004: 0xffffffff
kffdnd.bnode.frlist.incarn:           0 ; 0x008: A=0 NUMM=0x0
kffdnd.overfl.number:        4294967295 ; 0x00c: 0xffffffff
kffdnd.overfl.incarn:                 0 ; 0x010: A=0 NUMM=0x0
kffdnd.parent.number:                 0 ; 0x014: 0x00000000
kffdnd.parent.incarn:                 1 ; 0x018: A=1 NUMM=0x0
kffdnd.fstblk.number:                 1 ; 0x01c: 0x00000001
kffdnd.fstblk.incarn:                 1 ; 0x020: A=1 NUMM=0x0
kfade[0].entry.incarn:                1 ; 0x024: A=1 NUMM=0x0
kfade[0].entry.hash:          710518681 ; 0x028: 0x2a59a799
kfade[0].entry.refer.number:          2 ; 0x02c: 0x00000002
kfade[0].entry.refer.incarn:          1 ; 0x030: A=1 NUMM=0x0
kfade[0].name:                 DATAFILE ; 0x034: length=8
kfade[0].fnum:               4294967295 ; 0x064: 0xffffffff
kfade[0].finc:               4294967295 ; 0x068: 0xffffffff
kfade[0].flags:                       4 ; 0x06c: U=0 S=0 S=1 U=0 F=0
kfade[0].ub1spare:                    0 ; 0x06d: 0x00
kfade[0].freeblock:                   0 ; 0x06e: 0x0000
kfade[1].entry.incarn:                3 ; 0x070: A=1 NUMM=0x1
kfade[1].entry.hash:         4053320104 ; 0x074: 0xf198c1a8
kfade[1].entry.refer.number:          3 ; 0x078: 0x00000003
kfade[1].entry.refer.incarn:          3 ; 0x07c: A=1 NUMM=0x1
kfade[1].name:              CONTROLFILE ; 0x080: length=11
kfade[1].fnum:               4294967295 ; 0x0b0: 0xffffffff
kfade[1].finc:               4294967295 ; 0x0b4: 0xffffffff
kfade[1].flags:                       4 ; 0x0b8: U=0 S=0 S=1 U=0 F=0
kfade[1].ub1spare:                    0 ; 0x0b9: 0x00
kfade[1].freeblock:                   0 ; 0x0ba: 0x0000
kfade[2].entry.incarn:                1 ; 0x0bc: A=1 NUMM=0x0
kfade[2].entry.hash:         2803485489 ; 0x0c0: 0xa719cb31
kfade[2].entry.refer.number:          4 ; 0x0c4: 0x00000004
kfade[2].entry.refer.incarn:          1 ; 0x0c8: A=1 NUMM=0x0
kfade[2].name:                ONLINELOG ; 0x0cc: length=9
kfade[2].fnum:               4294967295 ; 0x0fc: 0xffffffff
kfade[2].finc:               4294967295 ; 0x100: 0xffffffff
kfade[2].flags:                       4 ; 0x104: U=0 S=0 S=1 U=0 F=0
kfade[2].ub1spare:                    0 ; 0x105: 0x00
kfade[2].freeblock:                   0 ; 0x106: 0x0000
kfade[3].entry.incarn:                1 ; 0x108: A=1 NUMM=0x0
kfade[3].entry.hash:         2905271101 ; 0x10c: 0xad2aeb3d
kfade[3].entry.refer.number:          5 ; 0x110: 0x00000005
kfade[3].entry.refer.incarn:          1 ; 0x114: A=1 NUMM=0x0
kfade[3].name:                 TEMPFILE ; 0x118: length=8
kfade[3].fnum:               4294967295 ; 0x148: 0xffffffff
kfade[3].finc:               4294967295 ; 0x14c: 0xffffffff
kfade[3].flags:                       4 ; 0x150: U=0 S=0 S=1 U=0 F=0
kfade[3].ub1spare:                    0 ; 0x151: 0x00
kfade[3].freeblock:                   0 ; 0x152: 0x0000
kfade[4].entry.incarn:                1 ; 0x154: A=1 NUMM=0x0
kfade[4].entry.hash:         3261836913 ; 0x158: 0xc26bae71
kfade[4].entry.refer.number:          6 ; 0x15c: 0x00000006
kfade[4].entry.refer.incarn:          1 ; 0x160: A=1 NUMM=0x0
kfade[4].name:            PARAMETERFILE ; 0x164: length=13
kfade[4].fnum:               4294967295 ; 0x194: 0xffffffff
kfade[4].finc:               4294967295 ; 0x198: 0xffffffff
kfade[4].flags:                       4 ; 0x19c: U=0 S=0 S=1 U=0 F=0
kfade[4].ub1spare:                    0 ; 0x19d: 0x00
kfade[4].freeblock:                   0 ; 0x19e: 0x0000
kfade[5].entry.incarn:                1 ; 0x1a0: A=1 NUMM=0x0
kfade[5].entry.hash:         3373604202 ; 0x1a4: 0xc9151d6a
kfade[5].entry.refer.number: 4294967295 ; 0x1a8: 0xffffffff
kfade[5].entry.refer.incarn:          0 ; 0x1ac: A=0 NUMM=0x0
kfade[5].name:         spfileora10g.ora ; 0x1b0: length=16
kfade[5].fnum:                      265 ; 0x1e0: 0x00000109
kfade[5].finc:                914797421 ; 0x1e4: 0x3686b36d
kfade[5].flags:                      17 ; 0x1e8: U=1 S=0 S=0 U=0 F=1
kfade[5].ub1spare:                    0 ; 0x1e9: 0x00
kfade[5].freeblock:                   0 ; 0x1ea: 0x0000
kfade[6].entry.incarn:                1 ; 0x1ec: A=1 NUMM=0x0
kfade[6].entry.hash:         3992241470 ; 0x1f0: 0xedf4c53e
kfade[6].entry.refer.number: 4294967295 ; 0x1f4: 0xffffffff
kfade[6].entry.refer.incarn:          0 ; 0x1f8: A=0 NUMM=0x0
kfade[6].name:           xifenfei03.dbf ; 0x1fc: length=14
kfade[6].fnum:                      268 ; 0x22c: 0x0000010c
kfade[6].finc:                918341409 ; 0x230: 0x36bcc721
kfade[6].flags:                      17 ; 0x234: U=1 S=0 S=0 U=0 F=1
kfade[6].ub1spare:                    0 ; 0x235: 0x00
kfade[6].freeblock:                   0 ; 0x236: 0x0000
kfade[7].entry.incarn:                0 ; 0x238: A=0 NUMM=0x0
kfade[7].entry.hash:                  0 ; 0x23c: 0x00000000
kfade[7].entry.refer.number:          0 ; 0x240: 0x00000000
kfade[7].entry.refer.incarn:          0 ; 0x244: A=0 NUMM=0x0
kfade[7].name:                          ; 0x248: length=0
kfade[7].fnum:                        0 ; 0x278: 0x00000000
kfade[7].finc:                        0 ; 0x27c: 0x00000000
kfade[7].flags:                       0 ; 0x280: U=0 S=0 S=0 U=0 F=0
kfade[7].ub1spare:                    0 ; 0x281: 0x00
kfade[7].freeblock:                   0 ; 0x282: 0x0000
www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD aun=26 blkn=1|grep name
kfade[0].name:                 DATAFILE ; 0x034: length=8
kfade[1].name:              CONTROLFILE ; 0x080: length=11
kfade[2].name:                ONLINELOG ; 0x0cc: length=9
kfade[3].name:                 TEMPFILE ; 0x118: length=8
kfade[4].name:            PARAMETERFILE ; 0x164: length=13
kfade[5].name:         spfileora10g.ora ; 0x1b0: length=16
kfade[6].name:           xifenfei03.dbf ; 0x1fc: length=14
kfade[7].name:                          ; 0x248: length=0
kfade[8].name:                          ; 0x294: length=0
www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD aun=26 blkn=2
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                           11 ; 0x002: KFBTYP_ALIASDIR
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                       2 ; 0x004: blk=2
kfbh.block.obj:                       6 ; 0x008: file=6
kfbh.check:                  3937052433 ; 0x00c: 0xeaaaa711
kfbh.fcn.base:                     3535 ; 0x010: 0x00000dcf
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kffdnd.bnode.incarn:                  1 ; 0x000: A=1 NUMM=0x0
kffdnd.bnode.frlist.number:  4294967295 ; 0x004: 0xffffffff
kffdnd.bnode.frlist.incarn:           0 ; 0x008: A=0 NUMM=0x0
kffdnd.overfl.number:        4294967295 ; 0x00c: 0xffffffff
kffdnd.overfl.incarn:                 0 ; 0x010: A=0 NUMM=0x0
kffdnd.parent.number:                 1 ; 0x014: 0x00000001
kffdnd.parent.incarn:                 1 ; 0x018: A=1 NUMM=0x0
kffdnd.fstblk.number:                 2 ; 0x01c: 0x00000002
kffdnd.fstblk.incarn:                 1 ; 0x020: A=1 NUMM=0x0
kfade[0].entry.incarn:                1 ; 0x024: A=1 NUMM=0x0
kfade[0].entry.hash:         1410293950 ; 0x028: 0x540f60be
kfade[0].entry.refer.number: 4294967295 ; 0x02c: 0xffffffff
kfade[0].entry.refer.incarn:          0 ; 0x030: A=0 NUMM=0x0
kfade[0].name:                   SYSTEM ; 0x034: length=6
kfade[0].fnum:                      256 ; 0x064: 0x00000100
kfade[0].finc:                914797317 ; 0x068: 0x3686b305
kfade[0].flags:                      18 ; 0x06c: U=0 S=1 S=0 U=0 F=1
kfade[0].ub1spare:                    0 ; 0x06d: 0x00
kfade[0].freeblock:                   0 ; 0x06e: 0x0000
kfade[1].entry.incarn:                1 ; 0x070: A=1 NUMM=0x0
kfade[1].entry.hash:         1052386617 ; 0x074: 0x3eba2539
kfade[1].entry.refer.number: 4294967295 ; 0x078: 0xffffffff
kfade[1].entry.refer.incarn:          0 ; 0x07c: A=0 NUMM=0x0
kfade[1].name:                   SYSAUX ; 0x080: length=6
kfade[1].fnum:                      257 ; 0x0b0: 0x00000101
kfade[1].finc:                914797317 ; 0x0b4: 0x3686b305
kfade[1].flags:                      18 ; 0x0b8: U=0 S=1 S=0 U=0 F=1
kfade[1].ub1spare:                    0 ; 0x0b9: 0x00
kfade[1].freeblock:                   0 ; 0x0ba: 0x0000
kfade[2].entry.incarn:                1 ; 0x0bc: A=1 NUMM=0x0
kfade[2].entry.hash:         2341166852 ; 0x0c0: 0x8b8b5f04
kfade[2].entry.refer.number: 4294967295 ; 0x0c4: 0xffffffff
kfade[2].entry.refer.incarn:          0 ; 0x0c8: A=0 NUMM=0x0
kfade[2].name:                 UNDOTBS1 ; 0x0cc: length=8
kfade[2].fnum:                      258 ; 0x0fc: 0x00000102
kfade[2].finc:                914797317 ; 0x100: 0x3686b305
kfade[2].flags:                      18 ; 0x104: U=0 S=1 S=0 U=0 F=1
kfade[2].ub1spare:                    0 ; 0x105: 0x00
kfade[2].freeblock:                   0 ; 0x106: 0x0000
kfade[3].entry.incarn:                1 ; 0x108: A=1 NUMM=0x0
kfade[3].entry.hash:           18985629 ; 0x10c: 0x0121b29d
kfade[3].entry.refer.number: 4294967295 ; 0x110: 0xffffffff
kfade[3].entry.refer.incarn:          0 ; 0x114: A=0 NUMM=0x0
kfade[3].name:                    USERS ; 0x118: length=5
kfade[3].fnum:                      259 ; 0x148: 0x00000103
kfade[3].finc:                914797317 ; 0x14c: 0x3686b305
kfade[3].flags:                      18 ; 0x150: U=0 S=1 S=0 U=0 F=1
kfade[3].ub1spare:                    0 ; 0x151: 0x00
kfade[3].freeblock:                   0 ; 0x152: 0x0000
kfade[4].entry.incarn:                1 ; 0x154: A=1 NUMM=0x0
kfade[4].entry.hash:          379856949 ; 0x158: 0x16a42835
kfade[4].entry.refer.number: 4294967295 ; 0x15c: 0xffffffff
kfade[4].entry.refer.incarn:          0 ; 0x160: A=0 NUMM=0x0
kfade[4].name:                 XIFENFEI ; 0x164: length=8
kfade[4].fnum:                      266 ; 0x194: 0x0000010a
kfade[4].finc:                918341361 ; 0x198: 0x36bcc6f1
kfade[4].flags:                      18 ; 0x19c: U=0 S=1 S=0 U=0 F=1
kfade[4].ub1spare:                    0 ; 0x19d: 0x00
kfade[4].freeblock:                   0 ; 0x19e: 0x0000
kfade[5].entry.incarn:                1 ; 0x1a0: A=1 NUMM=0x0
kfade[5].entry.hash:          889929475 ; 0x1a4: 0x350b3f03
kfade[5].entry.refer.number: 4294967295 ; 0x1a8: 0xffffffff
kfade[5].entry.refer.incarn:          0 ; 0x1ac: A=0 NUMM=0x0
kfade[5].name:                 XIFENFEI ; 0x1b0: length=8
kfade[5].fnum:                      267 ; 0x1e0: 0x0000010b
kfade[5].finc:                918341389 ; 0x1e4: 0x36bcc70d
kfade[5].flags:                      18 ; 0x1e8: U=0 S=1 S=0 U=0 F=1
kfade[5].ub1spare:                    0 ; 0x1e9: 0x00
kfade[5].freeblock:                   0 ; 0x1ea: 0x0000
kfade[6].entry.incarn:                1 ; 0x1ec: A=1 NUMM=0x0
kfade[6].entry.hash:         3416790953 ; 0x1f0: 0xcba817a9
kfade[6].entry.refer.number: 4294967295 ; 0x1f4: 0xffffffff
kfade[6].entry.refer.incarn:          0 ; 0x1f8: A=0 NUMM=0x0
kfade[6].name:           xifenfei02.dbf ; 0x1fc: length=14
kfade[6].fnum:                      267 ; 0x22c: 0x0000010b
kfade[6].finc:                918341389 ; 0x230: 0x36bcc70d
kfade[6].flags:                      17 ; 0x234: U=1 S=0 S=0 U=0 F=1
kfade[6].ub1spare:                    0 ; 0x235: 0x00
kfade[6].freeblock:                   0 ; 0x236: 0x0000
kfade[7].entry.incarn:                1 ; 0x238: A=1 NUMM=0x0
kfade[7].entry.hash:         3200622536 ; 0x23c: 0xbec59fc8
kfade[7].entry.refer.number: 4294967295 ; 0x240: 0xffffffff
kfade[7].entry.refer.incarn:          0 ; 0x244: A=0 NUMM=0x0
kfade[7].name:                 XIFENFEI ; 0x248: length=8
kfade[7].fnum:                      268 ; 0x278: 0x0000010c
kfade[7].finc:                918341409 ; 0x27c: 0x36bcc721
kfade[7].flags:                      18 ; 0x280: U=0 S=1 S=0 U=0 F=1
kfade[7].ub1spare:                    0 ; 0x281: 0x00
kfade[7].freeblock:                   0 ; 0x282: 0x0000
www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD aun=26 blkn=2|grep name
kfade[0].name:                   SYSTEM ; 0x034: length=6
kfade[1].name:                   SYSAUX ; 0x080: length=6
kfade[2].name:                 UNDOTBS1 ; 0x0cc: length=8
kfade[3].name:                    USERS ; 0x118: length=5
kfade[4].name:                 XIFENFEI ; 0x164: length=8
kfade[5].name:                 XIFENFEI ; 0x1b0: length=8
kfade[6].name:           xifenfei02.dbf ; 0x1fc: length=14
kfade[7].name:                 XIFENFEI ; 0x248: length=8
kfade[8].name:                          ; 0x294: length=0
www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD aun=26 blkn=3
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                           11 ; 0x002: KFBTYP_ALIASDIR
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                       3 ; 0x004: blk=3
kfbh.block.obj:                       6 ; 0x008: file=6
kfbh.check:                   362685464 ; 0x00c: 0x159e2418
kfbh.fcn.base:                     1938 ; 0x010: 0x00000792
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kffdnd.bnode.incarn:                  3 ; 0x000: A=1 NUMM=0x1
kffdnd.bnode.frlist.number:  4294967295 ; 0x004: 0xffffffff
kffdnd.bnode.frlist.incarn:           0 ; 0x008: A=0 NUMM=0x0
kffdnd.overfl.number:        4294967295 ; 0x00c: 0xffffffff
kffdnd.overfl.incarn:                 0 ; 0x010: A=0 NUMM=0x0
kffdnd.parent.number:                 1 ; 0x014: 0x00000001
kffdnd.parent.incarn:                 1 ; 0x018: A=1 NUMM=0x0
kffdnd.fstblk.number:                 3 ; 0x01c: 0x00000003
kffdnd.fstblk.incarn:                 3 ; 0x020: A=1 NUMM=0x1
kfade[0].entry.incarn:                3 ; 0x024: A=1 NUMM=0x1
kfade[0].entry.hash:         2951411460 ; 0x028: 0xafeaf704
kfade[0].entry.refer.number: 4294967295 ; 0x02c: 0xffffffff
kfade[0].entry.refer.incarn:          0 ; 0x030: A=0 NUMM=0x0
kfade[0].name:                  Current ; 0x034: length=7
kfade[0].fnum:                      260 ; 0x064: 0x00000104
kfade[0].finc:                914797381 ; 0x068: 0x3686b345
kfade[0].flags:                      18 ; 0x06c: U=0 S=1 S=0 U=0 F=1
kfade[0].ub1spare:                    0 ; 0x06d: 0x00
kfade[0].freeblock:                   0 ; 0x06e: 0x0000
kfade[1].entry.incarn:                0 ; 0x070: A=0 NUMM=0x0
kfade[1].entry.hash:                  0 ; 0x074: 0x00000000
kfade[1].entry.refer.number:          0 ; 0x078: 0x00000000
kfade[1].entry.refer.incarn:          0 ; 0x07c: A=0 NUMM=0x0
kfade[1].name:                          ; 0x080: length=0
kfade[1].fnum:                        0 ; 0x0b0: 0x00000000
kfade[1].finc:                        0 ; 0x0b4: 0x00000000
kfade[1].flags:                       0 ; 0x0b8: U=0 S=0 S=0 U=0 F=0
kfade[1].ub1spare:                    0 ; 0x0b9: 0x00
kfade[1].freeblock:                   0 ; 0x0ba: 0x0000
www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD aun=26 blkn=3|grep name
kfade[0].name:                  Current ; 0x034: length=7
kfade[1].name:                          ; 0x080: length=0
kfade[2].name:                          ; 0x0cc: length=0
kfade[3].name:                          ; 0x118: length=0
kfade[4].name:                          ; 0x164: length=0
www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD aun=26 blkn=4|more
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                           11 ; 0x002: KFBTYP_ALIASDIR
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                       4 ; 0x004: blk=4
kfbh.block.obj:                       6 ; 0x008: file=6
kfbh.check:                  3581479529 ; 0x00c: 0xd5790a69
kfbh.fcn.base:                     2167 ; 0x010: 0x00000877
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kffdnd.bnode.incarn:                  1 ; 0x000: A=1 NUMM=0x0
kffdnd.bnode.frlist.number:  4294967295 ; 0x004: 0xffffffff
kffdnd.bnode.frlist.incarn:           0 ; 0x008: A=0 NUMM=0x0
kffdnd.overfl.number:        4294967295 ; 0x00c: 0xffffffff
kffdnd.overfl.incarn:                 0 ; 0x010: A=0 NUMM=0x0
kffdnd.parent.number:                 1 ; 0x014: 0x00000001
kffdnd.parent.incarn:                 1 ; 0x018: A=1 NUMM=0x0
kffdnd.fstblk.number:                 4 ; 0x01c: 0x00000004
kffdnd.fstblk.incarn:                 1 ; 0x020: A=1 NUMM=0x0
kfade[0].entry.incarn:                1 ; 0x024: A=1 NUMM=0x0
kfade[0].entry.hash:         1017821950 ; 0x028: 0x3caabafe
kfade[0].entry.refer.number: 4294967295 ; 0x02c: 0xffffffff
kfade[0].entry.refer.incarn:          0 ; 0x030: A=0 NUMM=0x0
kfade[0].name:                  group_1 ; 0x034: length=7
kfade[0].fnum:                      261 ; 0x064: 0x00000105
kfade[0].finc:                914797385 ; 0x068: 0x3686b349
kfade[0].flags:                      18 ; 0x06c: U=0 S=1 S=0 U=0 F=1
kfade[0].ub1spare:                    0 ; 0x06d: 0x00
kfade[0].freeblock:                   0 ; 0x06e: 0x0000
kfade[1].entry.incarn:                1 ; 0x070: A=1 NUMM=0x0
kfade[1].entry.hash:         1570256801 ; 0x074: 0x5d9837a1
kfade[1].entry.refer.number: 4294967295 ; 0x078: 0xffffffff
kfade[1].entry.refer.incarn:          0 ; 0x07c: A=0 NUMM=0x0
kfade[1].name:                  group_2 ; 0x080: length=7
kfade[1].fnum:                      262 ; 0x0b0: 0x00000106
kfade[1].finc:                914797385 ; 0x0b4: 0x3686b349
kfade[1].flags:                      18 ; 0x0b8: U=0 S=1 S=0 U=0 F=1
kfade[1].ub1spare:                    0 ; 0x0b9: 0x00
kfade[1].freeblock:                   0 ; 0x0ba: 0x0000
kfade[2].entry.incarn:                1 ; 0x0bc: A=1 NUMM=0x0
kfade[2].entry.hash:          157707762 ; 0x0c0: 0x09666df2
kfade[2].entry.refer.number: 4294967295 ; 0x0c4: 0xffffffff
kfade[2].entry.refer.incarn:          0 ; 0x0c8: A=0 NUMM=0x0
kfade[2].name:                  group_3 ; 0x0cc: length=7
kfade[2].fnum:                      263 ; 0x0fc: 0x00000107
kfade[2].finc:                914797387 ; 0x100: 0x3686b34b
kfade[2].flags:                      18 ; 0x104: U=0 S=1 S=0 U=0 F=1
kfade[2].ub1spare:                    0 ; 0x105: 0x00
kfade[2].freeblock:                   0 ; 0x106: 0x0000
kfade[3].entry.incarn:                0 ; 0x108: A=0 NUMM=0x0
kfade[3].entry.hash:                  0 ; 0x10c: 0x00000000
kfade[3].entry.refer.number:          0 ; 0x110: 0x00000000
kfade[3].entry.refer.incarn:          0 ; 0x114: A=0 NUMM=0x0
kfade[3].name:                          ; 0x118: length=0
kfade[3].fnum:                        0 ; 0x148: 0x00000000
kfade[3].finc:                        0 ; 0x14c: 0x00000000
kfade[3].flags:                       0 ; 0x150: U=0 S=0 S=0 U=0 F=0
kfade[3].ub1spare:                    0 ; 0x151: 0x00
kfade[3].freeblock:                   0 ; 0x152: 0x0000
www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD aun=26 blkn=4|grep name
kfade[0].name:                  group_1 ; 0x034: length=7
kfade[1].name:                  group_2 ; 0x080: length=7
kfade[2].name:                  group_3 ; 0x0cc: length=7
kfade[3].name:                          ; 0x118: length=0
kfade[4].name:                          ; 0x164: length=0
kfade[5].name:                          ; 0x1b0: length=0
kfade[6].name:                          ; 0x1fc: length=0
www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD aun=26 blkn=5|more
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                           11 ; 0x002: KFBTYP_ALIASDIR
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                       5 ; 0x004: blk=5
kfbh.block.obj:                       6 ; 0x008: file=6
kfbh.check:                  1153372471 ; 0x00c: 0x44bf1137
kfbh.fcn.base:                     2212 ; 0x010: 0x000008a4
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kffdnd.bnode.incarn:                  1 ; 0x000: A=1 NUMM=0x0
kffdnd.bnode.frlist.number:  4294967295 ; 0x004: 0xffffffff
kffdnd.bnode.frlist.incarn:           0 ; 0x008: A=0 NUMM=0x0
kffdnd.overfl.number:        4294967295 ; 0x00c: 0xffffffff
kffdnd.overfl.incarn:                 0 ; 0x010: A=0 NUMM=0x0
kffdnd.parent.number:                 1 ; 0x014: 0x00000001
kffdnd.parent.incarn:                 1 ; 0x018: A=1 NUMM=0x0
kffdnd.fstblk.number:                 5 ; 0x01c: 0x00000005
kffdnd.fstblk.incarn:                 1 ; 0x020: A=1 NUMM=0x0
kfade[0].entry.incarn:                1 ; 0x024: A=1 NUMM=0x0
kfade[0].entry.hash:         3699413877 ; 0x028: 0xdc809375
kfade[0].entry.refer.number: 4294967295 ; 0x02c: 0xffffffff
kfade[0].entry.refer.incarn:          0 ; 0x030: A=0 NUMM=0x0
kfade[0].name:                     TEMP ; 0x034: length=4
kfade[0].fnum:                      264 ; 0x064: 0x00000108
kfade[0].finc:                914797393 ; 0x068: 0x3686b351
kfade[0].flags:                      18 ; 0x06c: U=0 S=1 S=0 U=0 F=1
kfade[0].ub1spare:                    0 ; 0x06d: 0x00
kfade[0].freeblock:                   0 ; 0x06e: 0x0000
kfade[1].entry.incarn:                0 ; 0x070: A=0 NUMM=0x0
kfade[1].entry.hash:                  0 ; 0x074: 0x00000000
kfade[1].entry.refer.number:          0 ; 0x078: 0x00000000
kfade[1].entry.refer.incarn:          0 ; 0x07c: A=0 NUMM=0x0
kfade[1].name:                          ; 0x080: length=0
kfade[1].fnum:                        0 ; 0x0b0: 0x00000000
kfade[1].finc:                        0 ; 0x0b4: 0x00000000
kfade[1].flags:                       0 ; 0x0b8: U=0 S=0 S=0 U=0 F=0
kfade[1].ub1spare:                    0 ; 0x0b9: 0x00
kfade[1].freeblock:                   0 ; 0x0ba: 0x0000
www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD aun=26 blkn=5|grep name
kfade[0].name:                     TEMP ; 0x034: length=4
kfade[1].name:                          ; 0x080: length=0
kfade[2].name:                          ; 0x0cc: length=0
kfade[3].name:                          ; 0x118: length=0
kfade[4].name:                          ; 0x164: length=0
www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD aun=26 blkn=6|more
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                           11 ; 0x002: KFBTYP_ALIASDIR
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                       6 ; 0x004: blk=6
kfbh.block.obj:                       6 ; 0x008: file=6
kfbh.check:                  1230193442 ; 0x00c: 0x49534322
kfbh.fcn.base:                     2267 ; 0x010: 0x000008db
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kffdnd.bnode.incarn:                  1 ; 0x000: A=1 NUMM=0x0
kffdnd.bnode.frlist.number:  4294967295 ; 0x004: 0xffffffff
kffdnd.bnode.frlist.incarn:           0 ; 0x008: A=0 NUMM=0x0
kffdnd.overfl.number:        4294967295 ; 0x00c: 0xffffffff
kffdnd.overfl.incarn:                 0 ; 0x010: A=0 NUMM=0x0
kffdnd.parent.number:                 1 ; 0x014: 0x00000001
kffdnd.parent.incarn:                 1 ; 0x018: A=1 NUMM=0x0
kffdnd.fstblk.number:                 6 ; 0x01c: 0x00000006
kffdnd.fstblk.incarn:                 1 ; 0x020: A=1 NUMM=0x0
kfade[0].entry.incarn:                1 ; 0x024: A=1 NUMM=0x0
kfade[0].entry.hash:         3897004393 ; 0x028: 0xe8479169
kfade[0].entry.refer.number: 4294967295 ; 0x02c: 0xffffffff
kfade[0].entry.refer.incarn:          0 ; 0x030: A=0 NUMM=0x0
kfade[0].name:                   spfile ; 0x034: length=6
kfade[0].fnum:                      265 ; 0x064: 0x00000109
kfade[0].finc:                914797421 ; 0x068: 0x3686b36d
kfade[0].flags:                      18 ; 0x06c: U=0 S=1 S=0 U=0 F=1
kfade[0].ub1spare:                    0 ; 0x06d: 0x00
kfade[0].freeblock:                   0 ; 0x06e: 0x0000
kfade[1].entry.incarn:                0 ; 0x070: A=0 NUMM=0x0
kfade[1].entry.hash:                  0 ; 0x074: 0x00000000
kfade[1].entry.refer.number:          0 ; 0x078: 0x00000000
kfade[1].entry.refer.incarn:          0 ; 0x07c: A=0 NUMM=0x0
kfade[1].name:                          ; 0x080: length=0
kfade[1].fnum:                        0 ; 0x0b0: 0x00000000
kfade[1].finc:                        0 ; 0x0b4: 0x00000000
kfade[1].flags:                       0 ; 0x0b8: U=0 S=0 S=0 U=0 F=0
kfade[1].ub1spare:                    0 ; 0x0b9: 0x00
kfade[1].freeblock:                   0 ; 0x0ba: 0x0000
www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD aun=26 blkn=6|grep name
kfade[0].name:                   spfile ; 0x034: length=6
kfade[1].name:                          ; 0x080: length=0
kfade[2].name:                          ; 0x0cc: length=0
kfade[3].name:                          ; 0x118: length=0
kfade[4].name:                          ; 0x164: length=0
www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD aun=26 blkn=7|grep name
kfade[0].name:                          ; 0x034: length=0
kfade[1].name:                          ; 0x080: length=0
kfade[2].name:                          ; 0x0cc: length=0
kfade[3].name:                          ; 0x118: length=0
kfade[4].name:                          ; 0x164: length=0
kfade[5].name:                          ; 0x1b0: length=0
kfade[6].name:                          ; 0x1fc: length=0

通过上述分析我们发现目前数据主要分布在au=26,block in(0-6)的几个block中,通过kfed已经找出来了所有的asm中文件的file_number

非win平台脚本实现

for (( i=0; i<255; i++ ))
do
   kfed read H:\ASMDISK\ASMDISK1.DD aun=26 blknum=$i
  \|egrep 'name|fnum'|grep -v length=0 |grep -v 0x00000000 >>asm_file.out
done

注意需要按照file 6的au依次处理,否则会不全,更加简单的方法,直接通过dul扫描磁盘获取相关file number

_OFFLINE_ROLLBACK_SEGMENTS/_CORRUPTED_ROLLBACK_SEGMENTS

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：_OFFLINE_ROLLBACK_SEGMENTS/_CORRUPTED_ROLLBACK_SEGMENTS

对于oracle undo异常的时候恢复中,经常需要使用的_OFFLINE_ROLLBACK_SEGMENTS和_CORRUPTED_ROLLBACK_SEGMENTS参数,关于这两个参数的区别进行说明
_OFFLINE_ROLLBACK_SEGMENTS 参数说明

_CORRUPTED_ROLLBACK_SEGMENTS 参数说明

_OFFLINE_ROLLBACK_SEGMENTS 和 _CORRUPTED_ROLLBACK_SEGMENTS 区别
offline_corrupted

这两个参数属于oracle隐含参数,在没有oracle support的情况下,请慎用.该相关参数可能导致数据库逻辑不一致风险,如果使用了,建议逻辑方式导出导入库

ORA-600 4193 错误说明和解决

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：ORA-600 4193 错误说明和解决

ORA-600 4193 解释说明

ERROR:
  Format: ORA-600 [4193] [a] [b]
VERSIONS:
  versions 6.0 to 12.1
DESCRIPTION:
  A mismatch has been detected between Redo records and Rollback (Undo)
  records.
  We are validating the Undo block sequence number in the undo block against
  the Redo block sequence number relating to the change being applied.
  This error is reported when this validation fails.
ARGUMENTS:
  Arg [a] Undo record seq number
  Arg [b] Redo record seq number
FUNCTIONALITY:
  KERNEL TRANSACTION UNDO
ORA-600 [4193] [a] [b] [ ] [ ]  [ ]
Versions: 7.2.2  - 9.2.0                              Source: ktuc.c
===========================================================================
Meaning: seq# mismatch while adding an undo record to an undo block. This
         is done by the application of redo.
---------------------------------------------------------------------------
Argument Description:
    a. (ktubhseq): undo record seq# - this is the seq# of the block that
                                      this undo record WILL BE APPLIED TO.
                                      This is from the Undo Block. It is
                                      NOT the seq# of the undo block itself.
    b. (ktudbseq): redo RECORD seq# - this is the seq# number in the block
                                      that this redo WILL BE APPLIED TO.
                                      This is from the Redo Record.
---------------------------------------------------------------------------
Diagnosis:
    This error is raised in kturdb which handles the adding of undo records
    by the application of redo.
    When we try to apply redo to an undo block (forward changes are made by
    the application of redo to a block) we check that the seq# in the undo
    record matches the seq# in the redo record. These seq# should be the
    same because when we apply a redo record we must apply it to the
    correct version of the block. We can only apply a redo record to a
    block that contains the same seq# as in the redo record.
    If the seq# do not match then this error is raised. This implies some
    kind of block corruption in either the redo or the undo block.
7.3.x - 8.1.7.x
ASSERT2(ubh->ktubhseq == db->ktudbseq, OERI(4193), KSESVSGN,
            ubh->ktubhseq, db->ktudbseq);
9.2.x
ksesic2(OERI(4193), ksenrg(ubh->ktubhseq), ksenrg(db->ktudbseq));
struct ktubh
{
  kxid  ktubhxid;      /* txid of tx currently using or last used this block */
  ub2   ktubhseq;                              /* undo block sequence number */
  ub1   ktubhcnt;    /* high water mark record index, number of undo entries */
  ub1   ktubhirb;  /* rollback record index, rec index to start the rollback */
  ub1   ktubhicl;  /* collecting record index, rec index to start retrieving col info */
  ub1   ktubhflg;                                                 /* dummy */
  ub2   ktubhidx[1];     /* byte offset of record in block, grows at runtime */
};
struct ktudb   Kernel Transaction Undo Data operation Block (redo)
{
  ub2    ktudbsiz;                                          /* size of entry */
  ub2    ktudbspc;                 /* verification: space left in undo block */
  ub2    ktudbflg;            /* flag to indicate the kind of redo operation */
  kxid   ktudbxid;                                          /* current tx id */
  ub2    ktudbseq;                                  /* block sequence number */
  ub1    ktudbrec;                       /* new record index for this change */
};

ORA 600 4193 处理方法同How to resolve ORA-600 [4194] errors

How to resolve ORA-600 [4194] errors

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：How to resolve ORA-600 [4194] errors

在oracle恢复中ORA-600 4194是一个非常常见的错误,该错误的主要原因是由于redo记录和undo(rollback)记录不匹配.
ORA 600 4194错误原因以及含义

ERROR:
  Format: ORA-600 [4194] [a] [b]
VERSIONS:
  versions 6.0 to 12.1
DESCRIPTION:
  A mismatch has been detected between Redo records and rollback (Undo)
  records.
  We are validating the Undo record number relating to the change being
  applied against the maximum undo record number recorded in the undo block.
  This error is reported when the validation fails.
ARGUMENTS:
  Arg [a] Maximum Undo record number in Undo block
  Arg [b] Undo record number from Redo block

ORA 600 4194 错误处理思路
第一步

Confirm whether the database is up and running or not.  If the database fails to start or crashes shortly
after startup due to this error occurring, then try setting event 10513 at level 2 in the init.ora/spfile
to disable transaction recovery and restart the instance, e.g.:
      event = "10513 trace name context forever, level 2"
This may allow the database to successfully open and stay up so that
the required diagnostics/actions can be performed.

第二步

In the trace file there should be an undo segment header dump, and so check
to see if the undo segment header shows an active transaction after recovery, e.g.:
TRN TBL    <---- Represents the Transaction table for the particular undo segment
index state cflags wrap# uel scn dba
---------------------------------------------------------------------------------------------
0x41 9 0x80 0x35ab6 0xffff 0x0695.38f6b959 0x1081e796
0x42 9 0x80 0x35bb1 0x000e 0x0695.38f6b028 0x1081e793
0x43 9 0x80 0x35b11 0x005d 0x0695.38f6b7ae 0x1081e795
0x44 9 0x80 0x359f0 0x0036 0x0695.38f69a91 0x1081e78e
0x45 10 0x80 0x35b1b 0x0000 0x0695.3a0aba4d 0x1081e796
0x46 9 0x80 0x35bb7 0x001c 0x0695.38f69bde 0x1081e78f
===================================
State ---> This column specifies the status of the transaction
                  9 -----> represents a commited transaction
                  10 ---> Represents a active transaction
Dba -----> Undo block containing the undo records
                  Strictly speaking this is the block at the end of the undo chain.
You can see from the transaction table that there is an active transaction
for this particular rollback/undo segment after recovery.
Therefore this rollback/undo segment and/or undo tablespace cannot be dropped without corrupting the database!
Therefore recreating the UNDO tablespace is not an option.

第三步

From the trace file determine the affected undo segment, e.g.:
Block image after block recovery:
UNDO BLK:
xid: 0x0015.02b.0001544b seq: 0x163e cnt: 0x12 irb: 0x12 icl: 0x0 flg: 0x0000
XID ==> Undo segment no + Slot no + Sequence no
Therefore, in this case the Undo Segment is:
USN# 0x15 (Hex) ==> 21 (Dec)  ==> _SYSSMU21$
So if and ONLY IF the transaction table shows no active transaction can the
 rollback/undo segment be offlined and dropped.Note however,
that before you can confirm if the entire UNDO tablespace can be dropped, you would need to check the
transaction tables of ALL active rollback/undo segments in the same wasy as the above.
The steps required to drop the rollback/undo segment are fully detailed in Note:179952.1,
but are briefly listed here for completeness:
If using Automatic Undo Management
Offline the undo segment using the _OFFLINE_ROLLBACK_SEGMENTS parameter and bounce the database as follows:
1.  Create  and edit the init.ora file for the instance to set the following parameters:
UNDO_MANAGEMENT=MANUAL
_OFFLINE_ROLLBACK_SEGMENTS=(_SYSSMU21$)
2.  Open the database in restricted mode to prevent user access, e.g.:
connect / as sysdba
startup restrict pfile = '<Full path to init.ora file>';
3.  Drop the rollback/undo segment, e.g.:
drop rollback segment "_SYSSMU21";
4.  Shutdown the instance, and remove the init.ora parameters added in point 1 and restart the instance, e.g.:
shutdown immediate
startup
If SMON was recovering the transaction then this may not work as we cannot open the database if it is determined
to be in an inconsistent state. I have reviewed a number of SRs where this approach was successful,
so it is important to try it first but understand that it may fail and you will have to resort to
a point in time recovery or forcing open the DB and recreating it.

第四步

Now we need to dump the undo block to see which object was affected.
We noted in Step 2 that this is the active transaction (from the trace file):
TRN TBL
index state cflags wrap# uel scn dba
0x45 10 0x80 0x35b1b 0x0000 0x0695.3a0aba4d 0x1081e796
Dba----------------> Undo block containing the undo records
dba--->0x1081e796 is the block containing the active transaction .
Use the WebIV tools to convert this RDBA to block number (block#) and file number (file#), e.g.:
V SPLIT ==> DBA (Hex) = File#,Block# (Hex File#,Block#)
= ===== === ===== ============
V8 10,10 ==> 276948886 (0x1081e796) = 66,124822 (0x42 0x1e796)
So the file# is 66 and the block# is 124822, so dump the block by issuing:
SQL> Alter system dump datafile 66 block 124822;
This will generate a trace file in the user_dump_dest.  The following is a sample of the information in the undo block:
UNDO BLK:
xid: 0x000c.045.00035b1b seq: 0x1e14 cnt: 0x17 irb: 0x17 icl: 0x0 flg: 0x0000
Rec Offset Rec Offset Rec Offset Rec Offset Rec Offset
---------------------------------------------------------------------------
0x01 0x1f8c 0x02 0x1f30 0x03 0x1ed4 0x04 0x1e78 0x05 0x1e1c
0x06 0x1dc0 0x07 0x1d64 0x08 0x1d08 0x09 0x1cac 0x0a 0x1c50
0x0b 0x1bf4 0x0c 0x1b98 0x0d 0x1b3c 0x0e 0x1ae0 0x0f 0x1a74
0x10 0x1a18 0x11 0x19bc 0x12 0x1960 0x13 0x1904 0x14 0x187c
0x15 0x181c 0x16 0x1798 0x17 0x173c
* Rec #0x16 slt: 0x45 objn: 1485619(0x0016ab33) objd: 1485619 tblspc: 71(0x00000047)
* Layer: 11 (Row) opc: 1 rci 0x00
Undo type: Regular undo Begin trans Last buffer split: No
Temp Object: No
Tablespace Undo: No
rdba: 0x00000000
*-----------------------------
uba: 0x1081e796.1e14.14 ctl max scn: 0x0695.38f69853 prv tx scn: 0x0695.38f698a1
KDO undo record:
KTB Redo
op: 0x04 ver: 0x01
op: L itl: scn: 0x0019.009.00034237 uba: 0x36c0cce4.1d2f.19
flg: C--- lkc: 0 scn: 0x0695.38f6b96b
KDO Op code: URP xtype: XA bdba: 0x35406893 hdba: 0x35406892
itli: 1 ispac: 0 maxfr: 4863
tabn: 0 slot: 0(0x0) flag: 0x2c lock: 0 ckix: 0
ncol: 1 nnew: 1 size: -1
col 0: [ 4] c3 0e 36 2e
*-----------------------------
* Rec #0x17 slt: 0x45 objn: 1485619(0x0016ab33) objd: 1485619 tblspc: 71(0x00000047)
* Layer: 11 (Row) opc: 1 rci 0x16
Undo type: Regular undo Last buffer split: No
Temp Object: No
Tablespace Undo: No
rdba: 0x00000000
*-----------------------------
From the trace file above:
UNDO BLK:
xid: 0x000c.045.00035b1b seq: 0x1e14 cnt: 0x17 irb: 0x17 icl: 0x0 flg: 0x0000
The undo segment with the active transaction is segment is 0x000c (Hex) which is 12 (Dec) as the XID is:
      Undo segment no + Slot no + Sequence no
This step is often skipped because it was performed earlier in step 3, however it is a good idea to do this
again now to make sure that the XID from the UNDO block matches the UNDO SEGMENT HEADER,
this way you have followed all the chain, from the UNDO SEGMENT to UNDO BLOCK, back and forth.
If there is a conflict here please check and make sure that the customer dumped the correct undo block.
Check for the value of irb which is an index which points you to the latest change done to the undo block.
This is the point from which a rollback would begin if one was issued.
From the trace file we see: 'irb: 0x17' so this points to record 0x17,
so search for this particular string i.e 0x17 and it will take you to undo record 'REC #0x17', e.g.:
* Rec #0x17 slt: 0x45 objn: 1485619(0x0016ab33) objd: 1485619 tblspc: 71(0x00000047)
* Layer: 11 (Row) opc: 1 rci 0x16
Undo type: Regular undo Last buffer split: No
Temp Object: No
Tablespace Undo: No
rdba: 0x00000000
*-----------------------------
Note the slot number (slt) is 0x45, the object number (objn) is the OBJECT_ID from dba_objects
and data object number (objd) is the DATA_OBJECT_ID from dba_objects.
These numbers may be the same but not necessarily, and so if the database is open then identify this object, e.g.:
        select object_name, owner, object_type, data_object_id from dba_objects where object_id = <objn>;
This is the object, which has an active transaction.  Note in the above trace file extract that rci
has a value of 0x16 which means that this record is at the end of an undo chain.
This means that the chain continues in another UNDO BLOCK.
Please refer to unpublished Note:281504.1 for information on Undo chains.
So the next record that needs to be rolled back is present in REC #X016.
If rci is 0x00 then it means that this is the first record present in the undo chain
and so you can check to see if there is rdba info, e.g.:
* Rec #0x16 slt: 0x45 objn: 1485619(0x0016ab33) objd: 1485619 tblspc: 71(0x00000047)
* Layer: 11 (Row) opc: 1 rci 0x00
Undo type: Regular undo Begin trans Last buffer split: No
Temp Object: No
Tablespace Undo: No
rdba: 0x00000000
*-----------------------------
uba: 0x1081e796.1e14.14 ctl max scn: 0x0695.38f69853 prv tx scn: 0x0695.38f698a1
KDO undo record:
KTB Redo
op: 0x04 ver: 0x01
op: L itl: scn: 0x0019.009.00034237 uba: 0x36c0cce4.1d2f.19
flg: C--- lkc: 0 scn: 0x0695.38f6b96b
KDO Op code: URP xtype: XA bdba: 0x35406893 hdba: 0x35406892
itli: 1 ispac: 0 maxfr: 4863
tabn: 0 slot: 0(0x0) flag: 0x2c lock: 0 ckix: 0
ncol: 1 nnew: 1 size: -1
col 0: [ 4] c3 0e 36 2e
*-----------------------------
If the object is an Index, drop and recreate it.  If it is a table,
then again the table would need to be dropped and recreated (or truncated)
so that its object number changes and hence the rollback/undo is no longer required.
If this isn't possible, then you have two options:
First take a backup of the database in its current state.
This is critical in case anything goes wrong and you lose the opportunity to salvage the data!
Option 1
 - Restore the undo segment datafile and the datafile containing the object and perform a full recovery.
   This can only be done if you have all the archived redo as you will need to do full recovery on these files.
OR
Option 2
If option 1 is not possible, you can use the unsupported method, e.g.:
Specify the undo segment in the _OFFLINE_ROLLBACK_SEGMENTS parameter and try to drop the rollback segment.
If there is an active transaction then this is not likely to work and you will probably need
to set the _CORRUPTED_ROLLBACK_SEGMENTS parameter as well

温馨提示：
1.隐含参数_OFFLINE_ROLLBACK_SEGMENTS/_CORRUPTED_ROLLBACK_SEGMENTS属于Oracle内部隐含参数,建议在Oracle support认可的情况下使用,因为使用之后可能导致数据库事务完整性彻底损坏
2.进行屏蔽事务之前,如果条件允许建议使用txchecker检查
2.使用上述方法恢复数据库之后，建议通过逻辑方式导出导入重建数据库

分类目录归档：Oracle备份恢复