FAL_CLIENT和FAL_SERVER 不设置也能apply redo

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之间产生裂隙，也就是有些归档日志没有及时的传输并应用到standby库。因为MRP(managed recovery process)/LSP(logical standby process)没有与primary直接通讯的能力来获取丢失的归档日志。因此这些gaps通过FAL客户和服务器来解决，由初始化参数定义FAL_CLIENT和FAL_SERVER。

FAL_SERVER指定一个Oracle Net service name,standby数据库使用这个参数连接到FAL server,这个参数适用于standby站点。比如,FAL_SERVER = PrimaryDB,此处PrimaryDB是一个TNS name,指向primary库。

FAL_CLIENT指定一个FAL客户端的名字，以便FAL Server可以引用standby库，这也是一个TNS name，primary库必须适当配置此TNS name指向stanby库。这个参数也是在standby库端设置。比如，FAL_CLIENT = StandbyDB,StandbyDB是standby库的TNS name。

FAL_CLIENT和FAL_SERVER应该成对设置或改变。

这两个参数只需在standby库设置，但也可以在primary库设置这两个参数，以方便switchover或failover时primary库转变为standby角色。
 

做了几个实验，主备库都是没有配置FAL参数，GAP也能解决。 实验过程如下:

1.主备库  并且没有配置FAL

SQL> show parameter fal

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

fal_client string

fal_server string

2.接下来 DOWN掉备库， 主库并且重启DB  然后切换多次主库归档

SQL> archive log list;

Database log mode Archive Mode

Automatic archival Enabled

Archive destination /u01/arch

Oldest online log sequence 594

Next log sequence to archive 596

Current log sequence 596

…多次切换 …

SQL> archive log list;

Database log mode Archive Mode

Automatic archival Enabled

Archive destination /u01/arch

Oldest online log sequence 603

Next log sequence to archive 605

Current log sequence 605

3.开启备库监听和DB并接受应用日志

Sat Oct 10 10:39:54 2015

Managed Standby Recovery not using Real Time Apply

Parallel Media Recovery started with 4 slaves

Waiting for all non-current ORLs to be archived...

All non-current ORLs have been archived.

Media Recovery Waiting for thread 1 sequence 596

FAL[client]: Error fetching gap sequence, no FAL server specified

Completed: alter database recover managed standby database disconnect from session

此时会看到GAP信息，但是归档还是可以传过来并被应用的。

Sat Oct 10 10:41:07 2015

Using STANDBY_ARCHIVE_DEST parameter default value as /u01/app/oracle/product/11.2.0/db_1/dbs/arch

RFS[1]: Assigned to RFS process 12075

RFS[1]: Opened log for thread 1 sequence 598 dbid 1651635937 branch 886845731

Archived Log entry 80 added for thread 1 sequence 598 rlc 886845731 ID 0x62727be1 dest 2:

Sat Oct 10 10:41:08 2015

RFS[2]: Assigned to RFS process 12079

RFS[2]: Opened log for thread 1 sequence 596 dbid 1651635937 branch 886845731

RFS[1]: Opened log for thread 1 sequence 599 dbid 1651635937 branch 886845731

Archived Log entry 81 added for thread 1 sequence 599 rlc 886845731 ID 0x62727be1 dest 2:

Sat Oct 10 10:41:08 2015

RFS[3]: Assigned to RFS process 12077

RFS[3]: Opened log for thread 1 sequence 597 dbid 1651635937 branch 886845731

Archived Log entry 82 added for thread 1 sequence 596 rlc 886845731 ID 0x62727be1 dest 2:

Archived Log entry 83 added for thread 1 sequence 597 rlc 886845731 ID 0x62727be1 dest 2:

RFS[1]: Opened log for thread 1 sequence 600 dbid 1651635937 branch 886845731

RFS[2]: Opened log for thread 1 sequence 601 dbid 1651635937 branch 886845731

Archived Log entry 84 added for thread 1 sequence 600 rlc 886845731 ID 0x62727be1 dest 2:

RFS[3]: Opened log for thread 1 sequence 602 dbid 1651635937 branch 886845731

Archived Log entry 85 added for thread 1 sequence 601 rlc 886845731 ID 0x62727be1 dest 2:

Archived Log entry 86 added for thread 1 sequence 602 rlc 886845731 ID 0x62727be1 dest 2:

RFS[1]: Opened log for thread 1 sequence 603 dbid 1651635937 branch 886845731

Archived Log entry 87 added for thread 1 sequence 603 rlc 886845731 ID 0x62727be1 dest 2:

RFS[2]: Opened log for thread 1 sequence 604 dbid 1651635937 branch 886845731

Archived Log entry 88 added for thread 1 sequence 604 rlc 886845731 ID 0x62727be1 dest 2:

RFS[2]: Opened log for thread 1 sequence 605 dbid 1651635937 branch 886845731

Archived Log entry 89 added for thread 1 sequence 605 rlc 886845731 ID 0x62727be1 dest 2:

Sat Oct 10 10:41:11 2015

Primary database is in MAXIMUM PERFORMANCE mode

RFS[4]: Assigned to RFS process 12081

RFS[4]: No standby redo logfiles created

RFS[4]: Opened log for thread 1 sequence 606 dbid 1651635937 branch 886845731

Sat Oct 10 10:41:14 2015

Media Recovery Log /u01/app/oracle/product/11.2.0/db_1/dbs/arch1_596_886845731.dbf

Media Recovery Log /u01/app/oracle/product/11.2.0/db_1/dbs/arch1_597_886845731.dbf

Media Recovery Log /u01/app/oracle/product/11.2.0/db_1/dbs/arch1_598_886845731.dbf

Media Recovery Log /u01/app/oracle/product/11.2.0/db_1/dbs/arch1_599_886845731.dbf

Media Recovery Log /u01/app/oracle/product/11.2.0/db_1/dbs/arch1_600_886845731.dbf

Media Recovery Log /u01/app/oracle/product/11.2.0/db_1/dbs/arch1_601_886845731.dbf

Media Recovery Log /u01/app/oracle/product/11.2.0/db_1/dbs/arch1_602_886845731.dbf

Media Recovery Log /u01/app/oracle/product/11.2.0/db_1/dbs/arch1_603_886845731.dbf

Media Recovery Log /u01/app/oracle/product/11.2.0/db_1/dbs/arch1_604_886845731.dbf

Media Recovery Log /u01/app/oracle/product/11.2.0/db_1/dbs/arch1_605_886845731.dbf

Media Recovery Waiting for thread 1 sequence 606 (in transit)

然后，他又尝试备库断掉之后，将主库的归档日志MV移动到其他地方，备库启动后，提示GAP，但是将归档MV回去后，又可以自动同步，这些都是在主备库没有设置FAL参数的情况想完成的，那么FAL参数到底有什么作用呢？

以下是我在没有设置FAL参数时的实验，数据库版本同样是11.2.0.4.0，备库无法read only模式打开。

[oracle@SL010M6-DB-PROMSTD2 admin]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on Fri Oct 16 17:44:29 2015

Copyright (c) 1982, 2013, Oracle. All rights reserved.

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> select status from v$instance;

STATUS

------------

MOUNTED

SQL> alter database open;

当OPEN备库的时候，需要介质恢复，由于没有设置FAL参数，备库不知道去哪取日志，命令将会夯住，告警日志会提示没有设置FAL参数。

alter database open

AUDIT_TRAIL initialization parameter is changed to OS, as DB is NOT compatible for database opened with read-only access

Signalling error 1152 for datafile 1!

Beginning Standby Crash Recovery.

Serial Media Recovery started

Managed Standby Recovery starting Real Time Apply

Media Recovery Waiting for thread 1 sequence 36

FAL[client]: Error fetching gap sequence, no FAL server specified

Fri Oct 16 17:44:53 2015

FAL[client]: Error fetching gap sequence, no FAL server specified

Fri Oct 16 17:45:03 2015

FAL[client]: Error fetching gap sequence, no FAL server specified

Fri Oct 16 17:45:13 2015

FAL[client]: Error fetching gap sequence, no FAL server specified

Fri Oct 16 17:45:23 2015

FAL[client]: Error fetching gap sequence, no FAL server specified

设置FAL参数后，备库就可以READ ONLY模式打开。

SQL> alter system set fal_client=promstd2;

System altered.

SQL> alter system set fal_server=promotion;

System altered.

SQL>

备库告警日志信息如下：

Fri Oct 16 17:47:16 2015

alter database open

Signalling error 1152 for datafile 1!

Beginning Standby Crash Recovery.

Serial Media Recovery started

Managed Standby Recovery starting Real Time Apply

Media Recovery Log /u01/app/oracle/arch/1_38_892918972.arc

Incomplete Recovery applied until change 1243923 time 10/16/2015 17:42:31

Completed Standby Crash Recovery.