What is fal server

Under certain circumstances, either because of network failures or a busy source environment, a gap builds up between the target sending the information and the destination receiving the changes and applying them. The value is an Oracle Net service name, which is assumed to be configured properly on the standby database system to point to the desired FAL server.

The value is an Oracle Net service name, which is assumed to be configured properly on the FAL server system to point to the FAL client standby database. This functionality is provided by log apply services and is used by the physical standby database to manage the detection and resolution of archived redo logs.

It is possible; however, to define these two parameters in the initialization parameter for the primary database server to ease the amount of work that would need to be performed if the primary database were required to transition its role.

A log file gap occurs whenever a primary database continues to commit transactions while the LNS process has ceased transmitting redo to the standby database. This can happen when the network or the standby database is down and your Data Guard protection mode is not Maximum Protection.

This cycle can repeat itself many times on a busy system before the connection between the primary and the standby is restored, resulting a large log file gap. Data Guard uses an ARCH process on the primary database to continuously ping the standby database during the outage to determine its status. When the communication with the standby is restored, the ARCH ping process queries the standby control file via its RFS process to determine the last complete log file that the standby received from the primary database.

Data Guard determines which log files are required to resynchronize the standby database and immediately begins transmitting them using additional ARCH processes. At the very next log switch, the LNS will attempt and succeed in making a connection to the standby database and will begin transmitting current redo while the ARCH processes resolve the gap in the background. Once the standby apply process is able to catch up the current redo records, the apply process automatically transitions out of reading from archived redo logs and into reading from the current SRL Standby Redo Log.

The performance of automatic gap resolution is critical. The primary must be able to transmit data at a much faster pace than its normal redo generation rate if the standby is to have any hope of catching up. It is only used on a physical standby database. When a physical standby database finds a problem of missing log file, it can go and fetch it from one of the databases primary or standby in the Data Guard configuration.

This is also referred as reactive gap resolution. However nowadays most of gap requests from a physical or logical standby database can be handled by the ping process of the primary database as mentioned above.

Oracle Support recommends not to set it. Otherwise you will receive ORA error. Following example demonstrates this case. The minimum number of groups required is an exact match, number and size, of the primary database, but performance may be increased by adding more.

During managed recovery the transfer of archivelogs is controlled by the servers without user intervention. Now that Data Guard is configured and running the primary database can be prevented from applying updates unless the update has been sent to at least one standby location.

Connect to the primary database and execute the following. If the primary database is not available the standby database can be activated as a primary database using the following statements. Since the standby database is now the primary database it should be backed up immediately.

The previous primary database can then be configured as a standby. Backups of the standby database can only be performed if the database is shut down or in read only mode. Read only mode is best for managed recovery systems as archive logs will still be transfered during the backup process, thus preventing gap sequences. Once the server is in the desired mode simply copy the appropriate database files.

A database can be in one of two mutually exclusive modes primary or standby. These roles can be altered at runtime without loss of data or resetting of redo logs. This process is known as a Switchover and can be performed using the following statements. This process has no affect on alternative standby locations. The process of converting the instances back to their original roles is known as a Switchback. The switchback is accomplished by performing another switchover.

Graceful Database Failover occurs when database failover causes a standby database to be converted to a primary database. This process will recovery all or some of the application data using the standby redo logs, therefore avoiding reinstantiation of other standby databases. If completed successfully, only the primary database will need to be reinstatiated as a standby database.

Forced Database Failover changes one standby database to a primary database.