Shulou(Shulou.com)06/01 Report--

In general, if there is a problem with dataguard, you will see the relevant error message in the alert log, or execute the SQL statement command.

Select error from v$ archive_dest can query and report an error. If an error occurs, check the steps as follows:

(1) check the alert logs of the main database and slave database to find out what the problem is.

(2) Log in to the main database (RAC) to check the status of archived logs

Select dest_id,thread#,max (sequence#) from v$archived_log where archived='YES' group by thread#,dest_id

Write down the max sequence of tread 1 and tread 2

(3) check the status of the reserve database.

Select archived_thread#,archived_seq#,applied_thread#,applied_seq# from vastly archived destabilization status; check whether it is synchronized with the main database. If it is consistent with the max sequence of the above master database, then it is done. There is no need to check, because the status is normal, but in general, due to network delay problems, one or two may also be ok status.

Select process,status,sequence# from v$managed_standby

There is usually an ARCH/RFS/MRP0 process

The ARCH process is responsible for copying the full redo log file to the archive log file after the redo log file switch, so as to prevent it from being overwritten when the redo log file is written in a loop.

RFS log receiving process

MRP0 is to manage the recovery process

In other words, ARCH archives the redo log, then RFS receives the archived logs, and MRP0 recovers the archived logs, all of which are indispensable.

All three have seq that can look at RFS and MRP0. If it is similar to the main library, there is no need to check it. It is generally normal.

Select dest_id,thread#,max (sequence#) from v$archived_log where archived='YES' group by thread#,dest_id; checks the receipt of archive logs from this repository

Select sequence#,applied from v$archived_log where applied='NO'; checks logs that are not applied in the repository.

The above are the general dg inspection steps. The last time there was a power outage, the standby database was shut down, and then when it was started, no attention was paid to whether the log continued to be applied. No erro was reported in the log of the master and slave database, and the log transfer was normal, and there was no gap (select * from v$archive_gap), but the slave database did not have the application log, so it was considered that the MRP0 process did not start.

Alter database recover managed standby database disconnect from session

The log begins to be applied. Consider executing this statement after the next power outage to avoid out-of-sync of data from disaster recovery to the computer room.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.