Dépannage des échecs de sauvegarde

Les sauvegardes de base de données peuvent échouer pour diverses raisons. En général, une sauvegarde échoue car l'hôte de base de données ne peut pas accéder à la banque d'objets, ou car l'hôte ou la configuration de base de données présente des problèmes.

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, une sauvegarde de base de données ayant échoué affiche le statut En échec, ou se bloque sur l'état Sauvegarde en cours ou Création. 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 cette rubrique pour trouver une solution.

Les sujet suivants sont abordés :

Identification de la cause première de l'échec de sauvegarde

  1. Connectez-vous à l'hôte en tant qu'utilisateur root et accédez à /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 | grep -i <dbname>

    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 les détails du problème suggèrent un problème avec RMAN, consultez les journaux RMAN dans le répertoire suivant.

    /opt/oracle/dcs/log/<hostname>/rman/bkup/<db_unique_name>/rman_backup/<yyyy-mm-dd>

Remarques :

Si l'échec 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 OCI utilise une structure d'agent afin de vous permettre de gérer votre base de données via la plate-forme cloud. 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 sauvegarde.

Les sujet suivants sont abordés :

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

Remarques :

Utilisez initctl au lieu de systemctl avec OL6.

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

    systemctl status initdcsagent

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

    systemctl 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 : 

    systemctl status initdcsagent

Problèmes relatifs à Oracle Clusterware

Oracle Clusterware permet aux serveurs de communiquer entre eux de manière à ce qu'ils puissent fonctionner comme une unité collective. Il peut parfois s'avérer nécessaire de redémarrer le programme Clusterware pour résoudre un échec de sauvegarde.

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

Redémarrage d'Oracle Clusterware

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

    crsctl check crs
    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

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

La sauvegarde de la base de données vers OCI Object Storage exige que l'hôte puisse se connecter à l'adresse Swift applicable. Vous pouvez tester cette connectivité à l'aide d'un utilisateur Swift.

Les sujet suivants sont abordés :

Vérification de la connectivité de l'hôte de base de données à la banque d'objets

  1. Créez un utilisateur Swift dans votre location. Pour plus d'informations, reportez-vous à Utilisation des jetons d'authentification dans Gestion des informations d'identification utilisateur.

  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>
  3. 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

Les sujet suivants sont abordés :

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

Commandes interactives dans le profil Oracle

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.

Système de fichiers plein

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.

Version incorrecte du module Oracle Database Cloud Backup

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 la dernière mise à jour de package.

Modifications apportées au fichier de profil de site (glogin.sql)

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 OCI. Reportez-vous à Configuration SQL*Plus. 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 OCI.

Problèmes de base de données

Une configuration ou un état de base de données incorrect peut entraîner l'échec des sauvegardes.

Les sujet suivants sont abordés :

Base de données non exécutée lors de la sauvegarde

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

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 la sauvegarde 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;

Mode d'archivage défini sur NOARCHIVELOG

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.

Vérification et définition du mode d'archivage

Ouvrez une invite de commande SQL*Plus et saisissez la commande suivante :

select log_mode from v$database;

Si vous devez définir le mode d'archivage sur ARCHIVELOG, démarrez la base de données avec le statut Montage (et non Ouvert), puis utilisez la commande suivante dans l'invite de commande SQL*Plus : 

alter database archivelog;

Vérifiez que le paramètre db_recovery_file_dest pointe vers +RECO et que le paramètre log_archive_dest_1 est défini sur USE_DB_RECOVERY_FILE_DEST.

Pour les bases de données RAC, une instance doit avoir le statut Montage lors de l'activation du mode ARCHIVELOG. Afin d'activer le mode ARCHIVELOG pour une base de données RAC, procédez comme suit :

  1. Arrêtez toutes les instances de base de données .

    srvctl stop database -d

  2. Démarrez l'une des instances de base de données ayant l'état MOUNT .

    srvctl start instance -d <db_unique_name> -i <instance_name> -o mount

  3. Accédez à l'invite de commande SQL*Plus .

    sqlplus / as sysdba

  4. Activez le mode ARCHIVELOG et quittez l'interface.

    alter database archivelog;
    exit;

  5. Arrêtez la base de données.

    srvctl stop instance -d <db_unique_name> -i <instance_name>

  6. Redémarrez toutes les instances de base de données .

    srvctl start database -d <db_unqiue_name>

  7. Dans l'invite de commande SQL*Plus, vérifiez que le mode d'archivage est défini sur ARCHIVELOG. 

    select log_mode from v$database;

Blocage d'un processus d'archivage de base de données et échecs de sauvegarde

Les sauvegardes peuvent échouer lorsqu'un processus d'archivage de l'instance de base de données est bloqué. Par exemple, cela peut se produire lorsque la zone de récupération rapide est pleine. Vous pouvez vérifier cette condition à l'aide de la commande suivante.

srvctl status database -db <db_unique_name> -v

Si la commande renvoie la sortie suivante, vous devez résoudre le problème de blocage du processus d'archivage pour pouvoir effectuer les sauvegardes :

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.

Une fois le blocage du processus résolu, la commande doit renvoyer la sortie suivante :

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

Si le statut de l'instance ne change pas une fois le problème sous-jacent résolu avec la ressource ou le périphérique saturé ou indisponible, essayez l'une des solutions de contournement suivantes :

  • Redémarrez la base de données à l'aide de la commande srvctl pour mettre à jour le statut de la base de données dans le clusterware.
  • Mettez à niveau la base de données vers les derniers niveaux d'ensemble de patches.

Erreurs de tablespace temporaire

Si les statistiques de table fixe ne sont pas à jour dans la base de données, les sauvegardes peuvent échouer avec des erreurs faisant référence à un tablespace temporaire présent dans le fichier dcs-agent.log. Exemple : 

select status from v$rman_status where COMMAND_ID=<backup_id>

Sortie :

ERROR at line 1:
ORA-01652: unable to extend temp segment by 128 in tablespace TEMP

Pour résoudre ce problème, rassemblez les statistiques de table fixe comme suit :

conn / as sysdba
exec dbms_stats.gather_fixed_objects_stats();

Configuration RMAN et échecs de sauvegarde

La modification de certains paramètres de configuration RMAN peut entraîner des échecs de sauvegarde dans OCI. 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 afin d'obtenir plus de détails sur les paramètres de configuration RMAN à ne pas modifier pour les bases de données dans OCI.

Paramètres de configuration RMAN ne devant pas être modifiés

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' MAXPIECESIZE 2 G FORMAT   '%d_%I_%U_%T_%t' PARMS  
    'SBT_LIBRARY=/opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs/libopc.so 
    ENV=(OPC_PFILE=/opt/oracle/dcs/commonstore/objectstore/opc_pfile/1578318329/opc_tiger_iad3c8.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;

Stratégie de conservation RMAN et échecs de sauvegarde

La configuration de la stratégie de conservation RMAN peut être à l'origine d'échecs de sauvegarde. L'utilisation de la configuration de stratégie de conservation REDUNDANCY au lieu de la stratégie RECOVERY WINDOW peut entraîner des échecs de sauvegarde. Veillez à utiliser la configuration RECOVERY WINDOW OF 30 DAYS.

Configuration du paramètre de stratégie de conservation RMAN

  1. Recherchez l'ID de base de données à l'aide de la commande suivante :

    dbcli list-databases

  2. Recherchez la valeur BackupConfigId pour la base de données à l'aide de la commande suivante : 

    dbcli describe-database -i <database_id>

  3. Mettez à jour la configuration de la stratégie de conservation vers RECOVERY WINDOW OF 30 DAYS : 

    dbcli update-backupconfig -i <backup_config_id> --recoverywindow 30

Perte du fichier de portefeuille de la banque d'objets et échecs de sauvegarde

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.

Vérification de l'existence du fichier de portefeuille de la banque d'objets et des droits d'accès appropriés

  1. Recherchez l'ID de base de données à l'aide de la commande suivante :

    dbcli list-databases

  2. Recherchez la valeur BackupConfigId pour la base de données à l'aide de la commande suivante : 

    dbcli describe-database -i <database_id>

  3. Recherchez la valeur BackupLocation pour la base de données à l'aide de la commande suivante : 

    dbcli describe-backupconfig <backup_config_id>

  4. Recherchez le chemin du fichier de paramètres de configuration de sauvegarde (opc_<backup_location_value>_BC.ora) à l'aide de la commande suivante : 

    locate opc_<backup_location_value>_BC.ora

    Exemple :

    locate opc_b9naijWMAXzi9example_BC.ora

    Sortie :

    /opt/oracle/dcs/commonstore/objectstore/opc_pfile/13aef284-9d6b-4eb6-8751-2988a9example/opc_b9naijWMAXzi9example_BC.ora

  5. Recherchez le chemin du fichier de portefeuille dans le fichier de paramètres de configuration de sauvegarde en examinant la valeur stockée dans le paramètre OPC_WALLET. Pour ce faire, accédez au répertoire contenant le fichier de paramètres de configuration de sauvegarde et utilisez la commande cat suivante : 

    cat <backup_config_parameter_file>

    Exemple :

    cat opc_b9naijWMAXzi9example_BC.ora

    Sortie :

    OPC_HOST=https://swiftobjectstorage.us-ashburn-1.oraclecloud.com/v1/dbbackupiad
OPC_WALLET='LOCATION=file:/opt/oracle/dcs/commonstore/objectstore/wallets/13aef284-9d6b-4eb6-8751-2988aexample CREDENTIAL_ALIAS=alias_opc'
OPC_CONTAINER=b9naijWMAXzi9example

  6. Vérifiez que le fichier cwallet.sso se trouve dans le répertoire indiqué dans le paramètre OPC_WALLET, puis assurez-vous que le fichier dispose des droits d'accès appropriés. Les droits d'accès au fichier doivent avoir une valeur octale de "600" (-rw-------). Pour ce faire, utilisez la commande suivante : 

    ls -ltr /opt/oracle/dcs/commonstore/objectstore/wallets/<backup_config_id>

    Exemple :

    ls -ltr /opt/oracle/dcs/commonstore/objectstore/wallets/13aef284-9d6b-4eb6-8751-2988aexample

    Sortie :

    total 4
-rw------- 1 oracle oinstall    0 Apr 20 06:45 cwallet.sso.lck
-rw------- 1 oracle oinstall 1941 Apr 20 06:45 cwallet.sso

Problèmes de portefeuille TDE

Les sujet suivants sont abordés :

Spécification incorrecte de l'emplacement du portefeuille TDE

Pour que les opérations de sauvegarde puissent être effectuées, le fichier $ORACLE_HOME/network/admin/sqlnet.ora doit contenir le paramètre ENCRYPTION_WALLET_LOCATION formaté exactement comme suit : 

ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME)))

Remarques :

Dans cette entrée d'emplacement de portefeuille, $ORACLE_UNQNAME est une variable d'environnement qui ne doit pas être remplacée par une valeur réelle.

Vérification de la spécification de l'emplacement du portefeuille TDE

Utilisez la commande cat pour vérifier l'indication de l'emplacement du portefeuille TDE. Exemple : 

cat $ORACLE_HOME/network/admin/sqlnet.ora

Sortie :

ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME)))

La variable d'environnement ORACLE_UNQNAME n'a pas été définie lors du démarrage de la base de données à l'aide de SQL*Plus

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.

Pour résoudre le problème, démarrez la base de données à l'aide de l'utilitaire srvctl : 

srvctl start database -d <db_unique_name>

Base de données pluggable ajoutée avec une clé de cryptage maître configurée de façon incorrecte

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. Cette clé de cryptage est stockée dans un fichier de clés unique utilisé par tous les conteneurs. 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 : 

    alter session set container=pdb2;
    select WRL_TYPE,WRL_PARAMETER,STATUS,WALLET_TYPE from v$encryption_wallet;

    Sortie :

    WRL_TYPE  WRL_PARAMETER                                           STATUS             WALLET_TYPE
--------- ------------------------------------------------------- ------------------ -----------
FILE      /opt/oracle/dcs/commonstore/wallets/tde/example_iadxyz/ 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 :

    show pdbs

    Sortie :

    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, consultez la documentation relative aux bases de données pluggables pour votre version d'Oracle Database.

  3. Exécutez les commandes DBCLI suivantes pour remplacer le statut par OPEN : 

    sudo su –
    dbcli list-database
    dbcli update-tdekey -i <database_ID> -n <PDB_name> -p

    La commande update-tdekey affichée vous invite à saisir le mot de passe administrateur.

  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.

Vérification de la configuration de paramètres liés au portefeuille TDE

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

  1. Vérifiez que le paramètre de nom unique (ORACLE_UNQNAME) de base de données de l'environnement est défini correctement à l'aide de la commande suivante :

    srvctl getenv database -d <db_unique_name>

    Exemple :

    srvctl getenv database -d orclbkp_iadxyz

    Sortie :

    orclbkp_iadxyz:
ORACLE_UNQNAME=orclbkp_iadxyz
TZ=UTC

  2. Vérifiez vos paramètres sqlnet.ora pour vous assurer que le fichier contient un paramètre ENCRYPTION_WALLET_LOCATION avec la valeur DIRECTORY correcte. Pour ce faire, utilisez la commande suivante : 

    cat $ORACLE_HOME/network/admin/sqlnet.ora

    Exemple :

    cat $ORACLE_HOME/network/admin/sqlnet.ora

    Sortie :

    ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME)))

  3. Vérifiez que le statut du portefeuille est Ouvert et que le type de portefeuille est Connexion automatique en examinant la vue v$encryption_wallet. Exemple : 

    select status, wrl_parameter,wallet_type from v$encryption_wallet;

    Sortie :

    STATUS  WRL_PARAMETER                                            WALLET_TYPE
------- -------------------------------------------------------- ------------
OPEN    /opt/oracle/dcs/commonstore/wallets/tde/example_iadxyz/  AUTOLOGIN

    Pour les bases de données pluggables, veillez à basculer sur le conteneur approprié avant d'interroger la vue v$encryption_wallet. Exemple : 

    sqlplus / as sysdba
    alter session set container=pdb1;
    select WRL_TYPE,WRL_PARAMETER,STATUS,WALLET_TYPE from v$encryption_wallet;

    Sortie :

    WRL_TYPE  WRL_PARAMETER                                          STATUS  WALLET_TYPE
--------- ------------------------------------------------------ ------- ------------
FILE      /opt/oracle/dcs/commonstore/wallets/tde/tiger_iad3c8/  OPEN    AUTOLOGIN

Fichier de portefeuille TDE manquant

Le fichier de portefeuille TDE (ewallet.p12) peut entraîner l'échec des sauvegardes s'il est manquant, ou s'il comporte un propriétaire ou des droits d'accès au système de fichier incompatibles. Vérifiez le fichier comme indiqué dans l'exemple suivant : 

ls -ltr /opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME/ewallet.p12

Sortie :

-rwx------ 1 oracle oinstall 5680 Apr 18 13:09 /opt/oracle/dcs/commonstore/wallets/tde/orclbkp_iadxzy/ewallet.p12

Le fichier de portefeuille TDE doit disposer de droits d'accès au fichier ayant une valeur octale de "700" (-rwx------) et le propriétaire de ce fichier doit faire partie du groupe de système d'exploitation oinstall.

Fichier de portefeuille de connexion automatique manquant

Le fichier de portefeuille de connexion automatique (cwallet.sso) peut entraîner l'échec des sauvegardes s'il est manquant, ou s'il comporte un propriétaire ou des droits d'accès au système de fichier incompatibles. Vérifiez le fichier comme indiqué dans l'exemple suivant : 

ls -ltr /opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME/cwallet.sso

Sortie :

-rwx------ 1 oracle oinstall 5725 Apr 18 13:09 /opt/oracle/dcs/commonstore/wallets/tde/orclbkp_iadxyz/cwallet.sso

Le fichier de portefeuille de connexion automatique doit disposer de droits d'accès au fichier ayant une valeur octale de "700" (-rwx------) et le propriétaire de ce fichier doit faire partie du groupe de système d'exploitation oinstall.

Autres causes des échecs de sauvegarde

Les sujet suivants sont abordés :

Point de montage commonstore non monté

Le point de montage /opt/oracle/dcs/commonstore doit être monté, sinon les sauvegardes échouent.

Vérification du point de montage commonstore

Vérifiez que le point de montage /opt/oracle/dcs/commonstore est monté, comme indiqué dans l'exemple suivant : 

srvctl config filesystem -volume commonstore -diskgroup data

Sortie :

Volume device: /dev/asm/commonstore-5
Diskgroup name: data
Volume name: commonstore
Canonical volume device: /dev/asm/commonstore-5
Accelerator volume devices:
Mountpoint path: /opt/oracle/dcs/commonstore
Mount point owner: oracle
Mount users:
Type: ACFS

Vérification de la mise en ligne d'ora.data.commonstore.acfs

  1. ora.data.commonstore.acfs doit être en ligne ou les sauvegardes échouent. Vérifiez cet élément comme indiqué dans l'exemple suivant : 

    crsctl stat resource ora.data.commonstore.acfs -v

    Sortie :

    NAME=ora.data.commonstore.acfs
TYPE=ora.acfs.type
LAST_SERVER=orcl
STATE=OFFLINE
TARGET=OFFLINE
...
STATE_DETAILS=admin unmounted /opt/oracle/dcs/commonstore
...

  2. Répertoriez le contenu du répertoire commonstore pour vérifier qu'il est monté. 

    ls -ltr /opt/oracle/dcs/commonstore

  3. Si la valeur STATE_DETAILS est unmounted, montez le système de fichiers comme indiqué dans l'exemple suivant : 

    srvctl start filesystem -volume commonstore -diskgroup data

  4. Assurez-vous que la modification a été effectuée comme indiqué dans l'exemple suivant :

    crsctl stat resource ora.data.commonstore.acfs -v

    Sortie :

    NAME=ora.data.commonstore.acfs
TYPE=ora.acfs.type
LAST_SERVER=orcl
STATE=ONLINE on orcl
TARGET=ONLINE
CARDINALITY_ID=ONLINE
...
STATE_DETAILS=mounted on /opt/oracle/dcs/commonstore

  5. Répertoriez le contenu du répertoire commonstore pour vérifier qu'il est monté, comme indiqué dans l'exemple suivant : 

    ls -ltr /opt/oracle/dcs/commonstore

    Sortie :

    total 220
drwx------ 2 root   root     65536 Apr 18 10:50 lost+found
drwx------ 3 oracle oinstall 20480 Apr 18 11:02 wallets
drwxr-xr-x 3 root   root     20480 Apr 20 06:41 pkgrepos
drwxr-xr-x 4 oracle oinstall 20480 Apr 20 06:41 objectstore

Base de données inscrite de façon incorrecte

Les sauvegardes de base de données échouent si la base de données n'est pas inscrite auprès de dcs-agent. Ce scénario peut se produire si vous migrez manuellement la base de données vers OCI et que vous n'exécutez pas la commande dbcli register-database.

Pour vérifier si la base de données est correctement inscrite, examinez les informations renvoyées par l'exécution des commandes srvctl config database et dbcli list-databases. Si l'une des commandes ne renvoie pas d'enregistrement de la base de données, contactez Oracle Support Services.

Pour obtenir des instructions sur l'inscription de la base de données, reportez-vous aux rubriques suivantes :

Obtention d'aide supplémentaire

Si vous n'avez pas pu résoudre le problème à l'aide des informations de cette rubrique, 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 base de données à utiliser dans les rapports de problèmes

Utilisez les commandes suivantes pour collecter des détails sur votre base de données. Enregistrez la sortie de chaque commande pour référence :

dbcli list-databases
dbcli describe-database -i <database_id>
dbcli describe-component

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

    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 :

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

Collecte de détails relatifs à la configuration TDE

  1. Exécutez la commande srvctl getenv database -d <db_unique_name> et enregistrez la sortie pour référence.

  2. Enregistrez la sortie de la vue v$encryption_wallet. Exemple : 

    select status, wrl_parameter,wallet_type from v$encryption_wallet;

    Sortie :

    STATUS   WRL_PARAMETER                                           WALLET_TYPE
-------- ------------------------------------------------------- ---------
OPEN     /opt/oracle/dcs/commonstore/wallets/tde/example_iadxyz/ AUTOLOGIN

  3. Enregistrez la sortie de la commande ls -ltr <wrl_parameter>. Par exemple : 

    ls -ltr /opt/oracle/dcs/commonstore/wallets/tde/example_iadxyz/

    Sortie :

    total 28
-rw----- 1 oracle asmadmin 2400 May  2 09:42 ewallet_2018050209420381_defaultTag.p12
-rw----- 1 oracle asmadmin 5680 May  2 09:42 ewallet.p12
-rw----- 1 oracle asmadmin 5723 May  2 09:42 cwallet.sso

Collecte du fichier de rapport de sauvegarde RMAN

Générez un fichier de rapport de sauvegarde RMAN à l'aide de la commande suivante : 

dbcli create-rmanbackupreport -i <db_id> -w detailed -rn <report_name>

Exemple :

dbcli create-rmanbackupreport -i 57fvwxyz-9dc4-45d3-876b-5f850example -w detailed -rn bkpreport1

Localisez le fichier de rapport à l'aide de la commande dbcli describe-rmanbackupreport -in <report_name>. L'emplacement du rapport est indiqué dans la sortie. Exemple : 

dbcli describe-rmanbackupreport -in bkpreport1

Sortie :

Backup Report details                                           
----------------------------------------------------------------
ID: b55vwxyz-c49f-4af3-a956-acccdexample
Report Type: detailed
Location: Node patchtst: /opt/oracle/dcs/log/patchtst/rman/bkup/example_iadxyz/rman_list_backup_detail
    /2018-05-02/rman_list_backup_detail_2018-05-02_11-46-51.0359.log
Database ID: 57fvwxyz-9dc4-45d3-876b-5f850example
CreatedTime: May 2, 2018 11:46:38 AM UTC