DataGuard之Apply Services(redo應用和SQL應用)
應用服務 Apply Services
根據oracle官方文檔整理
http://docs.oracle.com/cd/E11882_01/server.112/e25608/log_apply.htm#i1027052
Apply Services在從庫上自動應用redo,實現Primary和Standby的數據同步。
1.Apply Services的兩種方式:
Redo Apply(物理standby)
SQL Apply(邏輯standby)
2.Apply Services 配置選項
<1>實時應用redo
實時應用要求:
standby庫是歸檔模式
standby庫建有standby redo log(用來接收Primary傳來的redo條目)
如果已經打開了實時應用特性,那麽standby庫上的apply service能夠應用它收到的redo條目,而不用等待standby庫上的standby redo log歸檔,然後才能應用redo。
這種方式下,switchover和failover都能夠快速完成,因為在switchover和failover之前,所有standby redo log都已經被應用了(不用實時方式的話,
切換之前要把所有standby redo log的歸檔都應用一遍,很耗時間)。
打開實時應用redo特性:
物理standby: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;
邏輯standby:ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
聯機文檔中的圖Figure 7-1很清晰的解釋了實時應用。
http://docs.oracle.com/cd/E11882_01/server.112/e25608/log_apply.htm#i1023371
<2>延時應用歸檔日誌
在某些情景中,我們需要standby庫延時應用已經歸檔的日誌,也就是standby庫已經收到了主庫傳來的redo log,並且已經在standby庫歸檔,但暫時不應用歸檔日誌。
通過設定延遲時間(以分鐘為單位),standby庫暫時避免了由於primary庫誤操作或者損壞造成的數據丟失。
為什麽用這種方式:
實際工作中可能存在這種情況,primary庫誤操作刪除了數據。如果standby庫是實時應用日誌模式,standby庫的相應數據也會被刪除。
而用延時應用歸檔日誌模式,就能避免這種情況發生。Primary庫誤刪數據了,standby庫在設定的延時時間內不會應用歸檔日誌,肯定不會刪除數據。
利用延時時間,完全可以找回誤刪除數據。
設定延遲時間:
在primary和standby庫的參數文件中的LOG_ARCHIVE_DEST_n參數加上DELAY選項,如果只指定了DELAY參數,但是沒有指定具體的值,默認是30分鐘。
如果已經啟用了實時日誌應用,delay這個參數會被忽略,因此不糊iqidong實時延遲日誌應用。
如果想讓standby庫延遲360分鐘應用日誌,那麽就在primary中設置延遲參數。
如:
--延遲360分鐘
SQL〉alter system set log_archive_dest_2=‘SERVICE=standby LGWR SYNC AFFIRM DELAY=360 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby‘;
--如果是全新的庫,也可以在參數文件中直接設置
log_archive_dest_2=‘service=standby LGWR SYNC AFFIRM DELAY=360 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby‘
取消延遲時間設定:
物理standby:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;
邏輯standby:
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY;
3.物理standby庫的redo日誌應用
默認情況,日誌應用使用的是歸檔日誌。但是,物理standby用實時日誌應用時,RFS進程把primary庫的redo條目寫入到standby庫的standby redo log中;
這時日誌應用進程可以直接讀取standby redo log進行日誌應用。
<1>開始日誌應用(starting redo apply)
物理standby庫上開始日誌應用,要確保物理standby庫處於mount狀態(??open狀態也可以吧??)。
使用ALTER DATABASE RECOVER MANAGED STANDBY DATABASE語句開始日誌應用。
在前臺開始日誌應用:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE; --這種方式執行過程中,在命令行做什麽操作都無用,直到其他session把該session殺掉。
在後臺開始日誌應用:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
實時日誌應用:加上using current logfile
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE; --前臺
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; --後臺
<2>停止日誌應用
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
<3>物理standby庫監控日誌應用情況
--顯示保護模式、保護級別、數據庫角色、切換狀態
SQL> SELECT PROTECTION_MODE,PROTECTION_LEVEL,DATABASE_ROLE ROLE, SWITCHOVER_STATUS FROM V$DATABASE;
PROTECTION_MODE PROTECTION_LEVEL ROLE SWITCHOVER_STATUS
-------------------- -------------------- ---------------- --------------------
MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE PHYSICAL STANDBY NOT ALLOWED
--fast-start failover狀態
SQL> SELECT FS_FAILOVER_STATUS "FSFO STATUS",FS_FAILOVER_CURRENT_TARGET TARGET,FS_FAILOVER_THRESHOLD THRESHOLD,
FS_FAILOVER_OBSERVER_PRESENT "OBSERVER PRESENT" FROM V$DATABASE;
FSFO STATUS TARGET THRESHOLD OBSERVE
---------------------- ------------------------------ ---------- -------
DISABLED 0
--物理standby庫中日誌應用、日誌傳輸狀態
SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#,BLOCK#,BLOCKS,PID FROM V$MANAGED_STANDBY;
PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS PID
--------- ------------ ---------- ---------- ---------- ---------- ----------
ARCH CLOSING 1 34 1 3 9742
ARCH CONNECTED 0 0 0 0 9746
ARCH CLOSING 1 30 1 3 9750
ARCH CLOSING 1 31 1 31 9754
ARCH CLOSING 1 26 1 77 9758
ARCH CLOSING 1 32 1 11 9762
ARCH CLOSING 1 27 1 1 9766
ARCH CLOSING 1 33 1 2 9770
RFS IDLE 0 0 0 0 10986
RFS IDLE 1 37 688 1 9797
RFS IDLE 0 0 0 0 9801
RFS IDLE 0 0 0 0 9805
MRP0 APPLYING_LOG 1 37 688 1024000 10916
RFS IDLE 0 0 0 0 10995
RFS IDLE 0 0 0 0 10999
--主要看RFS和MRP0
--RFS(Remote File Server)進程:接收primary數據庫的redo,保存在standby redo log(arch模式不寫standby,直接保存歸檔)
狀態值有:
WRITING:進程活躍,正在把redo寫到歸檔日誌中
IDLE:空閑,沒有日誌同步
RECEIVING:收聽網絡通信
OPENING:正在打開歸檔日誌
--MRP0(Manager Recover Process):負責日誌應用個,只要啟用到日誌應用才會有這個服務。在物理standby中是MRP,在邏輯standby中是LSP。
狀態值:
WAIT_FOR_LOG:等待日誌完成
APPLYING_LOG:正在應用日誌
--物理standby收到的primary庫傳輸過來的歸檔
SQL> SELECT THREAD#, SEQUENCE#,FIRST_CHANGE#,NEXT_CHANGE# FROM V$ARCHIVED_LOG;
--datagruad信息
SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS;
MESSAGE
--------------------------------------------------------------------------------
LNS: Beginning to archive log 1 thread 1 sequence 37
LNS: Completed archiving log 1 thread 1 sequence 37
ARC2: Beginning to archive thread 1 sequence 37 (1051112-1053910)
ARC2: Completed archiving thread 1 sequence 37 (1051112-1053910)
LNS: Standby redo logfile selected for thread 1 sequence 38 for destination LOG_
ARCHIVE_DEST_2
--在備庫中查看存檔目錄是否正常
SQL> select DEST_NAME,STATUS,ERROR,TARGET,PROCESS from v$archive_dest where rownum<4;
--裂縫:standby庫和primary庫差多少redo文件
SELECT * FROM V$ARCHIVE_GAP;
4.邏輯standby庫的redo日誌應用
SQL應用把歸檔日誌或者standby redo log通過logmnr轉換成SQL語句,然後在邏輯standby數據上執行SQL。SQL應用時standby庫處於open狀態,
這時在standby庫也可以做其他操作,如報表、查詢等。
<1>開始SQL應用
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; --邏輯standby數據庫實時SQL應用
<2>停止SQL應用
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
<3>監控SQL應用情況
--SQL應用過程中發生的事件。默認這個視圖最多記錄10000個事件。可以通過DBMS_LOGSTDBY.APPLY_SET() 修改。
SQL> ALTER SESSION SET NLS_DATE_FORMAT = ‘DD-MON-YY HH24:MI:SS‘;
SQL> COLUMN STATUS FORMAT A60
SQL> SELECT EVENT_TIME, STATUS, EVENT FROM DBA_LOGSTDBY_EVENTS ORDER BY EVENT_TIMESTAMP, COMMIT_SCN, CURRENT_SCN;
--SQL應用過程中,歸檔日誌的動態信息
SQL> COLUMN DICT_BEGIN FORMAT A10;
SQL> SET NUMF 99999999;
SQL> SELECT FILE_NAME, SEQUENCE# AS SEQ#, FIRST_CHANGE# AS F_SCN#,NEXT_CHANGE# AS N_SCN#, TIMESTAMP,DICT_BEGIN AS BEG, DICT_END AS END,
THREAD# AS THR#, APPLIED FROM DBA_LOGSTDBY_LOG ORDER BY SEQUENCE#;
FILE_NAME SEQ# F_SCN N_SCN TIMESTAM BEG END THR# APPLIED
------------------------- ---- ------- ------- -------- --- --- --- ---------
/oracle/dbs/hq_nyc_2.log 2 101579 101588 11:02:58 NO NO 1 YES
/oracle/dbs/hq_nyc_3.log 3 101588 142065 11:02:02 NO NO 1 YES
/oracle/dbs/hq_nyc_4.log 4 142065 142307 11:02:10 NO NO 1 YES
/oracle/dbs/hq_nyc_5.log 5 142307 142739 11:02:48 YES YES 1 YES
/oracle/dbs/hq_nyc_6.log 6 142739 143973 12:02:10 NO NO 1 YES
/oracle/dbs/hq_nyc_7.log 7 143973 144042 01:02:11 NO NO 1 YES
/oracle/dbs/hq_nyc_8.log 8 144042 144051 01:02:01 NO NO 1 YES
/oracle/dbs/hq_nyc_9.log 9 144051 144054 01:02:16 NO NO 1 YES
/oracle/dbs/hq_nyc_10.log 10 144054 144057 01:02:21 NO NO 1 YES
/oracle/dbs/hq_nyc_11.log 11 144057 144060 01:02:26 NO NO 1 CURRENT
/oracle/dbs/hq_nyc_12.log 12 144060 144089 01:02:30 NO NO 1 CURRENT
/oracle/dbs/hq_nyc_13.log 13 144089 144147 01:02:41 NO NO 1 NO
--???
SQL> COL NAME FORMAT A20
SQL> COL VALUE FORMAT A12
SQL> COL UNIT FORMAT A30
SQL> SELECT NAME, VALUE, UNIT FROM V$DATAGUARD_STATS;
NAME VALUE UNIT
-------------------- ------------ ------------------------------
apply finish time +00 00:00:00 day(2) to second(1) interval
apply lag +00 00:00:00 day(2) to second(0) interval
transport lag +00 00:00:00 day(2) to second(0) interval
本文轉自:http://blog.chinaunix.net/uid-26844646-id-5602383.html
DataGuard之Apply Services(redo應用和SQL應用)