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

Utilisez les sections suivantes pour résoudre les problèmes rencontrés avec les plates-formes Oracle Autonomous AI Database on Dedicated Exadata Infrastructure on Oracle Public Cloud et Exadata Cloud@Customer.

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

S'APPLIQUE À : Applicable Oracle Public Cloud uniquement

Cause potentielle

Le cluster de machines virtuelles Exadata Autonomous ne parvient pas à 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 AI Database dédié aux administrateurs de sécurité
Documentation : Préparation pour l'utilisation de clés gérées par l'utilisateur dans le service Vault

Impossible d'accéder au coffre

S'APPLIQUE À : Applicable Oracle Public Cloud uniquement

Cause potentielle

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

Action suggérée

Vérifiez que le coffre 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

Vérifiez 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 AI Database dédié aux administrateurs de sécurité
Documentation : Préparation pour l'utilisation de clés gérées par l'utilisateur dans le service Vault

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

S'applique à : Applicable 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 NFS est accessible à partir du réseau de cluster de machines virtuelles Exadata Autonomous (AVMC).

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.
Attachez le 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 à : Applicable Exadata Cloud@Customer uniquement

Causes potentielles

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

Actions suggérées

Vérifiez le chemin d'export et les autorisations sur le chemin d'export.
Vérifiez que les ports d'accès sont ouverts entre les adresses IP du serveur NFS et du 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
- La valeur 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 de base de données Autonomous AI afin d'implémenter des règles de routage pour détourner le trafic vers NFS via des adresses IP de sauvegarde.

Impossible d'écrire un fichier dans NFS (Network File System)

S'applique à : Applicable Exadata Cloud@Customer uniquement

Cause potentielle

Autorisations incorrectes 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 du droit d'accès sur le montage NFS.

La valeur uid:gid de l'utilisateur Oracle pour le cluster de machines virtuelles Autonomous doit être 1001:1001

Impossible d'obtenir le trafic sortant depuis 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 selon vos besoins pour des tâches telles que l'envoi de courriels ou l'accès à des ressources REST (ou HTTP). L'accès ne sera disponible qu'une fois que l'utilisateur l'aura configuré.

Résolution

Pour accorder un accès réseau via APEX (tel que configuré précédemment par défaut) :

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 se trouve à l'aide de 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 via APEX. Ces listes de contrôle d'accès n'ont d'incidence que sur les cas d'utilisation où ADMIN ou le code appartenant à ADMIN directement appelé UTL_HTTP ou UTL_SMTP.

Références supplémentaires

Documentation illustrant la règle générique qui autorise l'accès à n'importe quel hôte, et une règle plus restrictive qui autorise 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, reportez-vous à APPEND_HOST_Procedure dans Oracle Database 19c PL/SQL Packages and Types Reference ou Oracle Database 26ai PL/SQL Packages and Types Reference.

Problèmes de conservation des sauvegardes avec ZDLRA

S'applique à : Applicable Exadata Cloud@Customer uniquement

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 suggéré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 support technique à déterminer 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 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 Diagnostics.
Soumettez une demande d'assistance sur le site My Oracle Support avec les résultats du diagnostic.

Résolution

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

Références supplémentaires

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

Délai de connexion à une base de données d'IA autonome avec SQL*Plus

Cause potentielle

Chaque fois que vous tentez de vous connecter à la base de données Autonomous AI sur une infrastructure Exadata dédiée 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 le 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

Vous avez deux possibilités 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 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.