标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 kfed MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-01110 ORA-01555 ORA-01578 ORA-08103 ORA-600 2131 ORA-600 2662 ORA-600 2663 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 Oracle 恢复 ORACLE恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (102)
- 数据库 (1,682)
- DB2 (22)
- MySQL (73)
- Oracle (1,544)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (159)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (7)
- Oracle ASM (67)
- Oracle Bug (8)
- Oracle RAC (53)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (565)
- Oracle安装升级 (92)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (79)
- PostgreSQL (18)
- PostgreSQL恢复 (6)
- SQL Server (27)
- SQL Server恢复 (8)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (37)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (20)
-
最近发表
- 断电引起的ORA-08102: 未找到索引关键字, 对象号 39故障处理
- ORA-00227: corrupt block detected in control file
- 手工删除19c rac
- 解决oracle数据文件路径有回车故障
- .wstop扩展名勒索数据库恢复
- Oracle Recovery Tools工具一键解决ORA-00376 ORA-01110故障(文件offline)
- OGG-02771 Input trail file format RELEASE 19.1 is different from previous trail file form at RELEASE 11.2.
- OGG-02246 Source redo compatibility level 19.0.0 requires trail FORMAT 12.2 or higher
- GoldenGate 19安装和打patch
- dd破坏asm磁盘头恢复
- 删除asmlib磁盘导致磁盘组故障恢复
- Kylin Linux 安装19c
- ORA-600 krse_arc_complete.4
- Oracle 19c 202410补丁(RUs+OJVM)
- ntfs MFT损坏(ntfs文件系统故障)导致oracle异常恢复
- .mkp扩展名oracle数据文件加密恢复
- 清空redo,导致ORA-27048: skgfifi: file header information is invalid
- A_H_README_TO_RECOVER勒索恢复
- 通过alert日志分析客户自行对一个数据库恢复的来龙去脉和点评
- ORA-12514: TNS: 监听进程不能解析在连接描述符中给出的SERVICE_NAME
标签归档:STANDBY DATABASE FINISH
DataGuard ora-16157故障解决
由于硬件故障,需要激活备库,由于登录错误服务器对本不该激活的服务器进行了如下操作
STANDBY DATABASE FINISH操作
[oracle@app73 ~]$ ss SQL*Plus: Release 11.2.0.4.0 Production on Sun Jun 26 23:33:19 2016 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 and Data Mining options SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; Database altered. SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH; Database altered.
对应的alert日志提示
Sun Jun 26 23:33:22 2016 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL Sun Jun 26 23:33:22 2016 MRP0: Background Media Recovery cancelled with status 16037 Errors in file /Data/oracle/diag/rdbms/commentdbdg/commentdb/trace/commentdb_pr00_11871.trc: ORA-16037: user requested cancel of managed recovery operation Managed Standby Recovery not using Real Time Apply Recovery interrupted! Recovered data files to a consistent state at change 47440782676 Sun Jun 26 23:33:23 2016 MRP0: Background Media Recovery process shutdown (commentdb) Managed Standby Recovery Canceled (commentdb) Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL Sun Jun 26 23:33:44 2016 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH Attempt to do a Terminal Recovery (commentdb) Media Recovery Start: Managed Standby Recovery (commentdb) started logmerger process Sun Jun 26 23:33:44 2016 Managed Standby Recovery not using Real Time Apply Parallel Media Recovery started with 4 slaves Media Recovery Waiting for thread 1 sequence 21196 (in transit) Killing 4 processes with pids 11881,11867,11869,14314 (all RFS, wait for I/O) in order to disallow current and future RFS connections. Requested by OS process 7372 Begin: Standby Redo Logfile archival End: Standby Redo Logfile archival Terminal Recovery timestamp is '06/26/2016 23:33:48' Terminal Recovery: applying standby redo logs. Terminal Recovery: thread 1 seq# 21196 redo required Terminal Recovery: Recovery of Online Redo Log: Thread 1 Group 10 Seq 21196 Reading mem 0 Mem# 0: /Data/oracle/oradata/commentdb/std_redo10.log Identified End-Of-Redo (failover) for thread 1 sequence 21196 at SCN 0xffff.ffffffff Incomplete Recovery applied until change 47440782709 time 06/26/2016 23:29:51 Media Recovery Complete (commentdb) Terminal Recovery: Enabled archive destination LOG_ARCHIVE_DEST_2 Terminal Recovery: successful completion Forcing ARSCN to IRSCN for TR 11:196142453 Attempt to set limbo arscn 11:196142453 irscn 11:196142453 Resetting standby activation ID 3880004483 (0xe7442b83) Sun Jun 26 23:33:48 2016 ARCH: Archival stopped, error occurred. Will continue retrying ORACLE Instance commentdb - Archival Error ORA-16014: log 10 sequence# 21196 not archived, no available destinations ORA-00312: online log 10 thread 1: '/Data/oracle/oradata/commentdb/std_redo10.log' Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH Sun Jun 26 23:39:24 2016 RFS[4]: Assigned to RFS process 7392 RFS[4]: No connections allowed during/after terminal recovery.
很明显数据库已经挺尸mrp并且成功执行了ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH
尝试重新启动mrp应用日志
SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down. SQL> startup mount; ORACLE instance started. Total System Global Area 2.1379E+10 bytes Fixed Size 2262656 bytes Variable Size 2684356992 bytes Database Buffers 1.8656E+10 bytes Redo Buffers 36073472 bytes Database mounted. SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; Database altered.
alert日志提示
Sun Jun 26 23:40:39 2016 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION Attempt to start background Managed Standby Recovery process (commentdb) Sun Jun 26 23:40:39 2016 MRP0 started with pid=24, OS id=7458 MRP0: Background Managed Standby Recovery process started (commentdb) started logmerger process Sun Jun 26 23:40:44 2016 Managed Standby Recovery starting Real Time Apply MRP0: Background Media Recovery terminated with error 16157 Errors in file /Data/oracle/diag/rdbms/commentdbdg/commentdb/trace/commentdb_pr00_7460.trc: ORA-16157: media recovery not allowed following successful FINISH recovery Managed Standby Recovery not using Real Time Apply Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION Recovery Slave PR00 previously exited with exception 16157 MRP0: Background Media Recovery process shutdown (commentdb) [oracle@app73 trace]$ oerr ora 16157 16157, 00000, "media recovery not allowed following successful FINISH recovery" // *Cause: A RECOVER MANAGED STANDBY DATABASE FINISH command has previously // completed successfully. Another media recovery is not allowed. // *Action: Issue one of these operations following a FINISH recocvery: // ALTER DATABASE OPEN READ ONLY or // ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY.
前台虽然提示mrp启动成功,但是alert日志提示启动mrp进程失败,原因是由于media recovery not allowed following successful FINISH recovery,也就是说由于我开始已经执行了ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH导致无法继续启动mrp进程,也就无法继续应用日志。
查看mos看看是否有解决方案
根据官方的说法只能重建dg,实在不甘心,个人感觉ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH执行完成,但是我没有failover命令执行,应该数据文件没有改变,只是控制文件发生了改变。
解决ora-16157问题
从主库重新生成standby controlfile并且传输到备库,再次尝试启动mrp
--主库操作 SQL> ALTER DATABASE CREATE standby CONTROLFILE AS '/tmp/controlfs01.ctl'; Database altered. --scp到备库 SQL> shutdown immediate; ORA-01109: database not open Database dismounted. ORACLE instance shut down. SQL> startup nomount; ORACLE instance started. Total System Global Area 2.1379E+10 bytes Fixed Size 2262656 bytes Variable Size 2684356992 bytes Database Buffers 1.8656E+10 bytes Redo Buffers 36073472 bytes [oracle@app73 ~]$ cp /tmp/controlfs01.ctl /Data/oracle/oradata/commentdb/control01.ctl [oracle@app73 ~]$ cp /tmp/controlfs01.ctl /Data/oracle/fast_recovery_area/commentdb/control02.ctl SQL> alter database mount; Database altered. SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; Database altered.
观察alert日志
ARC2: Becoming the active heartbeat ARCH Completed: alter database mount ARC3: Archival started ARC0: STARTING ARCH PROCESSES COMPLETE ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION Attempt to start background Managed Standby Recovery process (commentdb) Sun Jun 26 23:46:50 2016 MRP0 started with pid=24, OS id=7547 MRP0: Background Managed Standby Recovery process started (commentdb) Sun Jun 26 23:46:54 2016 RFS[1]: Assigned to RFS process 7553 RFS[1]: Selected log 10 for thread 1 sequence 21197 dbid -414945661 branch 893285763 Sun Jun 26 23:46:54 2016 Primary database is in MAXIMUM PERFORMANCE mode RFS[2]: Assigned to RFS process 7555 RFS[2]: Selected log 11 for thread 1 sequence 21198 dbid -414945661 branch 893285763 Archived Log entry 1 added for thread 1 sequence 21197 ID 0xe7442b83 dest 1: started logmerger process Sun Jun 26 23:46:55 2016 Managed Standby Recovery starting Real Time Apply Parallel Media Recovery started with 4 slaves Waiting for all non-current ORLs to be archived... All non-current ORLs have been archived. Sun Jun 26 23:46:56 2016 Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION Sun Jun 26 23:47:06 2016 Media Recovery Waiting for thread 1 sequence 21196 Fetching gap sequence in thread 1, gap sequence 21196-21196 Sun Jun 26 23:47:06 2016 RFS[3]: Assigned to RFS process 7567 RFS[3]: Opened log for thread 1 sequence 21196 dbid -414945661 branch 893285763 Archived Log entry 2 added for thread 1 sequence 21196 rlc 893285763 ID 0xe7442b83 dest 2: Media Recovery Log /Data/oracle/fast_recovery_area/COMMENTDBDG/archivelog/2016_06_26/o1_mf_1_21196_cpzy7tjc_.arc Media Recovery Log /Data/oracle/fast_recovery_area/COMMENTDBDG/archivelog/2016_06_26/o1_mf_1_21197_cpzy7gtl_.arc Media Recovery Waiting for thread 1 sequence 21198 (in transit) Recovery of Online Redo Log: Thread 1 Group 11 Seq 21198 Reading mem 0 Mem# 0: /Data/oracle/oradata/commentdb/std_redo11.log
到这里已经证明,通过重建standby controlfile实现了即使执行了ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH(ORA-16157)也可以通过不重建dg,让其恢复正常(恢复dg状态).