Preparation for FAILOVER

ASSUMPTIONS

This reporting target replicate instance is using the primary database source to mine the realtime redo logs. It is NOT for the configuration where the standby logs are being used to apply to the target database.

Preparation for FAILOVER.

After configuring replication on SOURCE server but before starting MINE/APPLY the full configuration directory over to the target. Name of this replication was TEST1.

Tar it up first ie /home/oracle/replicate/TEST1/

$ tarcvf TEST1_files.tar TEST1/* TEST1/*/*

$ scpTEST1_files.tar <targetServer:/home/oracle/replicate/.

Then on target untar file

$ tarxvfoTEST1_files.tar

Start MINE on source server & APPLY on target server and continue normally with replication

FAILOVER /ACTIVATION OF STANDBY

* Note these directions are for Activated Standby & Target database hosted on same server. Adjust where necessary if this is not the case.

Log into activated standby server

Ensure tnsnames connecting to activated standby database on standby server, ie

$ tnsping SRCDB

After failover from activated standby, get the SCN #.

SQL> sqlplus / as sysdba

SQL> column get_system_change_number format 99999999999999

SQL> select dbms_flashback.get_system_change_number from dual;

log into DbvisitRepliateconsole & set remote interface

$ ./start-console.sh

dbvrep> set MINE.MINE_REMOTE_INTERFACE = dbvlin821.dbvisit.co.nz:7901

dbvrep> exit

Start MINE & APPLY from shell on Activated Standby/Target server (cohosted in example)

After you no longer see progress, shutdown

dbvrep> shutdown apply

dbvrep> shutdown mine -- this may hang

If processes don’t shutdown gracefully, exit out of console & do a

$ ps –ef |grep APPLY

$ kll -9 <apply_PID

$ ps –ef |grep MINE

$ kll -9 <mine_PID

RE-CONFIGURATIONin a new directory on Activated Standby Host.

For example, create a new directory for the reconfiguration, ie if original was

/home/oracle/replicate/TEST1 then

$ mkdir /home/oracle/replicate/TEST2

$ cd /home/oracle/replicate/TEST2

Run the setup wizard once again by running dbvrep to redefine the replication set

$ dbvrep

Run setup wizard but this time rather than accepting the default ‘dbvrep’ user call it something different, ie ‘dbvrep2’

After you complete the setup wizard go to the configuration file directory

$ cd config

And edit the file TEST2-setup.dbvrep

Locate the line

SET APPLY.INSTANTIATE_SCN NOW

and replace with the work NOW with the SCN you got from above, ie.

SET APPLY.INSTANTIATE_SCN 192733708

Save the file then go back to your replication main directory

$ cd ../

Run now the <DDC>-all.sh (or –all.bat) script.

Once this is done you can startup MINE & APPLY with the *.sh script(s) provided. For this example the activated standby & the replicate instance are on same server

$ ./TEST2-run-<hostname>.sh

Contents of this file are below since both activated standby & target db are on same server

$ cat TEST2-run-<hostname>.sh

EXEC="/usr/bin/dbvrep"

$EXEC --daemon --ddcfile /home/oracle/replicate/TEST2/TEST2-APPLY.ddc start APPLY

$EXEC --daemon --ddcfile /home/oracle/replicate/TEST2/TEST2-MINE.ddc start MINE

Since a FAILOVER may have left transactions inflight you may get conflicts with the message 0 rows found when investigating conflict

Dbvrep> list conflict

Information for conflict 12010007898 (current conflict):

Table: OE.ORDERS at transaction 0009.019.00003ebf at SCN 192754221

SQL text (with replaced bind values): update "OE"."ORDERS"

set "ORDER_STATUS" = 9

where (1=1)

and "ORDER_STATUS" = 0

and "ORDER_ID" = 1531029

Error: Command affected 0 row(s).

Handled as: RETRY

Resolved at: 21.05.2016 05:34:36

Resolved as: RETRIED

The only way to do this is resolve as ignore for all conflicts of this type you encounter.

If the conflicts only seem to impact 1 table, you can follow steps to unprepared/reprepare and reinstantiate the target database for this table.

The only other alternative is to reinstantantiate your target replicate instance from scratch using your activated standby as the source..