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.
API Gateway
Pour consulter les problèmes connus relatifs à API Gateway, reportez-vous à Problèmes connus pour API Gateway.
Application Performance Monitoring
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
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.
Facturation et gestion des coûts
Pour consulter les problèmes connus relatifs à la facturation et à la gestion des coûts, reportez-vous à Problèmes connus pour la facturation et la gestion des coûts.
Block Volume
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
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
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
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
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
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.
Cloud Guard
Pour consulter les problèmes connus relatifs à Cloud Guard, reportez-vous à Problèmes connus pour Cloud Guard.
Cloud Shell
Pour consulter les problèmes connus relatifs à Cloud Shell, reportez-vous à Problèmes connus pour Cloud Shell.
Quotas de compartiment
Pour consulter les problèmes connus relatifs aux quotas de compartiment, reportez-vous à Problèmes connus pour les quotas de compartiment.
Compliance Documents
Pour consulter les problèmes connus relatifs à Compliance Documents, reportez-vous à Problèmes connus pour Compliance Documents.
Compute
Pour consulter les problèmes connus relatifs à Compute, reportez-vous à Problèmes connus pour Compute.
Compute Cloud@Customer
Pour consulter les problèmes connus relatifs à Compute Cloud@Customer, reportez-vous à Problèmes connus.
Connecteur Hub
Pour consulter les problèmes connus relatifs à Connector Hub, reportez-vous à Problèmes connus pour Connector Hub.
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 :
- 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.
- 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.
- 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
Console Dashboards
Pour consulter les problèmes connus relatifs à Console Dashboards, reportez-vous à Problèmes connus pour Console Dashboards.
Container Engine for Kubernetes
Pour consulter les problèmes connus relatifs à Container Engine for Kubernetes, reportez-vous à Problèmes connus pour Container Engine for Kubernetes.
Container Instances
Pour consulter les problèmes connus relatifs à Container Instances, reportez-vous à Problèmes connus pour Container Instances.
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
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
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
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
--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.
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
--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 &
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 :
- 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.
- 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é :- 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.
- Définissez le paramètre
encrypt_new_tablespaces
sur DDL, comme suit :SQL> alter system set "encrypt_new_tablespaces" = DDL scope = memory;
- 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;
- 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>;
- 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éfinissezencrypt_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.
- Vérifiez le tablespace TEMP par défaut en procédant comme suit :
- 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 commandedbaascli
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 : 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 :
- 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.
- 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é :- 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.
- Définissez le paramètre
encrypt_new_tablespaces
sur DDL, comme suit :SQL> alter system set "encrypt_new_tablespaces" = DDL scope = memory;
- 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;
- 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>;
- 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éfinissezencrypt_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.
- Vérifiez le tablespace TEMP par défaut en procédant comme suit :
- 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 commandedbaascli
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 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
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
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 :
-
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
-
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 :
-
Déterminez l'utilisateur et l'ID de banque d'objets Swift que la base de données utilise pour les sauvegardes.
-
Exécutez la commande
dbcli list-databases
pour déterminer l'ID de la base de données. -
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
-
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
-
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
-
-
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.
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
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 :
Langage | Version | Documentation |
---|---|---|
Java | 1.2.49 | https://github.com/oracle/oci-java-sdk/releases |
Python | 2.0.6 | https://github.com/oracle/oci-python-sdk/releases |
Ruby | 2.3.9 | https://github.com/oracle/oci-ruby-sdk/releases |
Go | 2.7.0 | https://github.com/oracle/oci-go-sdk/releases |
Lien direct vers ce problème : Modifications des ruptures de code dans les kits SDK du service Database
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 :
-
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.
- 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.
- Extrayez le contenu d'opc_installer.zip dans un répertoire cible, par exemple, /home/opc.
- Dans votre location, créez un utilisateur temporaire et accordez-lui des privilèges permettant d'accéder à Object Storage.
- Créez un jeton d'authentification pour cet utilisateur temporaire et notez le mot de passe.
-
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.
-
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.
-
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.)
-
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 :
- Sauvegardez les fichiers dans le répertoire
/opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs
. -
Exécutez ces deux commandes pour remplacer les fichiers
libopc.so
etopc_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
- Sauvegardez les fichiers dans le répertoire
-
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.
- (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
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 :
-
Passez à l'utilisateur oracle dans le système d'exploitation.
[opc@hostname ~]$ sudo su - oracle
-
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
-
Démarrez SQL*Plus.
[oracle@hostname ~]$ sqlplus / as sysdba
-
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
-
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
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.
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"
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 :
-
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
-
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))
-
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
-
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
-
Modifiez les droits d'accès :
[oracle@dbsysHost xdb_wallet]$ chmod 640 /u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet/*
-
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
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.
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.
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
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
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.
-
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.
-
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
-
Vous pouvez également utiliser SQL*Plus pour confirmer que les disques "votants" sont endommagés :
-
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
-
Connectez-vous à SQL*Plus en tant qu'utilisateur
SYSASM
.$ORACLE_HOME/bin/sqlplus / as sysasm
-
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.
-
-
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.
-
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.
-
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.
-
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 êtreONLINE
et celle devoting_file
ne doit pas êtreY
.
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
-
-
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
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 :
- Connectez-vous au noeud en tant qu'utilisateur root.
-
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
-
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
- 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
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
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
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.
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.
Database Migration
Pour consulter les problèmes connus relatifs à Database Migration, reportez-vous à Problèmes connus pour Database Migration.
OCI Database avec PostgreSQL
Pour connaître les problèmes connus relatifs à OCI Database avec PostgreSQL, reportez-vous à OCI Database avec PostgreSQL Problèmes connus.
Outils de développeur
Pour connaître les problèmes connus liés aux outils de développeur, reportez-vous à Problèmes connus pour les outils de développeur.
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.
Email Delivery
Pour consulter les problèmes connus, reportez-vous à Problèmes connus pour Email Delivery.
Events
Actuellement, il n'existe aucun problème connu pour Events.
File Storage
Pour consulter les problèmes connus relatifs à File Storage, reportez-vous à Problèmes connus pour File Storage.
Full Stack Disaster Recovery
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.
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.
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.
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.
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.
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.
/bin/sh /path/to/myscript.sh arg1 arg2
au lieu de sh myscript.sh arg1 arg2
.
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.
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.
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.
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.
sleep
dans le script wrapper, comme indiqué ici :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 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.
Functions
Pour consulter les problèmes connus relatifs à Functions, reportez-vous à Problèmes connus pour OCI Functions.
Globally Distributed Autonomous Database
Pour consulter les problèmes connus relatifs à Globally Distributed Autonomous Database, reportez-vous à Problèmes connus.
GoldenGate
Reportez-vous à Problèmes connus pour Oracle Cloud Infrastructure GoldenGate.
Health Checks
Pour consulter les problèmes connus relatifs à Health Checks, reportez-vous à Problèmes connus pour Health Checks.
IAM
Pour consulter les problèmes relatifs aux instances IAM avec des domaines d'identité, reportez-vous à Problèmes connus pour les instances IAM avec des domaines d'identité.
Pour consulter les problèmes relatifs aux instances IAM sans domaines d'identité, reportez-vous à Problèmes connus pour les instances IAM sans domaines d'identité.
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
Pour consulter les problèmes connus relatifs à Logging, reportez-vous à Problèmes connus pour Logging.
Logging Analytics
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
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.
- 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.
Monitoring
Pour consulter les problèmes connus relatifs à Monitoring, reportez-vous à Problèmes connus pour Monitoring.
Network Load Balancer
Pour consulter les problèmes connus relatifs à Network Load Balancer, reportez-vous à Problèmes connus.
Networking
Pour consulter les problèmes connus relatifs à Networking, reportez-vous à Problèmes connus pour Networking.
Notifications
Pour consulter les problèmes connus relatifs à Notifications, reportez-vous à Problèmes connus pour Notifications.
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
Pour plus d'informations sur les problèmes connus dans le service OS Management, reportez-vous à Problèmes connus pour OS Management.
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.
Resource Manager
Pour consulter les problèmes connus relatifs à Resource Manager, reportez-vous à Problèmes connus pour Resource Manager.
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
Pour consulter les problèmes connus relatifs à Search, 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.
Streaming
Pour consulter les problèmes connus relatifs à Streaming, reportez-vous à Problèmes connus pour Streaming.
Tagging
Pour consulter les problèmes connus relatifs à Tagging, reportez-vous à Problèmes connus pour Tagging.
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.
Visual Builder
Pour connaître les problèmes connus liés à Visual Builder, reportez-vous à Problèmes connus pour Oracle Visual Builder.
Visual Builder Studio
Pour connaître les problèmes connus relatifs à Visual Builder Studio, reportez-vous à Problèmes connus pour Oracle Visual Builder Studio.
Web Application Firewall (WAF)
Pour consulter les problèmes connus relatifs à Web Application Firewall, reportez-vous à Problèmes connus pour Web Application Firewall.
Web Application Acceleration
Pour consulter les problèmes connus relatifs à Web Application Acceleration, reportez-vous à Problèmes connus.