Oracle Data Guard延迟的几个可能(r11笔记第69天)

最新推荐文章于 2024-06-14 11:33:40 发布

congbao6525

最新推荐文章于 2024-06-14 11:33:40 发布

阅读量286

点赞数

Oracle Data Guard中很可能出现延迟的情况，而数据一旦出现延迟就意味着丢数据。退一步来说丢数据总比数据乱了好，但是回过头来，能不丢数据但是丢了，这就有些说不过去了。

因为预防人为误操作等，可能有些环境中会特意设置一个延迟，基本就是下面的设置方法：

方法1：

alter database recover managed standby database delay 120 disconnect from session;方法2：

alter system set log_archive_dest_3='service=db3 lgwr async delay=120 valid_for=(all_logfiles,all_roles)
db_unique_name=db3'; 我们这里所说的延迟是计划外的延迟，比如一个ADG的环境，案例应该是实时同步，但是却有数据同步出现延迟的情况。我自己碰到一些，还帮网友处理过几次。

大体来说，10g和11g中的数据同步延迟场景还不大一样。

在10g中如果一主两备的架构下，如果备1是在read only状态，则整个数据同步还是会延迟，需要手工切换日志才能增量同步。

在11g中，倒不存在这样的限制了，因为是Active Data Guard的方式，所以可以在read only的基础上接收应用增量数据变化。但是延迟的问题依旧可能存在。

我一个例子来说明,简单来说，如何判断一个Data Guard是Active Data Guard呢，可以用一个SQL语句来判定。

10:27:21 SQL>select current_scn from v$database;
CURRENT_SCN
      232913508003
10:27:22 SQL> /
       CURRENT_SCN
      232913508005随着时间的变化，SCN会发生变化，这和10g是一个鲜明的对比。
    而如果Data Guard环境出现延迟，如果通过DG Broker来查看，基本就是下面的显示情况。

DGMGRL> show database verbose sol;
Role:            PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag:   3 minutes 37 seconds
Apply Lag:       3 minutes 37 seconds
Real Time Query: ON   同时在备库的alert日志中查看却似乎看不出什么特别之处。我碰到一个环境，数据延迟时好时坏，很不稳定，听起来很棘手，我们来简单看看。

日志如下：

RFS[1]: Opened log for thread 1 sequence 476185 dbid 1210367666 branch 622336050
Wed Feb 08 11:55:23 2017
Media Recovery Log /U01/app/oracle/oradata/sol/arch/SOL/archivelog/2017_02_08/o1_mf_1_476184_d9o2rzdc_.arc
Media Recovery Waiting for thread 1 sequence 476185 (in transit) 出现这种情况，基本可以断定是差一个归档。

我们看看主备库的日志文件的情况。
查看备库的standby log情况：

SQL> select group#,bytes from v$standby_log;
    GROUP#      BYTES
---------- ----------
        21 524288000
        22 524288000
。。。

主库的online log情况：

SQL> select group#,bytes,status from v$log
    GROUP#      BYTES STATUS
---------- ---------- ----------------
         1 209715200 INACTIVE
         2 209715200 INACTIVE
         3 209715200 INACTIVE
         4 209715200 INACTIVE
         5 209715200 INACTIVE
         6 209715200 INACTIVE
         7 524288000 INACTIVE
         8 629145600 INACTIVE
         9 1073741824 CURRENT
        10 1073741824 INACTIVE    如果到了这里，想必就会清晰很多了，主库中的online log大小不一，看起来是经过了多次设置，估计最开始设置为200M，感觉有些小了，后面改进，设置成了500M,估计还是差强人意，就改成了1G。其实这个日志是可以做调整设置的，而不是一锤子买卖，肯定能修改。
如果出现延迟，很可能就是和日志的大小情况有关，主库的小，备库的大，暂时不会出现问题，如果主库的大，备库的小，那就有问题，或者备库没有standby log，也是如此。

一个较为正常的备库的alert日志情况如下，假设归档设置是默认的情况下。会有下面的额外两行尤其需要关注，你可以看到standby log被引用。

RFS[1]: Selected log 23 for thread 1 sequence 476186 dbid 1210367666 branch 622336050
Media Recovery Log /U01/app/oracle/oradata/sol/arch/SOL/archivelog/2017_02_08/o1_mf_1_476185_d9o5ocmt_.arc
Wed Feb 08 14:14:06 2017
Media Recovery Waiting for thread 1 sequence 476186 (in transit)
Recovery of Online Redo Log: Thread 1 Group 23 Seq 476186 Reading mem 0
Mem# 0: /U01/app/oracle/oradata/sol/arch/SOL/onlinelog/o1_mf_23_d9ofo81j_.log 所以说，任何看起来复杂的问题的原因都会很简单，明确了问题，解决起来就会得心应手。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23718752/viewspace-2133246/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/23718752/viewspace-2133246/