Oracle备用数据库恢复过程中解决ORA-752 或 ORA-600[3020]

 

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

ORA-00752: 恢复操作检测到数据块写入丢失

ORA-00752: recovery detected a lost write of a data block

oerr ora 752
00752, 00000, “recovery detected a lost write of a data block”
// *Cause: A write of a data block to storage was lost during
// normal database operation on the primary database.
// *Action: Shutdown the primary database and activate the physical standby
// database to failover. See the Data Guard Concepts and Administration
// guide for details.

ORA-00600: 内部错误代码，参数: [3020]

 

 

 

 

应用于:

Oracle数据库- 企业版- 10.2.0.1至11.2.0.4版本[发行10.2至11.2]

本文档中的信息适用于任何平台。

症状

由于 redo-data一致性检测失败，这问题叫卡住恢复，Standby Redo Apply就会终止。当底层的操作系统或存储系统失去正常操作中主/备用数据库发出的写操作，就可能会出现卡住恢复。由于redo中储存的信息与存储在数据库块中正被恢复的信息两者之间有不一致，应用redo时数据库会显示内部错误。

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]卡住恢复错误出现在备用数据库，可能有以下几个原因：主数据库丢失写操作，备份数据库丢失写操作，redo丢失或是主数据库上逻辑坏块导致 redo链不完整。

注意：在主/备用数据库启用DB_LOST_WRITE_PROTECT，由于ORA-752错误主数据库丢失写操作，Standby Redo Apply 就会终止。

 

注意：如果你有一个RAC主库，但没有用来修复错误11674485的Oracle RDBMS补丁，备用数据库检测到的“主库丢失写操作”也许是“假阳性”。请先按照“修复错误11674485的步骤” 这一章节所述步骤作出决定，然后再执行其他操作。

 

ORA-752: recovery detected a lost write of a data block
ORA-752错误表明是主数据库丢失写操作。 Oracle强烈建议启动DB_LOST_WRITE_PROTECT（和DB_BLOCK_CHECKSUM= FULL）更好地检测和保护以避免丢失写操作。研究表明这对主数据库的影响可以忽略不计.

解决方案

大多数情况下，备用数据库卡住恢复错误表明主数据库有坏块。主数据库不报错。

警告：不要通过还原主库上的备份来修复备用数据库，因为这样会导致备用数据库也崩溃！唯一的例外情况是已知备用数据库丢失写操作时，但也应该由Oracle Support来做出决定。

ORA-752错误认定了主库丢失写操作。如果数据的完整性至关重要，应立即故障切换到备用数据库，丢失一些数据也是可以接受的。如果通过 Oracle Support打开服务请求时出现ORA-600[3020]错误，Oracle Support 应该立即参与。

当介质恢复遇到问题时，警报日志也许会暗示，如果可以破坏引发问题的数据块，就可以继续恢复。警报日志包含有关该块的信息：它的块类型，块地址，所属的表空间，等等。对于包含用户数据的块，警报日志也可能报告数据对象号。
对于包含用户数据的块，你可以查询数据库找出哪些对象或表拥有此块。如果该块属于可重建或不重要的对象，那么标记块损坏后就可以继续进行恢复。这一过程在随后的章节中有介绍。

确定损坏的程度

要确定损坏是否隔离进行诊断试验恢复，扫描redo找问题，但实际上对恢复的数据库没有作任何更改。试验恢复在alert_<SID>.LOG报告额外的损坏。你可以使用 RECOVER … TEST 语句来调用试验恢复。请参阅Document 283262.1查询试验恢复的其他详细信息。

确定根本原因

需要收集并立即发送到Oracle Support的信息:

1. 完整的或是从最后一次成功启动数据库这一时间段内的log中提取的 。
2. RDA报告（或至少ora文件或spfile中）。请参考Document 314422.1
3. 出错时或出错后生成的所有跟踪文件。
4. 最后一次成功启动数据库这一时间段内的任何系统以及I/ O 子系统中日志/错误文件。
5. 控制文件转储

SQL> alter session set events ‘immediate trace name controlf level xx’;

6. 数据文件头转储:

SQL> alter session set events ‘immediate trace name file_hdrs level 10’;

7. redo 日志头转储:

SQL> alter session set events ‘immediate trace name redohdr level 10’;

报错ORA-752显示丢失写操作时应采取什么措施?

选项1：确定受影响的对象是否可以重建并且允许继续恢复：

1. 首先确定受影响的对象。警报日志信息会提供数据文件数与相应的块号。对于包含用户数据的块，警报日志也会报告数据对象号。使用该信息，可以确定哪些对象受到损坏：

阀芯输出，并妥善保管
Spool the output and keep them handy.

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;

1. 如果可行，删除并在主库上重建受影响的对象。
2. 一旦对象已重建，请使用以下步骤跳过备用数据库的损坏块:
   1. 备用数据库上暂时禁用丢失写保护:

SQL> ALTER SYSTEM SET DB_LOST_WRITE_PROTECT = NONE;

1. 允许继续进行恢复，尽管用ALLOW n CORRUPTION 语句运行RECOVER命令时出现损坏块，其中n是合理的损坏块数量。

SQL> alter database recover automatic standby database
allow 1 corruption;

1. 一旦警报日志显示块已被标记为损坏，重新启动管理恢复。

SQL> alter database recover cancel;
SQL> alter database recover managed standby database
using current logfile disconnect;

选项2：激活备用数据库

如果受影响的对象不能重建，则重新激活备用数据库。通过激活备用数据库，会丢失一些数据，但可以保证数据的完整性。

1. 在备用数据库上发出如下的SQL语句，将其转换为一个主数据库:

SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;

如果备用数据库是由Data Guard broker管理，发出如下的Data Guard Broker命令，立即执行故障切换到备用数据库

DGMGRL> FAILOVER TO database-name IMMEDIATE;

 

注意：在某些情况下，”alter database activate standby database”命令在物理备用数据库上会出错，因为无法将最后部分备用redo日志存档。要解决这一错误将部分归档redo日志存档，请执行下列步骤：

1）关闭并安装物理备用数据库实例

2）删除所有使用ALTER DATABASE DROP LOGFILE GROUP <standby_group_#>激活的备用redo日志组。在 V$standby_log上做查询就可以找到备用redo日志组。

3）重复 ‘alter database activate standby database’ 命令。

4）采取新的生产数据库的完整备份。

2.  备份新的主数据库。立即进行备份是必要的安全措施，因为数据库副本备份不完整而发生故障转移造成的更改是无法恢复的。由于故障转移，原来的主数据库不再参与Data Guard配置，所有其它备用数据库将接收并处理来自新的主数据库的redo数据。
3.  打开新的主数据库。

   4.  可选步骤是重建出错的主数据库作为物理备用数据库。可以在步骤3中提取新的主数据库的数据库备份来完成（这种情况下不能使用闪回数据库或Data Guard broker重新实例原来的主数据库）。

注意，一个新建的物理备用数据库若使用新的主数据库备份，其数据文件与原来的备用数据库相同。因此，在旧的备用数据库激活之前已有的检测不到的丢失的写操作，新备用数据库是检测不到的，因为新的备用数据库会比较相同的块。而发生在主/备用数据库上的任何新的丢失的写操作是可以检测到的。

报错ORA-600[3020]时可以采取什么措施?

报错ORA-600[3020]时立即使用Oracle Supporrt。通过My Oracle Support打开服务请求时，请准备提供“确定根本原因”一节中列出的信息。

防止丢失写

在主备用数据库上设置DB_LOST_WRITE_PROTECT to TYPICAL来防止写丢失。这样物理备用数据库Redo Apply进程会比较备用数据库的SCN块以及储存在主数据库中redo流上的SCN块（若块被读出），以确定主数据库上是否丢失写。启动DB_LOST_WRITE_PROTECT，Redo Apply就可以使用主数据库上的其他信息。如果主数据库上的SCN块低于备用数据库上的SCN块，那它就检测到主数据库上丢失写，并引发一个外部错误（ORA-752）。
Oracle强烈建议启用DB_LOST_WRITE_PROTECT和DB_BLOCK_CHECKSUM= FULL以更好地检测和防止丢失写。研究表明这对主数据库的影响可以忽略不计。

需要注意的是DB_LOST_WRITE_PROTECT仅在Oracle11g和更高版本中可用。

修复错误11674485的步骤

本节所列步骤可以帮助确定是否出现了错误11674485，并说明了修复备用数据库所必需的后续解决办法。

如果检测到已出现错误11674485（详见下文），主数据库没有丢失写，也没有损坏。唯一必要的解决办法是当假阳性被触发时，在已标记为坏块管理备用恢复的备用数据库上恢复数据文件。

检测 – 如何知道备用数据库上检测到的“主数据库写丢失”是误报？

 

当备用数据库恢复检测到主数据库上写丢失，备用数据库会报错ORA-752并停止运行。下面是这种情况下备用数据库警报日志输出实例：

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

如果主数据库是RAC，这一事件可能是错误11674485造成的。遇到错误11674485时，备用恢复显示，发现主数据库丢失写，虽然主数据库没有任何丢失写也没有其他损坏。如果主数据库不是RAC，就不会出现错误11674485。

 

要确定特定的ORA-752是否由错误11674485引起的，你需要研究检测写丢失恢复过程中的跟踪文件。在上面的例子中，我们需要研究跟踪文件gmfcdwp8_pr0m_28759.trc。

 

跟踪文件应包含以下信息：

 

STANDBY REDO APPLICATION HAS DETECTED THAT THE PRIMARY DATABASE

 

紧随着上述信息的是redo变化矢量的信息，正是redo变化引发了备用恢复显示主库丢失写。 例如:

 

STANDBY REDO APPLICATION HAS DETECTED THAT THE PRIMARY DATABASE
LOST A DISK WRITE OF BLOCK 657290, FILE 786
The block read on the primary had SCN 10753662227193 (0x09c7.c83792f9) seq 1
(0x01)
while expected to have SCN 10753662227199 (0x09c7.c83792ff) seq 1 (0x01)
The block was read at 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

这些开头为“块读取在SCN……”的行，接下来开头为“CHANGE＃1 TYP：0 CLS：…”的行，对下面的分析很重要，所以请记下这些行。

 

相同的跟踪文件包含特定块的所有相关redo的redo转储（上面的例子中，特定块是文件＃786，块＃657290）。特定redo记录如下：

 

1. redo记录SCN应该与跟踪文件信息”The block was read at SCN …, BRR:”中的SCN相同。在上述例子中，redo记录SCN应为10753662227200（0x09c7.c8379300）
2. redo记录应该与上面的变化矢量头转储行“CHANGE＃1 TYP：0 …”有确切的匹配信息。 （也许在redo转储中有多变化矢量与这行相匹配）。

下面是redo转储与上述两个条件相匹配的例子:

 

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 )

检测到丢失写是由错误11674485引起的，如果满足以下两个条件：

1. 设置变化矢量头有“RBL：1”。
2. 变化矢量有“平”标志。 （可能有也可能没有设置其它标志（例如chval），但最重要的是，设置了“平”标志）。

解决错误11674485的办法

 

遇到错误11674485时，管理备用恢复会在数据文件中标记一个坏块。从下面的备用警报日志行，很容易确定数据文件的名称和号码：

Reading datafile ‘+DATA/gmfcdwp/datafile/ods_data_306.dbf’ for corruption at rdba: 0x95ca078a (file 786, block 657290)

 

1. 在主数据库上强制检查点，通过更改系统检查命令或是将受影响的数据文件相关联的表空间放入热备份模式，随后将其从热备份模式中取出。
2. 从主库中复制上述数据文件到备用库，使用以下MOS说明中概述的步骤：

如何在ASM上使用RMAN从主数据库复制ASM数据文件到备用数据库（文档编号605234.1）