本篇内容介绍了“怎么修复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
| 变化 | |
|---|---|
| 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， |
| 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的坏块问题”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注亿速云网站，小编将为大家输出更多高质量的实用文章！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
