Pages

Sunday, May 26, 2013

how to check data guard is in sync?


### How to check data guard is in sync?

On Standby:


SQL> col CURRENT_SCN for 9999999999999999999

SQL> SELECT SCN_TO_TIMESTAMP(CURRENT_SCN) SYNC_UNTIL FROM V$DATABASE;

SYNC_UNTIL
---------------------------------
26-MAY-13 02.00.38.000000000 PM

SQL>

































Data Guard - How To Check Whether Physical Standby is in Sync with the Primary or Not?



Summary:


1. Check for GAP on standby
2. Check redo received on standby
3. Check redo applied on standby
4. Identify missing archive log files
5. Copy archive log files
6. Register archive log files with standby
7. Restart the managed recovery operations


step 1. Check for GAP on standby

-----------------------------------------------------------------------------------------------
primary + standby > select max(sequence#) from v$log_history;

primary > SELECT THREAD# "Thread",SEQUENCE# "Last Sequence Generated"
          FROM V$ARCHIVED_LOG
          WHERE (THREAD#,FIRST_TIME ) IN (SELECT THREAD#,MAX(FIRST_TIME) FROM V$ARCHIVED_LOG GROUP BY THREAD#)
          ORDER BY 1;
-----------------------------------------------------------------------------------------------


step 2 and 3. Check redo received on standby and Check redo applied on standby

-----------------------------------------------------------------------------------------------
standby > SELECT ARCH.THREAD# "Thread", ARCH.SEQUENCE# "Last Sequence Received", APPL.SEQUENCE# "Last Sequence Applied", (ARCH.SEQUENCE# - APPL.SEQUENCE#) "Difference"
          FROM
         (SELECT THREAD# ,SEQUENCE# FROM V$ARCHIVED_LOG WHERE (THREAD#,FIRST_TIME ) IN (SELECT THREAD#,MAX(FIRST_TIME) FROM V$ARCHIVED_LOG GROUP BY THREAD#)) ARCH,
         (SELECT THREAD# ,SEQUENCE# FROM V$LOG_HISTORY WHERE (THREAD#,FIRST_TIME ) IN (SELECT THREAD#,MAX(FIRST_TIME) FROM V$LOG_HISTORY GROUP BY THREAD#)) APPL
         WHERE
         ARCH.THREAD# = APPL.THREAD#
          ORDER BY 1;
-----------------------------------------------------------------------------------------------


step 4. Identify missing archive log files

-----------------------------------------------------------------------------------------------
-- if GAP
standby > SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
-----------------------------------------------------------------------------------------------


step 5.  Copy archive log files

-----------------------------------------------------------------------------------------------
After identifying a gap (as shown above), the DBA will need to query the primary database
to locate the archived redo logs on the primary database. The following query assumes the
local archive destination on the primary database is LOG_ARCHIVE_DEST_1:

primary > SELECT name
            FROM v$archived_log
            WHERE thread# = 1
              AND dest_id = 1
              AND sequence# BETWEEN 09464 and 90468;
-----------------------------------------------------------------------------------------------


step 6. Register archive log files with standby

-----------------------------------------------------------------------------------------------
--  Copy the above redo log files to the physical standby database and register
    them using the ALTER DATABASE REGISTER LOGFILE ... SQL statement on the
    physical standby database.
 
    For example:

standby > ALTER DATABASE REGISTER LOGFILE '/u04/arch/HSBC33/arch_t1_s64.dbf';
standby > ALTER DATABASE REGISTER LOGFILE '/u04/arch/HSBC33/arch_t1_s65.dbf';
standby > ALTER DATABASE REGISTER LOGFILE '/u04/arch/HSBC33/arch_t1_s66.dbf';
standby > ALTER DATABASE REGISTER LOGFILE '/u04/arch/HSBC33/arch_t1_s67.dbf';
standby > ALTER DATABASE REGISTER LOGFILE '/u04/arch/HSBC33/arch_t1_s68.dbf';
-----------------------------------------------------------------------------------------------


step 7. Restart the managed recovery operations

-----------------------------------------------------------------------------------------------
-- After the redo logs have been registered on the physical standby database,
   the DBA can restart the managed recovery operations.

   For example, to put the physical standby database into automatic recovery managed mode:

standby > alter database recover managed standby database disconnect from session;
-----------------------------------------------------------------------------------------------


Tuesday, March 5, 2013

How to check RECOVER MANAGED STANDBY DATABASE real time apply?



### On Standby: Delayed apply or Real time apply?


SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DELAY 60 disconnect; -- apply delayed for 60 minutes.

Database altered.

SQL> SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS;

RECOVERY_MODE
-----------------------
MANAGED
IDLE
IDLE
IDLE
...


SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE disconnect; -- Realtime apply

Database altered.

SQL> SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS; 

RECOVERY_MODE
-----------------------
MANAGED REAL TIME APPLY
IDLE
IDLE
IDLE
...



-- no time delay
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; 

-- no time delay
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY DISCONNECT;

-- 60 minutes delay
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DELAY 60 DISCONNECT;

-- real time apply
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;


--- Note: -----------------------------------------------------------------------------------

By default, apply services wait for the full archived redo log file to arrive on the standby database before applying it to the standby database.

If the real-time apply feature is enabled, apply services can apply redo data as it is received, without waiting for the current standby redo log file to be archived.