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.

Anomaly Detection

Il n'existe actuellement aucun problème connu concernant le service Anomaly Detection.

Application Performance Monitoring

Les moniteurs Navigateur et Navigateur associé à des scripts peuvent ne pas exécuter d'applications utilisant des cadres

Détails : dans la surveillance synthétique, les moniteurs Navigateur et Navigateur associé à des scripts peuvent ne pas s'exécuter sur des applications qui utilisent des cadres.

Solution de contournement : nous sommes conscients du problème et travaillons à sa résolution. Pour les moniteurs Navigateur associé à des scripts, vous pouvez contourner ce problème en remplaçant index=<frame-index> par id=<id-of-frame> ou name=<name-of-frame> dans le script .side.

Par exemple, si ce script est la version d'origine :

{
      "id": "23956f51-8812-40e6-ac91-1d608871ee4c",
      "comment": "",
      "command": "selectFrame",
      "target": "index=0",
      "targets": [
        ["index=0"]
      ],
      "value": ""
    }

Le script suivant en est la version modifiée :

{
      "id": "23956f51-8812-40e6-ac91-1d608871ee4c",
      "comment": "",
      "command": "selectFrame",
      "target": "id=frame1",
      "targets": [
        ["id=frame1"]
      ],
      "value": ""
    }

Lien direct vers ce problème : Les moniteurs Navigateur et Navigateur associé à des scripts peuvent ne pas exécuter d'applications utilisant des cadres

Problèmes relatifs aux stratégies d'autorisation basées sur les balises de ressource apm-domains

Détails : les stratégies d'autorisation basées sur les balises de ressource apm-domains ne fonctionnent pas pour les API Explorateur de traces et Surveillance synthétique, ce qui entraîne des échecs d'autorisation.

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

Lien direct vers ce problème : Problèmes relatifs aux stratégies d'autorisation basées sur les balises de ressource apm-domains

Artifact Registry

Pour consulter les problèmes connus relatifs à Artifact Registry, reportez-vous à Problèmes connus.

Audit

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

Automated CEMLI Execution

Pour consulter les problèmes connus relatifs à Automated CEMLI Execution, reportez-vous à Problèmes connus.

Bastion

Pour consulter les problèmes connus relatifs à Bastion, reportez-vous à Problèmes connus.

Big Data

Pour consulter les problèmes connus relatifs à Big Data Service, reportez-vous à Problèmes connus.

Block Volume

La réplication inter-régions n'est pas prise en charge pour les volumes cryptés avec des clés gérées par le client

Détails : lorsque vous essayez d'activer la réplication inter-régions pour un volume configuré de sorte à utiliser une clé de cryptage Vault, le message d'erreur suivant apparaît : Erreur lors de la modification du volume : vous ne pouvez pas activer la réplication inter-régions pour le volume <ID_volume> car il utilise une clé de cryptage Vault.

Solution de contournement : nous travaillons à une résolution. La réplication inter-régions n'est pas prise en charge pour les volumes cryptés avec une clé gérée par le client. Pour activer la réplication, annulez l'affectation de la clé de cryptage Vault au volume comme solution de contournement. Dans ce scénario, le volume est crypté avec une clé gérée par Oracle.

Lien direct vers ce problème : La réplication inter-régions n'est pas prise en charge pour les volumes cryptés avec des clés gérées par le client

Les chemins d'accès multiples ne sont pas activés pour l'attachement de volume paravirtualisé une fois l'instance redimensionnée

Détails : afin que les volumes configurés pour des performances très élevées fonctionnent à un niveau optimal des performances, les chemins d'accès multiples doivent être activés pour l'attachement de volume. Les attachements à des instances de machine virtuelle pour lesquels les chemins d'accès multiples sont activés sont uniquement pris en charge pour les instances reposant sur des formes avec au moins 16 OCPU.

Si vous disposez d'une instance comportant moins de 16 OCPU, vous pouvez la redimensionner de sorte qu'elle en compte 16 ou plus et prenne en charge les attachements pour lesquels les chemins d'accès multiples sont activés. Cette étape ne fonctionne pas pour les instances où le nombre d'OCPU était initialement inférieur à 8 et où l'attachement de volume est paravirtualisé. Dans ce cas, une fois le volume détaché et réattaché, les chemins d'accès multiples ne sont toujours pas activés pour l'attachement de volume, même si l'instance prend désormais en charge les attachements pour lesquels les chemins d'accès multiples sont activés.

Solution de contournement : pour contourner le problème, nous vous recommandons de créer une instance reposant sur une forme avec 16 OCPU ou plus, puis d'attacher le volume à la nouvelle instance.

Lien direct vers ce problème : Les chemins d'accès multiples ne sont pas activés pour l'attachement de volume paravirtualisé une fois l'instance redimensionnée

Risque d'échec de l'attachement du nombre maximal de volumes de blocs à des instances VM.Standard.A1.Flex plus petites

Détails : lorsque vous tentez d'attacher le nombre maximal de volumes de blocs à une instance VM.Standard.A1.Flex plus petite, l'attachement des volumes peut échouer dans certains cas. Cela se produit en raison des limitations de la configuration de l'hôte physique sous-jacent.

Solution de contournement : nous travaillons à une résolution. Pour contourner le problème, nous vous recommandons d'augmenter la taille de la machine virtuelle en la redimensionnant, puis de réessayer d'attacher les volumes.

Lien direct vers ce problème : Risque d'échec de l'attachement du nombre maximal de volumes de blocs à des instances VM.Standard.A1.Flex plus petites

Clés de cryptage Vault non copiées dans la région de destination pour les copies de sauvegarde inter-région programmées

Détails : lorsque vous programmez des sauvegardes de volume et de groupe de volumes à l'aide d'une stratégie de sauvegarde activée pour la copie inter-région de volumes cryptés avec les clés de cryptage du service Vault, les clés de cryptage ne sont pas copiées avec la sauvegarde de volume dans la région de destination. Les copies de sauvegarde de volume dans la région de destination sont à la place cryptées à l'aide des clés fournies par Oracle.

Solution de contournement : nous travaillons à une résolution. Pour contourner ce problème, vous pouvez copier manuellement les sauvegardes de volume et de groupe de volumes dans les régions, manuellement ou à l'aide d'un script, et indiquer l'ID de clé de gestion des clés dans la région cible pour l'opération de copie. Pour plus d'informations sur la copie inter-région manuelle, reportez-vous à Copie d'une sauvegarde de volume entre des régions.

Lien direct vers ce problème : Clés de cryptage Vault non copiées dans la région de destination pour les copies de sauvegarde inter-région programmées

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

Détails : lorsque vous associez 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 de blocs, 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

L'attribut bootVolumeSizeInGBs est NULL

Détails : lors de l'appel de GetInstance, l'attribut bootVolumeSizeInGBs d'InstanceSourceViaImageDetails est NULL.

Solution de contournement : nous travaillons à une résolution. Pour contourner ce problème, appelez GetBootVolume et utilisez l'attribut sizeInGBs de BootVolume.

Lien direct vers ce problème : L'attribut bootVolumeSizeInGBs est NULL

Blockchain Platform

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

Certificates

Pour consulter les problèmes connus relatifs à Certificates, reportez-vous à Problèmes connus.

Compute Cloud@Customer

Pour consulter les problèmes connus relatifs à Compute Cloud@Customer, reportez-vous à Problèmes connus.

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 Registry

Pour consulter les problèmes connus relatifs à Container Registry, reportez-vous à Problèmes connus.

Data Catalog

Pour consulter les problèmes connus relatifs à Data Catalog, reportez-vous à Problèmes connus.

Data Flow

Pour consulter les problèmes connus relatifs à Data Flow, reportez-vous à Problèmes connus.

Data Integration

Pour consulter les problèmes connus relatifs à Data Integration, reportez-vous à Problèmes connus.

Data Labeling

Pour consulter les problèmes connus relatifs à Data Labeling, reportez-vous à Problèmes connus.

Data Science

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

Data Transfer

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

Database

Bases de données pluggables existantes dans une nouvelle base de données

Détails : les bases de données pluggables existantes n'apparaissent pas dans les nouvelles bases de données. De plus, plusieurs heures peuvent s'écouler avant qu'elles n'apparaissent dans la console. Cela inclut la base de données pluggable par défaut pour une nouvelle base de données et les bases de données pluggables existantes pour les bases de données clonées ou restaurées. Dans le cas d'une restauration dynamique vers une version antérieure, la liste des bases de données pluggables est mise à jour de la même manière et peut nécessiter un petit délai.

Solution de contournement : aucune

Lien direct vers ce problème : Bases de données pluggables existantes dans une nouvelle base de données

Base de données pluggable dans la configuration Data Guard existante

Détails : la création et le clonage d'une base de données pluggable dans la base de données principale ne sont pas autorisés via la console ou l'API.

Solution de contournement : vous pouvez utiliser SQLPlus pour créer ou cloner des bases de données pluggables dans la base de données principale. Elles seront synchronisées ultérieurement dans la console OCI.

Lien direct vers ce problème : Base de données pluggable dans la configuration Data Guard existante

Migration d'un portefeuille TDE basé sur un fichier vers un portefeuille TDE basé sur une clé gérée par le client sur Oracle Database 12c V1

Détails : l'utilisation de l'API du service Database pour migrer un portefeuille TDE basé sur un fichier vers un portefeuille TDE basé sur une clé gérée par le client sur Oracle Database 12c version 1 (12.1.0.2) échoue avec l'erreur suivante :

[FATAL] [DBAAS-11014] - Les patches requis (30128047) ne sont pas présentés dans le répertoire de base Oracle <ORACLE_HOME>
ACTION : appliquez les patches requis (30128047) et réessayez d'effectuer l'opération

Solution de contournement : utilisez l'utilitaire DBAASCLI avec l'indicateur --skip_patch_check true afin d'ignorer la validation du patch pour le bug 30128047. Vérifiez que vous avez appliqué le patch pour le bug 31527103 dans le répertoire de base Oracle, puis exécutez la commande dbaascli suivante :
nohup /var/opt/oracle/dbaascli/dbaascli tde file_to_hsm --dbname <database_name> --kms_key_ocid <kms_key_ocid> --skip_patch_check true &

Dans la commande précédente, <kms_key_ocid> fait référence à l'OCID de la clé gérée par le client que vous utilisez.

Migration d'un portefeuille TDE basé sur une clé gérée par le client vers un portefeuille TDE basé sur un fichier sur Oracle Database 12c V1

Détails : l'utilisation de l'API du service Database pour migrer un portefeuille TDE basé sur une clé gérée par le client vers un portefeuille TDE basé sur un fichier sur Oracle Database 12c version 1 (12.1.0.2) échoue avec l'erreur suivante :

[FATAL] [DBAAS-11014] - Les patches requis (30128047) ne sont pas présentés dans le répertoire de base Oracle <ORACLE_HOME>
ACTION : appliquez les patches requis (30128047) et réessayez d'effectuer l'opération

Solution de contournement : utilisez l'utilitaire DBAASCLI avec l'indicateur --skip_patch_check true afin d'ignorer la validation du patch pour le bug 30128047. Vérifiez que vous avez appliqué le patch pour le bug 29667994 dans le répertoire de base Oracle, puis exécutez la commande dbaascli suivante :
nohup /var/opt/oracle/dbaascli/dbaascli tde hsm_to_file --dbname <database_name> --skip_patch_check true &
Migration d'un portefeuille TDE basé sur un fichier vers un portefeuille TDE basé sur une clé gérée par le client sur Oracle Database 12c V2

Détails : l'utilisation de l'API du service Database pour migrer un portefeuille TDE basé sur un fichier vers un portefeuille TDE basé sur une clé gérée par le client sur Oracle Database 12c version 2 (12.2.0.1) échoue avec l'erreur suivante :

[FATAL] [DBAAS-11014] - Les patches requis (30128047) ne sont pas présentés dans le répertoire de base Oracle <ORACLE_HOME>
ACTION : appliquez les patches requis (30128047) et réessayez d'effectuer l'opération

Solution de contournement : migrez un portefeuille TDE basé sur un fichier vers un portefeuille TDE basé sur une clé gérée par le client en procédant comme suit :

  1. Déterminez si la base de données a des tablespaces UNDO ou TEMP cryptés dans l'une des bases de données autonomes ou dans CDB$ROOT, comme suit :
    Exécutez la requête suivante à partir de CDB$ROOT afin de répertorier tous les tablespaces cryptés contenus dans toutes les bases de données autonomes :
    SQL> select tstab.con_id, tstab.name from v$tablespace tstab, v$encrypted_tablespaces enctstab where tstab.ts# = enctstab.ts# and encryptedts = 'YES';

    Dans la colonne NAME du résultat de la requête, recherchez les noms des tablespaces UNDO et TEMP. S'il existe des tablespaces UNDO ou TEMP cryptés, passez à l'étape suivante.

  2. Décryptez les tablespaces UNDO ou TEMP en procédant comme suit :

    Si un tablespace UNDO est crypté :

    Décryptez les tablespaces UNDO existants en procédant comme suit :
    SQL> alter tablespace <undo_tablespace_name> encryption online decrypt;

    Répétez cette procédure pour tous les tablespaces UNDO cryptés.

    Si un tablespace TEMP est crypté :
    1. Vérifiez le tablespace TEMP par défaut en procédant comme suit :
      SQL> select property_value from database_properties where property_name = 'DEFAULT_TEMP_TABLESPACE';
      Si le tablespace TEMP par défaut n'est pas crypté mais que d'autres tablespaces TEMP le sont, supprimez les autres tablespaces TEMP, comme suit :
      SQL> drop tablespace <temp_tablespace_name>;

      Ignorez le reste des étapes de cette procédure.

      Si le tablespace TEMP par défaut est crypté, suivez le reste des étapes pour créer et définir un tablespace TEMP non crypté par défaut.

    2. Définissez le paramètre encrypt_new_tablespaces sur DDL, comme suit :
      SQL> alter system set "encrypt_new_tablespaces" = DDL scope = memory;
    3. Créez un tablespace TEMP avec les spécifications du tablespace TEMP en cours, comme suit :
      SQL> create temporary tablespace <temp_tablespace_name> TEMPFILE size 5000M;
    4. Définissez le nouveau tablespace TEMP comme tablespace TEMP par défaut pour la base de données, comme suit :
      SQL> alter database default temporary tablespace <temp_tablespace_name>;
    5. Supprimez les tablespaces TEMP existants, comme suit :
      SQL> drop tablespace <temp_tablespace_name>;

    Répétez cette procédure pour tous les tablespaces TEMP cryptés.

    La base de données est désormais en cours d'exécution avec les tablespaces UNDO et TEMP par défaut qui ne sont pas cryptés. Les tablespaces TEMP et UNDO plus anciens sont également décryptés.

    Définissez encrypt_new_tablespaces sur sa valeur d'origine, comme suit :
    SQL> alter system set "encrypt_new_tablespaces" = cloud_only;

    Procédez à la migration du fichier de clés vers les clés gérées par le client.

  3. Une fois que vous avez vérifié qu'aucun tablespace UNDO ou TEMP n'est crypté dans aucune des bases de données pluggables ou dans CDB$ROOT, exécutez l'utilitaire DBAASCLI avec l'indicateur --skip_patch_check true afin d'ignorer la validation du patch pour le bug 30128047. Vérifiez que vous avez appliqué le patch pour le bug 31527103 dans le répertoire de base Oracle, puis exécutez la commande dbaascli suivante :
    nohup /var/opt/oracle/dbaascli/dbaascli tde file_to_hsm --dbname <database_name> --kms_key_ocid <kms_key_ocid> --skip_patch_check true &

    Dans la commande précédente, <kms_key_ocid> fait référence à l'OCID de la clé gérée par le client que vous utilisez.

Migration d'un portefeuille TDE basé sur une clé gérée par le client vers un portefeuille TDE basé sur un fichier sur Oracle Database 12c V2

Détails : l'utilisation de l'API du service Database pour migrer un portefeuille TDE basé sur une clé gérée par le client vers un portefeuille TDE basé sur un fichier sur Oracle Database 12c version 2 (12.2.0.1) échoue avec l'erreur suivante :

[FATAL] [DBAAS-11014] - Les patches requis (30128047) ne sont pas présentés dans le répertoire de base Oracle <ORACLE_HOME>
ACTION : appliquez les patches requis (30128047) et réessayez d'effectuer l'opération

Solution de contournement : migrez un portefeuille TDE basé sur une clé gérée par le client vers un portefeuille TDE basé sur un fichier, comme suit :

  1. Déterminez si la base de données a des tablespaces UNDO ou TEMP cryptés dans l'une des bases de données autonomes ou dans CDB$ROOT, comme suit :
    Exécutez la requête suivante à partir de CDB$ROOT afin de répertorier tous les tablespaces cryptés contenus dans toutes les bases de données autonomes :
    SQL> select tstab.con_id, tstab.name from v$tablespace tstab, v$encrypted_tablespaces enctstab where tstab.ts# = enctstab.ts# and encryptedts = 'YES';

    Dans la colonne NAME du résultat de la requête, recherchez les noms des tablespaces UNDO et TEMP. S'il existe des tablespaces UNDO ou TEMP cryptés, passez à l'étape suivante.

  2. Décryptez les tablespaces UNDO ou TEMP en procédant comme suit :

    Si un tablespace UNDO est crypté :

    Décryptez les tablespaces UNDO existants en procédant comme suit :
    SQL> alter tablespace <undo_tablespace_name> encryption online decrypt;

    Répétez cette procédure pour tous les tablespaces UNDO cryptés.

    Si un tablespace TEMP est crypté :
    1. Vérifiez le tablespace TEMP par défaut en procédant comme suit :
      SQL> select property_value from database_properties where property_name = 'DEFAULT_TEMP_TABLESPACE';
      Si le tablespace TEMP par défaut n'est pas crypté mais que d'autres tablespaces TEMP le sont, supprimez les autres tablespaces TEMP, comme suit :
      SQL> drop tablespace <temp_tablespace_name>;

      Ignorez le reste des étapes de cette procédure.

      Si le tablespace TEMP par défaut est crypté, suivez le reste des étapes pour créer et définir un tablespace TEMP non crypté par défaut.

    2. Définissez le paramètre encrypt_new_tablespaces sur DDL, comme suit :
      SQL> alter system set "encrypt_new_tablespaces" = DDL scope = memory;
    3. Créez un tablespace TEMP avec les spécifications du tablespace TEMP en cours, comme suit :
      SQL> create temporary tablespace <temp_tablespace_name> TEMPFILE size 5000M;
    4. Définissez le nouveau tablespace TEMP comme tablespace TEMP par défaut pour la base de données, comme suit :
      SQL> alter database default temporary tablespace <temp_tablespace_name>;
    5. Supprimez les tablespaces TEMP existants, comme suit :
      SQL> drop tablespace <temp_tablespace_name>;

    Répétez cette procédure pour tous les tablespaces TEMP cryptés.

    La base de données est désormais en cours d'exécution avec les tablespaces UNDO et TEMP par défaut qui ne sont pas cryptés. Les tablespaces TEMP et UNDO plus anciens sont également décryptés.

    Définissez encrypt_new_tablespaces sur sa valeur d'origine, comme suit :
    SQL> alter system set "encrypt_new_tablespaces" = cloud_only;

    Procédez à la migration du fichier de clés vers les clés gérées par le client.

  3. Une fois que vous avez vérifié qu'aucun tablespace UNDO ou TEMP n'est crypté dans aucune des bases de données pluggables ou dans CDB$ROOT, exécutez l'utilitaire DBAASCLI avec l'indicateur --skip_patch_check true afin d'ignorer la validation du patch pour le bug 30128047. Vérifiez que vous avez appliqué le patch pour le bug 29667994 dans le répertoire de base Oracle, puis exécutez la commande dbaascli suivante :
    nohup /var/opt/oracle/dbaascli/dbaascli tde file_to_hsm --dbname <database_name> --kms_key_ocid <kms_key_ocid> --skip_patch_check true &

    Dans la commande précédente, <kms_key_ocid> fait référence à l'OCID de la clé gérée par le client que vous utilisez.

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 travaillons à une 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 obtenir des détails, reportez-vous à Problèmes d'accès des instances aux services yum d'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 des outils dans une instance Exadata Cloud Service 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 de patches à Oracle Grid Infrastructure et aux bases de données Oracle à l'aide de dbaascli pour obtenir des instructions sur la manière d'employer l'utilitaire dbaascli afin d'appliquer des patches pour Oracle Grid Infrastructure et Oracle Database sur Exadata Database Service on Dedicated Infrastructure.

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 des outils dans une instance Exadata Cloud Service.
  • 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 les sauvegardes sur Exadata Cloud Service.

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 Mise à jour des outils dans une instance Exadata Cloud Service pour vérifier que le package de l'outil correspond à la version 17430 ou version antérieure, puis le mettre à 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

Redimensionnement du stockage d'un système de base de données de machine virtuelle

Si vous redimensionnez du stockage de données standard ou du stockage de zone de récupération (RECO) d'une valeur inférieure à 10 240 Go (10 To) à une valeur supérieure à 10 240 Go, effectuez le redimensionnement en deux opérations. Tout d'abord, redimensionnez le système à 10 240 Go. Une fois que cette première opération de redimensionnement est terminée et que le système présente l'état Disponible, effectuez une seconde opération de redimensionnement, en indiquant une valeur de stockage cible supérieure à 10 240 Go. Toute tentative de redimensionnement d'une valeur inférieure à 10 240 Go à une valeur supérieure à 10 240 Go en une seule opération peut entraîner l'échec de l'opération. Pour obtenir des instructions sur le redimensionnement, reportez-vous à Augmentation du stockage pour un système de base de données de machine virtuelle.

Echec du redimensionnement de la forme des systèmes de base de données de machine virtuelle car le paramètre DB_Cache_nX n'est pas égal à 0 (zéro)

Détails : lors du redimensionnement d'un système de base de données de machine virtuelle pour utiliser une forme de système plus grande, l'opération de redimensionnement échoue si un paramètre DB_Cache_nX n'est pas défini sur 0 (zéro).

Solution de contournement : lors du redimensionnement d'un système de base de données de machine virtuelle, assurez-vous que tous les paramètres DB_Cache_nX (par exemple, DB_nK_CACHE_SIZE) sont définis sur 0.

DNS

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

Document Understanding

Pour consulter les problèmes connus relatifs à Document Understanding, reportez-vous à Problèmes connus.

Events

Actuellement, il n'existe aucun problème connu pour Events.

Full Stack Disaster Recovery

Sauvegardes de groupe de volumes pour effectuer une récupération après sinistre intra-région et inter-domaines de disponibilité

Détails : si vous utilisez des sauvegardes de groupe de volumes lorsque vous effectuez des opérations de récupération après sinistre pour le calcul et le stockage sur différents domaines de disponibilité au sein d'une même région, les transitions de récupération après sinistre aller-retour font que le calcul et le stockage de blocs associé (qui utilise des sauvegardes de groupe de volumes) se retrouvent à chaque fois dans un domaine de disponibilité différent.

Solution de contournement : ce problème n'affecte pas le stockage de blocs répliqué à l'aide de la réplication de groupe de volumes.

Les paramètres du réglage automatique des performances pour les volumes de stockage de blocs ne sont pas repris lors des opérations de récupération après sinistre

Détails : les paramètres du réglage automatique des performances pour les volumes de stockage de blocs ne sont pas repris lors des opérations de récupération après sinistre

Solution de contournement : pour les volumes de stockage de blocs pour lesquels le réglage automatique des performances est activé, vous devez réactiver ces paramètres une fois que la récupération après sinistre de la pile complète a transféré ces volumes de stockage de blocs vers une autre région.

Les modifications apportées aux ressources protégées contre la récupération après sinistre de la pile complète peuvent entraîner des problèmes dans certaines situations de basculement

Détails : si vous effectuez une opération de basculement immédiatement après avoir modifié une ressource protégée par la récupération après sinistre de la pile complète, la récupération de la ressource peut échouer ou la ressource peut ne pas être récupérée correctement. Par exemple, si vous modifiez la cible de réplication ou d'autres propriétés d'un groupe de volumes que vous avez ajouté à un groupe de protection de récupération après sinistre, et que la région principale subit par la suite une coupure immédiate, Full Stack DR peut ne pas détecter les modifications apportées aux paramètres de réplication du groupe de volumes, ce qui affectera la récupération de ce groupe de volumes.

Solution de contournement : effectuez une prévérification de permutation immédiatement après avoir apporté des modifications aux ressources sous protection de récupération après sinistre.

Les étapes définies par l'utilisateur sur les instances Microsoft Windows ne peuvent pas employer Exécuter en tant qu'utilisateur lors de l'exécution de scripts locaux

Détails : Full Stack DR utilise l'utilitaire Commande d'exécution de l'agent Oracle Cloud pour exécuter des scripts locaux sur les instances. Lorsque vous configurez une étape définie par l'utilisateur pour exécuter un script local sur une instance Microsoft Windows, vous ne pouvez pas utiliser la fonctionnalité d'exécution en tant qu'utilisateur de récupération après sinistre de la pile complète qui vous permet de spécifier un autre ID utilisateur afin d'exécuter les scripts locaux résidant sur les instances.

Solution de contournement : sur les instances Microsoft Windows, le script peut uniquement être exécuté en tant qu'ID utilisateur ocarun par défaut employé par l'utilitaire Commande d'exécution de l'agent Oracle Cloud. Cette limitation n'affecte pas les instances Oracle Linux.

Les étapes définies par l'utilisateur sur les instances Microsoft Windows ne peuvent pas utiliser de scripts inaccessibles pour l'ID utilisateur "ocarun"

Détails : Full Stack DR utilise l'utilitaire Commande d'exécution de l'agent Oracle Cloud pour exécuter des scripts locaux sur les instances. Par défaut, ces scripts sont exécutés en tant qu'utilisateur ocarun.

Solution de contournement : sur une instance Microsoft Windows, tout script local que vous configurez pour être exécuté en tant qu'étape définie par l'utilisateur dans un plan de récupération après sinistre doit être accessible et exécutable par l'ID utilisateur ocarun.

La non-spécification des chemins complets pour un script local exécuté à l'aide d'une étape définie par l'utilisateur entraîne des erreurs

Détails : lors de l'exécution d'un script local à l'aide d'une étape définie par l'utilisateur dans un plan de récupération après sinistre, si vous ne fournissez pas de chemins d'accès complets aux scripts ou aux interpréteurs de script, Full Stack DR génère des erreurs.

Solution de contournement : lorsque vous configurez une étape définie par l'utilisateur dans un plan de récupération après sinistre pour exécuter un script local résidant sur une instance, veillez à fournir le chemin d'accès complet à tout interpréteur pouvant précéder le nom du script, ainsi que le chemin d'accès complet au script.

Indiquez /bin/sh /path/to/myscript.sh arg1 arg2 au lieu de sh myscript.sh arg1 arg2.
Les noeuds de cluster OCFS2 se déconnecteront du cluster si leurs adresses IP privées ne peuvent pas être réaffectées dans la région de secours

Détails : au cours des opérations de DR, Full Stack DR tente de réaffecter l'adresse IP privée d'origine affectée à une instance si le bloc CIDR du sous-réseau de destination correspond au bloc CIDR du sous-réseau source, et si l'adresse IP privée d'origine de l'instance n'est pas déjà affectée.

Si vous utilisez la récupération après sinistre de pile complète pour transférer tous les noeuds d'un cluster OCFS2 et que l'adresse IP privée de l'un des noeuds de cluster ne peut pas être réaffectée, ces noeuds se détachent du cluster OCFS2 après leur lancement dans la région de secours.

Solution de contournement : assurez-vous que le bloc CIDR du sous-réseau de destination correspond au bloc CIDR du sous-réseau source et que toutes les adresses IP privées requises pour les noeuds de cluster sont disponibles dans le sous-réseau de destination.

Après les opérations de récupération après sinistre, les instances de calcul peuvent afficher des informations incorrectes pour l'accès à l'instance

Détails : après le transfert d'une instance Full Stack DR vers une autre région, la page de ressource de l'instance peut afficher le message suivant pour Accès à l'instance :

Nous ne savons pas comment vous connecter à une instance qui utilise cette image

Solution de contournement : ignorez ce message. Les connexions SSH à l'instance fonctionnent normalement si vous utilisez le fichier de clés SSH d'origine pour vous connecter à l'instance et l'authentifier.

Après les opérations de récupération après sinistre, les volumes d'initialisation d'une instance peuvent ne pas afficher les informations d'image correctes

Détails : après le transfert d'une instance Full Stack DR vers une autre région, la page de ressource de l'instance peut afficher des informations incorrectes pour la partie Image de son volume d'initialisation.

Par exemple, la colonne Informations sur l'image peut afficher le message suivant : Erreur lors du chargement des données.

Solution de contournement : ce message d'erreur concerne l'affichage du nom de l'image mais n'affecte pas le fonctionnement de l'instance et de son volume d'initialisation.

La commande d'exécution des travaux en arrière-plan échoue à l'étape définie par l'utilisateur

Détails : en l'absence de temps de veille pour la commande nohup, l'exécution de la commande run échoue et le signalement du statut échoue.

Solution : pour démarrer un processus en arrière-plan, ajoutez sleep dans le script wrapper, comme indiqué ici :
nohup sh enabler.sh  &> enabler.log &
sleep 10
exit 0
Les paramètres de performances des volumes de blocs ne sont pas répliqués et restaurés automatiquement

Détails : lors d'une transition de récupération après sinistre, lorsque les volumes de blocs sont déplacés vers une autre région, les paramètres de performances (IOPS et débit) ne sont pas répliqués et restaurés automatiquement. Vous devrez peut-être reconfigurer ces paramètres de performances.

Solution : après l'exécution d'un plan de récupération après sinistre, configurez le paramètre de performances manuellement.

Globally Distributed Autonomous Database

Pour consulter les problèmes connus relatifs à Globally Distributed Autonomous Database, reportez-vous à Problèmes connus.

Intégration

Pour consulter les problèmes connus relatifs à Integration Generation 2, reportez-vous à Problèmes connus.

Pour consulter les problèmes connus liés à Integration 3, reportez-vous à Problèmes connus.

Java Management

Pour plus d'informations sur les problèmes connus dans le service Java Management, reportez-vous à Problèmes connus.

Language

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

Load Balancer

Pour consulter les problèmes connus relatifs au service Load Balancer, reportez-vous à Problèmes connus.

Logging Analytics

Téléchargement à la demande à partir d'une machine Windows à l'aide d'un fichier ZIP

Détails : le téléchargement à la demande d'un fichier ZIP créé sur une machine Windows peut parfois ne pas parvenir à télécharger le contenu du journal. L'échec s'explique par le fait que le fichier ZIP créé sous Windows a la même heure de dernière modification que l'heure de création du fichier. Par conséquent, lorsque le fichier est décompressé, l'heure de dernière modification est définie comme heure de création du fichier. Or, celle-ci peut être antérieure à l'horodatage des entrées de journal dans le fichier journal. Dans ce cas, les entrées de journal dont l'horodatage est plus récent que l'heure de dernière modification du fichier ne sont pas téléchargées.

Exemple du problème :

Horodatage de l'entrée de journal : 2020-10-12 21:12:06

Heure de dernière modification du fichier journal : 2020-10-10 08:00:00

Solution de contournement : copiez les fichiers journaux dans un nouveau dossier et créez un fichier ZIP. Cette action permet d'avoir une heure de dernière modification du fichier plus récente que l'horodatage des entrées de journal. Utilisez ce nouveau fichier ZIP pour le téléchargement à la demande.

Valeurs observées après l'implémentation de la solution de contournement d'après l'exemple précédent :

Horodatage de l'entrée de journal : 2020-10-12 21:12:06

Heure de dernière modification du fichier journal : 2021-03-31 08:00:00

Lien direct vers ce problème : Téléchargement à la demande à partir d'une machine Windows à l'aide d'un fichier ZIP

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 une utilisation élevée des ressources (mémoire / stockage / CPU) par l'agent de gestion, ce qui peut ralentir la collecte des journaux, affecter d'autres fonctionnalités de l'agent de gestion et ralentir la machine hôte.

Lorsque des dossiers volumineux sont détectés par le module d'extension Management Agent de Logging Analytics, un message semblable à l'exemple suivant est ajouté au fichier mgmt_agent_logan.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. Utilisez un mécanisme de nettoyage pour enlever les fichiers peu de temps après leur collecte afin que l'agent de gestion dispose de suffisamment de temps pour les collecter à nouveau.

Toutefois, si vous souhaitez continuer à surveiller les journaux dans des dossiers volumineux, vous pouvez activer le support 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 et redémarrez l'agent.

Vous devrez peut-être apporter des modifications à la configuration de l'agent hôte pour activer cette prise en charge. Essayez les nouveaux paramètres dans un environnement de développement ou de test avant de les mettre en production. Déterminez l'augmentation pour les facteurs suivants en utilisant un environnement représentatif pour les tester. L'augmentation requise réelle dépendra de facteurs tels que le nombre de fichiers, le taux de création de fichiers et les autres types de collecte effectués par l'agent de gestion.
  • Augmentez la taille de la portion de mémoire de l'agent de gestion. Pour les répertoires contenant un grand nombre de fichiers, la taille de portion de mémoire requise augmente avec le nombre de fichiers. Reportez-vous à la documentation Management Agent.
  • Assurez-vous que l'espace disque et les inodes sont suffisants pour gérer le grand nombre de fichiers d'état que l'agent de gestion peut avoir à conserver. Cela dépend du type de source de journal et d'analyseur utilisé. Si votre analyseur utilise la fonction Header-Detail, l'agent crée et stocke l'en-tête dans un fichier cache tant que le fichier journal d'origine existe.
  • Assurez-vous que le paramètre du système d'exploitation pour le nombre de fichiers ouverts peut prendre en charge l'agent de gestion qui lit le dossier volumineux et potentiellement un grand nombre de fichiers d'état.

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

Managed Access

Pour consulter les problèmes connus relatifs à Managed Access, reportez-vous à Problèmes connus.

Managed Cloud Self Service Platform

Pour consulter les problèmes connus relatifs à Managed Cloud Self Service Platform, reportez-vous à Problèmes connus.

Management Agent

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

Marketplace

Pour consulter les problèmes connus relatifs à Marketplace, reportez-vous à Problèmes connus.

Media Services

Pour consulter les problèmes connus relatifs à Media Flow, reportez-vous à Problèmes connus.

Pour consulter les problèmes connus relatifs à Media Streams, reportez-vous à Problèmes connus.

Network Load Balancer

Pour consulter les problèmes connus relatifs à Network Load Balancer, reportez-vous à Problèmes connus.

Object Storage

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

Centre de contrôle OCI

Pour consulter les problèmes connus relatifs à OCI Control Center, reportez-vous à Problèmes connus.

Ops Insights

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

Oracle Cloud Marketplace

Pour consulter les problèmes connus relatifs à Oracle Cloud Marketplace, reportez-vous à Problèmes connus.

OS Management Hub

Pour plus d'informations sur les problèmes connus avec OS Management Hub, reportez-vous à Problèmes connus.

Portail Partenaires

Pour consulter les problèmes connus relatifs au portail Partenaires, reportez-vous à Problèmes connus.

Process Automation

Pour plus d'informations sur les problèmes connus dans le service Process Automation, reportez-vous à Problèmes connus.

Éditeur

Pour consulter les problèmes connus relatifs à Marketplace, reportez-vous à Problèmes connus.

Queue

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

Roving Edge Infrastructure

Actuellement, il n'existe aucun problème connu lié à Roving Edge Infrastructure.

Bureaux sécurisés

Pour consulter les problèmes connus relatifs aux bureaux sécurisés, reportez-vous à Problèmes connus.

Search with OpenSearch

Pour consulter les problèmes connus relatifs à Search with OpenSearch, reportez-vous à Problèmes connus.

Security Zones

Pour consulter les problèmes connus relatifs à Security Zones, reportez-vous à Problèmes connus.

Service Mesh

Pour consulter les problèmes connus relatifs à Service Mesh, reportez-vous à Problèmes connus.

Catalogue de services

Pour consulter les problèmes connus relatifs aux catalogues de services, reportez-vous à Problèmes connus.

Speech

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

Gestion de locations

Pour consulter les problèmes connus relatifs à Tenancy Management, reportez-vous à Problèmes connus.

Threat Intelligence

Pour consulter les problèmes connus relatifs à Threat Intelligence, reportez-vous à Problèmes connus.

Traffic Management Steering Policies

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

Vault

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

Vision

Pour consulter les problèmes connus relatifs à Vision, reportez-vous à Problèmes connus.

Web Application Acceleration

Pour consulter les problèmes connus relatifs à Web Application Acceleration, reportez-vous à Problèmes connus.