For several months it seemed to me that our UCCX 5 system was beginning to have trouble. At first it appeared as a problem with our wallboard system being unable to display the real-time data properly. I had deduced that queries to the db_cra database were taking 4 - 5 minutes to return data.
At first I called on the vendor for our wallboard, but they were unable to help stating that it was a UCCX database issue - and I agreed. I then went to Cisco TAC and fed them all my information and asked them for help. They also were unable to help figure out what was happening, but they could see that the SQL queries that used to take 2 seconds were now taking several minutes. Since the wallboard system queried the database every 10 seconds, it was over-taxing the database.
This began to cause little anomalies in things like call-distribution, dropped calls, slow to no Historical reports returns, and this ultimately began to cause failovers to our backup node. I could not go a day without a failover and I had to reboot the servers almost every night.
I felt there was no solution and was afraid we needed to replace our system.
After talking to all the engineers around the world, my solution came from our very own SQL administrator. Within 5 minutes he was able to resolve all our issues.
The root of our problem was that the indexing of the db_cra database was extremely fragmented.
He wrote a SQL sript that he had me run against the database and he told me that this would correct any indexing issues.
It worked like a charm.
The system stopped behaving poorly immediately. This resolved many of our problems that I had been living with for a long time. It made the Admin page work so much faster, call distribution issues halted, the wallboard is running faster than ever with real-time data, and the list goes on. This resolved so many smaller issues that I cannot even list them all.
I would advise anyone using a SQL database, whether it be a Cisco product or not, to always keep their database 'defragmented'.
My SQL admin also setup the script to run automatically, on a schedule to keep our database running like a Ferrari. It has been sweet ever since.
KEEP YOUR INDEXES CLEAN AND YOU WILL REAP HAPPINESS!
I was equally shocked that there was no escalation, as was my boss and my Cisco rep. They let me go with no resolution and hung-up the phone leaving me with instructions to have some-one else take a look at the database. It was very unexpected, especially considering how close they were to the point when we were trouble-shooting.
The TAC SR # 611904619 - IPCC Database Not Returning Query Data.
With this resolution, it also raised to my mind the issue of Informix. We are using CUCM 6.1.2 and are concerned about the same issue happening there and we would like to determine if this can happen there also, and if there is a re-indexing tool available for Informix.
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...