[cisco-voip] [RTMT-ALERT-CMPUB-Cluster] DBChangeNotifyFailure
Baha Akman
makman at cisco.com
Mon Feb 9 17:01:00 EST 2009
In addition to what Wes said Scott, I just want to add that this alert
is a pretty important especially when it remains active for an
extended period of time. Here is some more background on how the alert
works;
The alert relies on Database Layer Monitor (DBMON) being up running
and in short summary it is designed to proactively warn customers of
Database Change Notify issues which could lead to critical failures if
left undetected. Dbmon is responsible for setting a Performance
counter named \DB Change Notification Server\QueueDelay. This counter
starts to increment and counts the seconds since the last time a
Change Notify Message was processed. Basically if the system due to
the example reasons Wes gave stops to process Change Notify messages
we start to count. The counter value is in seconds. If the count
reaches 2 min we raise this Alert. The alert is raised once every 30
min by default.
During heavy utilization or as you have experienced an application
crashes this alert can be raised but you may not need to take any
immediate action. If the you see the alert getting raised persistently
then I would start to worry about things and inspect the Platform CLI
output "show tech notify". If you have RTMT alert central up this
Alert's In Safe range field can tell you if the system have started to
process Change Notify Messages again.
Hope this helps further understand this Alert,
--
Baha Akman
Software Q/A Engineer
Cisco Systems, Inc.
(919) 991-5628
baha at cisco.com
On Feb 9, 2009, at 4:36 PM, Voll, Scott wrote:
> I’m guessing then it had to do with MWI / AD / Exchange/ Unity. We
> had some issues that just got resolved.
>
> Thanks Wes,
>
> Scott
>
> From: Wes Sisk [mailto:wsisk at cisco.com]
> Sent: Monday, February 09, 2009 1:29 PM
> To: Voll, Scott
> Cc: Cisco VoIPoE List
> Subject: Re: [cisco-voip] [RTMT-ALERT-CMPUB-Cluster]
> DBChangeNotifyFailure
>
> If you use Extension Mobility or stare at MWI then DB change delayed
> is a concern. That means your EM login or Red light will be delayed.
>
> What can cause it?
> Clustering over the WAN
> Processes restarting (changes are held until timeout or process
> consumes off the queue again)
> High number of change notifications (MWI refresh, AD User Sync)
>
> /Wes
>
> On Monday, February 09, 2009 3:37:50 PM, Voll, Scott <Scott.Voll at wesd.org
> > wrote:
>
> What would cause the DB change to be delayed? Something to worry
> about or not? CM 6.1.2.1106
>
> I’ve only received one or two of these.
>
> Thanks
>
> Scott
>
>
> Subject: [RTMT-ALERT-CMPUB-Cluster] DBChangeNotifyFailure
>
> DBChangeNotify queue delay over 2 minutes. Current DB ChangeNotify
> queue delay (135) is over 120-sec threshold. The alert is generated
> on Mon Feb 09 10:20:34 PST 2009 on node 10.200.102.20.
>
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20090209/efc81ce6/attachment.html>
More information about the cisco-voip
mailing list