怎么修复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_LOGGINGDATAPUMP
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:yNOARCHIVELOG模式数据库，对NOLOGGING对象执行了DIRECT PATH操作，并且以后手动恢复数据库，即使打开了FORCE LOGGING，
也会报ORA-1578 和 ORA-26040。这个约束在11.2.0.2以上版本取消，这个问题在10g不会发生。以下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的坏块问题”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注百云网站，小编将为大家输出更多高质量的实用文章！

相关推荐: ORA-01804: failure to initialize timezone information

把EBS 数据库从11.1.0.7升级到11.2.0.4后，无法登陆[oraprod@ebsprod PROD_ebsprod]$ sqlplus / as sysdbaERR免费云主机域名OR:ORA-01804: failure to initialize…