本文作者：
junsansi????
轉載網址：
http://www.5ienet.com/index.shtml
?
?
第二部分物理standby(4)高級管理? 2008.1.13
?
??? 世上沒有永恒的主角，能夠留住永恒的反是那些默默無聞的小角色，這一節出場的都是重量級選手，它們雖然不是主角，但他們比主角更重要(有時候)。
?
?
一、READONLY/WRITE模式打開物理STANDBY
?
??? 前面提到關于物理standby 可以有效分擔primary 數據庫壓力，提升資源利用，實際上說的就是這個。以readonly 或read write 模式打開物理standby，你可以轉移一些查詢任何啦，備份啦之類的操作到standby 數據庫，以這種方式來分擔一些primary 的壓力。下面我們來演示一下，如何切換standby 數據庫的打開模式，其實，非常簡單。例如，以Read-only 模式打開物理standby：
?
??? 這里要分兩種情況：
?
???
1).standby 數據庫處于shutdown 狀態
?
??? 直接startup 即可。
???
SQL> startup
??? ORACLE 例程已經啟動。
??? ......
?
???
2).standby 數據庫處于redo 應用狀態
?
??? 首先取消redo 應用：
??? SQL> alter database recover managed standby database cancel;
??? 數據庫已更改。
?
??? 然后再打開數據庫
??? SQL> alter database open ;
??? 數據庫已更改。
?
??? 提示：open 的時候不需要附加read only 子句，oracle 會根據控制文件判斷是否是物理standby，從而自動啟動到read only 模式，直接startup 也是同理。
?
???
3).如果想從open 狀態再切換回redo 應用狀態，并不需要shutdown，直接啟用redo 應用即可，例如：
?
??? SQL> select status from v$instance;
??? STATUS
??? ------------
??? OPEN
??? SQL> alter database recover managed standby database disconnect from session;
??? 數據庫已更改。
??? SQL> select status from v$instance;
??? STATUS
??? ------------
??? MOUNTED
?
?
??? 正如演示中我們所看到的，操作有一點點復雜，并且由于只讀打開時就不能應用，雖然我們能夠查詢，但是查詢的結果確是與primary 不同步的，這點大大降低了物理standby 做報表服務分擔主庫壓力的可能性，對于這點呢，我們有兩個解決方案：
?
??? 1、改用邏輯standby，由于邏輯standby 是打開狀態下的實時應用，因此數據同步應該是沒啥問題了（只要primary 的數據類型和操作邏輯standby 都能被支持），當然邏輯standby 有邏輯standby 的問題，這個看完后面的邏輯standby 相關章節，您就明白了。
??? 2、據稱oracle11g 全面改良了物理standby，最突出的特點就是在read only 打開模式下，可以邊接收邊應用了（這下不用擔心查詢的數據不及時的問題了），您可以考慮升級您的數據庫到最新版本，當然新版本也有新版本的問題，比如各種尚未暴露出來的bug，想想就擔心是不是:)
?
??? 所以你看，做技術其實并不困難，難的是做決擇。這么引申過來看一看，老板們不容易啊，怪不得越大的領導腦袋上頭發越少呢，為了保持我干凈整潔濃密的發型，我我，我還是選擇干技術吧~~~~
?
?
二、管理影響standby的primary數據庫事件
?
??? 為預防可能的錯誤，你必須知道primary 數據庫的某些事件可能影響standby 數據庫，并且了解如何處理。
?
??? 某些情況下，primary 數據庫的某些改動會自動通過redo 數據傳播到standby 數據庫，因此不需要在standby數據庫做額外的操作，而某些情況，則需要你手工調整。
?
??? 下列事件會由redo 傳輸服務及redo 應用自動處理，不需要dba 的干預，分別是：
??? ● ALTER DATABASE ENABLE|DISABLE THREAD 語句(主要針對rac 環境，目前基本已廢棄，因為ENABLE|DISABLE INSTANCE 子句完全能夠實現類似功能)
??? ● 修改表空間狀態(例如read-write 到read-only，online 到offline)
??? ● 創建修改刪除表空間或數據文件(如果初始化參數STANDBY_FILE_MANAGEMENT 被設置為AUTO 的話，這點在前面第一章的時候提到過)
?
?
??? 下列事情則需要dba 手工干預：
?
1、添加修改刪除數據文件或表空間
?
??? 前面提到了，初始化參數STANDBY_FILE_MANAGEMENT 可以控制是否自動將primary 數據庫增加刪除表空間、數據文件的改動繼承到standby。
??? ● 如果該參數值設置為auto，則自動創建。
??? ● 如果設置為manual，則需要手工復制新創建的數據文件到standby 服務器。
?
??? 不過需要注意一點， 如果數據文件是從其它數據庫復制而來( 比如通過tts) ， 則不管STANDBY_FILE_MANAGEMENT 參數值如何設置，都必須同時復制到standby 數據庫，并注意要修改standby 數據庫的控制文件。
?
??? 下面分別通過示例演示STANDBY_FILE_MANAGEMENT 參數值為AUTO/MANUAL 值時增加及刪除
數據文件時的情形：
?
???
1).STANDBY_FILE_MANAGEMENT設置為AUTO，增加及刪除表空間和數據文件
?
??? 我們先來看看初始化參數的設置： ----standby 數據庫操作
??? SQL> show parameter standby_file
??? NAME????????????????????????? TYPE????????VALUE
??? ----------------------------- ----------- ---------------
??? standby_file_management?????? string????? AUTO
?
?????
A).增加新的表空間--primary 數據庫操作
??????? SQL> create tablespace mytmp datafile 'e:\ora10g\oradata\jssweb\mytmp01.dbf' size 20m;
??????? 表空間已創建。
??????? 檢查剛添加的數據文件
??????? SQL> select name from v$datafile;
??????? NAME
??????? -----------------------------------------------
??????? E:\ORA10G\ORADATA\JSSWEB\SYSTEM01.DBF
??????? E:\ORA10G\ORADATA\JSSWEB\UNDOTBS01.DBF
??????? E:\ORA10G\ORADATA\JSSWEB\SYSAUX01.DBF
??????? E:\ORA10G\ORADATA\JSSWEB\USERS01.DBF
??????? E:\ORA10G\ORADATA\JSSWEB\WEBTBS01.DBF
??????? E:\ORA10G\ORADATA\JSSWEB\MYTMP01.DBF
??????? 已選擇6 行。
?
??????? 切換日志
??????? SQL> alter system switch logfile;
??????? 系統已更改。
?
????? B).驗證standby 庫--standby 數據庫操作
??????? SQL> select name from v$datafile;
??????? NAME
??????? ----------------------------------------------------
??????? E:\ORA10G\ORADATA\JSSPDG\SYSTEM01.DBF
??????? E:\ORA10G\ORADATA\JSSPDG\UNDOTBS01.DBF
??????? E:\ORA10G\ORADATA\JSSPDG\SYSAUX01.DBF
??????? E:\ORA10G\ORADATA\JSSPDG\USERS01.DBF
??????? E:\ORA10G\ORADATA\JSSPDG\WEBTBS01.DBF
??????? E:\ORA10G\ORADATA\JSSPDG\MYTMP01.DBF
??????? 已選擇6 行。
??????? SQL> select name from v$tablespace;
??????? NAME
??????? ------------------------------
??????? SYSTEM
??????? UNDOTBS1
??????? SYSAUX
??????? TEMP
??????? USERS
??????? WEBTBS
??????? MYTMP
??????? 已選擇7 行。
?
??????? 可以看到，表空間和數據文件已經自動創建，你是不是奇怪為什么數據文件路徑自動變成了jsspdg，赫赫，因為我們設置了db_file_name_convert 嘛。
?
?????
C).刪除表空間--primary 數據庫操作
??????? SQL> drop tablespace mytmp including contents and datafiles;
??????? 表空間已刪除。
??????? SQL> select name from v$datafile;
??????? NAME
??????? --------------------------------------------------
??????? E:\ORA10G\ORADATA\JSSWEB\SYSTEM01.DBF
??????? E:\ORA10G\ORADATA\JSSWEB\UNDOTBS01.DBF
??????? E:\ORA10G\ORADATA\JSSWEB\SYSAUX01.DBF
??????? E:\ORA10G\ORADATA\JSSWEB\USERS01.DBF
??????? E:\ORA10G\ORADATA\JSSWEB\WEBTBS01.DBF
??????? SQL> alter system switch logfile;
??????? 系統已更改。
??????? 提示：使用including 子句刪除表空間時，
?
?????
D).驗證standby 數據庫--standby 數據庫操作
??????? SQL> select name from v$datafile;
??????? NAME
??????? --------------------------------------------------
??????? E:\ORA10G\ORADATA\JSSPDG\SYSTEM01.DBF
??????? E:\ORA10G\ORADATA\JSSPDG\UNDOTBS01.DBF
??????? E:\ORA10G\ORADATA\JSSPDG\SYSAUX01.DBF
??????? E:\ORA10G\ORADATA\JSSPDG\USERS01.DBF
??????? E:\ORA10G\ORADATA\JSSPDG\WEBTBS01.DBF
??????? SQL> select name from v$tablespace;
??????? NAME
??????? ------------------------------
??????? SYSTEM
??????? UNDOTBS1
??????? SYSAUX
??????? TEMP
??????? USERS
??????? WEBTBS
??????? 已選擇6 行。
??????? 得出結論，對于初始化參數STANDBY_FILE_MANAGMENT 設置為auto 的話，對于表空間和數據文件的操作完全無須dba 手工干預，primary 和standby 都能很好的處理。
?
???
2).STANDBY_FILE_MANAGEMENT設置為MANUAL，增加及刪除表空間和數據文件
?
?????
A).增加新的表空間--primary 數據庫操作
??????? SQL> create tablespace mytmp datafile 'e:\ora10g\oradata\jssweb\mytmp01.dbf' size 20m;
??????? 表空間已創建。
??????? 檢查剛添加的數據文件
??????? SQL> select name from v$datafile;
??????? NAME
??????? -----------------------------------------------
??????? E:\ORA10G\ORADATA\JSSWEB\SYSTEM01.DBF
??????? E:\ORA10G\ORADATA\JSSWEB\UNDOTBS01.DBF
??????? E:\ORA10G\ORADATA\JSSWEB\SYSAUX01.DBF
??????? E:\ORA10G\ORADATA\JSSWEB\USERS01.DBF
??????? E:\ORA10G\ORADATA\JSSWEB\WEBTBS01.DBF
??????? E:\ORA10G\ORADATA\JSSWEB\MYTMP01.DBF
??????? 已選擇6 行。
??????? 切換日志
??????? SQL> alter system switch logfile;
??????? 系統已更改。
?
????? B).驗證standby 庫--standby 數據庫操作
??????? SQL> select name from v$datafile;
??????? NAME
??????? ----------------------------------------------------
??????? E:\ORA10G\ORADATA\JSSPDG\SYSTEM01.DBF
??????? E:\ORA10G\ORADATA\JSSPDG\UNDOTBS01.DBF
??????? E:\ORA10G\ORADATA\JSSPDG\SYSAUX01.DBF
??????? E:\ORA10G\ORADATA\JSSPDG\USERS01.DBF
??????? E:\ORA10G\ORADATA\JSSPDG\WEBTBS01.DBF
??????? E:\ORA10G\PRODUCT\10.2.0\DB_1\DATABASE\UNNAMED00006
??????? 已選擇6 行。
??????? SQL> select name from v$tablespace;
??????? NAME
??????? ------------------------------
??????? SYSTEM
??????? UNDOTBS1
??????? SYSAUX
??????? TEMP
??????? USERS
??????? WEBTBS
??????? MYTMP
??????? 已選擇7 行。
??????? 可以看到，表空間已經自動創建，但是，數據文件卻被起了個怪名字，手工修改其與primary
??????? 數據庫保持一致，如下(注意執行命令之后手工復制數據文件到standby)：
??????? SQL> alter database create datafile'E:\ORA10G\PRODUCT\10.2.0\DB_1\DATABASE\UNNAMED00006'
?????????? 2 as 'E:\ora10g\oradata\jsspdg\mytmp01.dbf';
??????? 數據庫已更改。
?
????? C).刪除表空間--primary 數據庫操作
??????? SQL> drop tablespace mytmp including contents and datafiles;
??????? 表空間已刪除。
??????? SQL> select name from v$datafile;
??????? NAME
??????? --------------------------------------------------
??????? E:\ORA10G\ORADATA\JSSWEB\SYSTEM01.DBF
??????? E:\ORA10G\ORADATA\JSSWEB\UNDOTBS01.DBF
??????? E:\ORA10G\ORADATA\JSSWEB\SYSAUX01.DBF
??????? E:\ORA10G\ORADATA\JSSWEB\USERS01.DBF
??????? E:\ORA10G\ORADATA\JSSWEB\WEBTBS01.DBF
??????? SQL> alter system switch logfile;
??????? 系統已更改。
?
???? D).驗證standby 數據庫--standby 數據庫操作
??????? SQL> select name from v$datafile;
??????? NAME
??????? ----------------------------------------------------
??????? E:\ORA10G\ORADATA\JSSPDG\SYSTEM01.DBF
??????? E:\ORA10G\ORADATA\JSSPDG\UNDOTBS01.DBF
??????? E:\ORA10G\ORADATA\JSSPDG\SYSAUX01.DBF
??????? E:\ORA10G\ORADATA\JSSPDG\USERS01.DBF
??????? E:\ORA10G\ORADATA\JSSPDG\WEBTBS01.DBF
??????? E:\ORA10G\PRODUCT\10.2.0\DB_1\DATABASE\UNNAMED00006
??????? 已選擇6 行。
??????? SQL> select name from v$tablespace;
??????? NAME
??????? ------------------------------
??????? SYSTEM
??????? UNDOTBS1
??????? SYSAUX
??????? TEMP
??????? USERS
??????? WEBTBS
??????? MYTMP
??????? 已選擇7 行。
??????? 呀，數據還在啊。趕緊分析分析，查看alert_jsspdg.log 文件，發現如下(特別注意粗體)：
?
??????? File #6 added to control file as 'UNNAMED00006' because
??????? the parameter STANDBY_FILE_MANAGEMENT is set to MANUAL
??????? The file should be manually created to continue.
??????? Errors with log E:\ORA10G\ORADATA\JSSPDG\LOG1_753_641301252.ARC
??????? MRPMRP0:BackgroundMediaRecoveryterminatedwitherror1274
??????? Fri Jan 18 09:48:45 2008
??????? 這下明白了，為什么有個UNNAMED00006 的數據文件，也曉得為啥standby 數據庫沒能刪除新加的表空間了吧，原來是后臺的redo 應用被停掉了，重啟redo 應用再來看看：
??????? SQL> alter database recover managed standby database disconnect from session;
??????? 數據庫已更改。
??????? SQL> select name from v$datafile;
??????? NAME
??????? ----------------------------------------------
??????? E:\ORA10G\ORADATA\JSSPDG\SYSTEM01.DBF
??????? E:\ORA10G\ORADATA\JSSPDG\UNDOTBS01.DBF
??????? E:\ORA10G\ORADATA\JSSPDG\SYSAUX01.DBF
??????? E:\ORA10G\ORADATA\JSSPDG\USERS01.DBF
??????? E:\ORA10G\ORADATA\JSSPDG\WEBTBS01.DBF
?
??????? 注意，既使你在primary 數據庫執行刪除時加上了including 子句，在standby 數據庫仍然只會將表空間和數據文件從數據字典中刪除，你還需要手工刪除表空間涉及的數據文件。
?
??? 再次得出結論，初始化參數STANDBY_FILE_MANAGMENT 設置為manual 的話，對于表空間和數據文件的操作必須有dba 手工介入，你肯定會問，這太麻煩了，那我干脆配置dg 的時候直接把初始化參數設置為auto 不就好了嘛，en，你想的很好，不過三思需要提醒你地是，如果你的存儲采用文件系統，那當然沒有問題，但是如果采用了裸設備，你就必須將該參數設置為manual。
?
2、重命名數據文件
??? 如果primary 數據庫重命令了一個或多個數據文件，該項修改并不會自動傳播到standby 數據庫。因為此，如果你想讓standby 和數據文件與primary 保持一致，那你也只能自己手工操作了。這會兒就算STANDBY_FILE_MANAGEMENT 也幫不上忙啦，不管它是auto 還是manual。下面通過示例做個演示：
?
???
A).將重命名的數據文件所在表空間offline --primary 數據庫操作
??? SQL> alter tablespace webtbs offline;
??? 表空間已更改。
?
??? B).手工將數據文件改名(操作系統) --primary 數據庫操作
??? 方式多樣，不詳述。
?
??? C).通過命令修改數據字典中的數據文件路徑，并online 表空間--primary 數據庫操作
??? SQL> alter tablespace webtbs rename datafile
?????? 2 'E:\ORA10G\ORADATA\JSSWEB\WEBTBS01.DBF' to
?????? 3 'E:\ORA10G\ORADATA\JSSWEB\TBSWEB01.DBF';
??? 表空間已更改。
??? SQL> alter tablespace webtbs online;
??? 表空間已更改。
?
??? D).暫停redo 應用，并shutdown --standby 數據庫操作
??? SQL> alter database recover managed standby database cancel;
??? 數據庫已更改。
??? SQL> shutdown immediate
??? ORA-01109: 數據庫未打開
??? ......
?
??? E).手工將數據文件改名(操作系統) --standby 數據庫操作
??? 方式多樣，不詳述。
?
???
F).重啟standby，修改數據文件路徑(數據字典) --standby 數據庫操作
??? SQL> startup mount
??? ORACLE 例程已經啟動。
??? Total System Global Area 167772160 bytes
??? Fixed Size 1289484 bytes
??? Variable Size 150995700 bytes
??? Database Buffers 8388608 bytes
??? Redo Buffers 7098368 bytes
??? 數據庫裝載完畢。
??? SQL> alter database rename file
???? ?2 'E:\ORA10G\ORADATA\JSSPDG\WEBTBS01.DBF' to
????? 3 'E:\ORA10G\ORADATA\JSSPDG\TBSWEB01.DBF';
??? 數據庫已更改。
?
???
G).重新啟動redo 應用。
??? SQL> alter database recover managed standby database disconnect from session;
??? 數據庫已更改。
?
???
H).切換日志--primary 數據庫操作
??? SQL> alter system switch logfile;
??? 系統已更改。
??? 峻工~~~~
?
3、添加或刪除OnlinOnlineredologs
?
??? 數據庫調優時極有可能會涉及到重置日志文件大小或增加刪除日志組等操作，基本上這種操作不會傳播到standby 數據庫，也不會影響到standby 數據庫的運行，但是如果你不注意其中的關系，造成的影響可能會很深遠，比如，我們假設我們的一臺primary 數據庫擁有5 組online redo 文件，standby 數據庫擁有2 組，當你執行switch over 之后，新的primary 執行歸檔的頻率會比standby 高的多，因此，當你在primary 數據庫增加或移除online redologs 時，一定記的手工同步一相standby 數據庫中相關的設置。
?
??? 這就是我們前面提到的standby redologs 與online redologs 之間的關系，即保證standby redologs 比onlineredologs 要至少多一組。
?
??? 操作的過程很簡單(總不會復雜過添加刪除數據文件)，這里就不演示了，需要你注意的就是在standby做操作前務必將STANDBY_FILE_MANAGEMENT 設置為MANUAL。
?
?
三、對openresetlogs的primary數據庫standby的恢復
??? 當primary 數據庫被以resetlogs 打開之后，dg 提供了一些方案，能夠讓你快速的恢復物理standby，當然這是有條件的，不可能所有的情況都可以快速恢復。我們都知道alter database open resetlogs 之后，數據庫的scn被重置，也就是此時其redo 數據也會從頭開始。當物理standby 接收到新的redo 數據時，redo 應用會自動獲取這部分redo 數據。對于物理standby 而言，只要數據庫沒有應用resetlogs 之后的redo 數據，那么這個過程是不需要dba 手工參與的。
?
??? 下表描述其它情況下如何同步standby 與primary 數據庫。
?
|
Standby數據庫狀態
|
Standby服務器操作
|
解決方案
|
|
沒有應用resetlog之前的redo數據
|
自動應用新的redo數據
|
無須手工介入
|
|
應用了resetlog之后的redo數據，不過standby打開了flashback。
|
可以應用，不過需要dba手工介入
|
1.手工flashback到應用之前
2.重啟redo應用，以重新接收新的redo數據。
|
|
應用了resetlog之后的redo數據，而且沒有flashback。
|
完全無法應用
|
重建物理standby是唯一的選擇
|
?
??? 很繞是吧，舉個例子你就明白了：
?
??? 假設primary 數據庫當前生成的archive sequence#如下：...26,27,28，然后在28 的時候執行了resetlogs，又生成了新的1,2,3.....，那么standby 能夠正常接收并應用26,27,28 及新產生的1,2,3....
??? 如果primary 數據庫在28 的時候發生數據出現故障，recover 到27，然后resetlogs，又生成了新的1,2,3.....這個時候(大家注意，招子放亮點)：如果standby 還沒有應用28，剛剛應用到27，則standby 還可以繼續接收新
的redo 數據1,2,3.....并應用。
??? 如果此時不幸，standby 由于是實時應用，已經應用了28 的redo 數據，那么如果standby 打開了flashback，不幸中的萬幸啊，這時候只需要dba 手工介紹先flashback 到27,然后再接收并應用新的1,2,3....
??? 如果此時非常不幸，standby 由于是實時應用，已經應用了28 的redo 數據，并且standby 也沒有打開flashback，那么，重建物理standby 是你唯一的選擇。
?
??? 這下大家都明白了吧，趕緊起立鼓掌感謝yangtingkun 大大的友情客串及形象示例，很通俗，很易懂:)。
?
?
四、監控primary/standby數據庫
??? 本節主要介紹一些監控dg 配置的方式，先給大家提供一個表格(描述不同事件的不同信息監控途徑)：
|
primary數據庫事件
|
primary監控途徑
|
standby監控途徑
|
|
帶有enable|disable thread子句的alterdatabase命令
|
Alert.log
V$THREAD
|
Alert.log
|
|
當前數據庫角色，保護模式，保護級別，switchover狀態，failover快速啟動信息等
|
V$DATABASE
|
V$DATABASE
|
|
Redo log切換
|
Alert.log
V$LOG
V$LOGFILE的status列
|
Alert.log
|
|
重建控制文件
|
Alert log
|
Alert log
|
|
手動執行恢復
|
Alert log
|
Alert log
|
|
表空間狀態修改(read-write/read-only,online/offline)
|
DBA_TABLESPACES
Alert log
|
V$RECOVER_FILE
|
|
創建刪除表空間或數據文件
|
DBA_DATA_FILES
Alert log
|
V$DATAFILE
Alert log
|
|
表空間或數據文件offline
|
V$RECOVER_FILE
Alert log
DBA_TABLESPACES
|
V$RECOVER_FILE
DBA_TABLESPACES
|
|
重命名數據文件
|
V$DATAFILE
Alert log
|
V$DATAFILE
Alert log
|
|
未被日志記錄或不可恢復的操作
|
V$DATAFILE view
V$DATABASE view
|
Alert.log
|
|
恢復的進程
|
V$ARCHIVE_DEST_STATUS
Alert log
|
V$ARCHIVED_LOG
V$LOG_HISTORY
V$MANAGED_STANDBY
Alert log
|
|
Redo傳輸的狀態和進度
|
V$ARCHIVE_DEST_STATUS
V$ARCHIVED_LOG
V$ARCHIVE_DEST
Alert log
|
V$ARCHIVED_LOG
Alert log
|
|
數據文件自動擴展
|
Alert log
|
Alert log
|
|
執行OPEN RESETLOGS或CLEAR UNARCHIVED LOGFILES
|
Alert log
|
Alert log
|
|
修改初始化參數
|
Alert log
|
Alert log
|
?
??? 概括起來主要通過二個方面：
?
???
1、AlerAlertLog
??? 一句話：一定要養成有事沒事定期不定期隨時查看alert.log 的好習慣同時特別注意alert 中的提示通常不經意間會發現它的提示能夠讓你的思路豁然開朗。
?
???
2、動態性能視圖
??? 先也是一句話：做為oracle 自己自覺主動維護的一批虛擬表它的作用非常明顯通過它可以及時獲得當前數據庫狀態及處理進度總之好處多多也需特別關注后面示例也會多處用到大家要擦亮雙眼。
?
??? ● 先來點與恢復進度相關的v$視圖應用示例：
?
?????
A).查看進程的活動狀況---v$managed_standby
??????? 該視圖就是專為顯示standby 數據庫相關進程的當前狀態信息，例如：
??????? SQL> select process,client_process,sequence#,status from v$managed_standby;
??????? PROCESS?? CLIENT_P SEQUENCE#?STATUS
??????? --------- -------- ---------- ------------
??????? ARCH????? ARCH???? 763????????CLOSING
??????? ARCH????? ARCH???? 762??????? CLOSING
??????? MRP0????? N/A????? 764??????? WAIT_FOR_LOG
??????? RFS?????? LGWR???? 764??????? IDLE
??????? RFS?????? N/A????? 0????????? IDLE
???????
PROCESS：顯示進程信息
??????? CLIENT_PROCESS：顯示對應的主數據庫中的進程
??????? SEQUENCE#：顯示歸檔redo 的序列號
??????? STATUS：顯示的進程狀態
??????? 通過上述查詢可以得知primary 開了兩個歸檔進程，使用lgwr 同步傳輸方式與standby 通信，已經接收完763 的日志，正等待764。
?
?????
B).確認redo 應用進度---v$archive_dest_status
??????? 該視圖顯示歸檔文件路徑配置信息及redo 的應用情況等，例如：
??????? SQL> select dest_name,archived_thread#,archived_seq#,applied_thread#,applied_seq#,db_unique_name
?????????? 2 from v$archive_dest_status where status='VALID';
??????? DEST_NAME????????????ARCHIVED_THREAD# ARCHIVED_SEQ# APPLIED_THREAD#APPLIED_SEQ# DB_UNIQUE_
??????? -------------------- ---------------- ------------- --------------- ------------ ----------
??????? LOG_ARCHIVE_DEST_1?? 1????????????????765???????????0???????????????0????????????jsspdg
??????? LOG_ARCHIVE_DEST_2?? 0????????????????0???????????? 0?????????????? 0????????????jssweb
??????? STANDBY_ARCHIVE_DEST 1????????????????764?????????? 1?????????????? 764????????? NONE
?
?????
C).檢查歸檔文件路徑及創建信息---v$archived_log
??????? 該視圖查詢standby 數據庫歸檔文件的一些附加信息，比如文件創建時間啦，創建進程啦，歸檔序號啦，是否被應用啦之類，例如：
??????? SQL> select name,creator,sequence#,applied,completion_time from v$archived_log;
??????? NAME???????????????????????????????????????????????CREATOR SEQUENCE#?APP COMPLETION_TIM
??????? -------------------------------------------------- ------- ---------- --- --------------
??????? E:\ORA10G\ORADATA\JSSPDG\LOG1_750_641301252.ARC????ARCH??? 750????????YES 18-1 月-08
??????? E:\ORA10G\ORADATA\JSSPDG\LOG1_749_641301252.ARC??? ARCH??? 749??????? YES 18-1 月-08
??????? E:\ORA10G\ORADATA\JSSPDG\LOG1_751_641301252.ARC??? ARCH??? 751??????? YES 18-1 月-08
??????? E:\ORA10G\ORADATA\JSSPDG\LOG1_752_641301252.ARC??? ARCH??? 752??????? YES 18-1 月-08
??????? E:\ORA10G\ORADATA\JSSPDG\LOG1_753_641301252.ARC??? ARCH??? 753??????? YES 18-1 月-08
??????? E:\ORA10G\ORADATA\JSSPDG\LOG1_754_641301252.ARC??? ARCH??? 754??????? YES 18-1 月-08
?
?????
D).查詢歸檔歷史---v$log_history
??????? 該視圖查詢standby 庫中所有已被應用的歸檔文件信息(不論該歸檔文件是否還存在)，例如：
??????? SQL> select first_time,first_change#,next_change#,sequence# from v$log_history;
??????? FIRST_TIME????????? FIRST_CHANGE# NEXT_CHANGE# SEQUENCE#
??????? ------------------- ------------- ------------ ----------
??????? 2008-01-03 12:00:51 499709??????? 528572?????? 18
??????? 2008-01-08 09:54:42 528572????????539402?????? 19
??????? 2008-01-08 22:00:06 539402????????547161?????? 20
??????? 2008-01-09 01:05:57 547161????????560393?????? 21
??????? 2008-01-09 10:13:53 560393????????561070?????? 22
?
??? ●再來點與log應用相關的v$視圖應用示例：
?
????? A).查詢當前數據的基本信息---v$database 信息。
??????? 例如，查詢數據庫角色，保護模式，保護級別等：
??????? SQL> selectdatabase_role,db_unique_name,open_mode,protection_mode,protection_level,switchover_status
?????????? 2 from v$database;
??????? DATABASE_ROLE??? DB_UNIQUE_NAME??OPEN_MODE? PROTECTION_MODE????? PROTECTION_LEVEL???? SWITCHOVER_STATUS
??????? ---------------- --------------- ---------- --------------------?-------------------- ------------------
??????? PHYSICAL STANDBY jsspdg??????????MOUNTED????MAXIMUM?AVAILABILITY MAXIMUM AVAILABILITY SESSIONS ACTIVE
?
??????? 再比如，查詢failover 后快速啟動的信息
??????? SQL> select fs_failover_status,fs_failover_current_target,fs_failover_threshold,
?????????? 2 fs_failover_observer_present from v$database;
??????? FS_FAILOVER_STATUS??? FS_FAILOVER_CURRENT_TARGET???? FS_FAILOVER_THRESHOLD FS_FAIL
??????? --------------------- ------------------------------ --------------------- -------
??????? DISABLED?????????????????????????????????????????????0
?
????? B).檢查應用模式(是否啟用了實時應用)---v$archive_dest_status
??????? 查詢v$archive_dest_status 視圖，如果打開了實時應用，則recovery_mode 會顯示為：MANAGEDREAL TIME APPLY，例如：
??????? SQL> select recovery_mode from v$archive_dest_status where dest_id=2;
??????? RECOVERY_MODE
??????? -----------------------
??????? MANAGED REAL TIME APPLY
?
????? C).Data guard 事件---v$dataguard_status
??????? 該視圖顯示那些被自動觸發寫入alert.log 或服務器trace 文件的事件。通常是在你不便訪問到服務器查詢alert.log 時，可以臨時訪問本視圖查看一些與dataguard 相關的信息，例如：
??????? SQL> select message from v$dataguard_status;
??????? MESSAGE
??????? ----------------------------------------------------------------------------
??????? ARC0:Archival started
??????? ARC1:Archival started
??????? ARC0: Becoming the 'no FAL' ARCH
??????? ARC0: Becoming the 'no SRL' ARCH
??????? ARC1: Becoming the heartbeat ARCH
??????? Attempt to start background Managed Standby Recovery process
??????? MRP0: Background Managed Standby Recovery process started
??????? Managed Standby Recovery not using Real Time Apply
??????? Media Recovery Waiting for thread 1 sequence 761
?
?
五、調整物理standbylog應用頻率
?
?? 調整應用頻率說白了就是調整io 讀取能力，所以通常我們可以從以下幾個方面著手：
?
1、設置recover 并行度
??? 在介質恢復或redo 應用期間，都需要讀取重做日志文件，默認都是串行恢復，我們可以在執行recover的時候加上parallel 子句來指定并行度，提高讀取和應用的性能，例如：
??? SQL> alter database recover managed standby database parallel 2 disconnect from session;
??? 推薦parallel 的值是#CPUs*2;
2、加快redo 應用頻繁
??? 設置初始化參數DB_BLOCK_CHECKING=FALSE 能夠提高2 倍左右的應用效率，該參數是驗證數據塊是否有效， 對于standby 禁止驗證基本上還是可以接受的， 另外還有一個關聯初始化參數DB_BLOCK_CHECKSUM，建議該參數在primary 和standby 都設置為true。
?
3、設置PARALLEL_EXECUTION_MESSAGE_SIZE
??? 如果打開了并行恢復，適當提高初始化參數：PARALLEL_EXECUTION_MESSAGE_SIZE 的參數值，比如4096 也能提高大概20%左右的性能，不過需要注意增大這個參數的參數值可能會占用更多內存。
?
4、優化磁盤I/O
??? 在恢復期間最大瓶頸就是I/O 讀寫，要緩解這個瓶頸，使用本地異步I/O 并設置初始化參數DISK_ASYNCH_IO=TRUE 會有所幫助。DISK_ASYNCH_IO 參數控制到數據文件的磁盤I/O 是否異步。某些情況下異步I/O 能降低數據庫文件并行讀取，提高整個恢復時間。
?
?
?
-The End-