topic Re: Monitoring Rdb replication in Operating System - OpenVMS

Monitoring Rdb replication

labadie_1 — Wed, 28 Sep 2005 03:53:33 GMT

Hello

This is more Rdb than purely Vms, but I guess some regular posters have Rdb and may know the answer.

I have setup a Rdb Hot Standby at a customer's site. It works fine.

In order to monitor that the replication is still active, I looked in the docs, but failed to find a procedure to do the job.

I ended with the following dirty hack, which may be late to detect the problem

$ !'f$ver(1)
$ set noon
$ if F$TRNLNM("wait_hot","LNM$SYSTEM",0,"SUPERVISOR",,).eqs.""
$ then
$ define/sys wait_hot "0 00:01:00.00"
$ endif
$ def tcpip$smtp_from "Admin Vms"
$ node == f$getsyi("nodename")
$ boucle:
$ pipe rmu/dump base | sea sys$pipe -
"Database is currently being replicated","Master"/match=and
$ if $severity.eq.1
$ then
$ def/group surv_hot ok
$ else
$ def/sys wait_hot "0 01:00:00.00"
$ endif
$ log = F$TRNLNM("surv_hot","LNM$GROUP",0,"SUPERVISOR",,)
$ if log.eqs.""
$ then
$ ti == f$time()
$ mail nl: dupont@dupont.com -
/subj=" replication base xx stopped on ''node' at ''ti' "
$ endif
$ wait 'F$TRNLNM("wait_hot","LNM$SYSTEM",0,"SUPERVISOR",,)
$ deas/group surv_hot
$ goto boucle
$ exit

I then thought about having all Rdb Hot standby messages go to OPERn, and use a program like opcom_catcher to intercept that.

I think there must be a much better way ?

Regards

Gérard

Re: Monitoring Rdb replication

Willem Grooters — Wed, 28 Sep 2005 05:32:18 GMT

It's more general than Rdb ...

I've had a similar situation, but with Oracle on TRU64. Each hour, a job was run to cycle the logfile, copy all closed logfiles to a safe location (for backup) and to the remote system, where another job, running 20 minutes later, would integrate these into the standby database.

For RdB I could thing of using JCC's Logminer - where all committed transactions can immediately be stored in the standby database, so it will be up-to-date to the second.

Re: Monitoring Rdb replication

Karl Rohwedder — Wed, 28 Sep 2005 06:52:12 GMT

Willem,

I think labadie is already doing that using RDB hotstandby facility and wants a tool to monitor the status of hotstandby,
whereas Logminer is a tool to extract data out of the AIJ instead of the database itself.

As far as labadie is concerned, I do not know of such a tool, sorry...

regards Kalle

Re: Monitoring Rdb replication

Willem Grooters — Thu, 29 Sep 2005 01:26:58 GMT

The extracted data can than be used to update the standby database - actually, the replication is a continuous process ;-)

Re: Monitoring Rdb replication

labadie_1 — Thu, 29 Sep 2005 06:01:58 GMT

The replication can stop for various reasons (Aij problem, remote node /network unavailable...). So I would like to know it quickly if this happens, and not learn it 2 months later :-)

I guess the Dutch Borse, for example, monitor it. I think I am not the first one to look for such a procedure :-)

Re: Monitoring Rdb replication

Willem Grooters — Thu, 29 Sep 2005 07:42:37 GMT

You need to monitor both the live and standby side (assuming it's on different machines)

I'm not familair with RdB and Oracle DBA is too long ago (and I never dug deep enough into it), so just a few wild shot (besides what I have done in the past):

* I guess that the replication are separate processes on both the live and standby database, that will end as soon as replication is finshed? Or can it be started that way?
If so, it might be an idea to check existance of the process. Have it register it's name and/or PID in a logical and use that for F$GETJPI in the monitoring process, and if the process is finished normally, have it removed the logical.
The monitoring process would just check the logical, if is exist check the PID for proces information; if still active, Ok; If non existent, it's wrong. If logical does no longer exist, it's Ok.
If applicable, the same would apply to te process integrating the data in the satndby database.

It may be that this data in some system table, so it may be an easy check (ReadOnly).

A hint I'd put anyway:
Since you use MAIL for signalling, consider messages in case of both success (just a subject line) and failure (full log). If it takes hours to run, consider intermediate messages to notify progress. In any case, no message is alarming as well.

Willem