逻辑备库的Swichover和Failover
邏輯備庫的Switchover?
檢查Primary數據庫狀態
查看當前Primary數據庫狀態：
SQL>? SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
--------------------
TO STANDBY?
如果該查詢返回TO STANDBY 或SESSIONS ACTIVE則表示狀態正常，可以執行轉換操作，如果是其他值，你就需要重新檢查一下Data Guard配置，如看看LOG_ARCHIVE_DEST_n之類的參數值是否正確、有效等。
3．準備轉換Primary為邏輯Standby
執行下列語句，將Primary置為準備轉換的狀態：
SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY;
Database altered.?
執行完上述操作后，Primary數據庫就開始為角色的轉換打好基礎，時刻準備著接收來自邏輯Standby數據庫，也就是未來的新Primary數據庫發來的REDO數據。
查看一下SWITCHOVER_STATUS的狀態：
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
--------------------
PREPARING SWITCHOVER?
4．準備轉換邏輯Standby為Primary
邏輯Standby數據庫準備轉換為Primary角色，執行下列語句：
SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY;
Database altered.?
語句執行時響應可能會有點慢。
執行完后查看當前邏輯Standby數據庫的轉換狀態：
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;??
SWITCHOVER_STATUS??
--------------------?
PREPARING SWITCHOVER?
5．再次檢查Primary數據庫狀態
執行下列語句：?
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
--------------------
TO LOGICAL STANDBY?
這步雖然不用做什么操作，但檢查結果卻非常重要，它直接關系到switchover轉換是否能夠成功。邏輯Standby執行完PREPARE命令之后，就會生成相應的LogMiner字典數據（就像我們前面創建邏輯Standby時，Primary數據庫會生成LogMiner字典數據一樣），只有它正常生成并發送至當前的Primary數據庫，轉換操作才能夠繼續下去。不然當前的Primary數據庫在轉換完之后，可能就失去了從新的Primary數據庫接收REDO數據的能力了。
因此，如果上述查詢的返回結果不是TO LOGICAL STANDBY的話，DBA就需要考慮是否取消此次轉換，檢查原因，然后再重新操作了。
取消轉換可以通過下列語句進行：
ALTER DATABASE PREPARE TO SWITCHOVER CANCEL;?
需要分別在Primary端和邏輯Standby端執行。由此可見準備工作的好處顯現出來了嘛，一旦異常，隨時可以選擇取消
6．轉換Primary為邏輯Standby
如果前面的操作都沒有問題，就可以正式開始角色轉換的操作，首先是將原Primary數據庫轉換成新的Standby，操作如下：
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY;
Database altered.?
該語句需要等待當前Primary數據庫所有事務全部結束才開始執行。該語句執行過程中會自動拒絕用戶提交新事務或修改需求。為了確保該操作盡可能快的執行，最好自開始切換操作起就禁止所有用戶的操作。
該命令執行完之后，這個Primary數據庫就已經成為新的邏輯Standby了。不過在新Primary執行完轉換之前，不要關閉當前這個數據庫。
7．再次檢查邏輯Standby狀態
邏輯Standby在接收到前Primary的轉換消息，并應用完相關的REDO數據之后，會自動暫停SQL應用，然后查詢SWITCHOVER_STATUS的狀態，應該為TO PRIMARY：
SQL>SELECT SWITCHOVER_STATUS FROM V$DATABASE;??
SWITCHOVER_STATUS??
--------------------?
TO PRIMARY?
或者?
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
--------------------
NOT ALLOWED?
8．轉換邏輯Standby為新的Primary數據庫
最后的工作總會在邏輯Standby端操作，通過下列語句，將該邏輯Standby轉換為新的Primary數據庫：
SQL>? ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
Database altered.?
轉換操作至此完成。
最后啟動新邏輯Standby，即前Primary數據庫端的SQL應用即可：
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Database altered.?
注意：每一個邏輯Standby都相當于是一個不同于（前）Primary的數據庫（DBID都不同），因此當邏輯Standby完成了轉換之后，相當于原Primary數據庫已經消失，依照原Primary數據庫配置的物理Standby自然也就失去了主從參照，物理Standby也就不再是當前Data Guard配置中的成員了。
這也正是前面修改Primary初始化參數時，取消發送REDO數據到物理Standby數據庫的原因。不過還好，對于switchover，Data Guard配置中的其他邏輯Standby數據庫不會有影響。
9．環境測試
最后來測試一下當前的Data Guard配置，首先在新Primary數據庫操作一條記錄：
SQL> insert into scott.dept values(2,'bl','bl');
1 row created.
SQL> commit;
Commit complete.?
轉到邏輯Standby端查看：??
??? DEPTNO DNAME????????? LOC
---------- -------------- -------------
???????? 1 dave?????????? dmm
???????? 2 bl????????? ?? ? bl?
同步成功，也基本代表轉換成功。
邏輯備庫的Failover?
failover有可能會丟失數據（視當前的數據庫保護模式而定），而且所有的操作都是在Standby數據庫端執行，這幾點對于邏輯Standby也同樣適用，甚至對于明確提及需要在前Primary數據庫執行的，不執行也沒關系，畢竟對于failover，我們假設的就是Primary數據庫已經over。
1．檢查及處理丟失的歸檔
雖然本步不是必需的，但如果希望盡可能少的丟失數據，除了數據保護模式之外，本步操作也非常重要。如果此時Primary數據庫仍可被訪問，首先應當檢查當前的歸檔日志序號與邏輯Standby是否相同：
在主庫查詢：
SQL>? SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG;
MAX(SEQUENCE#)
--------------
?????????? 113?
在備庫查詢：?
SQL> SELECT SEQUENCE#,APPLIED FROM DBA_LOGSTDBY_LOG;
?SEQUENCE# APPLIED
---------- --------
?????? 110 CURRENT
?????? 111 NO?
如果上述查詢的結果不同，說明Primary存在尚未發送至邏輯Standby數據庫的歸檔文件，手工復制這些文件到待轉換角色的邏輯Standby端，然后在該邏輯Standby數據庫的SQL*Plus命令窗口，
通過執行?ALTER DATABASE REGISTER LOGICAL LOGFILE 'filepath';?命令，將復制過來的歸檔文件手工注冊。
如果邏輯Standby與Primary的歸檔序號相同，但某些序號的APPLIED狀態為NO，建議DBA檢查一下當前邏輯Standby數據庫是否啟動了SQL應用。
如果Primary數據庫已經無法打開，DBA就只好直接到磁盤上查看歸檔目錄中的序號，來與邏輯Standby數據庫做比較。如果Primary數據庫已經完全無法訪問，那請直接跳過本步。
2．檢查待轉換邏輯Standby的日志應用情況
查詢重做日志的應用情況，可以通過V$LOGSTDBY_PROGRESS視圖進行，例如：
SQL>? SELECT APPLIED_SCN,LATEST_SCN FROM V$LOGSTDBY_PROGRESS;
APPLIED_SCN LATEST_SCN
----------- ----------
???? 598967???? 598967?
如果返回的結果中顯示，兩列的列值一致，則表示所有接收到的重做日志都已經應用。如果不一致的話，啟動邏輯Standby端的SQL應用。
3．檢查及修正待轉換邏輯Standby的初始化參數配置
確認待轉換的邏輯Standby配置了正確的歸檔路徑，不僅是寫本地的歸檔配置，還要有寫遠端服務器的歸檔配置，不然轉換完之后，這臺新的Primary數據庫就成了光桿司令了。
一般來說，我們都是推薦在創建Standby數據庫的同時將一些用于角色切換的初始化參數也配置好（Primary和Standby端都應如此），以減少切換時操作的時間，提高切換效率。執行如下命令：
SQL> SHOW PARAMETER LOG_ARCHIVE_DEST??
4．激活新的Primary數據庫
首先查看當前操作的角色：?
SQL> SELECT DATABASE_ROLE,FORCE_LOGGING FROM V$DATABASE;??
DATABASE_ROLE??? FOR?
---------------- ---?
LOGICAL STANDBY? YES?
注 意
如果當前FORCE_LOGGING為NO，務必執行ALTER DATABASE FORCE LOGGING;命令。
執行下列語句，轉換Standby數據庫角色為Primary：
SQL> ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE FINISH APPLY;?
數據庫已更改。
該語句主要是停止待轉換的邏輯Standby中RFS進程，并應用完當前所有已接收但并未應用的REDO數據，然后停止SQL應用，將數據庫轉換成Primary角色。
語句執行完成后，再次查看當前數據庫的角色：
SQL> SELECT DATABASE_ROLE,FORCE_LOGGING FROM V$DATABASE;??
DATABASE_ROLE??? FOR?
---------------- ---?
PRIMARY????????? YES?
基本上到這一步，我們可以說角色轉換的工作已經完成了. 此處與邏輯Standby的switchover同理，切換完之后，原Data Guard配置就失效了，徹底的失效了，不僅物理Standby沒了，邏輯Standby也失去了參照，邏輯Standby的failover威力確實大呀，怪不得邏輯Standby用的人這么少呢，環境脆弱肯定是原因之一，因此我們需要做些設置，重新將原來的邏輯Standby再加入到新的Data Guard配置環境中。
5．修復其他Standby數據庫
物理Standby數據庫的修復只有重建一種方式，至于如何創建物理Standby，前面說的已經足夠多了，下面重點描述一下原Data Guard環境中的邏輯Standby。
注意的是，邏輯Standby的修復可不像物理Standby那樣簡單，相比較來說，重建其實是個簡單的工作，因為初始化參數文件、密鑰文件、存放目錄等都是現成的，幾乎不需要改動，DBA所需要做的，基本上就是重新復制一份新Primary數據庫的相關文件，每個邏輯Standby都相當于是獨立的數據庫，如果你不希望重建邏輯Standby的話呢，Oracle倒是也提供了其他的解決方案。
假定原Data Guard環境中有邏輯Standby數據庫LGDG，執行failover后，LGDG不再是新Data Guard環境中的成員，這里演示如何恢復該數據庫到當前的Data Guard配置，操作步驟如下：
（1）在原邏輯Standby中創建數據庫鏈，連接到新的Primary數據庫。
這里所謂的原Standby數據庫，自然是指JSSLDG2嘍，注意，數據庫鏈中用于連接新Primary數據庫的用戶必須擁有SELECT_CATALOG_ROLE角色。執行以下語句：
SQL> ALTER SESSION DISABLE GUARD;?
Session altered.
SQL> CREATE DATABASE LINK BL CONNECT TO SYSTEM IDENTIFIED BY admin USING 'orcl_pd';
Database link created.
SQL> ALTER SESSION ENABLE GUARD;?
會話已更改。?
驗證一下數據鏈是否能夠正常訪問：
SQL> SELECT SYSDATE FROM DUAL@BL;
SYSDATE
---------
06-MAY-10?
提 示： ALTER SESSION ENABLE|DISABLE GUARD語句作用？
該語句用于允許或禁止用戶修改邏輯Standby中的結構。
（2）重新啟動SQL應用。
在各個邏輯Standby端執行下列語句啟動SQL應用（注意更新dblinkName）：
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY BL;??
Database altered.?
如果你運氣好，等語句執行完之后，恢復過程就完成了。如果你非常不幸地碰到了ORA-16109錯誤，那么我不得不告訴你，恐怕你得重建邏輯Standby了。
參考至:http://blog.csdn.net/tianlesoftware/article/details/5564179
如有錯誤，歡迎指正
郵箱:czmcj@163.com
總結
以上是生活随笔為你收集整理的逻辑备库的Swichover和Failover的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Linux高可用性方案之Heartbea
- 下一篇： websocket 之入门 (一)