Versions Compared

Old Version 4

changes.mady.by.user Chris Lawless (Deactivated)

Saved on

compared with

New Version Current

changes.mady.by.user Arjen Visser

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

 IssueCause and action
1

Was the Mine process started on the Mine server?

If no, then start.

If Mine was started, but it stopped without reason, please see MINE or APPLY process stops without any reason.

To restart the Mine process, see Restarting MINE Process

2

Was the Apply process started on the Apply server?

If no, then start.

If Apply was started, but it stopped without reason, please see MINE or APPLY process stops without any reason 

3

Check the Mine log is being updated. On the Mine server, the Mine log is located in the "log" directory and the file name is similar to dbvrep_MINE_*.log. This log will be updated every few seconds. Check for error messages in the log if the file is not being updated. 

If no, then check if the dbvrep process or service is still running.
4Check the Apply log is being updated. On the Apply server, the Apply log is located in the "log" directory and the file name is similar to dbvrep_APPLY_*.log. This log will be updated every few seconds. Check for error messages in the log if the file is not being updated.If no, then check if the dbvrep process or service is still running.
5

Check that the DBRSCOMMON_HEARTBEAT is still being updated. This table is in the dbvrep schema on both the source and target systems.

The table is updated by determination of the MINE_HEARTBEAT_TIME parameter.  The parameter default is set to 10 seconds by can be set according to the needs of the customer.  Every 10 seconds the DBRSCOMMON_HEARTBEAT table would be updated with new information such as the timestamp and SCN.  

See Heartbeat table for more information and an example SQL statement that can be used to run against the heartbeat table.

If no, then check the Mine or Apply log for errors.
6Check that the dbvrep process or service is still running

If not, then check if there is enough memory for the process to run.

Some OS may terminate processes without warning if they consume heavy resources. Check the OS logs for notification of this.

7Check if there are any current conflicts. This may pause the replication.See Viewing the conflicts
8Has the replication slowed down?

Causes of slowdown:

  • Conflicts cause the replication to slow down because all parallel processes are paused in order for the conflict to be resolved. Even if automatic conflict handlers are in place, the replication may not pause, but will slow down due to automatic conflict handlers having to process the conflict in serial mode. Determine the cause of the conflict and avoid conflicts.
  • BLOBS and CLOBS. Replicating these datatypes require more processing than other data types.
  • Not having primary keys or unique keys on source tables. This requires more elaborate predicates on the SQL being run against the Apply database. If possible ensure primary keys or unique keys on the source database.
  • Not having the correct indexes on the Apply database. Performance analysis on the Apply database may indicate that the SQL being run by the Apply process is not efficient. Adding the correct indexes may increase the performance.
  • CTAS. Create Table As Select can also often cause a temporary slowdown. Replicating these statements require more processing.  When there are CTAS, special plog files will be created. These plog files can be identified because the plog name will contain part of the table name of the CTAS.
  • Are the disks suffering from IO bottleneck? The disks containing the plogs require fast IO disks to ensure maximum performance. If the disks that contain the plogs suffer from IO performance issues, then the replication performance will also suffer.
  • Run profiling to see where the slowdown is: Dbvisit Replicate Profile Performance Statistics
  • For other tips and trick please see Optimizing Dbvisit Replicate and improving performance