We're here to help!

  1. Dbvisit Support
  2. Dbvisit Standby
  3. Dbvisit Standby Knowledge Base

Keeping Cascade Standby up to date after running Graceful Switchover

Follow
Grace Tan —

Read our docs This article provides some workaround that should help keep Cascade Standby up to date after a Graceful Switchover is performed between Primary and Standby1.


Problem Details

Problem Statement

N/A

Applicable Error Code

N/A

Affected Versions

Dbvisit Standby v8

Affected Platforms

All platforms supported by v8

 


Description

How to keep Cascade Standby configuration working and up to date after a Graceful Switchover is performed between Primary and Standby1.

 

I have below configuration where Standby2 is created using Dbvisit Standby Cascade option.

Primary: kiwi701; Oracle 12.2.0.1.0 Single instance, +ASM

Standby1: kiwi702; Oracle 12.2.0.1.0 Single instance, +ASM

Standby2: kiwi703; 12.2.0.1.0 Single instance, Filesystem

DDC1: DEV (for Primary -> Standby1)

DDC2: DEV2 (for Standby1 -> Standby2)

 

Steps Performed

OPTION 1 - Keeping CASCADE=Y in the DDC

  1. Run GS between Primary and Standby1. Prior to clicking "SUBMIT" button, make sure that log gap is 0. Otherwise, if there is a gap, GS will prompt you to send and apply logs to standby until they are sync. Note: Prior to running GS, I have disabled Dbvisit Scheduling / daemon across all servers.

    Once GS is successful, send and apply logs should work as per normal between the new Primary (kiwi702) and now Standby1 (kiwi701).

    on new Primary:

    [oracle@kiwi702 /usr/dbvisit/standby]$ ./dbvctl -d DEV
    =============================================================
    Dbvisit Standby Database Technology (8.0.14.19186) (pid 7959)
    dbvctl started on kiwi702: Tue Jun 20 14:42:36 2017
    =============================================================

    >>> Obtaining information from standby database (RUN_INSPECT=Y)... done
    Note FORCE_LOGGING is disabled in the primary database.
        Performing a log switch...


    >>> Transferring Log file(s) from DEV on kiwi702 to kiwi701 for thread 1:

        thread 1 sequence 61 (thread_1_seq_61.298.947169761)

    =============================================================
    dbvctl ended on kiwi702: Tue Jun 20 14:42:48 2017
    =============================================================

    on now Standby1:

    [oracle@kiwi701 /usr/dbvisit/standby]$ ./dbvctl -d DEV
    =============================================================
    Dbvisit Standby Database Technology (8.0.14.19186) (pid 10672)
    dbvctl started on kiwi701: Tue Jun 20 14:44:20 2017
    =============================================================


    >>> Applying Log file(s) from kiwi702 to DEV on kiwi701:

        thread 1 sequence 61 (1_61_939821488.arc)
        Last applied log(s):
        thread 1 sequence 61

        Next SCN required for recovery 4245256 generated at 2017-06-20:14:42:40 +12:00.
        Next required log thread 1 sequence 62

    =============================================================
    dbvctl ended on kiwi701: Tue Jun 20 14:44:33 2017
    =============================================================>/code>

     But how do you keep the link between the new Standby1 (kiwi701) and cascade standby - Standby2 (kiwi703) so send and apply of logs should still continue? Succeeding steps should help.

  2. Manually copy dbv_DEV2.env DDC file from kiwi703 to kiwi701 (Standby1). Edit DEV2 DDC file and set SOURCE=kiwi701 which was originally kiwi702. Make sure to keep parameter CASCADE=Y. Sync DEV2 DDC files between kiwi701 and kiwi703 by running below command. 
    [oracle@kiwi701 /usr/dbvisit/standby]$ ./dbvctl -d DEV2 -c
    =============================================================
    Dbvisit Standby Database Technology (8.0.14.19186) (pid 10319)
    dbvctl started on kiwi701: Tue Jun 20 14:35:09 2017
    =============================================================

    >>> Dbvisit Standby configuration copied to kiwi703...

    =============================================================
    dbvctl ended on kiwi701: Tue Jun 20 14:35:10 2017
    =============================================================
  3. On kiwi701, try sending logs to Standby2 (kiwi703) using DEV2 DDC like below.

    on now Standby1:

    [oracle@kiwi701 /usr/dbvisit/standby]$ ./dbvctl -d DEV2
    =============================================================
    Dbvisit Standby Database Technology (8.0.14.19186) (pid 10399)
    dbvctl started on kiwi701: Tue Jun 20 14:41:44 2017
    =============================================================

    >>> Obtaining information from standby database (RUN_INSPECT=Y)... done
    Note FORCE_LOGGING is disabled in the primary database.
    >>> Sending heartbeat message... skipped

    >>> Transferring Log file(s) from DEV on kiwi701 to kiwi703 for thread 1:


    Dbvisit Standby terminated...
    Error Code: 419
    Cannot locate log /u01/app/oracle/dbvisit_arch/DEV/1_51_939821488.arc

     If it errors due to a missing log, try to resend the required log from the new Primary (kiwi702) using the command dbvctl -d <DDC> -r <seq#> -t <thread#> if the archive log exists. Another option would be to manually ship the required archive log from ARCHSOURCE of new primary to ARCHDEST of now Standby1.

     [oracle@kiwi702 /u01/app/oracle/dbvisit_arch/DEV]$ ls -lrt *51*
    
-rwx------ 1 oracle oinstall 4518400 Jun 14 22:59 1_51_939821488.arc

     Using scp I copied logs seq 51 to 55.

    [oracle@kiwi702 /u01/app/oracle/dbvisit_arch/DEV]$ scp 1_51_939821488.arc oracle@kiwi701:/u01/app/oracle/dbvisit_arch/DEV
    oracle@kiwi701's password:
    1_51_939821488.arc

     Then apply logs should be successful from here.

     [oracle@kiwi701 /usr/dbvisit/standby]$ ./dbvctl -d DEV2
=============================================================
    Dbvisit Standby Database Technology (8.0.14.19186) (pid 14749)
    dbvctl started on kiwi701: Tue Jun 20 15:59:00 2017
    =============================================================

    >>> Obtaining information from standby database (RUN_INSPECT=Y)... done
    Note FORCE_LOGGING is disabled in the primary database.

    >>> Transferring Log file(s) from DEV on kiwi701 to kiwi703 for thread 1:

        thread 1 sequence 53 (1_53_939821488.arc)
        thread 1 sequence 54 (1_54_939821488.arc)
        thread 1 sequence 55 (1_55_939821488.arc)
        thread 1 sequence 56 (1_56_939821488.arc)
        thread 1 sequence 57 (1_57_939821488.arc)
        thread 1 sequence 58 (1_58_939821488.arc)
        thread 1 sequence 59 (1_59_939821488.arc)
        thread 1 sequence 60 (1_60_939821488.arc)
        thread 1 sequence 61 (1_61_939821488.arc)
        thread 1 sequence 62 (1_62_939821488.arc)

    =============================================================
    dbvctl ended on kiwi701: Tue Jun 20 15:59:16 2017
    =============================================================
  4. Notice that I have performed Step3 via command line. If there is a need to keep Cascade Standby working in this kind of setup (meaning you are not planning to switch back kiwi701 and kiwi702 anytime soon) and you want to make use of Central GUI Console, then these steps needs to be performed.
    • Import the DDC (dbv_DEV2.env) file created at Step2 which should now has SOURCE=kiwi701.
    • Under Database Actions, you should be able to see the imported DEV2 DDC file.
    • Dbvisit should run as per normal between Standby1 (kiwi701) and Cascade Standby (kiwi703).

 

OPTION 2 - Setting CASCADE=N

  1. After a successful GS between kiwi701 and kiwi702, and you preferred the new primary (kiwi702) to ship logs to kiwi703, another way to do it is to edit the DDC and set CASCADE=N.
  2. Ship logs from new primary (kiwi702) to Standby2 (kiwi703).
  3. Run dbvisit as per normal on kiwi703 to apply logs.
  4. In the event that Step2 failed due to a missing log, then it is necessary to run Synchronise Standby from Central Console or run dbvctl -d <DDC> --sync if using command line.
 
Have more questions? Submit a request

Comments