admin – 第25页 – Database SOS

ORA-600 3020

ORA-600 3020官方解释说明

ERROR:
  Format: ORA-600 [3020] [a] [b] {c} [d] [e]
VERSIONS:
  version 6.0 and above
DESCRIPTION:
  This is called a 'STUCK RECOVERY'.
  There is an inconsistency between the information stored in the redo
  and the information stored in a database block being recovered.
ARGUMENTS:
For Oracle 9.2 and earlier:
  Arg [a] Block DBA
  Arg [b] Redo Thread
  Arg  Redo RBA Seq
  Arg [d] Redo RBA Block No
  Arg [e] Redo RBA Offset.
For Oracle 10.1
  Arg [a] Absolute file number of the datafile.
  Arg [b] Block number
  Arg  Block DBA
FUNCTIONALITY:
  kernel cache recovery parallel
IMPACT:
  INSTANCE FAILURE during recovery.
SUGGESTIONS:
  There have been cases of receiving this error when RECOVER has
  been issued, but either some datafiles were not restored to disk,
  or the restoration has not finished.
  Therefore, ensure that the entire backup has been restored and that
  the restore has finished PRIOR to issuing a RECOVER database command.
  If problems continue, consider restoring from a backup and doing a
  point-in-time recovery to a time PRIOR to the one implied by
  the ORA-600[3020] error.
  Example:
     SQL> recover database until time 'YYYY-MON-DD:HH:MI:SS';
  This error can also be caused by a lost update.
  During normal operations, block updates/writes are being performed to
  a number of files including database datafiles, redo log files,
  archived redo log files etc.
  This error can be reported if any of these updates are lost for some
  reason.
  Therefore, thoroughly check your operating system and disk hardware.
  In the case of a lost update, restore an old copy of the datafile and
  attempt to recover and roll forward again.

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

在大家熟悉的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

在数据库恢复中,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 异常恢复

有网友数据库启动报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

我相信_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库之后,强烈建议通过逻辑方式重建库

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

有客户数据库由于某种原因无法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恢复

前段时间有多个朋友问我,在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

mount数据库也可能有LOCAL=NO的进程

在一次无意中发现mount状态的数据库也有LOCAL=NO的进程,经过分析确定是由于主库连接到备库的nls或者arch进程连接到备库引起的
发现mount库中有LOCAL=NO的进程

[oracle@localhost ~]$ sqlplus / as sysdba
SQL*Plus: Release 10.2.0.5.0 - Production on Fri Jul 29 11:59:57 2016
Copyright (c) 1982, 2010, Oracle.  All Rights Reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> select database_role ,open_mode from v$database;
DATABASE_ROLE    OPEN_MODE
---------------- ----------
PHYSICAL STANDBY MOUNTED
SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[oracle@localhost ~]$ ps -ef|grep LOCAL
oracle   11394     1  0 Apr27 ?        08:08:41 oracleorcl (LOCAL=NO)
oracle   11398     1  0 Apr27 ?        15:36:29 oracleorcl (LOCAL=NO)
oracle   18854 18752  0 12:00 pts/2    00:00:00 grep LOCAL
[oracle@localhost ~]$ ps -ef|grep pmon
oracle   14374     1  0  2015 ?        00:10:54 ora_pmon_orcl
oracle   18893 18752  0 12:01 pts/2    00:00:00 grep pmon
SQL>  select sid,status,username from v$session where paddr in
   2  (select addr from v$process where spid in(11394,11398));
       SID STATUS   USERNAME
---------- -------- ------------------------------
       510 INACTIVE PUBLIC
       507 INACTIVE PUBLIC

查看备库进程连接

[oracle@localhost ~]$ netstat -natp|grep -E '11394|11398'
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 192.168.160.22:1521         192.168.160.23:42783        ESTABLISHED 11394/oracleorcl
tcp        0      0 192.168.160.22:1521         192.168.160.23:42785        ESTABLISHED 11398/oracleorcl

主库上查看,确定192.168.160.22是备库

SQL> show parameter log_archive_dest_2;
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_2                   string      service=orcl lgwr async valid_
                                                 for=(online_logfiles,primary_r
                                                 ole) db_unique_name=orcl
SQL> !tnsping orcl
TNS Ping Utility for Linux: Version 10.2.0.5.0 - Production on 29-JUL-2016 12:20:01
Copyright (c) 1997,  2010, Oracle.  All rights reserved.
Used parameter files:
Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST =192.168.160.22)(PORT = 1521))
 (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = orcl)))
OK (0 msec)

查看主库连接

[oracle@localhost ~]$ netstat -natp|grep "192.168.160.22"
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 192.168.160.23:42785        192.168.160.22:1521         ESTABLISHED 12394/ora_arc1_orcl
tcp        0      0 192.168.160.23:42783        192.168.160.22:1521         ESTABLISHED 12400/ora_lns1_orcl

通过分析确定在mount情况的备库中,会有LOCAL=NO的进程,他们是主库arch和lns进程对应的服务进程

_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的情况下,请慎用.该相关参数可能导致数据库逻辑不一致风险,如果使用了,建议逻辑方式导出导入库

NB	Prob	Bug	Fixed	Description
	III	16384983	11.2.0.4.6, 11.2.0.4.BP15, 12.1.0.2, 12.2.0.0	RMAN bad backup – causes recovery to fail with ORA-600 [3020]
	III	16057129	11.2.0.3.BP22, 11.2.0.4, 12.1.0.1.2, 12.1.0.2	Exadata cell optimized incremental backup can skip some blocks to backup
	I	22302666	12.2.0.0	ORA-753 ORA-756 or ORA-600 [3020] with KCOX_FUTURE after RMAN Restore / PITR with BCT after Open Resetlogs in 12c
	II	21629064	12.1.0.2.160719, 12.2.0.0	ORA-600 [3020] KCOX_FUTURE by RECOVERY for KTU UNDO BLOCK SEQ:254 sometime after RMAN Restore of UNDO datafile in Source Database
	III	20509482	11.2.0.4.BP20, 12.1.0.2.160119, 12.1.0.2.DBBP09, 12.2.0.0	ORA-600 [3020] / ORA-752 Wrong Results after Parallel Direct Load or RMAN ORA-600 [krcrfr_nohist] in RAC (caused by fix for bug 9962369)
	II	19445860	12.2.0.0	ORA-1172 or ORA-600 [3020] Stuck recovery in RAC after attempted block rebuild
	III	18284763	11.2.0.4.BP13, 12.1.0.2, 12.2.0.0	ORA-600 [3020] on ASSM blocks in Standby Database after CONVERT TO PHYSICAL or ORA-8103 ORA-600 [4552] in non-standby after FLASHBACK
	III	18268201	12.1.0.2, 12.2.0.0	ORA-600 [3020] ORA-10567 and ORA-10560: block type ‘0’ / ORA-600 [kdBlkCheckError] ORA-600 [ktfbbset-2] after flashback which reversed a datafile extend – superseded
	I	16891789	11.2.0.4, 12.1.0.2, 12.2.0.0	ORA-600 [3020] or ORA-752 if db_lost_write_protect is enabled. Bystander standby recovers wrong redo log after switchover or failover.
+	III	17761775	11.2.0.3.9, 11.2.0.3.BP22, 11.2.0.4.2, 11.2.0.4.BP03, 12.1.0.1.3, 12.1.0.2	ORA-600 [kclchkblkdma_3] ORA-600 [3020] or ORA-600 [kcbchg1_16] Join of temp and permanent table in RAC might lead to corruption – superseded
	I	16844448	11.2.0.3.9, 11.2.0.3.BP22, 11.2.0.4, 12.1.0.2	ORA-600 [3020] after flashback database in a RAC
	III	15999982	11.2.0.3.BP24, 11.2.0.4, 12.1.0.2	ORA-600 [kcl_sanity_check_cr_1] ORA-600 [kclchkblkdma_3] in RAC or ORA-752 ORA-600 [3020] during recovery
	II	21425496		ORA-752 or ORA-600 [3020] on recovery of Block Cleanout Operation OP:4.6
	I	9847338		Session hang after applying the patch for Bug 9587912 which causes ORA-600 [3020]
+	III	13467683	11.2.0.2.9, 11.2.0.2.BP15, 11.2.0.3.3, 11.2.0.3.BP04, 11.2.0.4, 12.1.0.1	Join of temp and permanent tables in RAC might cause corruption of permanent table. Regression by bug 10352368
E	–	12831782	11.2.0.2.BP11, 11.2.0.3.BP01, 11.2.0.4, 12.1.0.1	ORA-600 [3020] / ORA-333 Recovery of datafile or async transport do not read mirror if there is a stale block
	II	12821418	11.2.0.3.8, 11.2.0.3.BP18, 11.2.0.4, 12.1.0.1	Direct NFS appears to be sending zero length windows to storage device. It may also cause Lost Writes
	I	12582839	11.2.0.3, 12.1.0.1	ORA-8103/ORA-600 [3020] on RMAN recovered locally managed tablespace
P	I	12330911	12.1.0.1	EXADATA LSI firmware for lost writes
	III	11689702	11.2.0.2.5, 11.2.0.2.BP13, 11.2.0.2.GIPSU05, 11.2.0.3, 12.1.0.1	ORA-600 [3020] during recovery after datafile RESIZE (to smaller size)
+	II	10425010	11.2.0.3, 12.1.0.1	Stale data blocks may be returned by Exadata FlashCache
	–	10329146	11.2.0.1.BP10, 11.2.0.2.2, 11.2.0.2.BP03, 11.2.0.2.GIBUNDLE02, 11.2.0.2.GIPSU02, 11.2.0.3, 12.1.0.1	Lost write in ASM with multiple DBWs and a disk is offlined and then onlined
	II	10218814	11.2.0.2.2, 11.2.0.2.BP02, 11.2.0.3, 12.1.0.1	ORA-600 [3020] during recovery / on standby
+	II	10209232	11.1.0.7.7, 11.2.0.1.BP08, 11.2.0.2.1, 11.2.0.2.BP02, 11.2.0.2.GIBUNDLE01, 11.2.0.3, 12.1.0.1	ORA-1578 / ORA-600 [3020] Corruption. Misplaced Blocks and Lost Write in ASM
*	III	10205230	11.2.0.1.6, 11.2.0.1.BP09, 11.2.0.2.2, 11.2.0.2.BP04, 11.2.0.3, 12.1.0.1	ORA-600 / corruption possible during shutdown in RAC
	II	10094823	11.2.0.2.4, 11.2.0.2.BP09, 11.2.0.3, 12.1.0.1	Block change tracking on physical standby can cause data loss
	–	10071193	11.2.0.2.BP02, 11.2.0.3, 12.1.0.1	Lost write / ORA-600 [kclchkblk_3] / ORA-600 [3020] in RAC – superceded
	–	9587912	11.2.0.2, 12.1.0.1	ORA-600 [3020] in datafile that went offline/online in a RAC instance
	–	8774868	11.2.0.1.2, 11.2.0.1.BP06, 11.2.0.2, 12.1.0.1	OERI[3020] reinstating primary
+	III	8769473	11.2.0.2, 12.1.0.1	ORA-600 [kcbzib_5] on multi block read in RAC. Invalid lock in RAC. ORA-600 [3020] in Recovery
P	II	8635179	10.2.0.5, 11.2.0.2, 12.1.0.1	Solaris: directio may be disabled for RAC file access. Corruption / Lost Write
+	II	8597106	11.2.0.1.BP06, 11.2.0.2, 12.1.0.1	Lost Write in ASM when normal redundancy is used
+E	II	17752121	11.2.0.3.9, 11.2.0.3.BP22, 11.2.0.4.2, 11.2.0.4.BP03	ORA-600 [kclchkblkdma_3] ORA-600 [3020] RAC diagnostic/fix to avoid a block being modified in Shared Mode and prevent corruption – Superseded
	III	8826708	10.2.0.5, 11.2.0.2	ORA-600 [3020] for block type 0x3a (58) during recovery for block restored by RMAN backup
	I	16579042	11.2.0.4	ORA-600 [kjbmpocr:alh] ORA-600 [kclchkblkdma_3] by LMS in RAC which may lead to corruption
	–	11684626	11.2.0.1	ORA-600 [3020] on standby involving “BRR” redo when db_lost_write_protect is enabled
	–	8230457	10.2.0.4.1, 10.2.0.5, 11.1.0.7.1, 11.2.0.1	Physical standby media recovery gets OERI[krr_media_12]
+	II	7680907	10.2.0.5, 11.1.0.7.1, 11.2.0.1	ORA-600 [kclexpandlock_2] in LMS / instance crash. Incorrect locks in RAC. ORA-600 [3020] in recovery
	II	4637668	10.2.0.3, 11.1.0.6	IMU transactions can produce out-of-order redo (OERI [3020] on recovery)
	–	4594917	9.2.0.8, 10.2.0.2, 11.1.0.6	Write IO error can cause incorrect file header checkpoint information
	–	4453449	10.2.0.2, 11.1.0.6	OERI:3020 / corruption errors from multiple FLASHBACK DATABASE
	III	7197445	10.2.0.4.1, 10.2.0.5	Standby Recovery session cancelled due to ORA-600 [3020] “CHANGE IN FUTURE OF BLOCK”
	II	5610267	10.2.0.5	MRP terminated by ORA-600[krr_media_12] / OERI:3020 after flashback
	–	3762714	9.2.0.7, 10.1.0.4, 10.2.0.1	ALTER DATABASE RECOVER MANAGED STANDBY fails with OERI[3020]
	I	3560209	10.2.0.1	OERI[3020] stuck recovery under RAC
	–	3397181	9.2.0.5, 10.1.0.3, 10.2.0.1	ALTER SYSTEM KILL SESSION of recovery slave causes stuck recovery
*	–	3381950	10.2.0.1	Backups from RAC DB before Data Guard Failover cannot be used
	–	3535712	9.2.0.6, 10.1.0.4	OERI[3020] / ORA-10567 from RAC with standby in max performance mode
	–	4594912	9.2.0.8, 10.1.0.2	Incorrect checkpoint possible in datafile headers
	–	3635331	9.2.0.6, 10.1.0.4	Stuck recovery (OERI:3020) / ORA-1172 on startup after a crash
	II	2322620	9.2.0.1	OERI:3020 possible on recovery of LOB DATA
P+	–	656370	7.3.3.4, 7.3.4.0, 8.0.3.0	AlphaNT only: Corrupt Redo (zeroed byte) OERI:3020

作者：admin