Locks on Apply

If there are database locks on the Apply database this will slow down the replication.

The locks will be visible in the Apply log.

The steps to identifying the locks are and to resolve them are:

1. Run the List transactions command in the Dbvisit Replicate command console several times and see if the same transaction keeps showing up. 

2. Run the following SQL on the target to see which SQL it is currently waiting on:

select
    sid,
    sql_text 
from
    v$session s,
    v$sql q 
where
    sid in
    (select
       sid
    from
       v$session
   where
       state in ('WAITING')
   and
       wait_class != 'Idle'
   and 
       event='enq: TX - row lock contention'
   and 
      (q.sql_id = s.sql_id or q.sql_id = s.prev_sql_id));

3. Find our which statement is the blocking session by running the following SQL:

select
blocking_session,
sid, serial#,
wait_class,
seconds_in_wait 
from
v$session 
where
blocking_session is not NULL
order by
blocking_session;

4. The transaction causing the lock can sometimes be committed or rolled back to ensure the continuation of the replication. This can be with the following commands:

When the Transaction ID of the statement is found, then the record can be committed with:

dbvrep> apply commit transaction xxx

This will cause the statement waiting for the lock to proceed as the locking statement is now committed on the target database.

The transaction can also be rolled back with command:

dbvrep> apply rollback transaction xxx

The user showing the locks on the Apply side is ALWAYS the dbvrep* user, even though the SQL will be for another user. This is because Dbvisit Replicate connects as the dbvrep user to process the SQL.

* The default is dbvrep, but this can different if a different schema name is chosen during configuration of Dbvisit Replicate.