Dépannage et problèmes connus pour Exadata Database Services for Azure

Utilisez les informations de cette section pour résoudre les erreurs courantes et les problèmes de provisionnement dans vos environnements Oracle Database@Azure.

Les problèmes abordés dans ce guide ne couvrent pas les problèmes généraux liés à la configuration, aux paramètres et à la configuration de compte Oracle Database@Azure. Pour plus d'informations sur ces rubriques, reportez-vous à Présentation d'Oracle Database@Azure.

Terminaisons et verrous Microsoft Azure pour les services de base de données Exadata

Oracle recommande de supprimer tous les verrous Microsoft Azure sur les ressources Oracle Database@Azure avant de mettre fin à une ressource Exadata Database Services.

Par exemple, si vous avez créé une adresse privée Microsoft Azure, supprimez d'abord cette ressource. Si vous disposez d'une stratégie qui empêche la suppression des ressources verrouillées, le workflow Oracle Database@Azure échoue car Oracle Database@Azure ne peut pas supprimer le verrou.

Le nom de domaine qualifié complet DNS privé ne peut pas contenir plus de quatre (4) libellés pour un cluster de machines virtuelles Oracle Exadata

Lors de la création d'un cluster de machines virtuelles Oracle Exadata, si vous sélectionnez une zone DNS privée dont le nom de domaine qualifié complet comporte plus de 4 libellés (délimités par un point '.'), vous obtenez l'erreur suivante :

Error returned by CreateCloudVmCluster operation in Database service. (400, InvalidParameter, false) domain name cannot contain more than 4 labels
La solution de contournement consiste à renommer le DNS privé à l'origine de l'erreur ou à sélectionner un autre DNS privé dont le nom de domaine qualifié complet comporte quatre (4) étiquettes ou moins.

Erreur non autorisée lorsque le DNS privé sans balises est utilisé pour les services de base de données Exadata

Lors de la création d'un cluster de machines virtuelles Oracle Exadata, si vous sélectionnez une zone DNS privée créée sans balise, la balise OCI par défaut oracle-tags est automatiquement générée pour le cluster de machines virtuelles. Si l'espace de noms de balise n'est pas autorisé dans la location OCI, cela peut entraîner une erreur.

404 NotAuthorizedOrNotFound
La solution consiste à ajouter les stratégies suivantes à la location OCI :
Allow any user to use tag-namespaces in tenancy where request.principal.type = ‘multicloudlink’
Allow any user to manage tag-defaults in tenancy where request.principal.type = ‘multicloudlink’

Différences d'exigences en matière d'adresses IP pour les services de base de données Exadata

Il existe des différences entre les exigences d'adresse IP d'Oracle Database@Azure et d'Oracle Cloud Infrastructure (OCI).

Dans la documentation Exigences relatives à l'espace d'adresse IP, les modifications suivantes doivent être prises en compte pour Oracle Database@Azure.
  • Oracle Database@Azure prend uniquement en charge Exadata X9M. Toutes les autres formes ne sont pas prises en charge.
  • Oracle Database@Azure réserve 13 adresses IP pour le sous-réseau client, contre 3 pour les exigences OCI.

Différences d'unité de transmission maximale (MTU) pour les services de base de données Exadata

L'unité de transmission maximale (MTU) est la taille de trame la plus grande (en octets) qui peut être envoyée. Il s'agit d'un paramètre configurable.

  • Taille MTU par défaut Azure = 1500 octets
  • Taille de MTU par défaut OCI = 9000 octets

En raison des différences de tailles de MTU par défaut, le repérage de MTU de chemin (PMTUD) est requis pour déterminer la MTU appropriée entre les ressources Azure et les services OCI. Pour que PMTUD fonctionne, les clients doivent autoriser Internet Control Message Protocol (ICMP) Type 3 code 4 sur l'ensemble de la pile réseau. La désactivation complète d'ICMP peut entraîner des problèmes de connectivité.

Limitation des zones DNS privées pour les services de base de données Exadata

Lors du provisionnement des services de base de données Exadata, une zone DNS privée peut uniquement sélectionner des zones avec quatre étiquettes ou moins.

Par exemple, a.b.c.d est autorisé, alors que a.b.c.d.e n'est pas autorisé.

Configuration entrante de réseau automatique pour les services de base de données Exadata

Vous pouvez connecter une machine virtuelle Microsoft Azure à un cluster de machines virtuelles Oracle Exadata si les deux se trouvent sur le même réseau virtuel (VNet). La fonctionnalité est automatique et ne nécessite aucune modification supplémentaire des règles de groupe de sécurité réseau. Si vous devez connecter une machine virtuelle Microsoft Azure à partir d'un fichier VNet différent de celui où le cluster de machines virtuelles Oracle Exadata a été créé, une étape supplémentaire pour configurer des règles de trafic de groupe de sécurité réseau afin de permettre au trafic de l'autre réseau virtuel de circuler correctement.

Par exemple, si vous disposez de deux (2) VNets (A et B) avec VNet A pour la machine virtuelle Microsoft Azure et VNet B pour le cluster de machines virtuelles Oracle Exadata, vous devez ajouter l'adresse CIDR de VNet A à la table de routage de groupe de sécurité réseau dans OCI.

Tableau 1-4 Règles de groupe de sécurité réseau client par défaut

Orientation Source ou destination Protocole Détails Description

Direction : sortie

Sans conservation de statut : non

Type de destination : CIDR

Date de destination : 0.0.0.0/0

Tous les protocoles Autoriser : tout le trafic pour tous les ports Règle sortante de groupe de sécurité réseau par défaut

Direction : Entrée

Sans conservation de statut : non

Type de source : CIDR

Source : CIDR VNet Microsoft Azure

TCP

Plage de ports source : Tout

Plage de ports de destination : tout

Autoriser : trafic TCP pour les ports : tous

Entrée de tout TCP à partir de Microsoft Azure VNet.

Direction : Entrée

Sans conservation de statut : non

Type de source : CIDR

Source : CIDR AzureVNet Microsoft

ICMP

Type : Tout

Code : Tout

Autoriser : trafic ICMP pour : Tout

Entrant tous les ICMP de Microsoft Azure VNet.

Tableau 1-5 Règles de groupe de sécurité réseau de sauvegarde par défaut

Orientation Source ou destination Protocole Détails Description

Direction : sortie

Sans conservation de statut : non

Type de destination : Service

Destination : stockage d'objets OCI IAD

TCP

Plage de ports source : Tout

Plage de ports de destination : 443

Autoriser : trafic TCP pour les ports : HTTPS 443

Permet d'accéder au stockage d'objets.

Direction : Entrée

Sans conservation de statut : non

Type de source : CIDR

Source : 0.0.0.0/0

ICMP

Type : 3

Code : 4

Autoriser : Trafic ICMP pour : 3, 4 Destination inaccessible : La fragmentation est requise et l'option Ne pas fragmenter a été définie

Autorise les messages de fragmentation de repérage de MTU de chemin.
Remarque

Les fonctionnalités de mise en réseau avancées d'Azure, qui incluent Azure Private Link, la prise en charge de plusieurs groupes de sécurité réseau et l'appairage de réseau virtuel global (VNet), permettent d'utiliser des sous-réseaux délégués Azure avec des clusters de machines virtuelles Oracle Exadata. Pour plus d'informations, reportez-vous à Planification réseau pour Oracle Database@Azure.

Echec du provisionnement du cluster de machines virtuelles Oracle Exadata avec une erreur d'autorisation

Le provisionnement d'un cluster de machines virtuelles Oracle Exadata échoue avec une erreur d'autorisation comme suit :

Authorization Failed
The client <client_name> with object id <object_id> does not have authorization to perform action 'Oracle.Database/location/operationStatuses/read' over scope <scope_details> or scope is invalid. If access was recently granted, please refresh your credentials.
L'échec se produit car l'utilisateur exécutant l'action ne dispose pas de droits d'accès Azure pour la ressource Microsoft.BareMetal/BareMetalConnections.
Solution de contournement
  1. Assurez-vous qu'aucune stratégie Azure affectée à l'utilisateur ou à l'abonnement n'empêche l'utilisateur d'effectuer l'action. Si des autorisations spécifiques sont affectées directement à l'utilisateur, ajoutez les ressources suivantes à la liste des autorisations.
    • Microsoft.BareMetal/BareMetalConnections
    • Microsoft.Network/privateDnsZones
  2. Supprimez le cluster de machines virtuelles Exadata en échec de l'interface utilisateur Azure.
  3. Attendez 30 minutes pour vous assurer que le cluster de machines virtuelles Exadata est entièrement arrêté dans Azure et OCI. Cette période d'attente garantit que toutes les ressources dépendantes sont également supprimées.
  4. Provisionnez le nouveau cluster de machines virtuelles Exadata.

Impossible de supprimer l'infrastructure Exadata

Azure dispose d'un délai d'expiration ciblé allant jusqu'à une (1) heure pour la suppression d'un cluster de machines virtuelles Exadata. Cette fois-ci, il peut arriver que toutes les ressources dépendantes de l'infrastructure Exadata ne soient pas totalement supprimées, en particulier les ressources réseau.

Azure peut faire passer le statut du cluster de machines virtuelles Exadata à TERMINATED, mais dans OCI, les ressources dépendantes peuvent toujours être enlevées. Dans ce cas, si le client tente de supprimer l'infrastructure de machine virtuelle Exadata ET que la suppression du cluster de machines virtuelles Exa n'est pas terminée côté OCI, le message d'erreur suivant apparaît :
Cannot delete Exadata infrastructure. All associated VM clusters must be deleted before you delete the Exadata infrastructure. (Code: 400)
La solution de contournement consiste à attendre la fin de tous les clusters de machines virtuelles Exadata associés à l'infrastructure Exadata dans OCI.

Le statut "Redimensionnement en cours" ne s'affiche pas pour la base de données pluggable

Les bases de données pluggables n'affichent pas le statut "Redimensionnement en cours" lorsqu'une opération de redimensionnement est en cours.

Au lieu de cela, le statut de la base de données pluggable passe de "Accepté" à "Mise à jour". Aucune solution de contournement disponible.

Echec du provisionnement de cluster de machines virtuelles Oracle Exadata car le nombre d'adresses IP disponibles signalées par OCI et Azure ne correspond pas

Azure signale le nombre incorrect d'adresses IP disponibles dans le sous-réseau, ce qui entraîne l'échec du provisionnement du cluster de machines virtuelles Oracle Exadata. Cela entraîne l'erreur suivante :

Error returned by CreateCloudVmCluster operation in Database service.(400, InvalidParameter, false) Cidr block of the subnet must have at least 11 ip addresses available.
Vérifiez le nombre correct d'adresses IP disponibles dans le sous-réseau à l'aide de la console OCI. Pour plus d'informations, reportez-vous à Liste des adresses IP privées. La solution consiste à reconfigurer le sous-réseau en fonction des prérequis.

Mesures signalant des pertes dans Microsoft Azure

Si un exportateur envoie une mesure de plus de 20 minutes, les agents l'abandonnent et les clients perdent ces données.

Ce délai de 20 minutes est une limitation de Microsoft Azure et s'applique à tout exportateur. Par exemple, voici quelques scénarios dans lesquels des mesures peuvent être perdues.
  • Certificats arrivés à expiration. L'exportateur ne peut pas établir de connexion avec l'agent et un arriéré de builds de mesures. Après la rotation vers de nouveaux certificats, les mesures sont obsolètes et, comme elles datent de plus de 20 minutes, l'agent supprime les mesures et les clients voient ces mesures.
  • Retard : Lorsque l'exportateur, pour une raison quelconque, développe un arriéré qui fait que l'exportateur prend plus de temps que d'habitude pour traiter les métriques, la métrique sera perdue si elles sont reçues par l'agent de plus de 20 minutes.
Il ne s'agit pas d'une liste exhaustive d'exemples, mais vise à fournir un contexte aux mesures signalant une perte.

Obtention de l'erreur "ResourceMoveProviderValidationFailed" lors de la tentative de déplacement de ressources OracleDB@Azure vers un autre groupe de ressources

Le déplacement de ressources Oracle Database@Azure n'est pas pris en charge actuellement à l'aide de la fonctionnalité de déplacement de ressources dans Azure.

Lorsque vous tentez de déplacer une ressource Oracle Database@Azure, vous obtenez l'erreur suivante :
(Code: ResourceMoveProviderValidationFailed) Resource provider 'Oracle.Database' failed to process resource move validation for resource type '<RESOURCE_TYPE>'

Pour résoudre ce problème et pour plus d'informations, reportez-vous à l'article suivant.

Impossible de créer une règle de groupe de sécurité réseau entrante sans indiquer le port source

Pour résoudre ce problème, procédez comme suit :

  • Utilisez la valeur "Tous" les ports dans les règles Groupes de sécurité réseau (NSG).
  • Les règles de groupe de sécurité réseau exigent que vous définissiez un port ou une plage de ports lorsque vous utilisez TCP ou UDP. Pour autoriser tous les ports, vous devez sélectionner Tous les protocoles au lieu de TCP/UDP.
  • Sélectionnez l'option Tous les protocoles lorsque vous voulez ajouter une règle. Cette configuration active tous les ports (1-65535) sur tous les protocoles.

Pour plus d'informations, reportez-vous à la documentation suivante.

Pour gérer les règles de groupe de sécurité réseau, reportez-vous à la documentation.

Ressource de base de données supprimée dans Azure mais pas dans OCI

Lorsque vous rencontrez le problème de suppression d'une ressource de cluster de machines virtuelles Exadata dans Azure mais pas d'enlèvement d'OCI, créez une demande d'assistance pour demander un accès temporaire à la suppression de la ressource.

Erreur :

DeleteCloudVmCluster operation is blocked for resources deployed at Azure. Please try this operation from Azure or contact support for further assistance.

Pour résoudre ce problème, reportez-vous à Création d'une demande d'assistance pour plus d'informations.