Dépannage des échecs de mise à jour

Les opérations de mise à jour peuvent échouer pour diverses raisons. En général, une opération échoue car un noeud de base de données est arrêté, l'espace est insuffisant sur le système de fichiers ou l'hôte de base de données ne parvient pas à accéder à la banque d'objets.

Cet article inclut des informations qui vous aideront à déterminer la cause de l'échec et à résoudre le problème. Les informations sont organisées en plusieurs sections, selon la condition d'erreur.

Si vous connaissez déjà la cause, vous pouvez passer directement à la rubrique présentant la suggestion de solution. Sinon, utilisez la rubrique Identification de la cause de l'échec pour commencer.

Les rubriques suivantes sont traitées dans cet article :

Conseil :

Vous pouvez également créer des connexions à la console série pour le dépannage du système en mode mono-utilisateur. Pour obtenir des informations sur la création d'une connexion à la console série dans la console OCI, reportez-vous à Gestion de la connexion entre la console série et le système de base de données.

Rubriques connexes

Identification de la cause de l'échec

Dans la console OCI, vous pouvez identifier une opération de mise à jour en échec en consultant l'historique des mises à jour d'un système de base de données ou d'une base de données particulière. Une mise à jour n'ayant pas été appliquée a le statut Echec et inclut une brève description de l'erreur à l'origine de l'échec. Si le message d'erreur ne contient pas suffisamment d'informations pour vous orienter vers une solution, vous pouvez utiliser les fichiers journaux et l'interface de ligne de commande de la base de données afin de collecter davantage de données. Consultez ensuite la section appropriée de cet article pour trouver une solution.

Les sujet suivants sont abordés :

Identification de la cause première de l'échec de l'opération de mise à jour

  1. Connectez-vous à l'hôte en tant qu'utilisateur root et accédez au répertoire /opt/oracle/dcs/bin/.

  2. Déterminez la séquence des opérations réalisées sur la base de données.

    dbcli list-jobs

    Notez le dernier ID de travail répertorié dont le statut n'est pas Succès.

  3. Avec l'ID de travail noté à l'étape précédente, utilisez la commande suivante pour vérifier les détails de ce travail :

    dbcli describe-job -i <job_ID> -j

    En général, l'exécution de cette commande est suffisante pour révéler la cause première de l'échec.

  4. Pour plus d'informations, consultez le fichier /opt/oracle/dcs/log/dcs-agent.log.

    Vous trouverez l'ID de travail dans ce fichier grâce à l'horodatage renvoyé par le rapport de travail à l'étape 2.

  5. Si l'échec de la mise à jour concerne une base de données RAC à 2 noeuds, effectuez les étapes 3 et 4 sur les deux noeuds.

Problèmes d'agent de service de base de données

La base de données utilise une structure d'agent afin de vous permettre de gérer votre base de données via la plate-forme Oracle Cloud.

Les sujet suivants sont abordés :

Résolution des échecs de mise à jour causés par un agent arrêté

Il peut parfois s'avérer nécessaire de redémarrer le programme dcsagent s'il est arrêté ou en attente afin de résoudre un échec de mise à jour.

Redémarrage de l'agent de service de base de données

  1. Dans l'invite de commande, vérifiez le statut de l'agent :

    initctl status initdcsagent

  2. Si l'agent est arrêté ou en attente, essayez de le redémarrer : 

    initctl start initdcsagent

  3. Vérifiez à nouveau le statut de l'agent pour vous assurer qu'il est démarré ou en cours d'exécution : 

    initctl status initdcsagent

Résolution des échecs de mise à jour causés par un agent devant être mis à jour

L'opération de mise à jour peut également échouer si l'agent doit être mis à jour. Pour cet échec, le système génère le message d'erreur suivant :

Current DcsAgent version is less than or equal to minimum required version.

Pour résoudre ce problème, effectuez les étapes de la section suivante.

Contact avec le support technique Oracle pour mettre à jour l'agent OCI Database Service

  1. Assurez-vous que l'agent (dcsagent) et le programme d'administration DCS (dcsadmin) sont en cours d'exécution à l'aide des commandes suivantes :

    initctl status initdcsagent
    initctl status initdcsadmin

  2. Si ces programmes ne sont pas en cours d'exécution, utilisez les commandes suivantes pour les redémarrer :

    initctl start initdcsagent
    initctl start initdcsadmin
  3. Suivez les instructions fournies dans Obtention d'aide supplémentaire pour collecter vos fichiers journaux d'agent DCS.
  4. Pour obtenir de l'aide avec la mise à jour de l'agent, contactez le support technique Oracle.

Problèmes de connectivité à la banque d'objets

Les mises à jour de système de base de données et de base de données sont stockés dans OCI Object Storage. Par conséquent, pour réaliser les opérations de mise à jour, l'hôte du système de base de données doit être connecté à l'emplacement Object Storage à partir duquel les mises à jour sont téléchargées.

Les sujet suivants sont abordés :

Vérification de la connectivité de l'hôte de base de données à OCI Object Storage

  1. Utilisez la commande suivante pour vérifier que l'hôte peut accéder à OCI Object Storage :

    dbcli describe-latestpatch

    Exemple de sortie indiquant le succès :

    componentType   availableVersion
--------------  --------------
gi              12.2.0.1.180417
gi              12.1.0.2.180417
db              11.2.0.4.180417
db              12.2.0.1.180417
db              12.1.0.2.180417
oak             12.1.2.11.3
oak             12.2.1.1.0

    Exemple de sortie indiquant l'échec :

    DCS-10032:Resource patch metadata is not found.Failed to download patchmetadata from objectstore

  2. Si vous ne pouvez pas vous connecter à la banque d'objets, reportez-vous à Sauvegarde d'une base de données à l'aide de la console pour découvrir comment configurer la connectivité à la banque d'objets.

Problèmes d'hôte

Si l'hôte de base de données présente au moins l'une des conditions suivantes, les opérations de mise à jour peuvent échouer.

Les sujet suivants sont abordés :

Noeud de base de données non exécuté lors de l'opération de mise à jour

Tous les noeuds de la base de données doivent être actifs et en cours d'exécution pendant l'opération de mise à jour, qu'elle s'applique au système de base de données ou au répertoire de base de base de données. Utilisez la console OCI pour vérifier que le statut de chaque noeud est défini sur AVAILABLE et pour démarrer le noeud, si nécessaire.

Système de fichiers plein

Les opérations de mise à jour requièrent au moins 15 Go d'espace libre dans le répertoire /u01 sur le système de fichiers hôte. Utilisez la commande df -h sur l'hôte pour vérifier l'espace disponible. Si l'espace disponible sur le système de fichiers est insuffisant, vous pouvez enlever les anciens fichiers trace ou journaux pour libérer de l'espace.

Problèmes relatifs à Oracle Clusterware

Les sujet suivants sont abordés :

Oracle Clusterware non exécuté

Oracle Clusterware permet aux serveurs de communiquer entre eux de manière à ce qu'ils puissent fonctionner comme une unité collective. Le programme logiciel du cluster doit être en fonctionnement sur le système de base de données pour que les opérations de mise à jour puissent être effectuées. Il peut parfois s'avérer nécessaire de redémarrer Oracle Clusterware pour résoudre un échec de mise à jour.

Redémarrage d'Oracle Clusterware

  1. A partir de l'invite de commande, vérifiez le statut d'Oracle Clusterware :

    crsctl check crs

    Sortie :

    CRS-4638: Oracle High Availability Services is online
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online

    Pour plus d'informations sur le statut, vous pouvez exécuter crsctl stat res -t.

  2. Si Oracle Clusterware est hors ligne, essayez de redémarrer le programme :

    crsctl start crs

  3. Vérifiez le statut d'Oracle Clusterware pour vous assurer qu'il est en ligne :

    crsctl check crs

Oracle Grid Infrastructure (GI) non mis à jour

Ce problème survient lorsque vous essayez de mettre à jour une base de données avant de mettre à jour le système de base de données associé. La description de l'erreur indique qu'Oracle Grid Infrastructure doit être mis à jour en premier. Pour résoudre ce problème, mettez à jour le système de base de données vers la dernière version disponible. Après avoir mis à jour le système de base de données, vous pouvez retenter l'opération de mise à jour de la base de données.

Afin d'obtenir la version en cours et la dernière version disponible de GI pour le système de base de données, utilisez la commande suivante :

dbcli describe-component

Problèmes de base de données

Un état de base de données incorrect peut entraîner des échecs de mise à jour.

Les sujet suivants sont abordés :

Base de données non exécutée lors de l'opération de mise à jour

La base de données doit être active et en cours d'exécution pour que toutes les tâches de mise à jour soient effectuées. Sinon, vous devez exécuter manuellement la tâche datapatch.

Vérification du fonctionnement de la base de données

Utilisez la commande suivante pour vérifier l'état de la base de données et veillez à ce que tous les problèmes ayant pu entraîner un état incorrect de la base de données soient résolus :

srvctl status database -d <db_unique_name> -verbose

Le système renvoie un message indiquant le statut de l'instance de base de données. Le statut de l'instance doit être Ouvert pour que l'opération de mise à jour puisse être effectuée.

Si la base de données n'est pas en cours d'exécution, utilisez la commande suivante pour la démarrer :

srvctl start database -d <db_unique_name> -o open

Si la base de données est montée mais que son statut n'est pas défini sur Ouvert, utilisez les commandes suivantes pour accéder à l'invite de commande SQL*Plus et définir le statut sur Ouvert : 

sqlplus / as sysdba
alter database open;

Exécution de la tâche datapatch

Avant d'exécuter la commande datapatch, assurez-vous que toutes les bases de données pluggables sont ouvertes. Pour ouvrir une base de données pluggable, vous pouvez utiliser SQL*Plus afin d'exécuter ALTER PLUGGABLE DATABASE <pdb_name> OPEN READ WRITE; sur la base de données pluggable. 

$ORACLE_HOME/OPatch/datapatch

La commande datapatch doit être exécutée sur chaque répertoire de base de base de données.

Obtention d'aide supplémentaire

Si vous n'avez pas pu résoudre le problème à l'aide des informations de cet article, suivez les procédures ci-dessous pour collecter des informations sur la base de données et des informations de diagnostic pertinentes. Après avoir collecté ces informations, contactez le support technique Oracle.

Les sujet suivants sont abordés :

Collecte d'informations de diagnostic sur les travaux ayant échoué

  1. Connectez-vous à l'hôte en tant qu'utilisateur root et accédez au répertoire /opt/oracle/dcs/bin/.

  2. Exécutez les deux commandes suivantes pour générer des informations sur le travail en échec :

    dbcli list-jobs | grep -i <dbname>
    dbcli describe-job -i <job_ID> -j

    L'élément <job_ID> dans la deuxième commande doit correspondre à l'ID du dernier travail en échec signalé par la première commande.

  3. Exécutez le script de collecteur de diagnostics pour créer un fichier ZIP contenant les informations de diagnostic destinées au support technique Oracle.

    diagcollector.py

    Cette commande crée un fichier nommé diagLogs -<timestamp>.zip dans le répertoire /tmp.

Collecte des fichiers journaux de l'agent DCS

Pour collecter les fichiers journaux de l'agent DCS, procédez comme suit :

  1. Connectez-vous en tant qu'utilisateur opc.

  2. Exécutez la commande suivante :

    sudo /opt/oracle/dcs/bin/diagcollector.py

  3. Le système renvoie un message indiquant que les journaux de l'agent sont disponibles dans un fichier ZIP dans le répertoire indiqué. Exemple :

    Log files collected to :/tmp/dcsdiag/diagLogs-1234567890.zip
Logs are being collected to:
/tmp/dcsdiag/diagLogs-1234567890.zip

Collecte des fichiers journaux Oracle Grid Infrastructure et Database

En cas d'échec d'une mise à jour d'Oracle Grid Infrastructure ou d'Oracle Database, les fichiers journaux de ces échecs se trouvent aux emplacements suivants :

Oracle Grid Infrastructure 

$GI_HOME/cfgtoollogs/

Oracle Database 

$ORACLE_HOME/cfgtoollogs/