Problèmes connus

Détails : Dans le cadre de la surveillance synthétique, les moniteurs de navigateur et de navigateur avec script pourraient ne pas fonctionner avec les applications qui utilisent des cadres.

Solution de rechange : Nous sommes conscients du problème et travaillons à le résoudre. Pour les moniteurs de navigateur avec script, 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 initiale :

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

La version modifiée du script est la suivante :

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

Lien direct vers ce problème :Les moniteurs de navigateur et de navigateur avec script peuvent ne pas exécuter les applications qui utilisent des cadres

Détails : Les politiques d'autorisation basées sur les marqueurs de ressource apm-domains ne fonctionnent pas pour l'explorateur de trace et les API de surveillance synthétique, provoquant des échecs d'autorisation.

Solution de rechange : Nous sommes conscients du problème et travaillons à le résoudre.

Lien direct vers ce problème : Problèmes liés aux politiques d'autorisation basées sur les marqueurs de ressource apm-domains

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

Solution de rechange : Créez un nouveau profil d'utilisateur Firefox comme suit :

1. Vérifiez que vous disposez de la dernière version de Firefox. Sinon, effectuez la mise à jour.
2. Créez un nouveau profil d'utilisateur et supprimez l'ancien. Suivez les instructions de l'aide Mozilla pour créer et supprimer des profils d'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 bogue du navigateur Firefox peut empêcher le chargement de la console

Détails : Les bases de données enfichables existantes n'apparaissent pas dans une nouvelle base de données et il peut falloir plusieurs heures avant qu'elles apparaissent dans la console. Cela concerne la base de données enfichable par défaut pour une nouvelle base de données et les bases de données enfichables existantes pour les bases clonées ou restaurées. En cas de restauration sur place d'une version plus ancienne, la liste de bases de données enfichables est mise à jour de la même manière et cela peut prendre un certain temps.

Solution de rechange : Aucune

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

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

Solution de rechange : Vous pouvez utiliser sqlplus pour créer ou cloner des bases pluggables dans la base principale et elles seront synchronisées plus tard dans la console OCI.

Lien direct vers ce problème : PDB dans une configuration de Data Guard existante

Détails : Échec de l'utilisation de l'API du service de base de données pour migrer un portefeuille TDE basé sur des fichiers vers un portefeuille TDE basé sur des clés gérées par le client dans Oracle Database 12c version 1 (12.1.0.2) avec l'erreur suivante :

[FATAL] [DBAAS-1101014] - Les correctifs requis (30128047) ne sont pas présents dans le répertoire de base Oracle <ORACLE_HOME>
ACTION : Appliquez les correctifs requis (30128047) et réessayez l'opération

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.

Détails : Échec de l'utilisation de l'API du service de base de données pour migrer un portefeuille TDE basé sur des clés gérées par le client vers un portefeuille TDE basé sur des fichiers dans Oracle Database 12c version 1 (12.1.0.2) avec l'erreur suivante :

[FATAL] [DBAAS-1101014] - Les correctifs requis (30128047) ne sont pas présents dans le répertoire de base Oracle <ORACLE_HOME>
ACTION : Appliquez les correctifs requis (30128047) et réessayez l'opération

nohup /var/opt/oracle/dbaascli/dbaascli tde hsm_to_file --dbname <database_name> --skip_patch_check true &

Détails : Échec de l'utilisation de l'API du service de base de données pour migrer un portefeuille TDE basé sur des fichiers vers un portefeuille TDE basé sur des clés gérées par le client dans Oracle Database 12c version 2 (12.2.0.1) avec l'erreur suivante :

[FATAL] [DBAAS-1101014] - Les correctifs requis (30128047) ne sont pas présents dans le répertoire de base Oracle <ORACLE_HOME>
ACTION : Appliquez les correctifs requis (30128047) et réessayez l'opération

Solution de rechange : Migrez un portefeuille TDE basé sur des fichiers vers un portefeuille TDE basé sur des clés gérées par le client, comme suit :

1. Déterminez si la base de données a chiffré les espaces-tables UNDO ou TEMP dans l'une des bases de données autonomes ou dans CDB$ROOT, comme suit :
   Exécutez l'interrogation suivante à partir de CDB$ROOT pour lister tous les espaces-tables chiffrés qui existent 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 l'interrogation, recherchez les noms des espaces-table UNDO et TEMP. S'il existe des espaces-tables UNDO ou TEMP chiffrés, passez à l'étape suivante.

2. Déchiffrez les espaces-tables UNDO ou TEMP comme suit :

   Si un espace-table UNDO est chiffré

   Déchiffrez les espaces-tables UNDO existants comme suit :

   SQL> alter tablespace <undo_tablespace_name> encryption online decrypt;

   Répétez cette procédure pour tous les espaces-tables UNDO chiffrés.

   Si un espace-table TEMP est chiffré

   1. Vérifiez l'espace-table TEMP par défaut, comme suit :

      SQL> select property_value from database_properties where property_name = 'DEFAULT_TEMP_TABLESPACE';

      Si l'espace-table TEMP par défaut n'est pas chiffré, mais que d'autres espaces-tables TEMP le sont, supprimez ces derniers, comme suit :

      SQL> drop tablespace <temp_tablespace_name>;

      Ignorez les autres étapes de cette procédure.

      Si l'espace-table TEMP par défaut est chiffré, passez aux étapes suivantes pour créer et définir un espace-table TEMP par défaut non chiffré.

   2. Réglez le paramètre encrypt_new_tablespaces à DDL, comme suit :

      SQL> alter system set "encrypt_new_tablespaces" = DDL scope = memory;

   3. Créez un espace-table TEMP avec les spécifications de l'espace-table TEMP courant, comme suit :

      SQL> create temporary tablespace <temp_tablespace_name> TEMPFILE size 5000M;

   4. Définissez le nouvel espace-table TEMP comme espace-table TEMP par défaut pour la base de données, comme suit :

      SQL> alter database default temporary tablespace <temp_tablespace_name>;

   5. Supprimez les espaces-tables TEMP existants, comme suit :

      SQL> drop tablespace <temp_tablespace_name>;

   Répétez cette procédure pour tous les espaces-tables TEMP chiffrés.

   La base de données est maintenant exécutée avec les espaces-tables UNDO et TEMP par défaut qui ne sont pas chiffrés et les espaces-tables TEMP et UNDO plus anciens sont également déchiffrés.

   Réglez encrypt_new_tablespaces à sa valeur initiale, comme suit :

   SQL> alter system set "encrypt_new_tablespaces" = cloud_only;

   Effectuez la migration du magasin de clés vers des clés gérées par le client.

3. Après avoir vérifié qu'aucun espace-table UNDO ou TEMP n'est chiffré dans aucune des bases de données enfichables ni dans CDB$ROOT, utilisez l'utilitaire DBAASCLI avec l'indicateur --skip_patch_check true pour ignorer la validation du correctif pour le bogue 30128047. Vérifiez que vous avez appliqué le correctif pour le bogue 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.

Détails : Échec de l'utilisation de l'API du service de base de données pour migrer un portefeuille TDE basé sur des clés gérées par le client vers un portefeuille TDE basé sur des fichiers dans Oracle Database 12c version 2 (12.2.0.1) avec l'erreur suivante :

[FATAL] [DBAAS-1101014] - Les correctifs requis (30128047) ne sont pas présents dans le répertoire de base Oracle <ORACLE_HOME>
ACTION : Appliquez les correctifs requis (30128047) et réessayez l'opération

Solution de rechange : Migrez un portefeuille TDE basé sur des clés gérées par le client vers un portefeuille TDE basé sur des fichiers, comme suit :

1. Déterminez si la base de données a chiffré les espaces-tables UNDO ou TEMP dans l'une des bases de données autonomes ou dans CDB$ROOT, comme suit :
   Exécutez l'interrogation suivante à partir de CDB$ROOT pour lister tous les espaces-tables chiffrés qui existent 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 l'interrogation, recherchez les noms des espaces-table UNDO et TEMP. S'il existe des espaces-tables UNDO ou TEMP chiffrés, passez à l'étape suivante.

2. Déchiffrez les espaces-tables UNDO ou TEMP comme suit :

   Si un espace-table UNDO est chiffré

   Déchiffrez les espaces-tables UNDO existants comme suit :

   SQL> alter tablespace <undo_tablespace_name> encryption online decrypt;

   Répétez cette procédure pour tous les espaces-tables UNDO chiffrés.

   Si un espace-table TEMP est chiffré

   1. Vérifiez l'espace-table TEMP par défaut, comme suit :

      SQL> select property_value from database_properties where property_name = 'DEFAULT_TEMP_TABLESPACE';

      Si l'espace-table TEMP par défaut n'est pas chiffré, mais que d'autres espaces-tables TEMP le sont, supprimez ces derniers, comme suit :

      SQL> drop tablespace <temp_tablespace_name>;

      Ignorez les autres étapes de cette procédure.

      Si l'espace-table TEMP par défaut est chiffré, passez aux étapes suivantes pour créer et définir un espace-table TEMP par défaut non chiffré.

   2. Réglez le paramètre encrypt_new_tablespaces à DDL, comme suit :

      SQL> alter system set "encrypt_new_tablespaces" = DDL scope = memory;

   3. Créez un espace-table TEMP avec les spécifications de l'espace-table TEMP courant, comme suit :

      SQL> create temporary tablespace <temp_tablespace_name> TEMPFILE size 5000M;

   4. Définissez le nouvel espace-table TEMP comme espace-table TEMP par défaut pour la base de données, comme suit :

      SQL> alter database default temporary tablespace <temp_tablespace_name>;

   5. Supprimez les espaces-tables TEMP existants, comme suit :

      SQL> drop tablespace <temp_tablespace_name>;

   Répétez cette procédure pour tous les espaces-tables TEMP chiffrés.

   La base de données est maintenant exécutée avec les espaces-tables UNDO et TEMP par défaut qui ne sont pas chiffrés et les espaces-tables TEMP et UNDO plus anciens sont également déchiffrés.

   Réglez encrypt_new_tablespaces à sa valeur initiale, comme suit :

   SQL> alter system set "encrypt_new_tablespaces" = cloud_only;

   Effectuez la migration du magasin de clés vers des clés gérées par le client.

3. Après avoir vérifié qu'aucun espace-table UNDO ou TEMP n'est chiffré dans aucune des bases de données enfichables ni dans CDB$ROOT, utilisez l'utilitaire DBAASCLI avec l'indicateur --skip_patch_check true pour ignorer la validation du correctif pour le bogue 30128047. Vérifiez que vous avez appliqué le correctif pour le bogue 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.

Détails : Lorsque vous remplacez le type de licence de votre base de données ou de votre système de base de données BYOL par une licence incluse, ou l'inverse, les deux types de licence sont facturés pour la première heure. Vous êtes ensuite facturé en fonction du nouveau type de licence.

Solution de rechange : Nous travaillons à une résolution.

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

Détails : Si vous configurez le VCN avec une passerelle de service, le sous-réseau privé bloque l'accès aux référentiels YUM nécessaires pour mettre à jour le système d'exploitation. Ce problème affecte tous les types de système de base de données.

Solution de rechange : Ce problème est désormais résolu. Voici la solution de rechange qui était recommandée avant que le problème ne soit réglé :

La passerelle de service permet d'accéder aux référentiels Oracle YUM si vous utilisez l'aperçu des passerelles de service appelé Tous les services de <region> dans Oracle Services Network. Toutefois, l'accès aux services YUM au moyen de la passerelle de service risque de rester problématique. Il existe une solution à ce problème. Pour plus de détails, voir Problèmes d'accès des instances aux services Oracle yum au moyen de la passerelle de service.

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

Détails : Les sauvegardes non gérées dans le service Stockage d'objets à l'aide de dbcli (interface de ligne de commande de base de données) ou de RMAN ont échoué 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 politiques mises en oeuvre 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 des certificats SSL qui en résulte peut entraîner l'échec des sauvegardes dans le service de stockage d'objets si le module Oracle Database Cloud Backup pointe toujours vers l'ancien certificat.

Solution de rechange pour dbcli : Vérifiez si les fichiers journaux contiennent les erreurs répertoriées et, si nécessaire, mettez à jour le module de sauvegarde.

Recherchez les erreurs répertoriées ci-dessus dans les fichiers journaux de sauvegarde RMAN:

1. Déterminez l'ID de la tâche de sauvegarde ayant échoué.

   dbcli list-jobs

   Dans cet exemple de sortie, l'ID tâche de la 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 de la tâche ayant échoué pour obtenir l'emplacement du fichier journal à vérifier.

   
   dbcli describe-job -i <failed_job_ID>
                               

   La commande describe-job devrait générer une sortie semblable à ce qui suit:

   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.

Mettre à jour le module Oracle Database Cloud Backup:

1. Déterminez l'ID magasin d'objets Swift et l'utilisateur dont la base de données se sert pour les sauvegardes.

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

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

      dbcli list-databases
      dbcli describe-database -i <database_ID> -j

   3. À l'aide de l'ID configuration de sauvegarde que vous avez noté à l'étape précédente, déterminez l'ID magasin d'objets (objectStoreId).

      dbcli list-backupconfigs
      dbcli describe-backupconfig –i <backupconfig_ID> -j

   4. À l'aide de l'ID magasin d'objets que vous avez noté à l'étape précédente, déterminez l'utilisateur du magasin d'objets (userName).

      dbcli list-objectstoreswifts
      dbcli describe-objectstoreswift –i <objectstore_ID> -j

2. À l'aide des données d'identification de magasin d'objets obtenues à l'étape1, mettez à jour le module de sauvegarde.

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

Solution de rechange pour RMAN : Vérifiez si les fichiers journaux RMAN contiennent les messages d'erreur répertoriés. Si tel est le cas, connectez-vous à l'hôte en tant qu'utilisateur oracle et servez-vous de vos données d'identification Swift pour réinstaller le module de sauvegarde.

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 rechange sur tous les noeuds de la grappe.

Consultez la documentation du module de sauvegarde d'Oracle Database Cloud pour plus d'informations sur l'utilisation de cette commande.

Lien direct vers ce problème : Échec de la sauvegarde dans le service de stockage d'objets à l'aide de dbcli ou de RMAN en raison de la modification des certificats

Détails : Les trousses SDK lancées le 18 octobre 2018 apportent des changements cassants à la taille et aux attributs d'édition de base de données dans les API de sauvegarde correspondantes.

Solution de rechange : Consultez la documentation ci-après selon le langage concerné pour plus d'informations sur les changements cassants et mettez à jour le code existant selon les besoins :

Lien direct vers ce problème : Changements cassants dans les trousses SDK de service de base de données

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

Solution de rechange : Installez le module Oracle Database Cloud Backup, puis communiquez avec le soutien technique d'Oracle pour obtenir des instructions supplémentaires.

Pour installer le module de sauvegarde d'Oracle Database Cloud:

1. Accédez par SSH au système de base de données et connectez-vous en tant qu'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 depuis 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 les privilèges requis pour accéder au stockage d'objets de la location.
5. Pour cet utilisateur temporaire, créez un jeton d'authentification et notez le mot de passe.

6. Vérifiez que les données d'identification fonctionnent en exécutant la commande curl suivante:

   Note
   
   Les mots de passe Swift sont maintenant appelés "jetons d'authentification". Pour plus d'informations, voir 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 savoir la région à utiliser.

   La commande doit retourner le code de réponse de succès HTTP 200 ou HTTP 204 Pas de 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

   Notez que <target_dir> est le répertoire où vous avez extrait opc_installer.zip à l'étape3.

   Cette commande peut prendre quelques minutes car elle télécharge libopc.so et d'autres fichiers. Une fois la commande terminée, vous devriez voir plusieurs fichiers (dont libopc.so) dans votre répertoire cible.

8. Passez dans le 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 aurez peut-être à utiliser sudo avec les commandes de copie pour les exécuter en tant que racine.)

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 de ce 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 de 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 retourner 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.

Après avoir terminé la procédure, communiquez avec le soutien technique Oracle ou avec l'administrateur du locataire pour obtenir des instructions supplémentaires. Vous devez fournir l'OCID du système de base de données pour lequel vous souhaitez 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

Détails : Les limites de mémoire des machines hôte exécutant la forme VM.Standard1.1 peuvent causer des échecs pour les tâches de sauvegarde automatique de base de données gérées par Oracle Cloud Infrastructure (tâches gérées à 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 rechange : Modifiez les paramètres de mémoire des systèmes de la manière suivante :

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

   [opc@hostname ~]$ sudo su - oracle

2. Réglez la variable d'environnement pour vous connecter à 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 initiaux de mémoire de la manière suivante:

   
   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 : Échec des sauvegardes automatiques gérées sur la forme VM.Standard1.1 en raison d'une panne de processus

Détails : Dans les systèmes de base de données High Performance et Extreme Performance, les opérations de l'utilitaire d'extraction de données employant la compression et/ou le parallélisme peuvent échouer et retourner l'erreur ORA-00439 : Fonctionnalité non activée. Ce problème affecte les versions de base de données 12.1.0.2.161018 et 12.1.0.2.170117.

Solution de rechange : Appliquez le correctif 25579568 ou 25891266 aux répertoires de base Oracle Database pour les versions 12.1.0.2.161018 ou 12.1.0.2.170117, respectivement. Sinon, utilisez la console pour appliquer le correctif d'avril 2017 au système de base de données et au répertoire de base.

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

Détails : Vous obtiendrez peut-être un message d'erreur "Échec de la connexion sécurisée" lorsque vous tentez de vous connecter à la console EM Express à partir de votre système de base de données à un noeud car les autorisations correctes n'ont pas été appliquées automatiquement.

Solution de rechange : Ajoutez des autorisations en lecture pour le groupe asmadmin dans le répertoire du portefeuille du système de base de données, puis réessayez la connexion :

1. Accédez par SSH à l'hôte du système de base de données, connectez-vous en tant qu'opc, sudo pour l'utilisateur de grille.

   [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 dans la sortie de la 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. Retournez à l'utilisateur opc, passez à l'utilisateur oracle, puis au répertoire du portefeuille.

   [opc@dbsysHost ~]$ sudo su - oracle
   [oracle@dbsysHost ~]$ cd /u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet

4. Affichez le contenu du répertoire et prenez note des autorisations.

   
   [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 autorisations:

   
   [oracle@dbsysHost xdb_wallet]$ chmod 640 /u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet/*

6. Vérifiez que des autorisations de lecture ont été ajoutées.

   [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 : Connexion impossible à la console EM Express à partir de votre système de base de données à un noeud

Détails : Les opérations de sauvegarde dans le service Stockage d'objets à l'aide de l'utilitaire de sauvegarde d'Exadata (bkup_api) ou de RMAN ont échoué et les erreurs suivantes sont survenues :

* 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 politiques mises en oeuvre 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 des certificats SSL qui en résulte peut entraîner l'échec des sauvegardes dans le service de stockage d'objets si le module Oracle Database Cloud Backup pointe toujours vers l'ancien certificat.

Solution de rechange pour bkup_api : Vérifiez si les fichiers journaux contiennent les erreurs répertoriées ci-dessus et, si nécessaire, réinstallez le module de sauvegarde.

Utilisez 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 rechange pour RMAN : Vérifiez si les fichiers journaux RMAN contiennent les messages d'erreur répertoriés. Si tel est le cas, connectez-vous à l'hôte en tant qu'utilisateur oracle et servez-vous de vos données d'identification Swift pour réinstaller le module de sauvegarde.

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 rechange sur tous les noeuds de la grappe.

Consultez la documentation du module de sauvegarde d'Oracle Database Cloud pour plus d'informations sur l'utilisation de cette commande.

Lien direct vers ce problème : échec de la sauvegarde dans le service de stockage d'objets à l'aide de bkup_api ou de RMAN en raison de la modification des certificats

Détails : Suite à la mise en disponibilité de la fonction Répertoire de base de base de données partagé pour les systèmes de base de données Exadata, la console synchronise et affiche maintenant les informations sur les bases de données créées et gérées à l'aide des utilitaires dbaasapi et dbaascli. Cependant, les bases de données où Data Guard est configuré n'affichent pas des informations correctes dans la console :

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

Solution de rechange : Nous sommes conscients du problème et travaillons à le résoudre. Dans l'intervalle, Oracle recommande de gérer les bases de données où Data Guard est activé en utilisant uniquement la console ou les utilitaires de ligne de commande.

Lien direct vers ce problème : Les informations de la console ne sont pas synchronisées pour les bases de données où Data Guard est activé lors de l'utilisation de dbaascli

Détails : Il s'agit d'un problème de gestion de grappe qui se produit uniquement avec la version 12.2.0.1 d'Oracle GI sans aucun correctif d'ensemble. Le problème est dû à un disque votant corrompu après sa mise hors ligne puis en ligne.

Solution de rechange : Déterminez la version de GI et vérifiez si le disque votant est corrompu. Au besoin, réparez le disque, puis appliquez le dernier ensemble GI.

1. Vérifiez que la version de GI est 12.2.0.1 sans aucun correctif d'ensemble:

   
   [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. Recherchez dans le fichier /u01/app/grid/diag/crs/<hostname>/crs/trace/ocssd.trc des éléments prouvant que le démarrage de GI a échoué en raison d'un disque votant corrompu :

   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 vérifier si les disques votants sont corrompus:

   1. Connectez-vous en tant qu'utilisateur de grille et réglez l'environnement à 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 que SYSASM.

      $ORACLE_HOME/bin/sqlplus / as sysasm

   3. Exécutez les deux interrogations 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 sain, les résultats devraient ressembler à l'exemple suivant.

      Résultats de l'interrogation 1

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

      Résultats de l'interrogation 2

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

      Dans un système sain, chaque disque votant retourné dans la première interrogation doit également figurer dans la deuxième et le total des disques doit être différent de zéro. Sinon, au moins un des disques votants est corrompu.

4. Si un disque votant est corrompu, mettez hors ligne le disque de grille qui le contient. Les cellules vont automatiquement déplacer le disque votant incorrect vers l'autre disque de grille et mettre en ligne ce disque votant.

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

      SQL> alter diskgroup DATAC01 offline disk DATAC01_CD_05_SCAQAE08CELADM13;
           Diskgroup altered.

   2. Attendez 30secondes, puis réexécutez les deux interrogations de l'étape3c pour vérifier que le disque votant a été migré vers le nouveau disque de grille et qu'il est sain.

   3. Vérifiez que le disque de grille précédemment mis hors ligne est maintenant en ligne:

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

      mode_status doit indiquer ONLINE et voting_file NE DOIT PAS être réglé à Y.

   Répétez les étapes 4a à 4c pour chaque disque de grille restant qui contient un disque votant corrompu.

   Note
   
   

   Si CRS ne démarre pas en raison du disque votant corrompu, utilisez le mode exclusif avant d'exécuter la commande de l'étape4.

   crsctl start crs -excl

5. Si vous utilisez Oracle GI version12.2.0.1 sans correctif d'ensemble, vous devez mettre à niveau à la dernière version de l'ensemble GI, qu'un disque votant soit corrompu ou non.

   Voir Application de correctifs à Oracle Grid Infrastructure et aux bases de données Oracle à l'aide de dbaascli pour obtenir des instructions sur l'utilisation de l'utilitaire dbaascli pour effectuer des opérations d'application de correctifs pour Oracle Grid Infrastructure et Oracle Database sur le service Exadata Database sur une infrastructure dédiée.

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

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 l'interface de ligne de commande d'Oracle Cloud Infrastructure. Toutefois, les systèmes provisionnés avant cette date requièrent des étapes supplémentaires pour activer cette fonctionnalité.

Les tentatives d'utilisation de cette fonctionnalité sans les étapes supplémentaires entraînent la génération des messages d'erreur suivants:

• Lors de la création d'une base de données - "Create Database is not supported on this Exadata DB system. To enable this feature, please contact Oracle Support."
• Lors de l'arrêt d'une base de données - "DeleteDbHome is not supported on this Exadata DB system. To enable this feature, please contact Oracle Support."

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

Créez d'abord une demande de service pour obtenir de l'aide du service Oracle Support. Oracle Support vous fournira une URL préauthentifiée pour un emplacement Oracle Cloud Infrastructure Object Storage où vous pourrez obtenir l'agent.

Avant d'installer l'agent Exadata:

• Mettez à niveau les outils (dbaastools rpm) à la dernière version sur tous les noeuds du système de base de données Exadata. Voir Mise à jour des outils sur une instance du service Exadata Cloud.
• Assurez-vous que le système est configuré pour 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é au service de stockage d'objets pour Oracle Cloud Infrastructure Object Storage, voir Préalables pour les sauvegardes sur Exadata Cloud Service.

Pour installer l'agent Exadata:

1. Connectez-vous au noeud en tant que racine.

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 étapes1 à3 sur les noeuds restants.

Une fois l'agent installé sur tous les noeuds, laissez jusqu'à 30minutes à Oracle pour effectuer des tâches supplémentaires de flux de travail, telles que la mise à niveau de l'agent vers la dernière version, la rotation des données d'identification de l'agent, etc. Une fois le processus terminé, vous pourrez utiliser les fonctions gérées d'Exadata dans la console, l'API ou l'interface de ligne de commande d'Oracle Cloud Infrastructure.

Lien direct vers ce problème : Les fonctions gérées ne sont pas activées pour les systèmes provisionnés avant le 15 juin 2018

Détails : Le fichier de configuration de l'application de correctifs (/var/opt/oracle/exapatch/exadbcpatch.cfg) pointe sur le magasin 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 la version du paquetage d'outils de base de données (dbaastools_exa) est17430 ou une valeur inférieure.

Solution de rechange : Suivez les instructions sous Mise à jour des outils sur une instance Exadata Cloud Service pour confirmer que la version de l'ensemble d'outils est 17430 ou inférieure, puis mettez-la à jour à la dernière version.

Lien direct vers ce problème : Le fichier de configuration de correctif pointe sur une région incorrecte

Détails : Une modification apportée à la façon dont Oracle Linux 7 gère les fichiers temporaires peut entraîner la suppression des fichiers 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 la version19.1.2 de l'image du système d'exploitation.

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

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

Détails : Si vous utilisez des sauvegardes de groupe de volumes lors de l'exécution d'opérations de reprise après sinistre pour le calcul et le stockage entre différents domaines de disponibilité au sein d'une même région, les allers-retours et les transitions de reprise après sinistre feront en sorte que le calcul et le stockage par blocs associé (qui utilise des sauvegardes de groupe de volumes) se retrouvent à chaque fois dans un domaine de disponibilité différent.

Solution de rechange : Ce problème n'a pas d'incidence sur le stockage par blocs qui est reproduit à l'aide de la réplication de groupe de volumes.

Informations détaillées : Les paramètres de réglage automatique de la performance pour les volumes de stockage par blocs ne sont pas conservés lors des opérations de DR

Solution de rechange : Pour les volumes de stockage par blocs pour lesquels le réglage automatique de la performance est activé, vous devez réactiver ces paramètres après le transfert de ces volumes de stockage par blocs vers une autre région par la récupération après sinistre de pile complète.

Détails : Si vous effectuez une opération de basculement immédiatement après la modification d'une ressource protégée par RS de pile complète, la récupération de la ressource peut échouer ou la ressource ne peut 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 RS et que la région principale subit une panne immédiatement après, la récupération après sinistre de la pile complète peut ne pas détecter les modifications que vous avez apportées aux paramètres de réplication du groupe de volumes, ce qui aura une incidence sur la récupération de ce dernier.

Solution de rechange : Effectuez une vérification préalable de la permutation immédiatement après avoir apporté des modifications aux ressources bénéficiant de la protection RS.

Détails : La récupération après sinistre de pile complète utilise l'utilitaire Exécuter la commande d'Oracle Cloud Agent (OCA) pour exécuter des scripts locaux dans les instances. Lorsque vous configurez une étape définie par l'utilisateur pour exécuter un script local dans une instance Microsoft Windows, vous ne pouvez pas utiliser la fonction DR de pile complète Exécuter en tant qu'utilisateur qui permet de spécifier un ID utilisateur différent pour exécuter des scripts locaux qui résident dans des instances.

Solution de rechange : Dans les instances Microsoft Windows, le script ne peut s'exécuter que comme l'ID utilisateur ocarun par défaut utilisé par l'utilitaire d'exécution de commande d'Oracle Cloud Agent. Cette limitation ne concerne pas les instances Oracle Linux.

Détails : La récupération après sinistre de pile complète utilise l'utilitaire Exécuter la commande d'Oracle Cloud Agent (OCA) pour exécuter des scripts locaux dans les instances. Par défaut, ces scripts sont exécutés en tant qu'utilisateur ocarun.

Solution de rechange : Dans 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 reprise après sinistre doit être accessible et exécutable par l'ID utilisateur ocarun.

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 complets aux interprètes de script ou aux scripts, la récupération après sinistre de pile complète génère des erreurs.

Solution de rechange : Lorsque vous configurez une étape définie par l'utilisateur dans un plan de RS pour exécuter un script local qui réside dans une instance, assurez-vous de fournir le chemin complet de tout interpréteur qui précède le nom du script, ainsi que le chemin complet du script.

Détails : Lors des opérations de RS, la RS de pile complète tente de réaffecter l'adresse IP privée initiale 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 initiale 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 déplacer tous les noeuds d'une grappe OCFS2 et que l'adresse IP privée d'un noeud de grappe ne peut pas être réaffectée, ces noeuds se détachent de la grappe OCFS2 après le lancement des noeuds dans la région de secours.

Solution de rechange : 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 la grappe sont disponibles dans le sous-réseau de destination.

Détails : Une fois que la reprise après sinistre de pile complète a déplacé une instance vers une autre région, la page de ressources de l'instance peut afficher le message suivant pour Accès à l'instance :

Impossible de savoir comment se connecter à une instance qui utilise cette image

Solution de rechange : Ignorez ce message. Les connexions SSH à l'instance fonctionnent normalement si vous utilisez le fichier de clés SSH initial pour la connexion à l'instance et l'authentification.

Détails : Une fois que la récupération après sinistre de pile complète a déplacé une instance vers une autre région, la page de ressources de l'instance peut afficher des informations incorrectes pour la partie Image de son volume de démarrage.

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

Solution de rechange : Ce message d'erreur concerne l'affichage du nom de l'image. Il n'a aucune incidence sur le fonctionnement de l'instance ou de son volume de démarrage.

Détails : Lorsqu'il n'y a pas d'heure de veille pour la commande nohup, l'exécution de la commande run échoue et la déclaration du statut échoue.

nohup sh enabler.sh  &> enabler.log &
sleep 10
exit 0

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

Solution de rechange : Après avoir exécuté un plan RS, configurez le paramètre de performance manuellement.

Détails : Lors du chargement sur demande d'un fichier zip créé sur un ordinateur Windows, le chargement du contenu du journal peut échouer. Cet échec est dû au fait que l'heure de la dernière modification et celle de la création du zip créé sous Windows sont les mêmes. Ainsi, lorsque le fichier est décompressé, l'heure de la dernière modification du fichier est définie comme l'heure de création du fichier, qui peut être antérieure à l'horodatage des entrées du fichier journal. Dans ce cas, les entrées de journal dont l'horodatage est plus récent que l'heure de la dernière modification du fichier ne sont pas chargées.

Exemple du problème

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

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

Solution de rechange : Copier les fichiers journaux dans un nouveau dossier et créer un fichier zip. L'heure de la dernière modification du fichier devient plus récente que l'horodatage des entrées du journal. Utilisez ce nouveau fichier zip pour le chargement sur demande.

Dans l'exemple précédent, après la mise en oeuvre de la solution de rechange :

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

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

Lien direct vers ce problème : Chargement sur demande depuis un ordinateur Windows à l'aide d'un fichier zip

Détails : Les dossiers contenant plus de 10 000 fichiers peuvent entraîner une utilisation élevée des ressources (mémoire / stockage / unité centrale) 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 de grands dossiers sont détectés par le plugiciel Log Analytics de l'agent de gestion, un message similaire à l'exemple suivant est ajouté au fichier mgmt_agent_logan.log de l'agent de gestion :

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 : Il est conseillé d'éviter d'utiliser des dossiers de grande taille. Utilisez un mécanisme de nettoyage pour supprimer les fichiers peu de temps après leur collecte afin que l'agent de gestion dispose de suffisamment de temps pour les collecter à nouveau.

Cependant, si vous voulez continuer à surveiller les journaux dans des dossiers de grande taille, vous pouvez activer le soutien 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.

Lien direct vers ce problème : Traitement spécial lors de la surveillance des journaux dans des dossiers de grande taille