On Cisco CallManager systems, Microsoft SQL 2000 Enterprise databases are used to store system and device configuration as well as call detail records (CDRs). To maintain data consistency throughout the cluster, the publisher database server uses one-way, or unidirectional, replication to each subscriber. All information is stored on one server (the publisher server) and replicated to the other servers (subscriber servers) in the cluster. Replicating the SQL database is a core function inside Cisco CallManager clusters.
Configuration changes on Cisco CallManager systems are possible only while the publisher server is available. To make sure that CDRs are written even if the publisher server is offline, every server stores CDR information locally in flat files. Cisco CallManager writes information to the publisher database only if Cisco CallManager web components are installed or Cisco CallManager Administration is performed directly on the publisher server. All entries that are made using the Cisco CallManager Administration page of the subscriber are written to the database on the publisher server. If the publisher is down, no updates can be made in the Cisco CallManager Administration page of the subscriber server.
CDR records are not written into a database of the subscriber, but they are written locally in transaction files at the subscribers (but not directly in the CDR database). Those files are periodically processed and inserted in the Microsoft SQL Server 2000 database by the CDR Insert service on the publisher server. If the publisher server is down, transaction files reside on the subscriber server to be processed as soon as the publisher is available again. After CDRs are processed, they are replicated from the publisher to subscriber database.
When you are building a publisher server, Cisco CallManager software itself might or might not be installed. If the publisher server does not have Cisco CallManager installed (and only has the SQL database installed), Cisco refers to the server as a glass house. This configuration is the best solution in large clusters. The publisher (either running Cisco CallManager or not [glass house]) holds the only copy of the database that is allowed to be written to. All subscribers replicate with the database of the publisher only, so they are in read-only mode.
In addition, the publisher occasionally acts as a backup CallManager service for the configuration. This configuration is typically used only in smaller clusters.
Database Management Tools Overview
Two tools are used to maintain the Cisco CallManager database services and are based on Microsoft SQL Server 2000:
Both tools allow administrators to verify proper working of Cisco CallManager Microsoft SQL Server 2000 databases. You can use the Microsoft SQL Server 2000 Enterprise Manager and DBLHelper when administrators need to examine the database structure and replication. You can use these tools to reactivate broken database connections.
In many cases, the reason for a broken database connection is publisher downtime. For example, administrators might take the publisher off the network to perform a software upgrade and restore it later. After reloading a Cisco CallManager publisher server, verify the database connection. A broken connection would not cause any obvious problem in system activity. Usually, users become aware of a broken connection only if the publisher becomes unresponsive again and any system changes are lost. For example, call forwarding instructions that are months out of date are active or newly added phones are unavailable when they failover to a subscriber server. Failures of the Extension Mobility functionality might also point to a broken publisher connection.
When you are troubleshooting Cisco CallManager SQL databases, it is beneficial to use both tools together.
Microsoft SQL Server 2000 Enterprise Manager
Microsoft SQL Server 2000 Enterprise Manager is included with the Microsoft SQL Server 2000 Enterprise software. To access it, choose Start > Programs > Microsoft SQL Server > Enterprise Manager. This is the primary administrative tool for Microsoft SQL Server 2000 and provides a Microsoft Management Console (MMC)compliant user interface, shown in Figure 30-1, which allows users to do the following:
Figure 30-1. Microsoft SQL Server 2000 Enterprise Manager
Because the Cisco CallManager installation includes the database and database structure needed for Cisco CallManager servers, it is not necessary to create new databases.
Do not change the structure of the Cisco CallManager database. The Cisco CallManager will malfunction or, in the worst case, stop responding.
The Microsoft SQL database name of Cisco CallManager is CCM03xx, where xx starts at 00 and increases incrementally with each Cisco CallManager upgrade (for example, upgrading from release 4.0 to 4.1).
You can use Microsoft SQL Server 2000 Enterprise Manager to determine whether a server is the publisher or the subscriber. Expand the database hierarchy down to the databaseMicrosoft SQL ServersSQL Server Group\DatabasesCCM03xx, as shown in Figure 30-2:
Figure 30-2. Determining Publisher Server Function with SQL Server 2000 Enterprise Manager
The second way to determine whether the server is the publisher or subscriber is to check whether the Replication Monitor is present on the specific Microsoft SQL server. The Replication Monitor is present only on the publisher and monitors the status of database replication between the publisher and the subscribers.
In the event that the subscriber stops replicating data from the publisher, you need to rebuild the relationships between the publisher and subscriber. The DBLHelper utility, a tool provided by Cisco, republishes or reinitializes a nonfunctioning subscription between the publisher and the subscriber databases. For DBLHelper to work, the SQL account password and administrative rights must be the same on the publisher and the subscriber. Because this tool is automated and nonintrusive, you might make a schedule of running it once per week to ensure the subscriber and publisher database links are active. If the link fails, you might not detect it for a considerable time because the symptoms are so subtle.
If you are upgrading from an earlier version of Cisco CallManager, DBLHelper.exe is usually located on the Cisco CallManager server in the C:Program FilesCisco Systems, IncCisco CallManager Upgrade AssistantDbReplCheck folder. Otherwise, contact Cisco TAC for the latest version of DBLHelper.
You can also use Microsoft SQL Server 2000 Enterprise Manager to re-create broken database connections between Cisco CallManager servers in the cluster, but this process is far more complex than using DBLHelper. The recommendation is to first try repairing the replication using DBLHelper. If DBLHelper cannot fix the problem, use the Microsoft SQL Server 2000 Enterprise Manager. For more information on how to use the Microsoft SQL Server 2000 Enterprise Manager to repair replications, search for "Reestablishing a Broken Cisco CallManager Cluster SQL Subscription" or "Broken SQL Replication" on Cisco.com. The documents for the 3.x version of Cisco CallManager also apply to the 4.x CallManager versions.
In Figure 30-3, DBLHelper shows two different states of Cisco CallManager Microsoft SQL Server 2000 databases. On the left, running DBLHelper.exe found that the replication was working. This status is depicted by the two green smiley face icons. On the right, a red (lower) sad face icon indicates that databases are out of synchronization. In this case, database connections need to be reestablished. Clicking the Republish button deletes the current subscription and re-creates it. Clicking the Reinitialize button reinitializes all subscriptions and starts the snapshot agent. It also begins an attempt to rebuild the subscription with the current database. To get more information about the current tab, click the Help button, which shows some additional information.
Figure 30-3. Using DBLHelper to Restore Broken Links
If there is more than one subscriber and only one has a broken database connection, use the Republish button to republish only the broken connection. If you use the Reinitialize button, all subscriptions will be reinitialized, which could cause a long system outage.
Part I: Cisco CallManager Fundamentals
Introduction to Cisco Unified Communications and Cisco Unified CallManager
Cisco Unified CallManager Clustering and Deployment Options
Cisco Unified CallManager Installation and Upgrades
Part II: IPT Devices and Users
Cisco IP Phones and Other User Devices
Configuring Cisco Unified CallManager to Support IP Phones
Cisco IP Telephony Users
Cisco Bulk Administration Tool
Part III: IPT Network Integration and Route Plan
Cisco Catalyst Switches
Configuring Cisco Gateways and Trunks
Cisco Unified CallManager Route Plan Basics
Cisco Unified CallManager Advanced Route Plans
Configuring Hunt Groups and Call Coverage
Implementing Telephony Call Restrictions and Control
Implementing Multiple-Site Deployments
Part IV: VoIP Features
Configuring User Features, Part 1
Configuring User Features, Part 2
Configuring Cisco Unified CallManager Attendant Console
Configuring Cisco IP Manager Assistant
Part V: IPT Security
Securing the Windows Operating System
Securing Cisco Unified CallManager Administration
Preventing Toll Fraud
Hardening the IP Phone
Understanding Cryptographic Fundamentals
Understanding the Public Key Infrastructure
Understanding Cisco IP Telephony Authentication and Encryption Fundamentals
Configuring Cisco IP Telephony Authentication and Encryption
Part VI: IP Video
Introducing IP Video Telephony
Configuring Cisco VT Advantage
Part VII: IPT Management
Introducing Database Tools and Cisco Unified CallManager Serviceability
Configuring Alarms and Traces
Using Additional Management and Monitoring Tools
Part VIII: Appendix
Appendix A. Answers to Review Questions