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

Before I got up, the damn phone rang. A stressful news: the dataguard database master is out of sync, so get up and work quickly.

The first step is to check the alarm log log.xml. Open your eyes and look carefully, and you don't see any abnormal output; then filter it with tools like grep, and you don't get anything. It seems that the situation is still good. If there is something like error here, there will be a big problem.

Next, check the serial numbers on both sides of the master and standby, and find that the archival serial numbers on both sides are the same.

As a result, it can be concluded that the archive log continues to be transferred and that no archive data has been lost. To ensure that in case of emergency, execute SQL > select name,SEQUENCE#,APPLIED fromv$archived_log order by sequence#; on the slave database to capture the output as follows:

Check the directory to see if these archive logs exist. Fortunately, they are! Check it on the main database, and the serial number is also right with the standby database. Now you can confirm that standby did not apply the log, go back to see if the process mrp is running, ps aux | grep mrp, hey, no! All right, let's execute it. The specific instructions are:

Sql > alter database recover managed standby database using current logfile disconnect

After the execution is completed, we can understand what happened by comparison.

Next, open the alarm log and you can see the changes in the archiving application. At the same time, contact others to check whether the data is gradually increasing.

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.