Erreur de communication de base de données - Service de base de données Cisco arrêté

Introduction

Ce document décrit comment résoudre les problèmes liés à cette erreur : " Erreur de communication de base de données " lors de l'accès à la page CUCM.

Conditions préalables

Conditions requises

Cisco recommande que vous ayez une connaissance de ce sujet :

• Cisco Unified Communications Manager (CUCM) version 11.5

Components Used

Les informations de ce document sont basées sur la version 11.5 de CCM

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. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Ce document vous aide à comprendre le scénario et les techniques TAC à dépanner lorsque vous recevez une erreur de communication de base de données lorsque vous accédez à la page de l'interface utilisateur graphique de CUCM. Ce message indique qu'il y a un problème avec le service de base de données A Cisco, ou qu'il peut être lié au pilote ODBC, mais ce document traite de tout ce que l'utilisateur peut vérifier et un peu de ce que le TAC vérifie lorsque le service de base de données A Cisco ne fonctionne pas comme prévu.

L'une des principales causes de ce problème peut être un arrêt inattendu du système. L'arrêt ingracieux du système d'exploitation Linux peut entraîner la corruption de fichiers qui se ferment brusquement lorsque le système s'arrête. Lorsque cela se produit, il y a une série de fichiers qui doivent être fermés avec grâce. Ces fichiers peuvent ensuite être nécessaires au système pour terminer le processus de démarrage ultérieurement.

D'autres causes peuvent être une modification du nom de domaine complet (FQDN), une modification de l'adresse IP au nom de domaine complet (FQDN) ou vice versa sans la procédure appropriée.

Lorsque les problèmes ci-dessus surviennent, il y a des actions à suivre dans une tentative d'enregistrement du système. L'enregistrement du système est mentionné parce que le plus souvent, si un service particulier dans Linux ne démarre pas correctement (bloqué dans l'état de démarrage ou arrêté), alors il peut être un problème dans le démon/processus responsable de démarrer ce service particulier. Il ne peut être corrigé que lorsque le serveur est reconstruit. 

Procédure de dépannage

Étape 1. Vérification de l'intégrité du système.

Utilisez les résultats des commandes utils diagnostic test et show status pour voir s'il y a d'autres erreurs qui sont lancées afin que d'autres actions puissent être planifiées en conséquence. Par exemple, assurez-vous que la partition active n'est pas remplie à 100 % par show status. Si ce n'est pas le cas, vous devez procéder à un dépannage avant de résoudre d'autres problèmes.

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

Étape 2. Redémarrez le service.

utils service restart Une base de données Cisco - redémarrez le service via l'interface de ligne de commande.

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:
 

Étape 3. Vérifiez les fichiers hosts, rhosts et sqlhosts.

Bien que seuls les fichiers hôtes puissent être mis en correspondance via l'interface de ligne de commande normale du serveur (rappelez-vous que l'interface graphique n'est pas accessible pour accéder à la page de rapport), utilisez la commande show tech network hosts pour faire correspondre les entrées de tous les serveurs du cluster. Si un serveur ne correspond pas, vous pouvez redémarrer le service Gestionnaire de cluster une fois qu'il tente de les corriger.

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: 

Étape 4. Vérifiez les fichiers à partir de la racine.

Cette étape et les étapes suivantes ne sont suivies que par le TAC après avoir obtenu l'accès au compte racine de votre système. le script controlcentre.sh est utilisé afin de redémarrer le service une fois à partir de l'interpréteur de commandes.

À partir des emplacements /home/informix/.rhosts et $INFORMIXDIR/etc/sqlhosts, les fichiers doivent correspondre manuellement dans tous les serveurs. Après cela, redémarrez le service Gestionnaire de cluster pour mettre à jour les détails dans n'importe quel fichier qui pourrait être nécessaire au démarrage.

Étape 5. Cochez la case Informix.

Informix est le processus responsable du service de base de données A Cisco et doit apparaître en ligne lorsque l'utilisateur racine bascule en tant qu'information et vérifie l'état.

Note: Toutes ces étapes, une fois cochées, peuvent aider à réactiver le service si et uniquement si le problème est dû à une non-correspondance dans le fichier hôte/rhosts ou à un blocage temporaire d'informations. Comme nous l'avons déjà mentionné, il peut y avoir de nombreuses autres raisons qui auraient pu causer ces incohérences. Le document ci-dessus met en évidence les étapes qui doivent être vérifiées une par une, juste pour préciser où le problème peut se trouver.

Dans la plupart des situations, nous devons reconstruire les noeuds si nous ne sommes pas en mesure de redémarrer le service à partir de la racine de si les fichiers système sont endommagés.

Lien de référence pour reconstruire Publisher : https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/116946-technote-product-00.html

Pour reconstruire l'abonné : Un nouvel abonné est installé avec la configuration système identique à l'ancien abonné