应用服务 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