Re: Database Link to check Standby Database

Ton wrote:
> I want to to create a Database Link from the production database to
> its Standby database.
>
> Purpose: Checking " V$LOG_HISTORY " on the Production and Standby
> server to idenity if all available production redo log files have been
> applied on the Standby datase.
>
> Questions:
>
> 1. Is it sensible to create and drop the Database Link connection
> everytime I run the script?
>
> 2. What will be consequences for the Standby server by creating a DB
> link by the Production server?
> In other words: During applying the redo log files from the production
> to the standby database will the Standby database also try to create
> database link (to itself)?
>
> 3. Is there a handier solution to check automatically if the both
> (Prod. & Standby) are in sequence?
>
> Thanks

You didn't mention a version. Are you asking about a physical standby or a logical standby?

In a physical standby, the Dataguard documentation specifically mentions V$ARCHIVE_DEST_STATUS as a way to determine managed recovery progress and gives a sample query. This view is (should be) identical on both the primary and the standby, so you could just check it on the primary and forget the link.

The documentation gives several other examples using V$ARCHIVED_LOG and V$LOG_HISTORY as well, in case you are doing manual recovery. You don't need a DB link for this, you could connect directly from SQL*Plus or some other client -- but link or otherwise, only if the standby is opened temporarily in read-only mode (which is the only way to open a physical standby without destroying its standby status).

A different view (dba_logstdby_progress) exists for the same purpose in a logical standby. With a logical standby database, the documentation calls for creating various links between the primary and standby in case a table needs to be re-instantiated or in case you are doing a switchover for disaster recovery (the latter is considered to be somewhat buggy and unreliable for version 9iR2).

--Mark Bole Received on Mon Aug 23 2004 - 09:36:43 CDT