作業系統：linux redhat 4.7
Oracle: 10.2.0.1
主庫：orcl_pd
備庫：LGDG
一． 邏輯Standby建立過程
1 建立實體Standby
參考之前的部落格
簡單的做如下幾點提示：
1）．初始化參數配置
初始化參數的修改并不僅僅隻是在待建立的Standby資料庫端建立，目前的Primary資料庫甚至同一個Data Guard配置中的其他Standby資料庫的初始化參數都有可能需要進行修改。
對于Primary資料庫，至少需要新增一個LOG_ARCHIVE_DEST_n參數，以發送REDO資料到新的Standby端，同時其他一些與Standby環境相關的參數也會涉及調整，如LOG_ARCHIVE_CONFIG及FAL_*等參數。
而對于現有的Standby資料庫（如果有的話），主要是基于角色轉換的考慮，有必要對一些參數提前進行設定，設定的參數對目前功能不會有任何影響或促進，如果确定不進行角色轉換，那麼同一個Data Guard配置中的其他Standby資料庫初始化參數也可以不做任何調整。
2）．監聽和NetService配置
建議用Net Manager 工具來配置，這樣不容易出現錯誤。
3）．建立密鑰檔案
必須確定在同一個Data Guard環境中，所有資料庫的SYS使用者擁有相同密碼，建議從其他伺服器複制密鑰檔案到本地，然後按照密鑰檔案名的格式修改檔案名即可。
注意Windows平台和Linux/UNIX平台下，密鑰檔案名的命名格式并不相同，Windows平台下密鑰檔案名格式為PWD[sid].ora，而Linux/UNIX平台下密鑰檔案名格式為orapw[sid]，注意檔案名的大小寫喲。
2 Primary資料庫生成資料字典
注意：在Primary生成資料字典前，一定要確定待轉換的實體Standby資料庫已經停止REDO應用。如果已經啟用了REDO應用，執行下列語句停止REDO應用：
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
Database altered.
執行下列過程，生成LogMiner字典資訊：
SQL> EXECUTE DBMS_LOGSTDBY.BUILD;
PL/SQL procedure successfully completed.
控制檔案中記錄了日志檔案的應用狀态，正常情況下一個日志檔案隻會被應用一次，如果Primary生成的資料字典資訊被實體Standby資料庫應用了，等該實體Standby轉換成邏輯Standby資料庫時（不應用資料字典不代表就不能執行轉換喲）就不會再應用這些檔案，自然也沒有Primary資料庫對象的中繼資料，這可能會導緻這部分對象的修改不能被邏輯Standby正常應用。
我們操作的根本目的是為了讓邏輯Standby能夠應用到這部分資料字典資訊，隻要能夠實作這一點，是否暫停REDO應用或什麼時間暫停REDO應用就無所謂了。這也我們了解另外一個問題，如果Primary生成LogMiner字典資訊時，待轉換的實體Standby資料庫沒有暫停REDO應用怎麼辦？好辦，馬上暫停REDO應用，然後Primary資料庫重新生成一下LogMiner字典資訊就是。
3 轉換實體Standby為邏輯Standby
執行下列語句，轉換實體Standby為邏輯Standby：
SQL> SHOW PARAMETER DB_NAME
NAME TYPE VALUE
---------------------- ----------- ------------------------------
db_name string mynew1
SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY LGDG;
執行完該語句之後，關閉資料庫并重新啟動到MOUNT狀态：
SQL> SHUTDOWN IMMEDIATE
ORA-01507: database not mounted
ORACLE instance shut down.
SQL> STARTUP MOUNT;
ORACLE instance started.
Total System Global Area 167772160 bytes
Fixed Size 1218316 bytes
Variable Size 79694068 bytes
Database Buffers 83886080 bytes
Redo Buffers 2973696 bytes
Database mounted.
為什麼要重新開機？因為上述操作涉及邏輯Standby資料庫更名，包括DBID、INCARNATION等均已被重新初始化。
再次檢視DB_NAME參數和資料庫角色：
SQL> SHOW PARAMETER DB_NAME;
NAME TYPE VALUE
-------------------------- ----------- ------------------------------
db_name string LGDG
SQL> SELECT DATABASE_ROLE FROM V$DATABASE;
DATABASE_ROLE
----------------
LOGICAL STANDBY
現在DB_NAME和資料庫的角色都已經被修改。
4 調整邏輯Standby資料庫初始化參數
設定重做日志檔案路徑，将本地生成的歸檔檔案和Primary資料庫發送來的歸檔檔案分開，存放到不同目錄内，注意歸檔檔案路徑不要沖突，修改參數如下：
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=/u01/archive VALID_FOR=(ONLINE_LOGFILES, ALL_ROLES) DB_UNIQUE_NAME=LGDG'; # LGDG 是在tnsnames.ora 中配置的
System altered.
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_3='LOCATION=/u01/std
VALID_FOR=(STANDBY_LOGFILES, STANDBY_ROLE) DB_UNIQUE_NAME=LGDG';
5 打開邏輯Standby
由于邏輯Standby與Primary資料庫事務并不一緻，是以第一次打開時必須指定RESETLOGS子句，執行語句如下：
SQL> ALTER DATABASE OPEN RESETLOGS;
然後執行下列SQL指令開始應用REDO資料：
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY ;
如果要啟用實時應用，建議首先建立Standby Redologs，例如，為該邏輯Standby建立幾組Standby Redologs：
SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 '/u01/app/oracle/oradata/orcl/redo04.log' SIZE 50m;
Database altered.
重新執行啟動REDO應用的指令，附加APPLY IMMEDIATE子句，以打開實時應用（由于目前REDO應用已經啟動，是以我們首先停止REDO應用）：
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
6 驗證環境
所有配置完成，接下來嘗試在Primary資料庫端執行修改操作，看看是否能夠分别在邏輯Standby和實體Standby端應用。
首先在Primary資料庫端執行下列語句，向tmp1表插入一條新記錄并送出：
SQL> insert into scott.dept values(1,'dave','dmm');
1 row created.
SQL> commit;
Commit complete.
SQL> alter system switch logfile;
接下來看看邏輯Standby的同步情況：
SQL> select * from scott.dept;
DEPTNO DNAME LOC
---------- -------------- -------------
10 ACCOUNTING NEW YORK
20 RESEARCH DALLAS
30 SALES CHICAGO
40 OPERATIONS BOSTON
1 dave dmm
提 示: 細心觀察重做日志，發現邏輯Standby有一點設計得很好，從Primary資料庫接收到的重做日志檔案檔案，應用過之後就會自動删除，節省了磁盤空間。
OK，至此邏輯Standby建立成功.
二． 主備切換之switchover
要在Primary和邏輯Standby之間切換角色，一般是從Primary資料庫開始操作。
如果Primary或邏輯Standby是RAC結構，切記在執行角色切換時，隻保留一個執行個體啟動，其他執行個體應當全部SHUTDOWN。等角色轉換操作完成之後再啟動其他執行個體，角色轉換的操作會自動傳播到這些執行個體上，并不需要DBA再對這些執行個體單獨做處理。
注意下列操作的執行步驟，強烈建議按照以下步驟執行，否則可能導緻切換不成功。
1．準備工作
檢查Primary和邏輯Standby的初始化參數設定，正常的檢查包括：
檢查兩機中初始化參數FAL_SERVER、FAL_CLIENT、LOG_ARCHIVE_CONFIG的參數值設定是否正确。
檢查兩機中初始化參數LOG_ARCHIVE_DEST_n的參數值設定是否正确。
首先來看目前的Primary資料庫：
SQL> SHOW PARAMETER FAL;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
fal_client string orcl_pd
fal_server string orcl_st
SQL> SHOW PARAMETER LOG_ARCHIVE_DEST;
NAME TYPE VALUE
log_archive_dest string
log_archive_dest_1 string location=/u01/archive
log_archive_dest_10 string
log_archive_dest_2 string service=LGDG
從上述顯示的結果來看，Primary資料庫的初始化參數并不太适合，為了避免其轉換之後可能發生的錯誤，我們提前做些修改：
SQL> ALTER SYSTEM SET FAL_SERVER='LGDG';
SQL> alter system set log_archive_dest_1='location=/u01/archive
valid_for=(online_logfiles,all_roles) db_unique_name=orcl_pd';
System altered.
SQL> alter system set log_archive_dest_3='location=/u01/std
valid_for=(standby_logfiles,standby_role) db_unique_name=orcl_pd';
System altered.
然後再看看待轉換的邏輯Standby：
SQL> SHOW PARAMETER FAL;
fal_client string orcl_st
fal_server string orcl_pd
log_archive_dest_1 string LOCATION=/u01/archive VALID_FO
R=(ONLINE_LOGFILES, ALL_ROLES)
DB_UNIQUE_NAME=LGDG
log_archive_dest_2 string service=orcl_pd lgwr sync AFFI
RM
log_archive_dest_3 string LOCATION=/u01/std
VALID_FOR=(STANDBY_LOGFILES, S
TANDBY_ROLE) DB_UNIQUE_NAME=LG
DG
修改一下：
SQL> ALTER SYSTEM SET FAL_CLIENT='LGDG';
最後檢查Primary資料庫是否配置了Standby Redologs：
SQL> select * from v$logfile;
GROUP# STATUS TYPE MEMBER
---------- ------- ------- -------------------------------------------------------------------------
3 ONLINE /u01/app/oracle/oradata/orcl/redo03.log
2 ONLINE /u01/app/oracle/oradata/orcl/redo02.log
1 ONLINE /u01/app/oracle/oradata/orcl/redo01.log
4 STANDBY /u01/app/oracle/oradata/orcl/redo04.log
5 STANDBY /u01/app/oracle/oradata/orcl/redo05.log
6 STANDBY /u01/app/oracle/oradata/orcl/redo06.log
7 STANDBY /u01/app/oracle/oradata/orcl/redo07.log
已經存在， 如果不存在，我們就手工的添加一下：
2．檢查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;
PREPARING SWITCHOVER
4．準備轉換邏輯Standby為Primary
邏輯Standby資料庫準備轉換為Primary角色，執行下列語句：
SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY;
語句執行時響應可能會有點慢。
執行完後檢視目前邏輯Standby資料庫的轉換狀态：
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
--------------------
PREPARING SWITCHOVER
5．再次檢查Primary資料庫狀态
執行下列語句：
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;
該語句需要等待目前Primary資料庫所有事務全部結束才開始執行。該語句執行過程中會自動拒絕使用者送出新事務或修改需求。為了確定該操作盡可能快的執行，最好自開始切換操作起就禁止所有使用者的操作。
該指令執行完之後，這個Primary資料庫就已經成為新的邏輯Standby了。不過在新Primary執行完轉換之前，不要關閉目前這個資料庫。
7．再次檢查邏輯Standby狀态
邏輯Standby在接收到前Primary的轉換消息，并應用完相關的REDO資料之後，會自動暫停SQL應用，然後查詢SWITCHOVER_STATUS的狀态，應該為TO PRIMARY：
SQL>SELECT SWITCHOVER_STATUS FROM V$DATABASE;
TO PRIMARY
或者
NOT ALLOWED
8．轉換邏輯Standby為新的Primary資料庫
最後的工作總會在邏輯Standby端操作，通過下列語句，将該邏輯Standby轉換為新的Primary資料庫：
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
轉換操作至此完成。
最後啟動新邏輯Standby，即前Primary資料庫端的SQL應用即可：
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
注意：每一個邏輯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');
轉到邏輯Standby端檢視：
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角色。
語句執行完成後，再次檢視目前資料庫的角色：
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;
如果你運氣好，等語句執行完之後，恢複過程就完成了。如果你非常不幸地碰到了ORA-16109錯誤，那麼我不得不告訴你，恐怕你得重建邏輯Standby了。
![【MySQL資料庫】資料庫索引事務1.索引2.事務[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)