ITPub博客

首页 > 数据库 > Oracle > 网络不佳 FRA快速恢复区上限 导致的Gap问题

网络不佳 FRA快速恢复区上限 导致的Gap问题

原创 Oracle 作者:steven_hua 时间:2016-09-30 09:50:01 0 删除 编辑
网络不佳 FRA快速恢复区上限 导致的Gap问题

Data Guard 配置情况:
1.LGWR ASYNC  
2.主库归档存放FRA(快速恢复区)USE_DB_RECOVERY_FILE_DEST
3.主备库存在不同的机房,时常有网络闪断的情况
4.FRA(快速恢复区)上限 200G
5.rman备份策略:保持28天的备份

*.LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=tdwlds'
*.LOG_ARCHIVE_DEST_2='SERVICE=tdwlds1 optional LGWR ASYNC affirm VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=tdwlds1'


备库,有gap,提示CONTROL_FILE_RECORD_KEEP_TIME 记录保持时间设置要大一点。
(根据日志同步的规则,
  LGWR ASYNC:主库一段产生Redo日志后,LGWR把日志同时提交给日志文件和本地LNS进程,
  LGWR进程只需成功写入日志文件就可以,不必等待LNSn进程的网络传送成功
  LNSn进程异步地把日志内容发送到StandbyDatabase。多个LNSn进程可以并发发送。
  因为LGWR进程不会等待LNSn进程的响应结果,所以配置LGWR ASYNC方式时不需要NET_TIMEOUT参数
  ^如果网络超时,LNSn就会发送失败,此时备库会每隔一段时间向主库索要需要的归档日志,而主库因为 快速恢复区FRA 80%上限,而删除了归档日志,就产生了Gap。
 
  LGWR SYNC:在网络不畅时极容易产生GAP
  )
Wed Sep 28 10:20:38 2016
Media Recovery Waiting for thread 1 sequence 15805
Fetching gap sequence in thread 1, gap sequence 15805-15805
Wed Sep 28 10:22:28 2016
FAL[client]: Failed to request gap sequence
 GAP - thread 1 sequence 15805-15805
 DBID 3703021612 branch 878254572
FAL[client]: All defined FAL servers have been attempted.
------------------------------------------------------------
Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization
parameter is defined to a value that's sufficiently large
enough to maintain adequate log switch information to resolve
archivelog gaps.
------------------------------------------------------------


SQL> select * from v$archive_gap;

   THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
---------- ------------- --------------
         1         15805          15805
        
        
主库,刚产生的归档日志也会自动删除了, 由于网络原因,有些甚至还没同步到备库
Wed Sep 28 10:40:40 2016
Deleted Oracle managed file /home/oracle/orahomes/fast_recovery_area/TDWLDS/archivelog/2016_09_28/o1_mf_1_15938_cyo9o7h8_.arc
Deleted Oracle managed file /home/oracle/orahomes/fast_recovery_area/TDWLDS/archivelog/2016_09_28/o1_mf_1_15937_cyo7ddbd_.arc
Deleted Oracle managed file /home/oracle/orahomes/fast_recovery_area/TDWLDS/archivelog/2016_09_28/o1_mf_1_15936_cyo6h0pr_.arc
Wed Sep 28 10:42:54 2016
Deleted Oracle managed file /home/oracle/orahomes/fast_recovery_area/TDWLDS/archivelog/2016_09_28/o1_mf_1_15795_cypcf85g_.arc
Wed Sep 28 10:45:36 2016
Deleted Oracle managed file /home/oracle/orahomes/fast_recovery_area/TDWLDS/archivelog/2016_09_28/o1_mf_1_15801_cypckgnh_.arc
Deleted Oracle managed file /home/oracle/orahomes/fast_recovery_area/TDWLDS/archivelog/2016_09_28/o1_mf_1_15935_cyo631n1_.arc


SQL> select * from V$FLASH_RECOVERY_AREA_USAGE;

FILE_TYPE            PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
-------------------- ------------------ ------------------------- ---------------
CONTROL FILE                          0                         0               0
REDO LOG                              0                         0               0
ARCHIVED LOG                      30.34                       .18            3880
BACKUP PIECE                          0                         0               0
IMAGE COPY                            0                         0               0
FLASHBACK LOG                         0                         0               0
FOREIGN ARCHIVED LOG                  0                         0               0

7 rows selected.

SQL> select name,
           space_limit/1024/1024/1024 space_limit,
           space_used/1024/1024/1024 space_used,
           round(100*space_used/space_limit,2) "Use%",
           number_of_files
    from v$recovery_file_dest;

NAME                                          SPACE_LIMIT SPACE_USED       Use% NUMBER_OF_FILES
-------------------------------------------------- ----------- ---------- ---------- ---------------
/home/oracle/orahomes/fast_recovery_area                   200  164.53196      82.27             636


FRA(快速恢复区)的空间使用率基本上在80%左右。alert日志也有相应的删除较早的归档日志的信息

参考:http://www.laoxiong.net/oracle-11g-data-guard-archived-log-managemen.html



配置调整如下
1.同步策略变更 LGWR ASYNC compression
*.LOG_ARCHIVE_DEST_2='SERVICE=tdwlds1 optional LGWR ASYNC affirm VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=tdwlds1 compression=enable'

2.Rman策略变更(根据备份集大小计算得出)
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 15 days;
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;

第二天查看:
NAME                                               SPACE_LIMIT SPACE_USED       Use% NUMBER_OF_FILES
-------------------------------------------------- ----------- ---------- ---------- ---------------
/home/oracle/orahomes/fast_recovery_area                   200 66.1604648      33.08             249




Gap的处理:
主库restore 缺失的归档日志,备库会自动获取并应用
RMAN> restore archivelog sequence between 15805 and 15805;

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

请登录后发表评论 登录
全部评论

注册时间:2008-05-16

  • 博文量
    117
  • 访问量
    190322