At times customers are asked to run a process in debug mode. This solution delves on what constitutes a debug.
In general a debugger is defined as a program which runs other programs in such a way as to let one see every step of program execution. A debugger will let one stop the program while it is running, change the program or program variables, and start the program running again.
In Shareplex, the concept of a debug is slightly different. Processes are run in debug mode so as to write detailed info on every step the processes undertake during replication. This info is written in the logs which are either dedicated to the respective process (for example, the Capture process writes to logs having string *ocap* in their name), or to the general log named trace_log which caters to all processes that do not have a dedicated log (for example sp_cop, sp_xport, etc). The processes may write to their respective log files with or without debug setting. However, with debug turned on, the writing activity can be quite detailed.
The debug is set in the following manner:
sp_ctrl>set param <debug parameter name> <value of debug flag>
To unset a debug:
sp_ctrl>reset param <debug parameter name>
Some debug parameters are dynamic (live) in the sense that they are set as soon as the command is executed. Others take effect once the underlying process is bounced (stopped and restarted). Yet there are other debug that will take effect once the Shareplex is bounced. When running a Shareplex process in debug mode, care should be taken to turn off the debug once it has served its purpose of collecting the desired info in the respective debug log. The reason for this is that debug will slow down the process and certain type of debug can result in high utilization of disk space which can result in disk full situation.