How to quickly identify if a debug is set in Shareplex environment and then unset it (4297020)

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.