怎么修复NOLOGGING操作引起的ORA-1578的坏块问题

本篇内容介绍了“怎么修复NOLOGGING操作引起的ORA-1578的坏块问题”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

适用于:

Oracle Database - Enterprise Edition - 版本 7.1.6.0 到 12.2.0.1 [发行版 7.1.6 到 12.2]本文档所含信息适用于所有平台

用途

重要：
如果只是错误ORA-1578，而没有伴随ORA-26040，那么这个坏块是其他的原因，可以通过RMAN Block Media Recovery修复。参考1578.1

适用范围

本文适用于用户和 Oracle Support。

详细信息

如果数据段定义为 NOLOGGING 属性，当 NOLOGGING/UNRECOVERABLE 操作修改该数据段或者使用datapump import 参数 disable_archive_logging:y，联机重做日志只记录很少的日志信息，如果之后执行 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错误。

DATAPUMP 参数 DISABLE_ARCHIVE_LOGGING

DATAPUMP impdp 参数 DISABLE_ARCHIVE_LOGGING:Y 在import时禁止 LOGGING 定义，会产生NOLOGGING操作; 如果相应的datafile被restored 和 recovered, 那么接下来的语句会报错 ORA-1578 和 ORA-26040.

"如果database是 FORCE LOGGING 模式, 那么DISABLE_ARCHIVE_LOGGING 选项不会关闭logging.

import时使用这个参数的例子:

impdp scott/tiger directory=DATA_PUMP_DIR dumpfile=dp transform=disable_archive_logging:y

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之后产生？

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

• alter database force logging;

问题是发生在物理standby库？

• 如果错误出现在物理 STANDBY 数据库， 从主库恢复被影响的数据文件 (只有当主库没有这个问题的情况下)。参考文档Doc ID 958181.1。 在12c中可以使用RMAN选项RECOVER NONLOGGED BLOCK with DATAFILE,TABLESPACE,DATABASE。例如：

•   

  RMAN> RECOVER DATABASE NONLOGGED BLOCK;

   

• 为了避免这个问题发生，在主库强制生产日志：

• alter database force logging;

如果同一个datafile的数据块在主库出现nologging 坏块，但是备库没有，可以通过手动跳过(dbms_repair)坏块 或者设置event 10231.
主库出现nologging 坏块可能是由于主库执行过备份恢复或者之前是备库，执行了switchover

识别被影响的Segment

参考  Note 819533.1 和  Note 472231.1 找到坏块所在的对象：

• 如果NOLOGGING数据块位于空闲数据块(dba_free_space视图可以查询到),DBVerify检查会发现这个问题,报错DBV-00201
  或者在v$database_block_corruption视图中显示.对于这种情况,我们可以等待到这个数据块被重用时,会自动格式化,或者
  手动强制格式化,参考Doc ID 336133.1

• 如果是索引，重新创建（drop/create）索引。

• 如果是表，使用 procedure DBMS_REPAIR.SKIP_CORRUPT_BLOCKS 跳过坏块，请参考 Note 556733.1 获取包 DBMS_REPAIR 的使用示例。然后考虑是否重建表：

  移动table: alter table &table_name move;

  或者

  保存数据 (export, Create Table as Select, etc) 然后truncate 或 drop/create

           例子：

          

标记表中需要skip的块:

BEGIN
DBMS_REPAIR.SKIP_CORRUPT_BLOCKS (
SCHEMA_NAME => '&schema_name',
OBJECT_NAME => '&table_name',
OBJECT_TYPE => dbms_repair.table_object,
FLAGS => dbms_repair.SKIP_FLAG);
END;
/

确认表的skipping corrupt blocks 是ENABLED:

select SKIP_CORRUPT
from dba_tables
where owner = '&schema_name'
and table_name = '&table_name';

Move这个表:

alter table &table_name move;

OR if decided to save the data:

export (datapump or conventional export)
or
Create Table &newtable as Select * From &nologging_corrupted_table;

 

• 如果是LOB 参考Note 293515.1。

           如果删除有坏块的段之后，这个坏块就处于空闲状态，后续可以被分配给其他对象/段，当这个坏块被分配给一个其他对象/段时，
           这个数据块被重新格式化。 如果v$database_block_corruption或者是v$nonlogged_block (12c+)视图中还是显示为坏块，那么手动运行rman validate来清除视图中的信息。

“怎么修复NOLOGGING操作引起的ORA-1578的坏块问题”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注亿速云网站，小编将为大家输出更多高质量的实用文章！