标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-00742 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)
- 操作系统 (103)
- 数据库 (1,706)
- DB2 (22)
- MySQL (74)
- Oracle (1,567)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (159)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (68)
- Oracle Bug (8)
- Oracle RAC (53)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (571)
- Oracle安装升级 (94)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (81)
- 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)
-
最近发表
- _gc_undo_affinity=FALSE触发ORA-01558
- public授权语句
- 中文环境显示AR8MSWIN1256(阿拉伯语字符集)
- 处理 Oracle 块损坏
- Oracle各种类型坏块说明和处理
- fio测试io,导致磁盘文件系统损坏故障恢复
- ORA-742 写丢失常见bug记录
- Oracle 19c 202501补丁(RUs+OJVM)-19.26
- 避免 19c 数据库性能问题需要考虑的事项 (Doc ID 3050476.1)
- Bug 21915719 Database hang or may fail to OPEN in 12c IBM AIX or HPUX Itanium – ORA-742, DEADLOCK or ORA-600 [kcrfrgv_nextlwn_scn] ORA-600 [krr_process_read_error_2]
- ORA-600 ktuPopDictI_1恢复
- impdp导入数据丢失sys授权问题分析
- impdp 创建index提示ORA-00942: table or view does not exist
- 数据泵导出 (expdp) 和导入 (impdp)工具性能降低分析参考
- 19c非归档数据库断电导致ORA-00742故障恢复
- Oracle 19c – 手动升级到 Non-CDB Oracle Database 19c 的完整核对清单
- sqlite数据库简单操作
- Oracle 暂定和恢复功能
- .pzpq扩展名勒索恢复
- Oracle read only用户—23ai新特性:只读用户
分类目录归档:Data Guard
12.2 standby 报ORA-01110
12.2备库报错
2018-06-13T19:29:00.302767+08:00 Errors in file /u01/app/oracle/diag/rdbms/xifenfeidg/xifenfei/trace/xifenfei_m000_2457.trc: ORA-01110: data file 1: '/u01/app/oracle/oradata/xifenfei/system01.dbf' 2018-06-13T19:29:00.829861+08:00 Errors in file /u01/app/oracle/diag/rdbms/xifenfeidg/xifenfei/trace/xifenfei_m000_2457.trc: ORA-01110: data file 2: '/u01/app/oracle/oradata/xifenfei/rich101.dbf' 2018-06-13T19:29:00.930632+08:00 Errors in file /u01/app/oracle/diag/rdbms/xifenfeidg/xifenfei/trace/xifenfei_m000_2457.trc: ORA-01110: data file 3: '/u01/app/oracle/oradata/xifenfei/sysaux01.dbf' 2018-06-13T19:29:01.010230+08:00 Errors in file /u01/app/oracle/diag/rdbms/xifenfeidg/xifenfei/trace/xifenfei_m000_2457.trc: ORA-01110: data file 4: '/u01/app/oracle/oradata/xifenfei/undotbs01.dbf' 2018-06-13T11:29:01.055975+00:00 Archived Log entry 5072 added for T-1.S-5020 ID 0x6a8e9d72 LAD:1 RFS[18]: Selected log 10 for T-1.S-5024 dbid 1787743346 branch 957530932 2018-06-13T19:29:01.091059+08:00 Errors in file /u01/app/oracle/diag/rdbms/xifenfeidg/xifenfei/trace/xifenfei_m000_2457.trc: ORA-01110: data file 5: '/u01/app/oracle/oradata/xifenfei/richman01.dbf' 2018-06-13T19:29:01.172613+08:00 Errors in file /u01/app/oracle/diag/rdbms/xifenfeidg/xifenfei/trace/xifenfei_m000_2457.trc: ORA-01110: data file 7: '/u01/app/oracle/oradata/xifenfei/users01.dbf' 2018-06-13T19:29:01.251906+08:00 Errors in file /u01/app/oracle/diag/rdbms/xifenfeidg/xifenfei/trace/xifenfei_m000_2457.trc: ORA-01110: data file 8: '/u01/app/oracle/oradata/xifenfei/r_index01.dbf'
trace文件
*** 2018-06-13T19:29:00.282836+08:00 *** SESSION ID:(2281.15120) 2018-06-13T19:29:00.282868+08:00 *** CLIENT ID:() 2018-06-13T19:29:00.282873+08:00 *** SERVICE NAME:(SYS$BACKGROUND) 2018-06-13T19:29:00.282878+08:00 *** MODULE NAME:(MMON_SLAVE) 2018-06-13T19:29:00.282883+08:00 *** ACTION NAME:(DDE async action) 2018-06-13T19:29:00.282888+08:00 *** CLIENT DRIVER:() 2018-06-13T19:29:00.282892+08:00 ========= Dump for error ORA 312 (no incident) ======== ----- DDE Action: 'DB_STRUCTURE_INTEGRITY_CHECK' (Async) ----- dbkh_reactive_run_check: BEGIN dbkh_reactive_run_check:; incident_id=0 dbkh_run_check_internal: BEGIN; check_namep=DB Structure Integrity Check, run_namep=<null> dbkh_run_check_internal: BEGIN; timeout=0 dbkh_run_check_internal: AFTER RUN CREATE; run_id=1841 *** 2018-06-13T19:29:00.302510+08:00 DDE previous invocation failed before phase II DDE was called in a 'No Invocation Mode' ----- Start Diag Diagnostic Dump ----- Diagnostic dump is performed due to an error in the diagfw code during error handling. Dump error and call stack for the diagnostic dump: *** 2018-06-13T19:29:00.302576+08:00 dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x0, level=1, mask=0x0) ----- Error Stack Dump ----- ORA-01110: data file 1: '/u01/app/oracle/oradata/xifenfei/system01.dbf' ----- SQL Statement (None) ----- Current SQL information unavailable - no cursor. ----- Call Stack Trace ----- calling call entry argument values in hex location type point (? means dubious value) -------------------- -------- -------------------- ---------------------------- ksedst()+119 call kgdsdst() 7FFF1A0D6C68 000000002 7FFF1A0B86D0 ? 7FFF1A0B87E8 ? 000000000 000000082 ? dbkedDefDump()+1200 call ksedst() 000000000 000000002 ? 7FFF1A0B86D0 ? 7FFF1A0B87E8 ? 000000000 ? 000000082 ? ksedmp()+259 call dbkedDefDump() 000000001 000000000 7FFF1A0B86D0 ? 7FFF1A0B87E8 ? 000000000 ? 000000082 ? dbgexExecuteIntDiag call ksedmp() 000000001 000000000 ? Dmp()+1457 7FFF1A0B86D0 ? 7FFF1A0B87E8 ? 000000000 ? 000000082 ? dbgeBeginInvoke()+3 call dbgexExecuteIntDiag 7F5A00000003 7F5A99B856C0 59 Dmp() 7FFF1A0B86D0 ? 7FFF1A0B87E8 ? 000000000 ? 000000082 ? dbgePostErrorKGE()+ call dbgeBeginInvoke() 7F5A99B856C0 7FFF1A0D7D20 1676 7FFF1A0B86D0 ? 7FFF1A0B87E8 ? 000000000 ? 000000082 ? dbkePostKGE_kgsf()+ call dbgePostErrorKGE() 7F5A99BC59A0 7F5A99AA0048 90 000000456 7FFF1A0B87E8 ? 000000000 ? 000000082 ? kgeade()+432 call dbkePostKGE_kgsf() 7F5A99BC59A0 7F5A99AA0048 000000456 7FFF1A0B87E8 ? 000000000 ? 000000082 ? kgerelv()+144 call kgeade() 7F5A99BC59A0 ? 7F5A99BC5BE8 ? 7F5A99AA0048 ? 000000456 ? 000000000 000000000 kgerev()+36 call kgerelv() 7F5A99BC59A0 ? 7F5A99AA0048 ? 7F5A99AA0048 ? 000000456 ? 012E79CF4 ? 000000002 ? kserec2()+185 call kgerev() 7F5A99BC59A0 ? 7F5A99AA0048 ? 7F5A99AA0048 ? 000000456 ? 7FFF1A0D8000 000000002 ? kcf_record_fn()+634 call kserec2() 7F5A99BC59A0 ? 000000000 000000001 000000001 00000002C 141E0C518 kcvvra_dfh()+5278 call kcf_record_fn() 000000001 151622BB8 000000000 7FFF1A0DA5D8 00000002C ? 141E0C518 ? kcidr_file_header_c call kcvvra_dfh() 7FFF1A0DA460 ? 7FFF1A0D9FE8 ? heck_common()+4669 000000000 ? 7FFF1A0D9398 7F5A94379000 ? 000000001 ? kcidr_file_header_a call kcidr_file_header_c 7F5A99A9F7A0 7F5A94379000 ll_check_common()+2 heck_common() 000000001 000000000 259 7F5A94379000 ? 000000000 kcidr_cross_check() call kcidr_file_header_a 7F5A99A9F7A0 7FFF1A0DABE4 +566 ll_check_common() 000000001 ? 000000000 ? 7F5A94379000 ? 000000000 ? dbkird_cross_check( call kcidr_cross_check() 7F5A99A9F7A0 7FFF1A0DABE4 ? )+557 7F5A99BC5BE8 000000000 ? 7F5A94379000 ? 000000000 ? dbkh_run_check_inte call dbkird_cross_check( 7F5A99A9F7A0 7FFF1A0DABE4 ? rnal()+2228 ) 7F5A99BC5BE8 ? 000000000 ? 7F5A94379000 ? 000000000 ? dbkh_reactive_run_c call dbkh_run_check_inte 7FFF1A0DB970 000000000 heck()+3011 rnal() 000000002 000000000 000000000 000000000 dbgdaAsyncReceive() call dbkh_reactive_run_c 7F5A99B856C0 7FFF1A0DBC90 +279 heck() 000000002 ? 000000000 ? 000000000 ? 000000000 ? dbgea_exec_()+1739 call dbgdaAsyncReceive() 7F5A99B856C0 0020C0029 7FFF1A0E7CA0 7FFF1A0E7D20 000000002 000000000 ? dbgea_exec()+621 call dbgea_exec_() 7F5A99B856C0 7F5A94984D18 0000000E8 000000000 000000002 ? 000000000 ? dbkea_exec()+1718 call dbgea_exec() 7F5A99B856C0 7F5A94984D18 0000000E8 000000000 000000002 ? 000000000 ? dbkea_slave_exec()+ call dbkea_exec() 7F5A99B856C0 ? 7F5A94984D18 ? 518 0000000E8 ? 000000000 ? 000000002 ? 000000000 ? kebm_slave_cb()+64 call dbkea_slave_exec() 1453D7248 7F5A94984D18 ? 0000000E8 ? 000000000 ? 000000002 ? 000000000 ? kebm_slave_main()+7 call kebm_slave_cb() 1453D7248 ? 7F5A94984D18 ? 72 0000000E8 ? 000000000 ? 000000002 ? 000000000 ? ksvrdp_int()+2010 call kebm_slave_main() 1453D7248 ? 1453D7248 0000000E8 ? 000000000 ? 000000002 ? 000000000 ? opirip()+602 call ksvrdp_int() 000000000 ? 000000000 ? 0000000E8 ? 000000000 ? 000000002 ? 000000000 ? opidrv()+602 call opirip() 000000032 000000004 7FFF1A0EAD98 000000000 ? 000000002 ? 000000000 ? sou2o()+145 call opidrv() 000000032 000000004 7FFF1A0EAD98 000000000 ? 000000002 ? 000000000 ? opimai_real()+202 call sou2o() 7FFF1A0EAD70 000000032 000000004 7FFF1A0EAD98 000000002 ? 000000000 ? ssthrdmain()+417 call opimai_real() 000000000 7FFF1A0EB080 000000004 ? 7FFF1A0EAD98 ? 000000002 ? 000000000 ? main()+262 call ssthrdmain() 000000000 000000003 7FFF1A0EB080 000000001 000000000 000000000 ? __libc_start_main() call main() 000000000 7FFF1A0EB2B8 +245 7FFF1A0EB080 ? 000000001 ? 000000000 ? 000000000 ? _start()+41 call __libc_start_main() 000D05240 000000001 7FFF1A0EB2B8 7F5A95015C05 ? 000000000 ? 000000000 ? --------------------- Binary Stack Dump ---------------------
BUG:24844841 – PHSB:CDB M000 REPORTED ORA-1110 ON ADG WHEN A DATAFILE IS ADDED ON PRIMARY
@ The M000 messages is a false alarm as well. It is a false alarm by DRA check
@ that doesn’t consider standby media recovery properly. Adding a file happens
@ to trigger the timing for the false alarm.
@ One way to fix this is to skip file header check if standby recovery is
@ running inside kcidr_file_header_all_check_common.
M000进程检查数据库文件头信息,由于bug原因报ORA-01110错误.
处理建议
1.打上补丁24844841
2.19.1版本修复该问题
3.重启备库,启动mgr
4.暂时忽略该问题(目前没有发现影响数据库同步)
参考:ORA-01110 For All Files In Standby Database (Doc ID 2322290.1)
dataguard配合flashback实现主备任意切换(failover和switchover)
有客户使用本地和公有云通过vpn搭建数据库容灾,其中有一个需求,当本地环境出现问题云端容灾库接管业务,当本地环境恢复之后,本地继续做为主库,云端作为备库.我这里使用oracle dataguard结合flashback模拟实现客户需求(也可以在failover之后通过重新搭建dg实现类似需求,具体需要看客户的实际场景:数据量,带宽,恢复时间,技术能力等)
正常dg同步的主备环境
这里ora11g主机是主库,ora10g主机是备库
--数据库版本 SQL> select * from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production PL/SQL Release 11.2.0.4.0 - Production CORE 11.2.0.4.0 Production TNS for Linux: Version 11.2.0.4.0 - Production NLSRTL Version 11.2.0.4.0 - Production ---主库(ora11g) SQL> select open_mode,database_role,(select HOST_NAME from v$instance) HOST_NAME,flashback_on from v$database; OPEN_MODE DATABASE_ROLE HOST_NAME FLASHBACK_ ------------------------------ ------------------------------ ------------------------------ ---------- READ WRITE PRIMARY ora11g YES SQL> create table xff.t_xifenfei as select * from dba_objects; Table created. SQL> select count(*) from xff.t_xifenfei; COUNT(*) ---------- 86348 ---备库(ora10g) SQL> select open_mode,database_role,(select HOST_NAME from v$instance) HOST_NAME,flashback_on from v$database; OPEN_MODE DATABASE_ROLE HOST_NAME FLASHBACK_ ------------------------------ ------------------------------ ------------------------------ ---------- READ ONLY WITH APPLY PHYSICAL STANDBY ora10g YES SQL> select count(*) from xff.t_xifenfei; COUNT(*) ---------- 86348
模拟主库(ora11g)故障,直接激活备库(ora10g)
模拟dg备库(ora10g)直接failover操作
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; Database altered. SQL> ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE; Database altered.
Sat Mar 24 16:05:40 2017 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL MRP0: Background Media Recovery cancelled with status 16037 Errors in file /u01/app/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_pr00_13428.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 1470499 Sat Mar 24 16:05:40 2017 MRP0: Background Media Recovery process shutdown (ora11g) Managed Standby Recovery Canceled (ora11g) Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL Sat Mar 24 16:05:50 2017 ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE ALTER DATABASE ACTIVATE [PHYSICAL] STANDBY DATABASE (ora11g) All dispatchers and shared servers shutdown CLOSE: killing server sessions. CLOSE: all sessions shutdown successfully. Sat Mar 24 16:05:50 2017 SMON: disabling cache recovery Killing 3 processes with pids 13372,13393,13388 (all RFS) in order to disallow current and future RFS connections. Requested by OS process 13350 Begin: Standby Redo Logfile archival End: Standby Redo Logfile archival RESETLOGS after incomplete recovery UNTIL CHANGE 1470499 Archived Log entry 9 added for thread 1 sequence 14 ID 0xfd5a5fc1 dest 1: Resetting resetlogs activation ID 4250558401 (0xfd5a5fc1) Online log /u01/app/oracle/oradata/ora11g/redo01.log: Thread 1 Group 1 was previously cleared Online log /u01/app/oracle/oradata/ora11g/redo02.log: Thread 1 Group 2 was previously cleared Online log /u01/app/oracle/oradata/ora11g/redo03.log: Thread 1 Group 3 was previously cleared Standby became primary SCN: 1470497 Sat Mar 24 16:05:52 2017 Setting recovery target incarnation to 4 ACTIVATE STANDBY: Complete - Database mounted as primary Completed: ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE
模拟新主库(ora10g)业务操作
SQL> select open_mode,database_role,(select HOST_NAME from v$instance) HOST_NAME,flashback_on from v$database; OPEN_MODE DATABASE_ROLE HOST_NAME FLASHBACK_ ------------------------------ ------------------------------ ------------------------------ ---------- MOUNTED PRIMARY ora10g YES SQL> alter database open; Database altered. SQL> select open_mode,database_role,(select HOST_NAME from v$instance) HOST_NAME,flashback_on from v$database; OPEN_MODE DATABASE_ROLE HOST_NAME FLASHBACK_ ------------------------------ ------------------------------ ------------------------------ ---------- READ WRITE PRIMARY ora10g YES SQL> alter system switch logfile; System altered. SQL> / System altered. SQL> / / System altered. SQL> System altered. SQL> SQL> archive log list; Database log mode Archive Mode Automatic archival Enabled Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 5 Next log sequence to archive 7 Current log sequence 7 SQL> delete from xff.t_xifenfei; 86348 rows deleted. SQL> commit; Commit complete. SQL> select count(*) from xff.t_xifenfei; COUNT(*) ---------- 0
原主库(ora11g)配置为新备库
---原主库(ora10g) SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down. SQL> startup mount ORACLE instance started. Total System Global Area 3056513024 bytes Fixed Size 2257152 bytes Variable Size 704646912 bytes Database Buffers 2332033024 bytes Redo Buffers 17575936 bytes Database mounted. SQL> Flashback database to scn 1470490; Flashback complete. SQL> select open_mode,database_role,(select HOST_NAME from v$instance) HOST_NAME,flashback_on from v$database; OPEN_MODE DATABASE_ROLE HOST_NAME FLASHBACK_ ------------------------------ ------------------------------ ------------------------------ ---------- MOUNTED PRIMARY ora11g YES --现在主库(ora10g) SQL> alter database create standby controlfile as '/tmp/ctl.3'; Database altered. [oracle@ora10g ~]$ scp /tmp/ctl.3 192.168.222.11:/u01/app/oracle/oradata/ora11g/control01.ctl oracle@192.168.222.11's password: ctl.3 ---也可以直接在老主库上执行ALTER DATABASE CONVERT TO PHYSICAL STANDBY; 转换为standby 角色,然后直接启动同步 --现在备库(ora11g) SQL> shutdown abort ORACLE instance shut down. SQL> startup mount ORACLE instance started. Total System Global Area 3056513024 bytes Fixed Size 2257152 bytes Variable Size 704646912 bytes Database Buffers 2332033024 bytes Redo Buffers 17575936 bytes Database mounted. SQL> col open_mode for a30 SQL> col database_role for a30 SQL> col HOST_NAME for a30 SQL> col flashback_on for a10 SQL> set lines 150 SQL> select open_mode,database_role,(select HOST_NAME from v$instance) HOST_NAME,flashback_on from v$database; OPEN_MODE DATABASE_ROLE HOST_NAME FLASHBACK_ ------------------------------ ------------------------------ ------------------------------ ---------- MOUNTED PHYSICAL STANDBY ora11g NO SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; Database altered.
Sat Mar 24 16:10:09 2017 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION Attempt to start background Managed Standby Recovery process (ora11g) Sat Mar 24 16:10:09 2017 MRP0 started with pid=27, OS id=27086 MRP0: Background Managed Standby Recovery process started (ora11g) started logmerger process Sat Mar 24 16:10:14 2017 Managed Standby Recovery starting Real Time Apply Parallel Media Recovery started with 4 slaves Media Recovery start incarnation depth : 1, target inc# : 4, irscn : 1470499 Waiting for all non-current ORLs to be archived... All non-current ORLs have been archived. Clearing online redo logfile 1 /u01/app/oracle/oradata/ora11g/redo01.log Clearing online log 1 of thread 1 sequence number 7 Clearing online redo logfile 1 complete Clearing online redo logfile 2 /u01/app/oracle/oradata/ora11g/redo02.log Clearing online log 2 of thread 1 sequence number 8 Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION Clearing online redo logfile 2 complete Clearing online redo logfile 3 /u01/app/oracle/oradata/ora11g/redo03.log Clearing online log 3 of thread 1 sequence number 9 Clearing online redo logfile 3 complete Media Recovery Waiting for thread 1 sequence 13 branch(resetlogs_id) 854379205 Sat Mar 24 16:10:16 2017 RFS[3]: Assigned to RFS process 27098 RFS[3]: Opened log for thread 1 sequence 13 dbid 48871109 branch 854379205 Archived Log entry 2 added for thread 1 sequence 13 rlc 854379205 ID 0xfd5a5fc1 dest 2: Sat Mar 24 16:10:16 2017 RFS[4]: Assigned to RFS process 27100 RFS[4]: Opened log for thread 1 sequence 14 dbid 48871109 branch 854379205 Archived Log entry 3 added for thread 1 sequence 14 rlc 854379205 ID 0xfd5a5fc1 dest 2: RFS[3]: Opened log for thread 1 sequence 1 dbid 48871109 branch 947798452 RFS[4]: Opened log for thread 1 sequence 3 dbid 48871109 branch 947798452 Sat Mar 24 16:10:16 2017 RFS[5]: Assigned to RFS process 27070 RFS[5]: Opened log for thread 1 sequence 2 dbid 48871109 branch 947798452 Archived Log entry 4 added for thread 1 sequence 1 rlc 947798452 ID 0x2ec1ed0 dest 2: Archived Log entry 5 added for thread 1 sequence 3 rlc 947798452 ID 0x2ec1ed0 dest 2: RFS[3]: Opened log for thread 1 sequence 4 dbid 48871109 branch 947798452 RFS[4]: Opened log for thread 1 sequence 5 dbid 48871109 branch 947798452 Archived Log entry 6 added for thread 1 sequence 5 rlc 947798452 ID 0x2ec1ed0 dest 2: Archived Log entry 7 added for thread 1 sequence 4 rlc 947798452 ID 0x2ec1ed0 dest 2: Archived Log entry 8 added for thread 1 sequence 2 rlc 947798452 ID 0x2ec1ed0 dest 2: RFS[4]: Opened log for thread 1 sequence 6 dbid 48871109 branch 947798452 Archived Log entry 9 added for thread 1 sequence 6 rlc 947798452 ID 0x2ec1ed0 dest 2: RFS[3]: Opened log for thread 1 sequence 7 dbid 48871109 branch 947798452 Archived Log entry 10 added for thread 1 sequence 7 rlc 947798452 ID 0x2ec1ed0 dest 2: Media Recovery Log /u01/app/oracle/fast_recovery_area/ORA11GDG/archivelog/2017_03_24/o1_mf_1_13_9xmyh8cs_.arc Media Recovery Log /u01/app/oracle/fast_recovery_area/ORA11GDG/archivelog/2017_03_24/o1_mf_1_14_9xmyh8dr_.arc Media Recovery Log /u01/app/oracle/fast_recovery_area/ORA11GDG/archivelog/2017_03_24/o1_mf_1_1_9xmyh8fk_.arc Media Recovery Log /u01/app/oracle/fast_recovery_area/ORA11GDG/archivelog/2017_03_24/o1_mf_1_2_9xmyh8fo_.arc Media Recovery Log /u01/app/oracle/fast_recovery_area/ORA11GDG/archivelog/2017_03_24/o1_mf_1_3_9xmyh8fm_.arc Media Recovery Log /u01/app/oracle/fast_recovery_area/ORA11GDG/archivelog/2017_03_24/o1_mf_1_4_9xmyh8g3_.arc Media Recovery Log /u01/app/oracle/fast_recovery_area/ORA11GDG/archivelog/2017_03_24/o1_mf_1_5_9xmyh8g4_.arc Media Recovery Log /u01/app/oracle/fast_recovery_area/ORA11GDG/archivelog/2017_03_24/o1_mf_1_6_9xmyh8gs_.arc Media Recovery Log /u01/app/oracle/fast_recovery_area/ORA11GDG/archivelog/2017_03_24/o1_mf_1_7_9xmyh8hl_.arc Media Recovery Log /u01/app/oracle/fast_recovery_area/ORA11GDG/archivelog/2017_03_24/o1_mf_1_8_9xmy5d3f_.arc Media Recovery Waiting for thread 1 sequence 9 (in transit) Recovery of Online Redo Log: Thread 1 Group 4 Seq 9 Reading mem 0 Mem# 0: /u01/app/oracle/oradata/ora11g/std_redo10.log
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE cancel; Database altered. SQL> alter database open; Database altered. SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; Database altered. SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE cancel; Database altered. SQL> alter database flashback on; Database altered. SQL> select open_mode,database_role,(select HOST_NAME from v$instance) HOST_NAME,flashback_on from v$database; OPEN_MODE DATABASE_ROLE HOST_NAME FLASHBACK_ ------------------------------ ------------------------------ ------------------------------ ---------- READ ONLY PHYSICAL STANDBY ora11g YES SQL> select count(*) from xff.t_xifenfei; COUNT(*) ---------- 0 --现在主库 SQL> drop table xff.t_xifenfei ; Table dropped. SQL> select count(*) from xff.t_xifenfei; select count(*) from xff.t_xifenfei * ERROR at line 1: ORA-00942: table or view does not exist --现在备库 SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; Database altered. SQL> select open_mode,database_role,(select HOST_NAME from v$instance) HOST_NAME,flashback_on from v$database; OPEN_MODE DATABASE_ROLE HOST_NAME FLASHBACK_ ------------------------------ ------------------------------ ------------------------------ ---------- READ ONLY WITH APPLY PHYSICAL STANDBY ora11g YES SQL> select count(*) from xff.t_xifenfei; select count(*) from xff.t_xifenfei * ERROR at line 1: ORA-00942: table or view does not exist
通过上述一系列操作,以前假设故障的主库,现在变成了被failover激活的主库的备库,也就是说数据库主备关系由ora11g主库—>ora10g备库变成了ora10g主库—>ora11g备库
switchover实现主备库互换
---现在主库(ora10g) SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY WITH SESSION SHUTDOWN; Database altered. --现在备库(ora11g) SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN; Database altered. SQL> select open_mode,database_role,(select HOST_NAME from v$instance) HOST_NAME,flashback_on from v$database; OPEN_MODE DATABASE_ROLE HOST_NAME FLASHBACK_ ------------------------------ ------------------------------ ------------------------------ ---------- MOUNTED PRIMARY ora11g YES SQL> alter database open; Database altered. SQL> select open_mode,database_role,(select HOST_NAME from v$instance) HOST_NAME,flashback_on from v$database; OPEN_MODE DATABASE_ROLE HOST_NAME FLASHBACK_ ------------------------------ ------------------------------ ------------------------------ ---------- READ WRITE PRIMARY ora11g YES --最新备库(ora10g) SQL> startup ORACLE instance started. Total System Global Area 3056513024 bytes Fixed Size 2257152 bytes Variable Size 687869696 bytes Database Buffers 2348810240 bytes Redo Buffers 17575936 bytes Database mounted. Database opened. SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; Database altered. SQL> select open_mode,database_role,(select HOST_NAME from v$instance) HOST_NAME,flashback_on from v$database; OPEN_MODE DATABASE_ROLE HOST_NAME FLASHBACK_ ------------------------------ ------------------------------ ------------------------------ ---------- READ ONLY WITH APPLY PHYSICAL STANDBY ora10g YES --最新主库(ora11g) SQL> alter system switch logfile; System altered. SQL> create table t_xifenfei as select * from dba_objects; Table created. SQL> select count(*) from t_xifenfei; COUNT(*) ---------- 86347 --最新备库(ora10g) SQL> select count(*) from t_xifenfei; COUNT(*) ---------- 86347
通过switchover主备库再次互换由ora10g主库—>ora11g备库变成了ora11g主库—>ora10g备库,再次恢复到最初的状态.这个不是唯一的方法,可以通过重建dg,也能够实现类似需求.
Oracle 12c active dataguard switchover
从12.1开始adg的切换发生了一些改变,直接使用alter database switchover to [target standby db_unique_name] verify; alter database switchover to [target standby db_unique_name]; 即可完成切换,以下是一次生产环境的具体操作步骤
主库操作
SQL> select database_role from v$database; DATABASE_ROLE ---------------- PRIMARY SQL> alter database switchover to xifenfei verify; 数据库已更改。 --alert日志 Sun Jun 25 09:07:08 2017 diag_adl:SWITCHOVER VERIFY: Send VERIFY request to switchover target xifenfei diag_adl:SWITCHOVER VERIFY COMPLETE SQL> alter database switchover to xifenfei; 数据库已更改。 --alert日志 Sun Jun 25 09:07:46 2017 diag_adl:Starting switchover [Process ID: 37024] Sun Jun 25 09:07:46 2017 diag_adl:ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY [Process Id: 37024] (xifenfei) diag_adl:Waiting for target standby to receive all redo Sun Jun 25 09:07:46 2017 diag_adl:Waiting for all non-current ORLs to be archived... Sun Jun 25 09:07:46 2017 diag_adl:All non-current ORLs have been archived. Sun Jun 25 09:07:46 2017 diag_adl:Waiting for all FAL entries to be archived... Sun Jun 25 09:07:46 2017 diag_adl:All FAL entries have been archived. Sun Jun 25 09:07:46 2017 diag_adl:Waiting for dest_id 2 to become synchronized... Sun Jun 25 09:07:47 2017 diag_adl:Active, synchronized Physical Standby switchover target has been identified diag_adl:Preventing updates and queries at the Primary diag_adl:Generating and shipping final logs to target standby diag_adl:Switchover End-Of-Redo Log thread 1 sequence 96534 has been fixed diag_adl:Switchover: Primary highest seen SCN set to 0x3.0x109d7502 diag_adl:ARCH: Noswitch archival of thread 1, sequence 96534 diag_adl:ARCH: End-Of-Redo Branch archival of thread 1 sequence 96534 diag_adl:ARCH: LGWR is scheduled to archive destination LOG_ARCHIVE_DEST_2 after log switch diag_adl:ARCH: Standby redo logfile selected for thread 1 sequence 96534 for destination LOG_ARCHIVE_DEST_2 diag_adl:ARCH: Archiving is disabled due to current logfile archival diag_adl:Primary will check for some target standby to have received all redo diag_adl:Waiting for target standby to apply all redo diag_adl:Backup controlfile written to trace file /u01/app/oracle/diag/rdbms/xifenfeildg/xifenfei/trace/xifenfei_ora_37024.trc diag_adl:Converting the primary database to a new standby database diag_adl:Clearing standby activation ID 612004791 (0x247a73b7) diag_adl:The primary database controlfile was created using the diag_adl:'MAXLOGFILES 16' clause. diag_adl:There is space for up to 11 standby redo logfiles diag_adl:Use the following SQL commands on the standby database to create diag_adl:standby redo logfiles that match the primary database: diag_adl:ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 1073741824; diag_adl:ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 1073741824; diag_adl:ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 1073741824; diag_adl:ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 1073741824; diag_adl:ALTER DATABASE ADD STANDBY LOGFILE 'srl5.f' SIZE 1073741824; diag_adl:ALTER DATABASE ADD STANDBY LOGFILE 'srl6.f' SIZE 1073741824; diag_adl:Archivelog for thread 1 sequence 96534 required for standby recovery diag_adl:Switchover: Primary controlfile converted to standby controlfile succesfully. diag_adl:Switchover: Complete - Database shutdown required diag_adl:Sending request(convert to primary database) to switchover target xifenfei Sun Jun 25 09:07:58 2017 diag_adl:Switchover complete. Database shutdown required diag_adl:USER (ospid: 37024): terminating the instance Sun Jun 25 09:07:59 2017 diag_adl:Instance terminated by USER, pid = 37024 diag_adl:Shutting down instance (abort) diag_adl:License high water mark = 527 Sun Jun 25 09:07:59 2017 Instance shutdown complete
备库alert日志
Sun Jun 25 09:05:54 2017 SWITCHOVER VERIFY BEGIN SWITCHOVER VERIFY COMPLETE Sun Jun 25 09:06:35 2017 RFS[107]: Assigned to RFS process (PID:7330) RFS[107]: Selected log 12 for thread 1 sequence 96534 dbid 588725663 branch 916962073 Sat Jun 24 20:06:35 2017 Archived Log entry 100576 added for thread 1 sequence 96534 ID 0x247a73b7 dest 1: Sat Jun 24 20:06:35 2017 Resetting standby activation ID 612004791 (0x247a73b7) Sat Jun 24 20:06:35 2017 Media Recovery End-Of-Redo indicator encountered Sat Jun 24 20:06:35 2017 Media Recovery Continuing Media Recovery Waiting for thread 1 sequence 96535 Sun Jun 25 09:06:36 2017 SWITCHOVER: received request 'ALTER DTABASE COMMIT TO SWITCHOVER TO PRIMARY' from primary database. Sun Jun 25 09:06:36 2017 ALTER DATABASE SWITCHOVER TO PRIMARY (xifenfei) Maximum wait for role transition is 15 minutes. Switchover: Media recovery is still active Role Change: Canceling MRP - no more redo to apply Sat Jun 24 20:06:36 2017 MRP0: Background Media Recovery cancelled with status 16037 Sat Jun 24 20:06:36 2017 Errors in file /u01/app/oracle/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_pr00_4590.trc: ORA-16037: user requested cancel of managed recovery operation Managed Standby Recovery not using Real Time Apply Recovery interrupted! Sat Jun 24 20:06:36 2017 Errors in file /u01/app/oracle/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_pr00_4590.trc: ORA-16037: user requested cancel of managed recovery operation Sat Jun 24 20:06:37 2017 MRP0: Background Media Recovery process shutdown (xifenfei) Sun Jun 25 09:06:38 2017 Role Change: Canceled MRP Killing 2 processes(PIDS:7328,4704)(all RFS) in order to disallow current and future RFS connections.Requested by OS process 7334 Stopping Emon pool All dispatchers and shared servers shutdown CLOSE: killing server sessions. Active process 5428 user 'oracle' program 'oracle@kage7.hk0620.com (TNS V1-V3)' Active process 5161 user 'oracle' program 'oracle@kage7.hk0620.com' ………… Active process 5428 user 'oracle' program 'oracle@kage7.hk0620.com (TNS V1-V3)' Active process 5161 user 'oracle' program 'oracle@kage7.hk0620.com' Active process 5178 user 'oracle' program 'oracle@kage7.hk0620.com' CLOSE: all sessions shutdown successfully. Stopping Emon pool Sat Jun 24 20:06:43 2017 SMON: disabling cache recovery Sat Jun 24 20:06:44 2017 Buffer Cache Full DB Caching mode changing from FULL CACHING DISABLED to FULL CACHING ENABLED Sun Jun 25 09:06:44 2017 Backup controlfile written to trace file /u01/app/oracle/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_rmi_7334.trc SwitchOver after complete recovery through change 13163656450 Online logfile pre-clearing operation disabled by switchover Online log /u01/app/oracle/oradata/xifenfei/redo01n.log: Thread 1 Group 1 was previously cleared Online log /u01/app/oracle/fast_recovery_area/xifenfei/redo01n.log: Thread 1 Group 1 was previously cleared Online log /u01/app/oracle/oradata/xifenfei/redo02n.log: Thread 1 Group 2 was previously cleared Online log /u01/app/oracle/fast_recovery_area/xifenfei/redo02n.log: Thread 1 Group 2 was previously cleared Online log /u01/app/oracle/oradata/xifenfei/redo03n.log: Thread 1 Group 3 was previously cleared Online log /u01/app/oracle/fast_recovery_area/xifenfei/redo03n.log: Thread 1 Group 3 was previously cleared Online log /u01/app/oracle/oradata/xifenfei/redo04n.log: Thread 1 Group 4 was previously cleared Online log /u01/app/oracle/fast_recovery_area/xifenfei/redo04n.log: Thread 1 Group 4 was previously cleared Online log /u01/app/oracle/oradata/xifenfei/redo05n.log: Thread 1 Group 5 was previously cleared Online log /u01/app/oracle/fast_recovery_area/xifenfei/redo05n.log: Thread 1 Group 5 was previously cleared Standby became primary SCN: 13163656448 Switchover: Complete - Database mounted as primary SWITCHOVER: completed request from primary database. Sat Jun 24 20:07:12 2017 ARC0: Becoming the 'no SRL' ARCH
原备库(现主库)操作
SQL> conn / as sysdba Connected. SQL> select database_role,open_mode from v$database; DATABASE_ROLE OPEN_MODE ---------------- -------------------- PRIMARY MOUNTED SQL> alter database open; Database altered.
原主库(现备库)操作
[oracle@localhost scripts]$ ss SQL*Plus: Release 12.1.0.2.0 Production on 星期日 6月 25 09:09:40 2017 Copyright (c) 1982, 2014, Oracle. All rights reserved. 已连接到空闲例程。 SQL> startup ORACLE 例程已经启动。 Total System Global Area 8.5899E+10 bytes Fixed Size 7654304 bytes Variable Size 1.2616E+10 bytes Database Buffers 7.3014E+10 bytes Redo Buffers 260780032 bytes 数据库装载完毕。 数据库已经打开。 SQL> alter database recover managed standby database disconnect; 数据库已更改。