ORA-01578和ORA-26040--NOLOGGING操作引起的坏块-错误解释和解决方案(文档ID 1623284.1)

Posted ^_^小麦苗^_^

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了ORA-01578和ORA-26040--NOLOGGING操作引起的坏块-错误解释和解决方案(文档ID 1623284.1)相关的知识,希望对你有一定的参考价值。

 

ORA-01578和ORA-26040--NOLOGGING操作引起的坏块-错误解释和解决方案(文档ID 1623284.1)

 





(一)NOLOGGING操作引起的坏块(ORA-01578ORA-26040)简介

如果只是错误ORA-01578,而没有伴随ORA-26040,那么这个坏块是由其它的原因引起的坏块,可以尝试使用RMANBMRBlock Media Recovery)修复。

如果数据段(表段、索引段)被定义为NOLOGGING属性,那么当NOLOGGINGAPPENDUNRECOVERABLE操作修改该数据段或者使用数据泵(DATAPUMPimpdp参数DISABLE_ARCHIVE_LOGGING:Y时,联机重做日志只会记录很少的日志信息。如果这些联机重做日志或归档日志被用来恢复数据文件,那么Oracle会将对应的数据块标志为无效(Soft Corrupt),而且下一次访问这些数据块时,会报ORA-01578ORA-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

数据字典视图DBA_TABLESDBA_INDEXESDBA_LOBSDBA_TAB_PARTITIONSDBA_LOB_PARTITIONSDBA_TAB_SUBPARTITIONS中的LOGGING列记录了NOLOGGING属性。若LOGGING=\'NO\'则表示NOLOGGING

数据泵DATAPUMPimpdp参数DISABLE_ARCHIVE_LOGGING:Y在执行导入时会禁止LOGGING定义,而产生NOLOGGING操作。如果相应的datafilerestoredrecovered,那么接下来的涉及到目标表的查询会报错ORA-1578ORA-26040。如果数据库是FORCE LOGGING模式,那么DISABLE_ARCHIVE_LOGGING选项不会关闭LOGGING

impdp使用参数“DISABLE_ARCHIVE_LOGGING:Y”的一个例子:

impdp 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-1578ORA-26040会因为介质恢复了NOLOGGING的部分导致了corruption而出现。

(二)利用RMANDBV检测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

RMANVALIDATE命令可以用来检测NOLOGGING数据块,检查结果记录在视图V$DATABASE_BLOCK_CORRUPTION(小于12c的版本)和V$NONLOGGED_BLOCK12c及其以上)。

下面的例子中检查出DATAFILE 4933坏块,查询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.511.1.0.7RMAN打印如下错误:

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.511.2.0.1RMAN报告,查看视图v$database_block_corruptionCORRUPTION_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。从12.2 版本开始,可以使用新的命令:“validate .. nonlogged block”去验证nologgingblock

在以下的例子中,数据文件56nologgedblock

RMAN> validate database nonlogged block;

 

Starting validate at ...

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=133 device type=DISK

channel ORA_DISK_1: starting validation of datafile

channel ORA_DISK_1: validation complete, elapsed time: 00:00:35

 

List of Datafiles

=================

File Status Nonlogged Blocks Blocks Examined Blocks Skipped

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

1        OK 0                         106363 0

2        OK 0                          78919 0

3        OK 0                          96639 0

4        OK 0                           4991 0

5        OK 400                         2559 0

6        OK 569                         2559 0

 

Details of nonlogged blocks can be queried from v$nonlogged_block view

在告警日志中会更新以下信息:

Started Nonlogged Block Replacement recovery(validate) on file 5 (ospid 26351 rcvid 10616970560844821494)

Finished Nonlogged Block Replacement recovery(validate) on file 5. 400 blocks found

 

Started Nonlogged Block Replacement recovery(validate) on file 6 (ospid 26351 rcvid 10616970560844821494)

Finished Nonlogged Block Replacement recovery(validate) on file 6. 569 blocks found

 

(三)监控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(默认值,该参数在10g中是不可用的),那么V$DATAFILE中以下列会被更新;

SYS@lhr121> select UNRECOVERABLE_CHANGE# ,   

  2  UNRECOVERABLE_TIME    ,

  3  FIRST_NONLOGGED_SCN ,

  4  FIRST_NONLOGGED_TIME from v$datafile where file#=6;

 

UNRECOVERABLE_CHANGE# UNRECOVERABLE_TIME  FIRST_NONLOGGED_SCN FIRST_NONLOGGED_TIM

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

              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

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

提取SCN0x0771.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时间:

select scn_to_timestamp(&&decimal_scn) from dual;

如果运行RMAN validate:

select file#, block#, scn_to_timestamp(CORRUPTION_CHANGE#)

from v$database_block_corruption

where CORRUPTION_TYPE=\'NOLOGGING\';

12c中:

select file#, block#, scn_to_timestamp(NONLOGGED_START_CHANGE#) from v$nonlogged_block;

如果查询gv$archived_log gv$log_history遇到错误ORA-08181:

alter session set nls_date_format = \'DD-MON-YY HH24:MI:SS\';

select first_time, next_time

from gv$archived_log

where &decimal_scn between first_change# and next_change#;

select first_time

from gv$log_history

where &decimal_scn between first_change# and next_change#;

 

 

如果运行RMAN validate:

 

alter session set nls_date_format = \'DD-MON-YY HH24:MI:SS\';

 

select file#, block#, first_time, next_time

from v$archived_log, v$database_block_corruption

where CORRUPTION_CHANGE# between first_change# and next_change#

and CORRUPTION_TYPE=\'NOLOGGING\';

 

 

select file#,block#,first_time

from   v$log_history, v$database_block_corruption

where  CORRUPTION_CHANGE# between first_change# and next_change#

  and CORRUPTION_TYPE=\'NOLOGGING\';

 

12c:

 

alter session set nls_date_format = \'DD-MON-YY HH24:MI:SS\';

 

select file#, block#, first_time, next_time

from v$nonlogged_block, v$archived_log

where NONLOGGED_START_CHANGE# between first_change# and next_change#;

 

 

select file#, block#, first_time

from v$nonlogged_block, v$log_history

where NONLOGGED_START_CHANGE# between first_change# and next_change#;

 

(五)SYSAUX表空间、AWREM等出现NOARCHIVELOGNOLOGGING问题

如果数据库版本是11.1.0.6 11.1.0.7 11.2.0.1,对NOLOGGING对象执行过DIRECT PATH操作,并且后续执行了RECOVER DATABASE命令,即使数据库FORCE LOGGING是打开的情况下,会出现ORA-1578ORA-26040错误。这种问题经常发生在SYSAUX表空间中的AWREM对象。请参考Note 1071869.1。注意数据库当前版本可能已经大于11.1 或者 11.2.0.1但是问题可能是在升级之前产生的。这个约束在11.2.0.2以上版本中取消,这个问题在10g不会发生。

RDBMS版本变化:

RDBMS版本

变化

10.2.0.4+

DBverify报告NOLOGGING block错误信息以上是关于ORA-01578和ORA-26040--NOLOGGING操作引起的坏块-错误解释和解决方案(文档ID 1623284.1)的主要内容,如果未能解决你的问题,请参考以下文章

请教ORA-01578 ORA-01110 sysaux01.dbf ORA-26040问题的相关推荐

ora-01578

oracle ora-01578 ORACLE 数据块损坏 (文件号 4, 块号 840339)

oracle数据库查询遇到ora-1578错误是怎么回事? ora-01578 "ORACLE data block corrupted

12 oracle 数据库坏块--物理坏块-ORA-01578/ORA-01110

ORA-01578: ORACLE data block corrupted ORA-01110: data file 5: ‘+DATA/yjt/datafile/undotbs2.264.994(

(c)2006-2024 SYSTEM All Rights Reserved IT常识