Dépannage d'Autonomous Database sur une infrastructure Exadata dédiée

Utilisez les sections suivantes pour vous aider à résoudre les problèmes que vous avez avec les plates-formes Oracle Autonomous Database on Dedicated Exadata Infrastructure sur Oracle Public Cloud et Exadata Cloud@Customer.

Impossible d'accéder aux clés de chiffrement principales

S'applique à : Applicable Oracle Public Cloud seulement

Cause possible

La grappe de machines virtuelles Exadata autonome (AVMC) ne peut pas atteindre la clé de chiffrement principale.

Action proposée

Vérifiez que la clé de chiffrement principale est accessible à partir de la grappe de machines virtuelles autonome.

Résolution

  • Assurez-vous que la passerelle de service est activée pour le sous-réseau AVMC avec la destination : Tous les services IAD dans Oracle Services Network.
  • Assurez-vous que la politique IAM suivante est définie pour le groupe dynamique :
    allow dynamic-group <dynamic-group-name> 
to manage keys 
in compartment <vaults-and-keys-compartment>
where all {
    target.key.id='<key_ocid>',        
    request.permission!='KEY_DELETE',
    request.permission!='KEY_MOVE',
    request.permission!='KEY_IMPORT',
    request.permission!='KEY_BACKUP’
}

Informations de référence supplémentaires

Impossible d'accéder à la chambre forte

S'applique à : Applicable Oracle Public Cloud seulement

Cause possible

La grappe de machines virtuelles Exadata autonome (AVMC) ne peut pas lire la chambre forte.

Action proposée

Vérifiez que la chambre forte est accessible à partir de l'AVMC.

Résolution

  • Assurez-vous que la passerelle de service est activée pour le sous-réseau AVMC avec la destination : Tous les services IAD dans Oracle Services Network
  • Assurez-vous que la politique IAM suivante est définie pour le groupe dynamique
    allow dynamic-group <dynamic-group> 
to read vaults 
in tenancy | compartment <vaults-and-keys-compartment>

Informations de référence supplémentaires

Échec de la sauvegarde sur le système de fichiers réseau (NFS)

S'APPLIQUE À : Applicable Exadata Cloud@Customer seulement

Cause possible

La destination NFS peut être inaccessible en raison d'un problème de réseau.

Action proposée

Vérifiez que le NFS est accessible à partir du réseau de la grappe de machines virtuelles Exadata autonome (AVMC).

Résolution

  • Vérifiez le routage réseau et réessayez. Toutes les adresses IP doivent être accessibles sur le réseau de sauvegarde de l'AVMC.
  • Déconnectez et rattachez le NFS.
  • Attacher le NFS secondaire partagé.

Informations de référence supplémentaires

Documentation : À propos de la sauvegarde et de la récupération

Impossible de monter le système de fichiers réseau (NFS)

S'APPLIQUE À : Applicable Exadata Cloud@Customer seulement

Causes potentielles

  • Chemin d'exportation incorrect.
  • Autorisations insuffisantes sur le chemin d'exportation.
  • Aucun accès réseau entre les adresses IP de client de grappe de machines virtuelles Exadata autonome et le serveur NFS.

Actions suggérées

  • Vérifiez le chemin d'exportation et les autorisations associées au chemin d'exportation.
  • Vérifiez que les ports d'accès sont ouverts entre le serveur NFS et les adresses IP de client.

Résolution

  • Assurez-vous que export_path est exact.
  • Assurez-vous que l'utilisateur Oracle dispose de l'autorisation sur export_path
    • uid:gid de l'utilisateur Oracle pour la grappe de machines virtuelles autonome doit être 1001:1001
  • Assurez-vous qu'aucun pare-feu ne bloque l'accès réseau entre les adresses IP du client AVMC et le serveur NFS.
  • Si l'accès réseau à NFS se fait au moyen des adresses IP de sauvegarde, créez une demande de service pour les opérations Autonomous Database afin de mettre en oeuvre des règles de routage pour détourner le trafic vers NFS au moyen des adresses IP de sauvegarde.

Impossible d'écrire un fichier dans le système de fichiers réseau (NFS)

S'APPLIQUE À : Applicable Exadata Cloud@Customer seulement

Cause possible

Autorisations incorrectes sur le montage NFS.

Action proposée

Vérifiez si le montage NFS dispose des autorisations appropriées.

Résolution

Assurez-vous que l'utilisateur Oracle dispose des autorisations appropriées pour le montage NFS.
  • uid:gid de l'utilisateur Oracle pour la grappe de machines virtuelles autonome doit être 1001:1001

Impossible d'obtenir le trafic sortant à partir d'APEX

Code d'erreur 

OPC :ORA-24247 WHILE TRYING TO USE APEX_INSTANCE_ADMIN.VALIDATE_EMAIL_CONFIG

Cause possible

Règles de trafic sortant HTTP et SMTP manquantes.

Action proposée

Activer l'accès réseau pour APEX selon vos besoins pour des tâches telles que l'envoi de courriels ou l'accès à des ressources REST (ou à d'autres ressources HTTP). L'accès ne sera disponible qu'une fois que l'utilisateur l'aura configuré.

Résolution

Pour accorder l'accès au réseau au moyen d'APEX (comme cela a été précédemment configuré de manière prête à l'emploi) :
  • Le nom de principal spécifié doit correspondre au schéma d'installation APEX, par exemple APEX_210200.
  • Le nom de schéma apex d'un déploiement particulier dépend de la version et peut être trouvé avec l'interrogation suivante :
    select schema from dba_registry where comp_id='APEX'
  • Les listes de contrôle d'accès créées pour d'autres utilisateurs, telles que ADMIN, n'auront aucune incidence sur l'accès au moyen d'APEX. Ces listes de contrôle d'accès n'auraient d'incidence que sur les cas d'utilisation où ADMIN ou le code appartenant à ADMIN directement appelé UTL_HTTP ou UTL_SMTP.

Informations de référence supplémentaires

Problèmes de conservation des sauvegardes avec ZDLRA

S'APPLIQUE À : Applicable Exadata Cloud@Customer seulement

Cause possible

La cause première dépend des détails du rapport de diagnostic généré selon les suggestions ci-dessous.

Action proposée

  • Pour nous aider à comprendre et à résoudre le problème, veuillez suivre la note My Oracle Support (MOS) suivante qui vous explique en collectant des données de diagnostic, ce qui aidera le support à préciser la cause de votre problème.

    Rapport d'activité du système : SRDC - Collecte de données Zero Data Loss Recovery Appliance (ZDLRA) (ID document 2154189.1)

  • Si le boîtier ZDLRA est supérieur ou égal à la version 19.2.1.1.2, la commande suivante peut également être utilisée pour générer le rapport d'activité du système (SAR), mais elle ne sera générée qu'au format texte :
    racli run diagnostics --tag=sar

    Cette commande génère un package Diagnostics.

  • Soumettez une demande de service dans My Oracle Support avec les résultats de diagnostic.

Résolution

Une fois la demande de service soumise avec les résultats de diagnostic, l'équipe d'Oracle Support communiquera avec vous pour résoudre le problème correspondant.

Informations de référence supplémentaires

Délai de connexion à Autonomous Database avec SQL*Plus

Cause potentielle

Chaque fois que vous essayez de vous connecter à Autonomous Database sur une infrastructure Exadata dédiée avec SQL*Plus, il tente d'atteindre ONS sur le port 6200 pour s'abonner à des événements FAN, une fois par noeud. Si la requête pour atteindre le nœud 6200 expire en raison d'une temporisation après 10 secondes (par nœud), elle se poursuit avec SQLNET 1521/2484 régulier, ce qui entraîne un retard de connexion.

Vous pouvez avoir un trafic entrant bloqué sur domU pour le port 6200 ou un trafic sortant bloqué sur l'hôte client.

Action proposée

Fournir des règles de trafic entrant et sortant pour le port FAN 6200 ou désactiver l'abonnement aux événements FAN sur votre client.

Résolution

Vous disposez de deux options pour résoudre ce problème :

Informations de référence supplémentaires