解析一下DataGuard环境里出现archivelog gap的两个场景

最新推荐文章于 2022-04-20 05:22:24 发布
最新推荐文章于 2022-04-20 05:22:24 发布
阅读量359 收藏
点赞数
文章标签： 数据库

<<< Redo Transport阶段出现archivelog gap >>>
测试环境描述：
prmy : tstdb1
stdby : tstdb1_stdby1
DG工作在MAXIMUM PERFORMANCE模式下

测试过程描述：tstdb1_stdby1 shutdown->在tstdb1上switch logfile若干次->tstdb1_stdby1重新启动->观察tstdb1上生成的archivelog已经传送到了tstdb1_stdby1

###DG工作在MAXIMUM PERFORMANCE模式
---tstdb1:
SQL> select db_unique_name,database_role,protection_mode,protection_level,open_mode,SWITCHOVER_STATUS from v$database;


DB_UNIQUE_NAME  DATABASE_ROLE    PROTECTION_MODE      PROTECTION_LEVEL     OPEN_MODE            SWITCHOVER_STATUS
--------------- ---------------- -------------------- -------------------- -------------------- --------------------
tstdb1          PRIMARY          MAXIMUM PERFORMANCE  MAXIMUM PERFORMANCE  READ WRITE           SESSIONS ACTIVE


---tstdb1_stdby1:
SQL> select db_unique_name,database_role,protection_mode,protection_level,open_mode,SWITCHOVER_STATUS from v$database;


DB_UNIQUE_NAME  DATABASE_ROLE    PROTECTION_MODE      PROTECTION_LEVEL     OPEN_MODE            SWITCHOVER_STATUS
--------------- ---------------- -------------------- -------------------- -------------------- --------------------
tstdb1_stdby1   PHYSICAL STANDBY MAXIMUM PERFORMANCE  MAXIMUM PERFORMANCE  READ ONLY WITH APPLY NOT ALLOWED


###关闭tstdb1_stdby1:
---关闭前记录一下当前最大的archivelog sequence#
SQL> select max(sequence#) from v$archived_log where RESETLOGS_CHANGE#=(select RESETLOGS_CHANGE# from v$database_incarnation where status='CURRENT');


MAX(SEQUENCE#)
--------------
            93
            
alter database recover managed standby database cancel;
shutdown abort


###tstdb1执行switch logfile的操作
SYS@tstdb1-SQL> archive log list
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     91
Next log sequence to archive   94
Current log sequence           94


alter system switch logfile;
alter system switch logfile;
alter system switch logfile;


SYS@tstdb1-SQL> archive log list
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     91
Next log sequence to archive   97
Current log sequence           97


其中seq#94~96的三个archivelog将在tstdb1_stdby1启动后自动传输到tstdb1_stdby1


###tstdb1_stdby1:重新启动后，检查94~96的日志已经接收过来了
startup 


SQL> select *from v$archive_gap;   <---v$archive_gap内容是空的


no rows selected


****等待reopen所指定的时间(默认300s)后，接收到了tstdb1传来的archivelog
col name format a90
set linesize 180
SQL> select sequence#,name,fal,creator,registrar from v$archived_log where sequence#>=93 and RESETLOGS_CHANGE#=(select RESETLOGS_CHANGE# from v$database_incarnation where status='CURRENT') order by sequence#;


 SEQUENCE# NAME                                                                                       FAL CREATOR REGISTR
---------- ------------------------------------------------------------------------------------------ --- ------- -------
        93 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_93_1mLXovJhM_.arc     NO  ARCH    RFS
        94 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_94_1mLZMUNCf_.arc     NO  ARCH    RFS    <---FAL=NO，是因为tstdb1_stdby1 shutdown之前seq# 94已经在tstdb1上作为current redolog了
        95 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_95_1mLZMSt-v_.arc     YES ARCH    RFS       <---FAL=YES
        96 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_96_1mLZMS9c8_.arc     YES ARCH    RFS      <---FAL=YES
        97 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_97_1mLZMTSce_.arc     NO  ARCH    RFS


上述94~96三个archivelog的传输是由ARCn[primary侧]与RFSn[standby侧]的这两个进程间通信完成的；这种archive gap主要发生在primary与standby间的网络故障或者standby实例宕机，导致primary产生的redolog无法在第一时间传送到standby主机，等到网络或者standby主机恢复后通过RFSn、ARCn进程将redo补传到standby主机


<<< Redo Apply阶段出现archivelog gap >>>
测试环境：
primary: tstdb1
stdby: tstdb1_stdby1
---tstdb1_stdby1：把tstdb1_stdby1上的MRP进程停掉
alter database recover managed standby database cancel;


---tstdb1: 连续Switch几次logfile
alter system switch logfile;   <---执行若干次


---tstdb1_stdby1: 因为MRP停止所以看到seq# 94开始的archivelog都没有apply
SQL> select sequence#,name,fal,creator,registrar,completion_time,applied from v$archived_log where sequence#>=93 and RESETLOGS_CHANGE#=(select RESETLOGS_CHANGE# from v$database_incarnation where status='CURRENT') order by sequence#;


 SEQUENCE# NAME                                                                                       FAL CREATOR REGISTR COMPLETION_TIME   APPLIED
---------- ------------------------------------------------------------------------------------------ --- ------- ------- ----------------- ---------
        93 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_93_1mLXovJhM_.arc     NO  ARCH    RFS     20150928 15:03:25 YES
        94 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_94_1mLZMUNCf_.arc     NO  ARCH    RFS     20150928 15:31:16 NO
        95 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_95_1mLZMSt-v_.arc     YES ARCH    RFS     20150928 15:31:15 NO
        96 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_96_1mLZMS9c8_.arc     YES ARCH    RFS     20150928 15:31:15 NO
        97 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_97_1mLZMTSce_.arc     NO  ARCH    RFS     20150928 15:31:16 NO
        98 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_98_1mLaMwijv_.arc     NO  ARCH    RFS     20150928 15:49:17 NO
        99 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_99_1mLaMvX29_.arc     YES ARCH    RFS     20150928 15:49:17 NO
       100 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_100_1mLaMutXu_.arc    YES ARCH    RFS     20150928 15:49:16 NO
       101 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_101_1mLaMvZmx_.arc    YES ARCH    RFS     20150928 15:49:17 NO
       102 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_102_1mLaMwlA9_.arc    YES ARCH    RFS     20150928 15:49:17 NO
       103 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_103_1mLaMwux8_.arc    YES ARCH    RFS     20150928 15:49:17 NO
       104 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_104_1mLaMwzpf_.arc    YES ARCH    RFS     20150928 15:49:17 NO
       105 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_105_1mLaN0VvY_.arc    NO  ARCH    RFS     20150928 15:49:18 NO
       106 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_106_1mLaN9x5D_.arc    NO  ARCH    RFS     20150928 15:49:21 NO
       107 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_107_1mLa-Hquy_.arc    NO  ARCH    RFS     20150928 16:00:17 NO
       108 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_108_1mLa-HQ0E_.arc    YES ARCH    RFS     20150928 16:00:17 NO
       109 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_109_1mLa-HRGz_.arc    YES ARCH    RFS     20150928 16:00:17 NO
       110 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_110_1mLapYURG_.arc    YES ARCH    RFS     20150928 15:57:17 NO
       111 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_111_1mLapednu_.arc    NO  ARCH    RFS     20150928 15:57:19 NO
       112 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_112_1mLapmLM__.arc    NO  ARCH    RFS     20150928 15:57:21 NO
       113 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_113_1mLatCu7l_.arc    NO  ARCH    RFS     20150928 15:58:19 NO


21 rows selected.


---tstdb1_stdby1: 模拟archivelog gap的场景，我们故意将seq# 97~99，seq# 102~104共六个archivelog挪走
mv /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_97_1mLZMTSce_.arc /oradata06/
mv /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_98_1mLaMwijv_.arc /oradata06/
mv /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_99_1mLaMvX29_.arc /oradata06/


mv /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_102_1mLaMwlA9_.arc /oradata06/
mv /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_103_1mLaMwux8_.arc /oradata06/
mv /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_104_1mLaMwzpf_.arc /oradata06/


---tstdb1：将seq# 102~104三个archivelog也挪走
mv /oradata06/fra/TSTDB1/archivelog/2015_09_28/o1_mf_1_102_1mLZd-S_d_.arc /oradata06/
mv /oradata06/fra/TSTDB1/archivelog/2015_09_28/o1_mf_1_103_1mLZd_sEl_.arc  /oradata06/
mv /oradata06/fra/TSTDB1/archivelog/2015_09_28/o1_mf_1_104_1mLZe1E7j_.arc  /oradata06/


---tstdb1: fal_*参数的设置为空：
show parameter fal_


NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
fal_client                           string
fal_server                           string


---tstdb1_stdby1: fal_*参数的设置也为空：
show parameter fal_


NAME                                 TYPE       VALUE
------------------------------------ ---------- ------------------------------
fal_client                           string
fal_server                           string


---tstdb1_stdby1：重新开启managed recovery
alter database recover managed standby database using current logfile disconnect;


***tstdb1_stdby1 alert.log显示:
Mon Sep 28 16:19:09 2015
alter database recover managed standby database using current logfile disconnect
Attempt to start background Managed Standby Recovery process (tstdb1_stdby1)
Mon Sep 28 16:19:09 2015
MRP0 started with pid=31, OS id=2752792 
MRP0: Background Managed Standby Recovery process started (tstdb1_stdby1)
 started logmerger process
Mon Sep 28 16:19:14 2015
Managed Standby Recovery starting Real Time Apply
Parallel Media Recovery started with 16 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Media Recovery Log /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_94_1mLZMUNCf_.arc
Media Recovery Log /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_95_1mLZMSt-v_.arc
Media Recovery Log /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_96_1mLZMS9c8_.arc
Media Recovery Log /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_97_1mLZMTSce_.arc
Error opening /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_97_1mLZMTSce_.arc      <---seq# 97无法open
Attempting refetch
Media Recovery Waiting for thread 1 sequence 97
Fetching gap sequence in thread 1, gap sequence 97-97
FAL[client]: Error fetching gap sequence, no FAL server specified                                                            <----fal_server没有定义找不到fal_server而报错，但从接下来的日志来看seq# 97还是能成功传过来
Completed: alter database recover managed standby database using current logfile disconnect
Mon Sep 28 16:19:18 2015
RFS[2]: Allowing overwrite of partial archivelog for thread 1 sequence 97
RFS[2]: Opened log for thread 1 sequence 97 dbid 2051793563 branch 891526089
Archived Log entry 326 added for thread 1 sequence 97 rlc 891526089 ID 0x7ab78c1e dest 2:                 <--- seq# 97注册到controlfile
Media Recovery Log /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_97_1mLc2IJRe_.arc         <--- applying seq# 97
Media Recovery Log /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_98_1mLaMwijv_.arc
Error opening /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_98_1mLaMwijv_.arc
Attempting refetch
Media Recovery Waiting for thread 1 sequence 98
Fetching gap sequence in thread 1, gap sequence 98-98
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:19:29 2015
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:19:39 2015
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:19:49 2015
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:19:59 2015
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:20:09 2015
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:20:18 2015
RFS[2]: Allowing overwrite of partial archivelog for thread 1 sequence 98
RFS[2]: Opened log for thread 1 sequence 98 dbid 2051793563 branch 891526089
Archived Log entry 327 added for thread 1 sequence 98 rlc 891526089 ID 0x7ab78c1e dest 2:                              <--- seq# 98注册到controlfile
Mon Sep 28 16:20:19 2015
Media Recovery Log /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_98_1mLc5tSbd_.arc     <--- applying seq# 98
Media Recovery Log /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_99_1mLaMvX29_.arc
Error opening /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_99_1mLaMvX29_.arc
Attempting refetch
Media Recovery Waiting for thread 1 sequence 99
Fetching gap sequence in thread 1, gap sequence 99-99
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:20:30 2015
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:20:40 2015
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:20:50 2015
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:21:00 2015
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:21:10 2015
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:21:18 2015
RFS[2]: Allowing overwrite of partial archivelog for thread 1 sequence 99
RFS[2]: Opened log for thread 1 sequence 99 dbid 2051793563 branch 891526089
Archived Log entry 328 added for thread 1 sequence 99 rlc 891526089 ID 0x7ab78c1e dest 2:
Media Recovery Log /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_99_1mLc9Sctz_.arc
Media Recovery Log /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_100_1mLaMutXu_.arc
Media Recovery Log /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_101_1mLaMvZmx_.arc
Media Recovery Log /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_102_1mLaMwlA9_.arc
Error opening /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_102_1mLaMwlA9_.arc
Attempting refetch
Media Recovery Waiting for thread 1 sequence 102                             
Fetching gap sequence in thread 1, gap sequence 102-102                         <---因为seq# 102~104在primary上也已经挪走了所以无法get过来
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:21:29 2015
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:21:39 2015
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:21:49 2015
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:21:59 2015
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:22:09 2015
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:22:19 2015
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:22:29 2015
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:22:39 2015
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:22:49 2015
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:22:59 2015
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:23:09 2015
FAL[client]: Failed to request gap sequence
 GAP - thread 1 sequence 102-102
 DBID 2051793563 branch 891526089
FAL[client]: All defined FAL servers have been attempted.
------------------------------------------------------------
Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization                <----表眀resolve archivelog gap要依赖于v$archived_log;
parameter is defined to a value that's sufficiently large 
enough to maintain adequate log switch information to resolve
archivelog gaps.
------------------------------------------------------------


---tstdb1_stdby1: 查询v$archived_log，发现seq#97~99各有两条记录，一条是APPLIED=YES，一条是APPLIED=NO
SQL>  select sequence#,name,fal,creator,registrar,completion_time,applied from v$archived_log where sequence#>=93 and RESETLOGS_CHANGE#=(select RESETLOGS_CHANGE# from v$database_incarnation where status='CURRENT') order by sequence#;


 SEQUENCE# NAME                                                                                       FAL CREATOR REGISTR COMPLETION_TIME   APPLIED
---------- ------------------------------------------------------------------------------------------ --- ------- ------- ----------------- ---------
        93 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_93_1mLXovJhM_.arc     NO  ARCH    RFS     20150928 15:03:25 YES
        94 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_94_1mLZMUNCf_.arc     NO  ARCH    RFS     20150928 15:31:16 YES
        95 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_95_1mLZMSt-v_.arc     YES ARCH    RFS     20150928 15:31:15 YES
        96 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_96_1mLZMS9c8_.arc     YES ARCH    RFS     20150928 15:31:15 YES
        97 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_97_1mLZMTSce_.arc     NO  ARCH    RFS     20150928 15:31:16 NO
        97 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_97_1mLc2IJRe_.arc     YES ARCH    RFS     20150928 16:19:18 YES
        98 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_98_1mLc5tSbd_.arc     YES ARCH    RFS     20150928 16:20:18 YES
        98 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_98_1mLaMwijv_.arc     NO  ARCH    RFS     20150928 15:49:17 NO
        99 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_99_1mLc9Sctz_.arc     YES ARCH    RFS     20150928 16:21:18 YES
        99 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_99_1mLaMvX29_.arc     YES ARCH    RFS     20150928 15:49:17 NO
       100 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_100_1mLaMutXu_.arc    YES ARCH    RFS     20150928 15:49:16 YES
       101 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_101_1mLaMvZmx_.arc    YES ARCH    RFS     20150928 15:49:17 YES
       102 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_102_1mLaMwlA9_.arc    YES ARCH    RFS     20150928 15:49:17 NO
       103 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_103_1mLaMwux8_.arc    YES ARCH    RFS     20150928 15:49:17 NO
       104 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_104_1mLaMwzpf_.arc    YES ARCH    RFS     20150928 15:49:17 NO
       105 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_105_1mLaN0VvY_.arc    NO  ARCH    RFS     20150928 15:49:18 NO
       106 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_106_1mLaN9x5D_.arc    NO  ARCH    RFS     20150928 15:49:21 NO
       107 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_107_1mLa-Hquy_.arc    NO  ARCH    RFS     20150928 16:00:17 NO
       108 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_108_1mLa-HQ0E_.arc    YES ARCH    RFS     20150928 16:00:17 NO
       109 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_109_1mLa-HRGz_.arc    YES ARCH    RFS     20150928 16:00:17 NO
       110 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_110_1mLapYURG_.arc    YES ARCH    RFS     20150928 15:57:17 NO
       111 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_111_1mLapednu_.arc    NO  ARCH    RFS     20150928 15:57:19 NO
       112 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_112_1mLapmLM__.arc    NO  ARCH    RFS     20150928 15:57:21 NO
       113 /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_113_1mLatCu7l_.arc    NO  ARCH    RFS     20150928 15:58:19 NO


---tstdb1：将seq#102~104恢复至原来的目录：
mv /oradata06/o1_mf_1_102_1mLZd-S_d_.arc /oradata06/fra/TSTDB1/archivelog/2015_09_28/  
mv /oradata06/o1_mf_1_103_1mLZd_sEl_.arc /oradata06/fra/TSTDB1/archivelog/2015_09_28/  
mv /oradata06/o1_mf_1_104_1mLZe1E7j_.arc /oradata06/fra/TSTDB1/archivelog/2015_09_28/  


---tstdb1_stdby1：大约1分钟后managed recovery继续进行
***tstdb1_stdby1 alert.log内容：
Mon Sep 28 16:38:19 2015
RFS[1]: Allowing overwrite of partial archivelog for thread 1 sequence 102
RFS[1]: Opened log for thread 1 sequence 102 dbid 2051793563 branch 891526089
Archived Log entry 329 added for thread 1 sequence 102 rlc 891526089 ID 0x7ab78c1e dest 2:
Mon Sep 28 16:38:20 2015
Media Recovery Log /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_102_1mLd6IGHB_.arc
Media Recovery Log /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_103_1mLaMwux8_.arc
Error opening /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_103_1mLaMwux8_.arc
Attempting refetch
Media Recovery Waiting for thread 1 sequence 103
Fetching gap sequence in thread 1, gap sequence 103-103
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:38:30 2015
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:38:40 2015
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:38:50 2015
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:39:00 2015
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:39:10 2015
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:39:19 2015
RFS[2]: Allowing overwrite of partial archivelog for thread 1 sequence 103
RFS[2]: Opened log for thread 1 sequence 103 dbid 2051793563 branch 891526089
Archived Log entry 330 added for thread 1 sequence 103 rlc 891526089 ID 0x7ab78c1e dest 2:
Mon Sep 28 16:39:20 2015
Media Recovery Log /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_103_1mLd9tMuw_.arc
Media Recovery Log /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_104_1mLaMwzpf_.arc
Error opening /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_104_1mLaMwzpf_.arc
Attempting refetch
Media Recovery Waiting for thread 1 sequence 104
Fetching gap sequence in thread 1, gap sequence 104-104
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:39:30 2015
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:39:40 2015
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:39:50 2015
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:40:00 2015
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:40:10 2015
FAL[client]: Error fetching gap sequence, no FAL server specified
Mon Sep 28 16:40:19 2015
RFS[2]: Allowing overwrite of partial archivelog for thread 1 sequence 104
RFS[2]: Opened log for thread 1 sequence 104 dbid 2051793563 branch 891526089
Archived Log entry 331 added for thread 1 sequence 104 rlc 891526089 ID 0x7ab78c1e dest 2:
Media Recovery Log /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_104_1mLdDSSBQ_.arc
Media Recovery Log /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_105_1mLaN0VvY_.arc
Media Recovery Log /oradata06/teststdby/fra/TSTDB1_STDBY1/archivelog/2015_09_28/o1_mf_1_106_1mLaN9x5D_.arc

从上述过程可以看出在managed recovery的过程中，如果出现了archivelog gap，理论上需要依靠fal_server、fal_client的设置从primary上fetch missing archivelog。但我们测试中发现不设置fal_server、fal_client也能将缺失的archivelog从primary侧get过来，但是每fetch一个archivelog会有1分钟的时间浪费在检测fal_server阶段；因此在实际应用时还是建议设置好fal_server，fal_client，在11.2以上版本中fal_client可以不设置，因为fal_client的值可以从fal_server的log_archive_dest_n参数里自动获取

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

转载于:http://blog.itpub.net/53956/viewspace-1810980/

cuiqiong6888
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
ORACLE DATAGUARD中手工处理日志v$archive_GAP的方法
09-10
Oracle DataGuard是Oracle数据库系统中的一种高可用性和灾难恢复解决方案，它通过在远程站点创建物理或逻辑备用数据库来提供数据保护。在9i版本之后，DataGuard引入了Fast Application Notification (FAL)特性，该...
Dataguard 环境搭建 Oracle linux5
03-04
Oracle Data Guard 是一种高可用性和灾难恢复解决方案，它在Oracle数据库环境中提供了数据保护。在本实验中，我们将在Oracle Linux 5环境下搭建Data Guard环境，使用Oracle 11gR2 11.2.0.3版本。实验平台是VMware ...
Data Guard维护管理三之处理archivelog gap
cuizhi4718的博客
01-01 150
1.When Is an Archive Gap Discovered? An archive gap can occur whenever the primary database archives a log locall...
Manually Determining and Resolving Archive Gaps
05-31 142
5.8.4 Manually Determining and Resolving Archive Gaps In some situations, automatic gap recovery may not take p...
Dataguard-备机产生gap的解决方法
cuanfanli6122的博客
05-29 192
有时候因为网络或备份故障等原因，主机所产生的归档日志无法传到备机上，这个时候备机就产生了gap。对于这种情况，应该如何解决？需要注意的是，一旦产生gap，即使gap之后的archive log能正常传到standby库中，sta...
使用RMAN增量备份处理Dataguard因归档丢失造成的gap
weixin_30482181的博客
03-29 155
场景： 备库执行日志应用出现如下报错： Thu Mar 29 11:21:45 2018FAL[client]: Failed to request gap sequence GAP - thread 1 sequence 184-185 DBID 1484954774 branch 960494131FAL[client]: All defined FAL servers have been...
UNRESOLVABLE GAP
about database article
05-10 4761
SQL> select * from v$version where rownum BANNER -------------------------------------------------------------------------------- Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64b
通过duplicate搭建oracle dataguard环境
10-08
某公司实施文档记录，非常珍贵的资料，通过duplicate实现oracle dataguard环境的搭建，需要的请下载。
DataGuard 出现问题的检查步骤
04-09
DataGuard 出现问题的检查步骤
使用RMAN修复存在有GAP的dataguard
文档搬运工
10-15 494
原文地址：https://docs.oracle.com/cd/E11882_01/server.112/e41134/rman.htm#SBYDB00759 11.10 Using RMAN Incremental Backups to Roll Forward a Physical Standby Database In some situations, RMAN incremental ...
Data guard 出现gap sequence修复
shenghuiping2001的专栏
01-03 759
一、出现gap sequence现象 SQL> alter database open; alter database open * 第 1 行出现错误: 今天的dataguard ，备库恢复open时报错： ORA-16004: 备份数据库需要恢复 ORA-01152: 文件 1 没有从过旧的备份中恢复 ORA-01110: 数据文件 1: 'C:\ORACLE\PRODUCT\
Data Guard出现gap sequence修复
雨花石
01-17 1453
一、问题描述 今天下午客户那边断电，导致了其中一个备库数据库起不来，报了下面的错误 Media Recovery Waiting for thread 1 sequence 12364 Fetching gap sequence in thread 1, gap sequence 12364-12364 Wed Jan 17 15:20:57 2018 FAL[client]: Failed
批量注册dataguard 丢失gap
jisen_huang的专栏
09-03 556
ls -ltr |awk '{print "alter database register logfile \047/oracle/oradata/"$9"\047; "}' >regsql1.sql
DG关于备库日志缺失gap的问题
richard的专栏（bigdata.han@gmail.com）
01-18 1502
状态确认查询 当前没有应用完的最小日志文件序列 Select min(Sequence#) From V$archived_Log where Applied!='YES'; mrp当前正在应用的日志序列 select process,status,sequence# from v$managed_standby; 通过查询可以看出当前应用日志
Physical dataguard 如何自动解决archive log gap
loryliu的专栏
05-26 2227
下文是MOS上的： Data Guard Gap Detection and Resolution Possibilities (文档 ID 1537316.1)
FAL_CLIENT和FAL_SERVER 不设置也能apply redo
jnrjian的博客
04-20 1349
FAL_CLIENT和FAL_SERVER是配置dataguard用到的两个参数,FAL指获取归档日志(Fetch Archived Log) 正常情况MRP进程负责FAL，出现GAP使用RFS进程读取FAL_SERVER=pri，设置FAL_CLIENT=dg 因为主库可能反向查询dg的信息，这两个值就是TNS中的，和rman duplicate时一样的。 在一定的条件下，或者因为网络失败，或者因为资源紧张，会在primary和standby之间产生裂隙，也就是有些归档日志没有及时的传输并应..
oracle证书ocis,ORACLE dataguar 配置笔记
weixin_29997523的博客
04-04 328
天在一台机器上模拟了dataguard,主备两个实例从物理上不共享任何归档文件路径。主要有以下内容：dataguard Physical standby的创建protection mode的切换switch over模拟了两台机器oel1,oel2 主库的归档放在oel1里面，备库的放在oel2里面创建的路径如下./oel1:orcl_pri_arch orcl_stdby_arch./oel...
FAL[client]: Failed to request gap sequence
喝醉酒的小白
04-04 1751
问题 备库预警日志 排查思路 备库 select * from v$gap; 主库 col name format a90 select name from v$archived_log where sequence#=7348; select thread#, blocks*block_size/1024/1024 as GB, first_time, name from v$archived_log where sequence#=7348; 分析结果：主库归档已经删除了，备库获取失败 解决方
oracle959错误,一次Oracle DG错误警示（生产库）
weixin_32550525的博客
04-04 540
生产库DG ,防火墙限制，导致归档传送失败主库在北京，备库在云南，主备、库网络通道之间有防火墙，由于防火墙对数据包传输的大小做了限制，导致北京和云南之间的主备库传输归档日志失败。1、告警日志错误主库：(北京)WARN: ARC3: Terminating ARCH (pid 9608) hung on a network operationWARN: ARC3: Terminating ARCH ...
Oracle 11 Dg 一主两备的搭建步骤.docx
05-17
然后，使用`scp`命令将此文件复制到其他两个节点，以保持配置一致。在命令行中输入以下命令： ```bash # 在hisdg01上编辑并添加主机信息 vi /etc/hosts # 将hosts文件复制到hisdg02 scp /etc/hosts hisdg02:/etc/...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值