Errore di comunicazione del database - Servizio Cisco DB inattivo

Introduzione

In questo documento viene descritto come risolvere i problemi relativi a questo errore: " Errore di comunicazione del database " durante l'accesso alla pagina CUCM.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza di questo argomento:

• Cisco Unified Communications Manager (CUCM) versione 11.5

Componenti usati

Le informazioni fornite in questo documento si basano sulla versione 11.5 di CCM

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

Questo documento aiuta a comprendere lo scenario e le tecniche TAC per risolvere i problemi relativi all'errore di comunicazione del database quando si accede alla pagina GUI CUCM. Questo messaggio indica che si è verificato un problema con il servizio A Cisco DB o che potrebbe essere correlato al driver ODBC. Nel documento vengono tuttavia illustrati tutti gli elementi che è possibile verificare e alcuni dei controlli TAC eseguiti quando il servizio A Cisco DB non funziona nel modo previsto.

Una delle cause principali può essere un arresto imprevisto del sistema. Lo spegnimento anomalo del sistema operativo Linux può causare il danneggiamento dei file che vengono chiusi all'improvviso quando il sistema si arresta. Quando ciò accade, c'è una serie di file che devono essere chiusi normalmente. Questi file potrebbero essere necessari al sistema per completare il processo di avvio in un secondo momento.

Altre cause possono essere una modifica nell'FQDN, una modifica da indirizzo IP a FQDN o viceversa senza la procedura corretta.

Quando si verificano i problemi descritti in precedenza, è necessario eseguire alcune operazioni per salvare il sistema. Il salvataggio del sistema viene menzionato perché il più delle volte, se un particolare servizio in Linux non viene avviato correttamente (bloccato nello stato di avvio o arresto), potrebbe essere un problema nel daemon/processo responsabile avviare quel particolare servizio. Può essere corretto solo durante la ricostruzione del server. 

Procedura di risoluzione dei problemi

Passaggio 1. Controllo di integrità del sistema.

Utilizzare gli output del comando utils Diagnose test e show status per verificare la presenza di altri errori e pianificare di conseguenza le azioni da eseguire. Ad esempio, assicurarsi che la partizione attiva non sia riempita al 100% tramite il comando show status. Se questa condizione non è vera, è necessario eseguire la risoluzione dei problemi prima di risolvere altri problemi.

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%)

Passaggio 2. Riavviare il servizio.

utilizza il riavvio del servizio Un database Cisco - riavvia il servizio tramite CLI.

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:
 

Passaggio 3. Controllare i file hosts, rhosts e sqlhosts.

Sebbene solo i file host possano essere associati tramite la normale CLI del server (ricordarsi che non è possibile accedere alla GUI per passare alla pagina di report), utilizzare il comando show tech network hosts per trovare una corrispondenza con le voci in tutti i server del cluster. In caso di mancata corrispondenza in uno dei server, è possibile riavviare il servizio Gestione cluster dopo averli corretti.

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: 

Passaggio 4. Controllare i file dalla directory principale.

Questa procedura e le successive sono seguite da TAC solo dopo aver ottenuto l'accesso al sistema da parte dell'account root. lo script controlcenter.sh viene utilizzato per riavviare il servizio una volta dalla shell.

Dalle posizioni /home/informix/.rhosts e $INFORMIXDIR/etc/sqlhosts, i file vengono allineati manualmente in tutti i server. Al termine, riavviare il servizio Gestione cluster per aggiornare i dettagli in qualsiasi file che potrebbe essere necessario durante l'avvio.

Passaggio 5. Controllare Informix.

Informix è il processo responsabile del servizio A Cisco DB e deve essere visualizzato in linea quando l'utente root cambia il nome in informix e controlla lo stato.

Nota: Tutte queste operazioni, una volta selezionate, consentono di ripristinare il servizio se e solo se il problema è dovuto a una mancata corrispondenza nel file host/rhosts o a un blocco temporaneo di informix. Come accennato in precedenza, ci possono essere molte altre ragioni che potrebbero aver causato queste incongruenze. Il documento precedente evidenzia i passaggi da controllare uno per uno solo per individuare il punto in cui potrebbe essersi verificato il problema.

Nella maggior parte delle situazioni è necessario ricostruire i nodi se non è possibile riavviare il servizio dalla radice di se i file di sistema sono danneggiati.

Collegamento Ref per ricompilare il server di pubblicazione :https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/116946-technote-product-00.html

Per ricompilare il Sottoscrittore: Il nuovo sottoscrittore viene installato con la stessa configurazione del sistema del vecchio sottoscrittore