CUCM 9.1.1a IDS Engine Attention alarm for CDR files

[Erick Bergquist]

Has anyone seen this error before?

Is the IDS engine preventing CDR files from being written to database or similar?

Machine Name: CUCM1

Severity: Error

App ID: Cisco Database Layer Monitor

Message: : 24120:

CUCM1: Jul 10 2013 04:00:29.233 UTC : %UC_-3-UNKNOWN_ALARM:IDSEngineAttention: %[class_id=cucm1_ccm9_1_1_20000_5--1][class_msg=CDR][specific_msg= :ATTENTION:-1:CDR: ATS and/or RIS files spooled to disk.:/var/log/active/cm/log/informix/ris/ris.g_sscm1_ccm9_1_1_20000_5.g_sscm][ClusterID=StandAloneCluster][NodeID=CUCM1]:

[Aman Soi]

Hi,

I was just checking the bugs related to the problem but could not find any.

Just to cross-check is DBReplication fine if there is PUB and SUB.

regds,

aman

[Kanes Ramasamy]

Hi All,

Has anyone managed to resolve this and if yes can you please share how it was resolved?

Thanks and Regards,

Kanes.R

[Clifford McGlamry]

I'm seeing the same error message on multiple clusters with 8.6.2-22900.  DB Replication is good. 

I'm puzzled how, if an error is unknown, is the alarm being triggered? 

[Jay Schulze]

Hello,

Did you ever find what this alert is? I've seen it in 9.1.1 as well as 9.1.2. And it's not in the definitions catalog. Doesn't seem to be impacting though.

thx

J

[vemanyam]

This can be caused due to replication issue:

++ Correct any misspelled server group names or incorrectly formatted sqlhosts entries & check dbreplication status

++ if issue found with db, perform dbreplication reset

==========================================

++ Sometimes the I/O wait time (in VMware deployment when storage is remote SAN) could cause such issues

++ Restarting Cisco Tomcat service might resolve the above issue

++ On UCS server, needs further investigation to identify firmware updates and any detected hardware component issues.

++ Also verify the SAN Connectivity, UCS & VMware issues if any 

++ Try restart the server and check

===================================

[kelvinteh15]

Hi,

Anyone have the resolution ? We are getting it intermittantly . No DB replication issue . Storage is remote SAN and we did not have any issue on the SAN.

Thanks.

[Manish Gogna]

Hi Kelvin,

Most of the cases related to this alert have been fixed by running 'utils dbreplication repair' on the node where the alert is generated. Even though you may see the replication status as 2, can you try running the above command and see if the issue still persists.

HTH

Manish

[kelvinteh15]

Hi ,

Thanks.

Since it is the production and no issue on the user end , i will not take the risk to run it . At the moment it just intermittant getting the alert . It has stop since the last 3 occur and clean for 24 hour . From the ESX , we could see there is little spike during the time we received alert .

Definately will try the db repair if it keep happening.

[Amarjeet Saini]

Hi Manish,

Thank you for suggesting the fix. We had same issue on one of the subscriber(11 server cluster). We are supporting contact center(UCCE)  with outbound dialing as well. The subscriber in question was one of our main serve talking to CVP's and PG's.

I was confident about the fix after reading your post but we ended up going to TAC as we needed a fallback plan.

TAC implemented same solution. Following are steps in sequence:

1.  Try dbreplication repair [affected server name] >> from publisher server.

2. It will take close to 1 hour for a cluster supporting approx 6000 phones. The step 1 command wil stop the alarms. However, there may still be table mismatches found by repair process.

3. If there are table mismatches found by repair process >> Next steps is to do utils dbreplication repair all >> on publisher. 

I know it looks scary.. as I was  a bit nervous to run this while agents were taking calls in UCCE environment(24x7) but we needed to fix the mismatch.

4. It took another 1 hour but it fixed the table mismatches and the alarms. No more alarms received and DB looks good.

Thank you for suggesting the fix. I ended up showing this thread to  TAC engineer. :)

Regards,

Amarjeet

[Manish Gogna]

That's great Amar, thanks for sharing.

Manish