ORACLE DG环境FAL参数的作用
Nov022015
前几天和同学研究下DG的FAL参数的作用，众所周知，FAL参数是解决GAP问题的，可是什么时候会使用到FAL参数呢？同学做了几个实验，主备库都是没有配置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.
ORACLE DG环境FAL参数的作用：等您坐沙发呢！
发表评论
