一步一步學DataGuard(15)邏輯standby之failover

邏輯standby之failover

前面學習物理standby的failover時我們提到過，failover有可能會丟失資料(視當前的資料庫保護模式而定)，對於邏輯standby也一樣；物理standby在做failover演示時還提到過，所有的操作都會在standby端執行，對於邏輯standby這也一樣，甚至對於明確提及在前primary執行的，你不執行，也沒關係，畢竟對於failover，我們假設的就是，primary已經over了:)

一、準備工作要充分

準備工作可以從以下幾個方面著手：

1、檢查及處理丟失的歸檔

雖然本步不是必須的，但如果希望儘可能少丟失資料，除了資料保護模式之外，本步操作也非常重要。如果此時primary仍可被訪問，首先檢查當前的歸檔日誌序號與邏輯standby是否相同：

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

MAX(SEQUENCE#)

--------------

24

JSSWEB> select sequence#,applied from dba_logstdby_log;

SEQUENCE# APPLIED

---------- --------

23 YES

24 YES

已選擇2行。

提示：如果primary的資料庫已經無法開啟，您就只好直接到磁碟上檢視歸檔目錄中的序號來與standby端做比較了。

如果不同序號，則將primary尚未傳送至standby的歸檔檔案手工複製到待轉換的邏輯standby伺服器，然後在standby端通過 ALTER DATABASE REGISTER LOGICAL LOGFILE ''; 命令將檔案手工註冊

如果standby與primary的歸檔序號相同，但某些序號的applied狀態為no，建議你檢查一下當前standby是否啟動了SQL應用：）。

2、檢查待轉換邏輯standby的日誌應用情況

可以通過查詢v$logstdby_progress檢視：

JSSWEB> select applied_scn,latest_scn from v$logstdby_progress;

APPLIED_SCN LATEST_SCN

----------- ----------

1259449 1259453

如果兩值一致，表示所有接收到的歸檔都已經應用了。

3、檢查及修正待轉換邏輯standby的初始化引數配置

確認待轉換的邏輯standby配置了正確的歸檔路徑，不僅是寫本地的歸檔，還要有寫遠端的歸檔，不然轉換完之後，這臺新的primary就成了光桿司令了。

JSSWEB> show parameter log_archive_dest

.......................

當然一般來說，我們都是推薦在建立standby的同時將一些用於角色切換的初始化引數也配置好(primary和standby端都應如此)，以減小切換時操作的時間，提高切換效率。

二、啟用新的primary資料庫

首先檢視當前操作的角色

JSSWEB> select database_role,force_logging from v$database;

DATABASE_ROLE FOR

---------------- ---

LOGICAL STANDBY YES

注意，如果當前force_logging為no，務必執行：Alter database force logging;

轉換standby角色為primary

JSSWEB> alter database activate logical standby database finish apply;

資料庫已更改。

該語句主要是停止待轉換的邏輯standby中RFS程式，並應用完當前所有已接收但並未應用的redo資料，然後停止sql應用，將資料庫轉換成primary角色。

JSSWEB> select database_role,force_logging from v$database;

DATABASE_ROLE FOR

---------------- ---

PRIMARY YES

基本上到這一步，我們可以說角色轉換的工作已經完成了，但是注意，活還沒有幹完！

此處與邏輯standby的switchover同理，切換完之後，原dg配置就失效了(不僅原物理standby沒了，原邏輯standby也失去了參照，看看，邏輯standby的failover確實威力巨大呀，怪不得邏輯standby用的人這麼人呢，環境脆弱肯定是原因之一啊)，因此我們需要做些設定，重新將原來的standby再加入到新的dg配置環境中。

三、修復其它standby

注意喲，邏輯standby的修復可並不像物理standby那樣簡單，每個邏輯standby都相當於是獨立的資料庫，如果你不希望重建邏輯standby的話呢，oracle倒是也提供了其它解決方案(雖然不一定好使)：

1、在各個原邏輯standby中建立資料庫鏈，連線到新的primary

注意，資料庫鏈中用於連線新primary的使用者必須擁有SELECT_CATALOG_ROLE角色。

JSSLDG2> alter session disable guard;

會話已更改。

JSSLDG2> create database link getjssweb connect to jss identified by jss using 'jssweb';

資料庫連結已建立。

JSSLDG2> alter session enable guard;

會話已更改。

驗證一下資料鏈是否能夠正常訪問：

JSSLDG2> select sysdate from dual@getjssweb;

SYSDATE

--------------

23-2月 -08

提示：關於alter session enable|disable guard語句，用於允許或禁止使用者修改邏輯standby中的結構。例如：

JSSLDG2> conn jss/jss

已連線。

JSSLDG2> select *from b;

ID

----------

1

2

3

4

5

6

7

8

已選擇8行。

JSSLDG2> alter table b rename to a;

alter table b rename to a

*

第 1 行出現錯誤:

ORA-16224: Database Guard 已啟用

JSSLDG2> alter session disable guard;

會話已更改。

JSSLDG2> alter table b rename to a;

表已更改。

2、重新啟動SQL應用

在各個邏輯standby執行下列語句啟動sql應用(注意更新dblinkName)：

JSSLDG2> alter database start logical standby apply new primary getjssweb;

資料庫已更改。

如果你運氣好，等語句執行完之後，恢復過程就完成了。如果你非常不幸的碰到了ORA-16109錯誤，那麼我不得不告訴你，恐怕你得重建邏輯standby了。所以，祝你好運吧:)

語句順利執行完之後，我們來驗證一下：

JSSWEB> alter system switch logfile;

系統已更改。

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

MAX(SEQUENCE#)

--------------

862

JSSLDG2> select sequence#,applied from dba_logstdby_log;

SEQUENCE# APPLIED

---------- --------

862 NO

注意：出現問題了！！

日誌是傳輸過去了，但是邏輯standby並沒有開始應用，怎麼回事？

我們先來確認一下standby的各程式狀態：

JSSLDG2> select process,status,group#,thread#,sequence#,block#,blocks from v$managed_standby;

PROCESS STATUS GROUP# THREAD# SEQUENCE# BLOCK# BLOCKS

--------- ------------ ---------------------------------------- ---------- ---------- ---------- ----------

ARCH CLOSING 2 1 4 16385 1836

ARCH CLOSING 6 1 862 1 18

RFS IDLE N/A 0 0 0 0

RFS IDLE 3 1 863 2 1

看起來也是正常的，接收完了862,正在等待863，但是，為什麼不應用呢。

手工查詢一下新primary生成的歸檔日誌情況：

JSSWEB> select sequence#,name,COMPLETION_TIME from v$archived_log where sequence#>855;

SEQUENCE# NAME COMPLETION_TIME

---------- ---------------------------------------------------------------------- -------------------

856 E:\ORA10G\ORADATA\JSSWEB\ARC\LOG1_856_641301252.ARC 2008-02-21 10:15:42

857 E:\ORA10G\ORADATA\JSSWEB\ARC\LOG1_857_641301252.ARC 2008-02-21 10:16:46

858 E:\ORA10G\ORADATA\JSSWEB\ARC\LOG1_858_641301252.ARC 2008-02-23 14:15:18

859 E:\ORA10G\ORADATA\JSSWEB\ARC\LOG1_859_641301252.ARC 2008-02-23 14:56:55

860 E:\ORA10G\ORADATA\JSSWEB\ARC\LOG1_860_641301252.ARC 2008-02-23 14:57:03

861 E:\ORA10G\ORADATA\JSSWEB\ARC\LOG1_861_641301252.ARC 2008-02-23 16:58:14

861 jssldg2 2008-02-23 16:58:16

862 E:\ORA10G\ORADATA\JSSWEB\ARC\LOG1_862_641301252.ARC 2008-02-23 17:08:57

862 jssldg2 2008-02-23 17:08:57

字數受限，詳細請檢視：

一步一步學DataGuard(15)邏輯standby之failover全文

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

一步一步學DataGuard(15)邏輯standby之failover

相關文章