DATAGUARD Management archive interrupt

Posted on 2010-01-23 filed under: Oracle (RSS) 13 views

If the backup system did not receive one or more of the primary database archived redo log files generated in the backup system will appear on archive interruption. Missing archived redo log file is interrupted. If there is disruption, then the Data Guard automatically detects and through copies of the missing sequence of log files to prepare the destination to resolve. For example, when the network becomes unavailable, from the primary database to a standby database, automatically archiving the temporary stop, there will be disruption archive. When the network is available again, from the primary database to the failure of the database redo data prepared by the automatic transmission to continue.
Data Guard does not require DBA manual intervention to detect and resolve such interrupts. The following section describes the interrupt detection and resolution.

Found that interrupt when the archive?

Whenever the primary database archives a log locally, but the prepared site does not receive the log archive interrupt occurs. Per minute, the primary database to investigate the Preparation of the database to see whether the archived redo log file sequence interruptions.

How to solve the break?

Interruption recovery solution through the polling mechanism. Prepared for the physical and logical databases, Oracle Change Data Capture, and Oracle Streams, Data Guard by automatically retrieving missing from the primary database archived redo log files to perform interrupt detection and resolution. No additional configuration settings to investigate the prepared database to detect any disruption or settlement disruption.
A very important consideration here is automatically interrupted recovery is in accordance with the primary database depend on the availability. If the primary database is not used, and you prepare to configure multiple physical databases, you can set up additional initialization parameters allow the database redo applications solve the archive from the others prepared interrupted.

Note:
In Oracle Database 10g version of the one before, FAL client and server from the primary database used to solve the break.

Use to take archive log (FAL) to address the archiving break

Take archive log (FAL) client and service to address the main database-generated databases and physical prepared to receive the archived redo log files to the range of detected interrupt.
𐁺 FAL client to automate requests for archived redo log file transfer.
𐁺 FAL server services from the FAL client to the FAL request.

FAL mechanism to deal with the following types of archive outages and problems:
𐁺 When you create a physical or logical prepared database, FAL mechanism can automatically retrieve the primary database, generated during hot backup of any archived redo log files.
𐁺 when there are in the database has been prepared to receive the archived redo log files to the question, FAL mechanism can automatically retrieve the archived redo log file to resolve any of the following circumstances:
𐁻 When the archived redo log files in the application to prepare the data before being removed from the disk.
𐁻 When the archived redo log files can not be applied because the disk is damaged.
𐁻 When the archived redo log files in the redo data is applied to the database before the accident was not the archived redo log files and other documents to replace (for example, a text file).
𐁺 prepared when you have multiple physical databases, FAL mechanism to prepare a database from the other physical automatically retrieve missing archived redo log files.
FAL client and server use the database set FAL_CLIENT prepared and FAL_SERVER initialization parameters to configure. In the initialization parameter file defined in the initialization parameter FAL_CLIENT and FAL_SERVER only to prepare a database of physics, as shown in the table:

Parameters	Function	Syntax
FAL_SERVER	Preparation of the database should be used to specify the FAL server to connect the network service name. It can be a list that contains multiple values.	Syntax FAL_SERVER = net_service_name Examples FAL_SERVER = standby2_db, standby3_db
FAL_CLIENT	Specify the FAL server should be used to connect to a database prepared by the network service name.	Syntax FAL_CLIENT = net_service_name Examples FAL_CLIENT = standby1_db

Manual detection and resolution of archiving interrupt

In some cases, automatic interruption recovery may not occur, you will need to manually restore the implementation of interrupts. For example, if you are prepared to use the logical database and the primary database is not available, you will need to manually implement interrupt recovery.
The following sections describe how to query the appropriate views to determine which log files are lost and the implementation of the manual recovery.

Prepared in the physical database:

To determine the physical prepared in your database whether there is disruption archive, query V $ ARCHIVE_GAP view, as shown in the following examples:

SQL> SELECT * FROM V $ ARCHIVE_GAP;

THREAD # LOW_SEQUENCE # HIGH_SEQUENCE #
----------- ------------- --------------
1710

The previous example of the output that your physical Preparation of the database log files from the current thread is a lost serial number seven to number 10. After you determine the break in the main database to execute the following SQL statement in your primary database archived redo log file location (assuming the primary database on the local archive destination is LOG_ARCHIVE_DEST_1):

SQL> SELECT NAME FROM V $ ARCHIVED_LOG WHERE THREAD # = 1 AND DEST_ID = 1
2> AND SEQUENCE # BETWEEN 7 AND 10;

NAME
-------------------------------------------------- ---------------
/ primary/thread1_dest/arcr_1_7.arc
/ primary/thread1_dest/arcr_1_8.arc
/ primary/thread1_dest/arcr_1_9.arc

Copies of these log files to your physical prepared in your physical database and prepare a database using the ALTER DATABASE REGISTER LOGFILE statement to register them. For example:

SQL> ALTER DATABASE REGISTER LOGFILE
'/ physical_standby1/thread1_dest/arcr_1_7.arc';
SQL> ALTER DATABASE REGISTER LOGFILE
'/ physical_standby1/thread1_dest/arcr_1_8.arc';

Preparation of your physical database to register these log files, you can restart redo application.

Note:
Physical Preparation of the database on the fixed view V $ ARCHIVE_GAP to return only redo the current application continues to prevent the next interrupt. Redo in resolving interrupt and restart the application again after the physical Preparation of database query V $ ARCHIVE_GAP a fixed view to determine the next interrupt number, if any. Repeat this process until no more interrupts.

Prepared in logic databases:

To determine whether there are archived interrupted, logically prepared database queries DBA_LOGSTDBY_LOG view. For example, the following query pointed out that the serial number of archived redo log files have discontinued because it was logically prepare the data showed that two files for THREAD1. (If not broken, then the query should show only one file for each thread.) Output displays the highest registration document serial number 10, but as shown in the file sequence number 6 are interrupted:

SQL> COLUMN FILE_NAME FORMAT a55

SQL> SELECT THREAD #, SEQUENCE #, FILE_NAME FROM DBA_LOGSTDBY_LOG L
2> WHERE NEXT_CHANGE # NOT IN
3> (SELECT FIRST_CHANGE # FROM DBA_LOGSTDBY_LOG WHERE L. THREAD # =
THREAD #)
4> ORDER BY THREAD #, SEQUENCE #;

THREAD # SEQUENCE # FILE_NAME
--------- ---------- ------------------------------- --------------
1 6 / disk1/oracle/dbs/log-1292880008_6.arc
1 10 / disk1/oracle/dbs/log-1292880008_10.arc

Copy the missing log files, serial numbers 7,8 and 9, to the logical backup system, and prepare a database of your use of the logic of ALTER DATABASE REGISTER LOGICAL LOGFILE statement to register them.

For example:
SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE
'/ disk1/oracle/dbs/log-1292880008_10.arc';

Logically prepared in your database to register these log files, you can restart the SQL application.

Note:
Prepared in logic on the database DBA_LOGSTDBY_LOG view only returns the current application continues to prevent the next SQL interrupt. In the settlement of the specified interrupt and restart the SQL applications, the re-prepared database queries in the logical view to determine the next DBA_LOGSTDBY_LOG interrupt number, if any. Repeat this process until no more interrupts.