Replication Alert Monitor: Monitoring Management

Exclusive offer: get 50% off this eBook here
IBM InfoSphere Replication Server and Data Event Publisher

IBM InfoSphere Replication Server and Data Event Publisher — Save 50%

Design, implement, and monitor a successful Q replication and Event Publishing project with IBM InfoSphere Replication Server and Data Event Publisher using this book and eBook

£22.99    £11.50
by Pav Kumar-Chatterjee | November 2010 | Enterprise Articles IBM

We can use the Replication Alert Monitor (RAM) to monitor the state of our replication environment. The Replication Alert Monitor is a program, which comes bundled with the replication code which checks the status of various replication objects and reports on these.

In this article by Pav Kumar-Chatterjee, author of IBM InfoSphere Replication Server and Data Event Publisher, we will cover the following:

  • Checking which monitors are active
  • Changing or reinitializing a monitor
  • Stopping a monitor
  • Suspending or resuming a monitor

 

IBM InfoSphere Replication Server and Data Event Publisher

IBM InfoSphere Replication Server and Data Event Publisher

Design, implement, and monitor a successful Q replication and Event Publishing project

  • Covers the toolsets needed to implement a successful Q replication project
  • Aimed at the Linux, Unix, and Windows operating systems, with many concepts common to z/OS as well
  • A chapter dedicated exclusively to WebSphere MQ for the DB2 DBA
  • Detailed step-by-step instructions for 13 Q replication scenarios with troubleshooting and monitoring tips
  • Written in a conversational and easy to follow manner

 

Appendix 

        Read more about this book      

(For more resources on IBM, see here.)

We use the ASNMCMD command to manage a running RAM monitor.

When we issue the asnmcmd command, we need to specify:

  • The monitor server name
  • The monitor name

And then one of the following keywords:

chgparms <parameters>, reinit, status, stop, qryparms, suspend, resume.

Where <parameters> can be:

monitor_interval=<n>, autoprune= [yn], alert_prune_limit=<n>, trace_limit=<n>, max_notifications_per_alert=<n>, max_notifications_minutes=<n>|

We can issue this command from a different screen from which the monitor was started.

Checking which monitors are active

To check which monitors are active, we can use the ASNMCMD command with the STATUS parameter. So to check the status of the monac1 monitor on mondb, we would issue:

$ asnmcmd MONITOR_SERVER=mondb MONITOR_QUAL=monac1 STATUS
ASN0600I "AsnMcmd" : "" : "Initial" : Program "asnmcmd 9.1.0" is
starting.
ASN0520I "AsnMcmd" : "MONAC1" : "Initial" : The STATUS command
response: "HoldLThread" thread is in the "is resting" state.
ASN0520I "AsnMcmd" : "MONAC1" : "Initial" : The STATUS command
response: "AdminThread" thread is in the "is resting" state.
ASN0520I "AsnMcmd" : "MONAC1" : "Initial" : The STATUS command
response: "WorkerThread" thread is in the "is resting" state.

If there is nothing running, then we get the following messages:

ASN0600I "AsnMcmd" : "" : "Initial" : Program "asnmcmd 9.1.0" is
starting.
ASN0506E "AsnMcmd" : "ASN" : "Initial" : The command was not
processed. The "Monitor" program is presumed down.

Note that there is a slight delay of a few seconds between the ASN0600I message and the ASN0506E message.

We can check when a monitor last ran using the following query:

$ db2 "SELECT SUBSTR(monitor_qual,1,10) AS monqual, last_monitor_time,
start_monitor_time, end_monitor_time, lastrun, lastsuccess, status FROM
asn.ibmsnap_monservers"
MONQUAL LAST_MONITOR_TIME START_MONITOR_TIME
MONAC1 2007-03-16-10.18.57.750000 2007-03-16-10.18.57.750000
END_MONITOR_TIME
2007-03-16-10.18.59.765000
LASTRUN LASTSUCCESS STATUS
2007-03-16-10.18.57.750000 2007-03-16-10.18.57.750000 0

Changing or reinitializing a monitor

If we change any of the following while the monitor is running such as contact information, alert conditions, or parameter values:

$ asnmcmd MONITOR_SERVER=mondb MONITOR_QUAL=monac1 CHGPARMS
MONITOR_INTERVAL=10

Then we do not have to stop and start the monitor, we can just reinitialize it as follows:

$ asnmcmd MONITOR_SERVER=mondb MONITOR_QUAL=monac1 REINIT

Stopping a monitor

To stop a monitor called monac1, we would issue the following command:

$ asnmcmd MONITOR_SERVER=mondb MONITOR_QUAL=monac1 STOP

Suspending or resuming a monitor

We cannot suspend a monitor from the Replication Center, we can only use ASNCLP scripts.

We can stop checking Q Capture and Q Apply for all defined alert conditions using the ASNMCMD SUSPEND command. When we want to resume monitoring again, then we issue the ASNMCMD RESUME command. Note that using the ANSMCMD command is an all or nothing approach. The SUSPEND option will suspend all monitoring qualifiers.

So what happens if we just want to suspend monitoring one monitored sever (DB2A or DB2B)? In this case, we would have to create a monitor suspension. We can suspend a monitor once only or on a repeatable basis. If we want to suspend a monitor on a repeatable basis, then it's best to first create a suspension template and then create a monitor suspension. If we want to suspend a monitor server once only, then we just need to create a monitor suspension.

All dates and times for monitor suspensions are based on the clock at the system where the monitor is running (MONDB). The time format is HH:MM:SS and the date format is YYYY-MM-DD.

The ASNCLP command to create a monitor suspension template is:

CREATE MONITOR SUSPENSION TEMPLATE <template_name>
START TIME <starting_time>
REPEATS occ-clause

Where occ_clause can be:

DAILY FOR DURATION <n> [HOURS | MINUTES]

Or:

WEEKLY DAY OF WEEK <day>
FOR DURATION <n> [HOURS/MINUTES/DAYS]

Where <day> can be Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, or Saturday.

The ASNCLP command to create a monitor suspension is:

CREATE MONITOR SUSPENSION <name>
[FOR SERVER <server_name> | ALIAS <server_alias>]
STARTING DATE <date>
[USING TEMPLATE <template_name> | STARTING TIME <starting_time>]
ENDING DATE <date>
ENDING TIME <ending_time>

So when should we use templates? We should use them:

  • If we want to suspend more than one monitor at the same date or time.
  • If we want to suspend a monitor on anything but a daily basis. Note that, we can specify a day of week when we create a monitor suspension template, which is not possible in the monitor suspension definition.

There are eight ASNCLP commands which deal with monitor suspensions:

ASNCLP command: Description:
LIST MONITOR SUSPENSION Generates a list of suspensions on a monitor control server.
ALTER MONITOR SUSPENSION Allows us to change the following properties of a monitor suspension:
• The template that is used
• The start or end date for using a template
• The start or end date for suspending the monitor program one time
DROP MONITOR SUSPENSION Deletes a monitor suspension from the monitor control tables.
LIST MONITOR SUSPENSION TEMPLATE Generates a list of monitor suspension templates on a monitor control server.
ALTER MONITOR SUSPENSION TEMPLATE Allows us to change the frequency and length of monitor suspensions as defined in a suspension template.
DROP MONITOR SUSPENSION TEMPLATE Deletes a monitor suspension template from the monitor control tables.
CREATE MONITOR SUSPENSION TEMPLATE Creates a monitor suspension template.
CREATE MONITOR SUSPENSION Creates a monitor suspension.

Even though we want to monitor Q replication, we need to specify SQL replication in the ASNCLP SESSION line.

So let's look at the ASNCLP command to create a monitor suspension template called LUNCH which starts daily at 12:00 and lasts for one hour:

ASNCLP SESSION SET TO SQL REPLICATION;
SET RUN SCRIPT NOW STOP ON SQL ERROR ON;
SET SERVER MONITOR TO DB mondb;
CREATE MONITOR SUSPENSION TEMPLATE lunch
START TIME 12:00:00
REPEATS DAILY
FOR DURATION 1 HOURS;

In the preceding command, we have not specified a server on which to apply the suspension—we have only defined the monitor server where to store the metadata. We have also not specified a start and end date—only a start and end time.

Once we have created a monitor suspension template, we can define a monitor suspension for a specific server (that is, source or target) and a specific date range, which uses the template we defined previously.

ASNCLP SESSION SET TO SQL REPLICATION;
SET RUN SCRIPT NOW STOP ON SQL ERROR ON;
SET SERVER MONITOR TO DB mondb;
SET SERVER TARGET TO DB db2b;
CREATE MONITOR SUSPENSION NAME s1
FOR SERVER db2b
STARTING DATE 2007-03-20
USING TEMPLATE lunch
ENDING DATE 2007-12-31;

In the above monitor suspension code, we do not have to specify a time value, because the time value is specified in the template definition. Note that now we have to specify a server for the template to work against.

We can also define a monitor suspension without making reference to a template by specifying all the information that we need (this would be the once only processing model):

CREATE MONITOR SUSPENSION NAME s2
FOR SERVER db2a
STARTING DATE 2007-03-20
STARTING TIME 12:00:00
ENDING DATE 2007-12-31
ENDING TIME 13:00:00

In the above monitor suspension definition we have not specified a template, so we have included the start and end dates and times.

We can list our monitor suspension templates and monitor suspensions using the following ASNCLP command:

ASNCLP SESSION SET TO SQL REPLICATION;
SET RUN SCRIPT NOW STOP ON SQL ERROR ON;
SET SERVER MONITOR TO DB mondb;
LIST MONITOR SUSPENSION TEMPLATE;
LIST MONITOR SUSPENSION;

This produces the following output:

====
CMD: LIST MONITOR SUSPENSION TEMPLATE;
====
TEMPLATE NAME START TIME FREQUENCY DURATION UNITS
------------------ ---------- --------- -------- -------
LUNCH 12:00:00 SUNDAY 1.0 HOURS
1 Template(s) found.
====
CMD: LIST MONITOR SUSPENSION;
====
SUSPENSION NAME SERVER NAME TEMPLATE NAME FREQUENCY
DURATION
------------------ ------------------ ------------------ ---------
S1 TARGET LUNCH SUNDAY
1.0
SUSPENDUNITS FIRST SUSPENSION STOP
-------- ------- ------------------- -------------------
HOURS 2007-03-20-12:00:00 2007-12-31-00:00:00
1 Suspension(s) found.

We can see the monitor suspension template called LUNCH, which we created and the monitor suspension S1.

We can alter a monitor suspension template by using the ASNCLP command ALTER MONITOR SUSPENSION. Suppose we want to change the suspension day from Sunday to Monday, then the ASNCLP command would be:

ASNCLP SESSION SET TO SQL REPLICATION;
SET RUN SCRIPT NOW STOP ON SQL ERROR ON;
SET SERVER MONITOR TO DB mondb;
ALTER MONITOR SUSPENSION TEMPLATE lunch;
LIST MONITOR SUSPENSION TEMPLATE;

To drop a monitor suspension, we would use the DROP MONITOR SUSPENSION ASNCLP command:

ASNCLP SESSION SET TO SQL REPLICATION;
SET RUN SCRIPT NOW STOP ON SQL ERROR ON;
SET SERVER MONITOR TO DB mondb;
SET SERVER TARGET TO DB db2b;
DROP MONITOR SUSPENSION s1;

Dropping a monitor suspension involves running the following SQL:

DELETE FROM ASN.IBMSNAP_SUSPENDS WHERE SUSPENSION_NAME = 'S1'

To drop a monitor suspension template, we would use the DROP MONITOR SUSPENSION TEMPLATE ASNCLP command:

ASNCLP SESSION SET TO SQL REPLICATION;
SET RUN SCRIPT NOW STOP ON SQL ERROR ON;
SET SERVER MONITOR TO DB mondb;
DROP MONITOR SUSPENSION TEMPLATE lunch;

Dropping a monitor suspension template involves running the following SQL:

DELETE FROM ASN.IBMSNAP_TEMPLATES WHERE TEMPLATE_NAME = 'LUNCH'

So let's look at an example in a bidirectional scenario as shown in the following diagram:

In this example, we have created four monitors to monitor Q Capture and Q Apply on each of the two servers. The monitor_qual are MONAC1, MONAA1, MONBA1, and MONBC1. The monitor_server is MONDB.

If we want to perform maintenance on the DB2B database every Sunday afternoon at 16:00 for one hour, we would create a monitor suspension template as follows:

ASNCLP SESSION SET TO SQL REPLICATION;
SET RUN SCRIPT NOW STOP ON SQL ERROR ON;

SET SERVER MONITOR TO DB mondb;

CREATE MONITOR SUSPENSION TEMPLATE tmaintbaft
START TIME 16:00:00
REPEATS WEEKLY DAY OF WEEK SUNDAY
FOR DURATION 1 HOURS;

And then, we would create a monitor suspension as follows:

ASNCLP SESSION SET TO SQL REPLICATION;
SET RUN SCRIPT NOW STOP ON SQL ERROR ON;
SET SERVER MONITOR TO DB mondb;
SET SERVER TARGET TO DB db2b;
CREATE MONITOR SUSPENSION NAME maintbaft
FOR SERVER DB2B
STARTING DATE 2007-03-20
USING TEMPLATE tmaintbaft
ENDING DATE 2007-12-31;

The ibmsnap_alerts table

The IBMSNAP_ALERTS table contains a record of all the alerts issued by the Replication Alert Monitor. The table records what alert condition occurred, at which server, and when they were detected.

Some common errors in the ALERT_CODE column are:

ASN5153W MONITOR "<monitor_qualifier>". The latency exceeds
the threshold value for program "<program_name>". The server
is "<server_name>". The schema is "<schema>". The latency is
"<latency>" seconds. The threshold is "<threshold>" seconds.

ASN5157W MONITOR "<monitor_qualifier>". The Q subscription
"<subscription_name>" is inactive. The server is "<server_name>".
The schema is "<schema>". State information: "<stateinfo>".

Summary

In this article we described the Replication Alert Monitor and how to monitor the Q replication setup.


Further resources on this subject:


IBM InfoSphere Replication Server and Data Event Publisher Design, implement, and monitor a successful Q replication and Event Publishing project with IBM InfoSphere Replication Server and Data Event Publisher using this book and eBook
Published: August 2010
eBook Price: £22.99
Book Price: £36.99
See more
Select your format and quantity:

About the Author :


Pav Kumar-Chatterjee

Pav Kumar-Chatterjee (Eur Ing, CENG, MBCS) has been involved in DB2 support on the mainframe platform since 1991, and on midrange platforms since 2000. Before joining IBM he worked as a database administrator in the airline industry as well as various financial institutions in the UK and Europe. He has held various positions during his time at IBM, including in the Software Business Services team and the global BetaWorks organization. His current position is a DB2 technical specialist in the Software Business. He was involved with Information Integrator (the forerunner of Replication Server) since its inception, and has helped numerous customers design and implement Q replication solutions, as well as speaking about Q replication at various conferences.
Pav Kumar-Chatterjee has co-authored the “DB2 pureXML Cookbook” (978-0-13-815047-1) published in August 2009.

Books From Packt


IBM Lotus Notes 8.5 User Guide
IBM Lotus Notes 8.5 User Guide

Application Development for IBM WebSphere Process Server 7 and Enterprise Service Bus 7
Application Development for IBM WebSphere Process Server 7 and Enterprise Service Bus 7

IBM Cognos 8 Report Studio Cookbook
IBM Cognos 8 Report Studio Cookbook

IBM Lotus Notes and Domino 8.5.1
IBM Lotus Notes and Domino 8.5.1

IBM WebSphere eXtreme Scale 6
IBM WebSphere eXtreme Scale 6

WebSphere Application Server 7.0 Administration Guide
WebSphere Application Server 7.0 Administration Guide

IBM Cognos 8 Planning
IBM Cognos 8 Planning

Domino 7 Lotus Notes Application Development
Domino 7 Lotus Notes Application Development


Code Download and Errata
Packt Anytime, Anywhere
Register Books
Print Upgrades
eBook Downloads
Video Support
Contact Us
Awards Voting Nominations Previous Winners
Judges Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software
Resources
Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software