如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
服务热线 ： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com
适用于：
Oracle Database – Enterprise Edition – 版本10.2.0.1 到 11.2.0.4 [Release 10.2 to 11.2]
本文信息适用于任何平台。
症状
Standby Redo Apply 可能由于重做数据一致性检查的失败而终止， 称为stuck recovery的问题。当底层的操作系统或存储系统在正常操作期间，丢失由主或备用数据库发出的写操作，可能会出现stuck recovery。因为存储在重做的信息和存储在被恢复的数据库块中的信息不一致，数据库在应用重做时会发出内部错误。
ORA-00600: internal error code, arguments: [3020], [2885689059], [1], [419819],[26750], [808], [], []
ORA-10567: Redo is inconsistent with data block (file# 1, block# 419819)
ORA-10564: tablespace USER1
ORA-01110: data file ’/oracle/datafiles/user1.dbf’
原因
ORA-600 [3020] stuck recovery错误可能在备用数据库发生，有多种原因：在主数据库的丢失写，在备用数据库的丢失写，丢失重做，或在主数据库的逻辑损坏导致不完整redo chain。
注: 当主和备用数据库上启用了DB_LOST_WRITE_PROTECT时，检测到primary丢失写时，Standby Redo Apply 终止并显示ORA-752 错误。
注意： 如果你有一个RAC primary，但没有修正bug 11674485的Oracle RDBMS补丁，在Standby检测到的“lost write on the primary”可能是误判。请按照“Steps to recover from bug 11674485”所述步骤，在继续下一步前做出确认。
ORA-752: recovery detected a lost write of a data block
该ORA-752错误表示在主数据库上发生丢失写操作。 Oracle强烈建议启用DB_LOST_WRITE_PROTECT（和DB_BLOCK_CHECKSUM= FULL）以更好检测并保护丢失写。有研究显示在主数据库上的影响是可忽略的。
解决方案
在大多数情况下，Standby stuck recovery错误表示主数据库损坏。在主数据库可能未报告错误。
警告: 不要通过还原主数据库上创建的备份来修复，因为这将确认备用数据库也是损坏的！唯一的例外是当备用数据库已知有一个丢失写，但这应该由Oracle Support进行确认。
一个ORA-752错误明确标识主数据库上的写丢失。如果数据的完整性很重要且丢失一些数据可以接受，则考虑立即故障切换到备用数据库。当通过My Oracle Support打开Service Request出现一个ORA-600 [3020]错误时，Oracle Support应该立即参与。
当媒介恢复遇到问题时，警报日志可能表明恢复可以持续，如果它被允许破坏导致问题的数据块。警报日志包含有关块的信息：它的块类型，块地址，所属表空间，等等。对于包含用户数据的块，警报日志也可能报告数据对象号。
对于包含用户数据的块，你可以查询数据库找出哪个对象或表拥有此块。如果该块属于可被重建或不重要的对象，则在标记块损坏后可以允许恢复继续进行。此过程在后续部分叙述。
确定损坏范围
要确定损坏是否被隔离，运行诊断试验恢复，这会扫描有问题的重做，但对被恢复数据库不作任何更改。试验恢复报告在alert_<SID>. Log中任何额外的损坏。你可以使用RECOVER … TEST语句来调用试验恢复。参阅 Document 283262.1获取试验恢复的其他详细信息。
确定根本原因
需要收集信息，并立即发送到Oracle Support：
- Complete or an extract from the alert.log covering at least the period from the last successful database startup. 完成或从覆盖至少从最后一次成功启动数据库期间的alert.log中的抽取。
- RDA 报告（或至少是init.ora或spfile）。参阅Document 314422.1
- 在失败当时和之后生成的所有跟踪文件。
- 覆盖从最后一次成功启动的时间段的所有系统和I / O子系统的日志/错误文件。
- 控制文件的dump
SQL> alter session set events ‘immediate trace name controlf level xx’;
- 数据文件头的dump：
SQL> alter session set events ‘immediate trace name file_hdrs level 10’;
- 重做日志头的dump：
SQL> alter session set events ‘immediate trace name redohdr level 10’;
当ORA-752丢失写错误被发出时可以采取什么措施？
选项 1: 确认受影响对象能否被重建以及恢复能否继续：
- 首先确定受影响的对象。警报日志信息将提供数据文件号及相应的块号。对于包含用户数据的块，警报日志也能报告数据对象号。使用该信息，你可以确定哪些对象被损坏影响：
Spool
输出并正确使用。
SQL> Select * from DBA_EXTENTS
where FILE_ID=&file_number and
&block_number BETWEEN BLOCK_ID and BLOCK_ID+BLOCKS-1;
如果错误提供对象号，通过以下查询确认受影响的对象 ：
SQL> Select * from DBA_OBJECTS where DATA_OBJECT_ID = &object_number;
- 如果可行，在primary上drop并重建受影响的对象。
- 一旦对象被重建，使用以下过程来跳过standby上的损坏块：
- 暂时禁用在standby上的丢失写保护：
SQL> ALTER SYSTEM SET DB_LOST_WRITE_PROTECT = NONE;
- 尽管块损坏，通过运行有ALLOW nCORRUPTION 子句的RECOVER 命令使恢复继续进行，其中 n 是允许损坏块的数量。
SQL> alter database recover automatic standby database
allow 1 corruption;
- 一旦警报调整表示块已被标记为corrupt，重启受管的恢复。
SQL> alter database recover cancel;
SQL> alter database recover managed standby database
using current logfile disconnect;
选项2: 激活备用数据库
如果受影响的对象不能被重建，则激活备用数据库。激活备用数据库会遇到数据丢失，但数据的完整性将得到保证。
- 在备用数据库上发出以下SQL语句将其转换为一个primary：
SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;
如果备用数据库由Data Guard broker管理，发出以下Data Guard Broker命令执行立即故障切换到备用数据库：
DGMGRL> FAILOVER TO database-name IMMEDIATE;
注：在某些情况下，“alter database activate standby database”命令会在物理备用数据库上失败，因为无法归档最后部分的备用重做日志。要无法归档部分归档重做日志，请执行下列步骤：
1) 关闭并mount物理备用数据库的一个实例
2) 使用ALTER DATABASE DROP LOGFILE GROUP <standby_group_#> drop所有ACTIVE的备用重做日志组。备用重做日志组的group#可以通过对V $ STANDBY_LOG查询来找出
3) 重复 ‘alter database activate standby database’ 命令。
4) 对新的生产数据库进行完整备份。
2. 备份新的primary。立即执行备份是必要的安全保证，因为故障转移后没有数据库的完整备份副本是无法恢复所做的更改的。故障转移的结果是，原来的主数据库不再参与Data Guard配置，且所有其它备用数据库现在接收并应用来自新的主数据库的重做数据。
3. 打开新的主数据库。
4. 可选的步骤是重建故障的主数据库作为物理备用数据库。这可以通过使用在步骤3的新primary进行的数据库备份来完成（在这里，你不能使用闪回数据库或Data Guard broker来重新实例化旧的主数据库）。
注意，使用新primary的备份创建的一个物理备用将具有与旧备用相同的数据文件。因此，在旧的备用被激活之前所有未检测到的丢失写不会被新的备用检测，因为新的备用将被比较相同的块。发生在primary或standby的所有新的丢失写会被检测。
当ORA-600 [3020]被发出时可以采取什么措施？
发生ORA-600 [3020]错误时立即使Oracle Support参与。通过My Oracle Support打开Service Request时，准备好提供“确定根本原因”下列出的信息。
保护丢失写
通过在主数据库和备用数据库上设置DB_LOST_WRITE_PROTECT为TYPICAL防止写丢失。通过这样做，物理备用Redo Apply过程将比较在standby的块SCN与存储在primary redo stream中的（当块被读时）块SCN，以确定在primary是否有丢失写。
Oracle强烈建议启用DB_LOST_WRITE_PROTECT 和 DB_BLOCK_CHECKSUM=FULL 更好地检测和保护丢失写。有研究显示在主数据库上的影响是可忽略的。
注意DB_LOST_WRITE_PROTECT 仅在Oracle 11g 及以上版本中提供。
从bug 11674485恢复的步骤
在这个部分的步骤会帮助你确认是否遇到了bug 11674485并解释修复备用数据库必须的后续解决方法。如果你检测遇到了bug 11674485 （详情见下文），主数据库并没有失去一个写也没有损坏。唯一必要的解决方法是当误判被触发时，恢复在standby被受管standby恢复标记为损坏块的数据文件。
检测 – 如何知道在standby检测的“Lost write at the Primary” 是误判a false positive？
当standby恢复检测到一个发生在主数据库上的写丢失，standby恢复发出ORA-752并停止。当发生这种情况，以下是standby警报日志的示例输出：
Hex dump of (file 786, block 657290) in trace file /diag/rdbms/gmfcdwp_lvt/gmfcdwp8/trace/gmfcdwp8_pr0m_28759.trc
STANDBY REDO APPLICATION HAS DETECTED THAT THE PRIMARY DATABASE
LOST A DISK WRITE OF BLOCK 657290, FILE 786
NO REDO AT OR AFTER SCN 10753662227200 CAN BE USED FOR RECOVERY.
Tue Apr 26 22:21:08 2011
Slave exiting with ORA-752 exception
Errors in file
/diag/rdbms/gmfcdwp_lvt/gmfcdwp8/trace/gmfcdwp8_pr0m_28759.trc:
ORA-00752: recovery detected a lost write of a data block
ORA-10567: Redo is inconsistent with data block (file# 786, block# 657290, file offset is 1089552384 bytes) <ORA-10564: tablespace ODS_DATA
ORA-01110: data file 786: ‘+DATA/gmfcdwp/datafile/ods_data_306.dbf’
ORA-10561: block type ‘TRANSACTION MANAGED INDEX BLOCK’, data object#4718509
Tue Apr 26 22:21:09 2011
Recovery Slave PR0M previously exited with exception 752
如果primary 是RAC，则可能该情况是由bug 11674485造成的。当遇到了bug 11674485，standby recovery 声称它找到了一个primary 丢失写，即使在primary没有任何丢失写或损坏。如果primary 不是RAC，则bug 11674485 无法发生。
为了确认ORA-752的一个特定事件是由bug 11674485导致的，你需要查看检测到丢失写的恢复进程的跟踪文件。在以上示例的情况中，我们需要查看跟踪文件gmfcdwp8_pr0m_28759.trc。
跟踪文件应当包含以下信息：
STANDBY REDO APPLICATION HAS DETECTED THAT THE PRIMARY DATABASE
紧跟在以上信息后的是触发standby恢复声称primary丢失写的redo change vector header。例如：
STANDBY REDO APPLICATION HAS DETECTED THAT THE PRIMARY DATABASE
LOST A DISK WRITE OF BLOCK 657290, FILE 786
在primary 上读的块有 SCN 10753662227193 (0x09c7.c83792f9) seq 1
(0x01)
而预期有 SCN 10753662227199 (0x09c7.c83792ff) seq 1 (0x01)
块在 SCN 10753662227200 (0x09c7.c8379300)上读，BRR:
CHANGE #1 TYP:0 CLS:32772 AFN:786 DBA:0x95ca078a OBJ:4718509 SCN:0x09c7.c83792f9 SEQ:1 OP:23.2 ENC:0 RBL:1
以“The block was read at SCN…” 起始的行和紧跟的以“CHANGE #1 TYP:0 CLS:…”开头的下一行对于以下分析是很重要的，所以请记下这些行。
相同的跟踪文件将包含特定块的所有相关重做的重做转储（在以上示例的情况中，该块是文件＃786，块＃657290）。特定重做记录如下：
- 重做记录SCN应该与在跟踪文件消息“The block was read at SCN …, BRR:”中观测到的SCN相同。在以上示例的情况中，重做记录SCN应为10753662227200 (0x09c7.c8379300)
- 重做记录应与“CHANGE #1 TYP: 0 …”以上的变化矢量头dump行有确切的匹配信息。（在匹配这行的重做dump中有可能有多个变化矢量）。
下面是匹配上述两个条件的redo dump的例子：
REDO RECORD – Thread:8 RBA: 0x000058.000a60b9.0038 LEN: 0x0034 VLD: 0x10
SCN: 0x09c7.c8379300 SUBSCN: 1 04/26/2011 21:59:30
CHANGE #1 TYP:0 CLS:32772 AFN:786 DBA:0x95ca078a OBJ:4718509
SCN:0x09c7.c83792f9 SEQ:1 OP:23.2 ENC:0 RBL:1
Block Read – afn: 786 rdba: 0x95ca078a BFT:(1024,2513045386) non-BFT:
599,657290)
scn: 0x09c7.c83792f9 seq: 0x01
flags: 0x00008004 ( ckval ping )
如果满足以下两个条件，丢失写检测是由bug11674485引起的：
- 变化矢量头有“RBL:1” 集。
- 变化矢量有“ping” flag。（可能有或没有其他flag集（例 chval），最重要的是设置了“ping” flag）。
Bug 11674485的解决方法
When bug 11674485 has been encountered managed standby recovery will marked one of the blocks in a datafile as corrupt. The name and number of the of the datafile is easily determined from the standby alert log line below: 当遇到了bug11674485，受管的standby恢复将标志数据文件中的一个块为corrupt。数据文件的名称和号很容易通过以下的standby警报日志行确定：
Reading datafile ‘+DATA/gmfcdwp/datafile/ods_data_306.dbf’ for corruption at rdba: 0x95ca078a (file 786, block 657290)
- 在主数据库通过alter system checkpoint命令强制一个检查点或使与受影响的数据文件相关的表空间处于热备份模式，然后再离开热备份模式。
- 将以上数据文件从primary复制到standby，使用以下MOS note列出的过程：
How to Copy ASM datafile From Primary Database to Standby Database on ASM using RMAN (Doc ID 605234.1)
参考
NOTE:283262.1 – Trial Recovery
NOTE:314422.1 – Remote Diagnostic Agent (RDA) – Getting Started
BUG:11689702 – ORA-600 [3020] DURING RECOVERY AFTER DATAFILE RESIZE
NOTE:1302614.1 – Rman or User Managed Restore/Recovery Fails With Ora-600 [3020] if Datafile resize Operation was Performed.
Comment