Debug parameters are set by customer on Supports advise to troubleshoot problems associated with a Shareplex process. They write useful debug information in their respective logs or in a general log file named trace_log, depending on which process the debug is set on. For example, Capture, Read, Post or Activation have their own log files and the files have the strings *ocap*, *ord*. *opo* and *rmp* appearing in their names (where * is the wildcard character). Other processes write debug information in a file named trace_log. All these files are located in $SP_SYS_VARDIR/log sub-directory. This debug information is used by Support or Development to troubleshoot customer issues. It may be noted that even without setting of debug parameters the processes write to these respective logs but such logging activity is minimal and for the most part does not provide useful debug information.
These log files can grow quickly when a process is run in debug mode (that is, debug parameter is set for the process). For the most part the customer is instructed by mail or otherwise to correctly set and unset the debug and gather the logs for analysis. There are times when the debug is left on inadvertently. This can cause the respective process to slow down considerably, thereby impacting speed of replication. Moreover, it can also cause space issues as some debug logs are written in cyclical fashion using a default set of 3 log files (typically 50M each) so they are always limited in size whereas others like trace_log are single files that can grow indefinitely as they do not have any size constraint except those of OS.
Debug set on a Shareplex process is causing slowness and disk space issues.
If a shareplex process is running very slow or if the disk space in /vardir/log directory is filling up due to too much logging, one can probe deeper to see if there was any debug left in place inadvertently during troubleshooting. The debug parameters always start with string "SP" and have the string "DEBUG" somewhere in the name. For example:
SP_OPO_DEBUG_FLAG
SP_COP_DEBUG
SP_CNC_DEBUG
SP_QUE_DEBUG
SP_XPT_DEBUG
SP_IMP_DEBUG
Some processes allow debug to be set dynamically (live), others require them to be set after the process is bounced (restart process) and yet some other require debug to be set after the Shareplex is bounced (restart sp_cop). The sp_ctrl command "list param modified" lists all parameters that are other than the default. One can identify if any debug parameters are set by looking at the output and looking for the string "DEBUG". One can then use the following command in sp_ctrl to unset the debug and the change may be live or require a process or sp_cop bounce depending on the parameter. To unset:
sp_ctrl>reset param <parameter name>
After resetting the parameter, one may want to monitor the respective log to see if it still grows rapidly or if the growth is slight. If the rapid growth has halted, then the debug has been unset.
