Datenbankkommunikationsfehler - Ausfall eines Cisco DB-Service

Einführung

In diesem Dokument wird beschrieben, wie Sie Probleme im Zusammenhang mit diesem Fehler beheben können: " Datenbankkommunikationsfehler " beim Zugriff auf die CUCM-Seite.

Voraussetzungen

Anforderungen

Cisco empfiehlt, über Kenntnisse in diesem Bereich zu verfügen:

• Cisco Unified Communications Manager (CUCM) Version 11.5

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf CCM-Version 11.5.

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Hintergrundinformationen

Dieses Dokument erläutert Szenario- und TAC-Techniken zur Fehlerbehebung, wenn beim Zugriff auf die CUCM-GUI-Seite ein Datenbankkommunikationsfehler auftritt. Diese Meldung weist darauf hin, dass ein Problem mit dem A Cisco DB-Dienst vorliegt oder es mit dem ODBC-Treiber in Zusammenhang stehen könnte. In diesem Dokument wird jedoch alles behandelt, was der Benutzer überprüfen kann, und ein wenig davon, was TAC überprüft, wenn der A Cisco DB-Dienst nicht wie erwartet funktioniert.

Eine der größten Ursachen dafür kann ein unerwartetes Herunterfahren des Systems sein. Ein unsanftes Herunterfahren unter Linux-Betriebssystemen kann zu Beschädigungen von Dateien führen, die abrupt geschlossen werden, wenn das System heruntergefahren wird. Wenn dies geschieht, gibt es eine Reihe von Dateien, die sanft geschlossen werden müssen. Diese Dateien können dann vom System benötigt werden, um den Startvorgang zu einem späteren Zeitpunkt abzuschließen.

Andere Ursachen können eine Änderung des FQDN, eine Änderung von der IP-Adresse in den FQDN oder umgekehrt ohne das richtige Verfahren sein.

Wenn die oben genannten Probleme auftreten, gibt es einige Maßnahmen, die bei der Angebotserstellung zur Rettung des Systems befolgt werden sollten. Das Speichern des Systems wird oft erwähnt, weil es ein Problem im Daemon/Prozess sein kann, der diesen Dienst startet, wenn ein bestimmter Dienst in Linux nicht richtig startet (startet oder beendet). Sie kann nur korrigiert werden, wenn der Server neu erstellt wird. 

Verfahren zur Fehlerbehebung

Schritt 1: Integritätsprüfung des Systems.

Verwenden Sie utils diagnose test und show status command output, um festzustellen, ob weitere Fehler ausgelöst werden, sodass weitere Aktionen entsprechend geplant werden können. Stellen Sie z. B. sicher, dass die aktive Partition nicht zu 100 % durch den Anzeigestatus gefüllt ist. Wenn dies nicht der Fall ist, müssen Sie eine Fehlerbehebung durchführen, bevor Sie andere Probleme beheben können.

admin:show status

Host Name          : CUCM11
Date               : Wed Jul 25, 2018 00:10:07
Time Zone          : India Standard Time (Asia/Kolkata)
Locale             : en_US.UTF-8
Product Ver        : 11.0.1.22045-1
Unified OS Version : 6.0.0.0-2

Uptime:
 00:10:09 up 48 days, 10:56,  1 user,  load average: 0.17, 0.29, 0.27

CPU Idle:   97.74%  System:   01.26%    User:   01.00%
  IOWAIT:   00.00%     IRQ:   00.00%    Soft:   00.00%

Memory Total:        3925432K
        Free:         188156K
        Used:        3737276K
      Cached:         610140K
      Shared:         203520K
     Buffers:          27696K

                        Total            Free            Used
Disk/active         14154228K        1154116K       12854984K (92%)
Disk/inactive       14154228K        1195212K       12813888K (92%)
Disk/logging        49573612K        3454524K       43594160K (93%)

Schritt 2: Starten Sie den Dienst neu.

utils service restart A Cisco DB - starten Sie den Service über CLI neu.

admin:utils service restart A Cisco DB
Do not press Ctrl+C while the service is restarting. If the service has not restarted properly, execute the same command again.
Service Manager is running
A Cisco DB[STOPPING]
A Cisco DB[STARTING]
A Cisco DB[STARTED]
admin:
 

Schritt 3: Überprüfen Sie Hosts, Hosts und SQLhosts-Dateien.

Obwohl nur Hostdateien über die normale CLI des Servers abgeglichen werden können (beachten Sie, dass Sie nicht auf die Berichterstellungsseite zugreifen können), verwenden Sie den Befehl show tech network hosts, um die Einträge auf allen Servern des Clusters abzugleichen. Wenn auf einem Server eine Diskrepanz auftritt, können Sie den Cluster Manager-Dienst neu starten, sobald er versucht, diese zu korrigieren.

admin:show tech network hosts 
 -------------------- show platform network -------------------- 

 /etc/hosts File: 
#This file was generated by the /etc/hosts cluster manager.
#It is automatically updated as nodes are added, changed, removed from the cluster.

127.0.0.1 localhost
::1 localhost
10.106.112.122 cucmsub.emea.lab cucmsub
10.106.112.123 imnp10.emea.lab imnp10
10.106.112.126 CUCM-10.emea.lab CUCM-10
admin: 

Schritt 4: Überprüfen Sie die Dateien von Root.

Dieser und die Schritte danach werden nur vom TAC gefolgt, nachdem Sie Zugriff auf Ihr System erhalten haben. controlCenter.sh-Skript wird verwendet, um den Dienst einmal von der Shell aus neu zu starten.

Von den Standorten /home/informix/.rhosts und $INFORMIXDIR/etc/sqlhosts aus werden die Dateien manuell auf allen Servern abgelegt. Starten Sie anschließend den Cluster Manager-Dienst neu, um die Details in jeder Datei zu aktualisieren, die während des Hochfahrens benötigt wird.

Schritt 5: Überprüfen Sie Informix.

Informix ist der Prozess, der für den A Cisco DB-Service verantwortlich ist. Er sollte als Online angezeigt werden, wenn der Root-Benutzer als informmix wechselt, und den Status überprüfen.

Hinweis: Alle diese Schritte können, sobald sie aktiviert sind, dazu beitragen, den Dienst wieder hochzufahren, wenn das Problem entweder auf eine Diskrepanz in der Host-/Rhosts-Datei zurückzuführen ist oder die Information vorübergehend fixiert ist. Wie bereits erwähnt, kann es viele andere Gründe geben, die zu diesen Diskrepanzen geführt haben könnten. Im obigen Dokument werden die Schritte hervorgehoben, die einzeln überprüft werden müssen, um die Position des Problems einzugrenzen.

In den meisten Fällen müssen wir die Knoten neu erstellen, wenn wir den Dienst nicht von root aus neu starten können, wenn die Systemdateien beschädigt sind.

Link zum Neuerstellen des Publisher: https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/116946-technote-product-00.html

So erstellen Sie den Abonnenten neu: Neuer Subscriber wird mit der gleichen Systemkonfiguration wie der alte Subscriber installiert.