ORA-1578 / ORA-26040

原文地址：http://www.sohu.com/a/110154017_465955

ORA-1578 / ORA-26040 - NOLOGGING 操作引起的坏块 - 错误解释和解决方案

如果数据段定义为 NOLOGGING 属性，当 NOLOGGING/UNRECOVERABLE 操作修改该数据段时，联机重做日志只记录很少的日志信息，如果之后执行 RECOVERY 操作的话，会导致这些块无效。

如果这些联机重做日志/归档日志被用来恢复数据文件，那么 Oracle 会将对应的数据块标志为无效，而且下一次访问这些数据块时，会报 ORA-1578 和 ORA-26040错误。

例如：

SQL> select * from test_nologging;

ORA-01578: ORACLE data block corrupted (file # 11, block # 84)

ORA-01110: data file 4: '/oradata/users.dbf'

ORA-26040: Data block was loaded using the NOLOGGING option

以下数据字典视图中的 LOGGING 列记录了 NOLOGGING 属性：

DBA_TABLES, DBA_INDEXES, DBA_LOBS, DBA_TAB_PARTITIONS, DBA_LOB_PARTITIONS, DBA_TAB_SUBPARTITIONS, 等等。

LOGGING='NO' 表示 NOLOGGING。

接下来，这些数据块会被标志为 Soft Corrupt，当下一次访问该数据块时，会报 ORA-1578 和 ORA-26040错误。

利用 RMAN/DBV 检测 NOLOGGING 导致的坏块

DBV 检测坏块时，如果 RDBMS 版本小于 10.2.0.4，那么 DBV 打印错误 DBV-200，如果 RDBMS 版本大于或等于 10.2.0.4，那么 DBV 打印错误 DBV-201

DBV-00200: Block, dba 46137428, already marked corrupted

DBV-00201: Block, DBA 46137428, marked corrupt for invalid redo application

"VALIDATE" RMAN 命令用来检测NOLOGGING数据块，检查结果记录在 view v$database_block_corruption (versions lower than 12c) 和 v$nonlogged_block (12c and greater). 下面的例子中检查出datafile 4 有 933 坏块，查询v$database_block_corruption 或者 v$nonlogged_block。

RMAN> VALIDATE DATABASE;

...

File Status Marked Corrupt Empty Blocks Blocks Examined High SCN

---- ------ -------------- ------------ --------------- ----------

4 OK 933 1 6401 2275124

File Name: /oracle/dbs/users.dbf

RMAN 检测坏块时，如果 RDBMS 版本小于 10.2.0.5 和 11.1.0.7，RMAN 打印如下错误：

10.2.0.4 and lower, 11.1.0.6, 11.1.0.7:

RMAN validate reports it in v$database_block_corruption with CORRUPTION_TYPE=LOGICAL

如果 RDBMS 版本大于或等于 10.2.0.5 和 11.2.0.1，RMAN 报告：查看视图 v$database_block_corruption 中 CORRUPTION_TYPE=NOLOGGING 的记录。

10.2.0.5 and 11.2.0.1+:

RMAN validate reports it in v$database_block_corruption with CORRUPTION_TYPE=NOLOGGING

在12c及以后版本中，RMAN validate的结果不在视图v$database_block_corruption中，而是在视图v$nonlogged_block：

12c:

RMAN validate的结果显示在视图v$nonlogged_block

NOLOGGING 导致的坏块不会导致 RMAN 备份失败，一般来说 soft corrupt block 不会导致 RMAN 备份失败，因此不需要设置 MAXCORRUPT。在这样的情况下，数据库备份中就会含有 soft corrupt block，如果使用这些备份恢复数据，那么恢复的数据也含有 soft corrupt block。

除 ORA-26040 错误之外，当还有一些其他通用信息出现时，block dump 可 能会被产生，如果数据块的 block dump 内有 byte 0xff 信息或者属于某个段，那么尝试执行 SQL 语句查询该数据块/段时，这个问题应该会重现。

监控 NOLOGGING 操作

执行NOLOGGING操作，并且之后没有备份的情况下，RMAN 命令 "REPORT UNRECOVERABLE" 可以查询出被影响的datafile。

RMAN> report unrecoverable;

using target database control file instead of recovery catalog

Report of files that need backup due to unrecoverable operations

File Type of Backup Required Name

---- ----------------------- -----------------------------------

4 full or incremental /oracle/dbs/users.dbf

当初始化参数db_unrecoverable_scn_tracking设置为true (默认值)，那么V$DATAFILE 中以下列会被更新；

db_unrecoverable_scn_tracking参数在10g中是不可用的。

UNRECOVERABLE_CHANGE#

UNRECOVERABLE_TIME

FIRST_NONLOGGED_SCN

FIRST_NONLOGGED_TIME

在11.2.0.4 or 12.1.0.2+版本中，设置event 16490的情况下，物理备库的MRP进程会检查出NOLOGGING变化，并记录在alert log。

ORA-16490 "logging invalidated blocks on standby due to invalidation redo"

"INVD_BLKS: Invalidating (file <file number>, bno <block number>)"

"fname: 'Datafile name'. rdba: ..."

识别数据块什么时候被标志为NOLOGGING

识别数据块什么时候被标志为NOLOGGING，可以将trace文件中数据块SCN或者v$database_block_coruption视图中CORRUPTION_CHANGE#值

转换为时间：

使用trace文件中数据块SCN

例如：

Start dump data blocks tsn: 60 file#: 4 minblk 84 maxblk 84

buffer tsn: 3 rdba: 0x02c00054 (11/84)

scn: 0x0771.4fa24eb5 seq: 0xff flg: 0x04 tail: 0x4eb500ff

提取SCN值 0x0771.4fa24eb5, 删除 '.' ，然后转换 0x07714fa24eb 到十进制 511453045995

使用v$database_block_coruption视图中CORRUPTION_CHANGE#值

如果运行RMAN validate命令后，v$database_block_coruption视图中corruption_type='NOLOGGING' (10.2.0.5 和 11.2.0.1+)，

那么CORRUPTION_CHANGE#列的值就是十进制的SCN值。

获得SCN Timestamp

SYSAUX表空间/AWR,EM 等出现NOARCHIVELOG 和 NOLOGGING 问题

如果数据库版本是11.1.0.6 或 11.1.0.7 或 11.2.0.1,

对NOLOGGING对象执行过DIRECT PATH操作，并且后续执行了RECOVER DATABASE命令，及时数据库FORCE LOGGING是打开的情况下，

会出现ORA-1578 and ORA-26040错误。

这种问题经常发生在SYSAUX表空间中的AWR或EM对象。

解决方法

NOLOGGING 操作引起的坏块是不能修复的，比如"Media Recovery" 或 "RMAN blockrecover"都无法修复这种坏块。可行的方法是在 NOLOGGING 操作之后立刻备份对应的数据文件。

问题是在执行RMAN DUPLICATE或RESTORE之后产生？

如果问题是执行RMAN DUPLICATE 或 RESTORE之后 ，那么在源库打开FORCE LOGGING，然后再重新运行RMAN DUPLICATE 或 RESTORE。

• alter database force logging;

问题是发生在物理standby库？

• 如果错误出现在物理 STANDBY数据库， 从主库恢复被影响的数据文件 (只有当主库没有这个问题的情况下)。避免这种问题产生的方法是在主库运行。

• alter database force logging;