Dépannage d'une base de données avec intelligence artificielle autonome sur une infrastructure Exadata dédiée

Utilisez les sections suivantes pour résoudre les problèmes que vous rencontrez avec Oracle Autonomous AI Database sur une infrastructure Exadata dédiée sur Oracle Public Cloud et les plates-formes Exadata Cloud@Customer.

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

S'APPLIQUE À : Applicable Oracle Public Cloud seulement

Cause potentielle

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

Laboratoire en direct : Oracle Autonomous AI Database Dedicated pour les administrateurs de la sécurité
Documentation : Se préparer à utiliser les clés gérées par le client dans le service de chambre forte

Impossible d'accéder à la chambre forte

S'APPLIQUE À : Applicable Oracle Public Cloud seulement

Cause potentielle

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

Laboratoire en direct : Oracle Autonomous AI Database Dedicated pour les administrateurs de la sécurité
Documentation : Se préparer à utiliser les clés gérées par le client dans le service de chambre forte

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

APPLICATIONS À : Applicable Exadata Cloud@Customer seulement

Cause potentielle

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

Action proposée

Vérifiez que 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 de l'AVMC.
Déconnectez et rattachez le NFS.
Joindre le serveur 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)

APPLICATIONS À : Applicable Exadata Cloud@Customer seulement

Causes potentielles

Chemin d'exportation incorrect.
Absence des autorisations appropriées sur le chemin d'exportation.
Aucun accès réseau entre les adresses IP de client de grappe de machines virtuelles Exadata autonome (AVMC) et le serveur NFS.

Actions suggérées

Vérifiez le chemin d'exportation et les autorisations associées.
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 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 de base de données Autonomous AI Database afin de mettre en oeuvre des règles de routage afin de 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)

APPLICATIONS À : Applicable Exadata Cloud@Customer seulement

Cause potentielle

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 de l'autorisation appropriée sur 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 potentielle

Règles de trafic sortant https 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 basées sur 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 précédemment configuré prêt à l'emploi) :

Le nom principal spécifié 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 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, comme ADMIN, n'auront pas d'incidence sur l'accès au moyen d'APEX. De telles listes de contrôle d'accès n'affecteraient que les cas d'utilisation où ADMIN ou le code détenu par ADMIN est directement appelé UTL_HTTP ou UTL_SMTP.

Informations de référence supplémentaires

Documentation qui présente la règle générique qui autoriserait l'accès à tous les hôtes, et une règle plus restrictive subséquente qui autoriserait l'accès localhost : 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, consultez APPEND_HOST_Procedure dans Informations de référence sur les ensembles et les types PL/SQL pour Oracle Database 19c ou Informations de référence sur les ensembles et les types PL/SQL pour Oracle Database 26ai.

Problèmes de conservation des sauvegardes avec ZDLRA

APPLICATIONS À : Applicable Exadata Cloud@Customer seulement

Cause potentielle

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

Action proposée

Pour nous aider à comprendre et à résoudre le problème, suivez la note My Oracle Support (MOS) suivante qui vous explique comment collecter des données de diagnostic, ce qui aidera le soutien à limiter 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 sera générée dans un format de texte uniquement :
```
racli run diagnostics --tag=sar
```
Cette commande génère un package Diagnostics.
Soumettre une demande de service dans My Oracle Support avec les résultats de diagnostic.

Résolution

Après avoir soumis la demande de service avec les résultats de diagnostic, l'équipe Oracle Support communiquera avec vous pour résoudre le problème correspondant.

Informations de référence supplémentaires

Documentation : Créer une demande de service dans My Oracle Support

Retard de connexion à une base de données autonome avec SQL*Plus

Cause potentielle

Chaque fois que vous essayez de vous connecter à une base de données d'IA autonome sur une infrastructure Exadata dédiée avec SQL*Plus, elle 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 :

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 propres à la connexion en fonction des exigences de chaque application. Voir Remplacement des paramètres de connexion au niveau de la chaîne de connexion pour des exemples.
Corrigez la connectivité au port 6200 de l'hôte client à domU en fournissant les règles de trafic entrant et sortant pour le port FAN 6200, comme décrit à l'étape 4. Créez le VCN et les sous-réseaux.