ITPub博客

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

原创 作者:oliseh 时间:2015-09-28 16:59:25 0 删除 编辑

<<< 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参数里自动获取
请登录后发表评论 登录
全部评论
不仅仅专注Oracle database技术, member of SHOUG

注册时间:2014-04-06

  • 博文量
    128
  • 访问量
    1602458