-
Title
What are the implications of enabling supplemental logging after a config file is activated? -
Description
What are the implications of enabling supplemental logging after a config file is activated?
-
Resolution
Supplemental logging(available starting with Oracle 9i) greatlyimproves activation and Shareplex performance. When supplemental logging is enabled, the time-consuming processes of analyzing tables for chained rows and building a row ID map are eliminated. This can result in faster activation times. Supplemental logging is required to be enabled when using Shareplex for Oracle 10G. However, Shareplex for Oracle 9iallows activation of the config file with Oracle supplemental logging is disabled.
If a config file was activated when the supplemental logging was disabled, and subsequently the supplemental logging is enabled, the following messages whille appear in the event log:
Notice: The state of supplemental logging has been changed. Changing the state of this feature while SharePlex is running is not recommended. The command detected is: Alter database add supplemental log data [sp_ocap/2101]
event_log (60/60)
If a config file was activated when the supplemental logging was disabled, and subsequently one wants to enable supplemental logging, one needs to clean up the previous environment by running ora_cleansp on source and target, resync the target if necessary, enable supplemental logging and activate.
Likewise (this is mentioned in Shareplex Admin Guide) one cannot disable supplemental logging if the config file is already active. One needs to clean up the previous environment by running ora_cleansp on source and target, resync the target if necessary, disable supplemental logging and activate. -
Additional Information
If supplemental logging has been enabled while there is an active config in place, then prior to running ora_cleansp to clean up the existing environment and activating afresh, try salvaging the situation by activating a copy of the currently active config file. If the activation succeeds, then there may not be any need to run ora_cleansp. In brief:
1.Make a copy of the currently active config file.
2.Activate the copy.Try these steps without the need to incur downtime on the source database. If it succeeds, then there is no need to resync the target.