Steps for Re-Instantiating Replication

The below article explains the steps by steps procedure to re-instantiate replication, when its broken.

Problem Details

Problem Statement

The replication may break due to various reasons , like missing archivelog, APPLY server crash etc.. in situations where we are not able to bring up the replication, best way to move forward is to re-instantiate.

Applicable Error Code

FATAL-9087: Could not find any valid archive or online redo log 123 (thread 1). See log file whether any files were rejected. ( We are not able to restore the archivelogs since its  deleted).

Affected Versions

Any replicate versions , Provided steps for One Way Oracle-Oracle replication

Affected Platforms

Platform independent.

 

Description

We have a running replication setup, which is missing a archivelog. Below is the setup details.

  1. Setup wizard is run for schema level replication with PL/SQL replication with the same schema. Replication name is 

LIVE .while running setup wizard the schema had 2 tables with  1 procedure. Added three more tables after that and then one procedure. Below is the final list.

2. Source Schema name is VIJAY. TNS entry is ttorcl_src.

3. Target Schema name is VIJAY. TNS entry is ttorcl_trg.

4. Final list of objects in source and target.

SQL> col object_name format a20 SQL> / OBJECT_NAME OBJECT_TYPE -------------------- ------------------- RESULTS78 TABLE TABLE8_PK INDEX TABLE8 TABLE TABLE7_PK INDEX TABLE7 TABLE DEPT TABLE EMP TABLE GEN_DATA PROCEDURE CLONE PROCEDURE

Replication Status

\ Dbvisit Replicate 2.8.04_154_gf0659b1(MAX edition) - Evaluation License expires in 30 days MINE is running. Currently at plog 822 and SCN 12716026 (05/05/2017 12:05:53). APPLY is running. Currently at plog 822 and SCN 12716000 (05/05/2017 12:05:46). Progress of replication LIVE:MINE->APPLY: total/this execution -------------------------------------------------------------------------------------------------------------------------------------------- VIJAY.EMP: 100% Mine:1000/1000 Unrecov:0/0 Applied:1000/1000 Conflicts:0/0 Last:05/05/2017 11:41:52/OK VIJAY.DEPT: 100% Mine:5/5 Unrecov:0/0 Applied:5/5 Conflicts:0/0 Last:05/05/2017 11:42:20/OK VIJAY.TABLE7: 100% Mine:5837/5837 Unrecov:0/0 Applied:5837/5837 Conflicts:0/0 Last:05/05/2017 11:56:47/OK VIJAY.TABLE8: 100% Mine:5820/5820 Unrecov:0/0 Applied:5820/5820 Conflicts:0/0 Last:05/05/2017 11:56:47/OK VIJAY.RESULTS78: 100% Mine:11045/11045 Unrecov:0/0 Applied:11045/11045 Conflicts:0/0 Last:05/05/2017 11:56:47/OK --------------------------------------------------------------------------------------------------------------------------------------------

Steps Performed

Below are the steps performed to re-initialise the replication.

  1. Shutdown MINE and APPLY.

dbvrep> shutdown all Upon restart MINE will go back to redolog 821 (thread 1), going back 1 log. Upon restart APPLY will go back to plog 821, going back 1 plog. Are you sure you want to shutdown? (Yes/No) [No] Yes Dbvisit Replicate MINE process shutting down. Dbvisit Replicate APPLY process shutting down. dbvrep>

2. If you have any conflict handlers in your environment, check the below link and export the conflict handlers before running the ALL.sh script and import it later. The steps are provided in detail.

https://support.dbvisit.com/hc/en-us/articles/220612107-How-to-export-import-current-conflict-handlers-when-you-need-to-reconfigure-Replicate

3. Run the all.sh script

4. Check the Nextsteps.txt file , you can ignore steps 1 to 5 , check the network link (if you are using impdp using the network link ).

5. Run the APPLY.sh , check the file you would see all the tables pertaining to the schema , for which replication is configured. Its a good practice to truncate the target tables, but the impdp does them as well with the parameter table_exists_action=TRUNCATE.

6. Check if the target has any foreign key constraints and triggers and disable them. 

7. Start MINE and APPLY.

8. Check the console and replication is running fine.

9. The number of objects matches as well.