【DB笔试面试792】在Oracle中，ORA-01578和ORA-26040--NOLOGGING操作引起的坏块解决方案
作者：互联网
【DB笔试面试792】在Oracle中，ORA-01578和ORA-26040--NOLOGGING操作引起的坏块-错误解释和解决方案.
♣ 答案部分
（一）NOLOGGING操作引起的坏块（ORA-01578和ORA-26040）简介
如果只是错误ORA-01578，而没有伴随ORA-26040，那么这个坏块是由其它的原因引起的坏块，可以尝试使用RMAN的BMR（Block Media Recovery）修复。
如果数据段（表段、索引段）被定义为NOLOGGING属性，那么当NOLOGGING加APPEND、UNRECOVERABLE操作修改该数据段或者使用数据泵（DATAPUMP）impdp参数DISABLE_ARCHIVE_LOGGING:Y时，联机重做日志只会记录很少的日志信息。如果这些联机重做日志或归档日志被用来恢复数据文件，那么Oracle会将对应的数据块标志为无效（Soft Corrupt），而且下一次访问这些数据块时，会报ORA-01578和ORA-26040错误。
例如：
1SQL> select * from test_nologging; 2 3ORA-01578: ORACLE data block corrupted (file # 11, block # 84) 4ORA-01110: data file 4: '/oradata/users.dbf' 5ORA-26040: Data block was loaded using the NOLOGGING option
数据字典视图DBA_TABLES、DBA_INDEXES、DBA_LOBS、DBA_TAB_PARTITIONS、DBA_LOB_PARTITIONS、DBA_TAB_SUBPARTITIONS中的LOGGING列记录了NOLOGGING属性。若LOGGING='NO'则表示NOLOGGING。
数据泵DATAPUMP的impdp参数DISABLE_ARCHIVE_LOGGING:Y在执行导入时会禁止LOGGING定义，而产生NOLOGGING操作。如果相应的datafile被restored和recovered，那么接下来的涉及到目标表的查询会报错ORA-1578和ORA-26040。如果数据库是FORCE LOGGING模式，那么DISABLE_ARCHIVE_LOGGING选项不会关闭LOGGING。
impdp使用参数“DISABLE_ARCHIVE_LOGGING:Y”的一个例子：
1impdp scott/tiger directory=DATA_PUMP_DIR dumpfile=dp transform=disable_archive_logging:y
NOLOGGING导致的坏块不会导致RMAN备份失败。一般来说soft corrupt block不会导致RMAN备份失败，不需要设置MAXCORRUPT。数据库备份中就会含有soft corrupt block，如果使用这些备份恢复数据，那么恢复的数据也含有soft corrupt block。
除ORA-26040错误之外，当还有一些其他通用信息出现时，block dump可能会被产生。如果数据块的block dump内有byte 0xff信息或者属于某个段，ORA-1578和ORA-26040会因为介质恢复了NOLOGGING的部分导致了corruption而出现。
（二）利用RMAN、DBV检测NOLOGGING导致的坏块
DBV在检测坏块时，如果RDBMS版本小于10.2.0.4，那么DBV打印错误DBV-200，如果RDBMS版本大于或等于10.2.0.4，那么DBV打印错误DBV-201：
1DBV-00200: Block, dba 46137428, already marked corrupted 2DBV-00201: Block, DBA 46137428, marked corrupt for invalid redo application
RMAN的VALIDATE命令可以用来检测NOLOGGING数据块，检查结果记录在视图V$DATABASE_BLOCK_CORRUPTION（小于12c的版本）和V$NONLOGGED_BLOCK（12c及其以上）。
下面的例子中检查出DATAFILE 4有933坏块，查询V$DATABASE_BLOCK_CORRUPTION或者V$NONLOGGED_BLOCK。
1RMAN> VALIDATE DATABASE; 2... 3..... 4File Status Marked Corrupt Empty Blocks Blocks Examined High SCN 5---- ------ -------------- ------------ --------------- ---------- 64 OK 933 1 6401 2275124 7 File Name: /oracle/dbs/users.dbf
RMAN在检测坏块时，如果RDBMS版本小于10.2.0.5和11.1.0.7，RMAN打印如下错误：
110.2.0.4 and lower, 11.1.0.6, 11.1.0.7: 2RMAN 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的记录。
110.2.0.5 and 11.2.0.1+: 2RMAN validate reports it in v$database_block_corruption with CORRUPTION_TYPE=NOLOGGING
在12c及以后版本中，RMAN validate的结果不在视图V$DATABASE_BLOCK_CORRUPTION中，而是在视图V$NONLOGGED_BLOCK。从12.2版本开始，可以使用新的命令：“validate .. nonlogged block”去验证NOLOGGING的Block。
在以下的例子中，数据文件5和6有nologged的block：
1RMAN> validate database nonlogged block; 2 3Starting validate at ... 4using target database control file instead of recovery catalog 5allocated channel: ORA_DISK_1 6channel ORA_DISK_1: SID=133 device type=DISK 7channel ORA_DISK_1: starting validation of datafile 8channel ORA_DISK_1: validation complete, elapsed time: 00:00:35 9 10List of Datafiles 11================= 12File Status Nonlogged Blocks Blocks Examined Blocks Skipped 13---- ------ ---------------- --------------- -------------- 141 OK 0 106363 0 152 OK 0 78919 0 163 OK 0 96639 0 174 OK 0 4991 0 185 OK 400 2559 0 196 OK 569 2559 0 20 21Details of nonlogged blocks can be queried from v$nonlogged_block view
在告警日志中会更新以下信息：
1Started Nonlogged Block Replacement recovery(validate) on file 5 (ospid 26351 rcvid 10616970560844821494) 2Finished Nonlogged Block Replacement recovery(validate) on file 5. 400 blocks found 3 4Started Nonlogged Block Replacement recovery(validate) on file 6 (ospid 26351 rcvid 10616970560844821494) 5Finished Nonlogged Block Replacement recovery(validate) on file 6. 569 blocks found
（三）监控NOLOGGING操作
若执行了NOLOGGING操作，并且之后在没有备份的情况下，RMAN命令“REPORT UNRECOVERABLE”可以查询出被影响的datafile。
1RMAN> report unrecoverable; 2 3using target database control file instead of recovery catalog 4Report of files that need backup due to unrecoverable operations 5File Type of Backup Required Name 6---- ----------------------- ----------------------------------- 74 full or incremental /oracle/dbs/users.dbf
当初始化参数db_unrecoverable_scn_tracking设置为true（默认值，该参数在10g中是不可用的），那么V$DATAFILE中以下列会被更新；
1SYS@lhr121> select UNRECOVERABLE_CHANGE# , 2 2 UNRECOVERABLE_TIME, 3 3 FIRST_NONLOGGED_SCN , 4 4 FIRST_NONLOGGED_TIME from v$datafile where file#=6; 5 6UNRECOVERABLE_CHANGE# UNRECOVERABLE_TIME FIRST_NONLOGGED_SCN FIRST_NONLOGGED_TIM 7--------------------- ------------------- ------------------- ------------------- 8 2878238 2018-04-10 10:53:47 2878238 2018-04-10 10:53:47
在11.2.0.4 或12.1.0.2+版本中，设置event 16490的情况下，物理备库的MRP进程会检查出NOLOGGING变化，并记录在alert log。
1ORA-16490 "logging invalidated blocks on standby due to invalidation redo" 2 3"INVD_BLKS: Invalidating (file <file number>, bno <block number>)" 4"fname: 'Datafile name'. rdba: ..."
（四）识别数据块什么时候被标志为NOLOGGING
识别数据块什么时候被标志为NOLOGGING，可以将trace文件中数据块SCN或者V$DATABASE_BLOCK_CORUPTION视图中CORRUPTION_CHANGE#值转换为时间：
① 使用trace文件中数据块SCN，例如：
1 Start dump data blocks tsn: 60 file#: 4 minblk 84 maxblk 84 2 buffer tsn: 3 rdba: 0x02c00054 (11/84) 3 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时间：
1SELECT SCN_TO_TIMESTAMP(&&DECIMAL_SCN) FROM DUAL;
如果运行RMAN VALIDATE:
1SELECT FILE#, BLOCK#, SCN_TO_TIMESTAMP(CORRUPTION_CHANGE#) 2FROM V$DATABASE_BLOCK_CORRUPTION 3WHERE CORRUPTION_TYPE='NOLOGGING';
在12c中：
1SELECT FILE#, BLOCK#, SCN_TO_TIMESTAMP(NONLOGGED_START_CHANGE#) FROM V$NONLOGGED_BLOCK;
如果查询GV$ARCHIVED_LOG或GV$LOG_HISTORY，那么会遇到错误ORA-08181:
1ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YY HH24:MI:SS'; 2SELECT FIRST_TIME, NEXT_TIME 3FROM GV$ARCHIVED_LOG 4WHERE &DECIMAL_SCN BETWEEN FIRST_CHANGE# AND NEXT_CHANGE#; 5或 6SELECT FIRST_TIME 7FROM GV$LOG_HISTORY 8WHERE &DECIMAL_SCN BETWEEN FIRST_CHANGE# AND NEXT_CHANGE#;
如果运行RMAN VALIDATE:
1ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YY HH24:MI:SS'; 2 3SELECT FILE#, BLOCK#, FIRST_TIME, NEXT_TIME 4FROM V$ARCHIVED_LOG, V$DATABASE_BLOCK_CORRUPTION 5WHERE CORRUPTION_CHANGE# BETWEEN FIRST_CHANGE# AND NEXT_CHANGE# 6AND CORRUPTION_TYPE='NOLOGGING'; 7 8或 9 10SELECT FILE#,BLOCK#,FIRST_TIME 11FROM V$LOG_HISTORY, V$DATABASE_BLOCK_CORRUPTION 12WHERE CORRUPTION_CHANGE# BETWEEN FIRST_CHANGE# AND NEXT_CHANGE# 13 AND CORRUPTION_TYPE='NOLOGGING'; 14 1512C: 16 17ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YY HH24:MI:SS'; 18 19SELECT FILE#, BLOCK#, FIRST_TIME, NEXT_TIME 20FROM V$NONLOGGED_BLOCK, V$ARCHIVED_LOG 21WHERE NONLOGGED_START_CHANGE# BETWEEN FIRST_CHANGE# AND NEXT_CHANGE#; 22 23或 24 25SELECT FILE#, BLOCK#, FIRST_TIME 26FROM V$NONLOGGED_BLOCK, V$LOG_HISTORY 27WHERE NONLOGGED_START_CHANGE# BETWEEN FIRST_CHANGE# AND NEXT_CHANGE#;
（五）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和ORA-26040错误。这种问题经常发生在SYSAUX表空间中的AWR或EM对象。请参考Note 1071869.1。注意数据库当前版本可能已经大于11.1或者11.2.0.1但是问题可能是在升级之前产生的。这个约束在11.2.0.2以上版本中取消，这个问题在10g不会发生。
RDBMS版本变化：
RDBMS版本 | 变化 |
10.2.0.4+ | DBverify报告NOLOGGING block错误信息 "DBV-00201: Block, DBA <rdba>, marked corrupt for invalid redo application" |
10.2.0.5, 10.2.0.1+ | RMAN validate命令检查NOLOGGING block，在v$database_block_coruption视图中记录corruption_type='NOLOGGING' |
11g+ | 引入db_unrecoverable_scn_tracking参数 |
11.1.0.6 or 11.1.0.7 or 11.2.0.1 | NOARCHIVELOG模式数据库，对NOLOGGING对象执行了DIRECT PATH操作，并且以后手动恢复数据库，即使打开了FORCE LOGGING，也会报ORA-1578 和 ORA-26040。这个约束在11.2.0.2以上版本取消，这个问题在10g不会发生。 |
12c | RMAN validate的结果不在视图v$database_block_corruption中，而是在视图v$nonlogged_block |
12.2 | 以下RMAN命令被引入： RMAN> validate [database / datafile] nonlogged block; RMAN> recover [database / datafile] nonlogged block; -> 对于 Standby 数据库 |
（六）解决方法
NOLOGGING操作引起的坏块是不能修复的，比如“Media Recovery”或“RMAN blockrecover”都无法修复这种坏块。可行的方法是在NOLOGGING操作之后立刻备份对应的数据文件。
如果错误是执行RMAN DUPLICATE或RESTORE之后产生的，那么在源库打开FORCE LOGGING，然后再重新运行RMAN DUPLICATE或RESTORE。
1alter database force logging;
如果错误出现在物理STANDBY数据库，那么可以从主库恢复被影响的数据文件（只有当主库没有这个问题的情况下）。参考文档Doc ID 958181.1。在Oracle 12c中可以使用RMAN选项RECOVER NONLOGGED BLOCK with DATAFILE、TABLESPACE、DATABASE。例如：
1RMAN> RECOVER DATABASE NONLOGGED BLOCK;
为了避免这个问题发生，在主库强制生产日志：
1ALTER DATABASE FORCE LOGGING;
如果同一个datafile的数据块在主库出现nologging坏块，但是备库没有，可以通过手动跳过(dbms_repair)坏块或者设置event 10231。主库出现nologging坏块可能是由于主库执行过备份恢复或者之前是备库，执行了switchover。
如果NOLOGGING数据块位于空闲数据块（DBA_FREE_SPACE视图可以查询到），那么DBVerify检查会发现这个问题，报错DBV-00201或者在V$DATABASE_BLOCK_CORRUPTION视图中显示。对于这种情况，可以等待到这个数据块被重用时会自动格式化或者手动强制格式化。
如果是索引，那么可以重新创建（drop/create）索引。如果是表，那么可以使用存储过程DBMS_REPAIR.SKIP_CORRUPT_BLOCKS跳过坏块，然后考虑是否重建表。
在删除有坏块的段之后，这个坏块就处于空闲状态，后续可以被分配给其他对象或段，当这个坏块被分配给其它对象或段时，这个数据块被重新格式化。如果V$DATABASE_BLOCK_CORRUPTION视图中还是显示为坏块，那么可以手动运行RMAN VALIDATE来清除视图中的信息。
如果是LOB，那么请参考Note 293515.1。
标签：01578,NOLOGGING,BLOCK,坏块,RMAN,CHANGE,ORA 来源： https://blog.51cto.com/lhrbest/2711857