[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