Document ID: 46082
The replication of the Structured Query Language (SQL) database is a core function of Cisco CallManager clusters. The server with the master copy of the Cisco CallManager database is called the publisher, while the servers that replicate the database are called subscribers. The subscriber server consistently polls the publisher server for any new changes to the publisher database. If any new changes are made, the subscriber performs a pull subscription in order to receive the most recent changes to the database.
In the event the subscriber stops the replication of data from the publisher, users need to rebuild the relationships between the publisher and subscriber. This document describes the DBLHelper utility. This utility republishes or re-initializes a broken subscription between the publisher and subscriber databases.
Note: If your Cisco CallManager servers are part of a "domain", in order for DBLHelper to properly be executed, you must log into the Cisco CallManager server as the "Local Administrator" account of the Cisco CallManager server, not the domain account.
This is a list of possible symptoms if the subscriber stops replicating from the publisher:
Changes that are made on the publisher are not reflected on phones that are registered with the subscriber.
Outbound calls fail on phones registered with the subscriber. As soon as you dial 9 you hear a re-order tone.
Call Forward All (CFwdALL) does not work.
IP phone displays Error Database.
This document assumes the SQL Administrator (SA) account password is available for both the publisher and subscriber if it runs on MSSQL 7.0. It assumes administrative rights if you use SQL Server 2000.
The information in this document is based on these software and hardware versions:
Cisco CallManager 3.x and 4.x
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Refer to the Cisco Technical Tips Conventions for more information on document conventions.
Complete these steps:
If you notice issues with Cisco CallManager failover or notice SQL replication errors in the application event log, check for the DBLHelper.exe file first.
This file is located in the c:\program files\cisco\bin directory. Make sure that you have the latest DBLHelper file in this location. If the file is not currently on the system, open a case with Cisco Technical Support and detail a broken SQL subscription. Use the Cisco TAC Service Request (registered customers only) tool to open a case.
Note: DBLHelper is only run on the publisher.
The Cisco Technical Support engineer can provide the DBLHelper.exe application for you.
If you use Cisco CallManager version 3.0 or 3.1, advise the Technical Support engineer. They can also send the odbc++ file to you.
Note: DBLHelper is compatible with Cisco CallManager 3.x and 4.x.
The odbc++ file in addition to DBLHelper.exe reside in c:\program files\cisco\bin.
The SQL replication relies on NetBios name resolution. Make sure the c:\winnt\system32\drivers\etc\"lmhosts" file is populated if needed.
If only the lmhosts.sam file exists, click start/run, enter cmd, and press Return.
From the C:\ prompt, enter cd \winnt\system32\drivers\etc as shown here.
Copy lmhosts.sam <space> lmhosts.
Edit the lmhosts file.
Save the file and click Exit.
From Windows Explorer, select c:\ > program files > cisco, click the bin directory and double-click on DBLHelper.exe.
This window displays:
Note: The red frowning icon indicates a broken SDL subscription between the publisher and subscriber Cisco CallManagers.
The Republish button deletes the current subscription and recreates it. The Reinitialize button reinitializes all subscriptions and starts the snapshot agent. It also attempts to rebuild the subscription with the current database.
Once you select an option, the button is grayed out. Once the operation is complete and the databases are reestablished, this window appears:
If a republish does not fix the replication issues and the red frowning icon still appears, then check to see if the database name is the same across all the Cisco CallManager servers. If any of the subscriber CallManager servers have a different name, update the database name in that subscriber. Open the Windows Registry Editor in that particular Cisco CallManager server and browse to HKEY_LOCAL_MACHINE > Software > Cisco Systems Inc. > DBL. Look for registry entries DBCONNECTION0, DBCONNECTION1, and so forth. Update the value of these entries with the publisher database name.
The value of the DBCONNECTIONx entry looks like this:
If the publisher database has a name of CCM0301, then update the registry value as:
The NameResolution tab indicates whether or not there is a Domain Name System. (DNS) entry, or hosts entry to indicate a name IP address resolution. It also indicates any network delay between servers.
The Compare DB tab allows you to compare the databases between Cisco CallManager release versions.
Note: This is not used.
The BackupData tab allows you to do a database backup that is saved in a .csv format.
Note: This is not a supported way to do a backup of the Cisco CallManager database.
Note: May sure that you close the DBLhelper application after it has run on the Publisher. If DBLhelper is left active, it can cause errors in the Event viewer.
In order to test the propagation of data, create a device on the publishing server that is easily recognizable and click Insert.
The device does not need to be functional. Click Update, then Close.
Go into the SQL Enterprise Manager, expand the SQL subscriber in question, and look in the database table to see if the new device is present.
The more recognizable the device, the easier it is to find.
After you add a new Cisco CallManager Subscriber to the cluster, a IsChangeNotfyReady SQL error is found in the Publisher.
Run the DBLhelper tool in order to resolve this error message .
- Cisco Unified CallManager Compatibility Matrix
- Reestablishing a Broken Cisco CallManager Cluster SQL Subscription with CallManager 3.0, 3.1 and 3.2
- Reestablishing a Broken CallManager Cluster SQL Subscription with Cisco CallManager 3.3
- Voice Technology Support
- Voice and Unified Communications Product Support
- Troubleshooting Cisco IP Telephony
- Technical Support & Documentation - Cisco Systems
|Updated: Jun 28, 2007||Document ID: 46082|