General housekeeping involving log directory of Shareplex.
The log subdirectory of Shareplex variable directory (also called vardir and is pointed to by the environment variable SP_SYS_VARDIR) contains logs for various Shareplex processes. If a periodic housekeeping is not done and the old logs are not removed, it can create space issues leading to other problems like slowness, queue corruption, etc. Yet one must be careful and only remove the logs which are not necessary and preserve the ones that will need to be referenced for recent events.
A Shareplex log can be periodically removed so that the space is manageable. Moreover, as the time goes by the older log entries lose their significance. To remove a log, stop either the Shareplex or the respective process associated with the log, and then rename the existing log(s) to something else before restarting Shareplex or the process. Henceforth the new log(s) will be generated and one can get rid of the older log at ones leisure after analyzing it as needed.
Sometimes Shareplex or its process runs in debug mode on instructions of Support or for one's own investigation needs (for example, slow Post investigation) and this can result in substantial increase in logging activity. Once the investigation is complete, debug will need to be unset,otherwise not only may this cause space issues (depending on whether the parameter to increase the # of log files was also invoked) but may also consume resources by logging too much information when there is no further need. To unset the debug and remove the respective logs, the steps involved would be:
a. On sp_ctrl unset the debug by:
sp_ctrl>reset param <parameter name>
b. Shutdown Shareplex or stop the respective process
c. Rename the existing log(s) to something else and remove them later as needed.
d. Restart Shareplex or the process so that new logs will be generated without logging debug information.
The logs generated by Shareplex fall into the following category:
1.General: They are not process specific, or they are not dedicated to one single process. They include event_log and commands_log. They will grow indefinitely (in one direction) unless they are periodically removed. Shareplex must beshutdown to remove them. The event_log is something like an alert.log in Oracle and logs the events happening in the database. In general the logging in event_log is substantial so it should be removed periodically. There is another log named trace_log that is not just dedicated to one process but would grow if any of these processes are run in debug mode, namely sp_cop, Export and Import processes. Please refer to Solution # SOL16499 that specifically delves on the truncate command used for housekeeping of event_log and trace_log. The effect of truncate command is same as shutting down Shareplex and renaming/removing these two logs before restarting Shareplex, except that the truncate command will get rid of log entries whereas doing it manually might give one an opportunity to preserve the old log before one decides to get rid of it. And the truncate command will only work on these two logs.
2.Logs dedicated to specific processes: They include Capture logs, Read logs, and Post logs with the strings in the name ocap, ord and opo respectively. These logs are cyclically written to 3 different log files, each 50M by default so they do not need that much attention. For example, by default there are three Capture logs and are named *ocap01.log, *ocap02.log and *ocap03.log. Unless asked by Support to generate more than the three logs (by setting a special parameter for that process),donot worry about these logs. Support would normally help to remove the logs if they made Shareplex generate more than the default three logs. If in doubt check with Support on this.To remove these logs, the easiest way is to stop the respective process and rename/remove them, before restarting the process.
Another logging is done by the compare process and has the logs with the strings in the name desvr on source and declt and sql on target. The compare logs are identified by the combination of PID of the source compare process, the name of source and target tables.Command remove log compare will remove these; they can also be removed manuallyif there is no compare with this PID running at that time.
Another log to attend to in periodic log maintenance is *errlog.sql located on the target. This file can grow rapidly depending on the out of sync encountered by Post. It can be renamed/removed by either stopping the Post or shutting down Shareplex. The file is useful when investigating the reasons behind out of sync.
Besides the above logs, there is another group of log file named core.xxxx (where xxxx is a number) typically referred to as core file that is located in $SP_SYS_VARDIR/dump directory that may need attention. The core file is generated during certain conditions when a process errors out. It provides useful information for Development when investigating the cause of failure. The core files are typically very large running into tens of MB and should be removed periodically after the investigation is done.
There is another set of log files generated by copy/append on the source and target, the source is named *sync_svr* and the target log is named * sync_clt*. Every time a copy/append is run a new set of log is generated on source and target. The logs can be removed when there is no copy/append in progress and if the logs do not need to be preserved anymore. In addition to this, there is a general log named sync-launcher* on target that keeps growing whenever a copy/append is run. This log contains info about OS environment and other communications and is not table specific unlike the sync_svr and sync_clt logs.
© ALL RIGHTS RESERVED. Feedback Terms of Use Privacy Cookie Preference Center