SharePlex reports errors and other abnormal conditions in the following ways.
Event Log
SharePlex reports operational errors, notices and warning conditions to the Event Log. This log provides a perpetual step-by-step record of replication activities, errors, and events. The Event Log can help you replay the sequence of events that led up to a problem.
Examples of replication events include:
Each entry in the Event Log includes:
- The date and time of the event.
- A description of the event and any related messages (error or non-error).
- The event’s process ID number, if it is associated with a SharePlex process.
To view the Event Log:
Use the show log command in sp_ctrl or open the file named event_log in the log sub-directory of the SharePlex variable-data directory.
SharePlex provides a script for unattended monitoring of this log. For more information, see Monitor events with sp_eventmon.
Note: To control the number of out-of-sync messages that Post logs when a target table is very out-of-sync, use the SP_OPO_SYNC_LOG_FREQUENCY parameter. For more information, see the SharePlex Reference Guide.
Status Database
The Status Database contains a summary of the conditions reported in the Event Log, including events that did not generate an error message or warning at the sp_ctrl user interface. This information alerts you to potential problems and helps you resolve existing ones. The Status Database may refer you to the Event Log for a more detailed explanation of a warning, notice or event.
To view the Status Database:
Use the show statusdb command in sp_ctrl or open the file in the data sub-directory of the SharePlex variable-data directory.
Error Log
When the Post process detects that source and target tables are out of synchronization, it logs the first 100 SQL statements and data for the out-of-sync transactions to an error file on the target system. You can use this log to determine the extent of the out-of-sync condition, and you can use the SQL statements to repair target tables if the condition is not too severe, after first correcting the cause of the problem.
To view the Error Log:
Open the ID_errlog.sql file in the log sub-directory of the SharePlex variable-data directory (where ID is the identifier of the SharePlex target, for example a target database).
Process logs
When a SharePlex process cannot process a record, the process not only logs the record to the Event Log, but also to its process log file. The process logs are primarily for use in debugging.
The name of a process log consists of the datasource identifier (such as the ORACLE_SID), the short name of the process (such as ocap, ord, opo, rcl), the file number, and the file extension (.log).
Examples:
Capture: ora10_ocap02.log
Read: ora10_ord01.log
Post: ora10_opo03.log
Reconcile: ora10_rcl01.log
The aging of old log files is performed in a circular pattern. The numbering begins with 01 and ends with 03. Up to three logs can exist at any time, including the current one. When all three logs are full (50 MB), the process starts overwriting them, beginning with the oldest one.
To view a process log
Open the file in the log sub-directory of the SharePlex variable-data directory.
Activation log
When you activate a configuration, it generates a log.
To view the activation log
Open the file named SID_oconf##.log in the log sub-directory of the SharePlex variable data directory.
Compare/repair log
The compare and repair commands log errors, messages and warnings to a log. For more information about these logs, see the compare commands in the SharePlex Reference Guide.
The information commands in sp_ctrl help you monitor different aspects of replication. Issue them frequently to:
- Monitor for out-of-sync tables.
- Verify that replication processes are running.
- View the number of replicated messages in the queues.
- View the Event Log to view warnings, errors and other notifications.
- View process statistics that are helpful for tuning and problem solving.
- Detect tables or operations that are slowing down the replication process.
List of information commands
|
append status |
3 |
Displays status and results of the append using and append commands. |
|
copy status |
3 |
Displays status and results of the copy using and copy commands. |
|
compare status |
3 |
Displays the status and results of the compare using and compare commands. |
|
lstatus |
3 |
Displays detailed information about the state of SharePlex replication. |
|
job status |
3 |
Displays current status and history for append, compare, copy and repair commands. |
|
orainfo |
3 |
Displays the Oracle database information. |
|
qstatus |
3 |
Displays the state of the capture, export and post queues. |
|
repair status |
2 |
Disaplys the status and results of the repair and repair using commands. |
|
report |
3 |
Displays append, compare, copy and/or repair history for a table. |
|
show |
3 |
Displays the source and destination of the data being processed by each replication process on a system, and displays the status of each process. |
|
show capture |
3 |
Displays brief or detailed statistics for the Capture process for use in tuning and problem solving. |
|
show config |
3 |
Displays properties of the active configuration. |
|
show export |
3 |
Displays the number of messages sent to the target system(s). |
|
show import |
3 |
Displays the number of messages received from the source system(s). |
|
show log |
3 |
Displays the Even Log, Command Log, Verify Log, Trace Log, or a process log. |
|
show post |
3 |
Displays brief or detailed statistics for the Post process for use in tuning and problem solving. |
|
show read |
3 |
Displays brief or detailed statistics for the Read process for use in tuning and problem solving. |
|
show sql |
3 |
Displays the current or last SQL statement processed by the Post process. |
|
show statusdb |
3 |
Displays the Status Database, which contains records of important replication events. |
|
show sync |
3 |
Displays information about out-of-sync conditions. |
|
status |
3 |
Displays an overview of the state of SharePlex replication. |
See the SharePlex Reference Guide for details about these commads.
Run Monitor Scripts on Unix or Linux
The SharePlex monitoring scripts notify you of events and conditions that can adversely affect replication on Unix or Linux systems. These scripts provide a monitoring mechanism without the need for frequent status checks through sp_ctrl. They can be run independently or through scheduled jobs.
SharePlex provides the following scripts:
- sp_eventmon monitors the SharePlex Event Log and reports errors that you specify in a special file.
- sp_logmon monitors how well Capture is keeping pace with the changes entering the redo logs. If Capture loses pace by a specified number of logs, sp_logmon alerts you before the logs wrap so that you can take corrective action. (applicable only for Oracle source)
- sp_ps monitors the SharePlex processes and notifies you if one or more are stopped so that you can correct the problem before the logs wrap or the queues exceed available disk space.
- sp_qstatmon monitors the status of the SharePlex queues and sends a warning if the backlog exceeds a threshold (limit) that you define. This enables you to take corrective action before the queues exceed available disk space and replication is adversely affected.
Important!
- These scripts run on Unix or Linux systems only.
- The monitoring scripts are overwritten with new scripts during patches and upgrades of SharePlex. Before you install the patch or upgrade, rename your existing scripts so that your customizing is retained. After applying the patches, update the new scripts with your customizing. Do not rename the existing scripts to replace the updated scripts, or you could lose important improvements or fixes.
|
Requirements for using the monitoring scripts
- These scripts must be run in the ksh shell.
-
All monitoring scripts must remain in the directory where they were installed. All but sp_ps are in the .app-modules directory of the SharePlex installation directory. The sp_ps script is in the util directory of the installation directory.
- The scripts must be customized to reflect your environment, such as the type of e-mail or the paging available.
-
To use the monitoring scripts, start sp_cop with the -uname name option, where name can be an identifier of your choice. Suggestions are:
- SharePlex must be running prior to executing a monitoring script.
-
Verify the ORACLE_HOME (the path to the ORACLE_HOME directory) for each Oracle instance being monitored. (only for Oracle source)
- The monitoring scripts make use of sp_ctrl commands. Before you use the scripts, make a link in the util sub-directory to the sp_ctrl binary in the bin sub-directory of the SharePlex product directory. Do not copy the binary itself, because that makes it difficult to maintain patches to sp_ctrl.
-
Users of the monitoring utilities must have the following rights:
- Local access to sp_ctrl and permission to run the script on the system on which the sp_cop to be monitored is running.
- Korn (ksh) shell access and ps permission from the Unix or Linux command line.
- Read, write and execute permissions to the directory where the scripts reside.
- The permission on the iwgrep utility must be 755.
- The monitoring utilities use the mailx program to send e-mail notifications. Before using a script, make sure mailx is configured to send e-mail on all systems where the monitoring scripts will be deployed.
- Paging requires that your service provider supports receiving e-mails on your paging device.
- To kill any of the processes generated by these scripts, use the kill -9 command. The kill command alone does not kill all of the processes.
The sp_logmon monitoring script helps prevent situations where you must resynchronize your data because the Oracle redo logs wrapped before Capture was finished reading them. It monitors the redo log group to which Oracle currently is writing and determines which log SharePlex is reading.
If Capture loses pace by a specified number of logs, sp_logmon generates a warning in the logmon.log file and in an e-mail message, if that option is enabled. This gives you time to correct the cause of the delay and restore the archive logs, if necessary.
Prepare to run sp_logmon
Before running the script, perform the following tasks.
Satisfy requirements
See Requirements for using the monitoring scripts before you use this script.
Note: The script must be run in the ksh shell.
Define email addresses
To use the e-mail notification feature, define the e-mail address(es) in the script before running it.
- Open the script in the app-modules directory of the SharePlex product directory.
-
Add any number of address strings after the MailUserName= variable. Use the full e-mail and/or pager address. Separate multiple entries with a comma, as shown in the following example:
MailUserName=scott@company.com,12345678910@pageservice.com
Important! If the person modifying the script is someone other than a SharePlex user, he or she needs to have these Oracle privileges:
- CONNECT privileges
- SELECT privileges for the V$LOG table
- SELECT privileges for the SharePlex internal tables
|
Run sp_logmon
Run the script from the util sub-directory of the SharePlex product directory, not from app-modules. When you run it from the util directory, you actually make a soft link that runs a utility which first sets up the correct environment before running the script itself.
Syntax:
nohup sp_logmon -p port -t interval -l integer [-m ] [/dev/null] &
Table 6: Required arguments
| nohup sp_logmon |
Directs the script to continue running in the background if the user logs out. This ensures continuous monitoring. The sp_logmon component runs the script. |
| -p port |
Sets the port number for the instance of sp_cop that you are monitoring. You can monitor different SharePlex instances by running sp_logmon for each one, using different values for this argument. |
| -t interval |
Sets the time interval between scans in seconds. The value can be any positive integer. |
| -l integer |
Sets the maximum permissible number of redo logs between where Oracle is writing and where Capture is reading. This value triggers the warning generated by sp_logmon. Valid values are positive integers from 1 to the number of redo logs in the group. |
| & |
Runs the script in the background. |
Table 7: Optional arguments
| /dev/null |
Redirects the notification output to the /dev/null device on the local system so that the monitoring process continues to run in the background and generate output. To have the output appear on screen, omit this argument. |
| -m |
Enables the e-mail/paging option. Without this parameter, sp_logmon only logs errors to the log file. |
