This is my very first post, so I apologize for any newbie behavior that could show up in this post!
We have a 2 node cluster of Cisco Unified Callmanager 5.1.1 and we have been facing issues with CAR, the problem seems to be the following:
1. At first we were unable to get up to date CAR reports, the only reports that would be available were a month or so old.
2. I tried to troubleshoot the problem at (1.) by increasing the frequency of the CDR load scheduler (which was set to 5 minutes every 24 hrs), while the uninhabited load should have done the job, but for some reason it didn't.
3. Since then we were able to get constant, up to date CAR reports (this continued for about 40 days), untill one day, no more records were moved to the CAR database, and the latest record that is in the Tbl_Billing_Data is on 19-May-2010, which is the day CDR stopped loading into CAR.
5. I used RTMT Trace & Log Query Wizard to view the "Cisco CDR files on Publisher Processed" and files seem to be generated fine.
6. But in the same query I checked the "Cisco CAR Scheduler" logs and what I found is that since 20th of May (the day CDR seemed to fail ) the log was filled with the follwing error, which by looking at the time was generated whenever a CDR Load was triggered:
Trace Level: ERROR Thread: main Class Name: services.Scheduler Message: runTasks(): Error while running the task. Will continue with next taskjava.lang.InterruptedException: sleep interrupted at java.lang.Thread.sleep(Native Method) at com.cisco.ccm.car.services.Scheduler.runTasks(Scheduler.java:2087) at com.cisco.ccm.car.services.Scheduler.<init>(Scheduler.java:244) at com.cisco.ccm.car.services.Scheduler.main(Scheduler.java:151)
And honestly I don't have any idea what that error means, but the fact that the error is generated when the scheduled CDR Load starts strongly suggests that this causes our problem.
Please have kind patience and try to help me with this one. I will provide any additional info in case needed!
I haven't tried that actually, but a few says back, I googled a lot, and followed many of the troubleshooting advices I found, and seems one of them worked out.
What I think might have solved the problem is increasing the value of the parameter MAX_ERROR_RECORD_ID to a value greater than that of
max(Error_Record_Id) from another table.
It may not be the solution that solved it for me, cause as I said, I did many troubleshooting that night, and I wasn't that patient to verify each action made. And still I would like to find out the root of the problem, cause we don't want to miss records for any other time!
But I'll keep rebooting in mind in case anything showed up again, thanks!
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...