Dépannage d'Autonomous Database on Dedicated Exadata Infrastructure

Impossible d'accéder aux clés de cryptage maître

S'APPLIQUE À : Oracle Public Cloud uniquement

Cause potentielle

Le cluster de machines virtuelles Exadata Autonomous (AVMC) n'est pas en mesure d'atteindre la clé de cryptage maître.

Action suggérée

Vérifiez que la clé de cryptage maître est accessible à partir d'AVMC.

Résolution

Assurez-vous que la passerelle de service est activée pour le sous-réseau AVMC avec Destination : tous les services IAD dans Oracle Services Network.

Assurez-vous que la stratégie 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’
}

Références supplémentaires

Live Lab : Oracle Autonomous Database Dedicated pour les administrateurs de la sécurité
Documentation : Préparation pour l'utilisation de clés gérées par le client dans le service Vault

Impossible d'accéder au coffre

S'APPLIQUE À : Oracle Public Cloud uniquement

Cause potentielle

Le cluster de machines virtuelles Exadata Autonomous (AVMC) ne peut pas lire le coffre.

Action suggérée

Vérifiez que le coffre est accessible depuis 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 stratégie IAM suivante est définie pour le groupe dynamique

allow dynamic-group <dynamic-group> 
to read vaults 
in tenancy | compartment <vaults-and-keys-compartment>

Références supplémentaires

Live Lab : Oracle Autonomous Database Dedicated pour les administrateurs de la sécurité
Documentation : Préparation pour l'utilisation de clés gérées par le client dans le service Vault

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

S'APPLIQUE À : Exadata Cloud@Customer uniquement

Cause potentielle

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

Action suggérée

Vérifiez que le NFS est accessible à partir du réseau AVMC (Autonomous Exadata VM Cluster).

Résolution

Vérifiez le routage réseau et réessayez. Toutes les adresses IP doivent être accessibles via le réseau de sauvegarde d'AVMC.
Déconnectez et reconnectez le NFS.
Attachez un NFS secondaire partagé.

Références supplémentaires

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

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

S'APPLIQUE À : Exadata Cloud@Customer uniquement

Causes potentielles

Chemin d'export incorrect.
Absence de droits d'accès appropriés sur le chemin d'export.
Aucun accès réseau entre les adresses IP client de cluster de machines virtuelles Exadata Autonomous et le serveur NFS.

Actions suggérées

Vérifiez le chemin et les droits d'accès de l'export.
Vérifiez que les ports d'accès sont ouverts entre le serveur NFS et les adresses IP client.

Résolution

Assurez-vous que export_path est correct.
Assurez-vous que l'utilisateur Oracle dispose des droits d'accès sur export_path
- uid:gid de l'utilisateur Oracle pour le cluster de machines virtuelles Autonomous doit être 1001:1001
Assurez-vous qu'aucun pare-feu ne bloque l'accès réseau entre les adresses IP client AVMC et le serveur NFS.
Si l'accès réseau à NFS se fait via des adresses IP de sauvegarde, créez une demande de service pour les opérations Autonomous Database afin d'implémenter des règles de routage afin de détourner le trafic vers NFS via des adresses IP de sauvegarde.

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

S'APPLIQUE À : Exadata Cloud@Customer uniquement

Cause potentielle

Droits d'accès incorrects sur le montage NFS.

Action suggérée

Vérifiez si le montage NFS dispose des droits d'accès appropriés.

Résolution

Assurez-vous que l'utilisateur Oracle dispose des droits d'accès appropriés sur le montage NFS.

uid:gid de l'utilisateur Oracle pour le cluster de machines virtuelles Autonomous 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 potentielle

Règles sortantes HTTPS et SMTP manquantes.

Action suggérée

Activez l'accès réseau pour APEX en fonction de vos besoins pour des tâches telles que l'envoi de courriels ou l'accès aux ressources REST (ou 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 réseau via APEX (comme configuré précédemment prêt à l'emploi), procédez comme suit :

Le nom de principal indiqué doit correspondre au schéma d'installation APEX. Par exemple, il peut s'agir de APEX_210200.
Le nom de schéma Apex d'un déploiement particulier dépend de la version et peut être trouvé avec la requête suivante :
```
select schema from dba_registry where comp_id='APEX'
```
Les listes de contrôle d'accès créées pour d'autres utilisateurs, comme ADMIN, n'auront aucune incidence sur l'accès via APEX. Ces listes de contrôle d'accès n'ont d'incidence que sur les cas d'emploi où ADMIN ou le code appartenant à ADMIN est directement appelé UTL_HTTP ou UTL_SMTP.

Références supplémentaires

Documentation présentant la règle générique autorisant l'accès à tous les hôtes et une règle plus restrictive autorisant l'accès à l'hôte local : Activation des services réseau dans Oracle Database
Pour plus de détails sur l'ajout de règles autorisant des hôtes ou des modèles de caractères génériques spécifiques, reportez-vous à APPEND_HOST_Procedure dans Référence des types et des packages PL/SQL Oracle Database 19c ou Référence des types et des packages PL/SQL Oracle Database 23ai.

Problèmes de conservation des sauvegardes avec ZDLRA

S'APPLIQUE À : Exadata Cloud@Customer uniquement

Cause potentielle

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

Action suggérée

Pour nous aider à comprendre et à résoudre le problème, veuillez suivre la note My Oracle Support (MOS) suivante qui vous explique comment collecter des données de diagnostic, ce qui aidera le Support à réduire la cause de votre problème.
Rapport d'activité du système : SRDC - Collecte de données Zero Data Loss Recovery Appliance (ZDLRA) (ID de document 2154189.1)
Si l'instance Recovery Appliance est supérieure ou égale à la version 19.2.1.1.2, la commande suivante peut également être utilisée pour générer le rapport d'activité système (SAR), mais elle sera générée au format texte uniquement :
```
racli run diagnostics --tag=sar
```
Cette commande génère un package de diagnostic.
Soumettez une demande d'assistance (SR) dans My Oracle Support avec les résultats du diagnostic.

Résolution

Une fois que vous avez soumis la demande de service avec les résultats de diagnostic, l'équipe de support technique Oracle vous contactera pour résoudre le problème correspondant.

Références supplémentaires

Documentation : Création d'une demande d'assistance dans My Oracle Support

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

Cause potentielle

Chaque fois que vous tentez de vous connecter à Autonomous Database on Dedicated Exadata Infrastructure avec SQL*Plus, il tente d'atteindre ONS sur le port 6200 pour s'abonner aux événements FAN, une fois par noeud. Si la demande d'accès au noeud 6200 expire en raison d'un délai d'attente au bout de 10 secondes (par noeud), elle se poursuit avec le SQLNET 1521/2484 régulier, ce qui entraîne un retard de connexion.

Vous pouvez avoir une entrée bloquée sur domU pour le port 6200 ou une sortie bloquée sur l'hôte client.

Action suggérée

Fournissez des règles entrantes et sortantes pour le port FAN 6200 ou désactivez l'abonnement aux événements FAN sur votre client.

Résolution

Pour résoudre ce problème, vous avez deux options :

Désactivez l'abonnement aux événements FAN sur votre client en mettant à jour le fichier XML oraaccess.

Le fichier oraaccess.xml vous permet de remplacer les paramètres spécifiques à la connexion en fonction des exigences de chaque application. Pour obtenir des exemples, reportez-vous à Remplacement des paramètres de connexion au niveau de la chaîne de connexion.
Corrigez la connectivité au port 6200 de l'hôte client vers domU en fournissant les règles entrantes et sortantes pour le port FAN 6200, comme décrit à l'Step 4. Créez le VCN et les sous-réseaux.

Références supplémentaires