DataGuard备库ORA-01196故障恢复一则

问题现象

在使用shutdown abort停DataGuard备库后，备库不能open，报ORA-01196错误。

具体如下：

发现一备库不能应用日志，查看备库日志没发现报错，怀疑是备库应用日志服务停止，于是尝试重启备库；

可能因为备库是读业务比较繁忙，在shutdown immediate关闭备库时等时间过长，于是使用了shutdown abort命令；

但后面在启动备库时发生报错，造成数据文件损坏，控制文件和数据文件的scn号不一致。

--启动备库时报错

SQL> startup

ORACLE 例程已经启动。

Total System Global Area 2.0310E+10 bytes

Fixed Size                  2235256 bytes

Variable Size            9328133256 bytes

Database Buffers         1.0939E+10 bytes

Redo Buffers               40894464 bytes

数据库装载完毕。

ORA-10458: standby database requiresrecovery

ORA-01196: 文件 1 由于介质恢复会话失败而不一致

ORA-01110: 数据文件 1:‘+DATA/htdb5/datafile/system.261.759082693‘

--查看日志

alter database open

Data Guard Brokerinitializing...

Data Guard Brokerinitialization complete

Beginning standby crash recovery.

Serial Media Recovery started

Managed Standby Recoverystarting Real Time Apply

Media Recovery Log+FRA/htdb5/archivelog/2015_07_16/thread_1_seq_180068.1541.885192077

Thu Jul 16 12:00:47 2015

Errors in file/u01/app/ora11g/diag/rdbms/htdb5/htdb5/trace/htdb5_ora_10154.trc:

ORA-01013: 用户请求取消当前的操作

ORA-10567: Redo is inconsistentwith data block (file# 47, block# 1187724, file offset is 1139900416 bytes)

ORA-10564: tablespace JDYWP_IDX

ORA-01110: 数据文件 47:‘+DATA/htdb5/datafile/jdywp_idx.336.856967805‘

ORA-10561: block type‘TRANSACTION MANAGED INDEX BLOCK‘, data object# 251837

Errors in file/u01/app/ora11g/diag/rdbms/htdb5/htdb5/trace/htdb5_ora_10154.trc:

ORA-00339: 归档日志未包含任何重做

ORA-00334: 归档日志: ‘+DATA/htdb5/onlinelog/group_2.280.759082845‘

ORA-10567: Redo is inconsistentwith data block (file# 47, block# 1187724, file offset is 1139900416 bytes)

ORA-10564: tablespace JDYWP_IDX

ORA-01110: 数据文件 47:‘+DATA/htdb5/datafile/jdywp_idx.336.856967805‘

ORA-10561: block type‘TRANSACTION MANAGED INDEX BLOCK‘, data object# 251837

Errors in file/u01/app/ora11g/diag/rdbms/htdb5/htdb5/trace/htdb5_ora_10154.trc  (incident=116743):

ORA-00600: 内部错误代码, 参数: [3020],[47], [1187724], [198320012], [], [], [], [], [], [], [], []

ORA-10567: Redo is inconsistentwith data block (file# 47, block# 1187724, file offset is 1139900416 bytes)

ORA-10564: tablespace JDYWP_IDX

ORA-01110: 数据文件 47:‘+DATA/htdb5/datafile/jdywp_idx.336.856967805‘

ORA-10561: block type‘TRANSACTION MANAGED INDEX BLOCK‘, data object# 251837

Incident details in:/u01/app/ora11g/diag/rdbms/htdb5/htdb5/incident/incdir_116743/htdb5_ora_10154_i116743.trc

Use ADRCI or Support Workbenchto package the incident.

See Note 411.1 at My OracleSupport for error and packaging details.

Standby crash recovery aborteddue to error 600.

Errors in file/u01/app/ora11g/diag/rdbms/htdb5/htdb5/trace/htdb5_ora_10154.trc:

ORA-00600: 内部错误代码, 参数: [3020],[47], [1187724], [198320012], [], [], [], [], [], [], [], []

ORA-10567: Redo is inconsistentwith data block (file# 47, block# 1187724, file offset is 1139900416 bytes)

ORA-10564: tablespace JDYWP_IDX

ORA-01110: 数据文件 47:‘+DATA/htdb5/datafile/jdywp_idx.336.856967805‘

ORA-10561: block type‘TRANSACTION MANAGED INDEX BLOCK‘, data object# 251837

Recovery interrupted!

Some recovered datafiles maybeleft media fuzzy

Media recovery may continue butopen resetlogs may fail

Completed standby crashrecovery.

Errors in file/u01/app/ora11g/diag/rdbms/htdb5/htdb5/trace/htdb5_ora_10154.trc:

ORA-10458: standby databaserequires recovery

ORA-01196: 文件 1 由于介质恢复会话失败而不一致

ORA-01110: 数据文件 1:‘+DATA/htdb5/datafile/system.261.759082693‘

ORA-10458 signalled during:alter database open...

Thu Jul 16 12:00:49 2015

Sweep [inc][116743]: completed

Sweep [inc2][116743]: completed

Thu Jul 16 12:00:49 2015

Dumping diagnostic data indirectory=[cdmp_20150716120049], requested by (instance=1, osid=10154),summary=[incident=116743].

Thu Jul 16 12:01:50 2015

解决办法：

把备库闪回到正常的状态的时点。

--前提数据库闪回之前已经打开

SQL> select FLASHBACK_ON from v$database;

FLASHBACK_ON

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

YES

SQL> Flashback database to timestamp to_timestamp(‘2015-07-16 4:00:05‘,‘yyyy-mm-ddhh24:mi:ss‘);

--或是使用Flashbackdatabase to scn 947921

SQL> alter database open;

SQL> select open_mode from v$database;

OPEN_MODE

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

READ ONLY

--启动实时应用

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

SQL> select open_mode from v$database;

OPEN_MODE

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

READ ONLY WITH APPLY

--查看日志看到日志已经从闪回的时点开始应用

Thu Jul 16 13:36:01 2015

Flashback database to timestampto_timestamp(‘2015-07-16 4:00:05‘,‘yyyy-mm-dd hh24:mi:ss‘)

Flashback Restore Start

Thu Jul 16 13:39:30 2015

Flashback Restore Complete

Flashback Media Recovery Start

started logmerger process

Parallel Media Recovery startedwith 16 slaves

Flashback Media Recovery Log+FRA/htdb5/archivelog/2015_07_16/thread_1_seq_180047.2212.885180637

Thu Jul 16 13:41:54 2015

Flashback Media Recovery Log+FRA/htdb5/archivelog/2015_07_16/thread_1_seq_180061.2611.885182343

Thu Jul 16 13:42:04 2015

Flashback Media Recovery Log+FRA/htdb5/archivelog/2015_07_16/thread_1_seq_180062.2861.885182537

Thu Jul 16 13:42:12 2015

Incomplete Recovery applieduntil change 71489772016 time 07/16/2015 04:00:06

Flashback Media RecoveryComplete

Completed: Flashback databaseto timestamp to_timestamp(‘2015-07-16 4:00:05‘,‘yyyy-mm-dd hh24:mi:ss‘)

Thu Jul 16 13:43:25 2015

Deleted Oracle managed file+FRA/htdb5/archivelog/2015_07_15/thread_1_seq_179690.2885.885083087

Thu Jul 16 13:43:25 2015

Standby controlfile consistentwith primary

RFS[3]: Selected log 8 forthread 1 sequence 180122 dbid 1083719948 branch 759079182

Archived Log entry 180115 addedfor thread 1 sequence 180121 ID 0x40a48484 dest 1:

Thu Jul 16 13:45:41 2015

alter database open

Data Guard Brokerinitializing...

Data Guard Brokerinitialization complete

SMON: enabling cache recovery

Dictionary check beginning

Dictionary check complete

Database Characterset isZHS16GBK

No Resource Manager plan active

replication_dependency_trackingturned off (no async multimaster replication found)

Physical standby databaseopened for read only access.

Completed: alter database open

Thu Jul 16 13:45:44 2015

ALTER DATABASE RECOVER MANAGEDSTANDBY DATABASE  THROUGH ALL SWITCHOVERDISCONNECT  USING CURRENT LOGFILE

Attempt to start backgroundManaged Standby Recovery process (htdb5)

Thu Jul 16 13:45:44 2015

MRP0 started with pid=51, OSid=14743

MRP0: Background ManagedStandby Recovery process started (htdb5)

started logmerger process

Thu Jul 16 13:45:50 2015

Managed Standby Recoverystarting Real Time Apply

Parallel Media Recovery startedwith 16 slaves

Waiting for all non-currentORLs to be archived...

All non-current ORLs have beenarchived.

Media Recovery Log +FRA/htdb5/archivelog/2015_07_16/thread_1_seq_180062.2861.885182537

Completed: ALTER DATABASERECOVER MANAGED STANDBY DATABASE  THROUGHALL SWITCHOVER DISCONNECT  USING CURRENTLOGFILE

Thu Jul 16 13:46:08 2015

Media Recovery Log+FRA/htdb5/archivelog/2015_07_16/thread_1_seq_180063.3683.885182777

Thu Jul 16 13:46:35 2015

Media Recovery Log+FRA/htdb5/archivelog/2015_07_16/thread_1_seq_180064.2542.885183119

Thu Jul 16 13:47:07 2015

Media Recovery Log+FRA/htdb5/archivelog/2015_07_16/thread_1_seq_180065.2717.885183615

版权声明：本文为博主原创文章，未经博主允许不得转载。

时间： 2024-10-10 16:07:47

DataGuard备库ORA-01196故障恢复一则的相关文章

Oracle 11 g duplicate功能_复制dataguard备库

Qracle 11g duplicate功能 不用备份源库,通过网络复制出standby库 1.在standby上grid用户配置listener 注意是指定oracle用户的家目录: 监听状态: [[email protected] ~]$lsnrctl LSNRCTL for Linux:Version 11.2.0.4.0 - Production on 19-MAY-2014 18:46:15 Copyright (c)1991, 2013, Oracle.  All rights re

11gR2 dataguard 备库文件损坏处理一例

延迟标记像极了线段树,不再多说. 区间反转在树伸展到位之后,也变成了简单的递归交换左右儿子. 愈发感觉到伸展树简直太漂亮了,伸展操作更是诱惑到不行 ,总之数据结构太有魅力了. 比较简单,就直接上模板了. #include <algorithm> #include <iostream> #include <cstring> #include <cstdlib> #include <cstdio> #include <queue> #in

在dataguard备库上找回在主库上被错误的Drop/Truncate/Delete 掉的Table

前提: - Standby Database Must be in Flashback database mode. - Time at which Drop/Truncate/Delete Table happened should be within the db_flashback_retention_target and all the flashback and archive logs should be available     在dataguard备库上找回在主库上被错误的Dr

【原创】oracle ORA-01157 ORA-01110 DataGuard 备库 临时表空间报错

简要: 当查询数据库数据时,提示临时表空间异常,报错ORA-01157 ORA-01110,经过对数据文件处理后,已经解决此故障. 环境:Oracle 11g RAC For Linux 6,该库为DataGuard备库 1. 查询数据时报错,如下: ERROR:ORA-01157: cannot identify/lock data file 226 - see DBWR trace fileORA-01110: data file 226: '+DG_DATA02/racdb/blsp_te

oracle11g dataguard 备库数据同步的检查方法

概述: 一.环境 主库: ip地址:192.168.122.203 oracle根目录:/data/db/oracle SID:qyq 数据文件路径/data/db/oracle/oradata/qyq 归档文件路径:/data/db/oracle/archive' 备库: ip地址:192.168.122.204 oracle根目录:/data/app/oracle SID:qyq 数据文件路径/data/app/oracle/oradata/qyq 归档文件路径:/data/app/orac

Dataguard搭建灾备库操作手册

数据库:Oracle11gr2 主库 alter database force logging; alter system set db_unique_name='erpdb' scope=spfile;  --我们让主库db_name=db_unique_name alter system set REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE scope=spfile; alter system set LOG_ARCHIVE_FORMAT='%t_%s_%r.arc

oracle11g dataguard物理备库搭建

Dataguard 环境: 操作系统:Redhat6.4 Primary数据库: IP 地址:192.168.1.122 数据库SID:ora11g DB_UNIQUE_NAME:ora11g_primary Standby数据库: IP 地址:192.168.1.123 数据库SID:ora11g DB_UNIQUE_NAME:ora11g_standby (注:oracle数据库版本是11.2.0.1.0) 1.Primary端的配置 (1).检查数据库是否支持 Data Guard(企业版

dataguard 归档丢失(主库中无此丢失归档处理),备库基于SCN恢复

dataguard 归档丢失(主库中无此丢失归档处理),备库基于SCN恢复 环境: OS: CentOS 6.5 DB: Oracle 10.2.0.5 1.主备库环境 主库: SQL> select dbid,name,LOG_MODE,open_mode,db_unique_name,DATABASE_ROLE,PROTECTION_MODE from v$database; DBID NAME LOG_MODE OPEN_MODE DB_UNIQUE_NAME DATABASE_ROLE

Dataguard搭建灾备库操作

DJI erpdb库搭建DG 数据库:Oracle11gr2 主库 (下面打井号的不用执行) alter database force logging; alter system set db_unique_name='erp' scope=spfile; --我们让主库db_name=db_unique_name alter system set REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE scope=spfile; alter system set LOG_ARC