Les sauvegardes de base de données peuvent échouer lors de la phase de configuration RMAN ou de l'exécution d'une tâche de sauvegarde RMAN. Les tâches de configuration RMAN comprennent la validation de la connectivité de destination de sauvegarde, l'installation du module de sauvegarde et les modifications de configuration RMAN. Les fichiers journaux que vous examinez dépendent de la phase de l'échec.

1. Connectez-vous à l'hôte en tant qu'utilisateur oracle.
2. Vérifiez le fichier journal concerné :
   • Pour identifier l'ID tâche d'une sauvegarde automatisée, utilisez la commande dbaascli database backup --dbname <dbname> --showHistory. Affiche l'historique de toutes les tâches de sauvegarde, y compris leurs ID correspondants.
   • Les journaux de tâches sont disponibles à l'adresse /var/opt/oracle/log/dtrs/jobs/, nommés au format <job_id>.log. En cas d'échec d'une tâche, un journal de débogage correspondant <job_id>.debug est également généré au même emplacement.
   • Vous pouvez trouver les journaux d'exécution de commande RMAN correspondants pour les opérations de sauvegarde, de récupération et de configuration dans le répertoire /var/opt/oracle/log/<dbname>/dtrs/rman/bkup.

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

   systemctl status dbcsagent.service

2. Si l'agent est à l'état Arrêter/Attente, essayez de le redémarrer :

   systemctl start dbcsagent.service

3. Vérifiez à nouveau le statut de l'agent pour confirmer qu'il a le statut Arrêter/En cours d'exécution :

   systemctl status dbcsagent.service

1. Créez un utilisateur Swift dans votre location. Voir Utilisation de jetons d'authentification.
2. Avec l'utilisateur que vous avez créé à l'étape précédente, utilisez la commande suivante pour vérifier si l'hôte peut accéder au magasin d'objets.

   curl -v -X HEAD -u <user_ID>:'<auth_token>' https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace>

   Voir Service de stockage d'objets - FAQ pour la bonne région à utiliser. Voir Présentation des espaces de noms du stockage d'objets pour plus d'informations sur votre espace de noms du stockage d'objets.
3. Si vous ne pouvez pas vous connecter au magasin d'objets, consultez la rubrique Préalables pour les sauvegardes sur le service Exadata Cloud pour des informations sur la configuration de la connectivité du magasin d'objets.

Si une commande interactive telle que oraenv, ou toute commande qui peut retourner un message d'erreur ou d'avertissement, a été ajoutée au fichier .bash_profile pour l'utilisateur grid ou oracle, les opérations du service Base de données telles que les sauvegardes automatiques peuvent être interrompues et échouer. Recherchez ces commandes dans le fichier .bash_profile et supprimez-les.

Les opérations de sauvegarde requièrent de l'espace dans le répertoire /u01 sur le système de fichiers hôte. Utilisez la commande df -h sur l'hôte afin de vérifier l'espace disponible pour les sauvegardes. Si l'espace du système de fichiers est insuffisant, vous pouvez supprimer les anciens fichiers journaux ou de suivi afin de libérer de l'espace.

Votre système n'a peut-être pas la version requise du module de sauvegarde (opc_installer.jar). Voir Impossible d'utiliser des sauvegardes gérées dans le système de base de données pour plus de détails sur ce problème connu. Pour corriger le problème, vous pouvez suivre la procédure décrite dans cette section ou simplement mettre à jour votre système de base de données et votre base de données avec le dernier correctif d'ensemble.

La personnalisation du fichier de profil de site ($ORACLE_HOME/sqlplus/admin/glogin.sql) peut entraîner l'échec des sauvegardes gérées dans Oracle Cloud Infrastructure. Des commandes interactives, en particulier, peuvent mener à des échecs de sauvegarde. Oracle recommande de ne pas modifier ce fichier pour les bases de données hébergées dans Oracle Cloud Infrastructure.

La base de données doit être active et en cours d'exécution (idéalement sur tous les noeuds) pendant la sauvegarde.

Lorsque vous provisionnez une nouvelle base de données, le mode d'archivage est réglé à ARCHIVELOG par défaut. Il s'agit du mode d'archivage obligatoire pour les opérations de sauvegarde. Vérifiez le paramètre du mode d'archivage pour la base de données et remplacez-le par ARCHIVELOG, s'il y a lieu.

Instance <instance_identifier> is running on node *<node_identifier>. Instance status: Stuck Archiver

Consultez le document ORA-00257 : Erreur de l'utilitaire d'archivage (ID document 2014425.1) pour obtenir des informations sur la résolution d'un processus d'utilitaire d'archivage bloqué.

Instance <instance_identifier> is running on node *<node_identifier>. Instance status: Open

Si le statut de l'instance ne change pas une fois résolu le problème sous-jacent de saturation ou d'indisponibilité de l'appareil ou de la ressource, essayez de redémarrer la base de données à l'aide de la commande srvctl pour mettre à jour le statut de la base de données dans la grappe.

La modification de certains paramètres de configuration RMAN peut provoquer des échecs de sauvegarde dans Oracle Cloud Infrastructure. Pour vérifier votre configuration RMAN, utilisez la commande show all dans l'invite de ligne de commande RMAN.

Pour plus de détails, voir la liste suivante des paramètres de configuration RMAN qui ne doivent pas être modifiés pour les bases de données dans Oracle Cloud Infrastructure.

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 30 DAYS;

CONFIGURE CONTROLFILE AUTOBACKUP ON;

CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 5 BACKUP TYPE TO COMPRESSED BACKUPSET;

CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2 G;

CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS  'SBT_LIBRARY=/var/opt/oracle/dbaas_acfs/<db_name>/opc/libopc.so, ENV=(OPC_PFILE=/var/opt/oracle/dbaas_acfs/<db_name>/opc/opc<db_name>.ora)';

CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO 'SBT_TAPE';

CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2 G;

CONFIGURE ENCRYPTION FOR DATABASE ON;

Les sauvegardes RMAN échouent lorsqu'un fichier de portefeuille de magasin d'objets est perdu. Le fichier de portefeuille est nécessaire pour activer la connectivité au magasin d'objets.

Les sauvegardes de base de données échouent si le portefeuille TDE n'est pas à l'état qui convient. Les scénarios suivants peuvent provoquer ce problème :

Si la base de données a été démarrée à l'aide de SQL*Plus et que la variable d'environnement ORACLE_UNQNAME n'était pas définie, le portefeuille n'est pas ouvert correctement.

srvctl start database -d <db_unique_name>

Dans un environnement multilocataire pour les versions d'Oracle Database qui prennent en charge le magasin de clés au niveau des bases de données enfichables, chacune de ces dernières possède sa propre clé principale de chiffrement. Pour les bases de données Oracle 18c, cette clé de chiffrement est stockée dans un magasin de clés unique utilisé par tous les conteneurs. (Oracle Database 19c ne prend pas en charge de magasin de clés au niveau de la base de données enfichable.) Après avoir créé ou développé une nouvelle base de données enfichable, vous devez créer et activer une clé principale de chiffrement pour elle. Si vous ne le faites pas, la colonne STATUS de la vue v$encryption_wallet affiche la valeur OPEN_NO_MASTER_KEY.

Pour vérifier le statut de la clé principale de chiffrement et créer une clé principale, procédez de la façon suivante :

1. Vérifiez la colonne STATUS de la vue v$encryption_wallet, comme illustré dans l'exemple suivant :

   
   SQL> alter session set container=pdb2;
   Session altered.
   
   SQL> select WRL_TYPE,WRL_PARAMETER,STATUS,WALLET_TYPE from v$encryption_wallet;
   
   WRL_TYPE   WRL_PARAMETER                                   STATUS             WALLET_TYPE
   ---------- ----------------------------------------------- ------------------ -----------
   FILE       /var/opt/oracle/dbaas_acfs/testdb30/tde_wallet/ OPEN_NO_MASTER_KEY AUTOLOGIN

2. Confirmez que la base de données enfichable est en mode d'ouverture READ WRITE et n'est pas restreinte, comme illustré dans l'exemple suivant :

   
   SQL> show pdbs
   
   CON_ID CON_NAME     OPEN MODE              RESTRICTED
   ------ ------------ ---------------------- ---------------
   2      PDB$SEED     READ ONLY              NO
   3      PDB1         READ WRITE             NO
   4      PDB2         READ WRITE             NO

   La base de données enfichable ne peut pas être ouverte en mode restreint (la colonne RESTRICTED doit afficher NO). Si la base de données enfichable est actuellement en mode restreint, consultez les informations dans la vue PDB_PLUG_IN_VIOLATIONS et résolvez le problème avant de continuer. Pour plus d'informations sur la vue PDB_PLUG_IN_VIOLATIONS et le statut restreint, consultez le Guide de l'administrateur d'Oracle Multitenant sur la base de données enfichable de votre version d'Oracle Database.

3. Créez et activez une clé principale de chiffrement principale pour la base de données enfichable :

   • Réglez le conteneur à la base de données enfichable :

     ALTER SESSION SET CONTAINER = <pdb>;

   • Créez et activez une clé de chiffrement principale dans la base de données enfichable en exécutant la commande suivante :

     ADMINISTER KEY MANAGEMENT SET KEY USING TAG '<tag>' 
     FORCE KEYSTORE IDENTIFIED BY <keystore-password> WITH BACKUP USING '<backup_identifier>';

   Notez ce qui suit :

   • La clause USING TAG est facultative et permet d'associer un marqueur à la nouvelle clé principale de chiffrement.

   • La clause WITH BACKUP est facultative et peut être utilisée pour créer une sauvegarde du magasin de clés avant la création de la nouvelle clé principale de chiffrement.

   Vous pouvez également utiliser les commandes dbaascli dbaascli tde status et dbaascli tde rotate masterkey pour examiner et gérer vos clés.

4. Confirmez que le statut du portefeuille est passé de OPEN_NO_MASTER_KEY à OPEN en interrogeant la vue v$encryption_wallet comme illustré à l'étape 1.

Des paramètres de configuration associés au portefeuille TDE peuvent entraîner l'échec des sauvegardes.

# ls -altr /var/opt/oracle/dbaas_acfs/<database_name>/tde_wallet/ewallet.p12
total 76
-rw------ 1 oracle oinstall 5467 Oct 1 20:17 ewallet.p12

Le fichier de portefeuille TDE doit avoir les autorisations de fichier avec la valeur octale "600" (-rw-------) et le responsable de ce fichier doit faire partie du groupe de systèmes d'exploitation oinstall.

# ls -altr /var/opt/oracle/dbaas_acfs/<database_name>/tde_wallet/cwallet.sso
total 76
-rw------ 1 oracle oinstall 5512 Oct 1 20:18 cwallet.sso

Le fichier de portefeuille à connexion automatique doit avoir les autorisations de fichier avec la valeur octale "600" (-rw-------) et le responsable de ce fichier doit faire partie du groupe de systèmes d'exploitation oinstall.

Sur chaque noeud de calcul associé à la configuration Data Guard, rassemblez les fichiers journaux en rapport avec le problème rencontré.

• Fichiers journaux de la phase d'activation, tels que ceux concernant la création de la base de données de secours et ceux du système principal ou de secours correspondant.
• Fichiers journaux de l'ID de la tâche d'activation. Par exemple : 23.
• Emplacement des fichiers journaux par phase d'activation et système Exadata (principal ou de secours).
• Fichiers journaux de noms de base de données (db_name or db_unique_name selon le chemin d'accès).

Data Guard Deployer (DGdeployer) est le processus qui exécute la configuration. Lors de la configuration de la base de données principale, il crée le fichier /var/opt/oracle/log/<dbname>/dgdeployer/dgdeployer.log.

Ce journal doit contenir la cause première de l'échec de la configuration de la base de données principale.

• Le journal principal de l'utilitaire de ligne de commande dbaasapi est le suivant : /var/opt/oracle/log/dbaasapi/db/dg/<job_ID>.log. Recherchez les entrées qui contiennent dg_api.
• L'un des journaux de secours de l'utilitaire de ligne de commande dbaasapi est le suivant : /var/opt/oracle/log/dbaasapi/db/dg/<job_ID>.log. Dans ce journal, recherchez les entrées qui contiennent dg_api.
• L'autre journal de secours est le suivant : /var/opt/oracle/log/<dbname>/dgcc/dgcc.log. Ce journal est le journal de configuration de Data Guard.

• Le moteur de déploiement Oracle Cloud (ODCE) crée le fichier /var/opt/oracle/log/<dbname>/ocde/ocde.log. Ce journal doit contenir la cause d'un échec de la création de la base de données de secours.
• L'utilitaire de ligne de commande dbaasapi crée le fichier var/opt/oracle/log/dbaasapi/db/dg/<job_ID>.log. Recherchez les entrées qui contiennent dg_api.
• Le fichier journal de configuration de Data Guard est le suivant : /var/opt/oracle/log/<dbname>/dgcc/dgcc.log.

• DGdeployer est le processus qui exécute la configuration. Il crée le fichier suivant : /var/opt/oracle/log/<dbname>/dgdeployer/dgdeployer.log. Ce journal doit contenir la cause première de l'échec de la configuration de la base de données de secours.
• L'utilitaire de ligne de commande dbaasapi crée le fichier /var/opt/oracle/log/dbaasapi/db/dg/<job_ID>.log. Recherchez les entrées qui contiennent dg_api.
• Le journal de configuration de Data Guard est le suivant : /var/opt/oracle/log/<dbname>/dgcc/dgcc.log.

DGdeployer est le processus qui exécute la configuration. Lors de la configuration de Data Guard, il crée le fichier /var/opt/oracle/log/<dbname>/dgdeployer/dgdeployer.log. Ce journal doit contenir la cause première de l'échec de la configuration de la base de données principale.

Sur chaque noeud des sites principal et de secours, rassemblez des fichiers journaux pour le nom de base de données connexe (db_name).

• Journal d'alerte de base de données : /u02/app/oracle/diag/rdbms/<dbname>/<dbinstance>/trace/alert_<dbinstance>.log
• Journal de courtier Data Guard : /u02/app/oracle/diag/rdbms/<dbname>/<dbinstance>/trace/drc<dbinstance>.log
• Fichier journal d'outils Cloud pour Data Guard : /var/opt/oracle/log/<dbname>/odg/odg.log

Le mot de passe entré pour activer Data Guard ne correspondait pas à celui de l'administrateur principal de l'utilisateur SYS. Cette erreur survient lors de la phase de validation de la base de données principale de l'activation.

La base de données est peut-être inactive. Cette erreur survient lors de la phase de validation de la base de données principale de l'activation. Vérifiez à l'aide de srvctl et de sql sur l'hôte que la base de données est en cours d'exécution sur tous les noeuds.

Impossible de configurer la base de données principale. Des commandes Data Guard non valides ou l'échec d'une reconfiguration de module d'écoute peuvent causer cette erreur.

Impossible de créer le portefeuille TDE. Les fichiers du magasin de clés (portefeuille) Oracle Transparent Database Encryption (TDE) n'ont pas pu être préparés pour le transport vers le site de secours. Cette erreur survient lors de la phase de création du portefeuille TDE de l'activation. L'un des éléments suivants peut causer un échec à ce stade :

• Impossible d'accéder aux fichiers de portefeuille TDE
• Les commandes d'activation n'ont pas pu créer d'archive contenant les fichiers de portefeuille

Procédure de dépannage :

1. Assurez-vous que la grappe est accessible. Pour vérifier le statut d'une grappe, exécutez la commande suivante :

   crsctl check cluster -all

2. Si la grappe ne fonctionne pas, exécutez la commande suivante pour la redémarrer :

   crsctl start crs -wait

3. Si cette erreur survient lorsque la grappe est accessible, vérifiez les journaux de création du portefeuille TDE (phase d'activation) pour déterminer la cause et la résolution de l'erreur.

L'archive contenant le portefeuille TDE n'a probablement pas été transmise au site de secours. Le problème est souvent résolu par une nouvelle tentative.

• Les sites principal et de secours ne peuvent peut-être pas communiquer entre eux pour configurer la base de données de secours. Ces erreurs surviennent lors de la phase de configuration de la base de données de secours de l'activation. À ce stade, des configurations sont effectuées sur la base de données de secours, notamment rman duplicate sur la base de données principale. Pour résoudre ce problème :
  1. Vérifiez le statut de connectivité des sites principal et de secours.
  2. Assurez-vous que l'hôte peut communiquer avec tous les autres depuis le port 1521. Vérifiez la configuration du réseau, y compris les groupes de sécurité de réseau (NSG), les listes de sécurité de réseau et la configuration de l'appairage distant de réseaux en nuage virtuels (le cas échéant). La meilleure façon de tester la communication entre l'hôte et les autres noeuds est d'accéder aux bases de données par SQL*PLUS, du système principal au système de secours et inversement.
• Les adresses IP virtuelles ou modules d'écoute SCAN ne fonctionnent pas. Utilisez le test ci-dessus pour identifier le problème.

Causes possibles :

• Les adresses IP virtuelles ou modules d'écoute SCAN ne fonctionnent pas. Vous pouvez confirmer ce problème en utilisant les commandes suivantes sur tout noeud de grappe.

  • [grid@exa1-****** ~]$ srvctl status
                scan

  • [grid@exa1-****** ~]$ srvctl status
                  scan_listener

• Les bases de données peuvent être inaccessibles. Vous pouvez confirmer ce problème en tentant de vous connecter à l'aide d'un alias Oracle Net existant.

Procédure de dépannage :

1. En tant qu'utilisateur de système d'exploitation oracle, vérifiez l'existence d'un alias Oracle Net pour la base de données conteneur. Recherchez un alias dans $ORACLE_HOME/network/admin/<dbname>/tnsnames.ora.

   L'exemple suivant montre une entrée pour une base de données conteneur nommée db12c :

   cat $ORACLE_HOME/network/admin/db12c/tnsnames.ora 
   DB12C = (DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST = exa1-*****-scan.********.******.******.com)(PORT = 1521)) 
   (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = db12c.********.******.******.com) 
   (FAILOVER_MODE = (TYPE = select) (METHOD = basic))))

2. Vérifiez que vous pouvez utiliser l'alias pour vous connecter à la base de données. Par exemple, en tant que sysdba, entrez la commande suivante :

   sqlplus sys@db12c

Les mots de passe d'utilisateur Oracle Database sys ou system pour la base de données et le portefeuille TDE sont peut-être différents. Pour comparer les mots de passe :

1. Connectez-vous à la base de données en tant qu'utilisateur sys et vérifiez le statut TDE dans

   V$ENCRYPTION_WALLET

   .
2. Connectez-vous à la base de données en tant qu'utilisateur system et vérifiez le statut TDE dans

   V$ENCRYPTION_WALLET

   .
3. Modifiez les mots de passe pour qu'ils soient identiques. Connectez-vous à l'hôte du système en tant qu'opc et exécutez les commandes suivantes :
   1. Pour modifier le mot de passe SYS :

      sudo dbaascli database changepassword --dbname <database_name>

   2. Pour modifier le mot de passe du portefeuille TDE :

      sudo dbaascli tde changepassword --dbname <database_name>

Pour les causes et résolutions possibles des problèmes de portefeuille TDE, voir Échecs de portefeuille TDE et de sauvegarde.

Lorsque les commandes de permutation, de basculement et de remise en service sont exécutées, plusieurs messages d'erreur peuvent se produire. Consultez la documentation d'Oracle Database pour en savoir plus sur ces messages d'erreur.

Note

Oracle recommande d'utiliser l'interface de ligne de commande du courtier Data Guard (dgmgrl) pour valider les configurations.

1. En tant qu'utilisateur Oracle, connectez-vous à la base de données principale ou de secours avec dgmgrl et vérifiez la configuration et la base de données :

   dgmgrl sys/<pwd>@<database>
   DGMGRL> VALIDATE CONFIGURATION VERBOSE
   DGMGRL> VALIDATE DATABASE VERBOSE <PRIMARY>
   DGMGRL> VALIDATE DATABASE VERBOSE <STANDBY>

2. Consultez la documentation d'Oracle Database pour vérifier le message d'erreur correspondant. Par exemple :
   • ORA-16766 : Redo Apply est arrêté.
   • ORA-16853 : Le décalage d'application des transactions a dépassé le seuil indiqué.
   • ORA-16664 : Impossible de recevoir le résultat à partir d'un membre (pour la base de données de secours).
   • ORA-12541 : TNS : Pas de processus d'écoute (pour la base de données principale).

Pour voir la cause et la résolution, vérifiez les erreurs dans Messages d'erreur de base de données.

Journaux pour DBAASCLI