问题现象

在使用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

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

  1. Oracle数据库由dataguard备库引起的log file sync等待

    导读: 最近数据库经常出现会话阻塞的报警,过一会又会自动消失,昨天晚上恰好发生了一次,于是赶紧进行了查看,不看不知道,一看吓一跳,发现是由dataguard引起的log file sync等待.我们知 ...

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

    概述: 一.环境      主库:       ip地址:192.168.122.203       oracle根目录:/data/db/oracle       SID:qyq       数据文 ...

  3. Oracle 11.2.4.0 ACTIVE DATAGUARD 单实例安装(COPY创建备库)

    Oracle 11.2.4.0 ADG 单实例安装(COPY创建备库) 规划: 主: OS: Linux Centos 6.5 X64 hostname:ORA11G-DG1 ipaddress:19 ...

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

    dataguard 归档丢失(主库中无此丢失归档处理),备库基于SCN恢复 环境: OS: CentOS 6.5 DB: Oracle 10.2.0.5 1.主备库环境 主库: SQL> sel ...

  5. DATAGUARD 在线重建备库

    环境: OS: CentOS 6.5 X64 DB: oracle 10.2.0.5 故障:之前由于错误激活备库主写导致主备日志同步,重建备库 1.关闭备库,删除数据文件及控制文件,redo文件 rm ...

  6. dataGuard主备库角色切换

    切换顺序: 先主库后备库 --查看主库可切换状态: SQL> select switchover_status from v$database; SWITCHOVER_STATUS ------ ...

  7. DataGuard切换(主库为Rac+备库为Rac)

    http://blog.itpub.net/29477587/viewspace-1331121/ 前段时间做了一次主备库的切换,大体写下操作步骤和记录,分享下. 环境:           db v ...

  8. OGG 从Oracle备库同步数据至kafka

    OGG 从Oracle备库同步数据至kafka Table of Contents 1. 目的 2. 环境及规划 3. 安装配置JDK 3.1. 安装jdk 3.2. 配置环境变量 4. 安装Data ...

  9. Oracle备库TNS连接失败的分析

    今天在测试12c的temp_undo的时候,准备在备库上测试一下,突然发现备库使用TNS连接竟然失败. 抛出的错误如下: $ sqlplus sys/oracle@testdb as sysdba S ...

随机推荐

  1. Lecture1 实验过程模型

    Part 1 基本概念 因变量:待检验理论重点关注的,受多个变量影响的变量.(实际考察的,结果) 自变量:影响因变量变化的变量. 因子:重点关注的自变量. 控制变量(control variables ...

  2. UVa 11987 并查集 Almost Union-Find

    原文戳这 与以往的并查集不同,这次需要一个删除操作.如果是叶子节点还好,直接修改父亲指针就好. 但是如果要是移动根节点,指向它的所有子节点也会跟着变化. 所以要增加一个永远不会被修改的虚拟根节点,这样 ...

  3. PYDay10&11&12&13-常用模块:time|datetime|os|sys|pickle|json|xml|shutil|logging|paramiko、configparser、字符串格式化、py自动全局变量、生成器迭代器

    1.py文件自动创建的全局变量 print(vars()) 返回值:{'__name__': '__main__', '__package__': None, '__loader__': <_f ...

  4. joyoi1864 守卫者的挑战

    #include <algorithm> #include <iostream> #include <cstdio> using namespace std; in ...

  5. Ext.js数据展示问题name展示code

    出现以上问题是因为model中定义的类型跟数据库不匹配 去掉js中vehicleModel的type或者改为type:'int'即可.

  6. python3--__repr_和__str__会返回字符串表达形式

    __repr_和__str__会返回字符串表达形式 下一个例子是已经见过的init构造方法和add重载方法,本例也会定义返回实例的字符串表达形式的__repr__方法.字符串格式把self.data对 ...

  7. [luoguP3110] [USACO14DEC]驮运Piggy Back(SPFA || BFS)

    传送门 以 1,2,n 为起点跑3次 bfs 或者 spfa 那么 ans = min(ans, dis[1][i] * B + dis[2][i] * E + dis[3][i] * P) (1 & ...

  8. angular中ng-class的一些用法

    在前面Angularjs开发一些经验总结中我们说到在angular开发中angular controller never 包含DOM元素(html/css),在controller需要一个简单的POJ ...

  9. golang-uuid

    uuid第三方库可以在github上找,我在这使用的是:github.com/satori/go.uuid PS:不知道哪里原因,使用go mod 管理包,下载的包和github上的不是完全一样,也特 ...

  10. HDU 5905 Black White Tree(树型DP)

    题目链接  Black White Tree 树型DP,设$f[i][j]$为以$i$为根的子树中大小为$j$的连通块中可以包含的最小黑点数目. $g[i][j]$为以$i$为根的子树中大小为$j$的 ...