使用broker工具failover切換之後恢復原來的主庫為新備庫
failover之前一直沒有做,現在終於完整地測試了一遍。這個主要是記得開啟閃回功能,確保最後的reinstate順利完成。
就這樣就能在failover之後順利地把原主庫恢復為備庫。
----failover測試:
----2.2SBDB作為主庫:
SQL> select open_mode,protection_mode,switchover_status,database_role from v$database;
OPEN_MODE PROTECTION_MODE SWITCHOVER_STATUS DATABASE_ROLE
-------------------- -------------------- -------------------- ----------------
READ WRITE MAXIMUM PERFORMANCE SESSIONS ACTIVE PRIMARY
----2.4ORA11GR2作為備庫:
SQL> select open_mode,protection_mode,switchover_status,database_role from v$database;
OPEN_MODE PROTECTION_MODE SWITCHOVER_STATUS DATABASE_ROLE
-------------------- -------------------- -------------------- ----------------
READ ONLY WITH APPLY MAXIMUM PERFORMANCE NOT ALLOWED PHYSICAL STANDBY
----開啟主庫的flashback功能:
SQL> alter database flashback on;
Database altered.
#已經開啟。
----主庫模擬故障不正常關庫:
--在不正常關庫前可以檢視主備庫的最大日誌號:
SQL> select max(sequence#), to_char(max(first_time),'yyyy-mm-dd hh24:mi:ss') from v$log_history where thread#=1
2 and RESETLOGS_TIME = (select max(a.RESETLOGS_TIME) from v$log_history a);
MAX(SEQUENCE#) TO_CHAR(MAX(FIRST_T
-------------- -------------------
210 2017-03-19 22:32:10
#經核對,主備庫的日誌號是相同的,則同步沒有延遲。
----主庫不正常關庫模擬:
SQL> shutdown abort;
ORACLE instance shut down.
SQL> select status from v$instance;
select status from v$instance
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 26669
Session ID: 88 Serial number: 313
SQL> select open_mode,protection_mode,switchover_status,database_role from v$database;
select open_mode,protection_mode,switchover_status,database_role from v$database
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 26669
Session ID: 88 Serial number: 313
----檢視備庫此時的狀態:
SQL> select open_mode,protection_mode,switchover_status,database_role from v$database;
OPEN_MODE PROTECTION_MODE SWITCHOVER_STATUS DATABASE_ROLE
-------------------- -------------------- -------------------- ----------------
READ ONLY WITH APPLY MAXIMUM PERFORMANCE NOT ALLOWED PHYSICAL STANDBY
#現在不是正常的switchover切換,所以備庫依然顯示切換狀態為NOT ALLOWED 。
----備庫登入DGbroker工具進行failover切換:
[oracle@oracle ~]$ dgmgrl
DGMGRL for Linux: Version 11.2.0.4.0 - 64bit Production
Copyright (c) 2000, 2009, Oracle. All rights reserved.
Welcome to DGMGRL, type "help" for information.
DGMGRL> connect sys/skysky
Connected.
DGMGRL> show configuration;
Configuration - SBDB
Protection Mode: MaxPerformance
Databases:
SBDB - Primary database
ORA11GR2 - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
ORA-01034: ORACLE not available
ORA-16625: cannot reach database "SBDB"
DGM-17017: unable to determine configuration status
----進行failover切換:
DGMGRL> failover to 'ORA11GR2';
Performing failover NOW, please wait...
Failover succeeded, new primary is "ORA11GR2"
DGMGRL>
#failover切換成功。
----切換成功後檢視DGbroker配置檔案:
DGMGRL> show configuration;
Configuration - SBDB
Protection Mode: MaxPerformance
Databases:
ORA11GR2 - Primary database
SBDB - Physical standby database (disabled)
ORA-16661: the standby database needs to be reinstated
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
---檢視現在主庫:
DGMGRL> show database 'ORA11GR2';
Database - ORA11GR2
Role: PRIMARY
Intended State: TRANSPORT-ON
Instance(s):
ORA11GR2
Database Status:
SUCCESS
---檢視原來主庫:
DGMGRL> show database 'SBDB';
Database - SBDB
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: (unknown)
Apply Lag: (unknown)
Apply Rate: (unknown)
Real Time Query: OFF
Instance(s):
SBDB
Database Status:
ORA-16661: the standby database needs to be reinstated
----嘗試檢視failover後主庫的狀態:
SQL> select open_mode,protection_mode,switchover_status,database_role from v$database;
select open_mode,protection_mode,switchover_status,database_role from v$database
*
ERROR at line 1:
ORA-03135: connection lost contact
Process ID: 1497
Session ID: 18 Serial number: 7
SQL> select status from v$instance;
ERROR:
ORA-03114: not connected to ORACLE
----重啟新主庫的例項:
SQL> select open_mode,protection_mode,switchover_status,database_role from v$database;
OPEN_MODE PROTECTION_MODE SWITCHOVER_STATUS DATABASE_ROLE
-------------------- -------------------- -------------------- ----------------
READ WRITE MAXIMUM PERFORMANCE NOT ALLOWED PRIMARY
#現在變成了可讀寫狀態,則作為主庫使用。
----一段時間後,嘗試重啟原來的主庫:
[oracle@host01 ~]$ sqlplus "/as sysdba"
SQL*Plus: Release 11.2.0.4.0 Production on Mon Mar 20 00:55:20 2017
Copyright (c) 1982, 2013, Oracle. All rights reserved.
Enter password:
Connected to an idle instance.
SQL> startup
ORACLE instance started.
Total System Global Area 830930944 bytes
Fixed Size 2257800 bytes
Variable Size 704646264 bytes
Database Buffers 121634816 bytes
Redo Buffers 2392064 bytes
Database mounted.
ORA-16649: possible failover to another database prevents this database from
being opened
----檢視此時的狀態:
SQL> select open_mode,protection_mode,switchover_status,database_role from v$database;
OPEN_MODE PROTECTION_MODE SWITCHOVER_STATUS DATABASE_ROLE
-------------------- -------------------- -------------------- ----------------
MOUNTED MAXIMUM PERFORMANCE NOT ALLOWED PRIMARY
----alert日誌的記錄:
Successful mount of redo thread 1, with mount id 255649302
Allocated 3981120 bytes in shared pool for flashback generation buffer
Starting background process RVWR
Mon Mar 20 00:55:55 2017
RVWR started with pid=21, OS id=26995
Database mounted in Exclusive Mode
Lost write protection disabled
Completed: ALTER DATABASE MOUNT
Mon Mar 20 00:55:56 2017
ALTER DATABASE OPEN
Data Guard Broker initializing...
Data Guard Broker initialization complete
Data Guard: verifying database primary role...
Starting Data Guard Broker (DMON)
Mon Mar 20 00:55:58 2017
INSV started with pid=22, OS id=27002
Mon Mar 20 00:56:01 2017
NSV1 started with pid=23, OS id=27006
Mon Mar 20 00:56:07 2017
Data Guard: version check completed
Data Guard determines a failover has occurred - this is no longer a primary database
ORA-16649 signalled during: ALTER DATABASE OPEN...
----恢復原來的主庫為新備庫:
----把原來的主庫開啟到mount狀態:
[oracle@host01 ~]$ sqlplus "/as sysdba"
SQL*Plus: Release 11.2.0.4.0 Production on Mon Mar 20 01:04:39 2017
Copyright (c) 1982, 2013, Oracle. All rights reserved.
Connected to an idle instance.
SQL> startup mount
ORACLE instance started.
Total System Global Area 830930944 bytes
Fixed Size 2257800 bytes
Variable Size 704646264 bytes
Database Buffers 121634816 bytes
Redo Buffers 2392064 bytes
Database mounted.
SQL>
----使用DGbroker登入Reinstate 原來的主庫(Reinstate the old primary database):
--新主庫側:
DGMGRL> REINSTATE DATABASE 'SBDB';
Reinstating database "SBDB", please wait...
Operation requires shutdown of instance "SBDB" on database "SBDB"
Shutting down instance "SBDB"...
Unable to connect to database
ORA-12545: Connect failed because target host or object does not exist
Failed.
Warning: You are no longer connected to ORACLE.
Please complete the following steps and reissue the REINSTATE command:
shut down instance "SBDB" of database "SBDB"
start up and mount instance "SBDB" of database "SBDB"
#這個雖然沒有一步到位,但是隻要跟著提示走,去重啟SBDB例項就可以了。重啟完之後,重新執行 REINSTATE DATABASE 'SBDB'
語句,就可以順利地REINSTATE DATABASE,把原來的主庫恢復起來了。重啟過程和REINSTATE過程可以參考本文提示到的兩段alert日誌記錄。
DGMGRL>
DGMGRL> REINSTATE DATABASE 'SBDB';
Reinstating database "SBDB", please wait...
Reinstatement of database "SBDB" succeeded
DGMGRL>
#REINSTATE DATABASE完成。
----檢視引數檔案:
DGMGRL> show configuration;
Configuration - SBDB
Protection Mode: MaxPerformance
Databases:
ORA11GR2 - Primary database
SBDB - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
DGMGRL>
----檢視新備庫:
DGMGRL> show database 'SBDB';
Database - SBDB
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds (computed 1 second ago)
Apply Lag: 0 seconds (computed 1 second ago)
Apply Rate: 196.00 KByte/s
Real Time Query: ON
Instance(s):
SBDB
Database Status:
SUCCESS
#已經恢復成功。
----檢視備庫的狀態:
SQL> select open_mode,protection_mode,switchover_status,database_role from v$database;
OPEN_MODE PROTECTION_MODE SWITCHOVER_STATUS DATABASE_ROLE
-------------------- -------------------- -------------------- ----------------
READ ONLY WITH APPLY MAXIMUM PERFORMANCE SWITCHOVER PENDING PHYSICAL STANDBY
#已經成功切換成DG的新備庫。
SQL> select max(sequence#), to_char(max(first_time),'yyyy-mm-dd hh24:mi:ss') from v$log_history where thread#=1
2 and RESETLOGS_TIME = (select max(a.RESETLOGS_TIME) from v$log_history a);
MAX(SEQUENCE#) TO_CHAR(MAX(FIRST_T
-------------- -------------------
6 2017-03-20 01:20:19
#新主備庫的最大日誌號相同。
--附加reinstate過程的日誌:
Reinstate過程中的alert日誌選段:
Using STANDBY_ARCHIVE_DEST parameter default value as /u01/app/arch/SBDB/
RFS[1]: Assigned to RFS process 27186
RFS[1]: Database mount ID mismatch [0xf3d3a60:0xf3ceb30] (255670880:255650608)
RFS[1]: Not using real application clusters
Mon Mar 20 01:14:26 2017
RSM0 started with pid=26, OS id=27188
FLASHBACK DATABASE TO SCN 3526040
Flashback Restore Start
Flashback Restore Complete
Flashback Media Recovery Start
Serial Media Recovery started
Recovery of Online Redo Log: Thread 1 Group 3 Seq 211 Reading mem 0
Mem# 0: /u01/app/oracle/oradata/SBDB/redo03.log
Mem# 1: /u01/app/oracle/oradata/SBDB/redo06.log
Incomplete Recovery applied until change 3526041 time 03/20/2017 00:38:59
Flashback Media Recovery Complete
Completed: FLASHBACK DATABASE TO SCN 3526040
alter database convert to physical standby
ALTER DATABASE CONVERT TO PHYSICAL STANDBY (SBDB)
Mon Mar 20 01:14:36 2017
Flush standby redo logfile failed:1649
Clearing standby activation ID 255679734 (0xf3d5cf6)
The primary database controlfile was created using the
'MAXLOGFILES 16' clause.
There is space for up to 13 standby redo logfiles
Use the following SQL commands on the standby database to create
standby redo logfiles that match the primary database:
ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 52428800;
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/SBDB/redo01.log
Clearing online log 1 of thread 1 sequence number 209
Clearing online redo logfile 1 complete
Clearing online redo logfile 2 /u01/app/oracle/oradata/SBDB/redo02.log
Clearing online log 2 of thread 1 sequence number 210
Mon Mar 20 01:14:49 2017
Clearing online redo logfile 2 complete
Clearing online redo logfile 3 /u01/app/oracle/oradata/SBDB/redo03.log
Clearing online log 3 of thread 1 sequence number 211
Clearing online redo logfile 3 complete
Completed: alter database convert to physical standby
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31392094/viewspace-2135704/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- openGauss主備切換之switchover與failoverAI
- Polardb資料庫掛庫後,如何恢復主備關係資料庫
- 【DG】Data Guard主備庫Failove切換AI
- 【DG】Data Guard主備庫Switchover切換
- 使用binlog2sql工具來恢復資料庫SQL資料庫
- MySQL 5.7 主庫崩潰切備庫MySql
- SQLServer2012映象主庫掛掉如何切換到映象備庫SQLServer
- OracleDG備庫恢復–gapOracle
- Oracle:Failover 到物理備庫OracleAI
- Oracle 單機切換為主備Oracle
- 使用Broker實現DG切換
- 資料庫備份恢復資料庫
- 備份與恢復:polardb資料庫備份與恢復資料庫
- 使用Mysqldump備份和恢復MySQL資料庫MySql資料庫
- oradim工具恢復資料庫資料庫
- oracle 11g dg broker 開啟fast-start failover自動故障切換OracleASTAI
- oracle 19c使用dgmgrl來執行switchover和failover切換OracleAI
- Spring Boot中自定義註解+AOP實現主備庫切換Spring Boot
- PostgreSql資料庫的備份和恢復SQL資料庫
- 如何在MySQL資料庫中使用use來切換資料庫?MySql資料庫
- mysqldump使用方法(MySQL資料庫的備份與恢復)MySql資料庫
- 時序資料庫InfluxDB之備份和恢復策略資料庫UX
- 時序資料庫 InfluxDB 之備份和恢復策略資料庫UX
- 利用innobackupex備份集恢復指定庫
- Oracle資料庫冷備和恢復Oracle資料庫
- Mysql資料庫備份及恢復MySql資料庫
- 達夢資料庫備份恢復資料庫
- ORACLE DG從庫 Rman備份恢復Oracle
- postgresql備份與恢復資料庫SQL資料庫
- 在DG備庫備份資料庫並恢復到一個主機上,報錯RMAN-06820資料庫
- Mongodb資料庫誤刪後的恢復MongoDB資料庫
- 將RAC備份集恢復為單例項資料庫單例資料庫
- Oracle資料庫恢復之resetlogsOracle資料庫
- 資料庫備份與恢復技術資料庫
- Mongo 資料庫備份和恢復命令Go資料庫
- pg_dump 備份,恢復資料庫資料庫
- 如何恢復在全備後新增了資料檔案的資料庫資料庫
- 寶塔資料庫恢復 mysql資料庫丟失恢復 mysql資料庫刪除庫恢復 寶塔mysql資料庫恢復資料庫MySql
- 主備都是全新的恢復,主主搭建步驟