Les sauvegardes de base de données peuvent échouer pendant l'étape de configuration RMAN ou pendant un travail de sauvegarde RMAN en cours d'exécution. Les tâches de configuration RMAN incluent la validation de la connectivité à la destination de sauvegarde, l'installation du module de sauvegarde et les modifications de configuration RMAN. Les fichiers journaux à examiner dépendent de l'étape à laquelle l'échec s'est produit.

1. Connectez-vous à l'hôte en tant qu'utilisateur oracle.
2. Consultez le fichier journal applicable :
   • Pour identifier l'ID de travail d'une sauvegarde automatisée, utilisez la commande dbaascli database backup --dbname <dbname> --showHistory. Cela affiche l'historique de tous les travaux de sauvegarde, y compris leurs ID de travail correspondants.
   • Les journaux de travail sont disponibles dans /var/opt/oracle/log/dtrs/jobs/, nommés selon le format <job_id>.log. En cas d'échec d'un travail, 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. Dans l'invite de commande, vérifiez le statut de l'agent :

   systemctl status dbcsagent.service

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

   systemctl start dbcsagent.service

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

   systemctl status dbcsagent.service

1. Créez un utilisateur Swift dans votre location. Reportez-vous à Utilisation des jetons d'authentification.
2. Avec l'utilisateur créé à l'étape précédente, exécutez la commande suivante pour vérifier que l'hôte peut accéder à la banque d'objets.

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

   Reportez-vous à FAQ sur Object Storage pour connaître la région à utiliser. Reportez-vous à Présentation des espaces de noms Object Storage pour plus d'informations sur votre espace de noms Object Storage.
3. Si vous ne parvenez pas à vous connecter à la banque d'objets, reportez-vous à Prérequis pour les sauvegardes sur Exadata Cloud Service afin d'obtenir plus d'informations sur la configuration de la connectivité à la banque d'objets.

Si une commande interactive telle que oraenv, ou toute commande pouvant renvoyer 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 de base de données, comme les sauvegardes automatiques, peuvent être interrompues et ne pas aboutir. Recherchez ces commandes dans le fichier .bash_profile et enlevez-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 disponible sur le système de fichiers est insuffisant, vous pouvez enlever les anciens fichiers trace ou journaux pour libérer de l'espace.

Votre système ne dispose peut-être pas de la version requise du module de sauvegarde (opc_installer.jar). Pour plus de détails sur ce problème connu, reportez-vous à Utilisation impossible des sauvegardes gérées dans votre système de base de données. Pour résoudre ce problème, vous pouvez suivre la procédure décrite dans cette section ou simplement mettre à jour le système de base de données et la base de données avec le dernier package de patches.

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. Les commandes interactives peuvent notamment entraîner 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 l'ensemble des noeuds) pendant la sauvegarde.

Lors du provisionnement d'une nouvelle base de données, le mode d'archivage est défini par défaut sur ARCHIVELOG. Il s'agit du mode d'archivage requis pour les opérations de sauvegarde. Vérifiez le paramètre de mode d'archivage de la base de données et définissez-le sur ARCHIVELOG, si nécessaire.

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

Reportez-vous à ORA-00257 : Archiver Error (ID de document 2014425.1) pour plus d'informations sur la résolution du blocage du processus d'archivage.

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

Si le statut de l'instance ne change pas après la résolution du problème sous-jacent (appareil ou ressource saturé ou indisponible), essayez de redémarrer la base de données à l'aide de la commande srvctl pour mettre à jour son statut dans le clusterware.

La modification de certains paramètres de configuration RMAN peut entraîner 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.

Reportez-vous à la liste des paramètres suivante pour plus de détails sur les paramètres de configuration RMAN à ne pas modifier 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 banque d'objets est perdu. Le fichier de portefeuille est nécessaire pour permettre la connectivité à la banque d'objets.

Les sauvegardes de base de données échouent si le portefeuille TDE n'est pas dans l'état approprié. Les scénarios suivants peuvent entraîner ce problème :

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

srvctl start database -d <db_unique_name>

Dans un environnement colocatif pour les versions d'Oracle Database prenant en charge le fichier de clés au niveau de la base de données pluggable, chaque base de données pluggable possède sa propre clé de cryptage maître. Pour les bases de données Oracle 18c, cette clé de cryptage est stockée dans un fichier de clés unique utilisé par tous les conteneurs. (Oracle Database 19c ne prend pas en charge les fichiers de clés au niveau de la base de données pluggable.) Une fois que vous avez créé ou connecté une base de données pluggable, vous devez créer et activer une clé de cryptage maître pour celle-ci. Si vous ne le faites pas, la colonne STATUS de la vue v$encryption_wallet indique la valeur OPEN_NO_MASTER_KEY.

Pour vérifier le statut de la clé de cryptage maître et créer une clé maître, procédez comme suit :

1. Examinez la colonne STATUS dans la vue v$encryption_wallet, comme indiqué 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. Vérifiez que la base de données pluggable est en mode d'ouverture READ WRITE et qu'elle n'est pas restreinte, comme indiqué 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 pluggable ne peut pas être ouverte en mode restreint (la colonne RESTRICTED doit afficher NO). Si la base de données pluggable est actuellement en mode restreint, examinez les informations contenues dans la vue PDB_PLUG_IN_VIOLATIONS et résolvez le problème avant de poursuivre. Afin d'avoir plus d'informations sur la vue PDB_PLUG_IN_VIOLATIONS et sur le statut restreint, reportez-vous à la section relative aux bases de données pluggables pour votre version d'Oracle Database dans le guide de l'administrateur Oracle Multitenant.

3. Créez et activez une clé de cryptage maître pour la base de données pluggable :

   • Définissez le conteneur sur la base de données pluggable :

     ALTER SESSION SET CONTAINER = <pdb>;

   • Créez et activez une clé de cryptage maître dans la base de données pluggable 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>';

   Prenez en compte les points suivants :

   • La clause USING TAG est facultative et peut être utilisée pour associer une balise à la nouvelle clé de cryptage maître.

   • La clause WITH BACKUP est facultative et peut être utilisée pour créer une sauvegarde du fichier de clés avant la création de la clé de cryptage maître.

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

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

Certains paramètres de configuration lié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 disposer de droits d'accès au fichier ayant une valeur octale de "600" (-rw-------) et le propriétaire de ce fichier doit faire partie du groupe de système 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 de connexion automatique doit disposer de droits d'accès au fichier ayant une valeur octale de "600" (-rw-------) et le propriétaire de ce fichier doit faire partie du groupe de système d'exploitation oinstall.

Sur chaque noeud de calcul associé à la configuration Data Guard, rassemblez les fichiers journaux correspondant au problème que vous avez rencontré.

• Fichiers journaux de l'étape d'activation (comme ceux détaillant l'opération de création d'une base de données de secours) ainsi que ceux du système principal ou de secours correspondant.
• Fichiers journaux d'ID de travail d'activation. Par exemple : 23.
• Emplacement des fichiers journaux d'activation par étape d'activation et système Exadata (principal ou de secours).
• Fichiers journaux de nom de base de données (db_name ou db_unique_name, selon le chemin du fichier).

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

Ce journal contient généralement 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 /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 /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 /var/opt/oracle/log/<dbname>/dgcc/dgcc.log. Il s'agit du journal de configuration Data Guard.

• Le moteur de déploiement Oracle Cloud crée le fichier /var/opt/oracle/log/<dbname>/ocde/ocde.log. Ce journal contient généralement la cause de l'é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 Data Guard est /var/opt/oracle/log/<dbname>/dgcc/dgcc.log.

• Le processus qui effectue la configuration est appelé DGdeployer. Il crée le fichier /var/opt/oracle/log/<dbname>/dgdeployer/dgdeployer.log. Ce journal contient généralement 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 Data Guard est /var/opt/oracle/log/<dbname>/dgcc/dgcc.log.

Le processus qui effectue la configuration est appelé DGdeployer. Lors de la configuration de Data Guard, il crée le fichier /var/opt/oracle/log/<dbname>/dgdeployer/dgdeployer.log. Ce journal contient généralement 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, collectez les fichiers journaux du nom de base de données associé (db_name).

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

Le mot de passe saisi afin d'activer Data Guard ne correspond pas au mot de passe administrateur principal pour l'utilisateur SYS. Cette erreur peut survenir lors de l'étape d'activation consistant à valider le site principal.

La base de données n'est peut-être pas en cours d'exécution. Cette erreur peut survenir lors de l'étape d'activation consistant à valider le site principal. Effectuez une vérification sur l'hôte à l'aide de srvctl et de sql pour vous assurer que la base de données est démarrée sur tous les noeuds.

La base de données principale n'a pas pu être configurée. Cette erreur peut être due à des commandes Data Guard non valides ou à l'échec de la reconfiguration du processus d'écoute.

Le portefeuille TDE n'a pas pu être créé. Les fichiers du fichier de clés (portefeuille) Oracle TDE (Transparent Database Encryption) n'ont pas pu être préparés en vue du transport vers le site de secours. Cette erreur peut survenir lors de l'étape d'activation consistant à créer un portefeuille TDE. Un échec à cette étape peut être dû aux éléments suivants :

• Accès impossible aux fichiers de portefeuille TDE
• Création impossible d'une archive contenant les fichiers de portefeuille à l'aide des commandes d'activation

Procédure de dépannage :

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

   crsctl check cluster -all

2. Si le cluster est arrêté, exécutez la commande suivante pour le redémarrer :

   crsctl start crs -wait

3. Si cette erreur survient alors que le cluster est accessible, consultez les journaux de l'étape de création d'un portefeuille TDE (étape d'activation) pour déterminer la cause et la méthode de résolution de l'erreur.

L'archive contenant le portefeuille TDE n'a probablement pas été transmise au site de secours. Il suffit généralement de faire une nouvelle tentative pour résoudre le problème.

• Les sites principal et de secours peuvent ne pas parvenir à communiquer entre eux pour configurer la base de données de secours. Ces erreurs peuvent survenir lors de l'étape d'activation consistant à configurer la base de données de secours. A cette étape, les configurations sont effectuées sur la base des données de secours, y compris la duplication de RMAN de la base des données principale. Pour résoudre ce problème, procédez comme suit :
  1. Vérifiez le statut de connectivité des sites principal et de secours.
  2. Assurez-vous que l'hôte peut communiquer à partir du port 1521 avec tous les autres ports. Vérifiez la configuration réseau, y compris les groupes de sécurité réseau, les listes de sécurité réseau et la configuration de l'appairage à distance de réseaux cloud virtuels (le cas échéant). La meilleure façon de tester la communication entre l'hôte et les autres noeuds consiste à accéder aux bases de données à l'aide de SQL*PLUS à partir de la base de données principale vers la base de données de secours, puis inversement.
• Les processus d'écoute ou les adresses IP virtuelles SCAN ne sont peut-être pas en cours d'exécution. Utilisez le test ci-dessus pour identifier le problème.

Causes possibles :

• Les processus d'écoute ou les adresses IP virtuelles SCAN ne sont peut-être pas en cours d'exécution. Vous pouvez vérifier la présence de ce problème à l'aide des commandes suivantes sur n'importe quel noeud de cluster.

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

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

• Les bases de données ne sont peut-être pas accessibles. Pour vérifier la présence de ce problème, essayez de vous connecter à l'aide d'un alias Oracle Net existant.

Procédure de dépannage :

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

   L'exemple suivant présente l'entrée d'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, saisissez la commande suivante :

   sqlplus sys@db12c

Une cause possible de cette erreur est que le mot de passe utilisateur Oracle Database sys ou system pour la base de données et le portefeuille TDE ne soient peut-être pas identiques. Pour comparer les mots de passe, procédez comme suit :

1. Connectez-vous à la base de données avec le nom 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, puis vérifiez le statut TDE dans V$ENCRYPTION_WALLET.
3. Mettez à jour les mots de passe applicables afin qu'ils correspondent. Connectez-vous à l'hôte du système en tant qu'utilisateur opc, puis exécutez les commandes suivantes :
   1. Pour modifier le mot de passe SYS, utilisez la commande suivante :

      sudo dbaascli database changepassword --dbname <database_name>

   2. Pour modifier le mot de passe du portefeuille TDE, utilisez la commande suivante :

      sudo dbaascli tde changepassword --dbname <database_name>

Pour connaître les causes et les résolutions possibles des problèmes de portefeuille TDE, reportez-vous à Portefeuille TDE et échecs de sauvegarde.

Plusieurs messages d'erreur peuvent survenir lors de l'exécution des commandes de permutation, de basculement et de rétablissement. Pour en savoir plus sur ces messages d'erreur, reportez-vous à la documentation Oracle Database.

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. Reportez-vous à la documentation Oracle Database pour trouver le message d'erreur correspondant. Par exemple :
   • ORA-16766 : Redo Apply est arrêté.
   • ORA-16853 : le décalage d'application a dépassé le seuil défini.
   • ORA-16664 : impossible de recevoir le résultat d'un membre (sous la base de données de secours).
   • ORA-12541 : TNS : aucun processus d'écoute (sous la base de données principale).

Pour connaître la cause et la méthode de résolution, consultez la liste des erreurs dans Messages d'erreur de la base de données.

Journaux DBAASCLI