Server Monitoring Configurations
For effective monitoring, you can configure your servers in the following ways:
• Notify users of server errors though their e-mail accounts
• Specify automatic shutdown of the server at a maximum error count
• Monitor replication activity
• Specify message logging levels
Mail Alert Setup
Through electronic mail, servers can provide notice to the DBA or other users of any errors as they occur. The level of message logging is dependent on the Log Level flag (-LGLn) setting. For more information, see Message Logging.
Note: The e-mail notification list feature is not available on Windows.
Visual DBA:
In VIsual DBA, you set up the mail alert feature by expanding the Replication branch in the Database Object Manager and expanding the Mail Alert Users branch. For more information, see the online help topic Defining Error Mail Destinations. 
Replicator Manager:
In Replicator Manager, you set up the mail alert feature using the Mail Notification List window by adding the e-mail account for those users who require e-mail notification. For more information, see Create a Mail Notification List.
The Error Mail (-MLE) flag, which controls the sending of error messages, is set by default. If you set the No Error Mail (-NML) flag, no mail messages are sent.
Note: When a transaction (for example, an unresolved collision) cannot be transmitted to its target, it remains on the distribution queue. Because the Replicator Server retries propagation every time it rereads the queue (as when new items are queued up), multiple mail notifications are sent. Consider this when deciding whether to use the ‑MLE or -NML flags and who to include in the mail notification list.
Error Count Maximum
If the volume of errors reaches a certain point (the default is 100), the Replicator Server shuts down to maintain the integrity of the system and to allow you to troubleshoot problems. The server automatically keeps track of its error count. You can control at what point the server shuts down by specifying a number that represents the maximum error count in the Maximum Error (-EMXn) flag.
If the error count of the server reaches the maximum error count, the server is automatically shut down. Each time the server is started, the error count of the server is reset to 0. If collision resolution is set on your system, be sure to increase the error count maximum to accommodate collision errors. Each collision, even if resolved automatically, counts as an error.
To change the maximum error count at any time, use one of the following methods:
Visual DBA and Performance Monitor: Use the Performance Monitor Raise Events page. For more information, see the Raising Events at the Server Level topic in Visual DBA or Visual Performance Monitor online help.
Replicator Manager: Use the Send Database Event Window in Replicator Manager.
Replication Activity Monitoring
The status of a server is sent to the Activity page in the Visual DBA Performance Monitor window or the Replication Monitor window at server startup, shutdown, and in response to a ping operation. The ping operation returns the status of the server and its error count.
Note: It is recommended that you use the rsstatd command to display Replicator Server statistics that are cumulative from server startup. Using rsstatd does not incur dbevent overhead.
You can monitor your system more closely with the Send Notifications flag
(-MON). The -MON flag causes the servers to issue activity notifications.
(-MON). The -MON flag causes the servers to issue activity notifications.
The -MON and Send No Notifications (-NMO) flags control whether the server issues activity notifications. Every time a row is propagated to a target and every time a transaction is committed, a notification is sent (or not sent if -NMO is selected) that updates the Incoming Records, Outgoing Records, and Activity display fields in the Performance Monitor or Replication Monitor. The -MON and -NMO flags also cause the server to notify the Performance Monitor or Replication Monitor when an error occurs. The default is -MON.
Though the -NMO flag stops the server from issuing activity notifications on errors, you can ping a server to obtain its status, overriding any -NMO flag.
Message Logging
When a Replicator Server starts, it creates three log files:
replicat.log
The replicat.log file contains Replicator Server messages. This file writes its buffers after every message is logged, allowing you to see the latest logged messages in real time. Messages are appended to this file from run to run.
print.log
The print.log file contains information that normally goes to the standard output (stdout), such as error output from the DBMS Server. This file contains Replicator Server messages at its specified logging level. This file gets initialized from run to run.
Unlike replicat.log, it is possible that the print.log does not contain the latest error messages.
Note: The print.log is not created on Microsoft Windows.
commit.log
The commit.log file is the two-phase commit recovery log for the Replicator Server. This file must not be manipulated because it contains information to resolve leftover willing-to-commit transactions. If the server has been shut down cleanly and there are no willing-to-commit transactions, it is safe to delete this file. Otherwise, do not delete it. This file is initialized from run to run, unless there are incomplete two-phase commit transactions, in which case they are recovered first.
Periodically, you must shut down the servers to clean out the log files.
The Log Level (-LGL) flag controls which messages get written to the replicat.log file, while the Print Logging Level (-PTL) flag controls the messages written to the print.log. Both the -PTL and -LGL flags share various settings that indicate the message levels that are logged.
The message levels that require attention are the Level 1 error messages and the Level 3 warning messages. You are advised to set the -LGL flag to receive Level 1 through Level 3 messages.
Message Logging Levels
Message logging levels 0 through 3 are as follows.
Note: Message Levels 4 and 5 are reserved for internal use only and can be set at the request of Customer Support to troubleshoot your system.
0
SILENT
Logs no messages.
Note: The exception is DBMS Server error messages, for example, informing users of deadlock. The server continues to channel these messages to the standard output (stdout).
1
Logs ERRORS
Errors are any occurrence that causes the Replicator Server to alert you to take some action. Error messages include configuration, timeout, transmission, and fatal errors such as the inability to replicate, the issuance of an invalid database event, or the inability to complete a distributed transaction.
2
Logs ERROR and INFORMATIONAL messages
Informational messages provide normal server status information such as startup, shutdown, and the setting of flags.
3
(Default) Logs ERROR, INFORMATIONAL, and WARNING messages
Warning messages convey some information about a problem or identify an unusual situation that requires your attention, for example, an invalid startup flag in the configuration file.
Last modified date: 08/14/2024