ORA-10578 ORA-01110 ORA-26040错误处理

一、问题描述

在ADG的standby库查询某张表的数据时，报如下错误：

二、原因分析

这是由NOLOGGING操作引起的坏块。

如果数据段（表段、索引段）被定义为NOLOGGING属性，那么当NOLOGGING加APPEND、UNRECOVERABLE操作修改该数据段或者使用数据泵（DATAPUMP）impdp参数DISABLE_ARCHIVE_LOGGING:Y时，联机重做日志只会记录很少的日志信息。如果这些联机重做日志或归档日志被用来恢复数据文件，那么Oracle会将对应的数据块标志为无效（Soft Corrupt），而且下一次访问这些数据块时，会报ORA-01578和ORA-26040错误。

三、处理方法

1. 修改Primary日志记录模式

为了避免后期出现同样的问题，建议把Primary库的日志记录模式修改为FORCE LOGGING。
说明：这里只是一个建议，是否需要修改要结合实际情况决定。

--查看当前日志记录模式（在Primary库操作）
# su - oracle
$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on Tue Nov 8 12:26:37 2022

Copyright (c) 1982, 2013, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

--查询结果显示当前日志记录模式未设置为force_logging
SQL> select log_mode,force_logging from v$database;

LOG_MODE     FOR
------------ ---
ARCHIVELOG   NO

--修改日志记录模式为force_logging
SQL> alter database force logging;

Database altered.

--查询结果显示日志记录模式已成功设置为force_logging
SQL> select log_mode,force_logging from v$database;

LOG_MODE     FOR
------------ ---
ARCHIVELOG   YES

2. 替换坏块

----在Primary库执行如下操作

--1.将表空间置于联机备份模式
SQL> alter tablespace USERS begin backup; 
Tablespace altered.

--2.将坏块所在文件从primary拷贝到standby（XXX.XXX.XX.XX替换成standby的ip）
$ scp /oracle/app/oracle/test/users02.dbf root@XXX.XXX.XX.XX:/oracle/app/oracle/test/users02.dbf

--3，结束备份模式
SQL> alter tablespace USERS end backup;  
Tablespace altered.

在热备份之前需要alter tablespace … begin backup呢？
我们在对数据库进行热备份的时候，需要使用alter tablespace … begin backup将表空间置于脱机或backup命令后，然后用操作系统命令进行数据文件的物理拷贝,达到备份的目的,这个过程中数据文件还是照样联机,并进行正常的数据插入,但会导致比平常更多的REDO记录的产生。

begin backup的tablespace下的数据文件在热备期间SCN不会发生变化。
这样带来的好处是，我们拷贝数据文件是个漫长的过程，我们不能保证数据文件头一定是首先被拷贝到备份里去的。在这过程中，数据库有可能会发生变化，假如已经产生变化的数据块之前已经被拷贝到备份里了，而没有置于begin backup的话其数据文件头里的SCN也将会产生变化，之后，数据文件头被拷贝到备份。如果之后的某个时间数据库需要进行恢复，将备份拷贝过来，从数据文件头的SCN开始进行介质恢复，那么从前面热备份操作时开始拷贝到文件产生变化的这段时间内的数据不在备份里，而介质恢复也不会去重做它，就将导致数据丢失。