?
?
第三部分邏輯standby(3)角色轉(zhuǎn)換? 2008.02.22
?
??? 關(guān)于角色轉(zhuǎn)換的一些概念在物理standby 章節(jié)的時候已經(jīng)講了很多，在概念和操作方式上二者基本一致，不過如果你真正深刻理解了物理standby 和邏輯standby，你會意識到，對于邏輯standby 而言，不管是switchover還是failover，怎么操作起來，都這么怪怪的呢~~~
?
?
邏輯standby之switchover
?
??? 要在primary 和邏輯standby 之間切換角色，一般是從操作primary 開始。
??? 提示：
??? 如果primary 或邏輯standby 是rac 結(jié)構(gòu)，切記只保留一個實例啟動，其它實例全部shutdown。等角色轉(zhuǎn)換操作完成之后再啟動其它實例，角色轉(zhuǎn)換的操作會自動傳播到這些實例上，并不需要你再對這些實例單獨做處理。
?
?
一、準備工作
1、檢查primary 和邏輯standby 的初始化參數(shù)設(shè)置，常規(guī)的檢查包括：
??? ●確保fal_server,fal_client 值設(shè)置正確
??? ●確保log_archive_dest_n 參數(shù)設(shè)置正確
??? 更多可能涉及的初始化參數(shù)可以參考2.1 中的第4 小章
?
??? 首先來看當(dāng)前的primary數(shù)據(jù)庫：
??? JSSWEB> show parameter fal
??? NAME?????????????????????? TYPE??????? VALUE
??? -------------------------- ----------- -------------------------------
??? fal_client???????????????? string????? jssweb
??? fal_server???????????????? string????? jsspdg
?
??? JSSWEB> show parameter name_convert
??? NAME?????????????????????? TYPE??????? VALUE
??? -------------------------- ----------- -------------------------------
??? db_file_name_convert?????? string????? oradata\jsspdg, oradata\jssweb
??? log_file_name_convert????? string????? oradata\jsspdg, oradata\jssweb
?
??? JSSWEB> show parameter log_archive_dest
??? NAME?????????????????????? TYPE??????? VALUE
??? -------------------------- ----------- -------------------------------
??? log_archive_dest?????????? string
??? log_archive_dest_1???????? string????? LOCATION=E:\ora10g\oradata\jssweb\arc
?????????????????????????????????????????? VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
?????????????????????????????????????????? DB_UNIQUE_NAME=jssweb
??? log_archive_dest_2???????? string????? service=jsspdg OPTIONAL LGWR SYNC AFFIRM
?????????????????????????????????????????? VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
?????????????????????????????????????????? DB_UNIQUE_NAME=jsspdg
??? ................
??? ................
??? ................
??? log_archive_dest_state_1?? string????? ENABLE
??? log_archive_dest_state_2?? string????? defer
?
??? 由于此處primary 的初始化參數(shù)并不合適，為了避免其轉(zhuǎn)換之后發(fā)生錯誤，我們需要提前做些修改：
??? JSSWEB> alter system set log_archive_dest_2='location=e:\ora10g\oradata\jssweb\std\valid_for=(standby_logfiles,standby_role) db_unique_name=jssweb';
???
系統(tǒng)已更改。
?
??? JSSWEB> alter system set log_archive_dest_1='location=e:\ora10g\oradata\jssweb\arc\valid_for=(online_logfiles,all_roles) db_unique_name=jssweb';
???
系統(tǒng)已更改。
?
??? JSSWEB> alter system set log_archive_dest_state_2='enable';
???
系統(tǒng)已更改。
?
??? JSSWEB> alter system set fal_server='jssldg';
???
系統(tǒng)已更改。
?
??? --xx_file_name_convert
這兩個參數(shù)無法動態(tài)修改，因此我們首先修改
spfile
，然后再重啟一下數(shù)據(jù)庫
??? JSSWEB> alter system set db_file_name_convert='oradata\jssldg','oradata\jssweb' scope=spfile;
???
系統(tǒng)已更改。
??? JSSWEB> alter system set log_file_name_convert='oradata\jssldg','oradata\jssweb' scope=spfile;
???
系統(tǒng)已更改。
?
??? JSSWEB> startup force
?
??? 然后再看看待轉(zhuǎn)換的邏輯standbstandby
??? JSSLDG> show parameter fal
??? NAME?????????????????? TYPE??????? VALUE
??? ---------------------- ----------- --------------------
??? fal_client?????????? string
??? fal_server?????????? string
?
??? JSSLDG> show parameter file_name
??? NAME?????????????????? TYPE??????? VALUE
??? ---------------------- ----------- --------------------
??? db_file_name_convert?? string????? oradata\jssweb, oradata\jssldg
??? log_file_name_convert? string????? oradata\jssweb, oradata\jssldg
?
??? JSSLDG> show parameter log_archive
??? NAME?????????????????? TYPE??????? VALUE
??? ---------------------- ----------- --------------------
??? log_archive_config???? string????? DG_CONFIG=(jssweb,jsspdg,jssldg)
??? log_archive_dest?????? string
??? log_archive_dest_1???? string????? location=E:\ora10g\oradata\jssldg\arc\
?????????????????????????????????????? valid_for=(online_logfiles,all_roles)
?????????????????????????????????????? db_unique_name=jssldg
??? log_archive_dest_10??? string
??? log_archive_dest_2???? string????? location=E:\ora10g\oradata\JSSLDG\std\
?????????????????????????????????????? valid_for=(standby_logfiles,standby_role)
?????????????????????????????????????? db_unique_name=JSSLDG
??? .......................
??? .......................
?
?
??? 對于待轉(zhuǎn)換的邏輯standby 中，某些初始化參數(shù)也可以不設(shè)置，不過走到這一步了，順手全設(shè)置一遍。
??? JSSLDG> alter system set fal_server='jssweb';
??? 系統(tǒng)已更改。
??? JSSLDG> alter system set fal_client='jssldg';
??? 系統(tǒng)已更改。
??? JSSLDG> alter system set log_archive_dest_3='service=jssweb lgwr async?valid_for=(online_logfiles,primary_role) db_unique_name=jssweb';
??? 系統(tǒng)已更改。
?
2、檢查primary 數(shù)據(jù)庫是否配置了standby redologs
??? JSSWEB> select * from v$standby_log;
??? 未選定行
?
??? 對于邏輯standby 數(shù)據(jù)庫，standby redologs 是必須的，因此我們需要為當(dāng)前的primary 創(chuàng)建幾個standbyredologs。
??? JSSWEB> alter database add standby logfile group 4 ('e:\ora10g\oradata\jssweb\standbyrd01.log') size 20m;
??? 數(shù)據(jù)庫已更改。
??? .....................
??? .......................
??? .........................
??? JSSWEB> alter database add standby logfile group 8 ('e:\ora10g\oradata\jssweb\standbyrd05.log') size 20m;
??? 數(shù)據(jù)庫已更改。
?
?
二、檢查primary數(shù)據(jù)庫狀態(tài)
?
??? 在當(dāng)前的primary 數(shù)據(jù)庫查詢v$database 視圖中的switchover_status 列，查看當(dāng)前primary 數(shù)據(jù)庫狀態(tài)。
??? JSSWEB> select switchover_status from v$database;
??? SWITCHOVER_STATUS
??? --------------------
??? TO STANDBY
?
??? 如果該查詢返回TO STANDBY 或SESSIONS ACTIVE 則表示狀態(tài)正常，可以執(zhí)行轉(zhuǎn)換操作，如果否的話，就需要你先檢查一下當(dāng)前的dataguard 配置，看看是否
?
?
三、準備轉(zhuǎn)換primary為邏輯standby
?
??? 執(zhí)行下列語句，將primary 置為準備轉(zhuǎn)換的狀態(tài)：
??? JSSWEB> alterdatabasepreparetoswitchovertologicalstandby;
??? 數(shù)據(jù)庫已更改。
?
??? 查看一下switchover_status 的狀態(tài)，喲，果然變成準備ing 啦~~
??? JSSWEB> select switchover_status from v$database;
??? SWITCHOVER_STATUS
??? --------------------
??? PREPARING SWITCHOVER
?
?
四、準備轉(zhuǎn)換邏輯standby為primary
?
??? 我們一定要學(xué)習(xí)oracle 這種邏輯，甭管想做什么，都得先有個準備的過程~
??? JSSLDG> alterdatabasepreparetoswitchovertoprimary;
??? 數(shù)據(jù)庫已更改。
??? JSSLDG> select switchover_status from v$database;
??? SWITCHOVER_STATUS
??? --------------------
??? PREPARING SWITCHOVER
?
?
五、再次檢查primary數(shù)據(jù)庫狀態(tài)
?
??? JSSWEB> select switchover_status from v$database;
??? SWITCHOVER_STATUS
??? --------------------
??? TO LOGICAL STANDBY
?
??? 注意：這步雖然不做什么操作，但檢查結(jié)果卻非常重要，它直接關(guān)系到switchover 轉(zhuǎn)換是否能夠成功。邏輯standby 執(zhí)行完prepare 命令之后，就會生成相應(yīng)的LogMiner 字典數(shù)據(jù)(就像我們前面創(chuàng)建邏輯standby 時，primary 會生成LogMiner 字典數(shù)據(jù)一樣)，只有它正常生成并發(fā)送至當(dāng)前的primary，轉(zhuǎn)換操作才能夠繼續(xù)下去。不然當(dāng)前的primary 數(shù)據(jù)庫在轉(zhuǎn)換完之后，可能就失去了從新的primary 接收redo 數(shù)據(jù)的能力了。
?
??? 因此，如果上述查詢的返回結(jié)果不是：TO LOGICAL STANDBY 的話，你可能就需要取消此次轉(zhuǎn)換，檢查原因，然后再重新操作了。
??? 提示：
??? 取消轉(zhuǎn)換可以通過下列語句：
??? ALTER DATABASE PREPARE TO SWITCHOVER CANCEL;
??? 需要分別在primary 和邏輯standby 執(zhí)行。
?
?
六、轉(zhuǎn)換primary為邏輯standby
?
??? 執(zhí)行下列語句：
??? JSSWEB> alterdatabasecommittoswitchovertologicalstandby;
??? 數(shù)據(jù)庫已更改。
?
??? 該語句需要等待當(dāng)前primary 所有事務(wù)全部結(jié)束。同時該語句也會自動拒絕用戶發(fā)布的新事務(wù)或修改需求。為確保該操作盡可能快的執(zhí)行，最好自開始切換操作起就禁止所有用戶的操作。
??? 該命令執(zhí)行完之后，這個primary 就已經(jīng)成為新的邏輯standby 了。不過在新primary 執(zhí)行完轉(zhuǎn)換之前，不要關(guān)閉當(dāng)前這個數(shù)據(jù)庫。
?
?
七、再次檢查邏輯standby狀態(tài)
?
??? 邏輯standby 在接收到前primary 的轉(zhuǎn)換消息，并應(yīng)用完相關(guān)的redo 數(shù)據(jù)之后，會自動暫停sql 應(yīng)用，然后查詢switchover_status 的狀態(tài)，應(yīng)該為：TO PRIMARY
??? JSSLDG> select switchover_status from v$database;
??? SWITCHOVER_STATUS
??? --------------------
??? TO PRIMARY
?
?
八、轉(zhuǎn)換邏輯standby為primary
?
??? 最后的工作總會在邏輯standby 上操作，通過上列語句，將該邏輯standby 轉(zhuǎn)換為新的primary。
??? JSSLDG> alterdatabasecommittoswitchovertoprimary;
??? 數(shù)據(jù)庫已更改。
?
??? 轉(zhuǎn)換完成
?
?
九、啟動新邏輯standby的sql應(yīng)用
??? 最后啟動新邏輯standby 的sql 應(yīng)用。
??? JSSWEB> alter database start logical standby apply;
??? 數(shù)據(jù)庫已更改。
?
??? 提示：還記的我們的jsspdg 嗎，雖然它也是standby(物理)，不過它現(xiàn)在也并非這個dataguard 配置中的一員了，這也是由于邏輯standby 自身特性決定的，每一個邏輯standby 都相當(dāng)于是一個不同于primary 的數(shù)據(jù)庫(DBID都不同)，因此在邏輯standby 完成了轉(zhuǎn)換之后，相當(dāng)于原primary 已經(jīng)消失，因此原primary 配置的物理standby也失去了主從參照，不過原primary 配置的邏輯standby 不會有影響。
?
?
邏輯standby之failover
??? 前面學(xué)習(xí)物理standby 的failover 時我們提到過，failover 有可能會丟失數(shù)據(jù)(視當(dāng)前的數(shù)據(jù)庫保護模式而定)，對于邏輯standby 也一樣；物理standby 在做failover 演示時還提到過，所有的操作都會在standby 端執(zhí)行，對于邏輯standby 這也一樣，甚至對于明確提及在前primary 執(zhí)行的，你不執(zhí)行，也沒關(guān)系，畢竟對于failover，我們假設(shè)的就是，primary 已經(jīng)over 了:)
?
?
一、準備工作要充分
?
??? 準備工作可以從以下幾個方面著手：
?
1、檢查及處理丟失的歸檔
?
??? 雖然本步不是必須的，但如果希望盡可能少丟失數(shù)據(jù)，除了數(shù)據(jù)保護模式之外，本步操作也非常重要。如果此時primary 仍可被訪問，首先檢查當(dāng)前的歸檔日志序號與邏輯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 的數(shù)據(jù)庫已經(jīng)無法打開，您就只好直接到磁盤上查看歸檔目錄中的序號來與standby端做比較了。
?
??? 如果不同序號，則將primary 尚未發(fā)送至standby 的歸檔文件手工復(fù)制到待轉(zhuǎn)換的邏輯standby 服務(wù)器，然后在standby 端通過ALTER DATABASE REGISTER LOGICAL LOGFILE ''; 命令將文件手工注冊
??? 如果standby 與primary 的歸檔序號相同，但某些序號的applied 狀態(tài)為no，建議你檢查一下當(dāng)前standby是否啟動了SQL 應(yīng)用：）。
?
2、檢查待轉(zhuǎn)換邏輯standby 的日志應(yīng)用情況
??? 可以通過查詢v$logstdby_progress 視圖：
??? JSSWEB> select applied_scn,latest_scn from v$logstdby_progress;
??? APPLIED_SCN LATEST_SCN
??? ----------- ----------
??? 1259449 ??? 1259453
?
??? 如果兩值一致，表示所有接收到的歸檔都已經(jīng)應(yīng)用了。
?
3、檢查及修正待轉(zhuǎn)換邏輯standby 的初始化參數(shù)配置
??? 確認待轉(zhuǎn)換的邏輯standby 配置了正確的歸檔路徑，不僅是寫本地的歸檔，還要有寫遠程的歸檔，不然轉(zhuǎn)換完之后，這臺新的primary 就成了光桿司令了。
??? JSSWEB> show parameter log_archive_dest
??? .......................
?
??? 當(dāng)然一般來說，我們都是推薦在創(chuàng)建standby 的同時將一些用于角色切換的初始化參數(shù)也配置好(primary 和standby 端都應(yīng)如此)，以減小切換時操作的時間，提高切換效率。
?
二、激活新的primary數(shù)據(jù)庫
?
??? 首先查看當(dāng)前操作的角色
??? JSSWEB> select database_role,force_logging from v$database;
??? DATABASE_ROLE ?? FOR
??? ---------------- ---
??? LOGICAL STANDBY YES
??? 注意，如果當(dāng)前force_logging 為no，務(wù)必執(zhí)行：Alter database force logging;
??? 轉(zhuǎn)換standby 角色為primary
??? JSSWEB> altealterdatabaseactivatelogicalstandbydatabasefinishapply;
??? 數(shù)據(jù)庫已更改。
?
??? 該語句主要是停止待轉(zhuǎn)換的邏輯standby 中RFS 進程，并應(yīng)用完當(dāng)前所有已接收但并未應(yīng)用的redo 數(shù)據(jù)，然后停止sql 應(yīng)用，將數(shù)據(jù)庫轉(zhuǎn)換成primary 角色。
??? JSSWEB> select database_role,force_logging from v$database;
??? DATABASE_ROLE ?? FOR
??? ---------------- ---
??? PRIMARY ???????? YES
?
??? 基本上到這一步，我們可以說角色轉(zhuǎn)換的工作已經(jīng)完成了，但是注意，活還沒有干完！
?
??? 此處與邏輯standby 的switchover 同理，切換完之后，原dg 配置就失效了(不僅原物理standby 沒了，原邏輯standby 也失去了參照，看看，邏輯standby 的failover 確實威力巨大呀，怪不得邏輯standby 用的人這么人呢，環(huán)境脆弱肯定是原因之一啊)，因此我們需要做些設(shè)置，重新將原來的standby 再加入到新的dg 配置環(huán)境中。
?
?
三、修復(fù)其它standby
?
??? 注意喲，邏輯standby 的修復(fù)可并不像物理standby 那樣簡單，每個邏輯standby 都相當(dāng)于是獨立的數(shù)據(jù)庫，如果你不希望重建邏輯standby 的話呢，oracle 倒是也提供了其它解決方案(雖然不一定好使)：
?
1、在各個原邏輯standby 中創(chuàng)建數(shù)據(jù)庫鏈，連接到新的primary
?
??? 注意，數(shù)據(jù)庫鏈中用于連接新primary 的用戶必須擁有SELECT_CATALOG_ROLE 角色。
??? JSSLDG2> alter session disable guard;
??? 會話已更改。
??? JSSLDG2> create database link getjssweb connect to jss identified by jss using 'jssweb';
??? 數(shù)據(jù)庫鏈接已創(chuàng)建。
??? JSSLDG2> alter session enable guard;
??? 會話已更改。
?
??? 驗證一下數(shù)據(jù)鏈是否能夠正常訪問：
??? JSSLDG2> select sysdate from dual@getjssweb;
??? SYSDATE
??? --------------
??? 23-2 月-08
??? 提示：關(guān)于alter session enable|disable guard 語句，用于允許或禁止用戶修改邏輯standby 中的結(jié)構(gòu)。例如：
??? 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 行出現(xiàn)錯誤:
??? ORA-16224: Database Guard 已啟用
?
??? JSSLDG2> alter session disable guard;
??? 會話已更改。
?
??? JSSLDG2> alter table b rename to a;
??? 表已更改。
?
2、重新啟動SQL 應(yīng)用
??? 在各個邏輯standby 執(zhí)行下列語句啟動sql 應(yīng)用(注意更新dblinkName)：
??? JSSLDG2> alter database start logical standby apply new primary getjssweb;
??? 數(shù)據(jù)庫已更改。
?
??? 如果你運氣好，等語句執(zhí)行完之后，恢復(fù)過程就完成了。如果你非常不幸的碰到了ORA-16109 錯誤，那么我不得不告訴你，恐怕你得重建邏輯standby 了。所以，祝你好運吧:)
??? 語句順利執(zhí)行完之后，我們來驗證一下：
??? JSSWEB> alter system switch logfile;
??? 系統(tǒng)已更改。
?
??? JSSWEB> select max(sequence#) from v$archived_log;
??? MAX(SEQUENCE#)
??? --------------
??? 862
?
??? JSSLDG2> select sequence#,applied from dba_logstdby_log;
??? SEQUENCE#? APPLIED
??? ---------- --------
??? 862??????? NO
?
??? 注意：出現(xiàn)問題了！！
?
??? 日志是傳輸過去了，但是邏輯standby 并沒有開始應(yīng)用，怎么回事？
?
??? 我們先來確認一下standby 的各進程狀態(tài)：
??? 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，但是，為什么不應(yīng)用呢。
?
??? 手工查詢一下新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
??? 863 ?????? E:\ORA10G\ORADATA\JSSWEB\ARC\LOG1_863_641301252.ARC????? 2008-02-23 17:19:48
??? 863 ?????? jssldg2 ???????????????????????????????????????????????? 2008-02-23 17:20:59
??? 864 ?????? E:\ORA10G\ORADATA\JSSWEB\ARC\LOG1_864_641301252.ARC????? 2008-02-23 17:21:11
??? 864 ?????? jssldg2 ???????????????????????????????????????????????? 2008-02-23 17:21:13
??? 已選擇13 行。
??? 發(fā)現(xiàn)了一點點痕跡，我們的切換操作是下午3 點左右進行的，期間還產(chǎn)生了序列號為860,861 之類的歸檔文件，但并未傳輸至standby，是不是因為這些文件中包含了一部分應(yīng)被應(yīng)用的數(shù)據(jù)，因此造成standby
接收到的新primary 傳輸過來的歸檔scn 與最后應(yīng)用的scn 不連續(xù)，所以無法應(yīng)用？再來驗證一下：
??? JSSLDG2> select applied_scn,latest_scn from v$logstdby_progress;
??? APPLIED_SCN LATEST_SCN
??? ----------- ----------
??? 1259449 ??? 1284126
??? 果然如此，應(yīng)用的scn 與最后的scn 確實不匹配，剩下的就好解決了，把所有可疑的應(yīng)傳輸?shù)絪tandby的歸檔文件手工復(fù)制到standby，然后通過alter 命令注冊一下：
??? JSSLDG2> alter database register logical logfile 'E:\ora10g\oradata\jssldg2\std\LOG1_859_641301252.ARC';
??? 數(shù)據(jù)庫已更改。
??? JSSLDG2> alter database register logical logfile 'E:\ora10g\oradata\jssldg2\std\LOG1_860_641301252.ARC';
??? 數(shù)據(jù)庫已更改。
??? JSSLDG2> alter database register logical logfile 'E:\ora10g\oradata\jssldg2\std\LOG1_861_641301252.ARC';
??? 數(shù)據(jù)庫已更改。
?
??? 提示：復(fù)制文件的時候盡可能把相近時間段的歸檔文件都拷過來，不用擔(dān)心無用歸檔會不會影響到應(yīng)用，oracle 會自動判斷歸檔中的scn，對于已經(jīng)應(yīng)用過的正常情況下是不會重復(fù)應(yīng)用的，因此我們把
859,860,861 全部復(fù)制過來。
?
??? 再查看一下應(yīng)用狀態(tài)：
??? JSSLDG2> select sequence#,applied from dba_logstdby_log;
??? SEQUENCE# APPLIED
??? ---------- --------
??? 862 ?????? CURRENT
??? 863 ?????? CURRENT
?
??? 哈哈，已經(jīng)開始應(yīng)用了。邏輯standby 恢復(fù)成功！想起官方文檔中有一句提示，說的是在打開新的primary數(shù)據(jù)庫，生成數(shù)據(jù)字典之前，不要執(zhí)行任何DDL，不然就只能重建邏輯standby 了，估計就是擔(dān)心執(zhí)行ddl后不幸觸發(fā)日志切換，造成邏輯standby 接收新primary 傳來的歸檔文件不連續(xù)，無法順利應(yīng)用。
?
??? 切換完成之后，在修復(fù)邏輯standby 的同時，順手打掃一下戰(zhàn)場，比如設(shè)置新primary 數(shù)據(jù)庫的備份策略，以及考慮如何修復(fù)前故障的primary 等等，dba 這份工作，人前看起來光鮮，如果你已經(jīng)下定決心要從事這行，那對于人后的辛苦一定要有深刻心理準備喲，你看看像上面這種情況，primary 只要隨隨便便宕個機，引之而來的工作量就夠我們忙活的。
?
?
??? 也許這個時候dba 需要的不僅是保持清晰的大腦，還要能打開思路，此時我們更不妨考慮在做角色切換和修復(fù)損壞的primary 之間做個選擇，究竟哪個更快，哪個更簡便一些呢，你看，干dba 這行，不僅壓力大，不僅要本領(lǐng)過硬，不僅要耐心細致，關(guān)鍵時刻還要保持清醒的頭腦，額地神耶，太刺激啦，太有挑戰(zhàn)啦~~~~~~