Problèmes connus

Les listes suivantes décrivent les problèmes connus d'Oracle Cloud Infrastructure.

Announcements

Actuellement, il n'existe aucun problème connu lié à Announcements.

API Gateway

Les passerelles d'API n'héritent pas des serveurs DNS personnalisés des sous-réseaux

Détails : le résolveur Oracle Cloud Infrastructure par défaut résout les adresses d'URL publiques (et les adresses d'URL avec des noms d'hôte publics) en adresses IP. De plus, un sous-réseau peut être configuré avec un serveur DNS personnalisé qui résout les adresses d'URL de nom d'hôte interne (et de nom d'hôte privé) en adresses IP. Cependant, les passerelles d'API que vous créez avec le service API Gateway n'héritent pas des serveurs DNS personnalisés des sous-réseaux. A la place, les passerelles d'API utilisent le résolveur Oracle Cloud Infrastructure par défaut, qui ne résout pas les adresses d'URL de nom d'hôte interne/privé.

En raison de cette restriction, si vous créez une passerelle d'API disposant d'une adresse d'URL de nom d'hôte interne/privé en tant que back-end d'URL HTTP ou HTTPS, les appels à l'API échoueront car le nom d'hôte ne peut pas être résolu en adresse IP.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution. En attendant, si vous voulez créer une passerelle d'API disposant d'une adresse d'URL interne/privée en tant que back-end d'URL HTTP ou HTTPS, vous devez indiquer l'adresse IP de l'hôte dans l'URL plutôt que le nom d'hôte. Par ailleurs, si le back-end est une URL HTTPS, vous devez également sélectionner l'option Désactiver la vérification SSL dans la console (ou inclure isSSLVerifyDisabled: true dans le fichier JSON de spécification de déploiement d'API).

Lien direct vers ce problème : Les passerelles d'API n'héritent pas des serveurs DNS personnalisés des sous-réseaux

Application Migration

Echec de la migration pour les applications Oracle Java Cloud Service portant des noms longs

Détails : Application Migration ne prend pas en charge la migration des applications Oracle Java Cloud Service dont le nom comporte plus de 28 caractères.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution. Avant de commencer la migration d'une application Oracle Java Cloud Service, renommez-la afin que son nom comporte moins de 28 caractères.

Lien direct vers ce problème : Echec de la migration pour les applications Oracle Java Cloud Service portant des noms longs

Attributs non pris en charge pour l'application Oracle Analytics Cloud - Classic

Détails : lorsque vous créez une migration pour l'application Oracle Analytics Cloud - Classic à l'aide de l'API ou de la CLI, vous devez obligatoirement fournir des valeurs pour les attributs serviceInstanceUser et serviceInstancePassword. Cependant, Application Migration ignore ces valeurs.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution. Vous pouvez saisir n'importe quelle valeur pour ces attributs, par exemple "non utilisé".

Lien direct vers ce problème : Attributs non pris en charge pour l'application Oracle Analytics Cloud - Classic

Paramètres de requête non pris en charge dans la commande listSourceApplications

Détails : la commande listSourceApplications ne prend pas en charge les paramètres de requête suivants : limit, page, sortOrder et sortBy.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution. N'utilisez pas ces paramètres de requête pour filtrer les résultats de recherche.

Lien direct vers ce problème : Paramètres de requête non pris en charge dans l'opération listSourceApplications

Paramètre de requête non pris en charge dans la commande listMigrations

Détails : la commande listMigrations ne prend pas en charge le paramètre de requête lifecycleState.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution. N'utilisez pas ce paramètre de requête pour filtrer les résultats de recherche.

Lien direct vers ce problème : Paramètre de requête non pris en charge dans la commande listMigrations

Audit

Actuellement, il n'existe aucun problème connu lié à Audit.

Block Volume

Evénement de fin de modification de compartiment non émis pour les volumes de blocs et les volumes d'initialisation

Détails : les événements com.oraclecloud.blockvolumes.changevolumecompartment.end et com.oraclecloud.blockvolumes.changebootvolumecompartment.end ne sont pas émis par le service Block Volume après les événements de début correspondants, même lorsque les opérations sont terminées.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution. Vérifiez directement que votre ressource a été déplacée vers le nouveau compartiment.

Lien direct vers ce problème : Evénement de fin de modification de compartiment non émis pour les volumes de blocs et les volumes d'initialisation

Informations manquantes dans les événements updatevolumekmskey et updatebootvolumekmskey pour les volumes de blocs et les volumes d'initialisation

Détails : les événements com.oraclecloud.blockvolumes.updatevolumekmskey.begin et com.oraclecloud.blockvolumes.updatebootvolumekmskey.begin ne comportent pas le champ current, qui doit contenir l'ID de clé KMS de la nouvelle clé à configurer pour le volume. Au lieu de cela, le champ previous contient cette valeur, alors qu'il devrait contenir l'ID de clé KMS précédent.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution. Vérifiez que votre ressource dispose de l'ID de clé KMS attendu après la mise à jour.

Lien direct vers ce problème : Informations manquantes dans les événements updatevolumekmskey et updatebootvolumekmskey pour les volumes de blocs et les volumes d'initialisation

Format du champ volumeId incorrect dans l'événement de création avec sauvegardes de volume d'initialisation et de volume manuelles

Détails : le champ volumeId dans additionalDetails pour les événements com.oraclecloud.blockvolumes.createvolumebackup.end et com.oraclecloud.blockvolumes.createbootvolumebackup.end est formaté comme un objet et non comme une chaîne pour les sauvegardes créées manuellement. Cela signifie que les règles définies pour être déclenchées en fonction de ce champ ne le seront pas pour les sauvegardes créées manuellement. Ce champ est formaté correctement en tant que chaîne pour les sauvegardes programmées.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution.

Lien direct vers ce problème : Format du champ volumeId incorrect dans l'événement de création avec sauvegardes de volume d'initialisation et de volume manuelles

Informations additionalDetails manquantes pour les événements copyvolumebackup.begin et copyvolumebackup.end

Détails : les champs sourceBackupId et destinationRegion sont manquants dans additionalDetails pour les événements com.oraclecloud.blockvolumes.copyvolumebackup.begin et com.oraclecloud.blockvolumes.copyvolumebackup.end. Par conséquent, les règles définies pour être déclenchées en fonction de ces champs ne le seront pas.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution.

Lien direct vers ce problème : Informations additionalDetails manquantes pour les événements copyvolumebackup.begin et copyvolumebackup.end

Option de chemin de dispositif non disponible pour les instances lancées avant le 11 janvier 2019
Erreur 409 lors du clonage d'un volume

Détails : lorsque vous clonez un volume qui est encore attaché à une instance, que vous supprimez le clone, puis que vous clonez à nouveau le volume, l'erreur suivante peut se produire :

Volume <volume-OCID> cannot be cloned in parallel while attached

Cette erreur peut également être renvoyée avec un code de réponse 409.

Solution de contournement : si vous utilisez l'API, la CLI, un kit SDK ou Terraform, vous devez surveiller l'attribut isHydrated du clone supprimé et ne pas créer de second clone tant que la valeur de cet attribut n'est pas true. Si vous utilisez la console, surveillez le champ Hydraté sur la page Détails du volume de blocs du clone supprimé et ne créez pas de second clone tant que la valeur de ce champ n'est pas True.

Lien direct vers ce problème : Erreur 409 lors du clonage d'un volume

Echec de l'attachement d'un volume d'initialisation Windows à une autre instance en tant que volume de données

Détails : lorsque vous attachez un volume d'initialisation Windows à une autre instance en tant que volume de données, si vous tentez de vous connecter au volume en suivant les étapes décrites dans Connexion à un volume, l'attachement du volume échoue et l'erreur suivante peut survenir :

Connect-IscsiTarget : The target has already been logged in via an iSCSI session.

Solution de contournement : vous devez ajouter ce qui suit à la fin de la commande Connect-IscsiTarget copiée à partir de la console :

-IsMultipathEnabled $True

Lien direct vers ce problème : Echec de l'attachement d'un volume d'initialisation Windows à une autre instance en tant que volume de données

Echec de l'opération de création volume-group sur des instances Windows à l'aide de la CLI

Détails : lorsque vous utilisez la CLI sous Windows pour créer un groupe de volumes et que vous fournissez une entrée JSON incorporée pour le paramètre source-details, l'opération échoue.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution. Pour contourner ce problème, placez l'entrée JSON incorporée entre guillemets et non entre apostrophes. Vous devez également échapper les guillemets dans le format JSON. Par exemple, l'extrait de code suivant fonctionne sur les instances Linux :

--source-details '{"type": "volumeIds", 

Pour qu'il fonctionne sur les instances Windows, remplacez-le par :

--source-details "{\"type\": \"volumeIds\", 

Lien direct vers ce problème : Echec de l'opération de création volume-group sur des instances Windows à l'aide de la CLI

Echec du redimensionnement du volume d'initialisation pour le clonage et la restauration à partir d'une sauvegarde à l'aide de la CLI

Détails : lorsque vous utilisez la CLI pour cloner un volume d'initialisation ou en restaurer un à partir d'une sauvegarde, vous ne pouvez pas redimensionner le volume.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution. Pour contourner ce problème, clonez le volume d'initialisation ou restaurez-le à partir d'une sauvegarde sans le redimensionner. Vous pouvez le redimensionner une fois l'opération de clonage ou de restauration terminée.

Lien direct vers ce problème : Echec du redimensionnement du volume d'initialisation pour le clonage et la restauration à partir d'une sauvegarde à l'aide de la CLI

Texte d'aide de la CLI incorrect pour les commandes de création de volume et de volume d'initialisation

Détails : le texte d'aide des options size-in-gbs et size-in-mbs est incorrect pour les commandes CLI oci bv volume create et oci bv boot-volume create. Il indique à tort que ces options ne peuvent pas être fournies lors du clonage d'un volume ou de la restauration d'un volume à partir d'une sauvegarde. Cette information est incorrecte. Elles peuvent être spécifiées quand vous clonez un volume ou que vous en restaurez un à partir d'une sauvegarde vers un volume de plus grande taille que celui d'origine. Vous ne pouvez pas indiquer de valeur inférieure à la taille du volume source d'origine.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution. Vous pouvez ignorer le texte d'aide de ces options de commande.

Lien direct vers ce problème : Texte d'aide de la CLI incorrect pour les commandes de création de volume et de volume d'initialisation

L'attribut bootVolumeSizeInGBs est NULL

Blockchain Platform

Pour consulter les problèmes connus liés à Blockchain Platform, reportez-vous à la page Problèmes connus.

Cloud Guard

Impossible de modifier la région de génération de rapports

Détails : la région de génération de rapports est affectée lors de l'activation de Cloud Guard. Une fois affecté, ce paramètre ne peut pas être modifié, même lorsque vous désactivez et activez Cloud Guard.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution.

Lien direct vers ce problème : Impossible de modifier la région de génération de rapports

Aucune vérification des valeurs pour les groupes conditionnels

Détails : les règles de détecteur et de répondeur s'appliquent à un type de ressource particulier. Les groupes conditionnels vous permettent d'indiquer des ressources particulières de ce type à inclure ou à exclure lors de l'application d'une règle.

Scénario 1 : vous pouvez fournir des OCID de ressource à un groupe conditionnel en tant que valeurs personnalisées ou dans une liste gérée. Cloud Guard ne vérifie pas la validité de ces valeurs.

Scénario 2 : lorsque vous ajoutez un pays ou une région en tant que paramètre de groupe conditionnel à un détecteur d'activité, Cloud Guard ne vérifie pas la validité de ces valeurs.

Solution de contournement : dans les deux scénarios ci-dessus, veillez à fournir des valeurs valides. Pour obtenir la liste des valeurs de pays et de régions valides, reportez-vous à la section Utilisation des groupes conditionnels avec des détecteurs dans Modification d'une recette de détecteur clonée.

Lien direct vers ce problème : Aucune vérification des valeurs pour les groupes conditionnels

Compliance Documents

Il n'existe actuellement aucun problème connu pour Compliance Documents.

Compute

Les instances CentOS 6 perdent la connectivité réseau en cas de charge élevée prolongée

Détails : une condition de concurrence a été repérée dans le noyau CentOS 6 qui affecte les instances de machine virtuelle fonctionnant sous une charge élevée prolongée. Lorsqu'une telle condition survient, les instances risquent de perdre la connectivité réseau.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution. En tant que solution de contournement, enlevez irqpoll de la ligne de commande du noyau en exécutant la commande suivante sur l'instance :

sudo sed -i.backup 's/irqpoll//g' /etc/grub.conf /boot/efi/EFI/redhat/grub.conf

Cela modifiera les fichiers pertinents, tout en laissant une copie de sauvegarde de l'état d'origine. Une fois les fichiers modifiés, redémarrez l'instance.

Lien direct vers ce problème : Les instances CentOS 6 perdent la connectivité réseau en cas de charge élevée prolongée

Résolu : Echec de la modification de la forme à partir de la série VM.Standard.E2 ou vers celle-ci dans la console
Le cryptage en transit d'un attachement de volume d'initialisation peut être modifié lorsqu'il n'est pas pris en charge par l'image
Monitoring et OS Management ne sont pas disponibles sur les contrôleurs de domaine

Détails : lorsque vous utilisez une instance Windows Server en tant que contrôleur de domaine, le service Monitoring et le service OS Management ne sont pas disponibles. Cela se produit car les services installés par l'agent Oracle Cloud sous Windows sont exécutés avec des comptes virtuels, mais les comptes virtuels ne sont pas pris en charge dans la portée du contrôleur de domaine.

Solution de contournement : utilisez les solutions de contournement suivantes :

  • Service Monitoring : le service NT de l'agent Oracle Cloud (y compris Monitoring) est exécuté sous la forme NT Service\OCA. A l'aide de services.msc, mettez à jour l'utilisateur exécuté pour le service NT afin d'utiliser un service de domaine ou un compte utilisateur. Ensuite, ajoutez l'utilisateur au groupe local de domaine Groupes de surveillance des performances.
  • Service de mise à jour d'OS Management et de l'agent Oracle Cloud :

    • Le service NT d'OS Management est exécuté sous la forme NT Service\OCAOSMS. A l'aide de services.msc, mettez à jour l'utilisateur exécuté pour le service NT afin qu'il utilise un compte de service du domaine ou un compte d'utilisateur du domaine disposant de privilèges d'administration locale. Ensuite, ajoutez l'utilisateur au groupe d'administrateurs local du domaine.
    • Le service NT de mise à jour de l'agent Oracle Cloud est exécuté sous la forme NT Service\OCAU. A l'aide de services.msc, mettez à jour l'utilisateur exécuté pour le service NT afin qu'il utilise un compte de service du domaine ou un compte d'utilisateur du domaine disposant de privilèges d'administration locale. Ensuite, ajoutez l'utilisateur au groupe d'administrateurs local du domaine.

Lien direct vers ce problème : Monitoring et OS Management ne sont pas disponibles sur les contrôleurs de domaine

Taille de sauvegarde de volume d'initialisation supérieure à celle attendue

Détails : en raison d'une modification récente du mode de traitement des images par le service Compute, lorsque vous créez une sauvegarde de volume d'initialisation, la sauvegarde est plus volumineuse que prévu. Dans certains cas, la taille de la sauvegarde de volume d'initialisation peut être supérieure à celle du volume d'initialisation.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution.

Lien direct vers ce problème : Taille de sauvegarde de volume d'initialisation supérieure à celle attendue

Problèmes intermittents liés à l'accès SSH, aux recherches DNS et à l'accès au service de métadonnées

Détails :

Des erreurs intermittentes peuvent survenir lors des opérations suivantes avec votre instance Compute :

  • Connexion à l'instance via SSH

  • Exécution d'une recherche DNS

  • Accès au service de métadonnées via http://169.254.169.254/*

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution.

Pour contourner temporairement ce problème, exécutez la commande suivante sur l'instance :

sudo ethtool -G ens3 tx 513 && sudo ethtool -G ens3 tx 512

Lien direct vers ce problème : Problèmes intermittents liés à l'accès SSH, aux recherches DNS et à l'accès au service de métadonnées.

Les volumes attachés iSCSI ne se connectent pas au redémarrage

Détails : si vous avez effectué une mise à jour yum sur votre instance à l'aide des référentiels YUM Oracle Linux 7 entre le 22 mars 2019 et le 9 avril 2019, il se peut que les volumes de blocs attachés iSCSI ne soient pas disponibles après le redémarrage de l'instance.

Solution de contournement : cela se produit lorsque l'instance n'est pas configurée pour se connecter automatiquement aux noeuds iSCSI au redémarrage. Pour configurer la connexion automatique, mettez à jour la version du package iscsi-initiator-utils en exécutant la commande suivante :

sudo yum update -y iscsi-initiator-utils-6.2.0.874-10.0.7.el7

Lien direct vers ce problème : Les volumes iSCSI ne se connectent pas au redémarrage

Le service iscsid doit être configuré pour redémarrer automatiquement

Détails : Oracle Cloud Infrastructure prend en charge les volumes de blocs et les volumes d'initialisation distants attachés iSCSI sur les instances Compute. Ces volumes attachés iSCSI sont gérés par le service iscsid. Dans les scénarios où le service iscsid est arrêté, qu'il s'agisse d'une panne ou qu'il soit arrêté par un administrateur système par inadvertance, il est important qu'il soit automatiquement redémarré pour augmenter la stabilité de l'infrastructure.

Solution de contournement : reportez-vous à Mise à jour du service iSCSI Linux pour un redémarrage automatique afin de connaître les étapes de configuration du service iscsid pour un redémarrage automatique.

Lien direct vers ce problème : Le service iscsid doit être configuré pour redémarrer automatiquement

Les instances de machine virtuelle DenseIO sont lancées avec un volume d'initialisation attaché iSCSI

Détails : lorsque vous créez une instance à l'aide de l'une des formes suivantes :

  • VM.DenseIO1.4

  • VM.DenseIO1.8

  • VM.DenseIO1.16

  • VM.DenseIO2.8

  • VM.DenseIO2.16

  • VM.DenseIO2.24

l'instance est lancée avec un attachement iSCSI pour le volume d'initialisation au lieu d'un attachement paravirtualisé. Cela signifie que les fonctionnalités qui nécessitent des attachements de volume d'initialisation paravirtualisés, comme le cryptage en transit, ne seront pas disponibles.

Lien direct vers ce problème : Les instances de machine virtuelle DenseIO sont lancées avec un volume d'initialisation attaché iSCSI

Les instances de machine virtuelle sont lancées avec un volume d'initialisation attaché iSCSI lorsque vous indiquez une valeur pour l'attribut ipxeScript
Le système se bloque après l'exécution de firewall-cmd --reload

Détails : sur une instance Compute, le système peut se bloquer lorsque vous exécutez la commande suivante pour recharger le pare-feu :

firewall-cmd --reload

Le rechargement du pare-feu à l'aide de cette commande sur une instance en cours d'exécution peut entraîner la perte de la connexion iSCSI et une panne du volume d'initialisation de l'instance, selon l'ordre dans lequel les règles du pare-feu sont rechargées.

Solution de contournement : afin d'éviter ce problème, n'utilisez pas le paramètre reload pour firewall-cmd. A la place, exécutez la commande firewall-cmd deux fois, en utilisant le paramètre permanent lors du premier appel afin de vous assurer que vous ne perdez pas la connectivité iSCSI.

Par exemple :

firewall-cmd --permanent
firewall-cmd

Lien direct vers ce problème : Le système se bloque après l'exécution firewall-cmd --reload

L'icône de réseau sur les instances Windows 2016 affiche un statut incorrect

Détails : sur les instances exécutant Windows 2016, un symbole "x" rouge est affiché sur l'icône de connexion réseau dans la barre des tâches, même si la connectivité réseau de l'instance ne présente aucun problème.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution. Si vous recyclez le processus explorer.exe, l'icône affiche le statut correct. Cependant, ce correctif n'est pas permanent ; le symbole "x" rouge réapparaît lorsque vous redémarrez l'instance.

Lien direct vers ce problème : L'icône de réseau sur les instances Windows 2016 affiche un statut incorrect

Sur les instances exécutant la version d'octobre 2018 d'Ubuntu 18.04, le système se bloque

Détails : iSCSId est désactivé par défaut dans la version d'octobre de l'image Ubuntu 18.04 fournie par Oracle. Sur les instances utilisant ce système d'exploitation, le système peut donc se bloquer en cas de rupture momentanée de la communication iSCSI.

Solution de contournement : pour contourner ce problème, exécutez la commande suivante pour activer iSCSId sur l'instance :

sudo systemctl enable iscsid && sudo systemctl start iscsid

Lien direct vers ce problème : Sur les instances exécutant la version d'octobre 2018 d'Ubuntu 18.04, le système se bloque

L'attribut kmsKeyId est NULL
Echec du redémarrage de l'instance Ubuntu après activation d'Uncomplicated Firewall (UFW)

Détails : une fois que l'option UFW a été activée sur une instance Computeexécutant Ubuntu, l'instance ne redémarre pas.

Solution de contournement : n'utilisez pas UFW pour modifier les règles de pare-feu. Les images fournies par Oracle sont préconfigurées avec des règles de pare-feu permettant aux instances d'établir des connexions sortantes avec leurs volumes de blocs et d'initialisation. Pour plus d'informations, reportez-vous à Règles de pare-feu de base. UFW peut enlever ces règles afin que l'instance ne puisse pas se connecter aux volumes d'initialisation et de blocs lors du redémarrage.

Pour modifier des règles de pare-feu ou en ajouter, mettez plutôt à jour le fichier /etc/iptables/rules.v4. Les modifications apportées ici aux règles de pare-feu sont appliquées après un redémarrage. Pour que les règles prennent effet immédiatement, exécutez la commande suivante :

$ sudo su -
# iptables-restore < /etc/iptables/rules.v4

Lien direct vers ce problème : Echec du redémarrage de l'instance après l'activation d'UFW

Impossible de se connecter à l'instance lancée à partir d'une nouvelle image personnalisée Windows généralisée

Détails : vous ne pouvez pas vous connecter à une instance lancée à partir d'une nouvelle image personnalisée Windows.

Solution de contournement : cela résulte de l'échec du processus de généralisation d'image en raison d'un problème lié à Sysprep après la mise à niveau vers WMF 5.0. Pour contourner ce problème, effectuez les étapes décrites dans Echec de Sysprep après l'installation de WMF 5.0.

Lien direct vers ce problème : Impossible de se connecter à l'instance lancée à partir d'une nouvelle image personnalisée Windows

Une image personnalisée créée à partir d'une instance Windows peut entraîner l'initialisation de Windows en mode sécurisé

Détails : les instances initiales lancées à partir d'une image personnalisée Windows nouvellement créée peuvent être initialisées en mode sécurisé ou de récupération. Les instances initialisées dans l'un des deux modes ne répondront pas à RDP. Cela peut se produire lorsque l'instance ne parvient pas à s'arrêter complètement avant la prise de l'image personnalisée. Vous pouvez toujours accéder à l'instance en vous connectant à la console VNC, à l'aide des étapes décrites dans Connexion à la console VNC.

Solution de contournement : pour contourner ce problème, avant de créer l'image personnalisée, connectez-vous à l'instance à l'aide de RDP et lancez-y l'arrêt.

Lien direct vers ce problème : Une image personnalisée créée à partir d'une instance Windows peut entraîner l'initialisation de Windows en mode sécurisé

Les instances lancées à partir d'images personnalisées Ubuntu 16 nécessitent une configuration réseau personnalisée

Détails : lors de l'import d'Ubuntu 16 LTS et de versions plus récentes d'Ubuntu, DHCP ne parvient pas à obtenir la configuration de la passerelle. Ainsi, il ne parvient pas non plus à configurer de routage par défaut vers la passerelle sur la carte d'interface réseau virtuelle.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution. Pour contourner ce problème, configurez statiquement le routage par défaut après l'import. La procédure est la suivante :

  1. Créez le script suivant :

    #! /bin/bash -e
    								ROUTER_IP=$(/usr/bin/curl --silent http://169.254.169.254/opc/v1/vnics/ | grep "virtualRouterIp" | grep -oP "\d+\.\d+\.\d+\.\d+" | head -n 1)
    								echo "Found Router IP $ROUTER_IP"
    
    							ip route add default via $ROUTER_IP

    et enregistrez-le dans /usr/local/bin/configure_default_route.sh.

  2. Exécutez la commande suivante pour rendre le script exécutable :

    sudo chmod +x /usr/local/bin/configure_default_route.sh
  3. Ajoutez l'élément suivant à /etc/network/interfaces pour qu'il soit lancé à chaque initialisation du système :

    # OCI Emulated boot network interface
    								auto ens3
    								iface ens3 inet dhcp
    							post-up /usr/local/bin/configure_default_route.sh

Lien direct vers ce problème : Les instances lancées à partir d'images personnalisées Ubuntu 16 nécessitent une configuration réseau personnalisée

Expiration du détachement de la carte d'interface réseau virtuelle secondaire pour certaines instances lancées à partir d'images personnalisées importées

Détails : lorsque vous détachez une carte d'interface réseau virtuelle secondaire d'instances lancées à partir d'images personnalisées importées, l'opération peut expirer.

Solution de contournement : le module hot-pluggable, acpiphp, doit être chargé pour que les cartes d'interface réseau virtuelles secondaires se détachent correctement dans Linux. En cas d'échec du détachement d'une carte d'interface réseau virtuelle, exécutez la commande lsmod pour afficher la liste des modules chargés, puis recherchez acpiphp dans la liste. Si vous ne voyez pas le module dans la liste, chargez-le en exécutant la commande suivante :

modprobe acpiphp

Réessayez l'opération de détachement pour la carte d'interface réseau virtuelle secondaire. Vous pouvez être amené à redémarrer le système pour que l'opération soit réalisée.

Lien direct vers ce problème : Expiration du détachement de la carte d'interface réseau virtuelle secondaire pour certaines instances lancées à partir d'images personnalisées importées

La carte d'interface réseau virtuelle secondaire peut ne pas fonctionner avec des anciennes images CentOS, Oracle Linux et RHEL
Erreur d'image non valide lors de l'export d'une image

Détails : lorsque vous tentez d'exporter une image, l'export échoue avec une erreur indiquant que l'image n'est pas valide. Cette erreur survient uniquement dans la région Ouest des Etats-Unis (Phoenix).

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution. Pour contourner ce problème, procédez comme suit :

  1. Lancez une nouvelle instance en fonction de l'image que vous essayez d'exporter et indiquez l'une des formes suivantes pour l'image :

    • BM.Standard1.36

    • BM.DenseIO1.36

    • VM.DenseIO1.4

    • VM.DenseIO1.8

    • VM.DenseIO1.16

  2. Créez une image personnalisée en suivant les étapes décrites dans Procédure de création d'une image personnalisée.

Après avoir créé l'image personnalisée, vous pouvez l'exporter.

Lien direct vers ce problème : Erreur d'image non valide lors de l'export d'une image

Les instances CentOS 6.x subissent des ralentissements ou des pannes lors de la création d'un système de fichiers ext2, ext3 ou ext4

Détails :l'instance ralentit ou s'arrête lors de la création d'un système de fichiers ext2, ext3 ou ext4 sur des lecteurs NVMe connectés en local pour des instances CentOS 6.x avec les formes suivantes :

  • VM.DenseIO1.4
  • VM.DenseIO1.8
  • VM.DenseIO1.16
  • BM.DenseIO1.36

Solution de contournement : les systèmes de fichiers ext2, ext3 et ext4 ne sont pas pris en charge sur les instances CentOS 6.x présentant les formes répertoriées dans la section Détails. Nous vous recommandons d'utiliser un autre système de fichiers.

Lien direct vers ce problème : Les instances CentOS 6.x ralentissent ou s'arrêtent lors de la création d'un système de fichiers ext2, ext3 ou ext4

Une erreur d'authentification se produit lors de la connexion à la console série pour une instance Bare Metal

Détails : lors de l'établissement d'une connexion SSH à une instance Bare Metal pour la première fois, le client SSH doit envoyer la clé correcte. Si plusieurs clés SSH sont configurées sous ~/.ssh ou dans le fichier ~/.ssh/config, il se peut que votre client n'envoie pas la clé correcte lors de la première tentative d'autorisation et que le message d'erreur suivant s'affiche :

Received disconnect from UNKNOWN port 65535:2: Too many authentication failures.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution. Afin de contourner ce problème, modifiez la chaîne de connexion dans la commande SSH pour utiliser l'indicateur configfile (-F) afin de remplacer le fichier de configuration par défaut, l'option -o IdentitiesOnly=yes afin de forcer le client SSH à utiliser la clé indiquée et l'indicateur de fichier d'identités (-i) afin de spécifier la clé SSH à utiliser, comme indiqué dans l'exemple suivant :

ssh -F /dev/null -o IdentitiesOnly=yes -i /<path>/<ssh_key> -o ProxyCommand='ssh -i /<path>/<ssh_key> -W %h:%p -p 443...

Lien direct vers ce problème : Une erreur d'authentification se produit lors de la connexion à la console série pour une instance Bare Metal

Heure système incorrecte sur les instances de machine virtuelle Windows lors de la modification du fuseau horaire par défaut

Détails : si vous modifiez le fuseau horaire par défaut sur les instances de machine virtuelle Windows, lors du redémarrage de l'instance ou de sa synchronisation avec l'horloge temps réel, l'heure système revient à l'heure du fuseau horaire par défaut. Toutefois, le système reste paramétré sur le nouveau fuseau horaire. L'horloge système est donc incorrecte.

Dans le journal des événements, vous voyez en outre des événements indiquant que l'heure système a été modifiée avec les détails suivants :

Change Reason: System time synchronized with the hardware clock.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution. Pour contourner ce problème, procédez comme suit :

  1. Ouvrez l'éditeur de registre et accédez à l'emplacement suivant :

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
  2. Créez une clé DWORD nommée RealTimeIsUniversal et définissez la valeur sur 1.

  3. Redémarrez l'instance.
  4. Réinitialisez manuellement l'heure et le fuseau horaire.

Lien direct vers ce problème : Heure système incorrecte sur les instances de machine virtuelle Windows lors de la modification du fuseau horaire par défaut

Les connexions à laconsole série ne fonctionnent pas pour les anciennes instances

Détails pour les instances de machine virtuelle : vous pouvez créer des connexions à la console série pour les instances de machine virtuelle uniquement pour celles qui ont été lancées à partir du 26 août 2017.

Détails pour les instances Bare Metal : vous pouvez créer des connexions à la console série vers les instances Bare Metal uniquement pour celles qui ont été lancées à partir du 21 octobre 2017.

Solution de contournement : si vous avez besoin d'un accès via la console série à une instance lancée avant les dates indiquées pour les instances de machine virtuelle et Bare Metal, vous pouvez contourner de problème en créant une image personnalisée de l'instance. Lorsque vous lancez une nouvelle instance basée sur l'image personnalisée, cette instance bénéficie d'un accès via la console série. Pour plus de détails sur la création d'une image personnalisée, reportez-vous à Gestion des images personnalisées.

Lien direct vers ce problème : Les connexions à la console série ne fonctionnent pas pour les anciennes instances

Paramètres listImage inactifs et champs de réponse Image manquants

Détails : l'opération ListImages de l'API Compute inclut des paramètres pour le filtrage côté serveur sur operatingSystem et operatingSystemVersion. Cependant, ces paramètres sont actuellement inactifs. De même, la documentation de l'objet de réponse Image inclut les attributs operatingSystem et operatingSystemVersion, mais l'objet ne renvoie pas ces champs actuellement.

Solution de contournement : le nom d'affichage des images fournies par Oracle inclut le système d'exploitation et la version de celui-ci, par exemple "Oracle-Linux-7.2-2016.09.18-0". "Oracle Linux" est le système d'exploitation et "7.2" la version.

Nous sommes conscients de cette omission et avons prévu de prendre en charge ces paramètres et attributs.

Lien direct vers ce problème : Paramètres listImage inactifs et champs de réponse Image manquants

Echec du redémarrage de l'instance si le service de gestionnaire de réseau est installé

Détails : si le service de gestionnaire de réseau est installé, le redémarrage d'une instance peut échouer.

Solution de contournement : si le service de gestionnaire de réseau n'est pas requis, vous pouvez le désinstaller. S'il l'est, modifiez le fichier de configuration de l'interface réseau avant de redémarrer l'instance. Définissez la clé de configuration NM_CONTROLLED sur "no" :

NM_CONTROLLED="no"

Généralement, le fichier de configuration de l'interface réseau est situé à l'emplacement suivant :

/etc/sysconfig/network-scripts/ifcfg-<interface_name>

Lien direct vers ce problème : Echec du redémarrage de l'instance si le service de gestionnaire de réseau est installé

La présence de caractères non ASCII dans le nom d'instance peut entraîner des échecs de lancement de Windows

Détails : lorsque le nom d'une instance Windows inclut des caractères non ASCII, le lancement de l'instance peut échouer. Cela se produit car le nom de l'instance est utilisé pour définir le nom de l'ordinateur Windows lors de la création de l'instance. Windows restreint les caractères autorisés dans les noms d'ordinateur et les caractères non ASCII peuvent provoquer des échecs de création d'instance Windows.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution. Pour contourner temporairement ce problème, nommez les instances Windows en utilisant uniquement les caractères ASCII suivants : lettres majuscules (A-Z), lettres minuscules (a-z), chiffres (0-9) et traits d'union (-).

Lien direct vers ce problème : La présence de caractères non ASCII dans le nom d'instance peut entraîner des échecs de lancement de Windows

Echec du lancement des pools d'instances et des réseaux de cluster lorsque la configuration d'instance ou l'équilibreur de charge associé inclut des balises définies

Détails : lorsque vous tentez de lancer un pool d'instances ou un réseau de cluster à partir d'une configuration d'instance incluant des balises définies, les instances ne peuvent pas être lancées. Le lancement des instances échoue également si vous tentez d'attacher des instances d'un pool ou d'un réseau de cluster à un équilibreur de charge qui inclut des balises définies. Le lancement des instances échoue avec l'un des messages d'erreur suivants :

The following tag namespaces / keys are not authorized or not found: Policies not set for the tenancy.
Failed to launch instance in pool <instance_pool_OCID> because the defined tags could not be operated on.
Failed to create instance pool in cluster network <cluster_network_OCID> because the defined tags could not be operated on.
Failed to create backend in load balancer: <load_balancer_OCID> because the defined tags could not be operated on.

Pour les configurations d'instance, cela se produit parce que le service Compute ne parvient pas à propager les balises définies vers les instances du pool ou du réseau de cluster. Pour les équilibreurs de charge, cela se produit parce que le service Compute ne parvient pas à appliquer les balises aux instances.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution. Pour contourner le problème, vous devez autoriser le service Compute à gérer les espaces de noms de balise en votre nom. Ajoutez l'une des stratégies suivantes :

  • Pour autoriser le service à utiliser l'espace de noms de balise dans tous les compartiments de la location, procédez comme suit :

    Allow service compute_management to use tag-namespace in tenancy
  • Pour réduire la portée d'accès par compartiment, utilisez l'instruction suivante :

    Allow service compute_management to use tag-namespace in compartment <compartment_name>

Lien direct vers ce problème : Echec du lancement des pools d'instances et des réseaux de cluster lorsque la configuration d'instance ou l'équilibreur de charge associé inclut des balises définies

Echec des mises à jour automatiques à l'aide d'Oracle Ksplice avec certaines configurations de réseau FastConnect
Impossible pour le service OS Management de gérer les images Oracle Autonomous Linux

Détails : les instances Oracle Autonomous Linux ne peuvent pas être gérées par le service OS Management.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution. N'installez pas l'agent du service OS Management (osms-agent) sur les instances Oracle Autonomous Linux.

Lien direct vers ce problème : Impossible pour le service OS Management de gérer les images Oracle Autonomous Linux

L'indicateur manquant est requis pour le service OS Management pour les instances créées avant septembre 2019

Détails : lors de l'utilisation du service OS Management sur les instances Oracle Linux créées avant septembre 2019, la page Détails de l'instance peut indiquer à tort que le service OS Management est activé (agent de gestion Oracle Cloud : activé) alors qu'il ne l'est pas.

Ce problème concerne les instances créées avant la définition de l'indicateur isManagementDisabled dans les métadonnées des instances Compute. Cet indicateur n'étant pas présent, les métadonnées de ces instances ne sont pas définies correctement pour le service OS Management.

Solution de contournement : pour résoudre ce problème, définissez l'indicateur isManagementDisabled sur False :

  1. Dans la configuration de l'agent pour l'instance, définissez l'option isManagementDisabled sur False :

    oci compute instance update --instance-id <instance_OCID> --agent-config '{"isManagementDisabled": false, "isMonitoringDisabled": false}'
  2. Utilisez l'interface de ligne de commande pour vérifier que l'indicateur a été mis à jour :

    oci compute instance get --instance-id <instance_OCID>

    Dans la sortie, l'indicateur mis à jour apparaît sous la forme "is-management-disabled": false.

    {
      "data":
        "agent-config": {
          "is-management-disabled": false,
          "is-monitoring-disabled": false
        },
    ...
    }
  3. Connectez-vous à l'instance via SSH, puis utilisez cURL pour appeler le service de métadonnées d'instance et vérifier que l'indicateur a été mis à jour dans l'instance Compute :

    curl http://169.254.169.254/opc/v1/instance/

    Dans la sortie, l'indicateur mis à jour est affiché sous la forme "managementDisabled" : false.

    {
      ...
      "agentConfig" : {
        "monitoringDisabled" : false,
        "managementDisabled" : false
      }
    }

Lien direct vers ce problème : L'indicateur manquant est requis pour le service OS Management pour les instances créées avant septembre 2019

Console

Un bug du navigateur Firefox peut empêcher le chargement de la console

Détails : lorsque vous essayez d'accéder à la console à l'aide de Firefox, la page Console ne se charge jamais dans le navigateur. Ce problème est probablement dû à un profil utilisateur Firefox endommagé.

Solution de contournement : créez un profil utilisateur Firefox comme suit :

  1. Vérifiez que vous utilisez la version la plus récente de Firefox. Si ce n'est pas le cas, effectuez une mise à jour vers la dernière version.
  2. Créez un profil utilisateur et enlevez l'ancien. Reportez-vous à l'assistance Mozilla pour obtenir des instructions sur la création et la suppression de profils utilisateur : https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles.
  3. Ouvrez Firefox avec le nouveau profil.

Vous pouvez également utiliser l'un des autres navigateurs pris en charge.

Lien direct vers ce problème : Un bug du navigateur Firefox peut empêcher le chargement de la console

Container Engine for Kubernetes

Les propriétés de noeud de processus actif ne sont pas synchronisées avec les propriétés de pool de noeuds mises à jour

Détails : les propriétés des nouveaux noeuds de processus actifs commençant dans un pool de noeuds ne reflètent pas les dernières modifications apportées aux propriétés du pool de noeuds. La cause probable est l'utilisation des attributs quantityPerSubnet et subnetIds en phase d'abandon lors de l'utilisation de l'opération d'API UpdateNodePoolDetails pour mettre à jour les propriétés du pool de noeuds.

Solutions de contournement : procédez de l'une des façons suivantes :
  • Commencez à utiliser l'attribut nodeConfigDetails lors de l'utilisation de l'opération d'API UpdateNodePoolDetails. Tout d'abord, redimensionnez le pool de noeuds sur 0 à l'aide de quantityPerSubnet. Ensuite, arrêtez d'utiliser les attributs subnetIds et quantityPerSubnet, et utilisez l'attribut nodeConfigDetails à la place.
  • Contactez le support technique Oracle pour redémarrer le composant back-end responsable de la synchronisation (composant locataire-agent).

Lien direct vers ce problème : Les propriétés de noeud de processus actif ne sont pas synchronisées avec les propriétés de pool de noeuds mises à jour

Impossible de lancer le tableau de bord Kubernetes

Détails : lorsque vous lancez le tableau de bord Kubernetes, des messages d'erreur tels que "net/http: TLS handshake timeout" et "connection reset by peer" peuvent apparaître dans le navigateur Web. Ce problème n'a été observé que dans les clusters récemment créés exécutant Kubernetes version 1.11. Pour plus d'informations sur un problème lié à Kubernetes, reportez-vous à la page https://github.com/kubernetes/dashboard/issues/3038.

Solution de contournement :

  1. Dans une fenêtre de terminal, saisissez :

    $ kubectl -n kube-system port-forward svc/kubernetes-dashboard 8443:443
  2. Dans le navigateur Web, accédez à https://localhost:8443.

Lien direct vers ce problème : Impossible de lancer le tableau de bord Kubernetes

Impossible d'accéder à Helm dans un cluster

Détails : si vous utilisez un jeton Kubeconfig version 2.0.0 pour accéder à des versions de Helm/Tiller antérieures à la version 2.11, vous recevez l'un des messages d'erreur suivants :

  • Error: Unauthorized
  • Error: could not get Kubernetes client: exec plugin: invalid apiVersion "client.authentication.k8s.io/v1beta1"

Solution de contournement : mettez à niveau Helm/Tiller comme suit :

  1. Dans une fenêtre de terminal, téléchargez un jeton Kubeconfig version 1.0.0 en saisissant la commande suivante :

    $ oci ce cluster create-kubeconfig --token-version=1.0.0 --cluster-id=<cluster_ocid>
  2. Identifiez la clé de région à utiliser pour indiquer le registre Oracle Cloud Infrastructure Registry dans la région du cluster (reportez-vous à Disponibilité par région). Par exemple, si le cluster se trouve dans la région Est des Etats-Unis (Ashburn), iad est la clé de région à utiliser pour indiquer le registre dans cette région.

  3. Mettez à niveau Tiller en entrant la commande suivante :

    $ helm init --upgrade -i <region-key>.ocir.io/odx-oke/oke-public/tiller:v2.14.3

    <region-key> est la clé que vous avez identifiée au cours de l'étape précédente.

  4. Dans un navigateur, accédez à la page https://helm.sh/docs/using_helm/#installing-the-helm-client et suivez les instructions de téléchargement et d'installation du fichier binaire client Helm.

  5. Une fois Helm/Tiller mis à niveau, téléchargez un jeton Kubeconfig version 2.0.0 en saisissant la commande suivante :

    $ oci ce cluster create-kubeconfig --token-version=2.0.0 --cluster-id=<cluster_ocid>

Lien direct vers ce problème : Impossible d'accéder à Helm dans un cluster

Certaines fonctionnalités Kubernetes (par exemple, Metrics Server) ne parviennent pas à communiquer avec le kubelet via http/2

Détails : Container Engine for Kubernetes version 1.8.0 a fait l'objet d'une amélioration de sécurité visant à améliorer l'efficacité du cryptage sur le kubelet exécuté sur les noeuds de processus actif client. Les noeuds de processus actif créés entre le 20 août 2019 et le 16 septembre 2019 incluent cette configuration. Le nouvel ensemble de cryptages n'autorise pas les connexions au kubelet via http/2. Cette restriction a un impact sur la fonctionnalité Metrics Server, ainsi que sur Horizontal Pod Autoscaler, qui dépend de Metrics Server.

Solution de contournement :

Pour chaque noeud de processus actif existant, procédez comme suit :

  1. Pour empêcher les nouveaux pods de démarrer et supprimer les pods existants sur le noeud de processus actif, entrez kubectl drain <node_name>. Pour plus d'informations concernant :

    Recommandation : si besoin, utilisez les budgets alloués en cas de perturbation de pod pour votre application afin de garantir qu'un nombre suffisant de pods de réplique est exécuté pendant toute l'opération de purge.

  2. Supprimez le noeud de processus actif (par exemple, en y mettant fin dans la console).
  3. Attendez qu'un noeud de processus actif de remplacement démarre.

Les noeuds de processus actif de remplacement incluent de nouveaux paramètres pour permettre la communication avec le kubelet.

Lien direct vers ce problème : Certaines fonctionnalités Kubernetes (par exemple, Metrics Server) ne parviennent pas à communiquer avec le kubelet via http/2

Echec du montage des volumes par les pods Kubernetes en raison de délais d'expiration

Détails : lorsqu'un nouveau pod démarre sur un noeud de processus actif dans un cluster, dans certaines situations, le pod ne parvient pas à monter tous les volumes attachés au noeud en raison de délais d'expiration. Vous voyez alors apparaître un message tel que le suivant :

Unable to mount volumes for pod "<pod_name>(<pod_uid>)": timeout expired waiting for volumes to attach or mount for pod "<namespace>"/"<pod_name>". list of unmounted volumes=[<failed_volume>]. list of unattached volumes=[<… list of volumes >]

L'une des causes possibles de ce problème a été identifiée : il peut survenir si les spécifications du pod incluent un champ fsGroup dans le champ securityContext. Si le conteneur est exécuté sur un noeud de processus actif en tant qu'utilisateur non root, la définition du champ fsGroup dans le champ securityContext peut générer des délais d'expiration en raison du nombre de fichiers dans lesquels Kubernetes doit apporter des modifications de propriété (reportez-vous à https://github.com/kubernetes/kubernetes/issues/67014).

Si les spécifications du pod n'incluent pas de champ fsgroup dans securityContext, la cause est inconnue.

Solutions de contournement :

Si les spécifications du pod incluent le champ fsgroup dans securityContext et que le conteneur exécute un utilisateur non root, envisagez les solutions de contournement suivantes :

  • Enlevez le champ fsgroup de securityContext.
  • Utilisez le champ supplementalGroups dans securityContext (au lieu de fsgroup) et définissez supplementalGroups sur l'identificateur de volume.
  • Modifiez les spécifications du pod pour que le conteneur soit exécuté en tant qu'utilisateur root.

Si les spécifications du pod n'incluent pas le champ fsgroup dans securityContext ou si le conteneur est déjà exécuté en tant qu'utilisateur root, vous devez redémarrer ou remplacer le noeud de processus actif. Par exemple, en arrêtant et en démarrant l'instance, en redémarrant l'instance ou en mettant fin à l'instance afin qu'une nouvelle instance démarre. Suivez les instructions de la section Arrêt et démarrage d'une instance ou Terminaison d'une instance, selon le cas, pour utiliser la console ou l'API. Vous pouvez également utiliser des commandes d'interface de ligne de commande, comme dans l'exemple suivant, pour mettre fin à une instance :

$ INSTANCE_OCID=$(kubectl get node <name> -ojsonpath='{.spec.providerID}')
$ oci compute instance terminate --instance-id $INSTANCE_OCID

<name> est le nom du noeud de processus actif, dérivé de la propriété Adresse IP privée de l'instance (par exemple, 10.0.10.5).

Lien direct vers ce problème : Echec du montage des volumes par les pods Kubernetes en raison de délais d'expiration

Data Catalog

Impossible d'importer un fichier de glossaire métier volumineux

Détails : lors de l'import d'un glossaire volumineux, l'opération d'import échoue.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution. Divisez votre fichier de glossaire en fichiers plus petits contenant moins de 100 termes, puis importez les différents fichiers dans Data Catalog.

Lien direct vers ce problème : Impossible d'importer un fichier de glossaire métier volumineux

Formatage RTF perdu lors de l'export d'un glossaire

Détails : lorsque vous exportez un glossaire, tout formatage RTF appliqué aux champs de description est perdu.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution. Appliquez manuellement le formatage requis au fichier exporté.

Lien direct vers ce problème : Formatage RTF perdu lors de l'export d'un glossaire

Suppression partielle de ressources de données volumineuses

Détails : lorsque vous supprimez des ressources de données présentant un grand nombre d'entités de données, vous recevez une notification d'erreur.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution. Retentez l'opération de suppression jusqu'à ce que vous receviez une notification indiquant que la suppression a été effectuée.

Lien direct vers ce problème : Suppression partielle de ressources de données volumineuses

Collecte incrémentielle des ressources de données Autonomous Database

Détails : lors de l'utilisation de l'option de collecte incrémentielle pour collecter des ressources de données Autonomous Database, les modifications apportées à la colonne des commentaires dans la base de données Oracle ne sont pas identifiées par Data Catalog.

Solution de contournement : collectez de nouveau la ressource de données sans sélectionner l'option de collecte incrémentielle. Vous vous assurez ainsi que le dernier état de la ressource de données est reflété dans Data Catalog.

Lien direct vers ce problème : Collecte incrémentielle des ressources de données Autonomous Database

Résolu : Problèmes avec la collecte incrémentielle des ressources de données

Détails : lorsque vous utilisez l'option de collecte incrémentielle pour collecter des ressources de données, elle ne fonctionne pas correctement pour certaines entités de données, notamment les sources de fichier Excel. De plus, lorsque vous collectez à nouveau les ressources de données, les entités de données supprimées dans la source de données sont encore présentes dans Data Catalog.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution. Collectez à nouveau la ressource de données sans sélectionner l'option de collecte incrémentielle. Vous vous assurez ainsi que le dernier état de la ressource de données est reflété dans Data Catalog.

Lien direct vers ce problème : Problèmes avec la collecte incrémentielle des ressources de données

Data Flow

Les fichiers requis pour chaque application doivent se trouver dans la région dans laquelle l'application est créée

Détails : les applications doivent être créées dans la même région que le bucket de banque d'objets qui contient tous les fichiers, fichiers JAR et configurations associés requis pour une exécution réussie de l'application. Le scénario inter-régions n'est pas pris en charge.

Solution de contournement : nous sommes conscients de ce problème. Il n'existe aucune autre solution de contournement que de s'assurer que tous les fichiers, les fichiers JAR, la configuration, etc. se trouvent dans la même région.

Lien direct vers ce problème : Les fichiers requis pour chaque application doivent se trouver dans la région dans laquelle l'application est créée

L'affichage dans la console Data Flow des sorties de journal, plus précisément des journaux de pilote et d'exécuteur, prend environ 12 minutes après la fin d'une exécution.

Détails : chaque exécution d'une application génère un ensemble de journaux de sortie : journaux d'application, tels que stdout et stderr, et journaux de diagnostics, tels que les journaux de pilote et d'exécuteur Spark. Les journaux d'application sont immédiatement disponibles dans la console Data Flow, mais les journaux de diagnostics peuvent mettre jusqu'à 12 minutes à apparaître.

Solution de contournement : nous sommes conscients de ce problème. Aucune solution de contournement n'est disponible pour le moment.

Lien direct vers ce problème : L'affichage dans la console Data Flow des sorties de journal, plus précisément des journaux de pilote et d'exécuteur, prend environ 12 minutes après la fin d'une exécution

Le traitement de flux de données haut débit n'est actuellement pas pris en charge.

Détails : les applications qui exigent la prise en charge de la transmission Spark en continu pour traiter les données actives haut débit ne sont pas prises en charge.

Solution de contournement : nous sommes conscients de ce problème et il n'existe aucune solution de contournement pour le moment.

Lien direct vers ce problème : Le traitement de flux de données haut débit n'est actuellement pas pris en charge

Erreurs d'interface utilisateur Spark

Détails : vous risquez d'obtenir une erreur lors de l'accès à l'interface utilisateur Spark. Cette erreur est généralement due au fait que l'application Spark est en cours de fermeture.

Solution de contournement : si une erreur survient, attendez une minute avant d'accéder de nouveau à l'interface utilisateur Spark.

Lien direct vers ce problème : Erreurs de l'interface utilisateur Spark

Data Integration

Le message d'erreur ne décrit pas correctement l'échec d'une tâche d'intégration causé par l'arrêt d'une base de données en tant que problème avec l'entité de données pour l'opérateur : SOURCE_1.

Détails : une tâche d'intégration a échoué car la base de données est arrêtée, mais le message d'erreur indique à tort ce qui suit :

There was as an issue with the data entity for operator: SOURCE_1. Either no data entity was selected, or you no longer have access to the selected data entity, connection, schema, or data asset. Check the operator or data asset details.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution. Pour empêcher l'affichage de ce message d'erreur, vérifiez la base de données et redémarrez-la, si nécessaire.

Lien direct vers ce problème :  Le message d'erreur ne décrit pas correctement l'échec d'une tâche d'intégration causé par l'arrêt d'une base de données en tant que problème avec l'entité de données pour l'opérateur : SOURCE_1.

Le noeud résultant d'une transformation d'extraction avec non-concordance d'une expression régulière affiche des valeurs vides dans Data Xplorer.

Détails : lorsque vous effectuez une transformation d'extraction d'une ressource de données Object Storage avec une expression régulière ne correspondant pas à tous les enregistrements, les résultats apparaissent sous forme de valeurs vides dans Data Xplorer pour l'opérateur/le noeud d'expression résultant.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution.

Lien direct vers ce problème : Le noeud résultant d'une transformation d'extraction avec non-concordance d'une expression régulière affiche des valeurs vides dans Data Xplorer.

Les journaux d'une tâche d'intégration ayant échoué en raison d'une ressource de données non valide ne sont pas affichés.

Détails : lorsqu'un hôte non valide est saisi pour une ressource de données et que cette ressource de données est utilisée dans un flux de données, la tâche d'intégration associée au flux de données échoue lors de l'exécution. Le panneau Messages du journal pour l'exécution de tâche affiche les messages d'erreur suivants :

Cannot find the schema with name <schema_name> using connection DI Object <connection_name_uid_details>.
No logs available.

Solution de contournement : veillez à fournir des détails de ressource de données et de connexion corrects pour vous assurer que ce schéma existe. Nous avons connaissance du problème et travaillons à sa résolution.

Lien direct vers ce problème : Les journaux d'une tâche d'intégration ayant échoué en raison d'une ressource de données non valide ne sont pas affichés.

Le nombre d'enregistrements d'insertion est égal à 0 (zéro) dans la table des exécutions de tâche pour Oracle Database, Autonomous Transaction Processing et Autonomous Data Warehouse.

Détails : pour Oracle Database, Autonomous Transaction Processing et Autonomous Data Warehouse, la table des exécutions de tâche affiche zéro dans la colonne des insertions, même s'il existe des enregistrements dans cette colonne.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution.

Lien direct vers ce problème : Le nombre d'enregistrements d'insertion est égal à 0 (zéro) dans la table des exécutions de tâche pour Oracle Database, Autonomous Transaction Processing et Autonomous Data Warehouse.

Les attributs cible pour Object Storage ne parviennent pas à remplir la somme si vous indiquez une échelle et une longueur, et les valeurs d'agrégation simples qui en résultent dépassent la limite de caractères.

Détails : dans Object Storage, si vous spécifiez une échelle et une longueur pour une agrégation simple, la somme résultante doit être comprise dans la longueur et l'échelle spécifiées. Si la somme dépasse la longueur et l'échelle spécifiées, elle renvoie une valeur NULL dans Data Xplorer et n'affiche rien dans la sortie cible.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution.

Lien direct vers ce problème :  Les attributs cible pour Object Storage ne parviennent pas à remplir la somme si vous indiquez une échelle et une longueur, et les valeurs d'agrégation simples qui en résultent dépassent la limite de caractères.

Data Xplorer ne prend pas en charge les flux de données partiels.

Détails : lorsque seulement deux opérateurs source ont été ajoutés à un flux de données et que vous cliquez sur l'onglet Données pour l'un des opérateurs source, Data Xplorer affiche une erreur de chaîne d'extraction de connexion.

Solution de contournement : veillez à sélectionner des entités de données pour les deux opérateurs source avant de cliquer sur l'onglet Données. Nous avons connaissance du problème et travaillons à sa résolution.

Lien direct vers ce problème : Data Xplorer ne prend pas en charge les flux de données partiels.

Le message d'erreur décrit incorrectement un échec causé par des types de données non pris en charge dans une tâche comme un problème d'extraction des données Data Xplorer.

Détails : si vous sélectionnez une entité de données qui utilise des types de données non pris en charge lors de l'utilisation de Data Xplorer ou de l'exécution d'une tâche, le message d'erreur indique incorrectement qu'il s'agit d'un problème lors de l'extraction des données Data Xplorer. Les types de données Oracle Database suivants ne sont pas pris en charge :

  • ROWID
  • UROWID
  • BFILE
  • TIMESTAMP WITH LOCAL TIMEZONE
  • INTERVAL DAY TO SECOND
  • INTERVAL YEAR TO MONTH
  • XMLTYPE
  • SDO_GEOMETRY

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution.

Lien direct vers ce problème : Le message d'erreur décrit incorrectement un échec causé par des types de données non pris en charge dans une tâche comme un problème d'extraction des données Data Xplorer.

Seule la valeur de délimiteur apparaît après l'application d'une transformation de fusion d'attributs lors de l'utilisation d'attributs contenant des valeurs NULL.

Détails : supposons que vous créez une tâche de flux de données ou de programme de chargement de données avec la base de données Oracle en tant que source. Vous effectuez une transformation de fusion d'attributs sur des attributs, et au moins l'un d'entre eux a une valeur NULL, et l'autre une valeur non NULL. Le résultat contient uniquement le délimiteur spécifié et aucune des valeurs.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution.

Lien direct vers ce problème : Seule la valeur de délimiteur apparaît après l'application d'une transformation de fusion d'attributs lors de l'utilisation d'attributs contenant des valeurs NULL.

Lors de l'affichage de l'onglet Données, lorsque le panneau Propriétés est développé, Data Xplorer conserve sa taille d'origine.

Détails : si vous développez le panneau Propriétés alors que l'onglet Données est affiché, Data Xplorer ne s'agrandit pas. Le nombre de lignes reste le même, avec une barre de défilement verticale pour parcourir les autres lignes.

Solution de contournement : utilisez Chrome ou une version plus récente de Firefox (plus récente que Firefox 69) pour afficher entièrement la grille du panneau. Si vous utilisez une version antérieure de Firefox (plus ancienne que Firefox 69), cliquez sur une colonne dans le panneau Propriétés, accédez à un autre onglet, puis revenez. Nous avons connaissance du problème et travaillons à sa résolution.

Lien direct vers ce problème : Lors de l'affichage de l'onglet Données, lorsque le panneau Propriétés est développé, Data Xplorer conserve sa taille d'origine.

La création d'une exécution de tâche à l'aide de l'API REST sans indiquer de clé entraîne une erreur interne.

Détails : si vous créez une exécution de tâche à l'aide de l'API REST sans spécifier de clé pour cette exécution de tâche, une erreur interne est générée.

Solution de contournement : veillez à indiquer une clé lors de la création d'une exécution de tâche à l'aide de l'API REST. Nous avons connaissance du problème et travaillons à sa résolution.

Lien direct vers ce problème : La création d'une exécution de tâche à l'aide de l'API REST sans indiquer de clé entraîne une erreur interne.

Data Science

Il n'existe actuellement aucun problème connu concernant le service Data Science.

Database

Ensemble des systèmes de base de données

Problème de facturation lors de la modification du type de licence

Détails : lorsque passez d'une licence de type BYOL à une licence incluse ou inversement pour votre base de données ou système de base de données, vous êtes facturé pour les deux types de licence au cours de la première heure. Vous êtes ensuite facturé pour le type de licence mis à jour.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution.

Lien direct vers ce problème : Problème de facturation lors de la modification du type de licence

Résolu : La passerelle de service ne prend actuellement pas en charge les mises à jour de système d'exploitation

Détails : si vous configurez votre réseau cloud virtuel avec une passerelle de service, le sous-réseau privé bloque l'accès aux référentiels YUM nécessaires à la mise à jour du système d'exploitation. Ce problème concerne tous les types de système de base de données.

Solution de contournement : ce problème est maintenant résolu. La solution de contournement suivante était recommandée avant la résolution du problème :

La passerelle de service permet d'accéder aux référentiels YUM Oracle si vous utilisez les libellés CIDR de service appelés Tous les services <region> dans Oracle Services Network. Toutefois, vous pouvez toujours rencontrer des problèmes d'accès aux services YUM via la passerelle de service. Il existe une solution au problème. Pour plus de détails, reportez-vous à Problèmes d'accès aux services YUM Oracle via la passerelle de service.

Lien direct vers ce problème : La passerelle de service ne prend actuellement pas en charge les mises à jour de système d'exploitation

Systèmes de base de données Bare Metal et de machine virtuelle uniquement

Echec de la sauvegarde vers Object Storage à l'aide de dbcli ou de RMAN en raison d'une modification de certificat

Détails : les sauvegardes non gérées effectuées vers Object Storage à l'aide de la CLI de base de données (dbcli) ou de RMAN échouent avec les erreurs suivantes :

-> Oracle Error Codes found:
-> ORA-19554: error allocating device, device type: SBT_TAPE, device name:
-> ORA-19511: non RMAN, but media manager or vendor specific failure, error text:
-> KBHS-00712: ORA-29024 received from local HTTP service
-> ORA-27023: skgfqsbi: media manager protocol error

En réponse aux stratégies implémentées par deux navigateurs Web courants concernant les certificats Symantec, Oracle a récemment modifié l'autorité de certification utilisée pour Oracle Cloud Infrastructure. La modification apportée aux certificats SSL peut entraîner l'échec des sauvegardes vers Object Storage si le module Oracle Database Cloud Backup pointe encore vers l'ancien certificat.

Solution de contournement pour dbcli : dans les fichiers journaux, recherchez les erreurs répertoriées ; si elles s'y trouvent, mettez à jour le module de sauvegarde.

Consultez les fichiers journaux de sauvegarde RMAN pour rechercher les erreurs répertoriées ci-dessus :

  1. Déterminez l'ID du travail de sauvegarde ayant échoué.

    dbcli list-jobs

    Dans cet exemple de sortie, l'ID du travail de sauvegarde ayant échoué est "f59d8470-6c37-49e4-a372-4788c984ea59".

    root@<node name> ~]# dbcli list-jobs
     
    ID                                       Description                                                                 Created                             Status
    ---------------------------------------- --------------------------------------------------------------------------- ----------------------------------- ----------
    cbe852de-c0f3-4807-85e8-7523647ec78c     Authentication key update for DCS_ADMIN                                     March 30, 2018 4:10:21 AM UTC       Success
    db83fdc4-5245-4307-88a7-178f8a0efa48     Provisioning service creation                                               March 30, 2018 4:12:01 AM UTC       Success
    c1511a7a-3c2e-4e42-9520-f156b1b4cf0e     SSH keys update                                                             March 30, 2018 4:48:24 AM UTC       Success
    22adf146-9779-4a2c-8682-7fd04d7520b2     SSH key delete                                                              March 30, 2018 4:50:02 AM UTC       Success
    6f2be750-9823-4ed5-b5ff-8e49f136dd22     create object store:bV0wqIaoLA4xLT4dGjOu                                    March 30, 2018 5:33:38 AM UTC       Success
    0716f464-1a10-40df-a303-cadee0302b1b     create backup config:bV0wqIaoLA4xLT4dGjOu_BC                                March 30, 2018 5:33:49 AM UTC       Success
    e08b21c3-cd09-4e3a-944c-d1da96cb21d8     update database : hfdb1                                                     March 30, 2018 5:34:04 AM UTC       Success
    1c3d7c58-79c3-4039-8f48-787057ce7c6e     Create Longterm Backup with TAG-DBTLongterm<identity number> for Db:<dbname>    March 30, 2018 5:37:11 AM UTC       Success
    f59d8470-6c37-49e4-a372-4788c984ea59     Create Longterm Backup with TAG-DBTLongterm<identity number> for Db:<dbname>    March 30, 2018 5:43:45 AM UTC       Failure
  2. Utilisez l'ID du travail ayant échoué pour obtenir l'emplacement du fichier journal à consulter.

    
    dbcli describe-job -i <failed_job_ID>

    La commande describe-job renvoie une sortie de ce type :

    Message: DCS-10001:Internal error encountered: Failed to run Rman statement.
    Refer log in Node <node_name>: /opt/oracle/dcs/log/<node_name>/rman/bkup/<db_unique_name>/rman_backup/<date>/rman_backup_<date>.log.

Mettez à jour le module Oracle Database Cloud Backup :

  1. Déterminez l'utilisateur et l'ID de banque d'objets Swift que la base de données utilise pour les sauvegardes.

    1. Exécutez la commande dbcli list-databases pour déterminer l'ID de la base de données.

    2. Utilisez l'ID de la base de données pour déterminer l'ID de configuration de sauvegarde (backupConfigId).

      dbcli list-databases
      dbcli describe-database -i <database_ID> -j
    3. A l'aide de l'ID de configuration de sauvegarde que vous avez noté à l'étape précédente, déterminez l'ID de banque d'objets (objectStoreId).

      dbcli list-backupconfigs
      dbcli describe-backupconfig –i <backupconfig_ID> -j
    4. A l'aide de l'ID de banque d'objets que vous avez noté à l'étape précédente, déterminez l'utilisateur de banque d'objets (userName).

      dbcli list-objectstoreswifts
      dbcli describe-objectstoreswift –i <objectstore_ID> -j
  2. Mettez à jour le module de sauvegarde à l'aide des informations d'identification de banque d'objets obtenues au cours de l'étape 1.

    dbcli update-objectstoreswift –i <objectstore_ID> -p –u <user_name>

Solution de contournement pour RMAN : dans les fichiers journaux RMAN, recherchez les messages d'erreur répertoriés. S'ils s'y trouvent, connectez-vous à l'hôte en tant qu'utilisateur oracle et utilisez les informations d'identification Swift pour réinstaller le module de sauvegarde.

Remarque

Les mots de passe Swift sont désormais appelés "jetons d'authentification". Pour plus de détails, reportez-vous à Utilisation d'un jeton d'authentification avec Swift.
java -jar <opc_install.jar_path> -opcId '<swift_user_ID>' -opcPass '<auth_token>' -container <objectstore_container> -walletDir <wallet_directory> -configfile <config_file> -host https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace> -import-all-trustcerts

Pour un système de base de données à plusieurs noeuds, appliquez la solution de contournement à tous les noeuds du cluster.

Pour plus d'informations sur l'utilisation de cette commande, reportez-vous à la documentation du module Oracle Database Cloud Backup.

Lien direct vers ce problème : Echec de la sauvegarde vers Object Storage à l'aide de dbcli ou de RMAN en raison d'une modification de certificat

Modifications des ruptures de code dans les kits SDK du service Database

Détails : les kits SDK publiés le 18 octobre 2018 introduisent des modifications des ruptures de code dans les attributs de taille et d'édition de base de données dans les API de sauvegarde de base de données.

Solution de contournement : reportez-vous à la documentation propre aux différents langages pour plus d'informations sur les modifications des ruptures de code, et mettez à jour le code existant si nécessaire :

Lien direct vers ce problème : Modifications des ruptures de code dans les kits SDK du service Database

Impossible d'utiliser des sauvegardes gérées dans le système de base de données

Détails : les opérations de sauvegarde et de restauration peuvent ne pas fonctionner dans votre système de base de données lorsque vous utilisez la console ou l'API.

Solution de contournement : installez le module Oracle Database Cloud Backup, puis contactez Oracle Support Services pour obtenir des instructions supplémentaires.

Pour installer le module Oracle Database Cloud Backup, procédez comme suit :

  1. Connectez-vous au système de base de données via SSH en tant qu'utilisateur opc.

    
    ssh -i <SSH_key> opc@<DB_system_IP address>
    login as: opc

    Vous pouvez également utiliser opc@<DB_system_hostname> pour vous connecter.

  2. Téléchargez le module Oracle Database Cloud Backup à partir de l'adresse http://www.oracle.com/technetwork/database/availability/oracle-cloud-backup-2162729.html.
  3. Extrayez le contenu d'opc_installer.zip dans un répertoire cible, par exemple, /home/opc.
  4. Dans votre location, créez un utilisateur temporaire et accordez-lui des privilèges permettant d'accéder à Object Storage.
  5. Créez un jeton d'authentification pour cet utilisateur temporaire et notez le mot de passe.
  6. Vérifiez que les informations d'identification fonctionnent en exécutant la commande curl suivante :

    Remarque

    Les mots de passe Swift sont désormais appelés "jetons d'authentification". Pour plus de détails, reportez-vous à Utilisation d'un jeton d'authentification avec Swift.
    curl -v -X HEAD -u  <user_id>:'<auth_token>' https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace>

    Consultez https://cloud.oracle.com/infrastructure/storage/object-storage/faq pour connaître la région à utiliser.

    La commande doit renvoyer le code de réponse de statut de réussite HTTP 200 ou HTTP 204 Aucun contenu. Tout autre code de statut indique un problème de connexion à Object Storage.

  7. Exécutez la commande suivante :

    java -jar opc_install.jar -opcid <user_id> -opcPass '<auth_token>' -libDir <target_dir> -walletDir <target_dir> -host https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace> -configFile config.txt

    <target_dir> est le répertoire dans lequel vous avez extrait opc_installer.zip au cours de l'étape 3.

    L'exécution de cette commande peut prendre quelques minutes car elle télécharge libopc.so et d'autres fichiers. Une fois la commande exécutée, vous devez voir plusieurs fichiers (y compris libopc.so) dans votre répertoire cible.

  8. Accédez au répertoire cible et copiez les fichiers lipopc.so et opc_install.jar dans le répertoire /opt/oracle/oak/pkgrepos/oss/odbcs.

    cp libopc.so /opt/oracle/oak/pkgrepos/oss/odbcs
    
    
    cp opc_install.jar /opt/oracle/oak/pkgrepos/oss/odbcs

    (Vous devrez peut-être utiliser sudo avec les commandes de copie pour les exécuter en tant qu'utilisateur root.)

  9. Exécutez la commande suivante pour vérifier si le répertoire indiqué existe :

    
    
    ls /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs

    Si ce répertoire existe, procédez comme suit :

    1. Sauvegardez les fichiers dans le répertoire /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs.
    2. Exécutez ces deux commandes pour remplacer les fichiers libopc.so et opc_install.jar existants dans le répertoire :

      
      cp libopc.so /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs
      cp opc_install.jar /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs
  10. Vérifiez la version du fichier opc_install.jar.

    
    java -jar /opt/oracle/oak/pkgrepos/oss/odbcs/opc_install.jar |grep -i build
    

    Si /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs existe, exécutez également la commande suivante :

    
    java -jar /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs/opc_install.jar |grep -i build

    Les deux commandes doivent renvoyer la sortie suivante :

    Oracle Database Cloud Backup Module Install Tool, build MAIN_2017-08-16.
  11. (Facultatif) Supprimez l'utilisateur temporaire et le répertoire cible que vous avez utilisés pour installer le module de sauvegarde.

Une fois que vous avez terminé la procédure, contactez le support technique Oracle ou l'administrateur de locataires pour obtenir davantage d'instructions. Vous devez fournir l'OCID du système de base de données pour lequel activer les sauvegardes.

Lien direct vers ce problème : Impossible d'utiliser des sauvegardes gérées dans le système de base de données

Echec des sauvegardes automatiques gérées sur la forme VM.Standard1.1 en raison d'une panne du processus

Détails : les limites de mémoire des ordinateurs hôte exécutant la forme VM.Standard1.1 peuvent entraîner l'échec des travaux de sauvegarde de base de données automatique gérés par Oracle Cloud Infrastructure (travaux gérés à l'aide de la console ou de l'API). Vous pouvez modifier les paramètres de mémoire des systèmes pour résoudre ce problème.

Solution de contournement : modifiez les paramètres de mémoire des systèmes comme suit :

  1. Passez à l'utilisateur oracle dans le système d'exploitation.

    [opc@hostname ~]$ sudo su - oracle
  2. Définissez la variable d'environnement pour la connexion à l'instance de base de données. Par exemple :

    
    [oracle@hostname ~]$ . oraenv
     ORACLE_SID = [oracle] ? orcl
    				
  3. Démarrez SQL*Plus.

    [oracle@hostname ~]$ sqlplus / as sysdba
  4. Modifiez les paramètres de mémoire initiaux comme suit :

    
    SQL> ALTER SYSTEM SET SGA_TARGET = 1228M scope=spfile;
    SQL> ALTER SYSTEM SET PGA_AGGREGATE_TARGET = 1228M;
    SQL> ALTER SYSTEM SET PGA_AGGREGATE_LIMIT = 2457M;
    SQL> exit
    							
  5. Redémarrez l'instance de base de données.

    
    [oracle@hostname ~]$ srvctl stop database -d db_unique_name -o immediate
    [oracle@hostname ~]$ srvctl start database -d db_unique_name -o open								

Lien direct vers ce problème : Echec des sauvegardes automatiques gérées sur la forme VM.Standard1.1 en raison d'une panne du processus

Les opérations Oracle Data Pump renvoient "ORA-00439 : fonctionnalité non activée"

Détails : sur les systèmes de base de données High Performance et Extreme Performance, les opérations de l'utilitaire Data Pump utilisant la compression et/ou le parallélisme peuvent échouer et renvoyer l'erreur ORA-00439 : fonctionnalité non activée. Ce problème concerne les versions de base de données 12.1.0.2.161018 et 12.1.0.2.170117.

Solution de contournement : appliquez le patch 25579568 ou 25891266 aux répertoires de base Oracle Database pour la version de base de données 12.1.0.2.161018 ou 12.1.0.2.170117, respectivement. Vous pouvez également utiliser la console pour appliquer le patch d'avril 2017 au répertoire de base de base de données et au système de base de données.

Remarque

Identification de la version d'une base de données dans un répertoire de base de base de données

Pour déterminer la version d'une base de données dans un répertoire de base de base de données, exécutez $ORACLE_HOME/OPatch/opatch lspatches en tant qu'utilisateur oracle ou dbcli list-dbhomes en tant qu'utilisateur root.

Lien direct vers ce problème : Les opérations Oracle Data Pump renvoient "ORA-00439 : fonctionnalité non activée"

Impossible de se connecter à la console EM Express à partir du système de base de données à 1 noeud

Détails : il se peut que vous receviez un message d'erreur indiquant l'échec de la connexion sécurisée lorsque vous tentez de vous connecter à la console EM Express à partir du système de base de données à 1 noeud, car les droits d'accès corrects n'ont pas été appliqués automatiquement.

Solution de contournement : ajoutez des droits d'accès en lecture pour le groupe asmadmin sur le répertoire de portefeuille du système de base de données, puis réessayez de vous connecter :

  1. Connectez-vous au système hôte de base de données via SSH en tant qu'utilisateur opc, puis exécutez la commande sudo pour passer à l'utilisateur grid.

    [opc@dbsysHost ~]$ sudo su - grid
    [grid@dbsysHost ~]$ . oraenv
    ORACLE_SID = [+ASM1] ?
    The Oracle base has been set to /u01/app/grid
    
  2. Obtenez l'emplacement du répertoire de portefeuille (affiché en rouge ci-dessous) dans la sortie de commande.

    [grid@dbsysHost ~]$ lsnrctl status | grep xdb_wallet
    
    (DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=dbsysHost.sub04061528182.dbsysapril6.oraclevcn.com)(PORT=5500))(Security=(my_wallet_directory=/u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet))(Presentation=HTTP)(Session=RAW))
  3. Revenez à l'utilisateur opc, passez à l'utilisateur oracle et passez dans le répertoire du portefeuille.

    [opc@dbsysHost ~]$ sudo su - oracle
    [oracle@dbsysHost ~]$ cd /u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet
  4. Répertoriez le contenu du répertoire et notez les droits d'accès.

    
    [oracle@dbsysHost xdb_wallet]$ ls -ltr
    total 8
    -rw------- 1 oracle asmadmin 3881 Apr  6 16:32 ewallet.p12
    -rw------- 1 oracle asmadmin 3926 Apr  6 16:32 cwallet.sso
    
  5. Modifiez les droits d'accès :

    
    [oracle@dbsysHost xdb_wallet]$ chmod 640 /u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet/*
  6. Vérifiez que des droits d'accès en lecture ont été ajoutés.

    [oracle@dbsysHost xdb_wallet]$ ls -ltr
    total 8
    -rw-r----- 1 oracle asmadmin 3881 Apr  6 16:32 ewallet.p12
    -rw-r----- 1 oracle asmadmin 3926 Apr  6 16:32 cwallet.sso
    

Lien direct vers ce problème : Impossible de se connecter à la console EM Express à partir du système de base de données à 1 noeud

Systèmes de base de données Exadata uniquement

Echec de la sauvegarde vers Object Storage à l'aide de bkup_api ou de RMAN en raison d'une modification de certificat

Détails : les opérations de sauvegarde effectuées vers Object Storage à l'aide de l'utilitaire de sauvegarde Exadata (bkup_api) ou de RMAN échouent avec les erreurs suivantes :

* DBaaS Error trace:
-> API::ERROR -> KBHS-00715: HTTP error occurred 'oracle-error'
-> API::ERROR -> ORA-19511: non RMAN, but media manager or vendor specific failure, error text:
-> API::ERROR -> ORA-19554: error allocating device, device type: SBT_TAPE, device name:
-> API::ERROR -> ORA-27023: skgfqsbi: media manager protocol error
-> API::ERROR Unable to verify the backup pieces
-> Oracle Error Codes found:
-> ORA-19554: error allocating device, device type: SBT_TAPE, device name:
-> ORA-19511: non RMAN, but media manager or vendor specific failure, error text:
-> KBHS-00712: ORA-29024 received from local HTTP service
-> ORA-27023: skgfqsbi: media manager protocol error

En réponse aux stratégies implémentées par deux navigateurs Web courants concernant les certificats Symantec, Oracle a récemment modifié l'autorité de certification utilisée pour Oracle Cloud Infrastructure. La modification apportée aux certificats SSL peut entraîner l'échec des sauvegardes vers Object Storage si le module Oracle Database Cloud Backup pointe encore vers l'ancien certificat.

Important

Avant d'utiliser la solution de contournement applicable de cette section, suivez les étapes de Mise à jour manuelle de l'outil cloud sur chaque noeud de calcul pour vous assurer que la dernière version de dbaastools_exa est installée sur le système.

Solution de contournement pour bkup_api : dans les fichiers journaux, recherchez les erreurs répertoriées ci-dessus ; si elles s'y trouvent, réinstallez le module de sauvegarde.

Exécutez la commande suivante pour vérifier le statut de la sauvegarde ayant échoué :

/var/opt/oracle/bkup_api/bkup_api bkup_status --dbname=<database_name>

Exécutez la commande suivante pour réinstaller le module de sauvegarde :

/var/opt/oracle/ocde/assistants/bkup/bkup -dbname=<database_name>

Solution de contournement pour RMAN : dans les fichiers journaux RMAN, recherchez les messages d'erreur répertoriés. S'ils s'y trouvent, connectez-vous à l'hôte en tant qu'utilisateur oracle et utilisez les informations d'identification Swift pour réinstaller le module de sauvegarde.

Remarque

Les mots de passe Swift sont désormais appelés "jetons d'authentification". Pour plus de détails, reportez-vous à Utilisation d'un jeton d'authentification avec Swift.
java -jar <opc_install.jar_path> -opcId '<Swift_user_ID>' -opcPass '<auth_token>' -container <objectstore_container> -walletDir <wallet_directory> -configfile <config_file> -host https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace> -import-all-trustcerts

Appliquez cette solution de contournement à l'ensemble des noeuds du cluster.

Pour plus d'informations sur l'utilisation de cette commande, reportez-vous à la documentation du module Oracle Database Cloud Backup.

Lien direct vers ce problème : Echec de la sauvegarde vers Object Storage à l'aide de bkup_api ou de RMAN en raison d'une modification de certificat

Informations de la console non synchronisées pour les bases de données sur lesquelles Data Guard est activé lors de l'utilisation de dbaascli

Détails : avec la publication de la fonctionnalité de répertoire de base de base de données partagée pour les systèmes de base de données Exadata, la console synchronise et affiche désormais les informations relatives aux bases de données créées et gérées à l'aide des utilitaires dbaasapi et dbaascli. Toutefois, les bases de données pour lesquelles Data Guard est configuré n'affichent pas les informations correctes dans la console dans les conditions suivantes :

  • Si Data Guard a été activé à l'aide de la console, et qu'une modification est apportée à la base de données principale ou de secours via dbaascli (par exemple, déplacement de la base de données vers un autre répertoire de base), le résultat n'est pas reflété dans la console.
  • Si Data Guard a été configuré manuellement, la console n'affiche pas d'association Data Guard entre les deux bases de données.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution. En attendant, Oracle vous recommande de gérer vos bases de données sur lesquelles Data Guard est activé en utilisant uniquement la console ou uniquement des utilitaires de ligne de commande.

Lien direct vers ce problème : Informations de la console non synchronisées pour les bases de données sur lesquelles Data Guard est activé lors de l'utilisation de dbaascli

Grid Infrastructure ne démarre pas après la mise hors ligne et la mise en ligne d'un disque

Détails : il s'agit d'un problème de clusterware qui se produit uniquement lorsque la version d'Oracle GI correspond à la version 12.2.0.1 sans package de patches. Ce problème est dû à l'endommagement d'un disque "votant" après l'avoir mis hors ligne, puis en ligne.

Solution de contournement : identifiez la version de GI et si le disque "votant" est endommagé. Réparez le disque, si nécessaire, puis appliquez le dernier groupe GI.

  1. Vérifiez que la version de GI correspond à la version 12.2.0.1 sans package de patches appliqué :

    
    [root@rmstest-udaau1 ~]# su - grid
    [grid@rmstest-udaau1 ~]$ . oraenv
    ORACLE_SID = [+ASM1] ? +ASM1
    The Oracle base has been set to /u01/app/grid
    [grid@rmstest-udaau1 ~]$ $ORACLE_HOME/OPatch/opatch lsinventory
    Oracle Interim Patch Installer version 12.2.0.1.6
    Copyright (c) 2018, Oracle Corporation.  All rights reserved.
    
    
    Oracle Home       : /u01/app/12.2.0.1/grid
    Central Inventory : /u01/app/oraInventory
       from           : /u01/app/12.2.0.1/grid/oraInst.loc
    OPatch version    : 12.2.0.1.6
    OUI version       : 12.2.0.1.4
    Log file location : /u01/app/12.2.0.1/grid/cfgtoollogs/opatch/opatch2018-01-15_22-11-10PM_1.log
    
    Lsinventory Output file location : /u01/app/12.2.0.1/grid/cfgtoollogs/opatch/lsinv/lsinventory2018-01-15_22-11-10PM.txt
    
    --------------------------------------------------------------------------------
    Local Machine Information::
    Hostname: rmstest-udaau1.exaagclient.sretest.oraclevcn.com
    ARU platform id: 226
    ARU platform description:: Linux x86-64
    
    Installed Top-level Products (1):
    
    Oracle Grid Infrastructure 12c                                       12.2.0.1.0
    There are 1 products installed in this Oracle Home.
    
    
    There are no Interim patches installed in this Oracle Home.
    
    
    --------------------------------------------------------------------------------
    
    OPatch succeeded.
  2. Consultez le fichier /u01/app/grid/diag/crs/<hostname>/crs/trace/ocssd.trc pour savoir si l'échec du démarrage de GI est dû à l'endommagement d'un disque "votant" :

    ocssd.trc
     
    2017-01-17 23:45:11.955 :    CSSD:3807860480: clssnmvDiskCheck:: configured 
    Sites = 1, Incative sites = 1, Mininum Sites required = 1 
    2017-01-17 23:45:11.955 :    CSSD:3807860480: (:CSSNM00018:)clssnmvDiskCheck: 
    Aborting, 2 of 5 configured voting disks available, need 3 
    ...... 
    . 
    2017-01-17 23:45:11.956 :    CSSD:3807860480: clssnmCheckForNetworkFailure: 
    skipping 31 defined 0 
    2017-01-17 23:45:11.956 :    CSSD:3807860480: clssnmRemoveNodeInTerm: node 4, 
    slcc05db08 terminated. Removing from its own member and connected bitmaps 
    2017-01-17 23:45:11.956 :    CSSD:3807860480: 
    ################################### 
    2017-01-17 23:45:11.956 :    CSSD:3807860480: clssscExit: CSSD aborting from 
    thread clssnmvDiskPingMonitorThread 
    2017-01-17 23:45:11.956 :    CSSD:3807860480: 
    ################################### 
    2017-01-17 23:45:11.956 :    CSSD:3807860480: (:CSSSC00012:)clssscExit: A 
    fatal error occurred and the CSS daemon is terminating abnormally 
     
    ------------
     
    2017-01-19 19:00:32.689 :    CSSD:3469420288: clssnmFindVF: Duplicate voting disk found in the queue of previously configured disks 
    queued(o/192.168.10.18/PCW_CD_02_slcc05cel10|[66223efc-29254fbb-bf901601-21009 
    cbd]), 
    found(o/192.168.10.18/PCW_CD_02_slcc05cel10|[66223efc-29254fbb-bf901601-21009c 
    bd]), is not corrupted 
    2017-01-19 19:01:06.467 :    CSSD:3452057344: clssnmvVoteDiskValidation: 
    Voting disk(o/192.168.10.19/PCW_CD_02_slcc05cel11) is corrupted
  3. Vous pouvez également utiliser SQL*Plus pour confirmer que les disques "votants" sont endommagés :

    1. Connectez-vous en tant qu'utilisateur grid et définissez l'environnement sur ASM.

      [root@rmstest-udaau1 ~]# su - grid
      [grid@rmstest-udaau1 ~]$ . oraenv
      ORACLE_SID = [+ASM1] ? +ASM1
      The Oracle base has been set to /u01/app/grid
    2. Connectez-vous à SQL*Plus en tant qu'utilisateur SYSASM.

      $ORACLE_HOME/bin/sqlplus / as sysasm
    3. Exécutez les deux requêtes suivantes :

      SQL> select name, voting_file from v$asm_disk where VOTING_FILE='Y' and group_number !=0;
      SQL> select  CC.name, count(*) from x$kfdat AA JOIN (select disk_number, name from v$asm_disk where VOTING_FILE='Y' and group_number !=0) CC ON CC.disk_number = AA.NUMBER_KFDAT where AA.FNUM_KFDAT= 1048572 group by CC.name;

      Si le système est en bon état, les résultats doivent ressembler à l'exemple suivant.

      Résultats de la requête 1

      NAME                           VOTING_FILE
      ------------------------------ ---------------
      DBFSC3_CD_02_SLCLCX0788        Y
      DBFSC3_CD_09_SLCLCX0787        Y
      DBFSC3_CD_04_SLCLCX0786        Y

      Résultats de la requête 2

      NAME                           COUNT(*)
      ------------------------------ ---------------
      DBFSC3_CD_02_SLCLCX0788        8
      DBFSC3_CD_09_SLCLCX0787        8
      DBFSC3_CD_04_SLCLCX0786        8

      Si le système est en bon état, chaque disque "votant" renvoyé dans la première requête doit également être renvoyé dans la seconde, et le décompte pour tous les disques doit être différent de zéro. Sinon, des disques "votants" sont endommagés.

  4. Si un disque "votant" est endommagé, mettez hors ligne le disque grille le contenant. Les cellules déplacent automatiquement le disque "votant" endommagé vers l'autre disque grille et le mettent en ligne.

    1. La commande suivante met hors ligne un disque grille nommé DATAC01_CD_05_SCAQAE08CELADM13.

      SQL> alter diskgroup DATAC01 offline disk DATAC01_CD_05_SCAQAE08CELADM13;
           Diskgroup altered.
    2. Patientez 30 secondes, puis réexécutez les deux requêtes de l'étape 3c pour vérifier que le disque "votant" a migré vers le nouveau disque grille et qu'il est en bon état.

    3. Vérifiez que le disque grille que vous avez mis hors ligne est maintenant en ligne :

      SQL> select name, mode_status, voting_file from v$asm_disk where name='DATAC01_CD_05_SCAQAE08CELADM13';

      La valeur de mode_status doit être ONLINE et celle de voting_file ne doit pas être Y.

    Répétez les étapes 4a à 4c pour chaque disque grille restant contenant un disque "votant" endommagé.
    Remarque

    Si le CRS ne démarre pas en raison de l'endommagement du disque "votant", démarrez-le en mode exclusif avant d'exécuter la commande de l'étape 4.

    crsctl start crs -excl
     
  5. Si vous utilisez Oracle GI version 12.2.0.1 sans package de patches, vous devez mettre à niveau la version de GI vers le dernier groupe GI, qu'un disque "votant" soit endommagé ou non.

    Reportez-vous à Application manuelle de patches à un système de base de données Exadata pour obtenir des instructions sur la manière d'employer l'utilitaire exadbcpatchmulti afin d'appliquer des patches pour Oracle Grid Infrastructure et Oracle Database sur un système de base de données Exadata.

Lien direct vers ce problème : Grid Infrastructure ne démarre pas après la mise hors ligne et la mise en ligne d'un disque

Fonctionnalités gérées non activées pour les systèmes provisionnés avant le 15 juin 2018

Détails : les systèmes de base de données Exadata lancés le 15 juin 2018 ou ultérieurement incluent automatiquement la possibilité de créer, de répertorier et de supprimer des bases de données à l'aide de la console, de l'API ou de la CLI Oracle Cloud Infrastructure. Toutefois, les systèmes provisionnés avant cette date exigent des étapes supplémentaires pour activer ces fonctionnalités.

Si vous tentez d'utiliser ces fonctionnalités sans effectuer les étapes supplémentaires, les messages d'erreur suivants s'affichent :

  • Lors de la création d'une base de données : "La création de base de données n'est pas prise en charge sur ce système de base de données Exadata. Pour activer cette fonctionnalité, contactez le support technique Oracle."
  • Lors de la terminaison d'une base de données : "DeleteDbHome n'est pas pris en charge sur ce système de base de données Exadata. Pour activer cette fonctionnalité, contactez le support technique Oracle."

Solution de contournement : vous devez installer l'agent Exadata sur chaque noeud du système de base de données Exadata.

Commencez par créer une demande de service pour obtenir de l'aide d'Oracle Support Services. Le support technique Oracle vous répondra en vous fournissant l'URL pré-authentifiée d'un emplacement Oracle Cloud Infrastructure Object Storage permettant d'obtenir l'agent.

Avant d'installer l'agent Exadata, procédez comme suit :

  • Mettez à niveau l'outil (dbaastools rpm) vers la dernière version sur tous les noeuds du système de base de données Exadata. Reportez-vous à Mise à jour de l'outil sur un système de base de données Exadata.
  • Vérifiez que le système est configuré de façon à accéder à Oracle Cloud Infrastructure Object Storage avec les listes de sécurité requises pour la région dans laquelle le système de base de données a été créé. Pour plus d'informations sur la connectivité à Oracle Cloud Infrastructure Object Storage, reportez-vous à Prérequis.

Pour installer l'agent Exadata, procédez comme suit :

  1. Connectez-vous au noeud en tant qu'utilisateur root.
  2. Exécutez les commandes suivantes pour installer l'agent :

    [root@<node_n>~]# cd /tmp
    [root@<node_n>~]# wget https://objectstorage.<region_name>.oraclecloud.com/p/1q523eOkAOYBJVP9RYji3V5APlMFHIv1_6bAMmxsS4E/n/dbaaspatchstore/b/dbaasexadatacustomersea1/o/backfill_agent_package_iwwva.tar
    [root@<node_n>~]# tar -xvf /tmp/backfill_agent_package_*.tar -C /tmp
    [root@<node_n>~]# rpm -ivh /tmp/dbcs-agent-2.5-3.x86_64.rpm

    Exemple de sortie :

    [root@<node_n>~]# rpm -ivh dbcs-agent-2.5-3.x86_64.rpm
    Preparing...                ########################################### [100%]
    Checking for dbaastools_exa rpm on the system
    Current dbaastools_exa version = dbaastools_exa-1.0-1+18.1.4.1.0_180725.0000.x86_64
    dbaastools_exa version dbaastools_exa-1.0-1+18.1.4.1.0_180725.0000.x86_64 is good. Continuing with dbcs-agent installation
       1:dbcs-agent             ########################################### [100%]
    initctl: Unknown instance:
    initctl: Unknown instance:
    initzookeeper start/running, process 85821
    initdbcsagent stop/waiting
    initdbcsadmin stop/waiting
    initdbcsagent start/running, process 85833
    initdbcsadmin start/running, process 85836
    
  3. Vérifiez que l'agent est installé et en cours d'exécution.

    [root@<node_n>~]# rpm -qa | grep dbcs-agent
    dbcs-agent-2.5-0.x86_64
    [root@<node_n>~]# initctl status initdbcsagent
    initdbcsagent start/running, process 97832
  4. Répétez les étapes 1 à 3 sur les noeuds restants.

Une fois l'agent installé sur tous les noeuds, attendez 30 minutes pour qu'Oracle effectue les tâches de workflow supplémentaires, telles que la mise à niveau de l'agent vers la dernière version, la rotation des informations d'identification de l'agent, etc. Une fois le processus terminé, vous devez pouvoir utiliser les fonctionnalités gérées par Exadata dans la console, l'API ou la CLI Oracle Cloud Infrastructure.

Lien direct vers ce problème : Fonctionnalités gérées non activées pour les systèmes provisionnés avant le 15 juin 2018

Le fichier de configuration de l'application de patches pointe vers une région incorrecte

Détails : le fichier de configuration de l'application de patches (/var/opt/oracle/exapatch/exadbcpatch.cfg) pointe vers la banque d'objets de la région us-phoenix-1, même si le système de base de données Exadata est déployé dans une autre région.

Ce problème survient si le package de l'outil de base de données (dbaastools_exa) correspond à la version 17430 ou version antérieure.

Solution de contournement : suivez les instructions de la rubrique Mise à jour manuelle de l'outil cloud sur chaque noeud de calcul pour confirmer que le package de l'outil correspond à la version 17430 ou version antérieure, puis mettez-le à jour vers la dernière version.

Lien direct vers ce problème : Le fichier de configuration de l'application de patches pointe vers une région incorrecte

Echecs de workflow de base de données en raison de la suppression par Oracle Linux 7 des fichiers temporaires requis

Détails : un changement dans la façon dont Oracle Linux 7 traite les fichiers temporaires peut entraîner la suppression des fichiers de socket requis du répertoire /var/tmp/.oracle. Ce problème ne concerne que les systèmes de base de données Exadata exécutant l'image de système d'exploitation version 19.1.2.

Solution de contournement : exécutez sudo /usr/local/bin/imageinfo en tant qu'utilisateur opc pour déterminer la version de l'image de système d'exploitation. Si la version de l'image est 19.1.2.0.0.190306, suivez les instructions du document portant l'ID 2498572.1 pour corriger le problème.

Lien direct vers ce problème : Echecs de workflow de base de données en raison de la suppression par Oracle Linux 7 des fichiers temporaires requis

Outils de développeur

Altération potentielle des données avec le kit SDK pour Python lors du téléchargement de fichiers binaires

Détails : lors de l'utilisation du kit SDK pour Python afin d'effectuer des opérations de téléchargement de fichiers binaires, vous pouvez rencontrer un problème d'altération des données si les nouvelles tentatives sont activées ou si vous utilisez UploadManager.upload_file.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution. Pour plus d'informations sur ce problème et les solutions de contournement, reportez-vous à Problème d'altération potentielle des données pour les nouvelles tentatives du kit SDK Python lors du téléchargement des données binaires.

Lien direct vers ce problème : Altération potentielle des données avec le kit SDK pour Python lors du téléchargement de fichiers binaires

DNS

Actuellement, il n'existe aucun problème connu lié à DNS.

Email Delivery

Impossible d'accéder aux informations d'identification SMTP pour les anciennes locations fédérées

Détails : les utilisateurs fédérés sont pris en charge pour Email Delivery, sauf avec les anciennes locations qui n'utilisent pas le système de gestion des identités interdomaines (SCIM). SCIM est la norme pour tous les accès aux informations d'identité. Depuis décembre 2018, toutes les locations utilisent SCIM.

Solution de contournement : demandez à un administrateur de votre location Oracle Cloud Infrastructure de créer un utilisateur dans la console qui sera à employer avec le service Email Delivery. La connexion directe à la console (pas de fédération) permettra d'accéder aux paramètres utilisateur et aux informations d'identification SMTP.

Lien direct vers ce problème : Impossible d'accéder aux informations d'identification SMTP pour les locations fédérées

Erreur lors de la tentative d'ajout d'une suppression à partir d'un compartiment autre que de type racine

Détails : dans la console, si vous choisissez un compartiment autre que de type racine et que vous accédez ensuite à la liste de suppression de courriels, l'erreur suivante se produira si vous tentez d'ajouter une suppression :

Error: The required compartmentId ocid1.compartment.oc1..aaaaaaaacq3ztcbrxvgfb35zj6wztdpwlkmzfh4rnsq63sugge624qr5cdla must be the root compartment for suppressions

Solution de contournement : accédez à la page des expéditeurs approuvés, choisissez le compartiment racine, puis revenez à la liste de suppression de courriels.

Lien direct vers ce problème : Erreur lors de la tentative d'ajout d'une suppression à partir d'un compartiment autre que de type racine

Events

Actuellement, il n'existe aucun problème connu lié à Events.

File Storage

File Storage ne prend pas actuellement en charge les listes de contrôle d'accès
Détails : File Storage ne prend pas en charge les listes de contrôle d'accès au niveau du fichier. Seuls les droits d'accès user, group et world sont pris en charge. File Storage utilise le protocole NFSv3, qui n'inclut pas la prise en charge des listes de contrôle d'accès. setfacl échoue sur les systèmes de fichiers montés. getfacl renvoie uniquement les droits d'accès standard.
Remarque

Certaines implémentations peuvent étendre le protocole NFSv3 et ajouter la prise en charge des listes de contrôle d'accès dans le cadre d'un programme rpc distinct.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution.

Lien direct vers ce problème : File Storage ne prend pas actuellement en charge les listes de contrôle d'accès

Erreur d'expiration du sémaphore lors de la création d'un cliché avec la ligne de commande Windows

Détails : lorsque vous utilisez la commande mkdir dans une commande Windows CMD pour créer un cliché d'un système de fichiers monté, une erreur apparaît. Par exemple : 

C:\>mkdir X:\.snapshot\snapshot1

The semaphore timeout period has expired.

Même si l'erreur apparaît, le cliché a été créé.

Solution de contournement : utilisez la console, l'API ou la CLI pour créer des clichés.

Lien direct vers ce problème : Erreur d'expiration du sémaphore lors de la création d'un cliché avec la ligne de commande Windows

Impossible de déplacer des ressources de stockage de fichier vers un autre compartiment

Détails : lors du déplacement d'un système de fichiers ou d'une cible de montage d'un compartiment vers un autre, l'opération échoue. Les utilisateurs doivent être membres du groupe d'administrateurs.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution. Pour contourner ce problème, assurez-vous que l'utilisateur est membre du groupe d'administrateurs. Pour plus d'informations, reportez-vous à la section Gestion des groupes.

Lien direct vers ce problème : Impossible de déplacer des ressources de stockage de fichier vers un autre compartiment

Erreur 409 lors de la création ou du déplacement d'un système de fichiers ou d'une cible de montage

Détails : lors de la création ou du déplacement d'un système de fichiers ou d'une cible de montage d'un compartiment vers un autre, vous pouvez rencontrer l'une des erreurs d'API 409 suivantes :

Création d'un système de fichiers :

oci.exceptions.ServiceError: {'opc-request-id': <<OPC REQUEST ID>>, 'code': 'Conflict', 'message': 'Another filesystem is currently being provisioned, try again later', 'status': 409}

Déplacement d'un système de fichiers :

oci.exceptions.ServiceError: {'opc-request-id': <<OPC REQUEST ID>>, 'code': 'Conflict', 'message': 'filesystem <<FILE SYSTEM OCID>> is currently being modified, try again later', 'status': 409}

Création d'une cible de montage :

oci.exceptions.ServiceError: {'opc-request-id': <<OPC REQUEST ID>>, 'code': 'Conflict', 'message': 'Another mount target is currently being provisioned, try again later', 'status': 409}

Déplacement d'une cible de montage :

oci.exceptions.ServiceError: {'opc-request-id': <<OPC REQUEST ID>>, 'code': 'Conflict', 'message': 'mount target<<MOUNT TARGET OCID>> is currently being modified, try again later', 'status': 409}

La fonctionnalité de quotas de compartiment introduit des contraintes qui limitent le nombre d'opérations simultanées qu'une location peut effectuer sur les ressources de système de fichiers et de cible de montage dans une région :

  • Chaque location d'une région peut avoir une opération CreateFileSystem ou ChangeFilesystemCompartment en cours à la fois.
  • Chaque location d'une région peut avoir une opération CreateMountTarget ou ChangeMountTargetCompartment en cours à la fois.

Si une location tente d'effectuer plusieurs opérations simultanées, une opération réussit et les autres reçoivent le code de réponse d'erreur 409. La stratégie de nouvelle tentative par défaut pour le kit SDK OCI consiste à ne pas réessayer les opérations en conflit de l'erreur 409. Reportez-vous à la page détaillant les comportements du kit SDK, notamment les nouvelles tentatives.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution. Pour contourner ce problème, créez une stratégie de nouvelle tentative personnalisée qui lance de nouvelles tentatives en cas d'erreur 409. Plusieurs exemples de création d'une stratégie de nouvelle tentative personnalisée sont fournis à la page https://github.com/oracle/oci-python-sdk/blob/master/examples/retries.py.

Lien direct vers ce problème : Erreur 409 lors de la création ou du déplacement d'un système de fichiers ou d'une cible de montage

Functions

Actuellement, il n'existe aucun problème connu lié à Functions.

Health Checks

Actuellement, il n'existe aucun problème connu lié à Health Checks.

IAM

Impossible de configurer de nouvelles fédérations avec Microsoft Active Directory

Détails : pendant le processus de configuration, après le téléchargement du document relatif aux métadonnées de fédération Oracle Cloud Infrastructure, Microsoft AD FS active automatiquement le cryptage d'assertion. Oracle Cloud Infrastructure ne prend pas en charge le cryptage pour le moment. Par conséquent, la configuration échoue.

Solution de contournement : ce problème est résolu. Le service IAM prend désormais en charge le cryptage d'assertion. Reportez-vous à Fédération avec Microsoft Active Directory.

Lien direct vers ce problème : Impossible de configurer de nouvelles fédérations avec Microsoft Active Directory

Les compartiments supprimés sont toujours pris en compte dans les limites de service

Détails : les compartiments supprimés sont toujours pris en compte dans la limite de service de compartiment de votre location. Les compartiments supprimés ne sont plus pris en compte après le nombre de jours indiqué dans le paramètre Période de conservation d'audit (90 à 365 jours). Ce paramètre indique également la période pendant laquelle les compartiments supprimés restent affichés dans la console.

Solution de contournement : tant que ce problème n'est pas résolu, vous pouvez demander l'augmentation de la limite de service des compartiments. Reportez-vous à Demande d'augmentation de limite de service.

Lien direct vers ce problème : Les compartiments supprimés sont toujours pris en compte dans les limites de service

Load Balancing

L'équilibreur de charge affiche le message Inconnu sur l'indicateur d'état des ensembles de back-ends de console

Détails : lors de l'exécution des vérifications de l'équilibreur de charge dans la console, le statut d'état des ensembles de back-ends peut être Inconnu, même si l'équilibreur de charge fonctionne correctement. Le statut Inconnu n'affecte pas le chemin de données.

Solution de contournement : reportez-vous aux graphiques de télémétrie publique de la console Oracle Cloud Infrastructure pour obtenir une indication précise de l'état des ensembles de back-ends de l'équilibreur de charge.

Lien direct vers ce problème : L'équilibreur de charge affiche le message Inconnu sur l'indicateur d'état des ensembles de back-ends de console

Logging Analytics

Gestion spéciale de la surveillance des journaux dans les dossiers volumineux

Détails : les dossiers contenant plus de 10 000 fichiers peuvent entraîner des problèmes de collection de journaux (ainsi que des problèmes au niveau du système d'exploitation).

Lorsque des dossiers volumineux sont détectés par le module d'extension Management Agent de Logging Analytics, un message semblable à l'exemple ci-dessous est ajouté au fichier mgmt_agent.log de Management Agent :

2020-07-30 14:46:51,653 [LOG.Executor.2388 (LA_TASK_os_file)-61850] INFO - ignore large dir /u01/service/database/logs. set property loganalytics.enable_large_dir to enable.

Résolution : nous recommandons d'éviter les dossiers volumineux.

Toutefois, si vous souhaitez continuer à surveiller les journaux dans des dossiers volumineux, vous pouvez activer la propriété indiquée dans le fichier mgmt_agent.log en effectuant l'action suivante :

sudo -u mgmt_agent echo "loganalytics.enable_large_dir=true" >> INSTALL_DIRECTORY/agent_inst/config/emd.properties

Remplacez INSTALL_DIRECTORY par le chemin d'accès au dossier agent_inst.

Lien direct vers ce problème : Gestion spéciale de la surveillance des journaux dans les dossiers volumineux

Management Agent

Il n'existe actuellement aucun problème connu lié à Management Agent.

Marketplace

Actuellement, il n'existe aucun problème connu lié à Marketplace.

Monitoring

Actuellement, il n'existe aucun problème connu lié à Monitoring.

Networking

Configuration de cartes d'interface réseau virtuelles secondaires dans Linux

Détails : le script rendu disponible par Oracle à l'adresse https://docs.cloud.oracle.com/iaas/Content/Resources/Assets/secondary_vnic_all_configure.sh est destiné à être utilisé dans les situations où une adresse IP et une carte d'interface réseau virtuelle supplémentaires doivent être affectées à des instances de calcul non hyperviseur. Le script n'est pas utile pour les applications de machine virtuelle basée sur un noyau (KVM) sur une instance Bare Metal.

Solution de contournement : effectuez les actions suivantes : Pour les applications KVM sur une instance Bare Metal, reportez-vous au livre blanc "Installation et configuration de KVM sur des instances Bare Metal avec plusieurs cartes d'interface réseau virtuelles".

Lien direct vers ce problème : Configuration de cartes d'interface réseau virtuelles secondaires dans Linux

Application d'aide de configuration de CPE : spécification du fournisseur de CPE

Détails : si les événements suivants se produisent, dans la console Oracle, vous recevez un message d'erreur indiquant que le CPE ne comprend pas les informations sur le fournisseur (type de dispositif), et que vous devez mettre à jour le CPE et ajouter les informations concernant le fournisseur :

  • Vous disposez d'un CPE qui existait avant la publication de la fonctionnalité Application d'aide de configuration de CPE.
  • Vous n'avez pas encore modifié le CPE dans la console Oracle et indiqué le fournisseur du CPE.
  • Vous tentez de générer le contenu de l'application d'aide pour le CPE ou toute connexion IPSec utilisant ce CPE.

Solution de contournement : effectuez les actions suivantes :

  1. Dans la console Oracle, affichez le CPE.
  2. Cliquez sur Modifier.
  3. Dans la section Informations sur le fournisseur de CPE, sélectionnez le fournisseur de votre CPE. Si vous n'êtes pas certain du fournisseur du CPE ou qu'il ne figure pas dans la liste, sélectionnez Autre.
  4. Si vous y êtes invité, sélectionnez une valeur pour Plate-forme/Version. Voici quelques instructions :

    • Dans la mesure du possible, Oracle recommande d'utiliser une configuration basée sur un routage.
    • Si votre plate-forme ou version de CPE n'apparaît pas dans la liste, choisissez la plate-forme/version antérieure la plus proche de celle de votre CPE.
  5. Cliquez sur Enregistrer les modifications. Il est important de cliquer sur cette option même si vous n'avez pas modifié la valeur du fournisseur.

Vous pouvez ensuite générer le contenu de l'application d'aide pour le CPE ou toute connexion IPSec utilisant ce CPE.

Lien direct vers ce problème : Application d'aide de configuration de CPE : spécification du fournisseur de CPE

Résolu : Connexion VPN : prise en charge de NAT-T dans la région Est des Etats-Unis (Ashburn)
Connexion VPN : données incorrectes dans plusieurs graphiques Monitoring

Détails : plusieurs graphiques Monitoring pour les tunnels de connexion VPN indiquent des données incorrectes et ne doivent pas être utilisés afin de déterminer les niveaux de trafic récents des tunnels.

Voici la liste des graphiques Monitoring disponibles pour les tunnels de connexion VPN :

  • Etat du tunnel IPSec : ce graphique est exact et indique correctement l'état démarré ou arrêté du tunnel.
  • Octets ou paquets envoyés ou reçus : ces quatre graphiques sont inexacts et n'affichent pas le niveau correct d'octets ou de paquets envoyés ou reçus via le tunnel.
  • Paquets avec des erreurs : ce graphique est inexact et n'affiche pas le nombre correct de paquets supprimés avec des erreurs.

Pour plus d'informations sur les graphiques, reportez-vous à Mesures de connexion VPN.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution.

Lien direct vers ce problème : Connexion VPN : données incorrectes dans plusieurs graphiques Monitoring

Résolu : Connexion VPN : problème avec la disponibilité régionale de NAT-T et Libreswan

Détails : si toutes les conditions suivantes sont réunies :

  • Vous utilisez Libreswan en tant que CPE pour la connexion VPN
  • Le CPE est situé derrière un périphérique NAT
  • Vous vous connectez à l'une des régions Oracle Cloud Infrastructure suivantes : Est des Etats-Unis (Ashburn), Centre de la Corée du Sud (Séoul), Est de Japon (Tokyo) ou Sud-est du Canada (Toronto)

Alors, vous pouvez rencontrer des problèmes de connectivité avec la connexion VPN en raison d'un problème d'interopérabilité de NAT-T (NAT traversal) avec le logiciel en cours sur les routeurs Oracle dans ces régions.

Oracle est conscient du problème. Le logiciel est en cours de mise à jour pour le corriger.

Antécédents : Oracle a activé NAT-T pour certains routeurs de connexion VPN de la région Est des Etats-Unis (Ashburn) et pour tous les routeurs des régions Centre de la Corée du Sud (Séoul), Est de Japon (Tokyo) et Sud-est du Canada (Toronto). Cependant, la version actuelle du logiciel de ces routeurs pose un problème d'interopérabilité avec NAT-T. Si vous suivez la documentation actuelle d'Oracle, qui dit de ne pas activer NAT-T sur le CPE, vous ne devriez pas être concerné par le problème.

Toutefois, si vous utilisez Libreswan en tant que CPE, que le CPE est situé derrière un périphérique NAT et que vous vous connectez à l'une des régions mentionnées, vous risquez de rencontrer des problèmes de connectivité pendant la période de mise à jour du logiciel du routeur par Oracle. Plus précisément, le tunnel peut démarrer sans transmettre le trafic.

Solution de contournement : ce problème est maintenant résolu. La solution de contournement suivante était recommandée avant la résolution du problème :

Pour les utilisateurs Libreswan des régions concernées, si vous rencontrez des problèmes de connectivité, procédez comme suit :

A. Activez NAT-T sur le CPE :

  1. Dans le fichier ipsec.conf de la connexion concernée, pour le paramètre encapsulation, remplacez la valeur no par yes.
  2. Redémarrez le service Libreswan.

Si les problèmes de connectivité persistent, procédez comme suit :

B. Configurez de nouveau la connexion :

  1. Recréez la connexion IPSec dans la console Oracle.
  2. Recréez la configuration Libreswan avec les informations de la nouvelle connexion IPSec.
  3. Rechargez le service Libreswan.

Si les problèmes de connectivité persistent, procédez comme suit :

C. Contactez My Oracle Support pour obtenir de l'aide. Pour obtenir des instructions, reportez-vous à Ouverture d'une demande d'assistance.

Lien direct vers ce problème : Résolu : Connexion VPN : problème avec la disponibilité régionale de NAT-T et Libreswan

Problèmes d'accès privé à Oracle Analytics Cloud via une passerelle de service pour un réseau sur site
Détails : si vous effectuez toutes les opérations suivantes, un routage asymétrique peut survenir pour le trafic entre le réseau sur site et Oracle Analytics Cloud : Le routage asymétrique signifie que le trafic de demande et le trafic de réponse transitent par des chemins différents. Le routage asymétrique peut se produire lorsqu'Oracle Analytics Cloud lance les connexions aux clients du réseau sur site, car les demandes de connexion doivent passer par un chemin public (Internet ou appairage public FastConnect). Cependant, la réponse transite par un chemin privé, conformément aux recommandations figurant dans Préférences de routage pour le trafic du réseau sur site vers Oracle.

Solution de contournement : vous avez deux possibilités.

  • Option 1 (recommandée) : avec Oracle Analytics Cloud, utilisez une passerelle de données au lieu de Remote Data Connector.
  • Option 2 : configurez le CPE (Customer-Premises Equipment) de sorte qu'il privilégie Internet ou un chemin d'appairage public FastConnect en ajoutant des routages statiques pour l'adresse IP source régionale d'Oracle Analytics Cloud. Ainsi, tout trafic de réponse vers Oracle Analytics Cloud sera renvoyé sur le même chemin que la demande de connexion entrante.

Une solution de contournement n'est requise que si vous utilisez Oracle Analytics Cloud pour lancer des connexions aux clients du réseau sur site et que vous n'employez pas encore de passerelle de données sur votre réseau.

Lien direct vers ce problème : Problèmes d'accès privé à Oracle Analytics Cloud via une passerelle de service pour un réseau sur site

Problèmes d'accès aux instances publiques à partir des services Oracle via une passerelle de service
Détails : si la table de routage associée au sous-réseau public d'un réseau cloud virtuel inclut les deux règles de routage en conflit suivantes, les services Oracle peuvent ne pas parvenir à accéder aux instances publiques de ce sous-réseau.
  1. Règle de routage avec le type de cible défini en tant que passerelle Internet.
  2. Règle de routage avec le service de destination défini sur Tous les services <region> d'Oracle Services Network et le type de cible défini en tant que passerelle de service.
Les deux règles de routage ci-dessus peuvent entraîner un routage asymétrique quand les services Oracle lancent des connexions aux instances publiques du réseau cloud virtuel. Oracle Cloud Infrastructure ne prend pas en charge ces règles simultanément dans la même table de routage. Oracle a mis à jour les API de service et la console afin de désactiver la prise en charge de cette configuration.

Solution de contournement : nous vous recommandons d'enlever la règle de routage dont le service de destination est défini sur Tous les services <region> d'Oracle Services Network et dont le type de cible est défini en tant que passerelle de service. Rétablissez la configuration utilisée avant d'adopter la passerelle de service pour Oracle Services Network. Avec cette modification, les instances publiques conservent l'accès à tous les services Oracle via la passerelle Internet. Les services Oracle peuvent continuer à accéder à vos instances publiques.

Toutefois, les instances du sous-réseau public peuvent continuer à accéder à Object Storage via la passerelle de service. Mettez à jour la table de routage du sous-réseau de manière à inclure une règle de routage dont le service de destination est défini sur OCI <region> Object Storage et la cible sur la passerelle de service du réseau cloud virtuel.

Ce problème connu ne concerne que les sous-réseaux publics ayant accès à une passerelle Internet. Concernant les sous-réseaux privés, vous pouvez continuer à configurer leur table de routage de manière à offrir un accès à Tous les services <region> d'Oracle Services Network ou à OCI <region> Object Storage via la passerelle de service du réseau cloud virtuel.

Lien direct vers ce problème : Problèmes d'accès aux instances publiques à partir des services Oracle via une passerelle de service

Résolu : Règles de routage de passerelle de service et restriction de console

Détails : si vous utilisez la console pour configurer une règle de routage qui utilise une passerelle de service comme cible, le service de destination de la règle doit correspondre au libellé CIDR de service activé pour la passerelle. Par exemple : supposons que vous utilisiez la console afin d'activer le libellé Tous les services <region> d'Oracle Services Network pour la passerelle de service. Ensuite, vous utilisez la console afin de configurer une règle de routage et choisissez OCI <region> Object Storage pour le service de destination au lieu du libellé CIDR de service que vous avez indiqué pour la passerelle de service. Lorsque vous essayez de définir la cible de la règle de routage, votre passerelle de service n'apparaît pas dans la liste des passerelles de service parmi lesquelles choisir. En effet, la console prend le service de destination indiqué pour la règle et affiche uniquement les passerelles de service pour lesquelles ce libellé CIDR de service est activé. Le réseau cloud virtuel ne peut avoir qu'une seule passerelle de service et, dans ce cas, il ne respecte pas cette logique. Cette restriction existe uniquement si vous configurez la règle de routage dans la console. Les autres interfaces (kits SDK, CLI, Terraform) ne sont pas soumises à cette restriction. Oracle a pour intention d'enlever cette restriction de l'interface de la console.

Solution de contournement : ce problème est maintenant résolu. La solution de contournement suivante était recommandée avant la résolution du problème :

Utilisez le même libellé CIDR de service pour la passerelle de service et le service de destination de la règle de routage. Sinon, si vous le souhaitez, utilisez une interface non soumise à la restriction (par exemple, la CLI). N'oubliez pas également que vous pouvez filtrer le trafic vers et en provenance des instances à l'aide de listes de sécurité et que vous pouvez utiliser n'importe quel libellé CIDR de service (ou libellé CIDR spécifique) dans une règle de liste de sécurité.

Lien direct vers ce problème : Règles de routage de passerelle de service et restriction de console

Problèmes d'accès aux services YUM Oracle via la passerelle de service
Détails : si vous souhaitez utiliser une passerelle de service avec votre réseau cloud virtuel sans employer de passerelle Internet ou de passerelle NAT pour l'accès à Internet, vos instances peuvent ne pas avoir accès au serveur YUM Oracle régional applicable. Il existe deux problèmes possibles :
  • Les référentiels des instances créées avant novembre 2018 peuvent pointer vers des URL inaccessibles via la passerelle de service
  • Les instances ne pouvant auparavant pas contacter le serveur YUM de leur région locale utilisent peut-être de nouveau yum.oracle.com, qui n'est pas accessible via la passerelle de service
Prérequis : pour utiliser l'une des stratégies d'atténuation ci-dessous, l'une des passerelles doit être configurée de sorte que vous puissiez atteindre le serveur YUM de la région (passerelle de service, passerelle NAT ou passerelle Internet).

Atténuation automatisée :

Essayez la méthode d'atténuation automatisée suivante. Si l'opération échoue pour une raison quelconque, utilisez la méthode d'atténuation manuelle qui suit.

Copiez le script suivant sur le système local et exécutez-le. Ce script désactive les référentiels existants et télécharge le fichier de référentiel, qui oriente le système vers les serveurs YUM locaux de la région, accessibles via la passerelle de service.

#!/bin/bash
REPODIR='/etc/yum.repos.d'
REPOS=$REPODIR/*
REGION=$(curl -sfm 3 http://169.254.169.254/opc/v1/instance/ | jq -r '.region' | cut -d '-' -f 2)
VERSION=$(egrep '^VERSION_ID' /etc/os-release | cut -d '"' -f 2 | cut -d '.' -f 1)
REPOURL="http://yum-${REGION}.oracle.com/yum-${REGION}-ol${VERSION}.repo"

echo "Disabling existing repos"
for i in $REPOS
do
  if [[ "$i" != *".disabled" ]]; then
    mv $i $i.disabled
    echo "$i disabled"
  else
    echo "$i repofile already disabled"
  fi
done
yum clean all
echo "Pulling new regional repository file"
wget -q $REPOURL -O "$REPODIR/yum-${REGION}-ol${VERSION}.repo"
retval=$?
if [[ "$retval" -ne 0 ]]; then
  echo "Unable to pull repo file, please run manual steps"
  exit 1
fi
yum makecache fast
Atténuation manuelle :

En cas d'échec de l'atténuation automatisée, vous pouvez atténuer le problème manuellement. Pour ce faire, désactivez les fichiers de référentiel existants et téléchargez le tout dernier fichier de référentiel à partir du serveur YUM de la région. Pour identifier la clé de région de votre instance, consultez la liste des régions dans Régions et domaines de disponibilité.

Pour désactiver les fichiers de référentiel existants, accédez au répertoire /etc/yum.repos.d et renommez tous les fichiers présents en ajoutant .disabled à la fin de leur nom.

Exemple :

ls /etc/yum.repos.d ksplice-uptrack.repo.disabled public-yum-ol7.repo.disabled

Téléchargez le fichier de référentiel de votre région vers le système local. L'exemple suivant utilise Ashburn (avec la clé de région iad). Remplacez iad par la clé de région applicable à votre instance.

cd /etc/yum.repos.d/
wget http://yum-iad.oracle.com/yum-iad-ol7.repo
chown root:root yum-iad-ol7.repo
yum makecache fast

Lien direct vers ce problème : Accès aux services YUM via la passerelle de service pour certaines images

Résolu : Les instances existantes d'un sous-réseau ne reçoivent pas la liste mise à jour des serveurs DNS dans les options DHCP

Détails : si vous mettez à jour la liste des serveurs DNS dans l'ensemble d'options DHCP d'un sous-réseau, les instances/cartes d'interface réseau virtuelles créées ultérieurement dans ce sous-réseau reçoivent la liste mise à jour, mais pas les instances/cartes d'interface réseau virtuelles existantes du sous-réseau.

Solution de contournement : ce problème est maintenant résolu. La solution de contournement suivante était recommandée avant la résolution du problème :

Vous pouvez créer des instances pour remplacer les instances existantes du sous-réseau. Une autre possibilité est de contacter My Oracle Support avec les informations suivantes :

  • OCID du réseau cloud virtuel
  • OCID du sous-réseau
  • OCID de l'instance concernée

Le problème de l'instance indiquée peut alors généralement être résolu en un jour.

Lien direct vers ce problème : Les instances existantes d'un sous-réseau ne reçoivent pas la liste mise à jour des serveurs DNS dans les options DHCP

Notifications

Actuellement, il n'existe aucun problème connu lié à Notifications.

Object Storage

Actuellement, il n'existe aucun problème connu lié à Object Storage.

OS Management

Impossible d'appliquer toutes les mises à jour Windows classées comme Autre à un groupe d'instances gérées

Détails : OS Management ne fournit actuellement aucune action pour appliquer toutes les mises à jour Windows classées comme Autre à un groupe d'instances gérées.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution. Pour appliquer toutes les mises à jour sur un groupe d'instances gérées, y compris les mises à jour Windows classées comme Autre, sélectionnez Tout pour le type de mise à jour. Pour plus d'informations, reportez-vous à la section Installation des mises à jour sur les instances Windows.

Lien direct vers ce problème : Impossible d'appliquer toutes les mises à jour Windows classées comme Autre à un groupe d'instances gérées

Impossible de gérer AppStreams dans Oracle Linux 8

Détails : pour Oracle Linux 8, le service OS Management ne prend actuellement pas en charge AppStreams, également appelé modules ou flux de modules.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution. Vous pouvez toujours mettre à jour des packages RPM individuels, mais la gestion des versions associée aux modules est ignorée à l'aide de cette méthode. Pour plus d'informations sur AppStreams, reportez-vous à Oracle Linux 8 : Gestion des logiciels sur Oracle Linux.

Lien direct vers ce problème : Impossible de gérer AppStreams dans Oracle Linux 8

Différence entre les mises à jour Windows affichées dans le panneau de configuration et celles dans la console OS Management et l'API

Détails : vous remarquerez peut-être une différence entre les mises à jour Windows affichées dans le panneau de configuration et celles affichées dans la console OS Management et l'API.

Le service OS Management dépend des données qu'il reçoit de l'API WUA (Windows Update Agent). Lors de l'utilisation de l'API WUA, le service OS Management ne dispose pas d'un accès complet à toutes les API disponibles, alors que ce serait le cas avec l'API WSUS (Windows Server Update Service). Les stratégies qui contrôlent ce que vous êtes autorisé à faire sont différentes si vous accédez au service de mise à jour Microsoft en amont ou si vous créez vos propres stratégies à l'aide de WSUS.

Solution de contournement : ce comportement est attendu à ce stade. Nous sommes conscients du problème et essayons de procéder à des améliorations.

Lien direct vers ce problème : Différence entre les mises à jour Windows affichées dans le panneau de configuration et celles dans la console OS Management et l'API

Le chargement initial des sources logicielles dans la console peut prendre plusieurs minutes
Impossible d'utiliser le service OS Management avec les instances trouvées dans les compartiments ManagedCompartmentForPaaS

Détails : le service OS Management ne peut pas être utilisé avec les instances trouvées dans les compartiments ManagedCompartmentForPaaS. Ce compartiment est créé pour le compte de l'utilisateur en vue d'une utilisation avec les services de plate-forme Oracle sur Oracle Cloud Infrastructure. Pour plus d'informations sur ce compartiment, reportez-vous à Informations sur les services de plate-forme pris en charge.

Lien direct vers ce problème : Impossible d'utiliser le service OS Management avec les instances trouvées dans les compartiments ManagedCompartmentForPaaS

Registry

API Registry non disponible

Détails : la fonctionnalité Registry permettant de créer et de gérer des référentiels n'est pas affichée via l'API.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution. Pour contourner ce problème, utilisez la console.

Lien direct vers ce problème : API Registry non disponible

Jusqu'au 30 septembre 2019 inclus, utilisez l'espace de noms de location plutôt que le nom de location dans les balises d'image et les informations d'identification de connexion Docker

Détails : jusqu'à maintenant, vous avez peut-être utilisé le nom de location ou l'espace de noms de location lors de la connexion à Oracle Cloud Infrastructure Registry et lors des opérations sur des images du service Registry.

Après le 30 septembre 2019, vous devrez employer l'espace de noms de location plutôt que le nom de location si vous utilisez Oracle Cloud Infrastructure Registry.

Antécédents : après le 30 septembre 2019, vous ne pourrez plus effectuer les opérations suivantes :

  • Indiquer le nom de location lors de la connexion à Oracle Cloud Infrastructure Registry.
  • Effectuer des opérations sur des images incluant un nom de location dans le chemin de référentiel.

A la place, vous devrez employer l'espace de noms plutôt que le nom de location si vous utilisez Oracle Cloud Infrastructure Registry.

Un espace de noms de location est une chaîne de caractères alphanumériques aléatoire, générée automatiquement et non mutable. Par exemple, l'espace de noms de la location acme-dev peut être ansh81vru1zp. L'espace de noms de location est visible sur la page Registry de la console.

Pour certaines anciennes locations, l'espace de noms de location peut être identique au nom de location. Si c'est le cas, aucune action n'est nécessaire.

Jusqu'au 30 septembre 2019 inclus, si l'espace de noms et le nom de location sont différents, vous devez effectuer les opérations suivantes :

  • Commencez à indiquer l'espace de noms de location lorsque vous vous connectez à Oracle Cloud Infrastructure Registry, plutôt que le nom de location.
  • Commencez à indiquer l'espace de noms de location lorsque vous propagez de nouvelles images vers Oracle Cloud Infrastructure Registry, plutôt que le nom de location.
  • Migrez toutes les images existantes d'Oracle Cloud Infrastructure Registry incluant le nom de location dans le chemin.

Les solutions de contournement et les exemples ci-après s'appuient sur les données suivantes :

  • le nom de location est acme-dev
  • l'espace de noms de location est ansh81vru1zp
  • le nom utilisateur est jdoe@acme.com

Solution de contournement pour vous connecter à Oracle Cloud Infrastructure Registry : précédemment, lorsque vous vous connectiez à Oracle Cloud Infrastructure Registry et que vous étiez invité à saisir un nom utilisateur, vous pouviez le saisir au format <tenancy-name>/<username>.

Par exemple :

$ docker login phx.ocir.io

Username: acme-dev/jdoe@acme.com
Password:

Jusqu'au 30 septembre 2019 inclus, vous devez commencer à utiliser l'espace de noms de location plutôt que le nom de location lorsque vous vous connectez à Oracle Cloud Infrastructure Registry. Lorsque vous êtes invité à saisir un nom utilisateur, entrez-le au format suivant : <tenancy-namespace>/<username>.

Par exemple :

$ docker login phx.ocir.io

Username: ansh81vru1zp/jdoe@acme.com
Password:

Solution de contournement relative à la propagation de nouvelles images vers Oracle Cloud Infrastructure Registry : précédemment, lorsque vous propagiez une nouvelle image vers Oracle Cloud Infrastructure Registry, vous pouviez indiquer le nom de location dans le chemin de référentiel dans la commande docker push. Vous pouviez entrer une commande au format suivant :

$ docker push <region-key>.ocir.io/<tenancy-name>/<image-name>:<tag>

Par exemple :

$ docker push phx.ocir.io/acme-dev/helloworld:latest

Jusqu'au 30 septembre 2019 inclus, vous devez commencer à utiliser l'espace de noms de location plutôt que le nom de location dans la commande docker push lorsque vous propagez de nouvelles images. Entrez la commande au format suivant :

$ docker push <region-key>.ocir.io/<tenancy-namespace>/<image-name>:<tag>

Par exemple :

$ docker push phx.ocir.io/ansh81vru1zp/helloworld:latest

Solution de contournement pour les images existantes d'Oracle Cloud Infrastructure Registry comportant le nom de location dans le chemin de référentiel : si vous avez précédemment propagé des images vers Oracle Cloud Infrastructure Registry, celles-ci peuvent inclure le nom de location dans le chemin de référentiel. Par exemple, phx.ocir.io/acme-dev/helloworld:latest.

Après le 30 septembre 2019, vous ne pourrez plus effectuer d'opérations sur les images existantes du service Registry incluant le nom de location dans le chemin de référentiel.

Par conséquent, jusqu'au 30 septembre 2019 inclus, pour chaque image existante contenant le nom de location dans le chemin de référentiel, vous devez remplacer ce nom par l'espace de noms de location.

Pour remplacer le nom de location par l'espace de noms de location dans le chemin de référentiel d'une image existante, procédez comme suit :

  1. Extrayez l'image en saisissant la commande suivante :

    $ docker pull <region-key>.ocir.io/<tenancy-name>/<image-name>:<tag>

    Par exemple :

    $ docker pull phx.ocir.io/acme-dev/helloworld:latest
  2. Utilisez la commande docker tag pour modifier le chemin de référentiel en saisissant la commande suivante :

    $ docker tag <region-key>.ocir.io/<tenancy-name>/<image-name>:<tag> <region-key>.ocir.io/<tenancy-namespace>/<image-name>:<tag>

    Par exemple :

    $ docker tag phx.ocir.io/acme-dev/helloworld:latest phx.ocir.io/ansh81vru1zp/helloworld:latest
  3. Propagez l'image avec le nouveau chemin de référentiel vers Registry en saisissant la commande suivante :

    $ docker push <region-key>.ocir.io/<tenancy-namespace>/<image-name>:<tag>

    Par exemple :

    $ docker push phx.ocir.io/ansh81vru1zp/helloworld:latest
  4. Répétez les étapes ci-dessus pour chaque image existante comportant un nom de location dans le chemin de référentiel.

Lien direct vers ce problème : Jusqu'au 30 septembre 2019 inclus, utilisez l'espace de noms de location plutôt que le nom de location dans les balises d'image et les informations d'identification de connexion Docker

Resource Manager

Le type oci:core:image:id n'est pas renseigné

Détails : le type oci:core:image:id est affiché en tant que champ de saisie au lieu de la liste déroulante attendue des valeurs OCID d'image.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution.

Lien direct vers ce problème : Le type oci:core:image:id n'est pas renseigné

Echec du repérage de ressources

Détails : lors de l'utilisation du repérage de ressources pour créer une pile à partir d'un compartiment, la demande de travail échoue.

Solution de contournement : pour contourner ce problème, veillez à ce que l'utilisateur qui crée la pile dispose des droits d'accès permettant de rechercher la location dans les compartiments. Créez la stratégie suivante pour le groupe auquel appartient l'utilisateur.

Allow group <group name> to inspect compartments in tenancy

Lien direct vers ce problème : Echec du repérage de ressources

Attributs manquants dans certaines ressources repérées

Détails : des attributs sont manquants dans certaines ressources prises en charge capturées à l'aide du repérage de ressources.

Service Type de ressource Champs manquants (avec liens vers la documentation du fournisseur OCI Terraform)
Big Data Instances

cluster_admin_password

cluster_public_key

Volume de blocs (principal) Volumes volume_backup_id
Compute (principal) Images instance_id

image_source_details

Compute (principal) Configurations d'instance instance_id

source

Compute (principal) Connexions à la console pour une instance public_key
Compute (principal) Instances

hostname_label (en phase d'abandon)

is_pv_encryption_in_transit_enabled

subnet_id (en phase d'abandon)

Compute (principal) Attachements de volume use_chap
Container Engine for Kubernetes Pools de noeuds node_source_details
Data Catalog Connexions enc_properties
Database Bases de données Conteneur Autonomous maintenance_window_details
Database Bases de données autonomes

admin_password

autonomous_database_backup_id

autonomous_database_id

clone_type

is_preview_version_with_service_terms_accepted

source

source_id

timestamp

Database Infrastructures Exadata Autonomous maintenance_window_details
Database Bases de données

admin_password

backup_id

backup_tde_password

db_version

source

Database Répertoires de base de base de données

admin_password

backup_id

backup_tde_password

source

Database Systèmes de base de données

admin_password

backup_id

backup_tde_password

maintenance_window_details

IAM Fournisseurs d'identités metadata
Load Balancing Equilibreurs de charge ip_mode
Marketplace Contrats acceptés signature
Networking (principal) Connexions croisées

far_cross_connect_or_cross_connect_group_id

near_cross_connect_or_cross_connect_group_id

NoSQL Database Cloud Index is_if_not_exists
Object Storage Objets

cache_control

content

content_disposition

content_encoding

content_language

source

source_uri_details

Web Application Acceleration and Security Certificats

certificate_data

is_trust_verification_disabled

private_key_data

Web Application Acceleration and Security Stratégies

are_redirects_challenged

is_case_sensitive

is_nat_enabled (human_interaction_challenge)

is_nat_enabled (js_challenge)

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution.

Lien direct vers ce problème : Attributs manquants dans certaines ressources repérées

Résolu : Erreur lors de l'exécution de la détection de dérive

Détails : une erreur est survenue lors de la tentative d'exécution de la détection de dérive sur une pile.

Solution de contournement : ce problème est maintenant résolu. La solution de contournement suivante était recommandée avant la résolution du problème :

Pour contourner ce problème, mettez à jour la pile pour inclure une variable de région, puis réessayez. Exemple de variable de région : {"region": "eu-frankfurt-1"}

Lien direct vers ce problème : Résolu : Erreur lors de l'exécution de la détection de dérive

Hub de connecteur de service

Il n'existe actuellement aucun problème connu lié au hub de connecteur de service.

Storage Gateway

Exceptions à la conformité POSIX

Détails : les conversions de fichier à objet suivantes ne sont pas prises en charge :

  • Listes de contrôle d'accès
  • Liens symboliques, hard links, canaux nommés et périphériques spéciaux
  • Sticky bits

Solution de contournement : si vous devez copier des fichiers spéciaux dans Object Storage, créez une archive tar des fichiers.

Lien direct vers ce problème : Exceptions de conformité POSIX

La commande df ne parvient pas à indiquer la taille et la capacité exactes

Détails : si vous exécutez la commande df sur un système de fichiers dans un client NFS, df indique une taille de système de fichiers de 0 (zéro) octet et une capacité de 8 Eo (capacité maximale). Object Storage ne possédant pas de quotas et pouvant stocker une quantité illimitée de données, il est impossible d'indiquer la taille du système de fichiers. Le bucket Object Storage n'indiquant pas l'utilisation du stockage, il est impossible de spécifier la capacité.

Solution de contournement : vous pouvez exécuter la commande du pour obtenir les informations d'utilisation, mais celle-ci implique un grand volume de métadonnées et prend un certain temps. Vous pouvez également répertorier tous les objets d'Object Storage et additionner leur taille pour déterminer l'utilisation actuelle d'Object Storage. Toutefois, cette méthode ne prend pas en compte les données stockées dans le cache du système de fichiers. Vous pouvez par ailleurs recourir à des mécanismes hors bande donnant une approximation de l'utilisation du stockage.

Lien direct vers ce problème : La commande df ne parvient pas à indiquer la taille et la capacité exactes

Tagging

Echec de la création d'une valeur de balise par défaut sous certaines conditions

Détails : la création d'une valeur de balise par défaut échoue lorsque les deux conditions suivantes sont réunies : l'espace de noms de balise contient une seule définition de clé active et plusieurs définitions de clé de balise mises hors service.

Solution de contournement : pour contourner ce problème, vous pouvez créer une autre définition de clé de balise dans l'espace de noms de balise.

Lien direct vers ce problème : Echec de la création d'une valeur de balise par défaut sous certaines conditions

Echec de la suppression d'une valeur de balise par défaut lorsque la balise est mise hors service
Dérive de l'état de Terraform avec les valeurs de balise par défaut et les balises des ressources secondaires

Détails : dans certains builds Terraform, aucune balise n'est créée pour les ressources secondaires et les balises par défaut configurées pour un compartiment ne sont pas automatiquement appliquées aux ressources. Il peut en résulter des balises par défaut manquantes et des ressources secondaires ne possédant pas de balises correspondant aux ressources principales. Dans certains cas, Terraform peut effectuer une boucle sans fin.

Solution de contournement : recherchez les éventuels problèmes de balisage dans votre script Terraform et dans chaque compartiment de la location.

  1. Examinez le script Terraform.

    • Pour toute ressource principale contenant des balises, copiez la balise à format libre ou définie vers la ressource secondaire. Par exemple, si votre configuration Terraform comporte une ressource principale telle qu'une instance de calcul et une ressource secondaire imbriquée telle qu'une carte d'interface réseau virtuelle attachée, copiez les balises de l'instance de calcul vers la carte d'interface réseau virtuelle. Les réseaux cloud virtuels et les pools d'instances sont également des ressources principales pouvant créer des ressources secondaires.

  2. Examinez l'arborescence des répertoires dans la location que vous créez.

    1. Commencez au niveau du compartiment racine et déterminez si des balises par défaut ont été configurées pour ce compartiment. Bien que les valeurs de balise soient facultatives, les valeurs par défaut permettent d'indiquer qu'une balise requiert une valeur.

    2. Les valeurs de balise par défaut sont définies pour un compartiment spécifique. Dans la console, vous les gérez sur la page Détails du compartiment.

      Cette capture d'écran présente la page Détails du compartiment de la console.

    3. Si le compartiment comporte des balises par défaut pour les ressources qui y sont créées, appliquez les balises et les valeurs correspondantes requises qui seraient créées par les valeurs par défaut à toutes les ressources que vous créerez avec votre script Terraform. En raison de l'héritage de balises, la balise par défaut est appliquée à toutes les ressources créées dans le compartiment, y compris les compartiments enfant et les ressources créées dans ces derniers. Reportez-vous à Héritage de balises.
    4. Répétez ces étapes pour tous les compartiments enfant en mettant à jour le script Terraform pour que toutes les balises par défaut soient prises en compte.

Lien direct vers ce problème : Dérive de l'état de Terraform avec les valeurs de balise par défaut et les balises des ressources secondaires

Traffic Management Steering Policies

Actuellement, il n'existe aucun problème connu lié à Traffic Management Steering Policies.

Vault

Actuellement, il n'existe aucun problème connu lié à Vault.

Web Application Firewall (WAF)

Une modification DNS globale provoque une interruption de service si les nouveaux sous-réseaux ne sont pas mis sur liste blanche

Détails : des modifications DNS globales seront effectuées pour tous les clients Oracle Web Application Firewall (WAF) à compter de décembre 2019. Tous les clients disposant d'un verrouillage d'origine (utilisant une liste blanche d'adresses IP explicites) et ne mettant pas sur liste blanche les nouveaux sous-réseaux subiront des temps d'inactivité et une dégradation du service.

Solution de contournement : (action requise) les clients doivent mettre sur liste blanche les nouveaux sous-réseaux pour éviter toute interruption de service. Pour consulter la documentation d'API, reportez-vous à ListEdgeSubnets.

Liste blanche d'extension OCI WAF

130.35.0.0/20

130.35.128.0/20

130.35.240.0/20

138.1.32.0/21

138.1.128.0/19

147.154.96.0/19

192.29.96.0/20

130.35.16.0/20

130.35.48.0/20

130.35.64.0/19

130.35.96.0/20

130.35.120.0/21

130.35.144.0/20

130.35.176.0/20

130.35.192.0/19

130.35.224.0/22

130.35.232.0/21

138.1.48.0/21

147.154.0.0/18

147.154.64.0/20

147.154.80.0/21

130.35.112.0/22

138.1.16.0/20

138.1.80.0/20

138.1.208.0/20

138.1.224.0/19

147.154.224.0/19

138.1.0.0/20

138.1.40.0/21

138.1.64.0/20

138.1.96.0/21

138.1.104.0/22

138.1.160.0/19

138.1.192.0/20

147.154.128.0/18

147.154.192.0/20

147.154.208.0/21

192.29.0.0/20

192.29.64.0/20

192.29.128.0/21

192.29.144.0/21

192.29.16.0/21

192.29.32.0/21

192.29.48.0/21

192.29.56.0/21

Lien direct vers ce problème : Une modification DNS globale provoque une interruption de service si les nouveaux sous-réseaux ne sont pas mis sur liste blanche