You can seek help from this (single node) and this (RAC) document for setting up dataguard. But if dataguard has become out of sync, there are several things that you might need to look at before you fix it. In the following I am providing a checklist that you can take a look to find out the issue and thus implement a solution.
- Check listener on both primary and dataguard. Listener should be up and running and database instance should be registered with the listener.
- On both primary and dataguard, check log_archive_n parameter for the correct values. TNS/connect string used in this parameter should be tested and made sure that they are resolving to correct database. On primary, it should resolve to standby; on standby it should resolve to primary.
- On primary, check log_archive_dest_state_n parameter. It should have value "ENABLE".
- On dataguard, check FAL_SERVER on dataguard. TNS/connect string specified in this parameter should resolve to the primary database.
- For 11g, on dataguard, check FAL_CLIENT. TNS/connect string specified in this parameter should be resolvable form the primary server to the standby database.
- Check if SYS password has recently been changed on primary. You can check this by checking "modified date" of the pasword file. Copy password file from the primary database to the standby database (all nodes in case of RAC).
- On dataguard, stop the instance (all instances in case of RAC), and start again.
- Once all of the above has
been tested/fixed, stop the managed recovery process on dataguard and start again.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
No comments:
Post a Comment