Dépanner les é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 la base de données ne peut pas accéder au magasin d'objets ou présente des problèmes, ou ceux-ci résident dans la configuration de la base de données.

Cet article comprend des informations pour vous aider à déterminer la cause de l'échec et à corriger le problème. Les informations sont organisées en plusieurs sections, en fonction de la condition de l'erreur.

Si vous connaissez déjà la cause, vous pouvez passer à la rubrique de la solution suggérée. Sinon, utilisez la rubrique Identifier la cause de la défaillance pour commencer.

Les rubriques suivantes sont décrites dans cet article :

Conseil :

Vous pouvez également créer des connexions à la console série pour dépanner le système en mode utilisateur unique. Pour plus d'informations sur la création d'une connexion à la console série dans la console OCI, voir Gérer la connexion de la console série au système de base de données.

Rubriques connexes

Identifier la cause de la défaillance

Dans la console OCI, une sauvegarde de base de données qui a échoué affiche le statut Échec ou reste bloquée au statut 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 l'interface de ligne de commande et les fichiers journaux de la base de données pour collecter d'autres données. Consultez ensuite la section pertinente de cette rubrique pour trouver la solution.

Les sujets suivants sont abordés :

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

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

  2. Déterminez l'ordre des opérations effectuées sur la base de données.

    dbcli list-jobs | grep -i <dbname>

    Notez le dernier ID tâche indiqué avec un statut autre que Réussite.

  3. Avec l'ID tâche que vous avez noté à l'étape précédente, utilisez la commande suivante pour vérifier les détails de cette tâche :

    dbcli describe-job -i <job_ID> -j

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

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

    Vous pouvez trouver l'ID tâche dans ce fichier en utilisant l'horodatage retourné par le rapport sur les tâches à l'étape 2.

  5. Si les détails du problème comportent l'erreur 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>

Note :

Si la base de données a échoué sur 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

Votre base de données OCI utilise un cadre d'agent pour vous permettre de gérer votre base de données au moyen de la plate-forme en nuage. Pour résoudre un échec de sauvegarde, vous aurez parfois besoin de redémarrer le programme dcsagent si son statut est Arrêter/Attente.

Les sujets suivants sont abordés :

Redémarrer l'agent du service de base de données

Note :

Utilisez initctl au lieu de systemctl lors de l'utilisation de OL6.

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

    systemctl status initdcsagent

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

    systemctl start initdcsagent

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

    systemctl status initdcsagent

Problèmes liés à Oracle Clusterware

Oracle Clusterware permet aux serveurs de communiquer entre eux afin qu'ils puissent fonctionner en tant qu'unité collective. Vous aurez parfois besoin de redémarrer le programme Clusterware pour résoudre un échec de sauvegarde.

Une ou plusieurs des conditions suivantes sur l'hôte de la base de données peuvent provoquer l'échec des sauvegardes :

Redémarrer Oracle Clusterware

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

    crsctl check crs
    crsctl stat res -t

  2. Si Oracle Clusterware n'est pas en ligne, redémarrez le programme :

    crsctl start crs

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

    crsctl check crs

Problèmes liés à la connectivité du magasin d'objets

La sauvegarde de votre base de données dans le service de stockage d'objets pour OCI nécessite que l'hôte puisse se connecter au point d'extrémité Swift applicable. Vous pouvez tester la connectivité à l'aide d'un utilisateur Swift.

Les sujets suivants sont abordés :

Vérifier que l'hôte de base de données peut se connecter au magasin d'objets

  1. Créez un utilisateur Swift dans votre location. Pour plus d'informations, voir Utilisation de jetons d'authentification dans Gestion des données d'identification des utilisateurs.

  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>
  3. Si vous ne pouvez pas vous connecter au magasin d'objets, voir Sécuriser une base de données à l'aide de la console pour plus d'informations sur la configuration de la connectivité au magasin d'objets.

Problèmes liés à l'hôte

Les sujets suivants sont abordés :

Une ou plusieurs des conditions suivantes sur l'hôte de la base de données peuvent provoquer l'échec des sauvegardes :

Commandes interactives dans le profil Oracle

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

Le système de fichiers est 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 du système de fichiers est insuffisant, vous pouvez supprimer les anciens fichiers journaux ou de suivi afin de libérer de l'espace.

Version incorrecte du module Oracle Database Cloud Backup

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 de cette section ou simplement mettre à jour votre système de base de données et votre base de données avec la dernière mise à jour de l'ensemble.

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. Voir Configuration SQL*Plus. 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 OCI.

Problèmes liés à la base de données

Une configuration ou un état de base de données incorrect peut mener à des échecs de sauvegarde.

Les sujets suivants sont abordés :

Base de données non active pendant la sauvegarde

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

Vérifier que la base de données est active et en cours d'exécution

Vérifiez l'état de la base de données à l'aide de la commande suivante et assurez-vous que les problèmes qui ont pu provoquer un état inapproprié sont résolus :

srvctl status database -d <db_unique_name> -verbose

Le système retourne un message incluant le statut d'instance de la base de données. Le statut de l'instance doit être Ouvert pour que la sauvegarde réussisse. Si la base de données n'est pas active, 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 n'est pas au statut Ouvert, utilisez les commandes suivantes pour accéder à l'invite de commande SQL*Plus et régler le statut à Ouvert : 

sqlplus / as sysdba
alter database open;

Mode d'archivage réglé à NOARCHIVELOG

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.

Vérifier et définir le mode d'archivage

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

select log_mode from v$database;

Si vous devez régler le mode d'archivage à ARCHIVELOG, lancez la base de données avec le statut Montage (et non Ouvert) et utilisez la commande suivante à l'invite de commande SQL*Plus : 

alter database archivelog;

Confirmez que le paramètre db_recovery_file_dest pointe vers +RECO et que le paramètre log_archive_dest_1 est réglé à 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. Pour activer le mode archivelog pour une base de données RAC, effectuez les étapes suivantes :

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

    srvctl stop database -d

  2. Démarrez une des instances de base de données dans l'état de montage .

    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 journal d'archivage et quittez.

    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. À l'invite de commande SQL*Plus, confirmez que le mode d'archivage est réglé à ARCHIVELOG. 

    select log_mode from v$database;

Processus de l'utilitaire d'archivage de base de données bloqué et échecs de sauvegarde

Les sauvegardes peuvent échouer lorsque le processus de l'utilitaire d'archivage de l'instance de base de données est bloqué. Par exemple, cela peut se produire quand la zone de récupération rapide (FRA) est pleine. Vous pouvez rechercher cette condition à l'aide de la commande suivante.

srvctl status database -db <db_unique_name> -v

Si la commande retourne la sortie suivante, vous devez résoudre le problème de blocage de l'utilitaire d'archivage pour réussir les sauvegardes :

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

Après avoir résolu le problème de blocage, la commande doit retourner la sortie suivante :

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 de la ressource ou de l'appareil complet ou indisponible, essayez une des solutions de rechange 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 Clusterware
  • Mettez la base de données aux niveaux du dernier ensemble de correctifs

Erreurs d'espace-table temporaire

Si les statistiques de table fixe ne sont pas à jour dans la base de données, les sauvegardes peuvent échouer avec des erreurs référençant l'espace-table temporaire présent dans le fichier dcs-agent.log. Par 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

Collectez les statistiques de votre table fixe comme suit pour résoudre ce problème.

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

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

Paramètres de configuration RMAN à ne pas modifier

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;

Politique de conservation RMAN et échecs de sauvegarde

La configuration de la politique de conservation RMAN peut être à l'origine d'échecs de sauvegarde. Utiliser la configuration de la politique de conservation REDUNDANCY à la place de la politique RECOVERY WINDOW peut mener à des échecs de sauvegarde. Assurez-vous d'utiliser la configuration RECOVERY WINDOW OF 30 DAYS.

Configurer le paramètre de politique de conservation RMAN

  1. Recherchez l'ID 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 politique de conservation à RECOVERY WINDOW OF 30 DAYS : 

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

Perte d'un fichier de portefeuille du magasin d'objets et échecs de sauvegarde

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.

Confirmer que le fichier de portefeuille du magasin d'objets existe et dispose des autorisations appropriées

  1. Recherchez l'ID 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 d'accès au fichier des 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

    Par 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 d'accès au fichier de portefeuille dans le fichier de paramètres de configuration de sauvegarde en inspectant la valeur stockée dans le paramètre OPC_WALLET. Pour ce faire, naviguez jusqu'au répertoire contenant le fichier de paramètres de configuration de sauvegarde et utilisez la commande cat suivante : 

    cat <backup_config_parameter_file>

    Par 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 existe dans le répertoire spécifié par le paramètre OPC_WALLET et confirmez que le fichier est doté des autorisations correctes. Les autorisations de fichier doivent avoir la valeur octale "600" (-rw-------). Utilisez la commande suivante : 

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

    Par 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 liés au portefeuille TDE

Les sujets suivants sont abordés :

Spécification de l'emplacement du portefeuille TDE incorrecte

Pour que les opérations de sauvegarde fonctionnent, 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)))

Note :

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

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

Utilisez la commande cat pour vérifier la spécification de l'emplacement du portefeuille TDE. Par 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'était pas définie au démarrage de la base de données avec SQL*Plus

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.

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

srvctl start database -d <db_unique_name>

Une base de données enfichable a été ajoutée avec une clé de chiffrement principale configurée de manière incorrecte

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

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

    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 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 la documentation sur la base de données enfichable de votre version d'Oracle Database.

  3. Exécutez les commandes DBCLI suivantes pour faire passer le statut à OPEN : 

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

    La commande update-tdekey affichée vous demande d'entrer le mot de passe de l'administrateur.

  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.

Vérifier la configuration associée au portefeuille TDE

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

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

    srvctl getenv database -d <db_unique_name>

    Par 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 confirmer que le fichier contient un paramètre ENCRYPTION_WALLET_LOCATION avec la valeur DIRECTORY correcte. Utilisez la commande suivante : 

    cat $ORACLE_HOME/network/admin/sqlnet.ora

    Par 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 open et que le type de portefeuille est Connexion automatique en consultant la vue v$encryption_wallet. Par 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 enfichables, assurez-vous de passer au conteneur approprié avant d'interroger la vue v$encryption_wallet. Par 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 des autorisations ou une responsabilité de système de fichiers incompatibles. Vérifiez le fichier comme illustré 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 avoir les autorisations de fichier avec la valeur octale "700" (-rwx------) et le responsable de ce fichier doit faire partie du groupe de systèmes d'exploitation oinstall.

Fichier de portefeuille à connexion automatique manquant

Le fichier de portefeuille à connexion automatique (cwallet.sso) peut entraîner l'échec des sauvegardes, s'il est manquant ou s'il comporte des autorisations ou une responsabilité de système de fichiers incompatibles. Vérifiez le fichier comme illustré 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 à connexion automatique doit avoir les autorisations de fichier avec la valeur octale "700" (-rwx------) et le responsable de ce fichier doit faire partie du groupe de systèmes d'exploitation oinstall.

Autres causes des échecs de sauvegarde

Les sujets suivants sont abordés :

Point de montage Commonstore non monté

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

Vérifier le point de montage Commonstore

Confirmez 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

Confirmer que ora.data.commonstore.acfs est en ligne

  1. L'état pour ora.data.commonstore.acfs doit être En ligne ou les sauvegardes échouent. Confirmez 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. Listez le contenu du répertoire commonstore pour confirmer 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 illustré dans l'exemple suivant : 

    srvctl start filesystem -volume commonstore -diskgroup data

  4. Vérifiez que la modification a réussi, comme illustré dans l'exemple ci-dessous :

    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. Listez le contenu du répertoire commonstore pour confirmer qu'il est monté, comme illustré 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

La base de données n'est pas enregistrée correctement

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

Pour vérifier si la base de données est correctement enregistrée, vérifiez les informations retournées en exécutant la commande srvctl config database et la commande dbcli list-databases. Si l'une des commandes ne retourne pas d'enregistrement de la base de données, communiquez avec les services Oracle Support.

Pour obtenir des instructions sur l'enregistrement de la base de données, consultez les rubriques suivantes :

Obtenir de l'aide supplémentaire

Si vous ne parvenez pas à résoudre le problème à l'aide des informations de cette rubrique, suivez les procédures ci-dessous pour collecter les informations de base de données et de diagnostic pertinentes. Après avoir collecté ces informations, communiquez avec Oracle Support.

Les sujets suivants sont abordés :

Collecter des informations de base de données à utiliser dans les rapports sur les problèmes

Utilisez les commandes suivantes pour collecter les détails de la 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

Collecter des informations de diagnostic sur les tâches ayant échoué

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

  2. Exécutez les deux commandes suivantes pour générer des informations sur la tâche ayant échoué :

    dbcli list-jobs
    dbcli describe-job -i <job_ID> -j

    La valeur <job_ID> dans la deuxième commande doit être l'ID de la dernière tâche en échec signalée depuis la première commande.

  3. Exécutez le script de collecte de diagnostic pour créer un fichier zip contenant les informations de diagnostic pour les services Oracle Support.

    diagcollector.py

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

Collecter des fichiers journaux d'agent DCS

Pour collecter des fichiers journaux d'agent DCS, effectuez les opérations suivantes :

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

  2. Exécutez la commande suivante :

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

    Le système retourne un message indiquant que les journaux d'agent sont disponibles dans un fichier zip du répertoire spécifié. Par exemple :

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

Collecter les détails de configuration TDE

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

  2. Entrez la sortie de la vue v$encryption_wallet. Par 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

Collecter le fichier de rapport de sauvegarde RMAN

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

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

Par exemple :

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

Localisez le fichier de rapport au moyen de la commande dbcli describe-rmanbackupreport -in <report_name>. L'emplacement du rapport est indiqué dans la sortie. Par 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