ORACLE 11G Data Guard 角色轉換

yuntui發表於2016-11-03


1,ORACLE Dataguard角色切換
DataGuard已經是現今標準的主流容災方案,由於日誌傳遞對於網路適應程度強,且可以採用同步實時的傳遞方式和非同步延遲的傳遞方式,甚至可以成為遠端的異地容災方案。不管用於何種用途,DG都免不了要進行角色轉換,即將standby 資料庫切換為primary資料庫,角色轉換分為:switchover和failover兩種



2,兩種方式的異同
1),switchover是primary庫轉換成standby庫、standby庫轉換成primary庫
2),failover後standby轉換成primary庫啟用
3)、使用場合不同:Switchover 用於有準備的、計劃之中的切換,通常是系統升級、資料遷移等常態任務;Failover用於意料之外的突發情況,比如異常掉電、自然災難等等。
4)、資料丟失程度不同:Switchover不會丟失資料,Failover通常意味著有部分資料丟失。
5)、善後處理的不同:Switchover之後Dataguard環境不會被破壞,任然有Primary、Standby兩種角色的系統存在。但是Failover之後,Dataguard環境就會被破壞,必須需要重建。



3.在primary上做switchover操作
switchover 準備工作,注意,如果要轉換角色的standby 處於maximum protection 模式,需要你首先將其切換為maximum performance 模式,
先檢查是否支援switch操作,登入primary庫,去查詢v$database表的switchover_status列
SQL> select switchover_status from v$database;


SWITCHOVER_STATUS
--------------------
TO STANDBY


SQL> 
如果該列值為"TO STANDBY"則表示primary 資料庫支援轉換為standby 角色,否則的話你就需要重新檢查一下Data Guard 配置,比如看看LOG_ARCHIVE_DEST_n 之類引數值是否正確有效等等。


3.1,啟動switchover --primary上操作
首先將primary 轉換為standby 的角色,透過下列語句:
alter database commit to switchover to physical standby;
SQL> alter database commit to switchover to physical standby;


Database altered.


SQL> 


3.2 重啟到mount
SQL> shutdown immediate
ORA-01507: database not mounted


ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.


Total System Global Area 3373858816 bytes
Fixed Size    2218032 bytes
Variable Size 1845495760 bytes
Database Buffers 1509949440 bytes
Redo Buffers   16195584 bytes
Database mounted.
SQL> 


3.3,去檢視當前的狀態
SQL> select switchover_status from v$database;


SWITCHOVER_STATUS
--------------------
TO PRIMARY


SQL> 
switchover_status為TO PRIMARY。
SQL> select open_mode,database_role from v$database;


OPEN_MODE     DATABASE_ROLE
-------------------- ----------------
MOUNTED     PHYSICAL STANDBY


SQL> 
database_role為物理standby(PHYSICAL STANDBY)。
轉換成功。


4 在待轉換的standby庫上做switchover操作 

4.1 檢視下,是否支援switchover切換操作
SQL> select switchover_status from v$database;


SWITCHOVER_STATUS
--------------------
TO PRIMARY


SQL> 
此時待轉換standby 資料庫switchover_status 列值應該是"TO_PRIMARY",如否則檢查其初始化引數檔案中的設定,提示一下,比著原primary 資料庫的初始化引數改改。


4.2,轉換成primary,透過下列語句轉換standby 到primary 角色:
alter database commit to switchover to primary;
SQL> alter database commit to switchover to primary;


Database altered.


SQL> 
注意:待轉換的物理standby 可以處於mount 模式或open read only 模式,但不能處於open read write模式。


4.3,完成轉換,開啟新的primary 資料庫
alter database open;
注:如果資料庫處於open read-only 模式的話,需要先shutdown 然後直接startup 即可。
檢視資料庫模式:
SELECT open_mode,database_role FROM v$database;
SQL> SELECT open_mode,database_role FROM v$database;


OPEN_MODE     DATABASE_ROLE
-------------------- ----------------
READ WRITE     PRIMARY


SQL> 


5,驗證一下新的primary以及新的standby操作
去新的primary上
SQL> show parameter db_unique


NAME     TYPE VALUE
------------------------------------ ----------- ------------------------------
db_unique_name     string pdunq_dg
SQL> 
SQL> 
SQL> select max(sequence#) from v$archived_log;


MAX(SEQUENCE#)
--------------
  369


SQL> 


SQL> alter system switch logfile;
System altered.


SQL>  


select max(sequence#) from v$archived_log;
SQL> select max(sequence#) from v$archived_log;


MAX(SEQUENCE#)
--------------
  370


SQL> 


去新的standby庫檢視下 
SQL> select max(sequence#) from v$archived_log;


MAX(SEQUENCE#)
--------------
  368


SQL> 


redo日誌沒有傳送到新的standby上面去,檢查下新primary的alert日誌,如下報錯:
Mon Feb 09 16:55:35 2015
Error 12154 received logging on to the standby
Errors in file /oracle/app/oracle/diag/rdbms/pdunq_dg/powerdes/trace/powerdes_arc2_23808.trc:
ORA-12154: TNS:could not resolve the connect identifier specified
PING[ARC2]: Heartbeat failed to connect to standby 'pdunq_dg'. Error is 12154.
Mon Feb 09 16:56:35 2015
Error 12154 received logging on to the standby
Errors in file /oracle/app/oracle/diag/rdbms/pdunq_dg/powerdes/trace/powerdes_arc2_23808.trc:
ORA-12154: TNS:could not resolve the connect identifier specified
PING[ARC2]: Heartbeat failed to connect to standby 'pdunq_dg'. Error is 12154.



6,問題排查
這個報錯原因是因為原來的primary和standby的db_unique_name不一樣,所以switchover後,原來指向的歸檔引數的db_unique_name要與新的standby保持一致,也就是要保持成pdunq才行:
去檢視下 show parameter log_archive_dest_2引數:
SQL> show parameter log_archive_dest_2;


NAME     TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_2     string SERVICE=pdunq_dg  lgwr sync af
firm VALID_FOR=(ONLINE_LOGFILE
S,PRIMARY_ROLE) DB_UNIQUE_NAME
=pdunq
log_archive_dest_20     string
log_archive_dest_21     string
log_archive_dest_22     string
log_archive_dest_23     string
log_archive_dest_24     string
log_archive_dest_25     string
log_archive_dest_26     string


NAME     TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_27     string
log_archive_dest_28     string
log_archive_dest_29     string
SQL> 
--修改log_archive_dest_2引數
alter system set log_archive_dest_2='SERVICE=pdunq_dg  lgwr sync affirm VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=pdunq';
alter system set log_archive_dest_state_2=enable;
alter system switch logfile;
SQL> alter system set log_archive_dest_2='SERVICE=pdunq_dg  lgwr sync affirm VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=pdunq';


System altered.


SQL> alter system set log_archive_dest_state_2=enable;


System altered.


SQL> alter system switch logfile;


System altered.


SQL> 
去新的primary、standby庫使用select max(sequence#) from v$archived_log;檢查記錄
SQL> select max(sequence#) from v$archived_log;


MAX(SEQUENCE#)
--------------
  373


SQL> 
至此,switchover成功結束。




7, failover 物理standby的轉換成primary庫

7.1、檢查歸檔檔案是否連續 在standby上操作
查詢待轉換standby 資料庫的V$ARCHIVE_GAP 檢視,確認歸檔檔案是否連線:
SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;


no rows selected


SQL> 
如果返回的有記錄,按照列出的記錄號複製對應的歸檔檔案到待轉換的standby 伺服器。這一步非常重
要,必須確保所有已生成的歸檔檔案均已存在於standby 伺服器,不然可能會資料不一致造成轉換時報錯。
檔案複製之後,透過下列命令將其加入資料字典:
ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';


7.2、檢查歸檔檔案是否完整
分別在primary/standby 執行下列語句:
SQL> select distinct thread#,max(sequence#) over(partition by thread#) a from v$archived_log;


   THREAD#    A
---------- ----------
1  375


SQL> 
該語句取得當前資料庫各執行緒已歸檔檔案最大序號,如果primary 與standby 最大序號不相同,必須將
多出的序號對應的歸檔檔案複製到待轉換的standby 伺服器。不過既然是failover,有可能primary 資料庫此
時已經無法開啟,甚至無法訪問,那你只好聽天由命嘍。


7.3、啟動failover 在standby上執行
執行下列語句:alter database recover managed standby database finish force;
SQL> alter database recover managed standby database finish force;


Database altered.

SQL> 
FORCE 關鍵字將會停止當前活動的RFS 程式,以便立刻執行failover。
剩下的步驟就與一般的switchover 很相似了


7.4、切換物理standby 角色為primary
SQL> SQL> alter database commit to switchover to primary;


Database altered.


SQL> 


7.5、啟動新的primary 資料庫。
如果當前資料庫已mount,直接open 即可,如果處於read-only 模式,需要首先shutdown immediate,然後再直接startup。
先檢視db的模式,命令為:select open_mode,database_role from v$database;
SQL> select open_mode,database_role from v$database;


OPEN_MODE     DATABASE_ROLE
-------------------- ----------------
MOUNTED     PRIMARY


SQL> 


為mount,所以需要open
SQL> alter database open;


Database altered.


SQL> 
再去檢視新primary的當前資料模式:
SQL> select open_mode,database_role from v$database;


OPEN_MODE     DATABASE_ROLE
-------------------- ----------------
READ WRITE     PRIMARY


SQL> 

角色轉換工作完成。剩下的是補救措施(針對原primary 資料庫),由於此時primary 資料庫已經不再是
data guard 配置的一部分,我們需要做的就是嘗試看看能否恢復原primary 資料庫,將其改造為新的standby
伺服器。具體操作方式可以分為二類:2.重建2.備份恢復。

 ----------------------------------------------------------------------------------------------------------------
<版權所有,允許轉載,但必須以連結方式註明源地址,否則追究法律責任!>
原部落格地址:       http://blog.itpub.net/26230597/viewspace-1432708/
原作者:黃杉 (mchdba)
----------------------------------------------------------------------------------------------------------------

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/30633755/viewspace-2127690/,如需轉載,請註明出處,否則將追究法律責任。

相關文章