Oracle dataguard is not working properly because a FAL[client]

Question

I had two databases, a primary and secondary and a configured dataguard between both, i restarted the suse linux but when starting up databases, the replication is not being done, i think i took the wrong way to startup the standby database....no it is just mounted, i have a gap not posibble to be detected at standby gap table, and a 'no FAL server specified' problem at standby database, what could be wrong?

    From Primary:
    System parameters with non-default values:
    processes                = 1200
    nls_date_format          = "MM/DD/YYYY HH24:MI:SS"
    memory_target            = 8000M
    memory_max_target        = 8G
    control_files            = "/oracle/app/oradata/ora11g/control01.ctl"
    control_files            = "/oracle/app/oradata/ora11g/control02.ctl"
    control_files            = "/oracle/app/oradata/ora11g/control03.ctl"
    db_block_size            = 8192
    compatible               = "11.1.0.0.0"
    log_archive_start        = TRUE
    log_archive_dest_1       = "LOCATION=/home/oracle/archive"
    log_archive_format       = "%t_%s_%r.dbf"
    db_recovery_file_dest    = "/oracle/app/flash_recovery_area"
    db_recovery_file_dest_size= 2G
    undo_tablespace          = "UNDOTBS1"
    sec_case_sensitive_logon = FALSE
    remote_login_passwordfile= "EXCLUSIVE"
    db_domain                = ""
    dispatchers              = "(PROTOCOL=TCP) (SERVICE=ora11gXDB)"
    local_listener           = ""
    remote_listener          = ""
    session_cached_cursors   = 450
    cursor_sharing           = "FORCE"
    audit_file_dest          = "/oracle/app/admin/ora11g/adump"
    audit_trail              = "NONE"
    db_name                  = "ora11g"
    open_cursors             = 300
    diagnostic_dest          = "/oracle/app"

From standby database alert log:

    Thu Feb 13 17:16:02 2014
    Starting ORACLE instance (normal)
    LICENSE_MAX_SESSION = 0
    LICENSE_SESSIONS_WARNING = 0
    Picked latch-free SCN scheme 3
    Autotune of undo retention is turned on.
    IMODE=BR
    ILAT =145
    LICENSE_MAX_USERS = 0
    SYS auditing is disabled
    Starting up ORACLE RDBMS Version: 11.1.0.7.0.
    Using parameter settings in server-side spfile        
    /oracle/app/product/11g/db/dbs/spfileora11g.ora
    System parameters with non-default values:
    processes                = 1200
    nls_date_format          = "MM/DD/YYYY HH24:MI:SS"
    memory_target            = 8000M 
    memory_max_target        = 8G
    control_files            = "/oracle/app/oradata/ora11g/control01.ctl"
    control_files            = "/oracle/app/oradata/ora11g/control02.ctl"
    control_files            = "/oracle/app/oradata/ora11g/control03.ctl"
    db_block_size            = 8192
    compatible               = "11.1.0.0.0"
    log_archive_start        = TRUE
    log_archive_dest_1       = "LOCATION=/home/oracle/archive"
    log_archive_format       = "%t_%s_%r.dbf"
    db_recovery_file_dest    = "/oracle/app/flash_recovery_area"
    db_recovery_file_dest_size= 2G
    undo_tablespace          = "UNDOTBS1"
    sec_case_sensitive_logon = FALSE
    remote_login_passwordfile= "EXCLUSIVE"
    db_domain                = ""
    dispatchers              = "(PROTOCOL=TCP) (SERVICE=ora11gXDB)"
    local_listener           = ""
    remote_listener          = ""
    session_cached_cursors   = 450
    cursor_sharing           = "FORCE"
    audit_file_dest          = "/oracle/app/admin/ora11g/adump"
    audit_trail              = "NONE"
    db_name                  = "ora11g"
    open_cursors             = 300
    diagnostic_dest          = "/oracle/app"
    Deprecated system parameters with specified values:
    log_archive_start
    End of deprecated system parameter listing
    Thu Feb 13 17:16:04 2014
    .
    .
    .
    starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)   (PROTOCOL=TCP))'...
    Thu Feb 13 17:16:04 2014
    MMNL started with pid=15, OS id=10039
    starting up 1 shared server(s) ...
    ORACLE_BASE from environment = /oracle/app
    Thu Feb 13 17:16:04 2014
    ALTER DATABASE   MOUNT
    Setting recovery target incarnation to 2
    ARCH: STARTING ARCH PROCESSES
    Thu Feb 13 17:16:09 2014
    ARC0 started with pid=19, OS id=10272
    Thu Feb 13 17:16:09 2014
    ARC1 started with pid=20, OS id=10274
    Thu Feb 13 17:16:09 2014
    ARC2 started with pid=21, OS id=10276
    ARC0: Archival started
    ARC1: Archival started
    ARC2: Archival started
    Thu Feb 13 17:16:09 2014
    ARC3 started with pid=22, OS id=10278
    ARC3: Archival started
    ARCH: STARTING ARCH PROCESSES COMPLETE
    ARC0: Becoming the 'no FAL' ARCH
    ARC0: Becoming the 'no SRL' ARCH
    ARC0: Thread not mounted
    ARC1: Becoming the heartbeat ARCH
    ARC2: Thread not mounted
    ARC1: Thread not mounted
    ARC3: Thread not mounted
    Successful mount of redo thread 1, with mount id 4235628820
    Physical Standby Database mounted.
    Lost write protection disabled
    Completed: ALTER DATABASE   MOUNT
    FAL[client]: Error fetching gap sequence, no FAL server specified

Primary

    SQL> select max(sequence#) from v$log_history;
    MAX(SEQUENCE#)
    --------------
    1606


    SQL> SELECT name FROM v$archived_log WHERE thread# = 1 AND dest_id = 1 AND sequence#         BETWEEN 1591 and 1606;
    /home/oracle/archive/1_1606_792822090.dbf
    16 rows selected.

    SQL>  SELECT GROUP#, BYTES FROM V$LOG;
    GROUP#      BYTES
    ---------- ----------
     1   52428800
     2   52428800
     3   52428800

Secondary

    SQL> select max(sequence#) from v$log_history;
    MAX(SEQUENCE#)
    --------------
    1591



    SQL>select process, thread#, sequence#, status from v$managed_standby where   process='MRP0';
    no rows selected


    SQL> SELECT GROUP#, BYTES FROM V$STANDBY_LOG;
    no rows selected

Answer 1

This question is 5 years old but I feel it hasn't been completely answered yet.

First how does oracle resolves the gap:

The MRP process is the one triggering the request for a GAP. That process is turned on like so: Without standby redo logs: alter database recover managed standby database disconnect; With standby redo: alter database recover managed standby database using current logfile disconnect;

If you have only one standby database for your primary database, then fal_server and fal_client parameters actually don't need to be configured.

If the fal_server is missing, oracle will grab that information from log_archive_dest_n.

This means that log_archive_dest_2 needs to be configured also on the standby database.

So how to solve a GAP resolution issue:

1. Make sure log_archive_dest_n is setup in both primary and standby
2. Make sure that there's no typo in the "service" value of log_archive_dest_n.
3. Make sure that the service value references a valid tns entry in tnsnames.ora
4. Make sure that the same password file is used on all nodes of your primary and standby cluster.
5. Make sure you can connect with sqlplus "sys/syspassword@primary as sysdba" and sqlplus "sys/syspassword@standby as sysdba" from both primary and standby.List item

The MRP process sends a GAP resolution requests every so often. If you want to get it immediately in order to make sure it works: SQL>alter database recover managed standby database cancel; SQL>alter database recover managed standby database using current logfile; (use standby redo logs, it applies logs faster on standby)

---

fal_server and fal_client parameters actually exists if you want to setup a cascaded standby setup.

Primary DB A sends archived logs to standby B If standby B becomes primary then send archived logs to standby C.

FAL behavior on 11.2 (Doc ID 1394472.1)

From 11.2 no need to mention FAL_CLIENT primary will take it from log_archive_dest_n (remote destination standby from where it received the FAL request) service.

FAL_SERVER And FAL_CLIENT Settings For Cascaded Standby (Doc ID 358767.1)

Answer 2

You need to set to parameters in the init file or spfile(sqlplus)

In the Primary database :

FAL_SERVER='standby_database'
FAL_CLIENT='primary_database'

In the standby database :

FAL_SERVER='primary_database'
FAL_CLIENT='standby_database'

These two parameters are needed for fetching archived log files (FAL mean Fetch ArchiveLog).

Hope that i help you.

Kind