Implications of incomplete recovery of a source database involved in replication. (4300066)

At times the source database in replication may need to undergo recovery. The reasons could be many such as server crash, user errors, etc. Such recovery can be incomplete recovery (up to a point in time, up to a SCN , etc) or a complete recovery. This solution delves on its implications.

General information.

If a source database undergoes recovery, then it needs to be a complete recovery to the most current time up to which the database was operational. If this is the case, then Shareplex will be able to resume replication from where it left off last time. If it is an incomplete recovery, then there will be inconsistency in the contents of Shareplex internal tables vis-à-vis what is highest log offset # / redo log sequence # in the database. This lack of synchronization will result in Capture process not able to gather any further changes to the source database and would require the following steps (on both source and target) to render the replication into running state once again:

1.Shutdown Shareplex.
2.Run ora_cleansp to clean up the existing replication environment.
3.Resync the target and activate afresh.
4.Restart Shareplex.

Another thing to add is that if the recovery needs to be done due to a database crash, then there is a chance that Shareplex queue may have corruption issues (since Shareplex may have been running when this happened). So, in the event that the source database was fully recovered to the most recent time, there still may be queue corruption that needs to be dealt with. In case of incomplete recovery, the queue corruption will not matter since the resolution would then involve running ora_cleansp.

Whether Shareplex queues are corrupted will only be known once Shareplex is restarted after database recovery. If the data is flowing fine from source to target after Shareplex is started on these, then there is no queue corruption. Otherwise there is a queue corruption to be dealt with. Support can then be contacted to run appropriate commands in qview utility to fix queue corruption.

The following provides information on the alternatives available if complete recovery could not be achieved on source database for any reason:

If the user does not completely recover the database to the most current time, Oracle must be instructed how far to recover. The user can perform:
Tablespace point-in-time recovery (TSPITR), which enables users to recover one or more tablespaces to a point-in-time that is different from the rest of the database.
Time-based recovery, also called point-in-time recovery (PITR), which recovers the data up to a specified point in time.
Cancel-based recovery, which recovers until the CANCEL command is issued.
Change-based recovery or log sequence recovery. If O/S commands are used, change-based recovery recovers up to a specified SCN in the redo record.