Résolution des problèmes de base de données pour Amazon RDS Custom for Oracle - Amazon Relational Database Service
Affichage des événements RDS CustomAbonnement aux événements personnalisés RDSRésolution des problèmes liés à la création d'une version de moteur personnalisée (CEV)Correction des configurations non prises en charge dans RDS Custom for OracleRésolution des problèmes de mise à niveau de RDS Custom for OracleDépannage de RDS Custom pour la promotion de réplicas Oracle

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Résolution des problèmes de base de données pour Amazon RDS Custom for Oracle

Le modèle de responsabilité partagée de RDS Custom fournit un accès au niveau du shell du système d'exploitation et un accès administrateur de base de données. RDS Custom exécute les ressources de votre compte, contrairement à Amazon RDS qui exécute les ressources d'un compte système. Un meilleur accès s'accompagne de responsabilités plus importantes. Dans les sections suivantes, vous apprendrez à résoudre les problèmes liés aux instances de base de données Amazon RDS Custom.

Note

Cette section explique comment résoudre les problèmes liés à RDS Custom for Oracle. Pour la résolution des problèmes liés à RDS Custom for SQL Server, consultez Résolution des problèmes de base de données pour Amazon RDS Custom for SQL Server.

Affichage des événements RDS Custom

La procédure d'affichage est la même pour les instances de base de données RDS Custom et Amazon RDS. Pour plus d’informations, consultez Affichage d'évènements Amazon RDS.

Pour afficher la notification d'événement personnalisée RDS à l'aide de AWS CLI, utilisez la describe-events commande. RDS Custom s'accompagne de plusieurs nouveaux événements. Les catégories d'événements sont les mêmes que pour Amazon RDS. Pour obtenir la liste des événements, consultez Catégories d'événements Amazon RDS et messages d'événements .

L'exemple suivant récupère les détails des événements qui se sont produits pour l'instance de base de données RDS Custom spécifiée.

aws rds describe-events \
    --source-identifier my-custom-instance \
    --source-type db-instance

Abonnement aux événements personnalisés RDS

La procédure d'abonnement à des événements est la même pour les instances de base de données RDS Custom et Amazon RDS. Pour plus d’informations, consultez Abonnement à la notification d'évènement Amazon RDS.

Pour vous abonner à la notification d'événements RDS Custom à l'aide de l'interface de ligne de commande, utilisez la commande create-event-subscription. Incluez les paramètres requis suivants :

  • --subscription-name

  • --sns-topic-arn

L'exemple suivant montre comment créer un abonnement pour les événements de sauvegarde et de restauration d'une instance de base de données RDS Custom dans le compte AWS actuel. Les notifications sont envoyées à une rubrique Amazon Simple Notification Service (Amazon SNS) spécifiée par --sns-topic-arn.

aws rds create-event-subscription \
    --subscription-name my-instance-events \
    --source-type db-instance \
    --event-categories '["backup","recovery"]' \
    --sns-topic-arn arn:aws:sns:us-east-1:123456789012:interesting-events

Résolution des problèmes liés à la création d'une version de moteur personnalisée pour RDS Custom for Oracle

Lorsque la création d'une CEV échoue, RDS Custom émet RDS-EVENT-0198 avec le message Creation failed for custom engine version major-engine-version.cev_name et ajoute des détails sur l'échec. Par exemple, l'événement imprime les fichiers manquants.

La création d'une CEV peut échouer en raison des problèmes suivants :

  • Le compartiment Amazon S3 contenant vos fichiers d'installation ne se trouve pas dans la même AWS région que votre CEV.

  • Lorsque vous demandez la création d'un CEV dans et Région AWS pour la première fois, RDS Custom crée un compartiment S3 pour stocker les ressources personnalisées RDS (telles que les artefacts CEV, les journaux et AWS CloudTrail les journaux de transactions).

    La création de la CEV échoue si RDS Custom ne parvient pas à créer le compartiment S3. Soit l'appelant ne dispose pas des autorisations S3, comme décrit dans la section Étape 5 : accordez les autorisations requises à votre utilisateur ou à votre rôle IAM, soit le nombre de compartiments S3 a atteint la limite.

  • L'appelant ne dispose pas des autorisations nécessaires pour obtenir des fichiers de votre compartiment S3 contenant les fichiers multimédias d'installation. Ces autorisations sont décrites dans la section Étape 7 : Ajouter les autorisations IAM nécessaires.

  • Votre politique IAM est dotée d'une condition aws:SourceIp. Assurez-vous de suivre les recommandations de la section AWS refuse l'accès à AWS en fonction de l'adresse IP source dans le Guide de l'utilisateur AWS Identity and Access Management . Assurez-vous également que l'appelant dispose des autorisations S3 décrites dans Étape 5 : accordez les autorisations requises à votre utilisateur ou à votre rôle IAM.

  • Les fichiers multimédias d'installation répertoriés dans le manifeste CEV ne se trouvent pas dans votre compartiment S3.

  • RDS Custom ne connaît pas les totaux de contrôle SHA-256 des fichiers d'installation.

    Vérifiez que les totaux de contrôle SHA-256 des fichiers fournis correspondent à celui qui se trouve sur le site Web Oracle. Si les totaux de contrôle correspondent, contactezAWS Support et indiquez le nom de la CEV qui a échoué, le nom de fichier et le total de contrôle.

  • La version OPatch est incompatible avec vos fichiers correctifs. Vous pourriez obtenir le message suivant :OPatch is lower than minimum required version. Check that the version meets the requirements for all patches, and try again. Pour appliquer un correctif Oracle, vous devez utiliser une version compatible de l'utilitaire OPatch. Vous pouvez trouver la version requise de l'utilitaire Opatch dans le fichier readme du correctif. Téléchargez l'utilitaire OPatch le plus récent depuis My Oracle Support, et essayez à nouveau de créer votre CEV.

  • Les correctifs spécifiés dans le manifeste CEV ne sont pas dans le bon ordre.

Vous pouvez afficher les événements RDS sur la console RDS (dans le volet de navigation, choisissez Events) ou à l'aide de la describe-events AWS CLI commande. La durée par défaut est de 60 minutes. Si aucun événement n'est renvoyé, spécifiez une durée plus importante, comme illustré dans l'exemple suivant.

aws rds describe-events --duration 360

Actuellement, le MediaImport service qui importe des fichiers depuis Amazon S3 pour créer des CEV n'est pas intégré à AWS CloudTrail. Par conséquent, si vous activez l'enregistrement des données pour Amazon RDS in CloudTrail, les appels au MediaImport service tels que l'CreateCustomDbEngineVersionévénement ne sont pas enregistrés.

Vous pouvez toutefois voir des appels provenant de l'API Gateway qui accède à votre compartiment Amazon S3. Ces appels proviennent du MediaImport service de l'CreateCustomDbEngineVersionévénement.

Correction des configurations non prises en charge dans RDS Custom for Oracle

Dans le modèle de responsabilité partagée, il vous incombe de corriger les problèmes de configuration qui redonnent à votre instance de base de données RDS Custom for Oracle le statut unsupported-configuration. Si le problème concerne l' AWS infrastructure, vous pouvez utiliser la console ou le AWS CLI pour le résoudre. Si le problème concerne le système d'exploitation ou la configuration de la base de données, vous pouvez vous connecter à l'hôte pour le résoudre.

Note

Cette section explique comment corriger les configurations non prises en charge dans RDS Custom for Oracle. Pour obtenir des informations sur RDS Custom for SQL Server, consultez Correction des configurations non prises en charge dans RDS Custom for SQL Server.

Le tableau suivant présente des descriptions des notifications et des événements envoyés par le périmètre de prise en charge et explique comment les corriger. Ces notifications et le périmètre de prise en charge sont susceptibles d'être modifiés. Pour en savoir plus sur le périmètre de prise en charge, consultez Périmètre de prise en charge RDS Custom. Pour les descriptions des événements, consultez Catégories d'événements Amazon RDS et messages d'événements .

ID de l’événement Configuration Message d'événement RDS Action

SP-O0000

Configuration manuelle non prise en charge

Le statut de l'instance de base de données personnalisée RDS est défini sur [Configuration non prise en charge] pour les raisons suivantes :

Pour résoudre ce problème, créez un AWS Support dossier.
AWS ressources (infrastructure)

SP-O1001

Volumes Amazon Elastic Block Store (Amazon EBS)

Les volumes EBS suivants ont été ajoutés à l'instance EC2 ec2_id : volume_id. Pour résoudre le problème, détachez les volumes spécifiés de l'instance.

RDS Custom crée deux types de volumes EBS, outre le volume racine créé à partir de l'Amazon Machine Image (AMI), et les associe à l'instance EC2 :

  • Volume binaire dans lequel se trouvent les fichiers binaires du logiciel de base de données

  • Les volumes de données dans lesquels se trouvent les fichiers de base de données

Lorsque vous créez votre instance de base de données, les configurations de stockage que vous spécifiez configurent les volumes de données.

Le périmètre de prise en charge surveille ce qui suit :

  • Les volumes EBS initiaux créés avec l'instance de base de données sont toujours associés à l'instance.

  • Les volumes EBS initiaux ont toujours les mêmes configurations que celles qui ont été définies initialement : type de stockage, taille, IOPS provisionnés et débit de stockage.

  • Aucun volume EBS supplémentaire n'est attaché à l'instance de base de données.

Utilisez la commande CLI suivante pour comparer le type de volume des détails du volume EBS et les détails de l'instance de base de données RDS Custom for Oracle : 

aws rds describe-db-instances \ 
    --db-instance-identifier db-instance-name | grep StorageType

SP-O1002

Volumes Amazon Elastic Block Store (Amazon EBS)

Le volume EBS volume_id a été détaché de l'instance EC2 [ec2_id]. Vous ne pouvez pas détacher le volume d'origine de cette instance. Pour résoudre le problème, attachez à nouveau volume_id à ec2_id.

RDS Custom crée deux types de volumes EBS, outre le volume racine créé à partir de l'Amazon Machine Image (AMI), et les associe à l'instance EC2 :

  • Volume binaire dans lequel se trouvent les fichiers binaires du logiciel de base de données

  • Les volumes de données dans lesquels se trouvent les fichiers de base de données

Lorsque vous créez votre instance de base de données, les configurations de stockage que vous spécifiez configurent les volumes de données.

Le périmètre de prise en charge surveille ce qui suit :

  • Les volumes EBS initiaux créés avec l'instance de base de données sont toujours associés à l'instance.

  • Les volumes EBS initiaux ont toujours les mêmes configurations que celles qui ont été définies initialement : type de stockage, taille, IOPS provisionnés et débit de stockage.

  • Aucun volume EBS supplémentaire n'est attaché à l'instance de base de données.

Utilisez la commande CLI suivante pour comparer le type de volume des détails du volume EBS et les détails de l'instance de base de données RDS Custom for Oracle : 

aws rds describe-db-instances \ 
    --db-instance-identifier db-instance-name | grep StorageType

SP-O1003

Volumes Amazon Elastic Block Store (Amazon EBS)

Le volume EBS volume_id d'origine attaché à l'instance EC2 ec2_id a été modifié comme suit : taille [X] à [Y], type [N] à [M] ou IOPS [J] à [K]. Pour résoudre le problème, annulez la modification.

RDS Custom crée deux types de volumes EBS, outre le volume racine créé à partir de l'Amazon Machine Image (AMI), et les associe à l'instance EC2 :

  • Volume binaire dans lequel se trouvent les fichiers binaires du logiciel de base de données

  • Les volumes de données dans lesquels se trouvent les fichiers de base de données

Lorsque vous créez votre instance de base de données, les configurations de stockage que vous spécifiez configurent les volumes de données.

Le périmètre de prise en charge surveille ce qui suit :

  • Les volumes EBS initiaux créés avec l'instance de base de données sont toujours associés à l'instance.

  • Les volumes EBS initiaux ont toujours les mêmes configurations que celles qui ont été définies initialement : type de stockage, taille, IOPS provisionnés et débit de stockage.

  • Aucun volume EBS supplémentaire n'est attaché à l'instance de base de données.

Utilisez la commande CLI suivante pour comparer le type de volume des détails du volume EBS et les détails de l'instance de base de données RDS Custom for Oracle : 

aws rds describe-db-instances \ 
    --db-instance-identifier db-instance-name | grep StorageType

SP-O1004

État de l'instance Amazon EC2

La restauration automatique a laissé l'instance EC2 [ec2_id] dans un état altéré. Pour résoudre le problème, consultez la section Résolution des problèmes de restauration d'instance.

Pour vérifier l'état d'une instance de base de données, utilisez la console ou exécutez la AWS CLI commande suivante :

aws rds describe-db-instances \ 
    --db-instance-identifier db-instance-name |grep DBInstanceStatus

SP-O1005

Attributs de l'instance Amazon EC2

L'instance EC2 [ec2_id] a été modifiée comme suit : l'attribut [att1] est passé de [val-old] à [val-new], l'attribut [att2] est passé de [val-old] à [val-new]. Pour résoudre le problème, revenez à la valeur d'origine.

SP-O1006

État de l'instance Amazon EC2

L'instance EC2 [ec2_id] a été interrompue ou est introuvable. Pour résoudre le problème, supprimez l'instance de base de données personnalisée RDS.

Le périmètre de prise en charge surveille les notifications de changement d'état de l'instance EC2. L'instance EC2 doit toujours être en cours d'exécution.

Pour supprimer votre instance de base de données

  1. Pour vérifier l'état d'une instance de base de données, utilisez la console ou exécutez la AWS CLI commande suivante : 

    aws rds describe-db-instances \ 
    --db-instance-identifier db-instance-name |grep DBInstanceStatus

  2. Supprimez votre instance de base de données RDS Custom pour Oracle.

SP-O1007

État de l'instance Amazon EC2

L'instance EC2 [ec2_id] a été arrêtée. Pour résoudre le problème, démarrez l'instance.

Le périmètre de prise en charge surveille les notifications de changement d'état de l'instance EC2. L'instance EC2 doit toujours être en cours d'exécution.

Pour redémarrer votre instance de base de données

  1. Pour vérifier l'état d'une instance de base de données, utilisez la console ou exécutez la AWS CLI commande suivante : 

    aws rds describe-db-instances \ 
    --db-instance-identifier db-instance-name |grep DBInstanceStatus

  2. Démarrez votre instance de base de données.

  3. Remontez les volumes binaires et les volumes de données.
Système d’exploitation

SP-O2001

Statut de l'agent RDS Custom

L'agent RDS Custom n'est pas exécuté sur l'instance EC2 [ec2_id]. Assurez-vous que l'agent est en cours d'exécution sur [ec2_id].

Sur RDS Custom for Oracle, l'instance de base de données sort du périmètre de prise en charge si l'agent RDS Custom s'arrête. L'agent publie la IamAlive métrique sur Amazon CloudWatch toutes les 30 secondes. Une alarme est déclenchée si la métrique n'a pas été publiée depuis 30 secondes. Le périmètre de prise en charge surveille également l'état du processus d'agent RDS Custom sur l'hôte toutes les 30 minutes.

Pour redémarrer l'agent RDS Custom

  1. Connectez-vous à votre hôte et assurez-vous que l'agent RDS Custom est en cours d'exécution.

  2. Exécutez la commande suivante pour connaître le statut de l'agent.

    service rdscustomagent status

  3. Utilisez la commande suivante pour démarrer l'agent.

    service rdscustomagent start

Lorsque l'agent RDS Custom s'exécute à nouveau, la IamAlive métrique est publiée sur Amazon CloudWatch et l'alarme passe à l'OKétat. Le périmètre de prise en charge est ainsi informé que l'agent est en cours d'exécution.

SP-O2002

AWS Systems Manager statut de l'agent (agent SSM)

L'agent Systems Manager sur l'instance EC2 [ec2_id] est inaccessible. Assurez-vous que vous avez correctement configuré le réseau, l'agent et les autorisations IAM.

L'agent SSM doit toujours être en cours d'exécution. L'agent RDS Custom est chargé de s'assurer que Systems Manager Agent est en cours d'exécution. Si l'agent SSM a été arrêté puis redémarré, l'agent personnalisé RDS publie une métrique sur. CloudWatch L'agent RDS Custom est doté d'une alarme sur la métrique configurée pour se déclencher si un redémarrage a eu lieu au cours des trois dernières minutes. Le périmètre de support surveille également l'état du processus de l'agent SSM sur l'hôte toutes les 30 minutes.

Pour de plus amples informations, consultez la section Résolution des problèmes de SSM Agent.

SP-O2003

AWS Systems Manager statut de l'agent (agent SSM)

L'agent Systems Manager sur l'instance EC2 [ec2_id] s'est écrasé plusieurs fois. Pour plus d'informations, consultez la documentation de dépannage de l'agent SSM.

Pour de plus amples informations, consultez la section Résolution des problèmes de SSM Agent.

SP-O 2004

Fuseau horaire du système d'exploitation

Le fuseau horaire sur l'instance EC2 [ec2_id] a été modifié. Pour résoudre ce problème, rétablissez le réglage précédent de [] previous-time-zonepour le fuseau horaire. Utilisez ensuite un groupe d'options RDS pour modifier le fuseau horaire.

L'automatisation RDS a détecté que le fuseau horaire de l'hôte avait été modifié sans utiliser de groupe d'options. Ce changement au niveau de l'hôte peut provoquer des échecs d'automatisation RDS, de sorte que l'instance EC2 est placée dans cet état. unsupported-configuration

Pour corriger le réglage du fuseau horaire

  1. Connectez-vous à votre hôte EC2 et vérifiez le fuseau horaire du système d'exploitation comme suit :

    timedatectl

  2. Mettez en pause l'automatisation de RDS Custom. Pour plus d’informations, consultez Suspendre et reprendre votre instance de base de données RDS Custom.

  3. Arrêtez l'instance de base de données.

  4. Annulez le changement de fuseau horaire sur le système d'exploitation.

  5. Démarrez l'instance de base de données.

  6. Relancez l'automatisation de RDS Custom.

Votre instance de base de données devient disponible dans les 30 minutes. Pour éviter de vous déplacer hors du périmètre à l'avenir, modifiez votre fuseau horaire via un groupe d'options. Pour plus d’informations, consultez Fuseau horaire Oracle.

SP-O 2005

Configurations sudo

Les configurations sudo sur l'instance EC2 [ec2_id] ne disposent pas des autorisations nécessaires. Pour résoudre ce problème, annulez les modifications récentes apportées aux configurations sudo.

Le périmètre de prise en charge vérifie que certains utilisateurs du système d'exploitation sont autorisés à exécuter certaines commandes. Il vérifie les configurations sudo par rapport à l'état pris en charge.

Lorsque les configurations sudo ne sont pas prises en charge, RDS Custom tente de les redéfinir sur le dernier état pris en charge. En cas de succès, la notification suivante est envoyée :

RDS Custom successfully overwrote your configuration. (RDS Custom a réussi à écraser votre configuration.)

Pour étudier les modifications apportées aux configurations sudo

  1. Connectez-vous à votre hôte.

  2. Exécutez la commande suivante.

    visudo -c -f /etc/sudoers.d/individual_sudo_files

  3. Modifiez les sudo configurations si nécessaire.

Une fois que le périmètre de support a déterminé que les sudo configurations sont prises en charge, votre instance de base de données RDS Custom for Oracle est disponible dans les 30 minutes.

SP-O 2006

Accessibilité du compartiment S3

L'automatisation personnalisée RDS ne peut pas télécharger de fichiers depuis le compartiment S3 sur l'instance EC2 [ec2_id]. Vérifiez votre configuration réseau et assurez-vous que l'instance autorise les connexions depuis et vers S3.
Database (Base de données)

SP-O3001

Cible de retard d'archivage de la base de données

Le paramètre ARCHIVE_LAG_TARGET sur l'instance EC2 [ec2_id] est en dehors de la plage recommandée value_range. Pour résoudre le problème, définissez le paramètre sur une valeur comprise dans value_range.

Le périmètre de support surveille le paramètre ARCHIVE_LAG_TARGET de base de données afin de vérifier que l'heure de restauration la plus récente de l'instance de base de données se situe dans des limites raisonnables.

Pour modifier l'objectif de décalage pour les redo logs archivés

  1. Connectez-vous à votre hôte EC2

  2. Connectez-vous à votre instance de base de données RDS Custom pour Oracle

  3. Remplacez le ARCHIVE_LAG_TARGET paramètre par une valeur comprise entre 60 et 7200. Par exemple, utilisez l'instruction SQL suivante.

    ALTER SYSTEM SET ARCHIVE_LAG_TARGET=300 SCOPE=BOTH;

Votre instance de base de données devient disponible dans les 30 minutes.

SP-O3002

Rôle Oracle Data Guard

Le rôle de base de données [role_name] n'est pas pris en charge pour Oracle Data Guard sur l'instance EC2 [ec2_id]. Pour résoudre le problème, définissez le paramètre DATABASE_ROLE sur PRIMARY ou PHYSICAL STANDBY.

Le périmètre de support surveille le rôle de base de données actuel toutes les 15 secondes et envoie une CloudWatch notification si le rôle de base de données a changé. Le paramètre Oracle Data Guard DATABASE_ROLE doit être PRIMARY ou PHYSICAL STANDBY.

Pour restaurer votre rôle de base de données Oracle Data Guard à une valeur prise en charge

  1. Vérifiez le rôle d'Oracle Data Guard en exécutant l'instruction suivante :

    SELECT DATABASE_ROLE FROM V$DATABASE;

  2. Si votre instance de base de données est autonome, utilisez l'une des instructions suivantes pour lui redonner le PRIMARY rôle :

    ALTER DATABASE COMMIT TO SWITCHOVER PRIMARY;
ALTER DATABASE ACTIVATE STANDBY DATABASE;

    Si votre instance de base de données est une réplique, utilisez l'instruction suivante pour lui redonner le PHYSICAL STANDBY rôle :

    ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

Une fois que le périmètre de prise en charge a déterminé que le rôle de base de données est pris en charge, votre instance de base de données RDS Custom for Oracle devient disponible dans les 15 secondes.

SP-O3003

État de la base de données

Le processus SMON de la base de données Oracle est dans un état zombie. Pour résoudre le problème, restaurez manuellement la base de données sur l'instance EC2 [ec2_id], ouvrez-la, puis sauvegardez-la immédiatement. Pour obtenir de l'aide supplémentaire, contactez AWS Support.

Le périmètre de prise en charge surveille l'état de l'instance de base de données. Il surveille également le nombre de redémarrages qui se sont produits au cours de la dernière heure et du jour précédent. Vous êtes averti lorsque l'instance se trouve dans un état où elle se trouve toujours, mais vous ne pouvez pas interagir avec elle.

Pour que le périmètre de support évalue l'état de votre instance

  1. Connectez-vous à votre hébergeur et déterminez l'état de la base de données.

    ps -eo pid,state,command | grep smon

  2. Si nécessaire, redémarrez votre instance de base de données. Si le redémarrage échoue, passez à l'étape suivante.

  3. Si nécessaire, redémarrez votre hôte EC2.

Après le redémarrage de votre instance de base de données, l'agent personnalisé RDS détecte que votre instance de base de données ne répond plus. Il notifie alors le périmètre de prise en charge qu'il faut réévaluer le statut de votre instance de base de données.

SP-O3004

Mode journal de base de données

Le mode journal de base de données sur l'instance EC2 [ec2_id] a été remplacé par [value_b]. Pour résoudre le problème, réglez le mode journal sur [value_a].
Pour modifier le mode de journalisation de votre instance de base de données sur ARCHIVELOG

  1. Connectez-vous à votre hôte EC2.

  2. Connectez-vous à votre base de données et exécutez l'instruction suivante :

    SELECT LOG_MODE FROM V$DATABASE;

    Vous pouvez également exécuter la commande suivante dans SQL*Plus :

    ARCHIVE LOG LIST

  3. Exécutez la commande SQL*Plus suivante pour lancer un arrêt cohérent.

    SHUTDOWN IMMEDIATE

L'agent RDS Custom redémarre automatiquement votre instance de base de données et définit le mode journal sur. ARCHIVELOG Votre instance de base de données devient disponible dans les 30 minutes.

SP-O3005

Chemin d'accès Oracle Home

Le répertoire d'origine Oracle Home sur l'instance EC2 [ec2_id] a été remplacé par new_path. Pour résoudre le problème, rétablissez le paramètre sur old_path.

SP-O3006

Nom unique de la base de données

Le nom unique de la base de données sur l'instance EC2 [ec2_id] a été remplacé par new_value. Pour résoudre le problème, remplacez le nom par old_value.
Pour modifier le nom unique de base de données de votre instance de base de données

  1. Connectez-vous à votre hôte EC2.

  2. Connectez-vous à la base de données et exécutez l'instruction suivante :

    SELECT DB_UNIQUE_NAME FROM V$DATABASE;

  3. Spécifiez le nom unique de la base de données d'origine à l'aide de la commandeALTER SYSTEM SET DB_UNIQUE_NAME.

  4. Exécutez l'instruction SQL suivante pour lancer un arrêt cohérent.

    SHUTDOWN IMMEDIATE;

L'agent RDS Custom redémarre automatiquement votre instance de base de données et définit le mode journal sur. ARCHIVELOG Votre instance de base de données devient disponible dans les 30 minutes.

Dépannage des mises à niveau de RDS Custom for Oracle

Votre mise à niveau d'une instance de RDS Custom for Oracle peut échouer. Vous trouverez ci-dessous des techniques que vous pouvez utiliser lors des mises à niveau des bases de données RDS Custom pour les instances de base de données Oracle :

  • Examinez tous les fichiers journaux de sortie de la mise à niveau dans l'annuaire /tmp sur votre instance de base de données. Les noms des journaux dépendent de la version du moteur de votre base de données. Par exemple, vous pouvez voir des journaux contenant les chaînes catupgrd ou catup.

  • Examinez le fichier alert.log situé dans l'annuaire /rdsdbdata/log/trace.

  • Exécutez la commande grep suivante dans le répertoire root pour suivre le processus de mise à niveau du système d'exploitation. Cette commande indique l'emplacement d'écriture des fichiers journaux et détermine l'état du processus de mise à niveau.

    ps -aux | grep upg

    Voici un exemple de résultat.

    root     18884  0.0  0.0 235428  8172 ?        S<   17:03   0:00 /usr/bin/sudo -u rdsdb /rdsdbbin/scripts/oracle-control ORCL op_apply_upgrade_sh RDS-UPGRADE/2.upgrade.sh
rdsdb    18886  0.0  0.0 153968 12164 ?        S<   17:03   0:00 /usr/bin/perl -T -w /rdsdbbin/scripts/oracle-control ORCL op_apply_upgrade_sh RDS-UPGRADE/2.upgrade.sh
rdsdb    18887  0.0  0.0 113196  3032 ?        S<   17:03   0:00 /bin/sh /rdsdbbin/oracle/rdbms/admin/RDS-UPGRADE/2.upgrade.sh
rdsdb    18900  0.0  0.0 113196  1812 ?        S<   17:03   0:00 /bin/sh /rdsdbbin/oracle/rdbms/admin/RDS-UPGRADE/2.upgrade.sh
rdsdb    18901  0.1  0.0 167652 20620 ?        S<   17:03   0:07 /rdsdbbin/oracle/perl/bin/perl catctl.pl -n 4 -d /rdsdbbin/oracle/rdbms/admin -l /tmp catupgrd.sql
root     29944  0.0  0.0 112724  2316 pts/0    S+   18:43   0:00 grep --color=auto upg

  • Exécutez la requête SQL suivante pour vérifier l'état actuel des composants, et trouver la version de la base de données et les options installées sur l'instance de base de données.

    SET LINESIZE 180
COLUMN COMP_ID FORMAT A15
COLUMN COMP_NAME FORMAT A40 TRUNC
COLUMN STATUS FORMAT A15 TRUNC
SELECT COMP_ID, COMP_NAME, VERSION, STATUS FROM DBA_REGISTRY ORDER BY 1;

    La sortie se présente comme suit :

    COMP_NAME                                STATUS               PROCEDURE
---------------------------------------- -------------------- --------------------------------------------------
Oracle Database Catalog Views            VALID                DBMS_REGISTRY_SYS.VALIDATE_CATALOG
Oracle Database Packages and Types       VALID                DBMS_REGISTRY_SYS.VALIDATE_CATPROC
Oracle Text                              VALID                VALIDATE_CONTEXT
Oracle XML Database                      VALID                DBMS_REGXDB.VALIDATEXDB

4 rows selected.

  • Exécutez la requête SQL suivante pour rechercher d'éventuels objets non valides susceptibles de perturber le processus de mise à niveau.

    SET PAGES 1000 LINES 2000
COL OBJECT FOR A40
SELECT SUBSTR(OWNER,1,12) OWNER,
       SUBSTR(OBJECT_NAME,1,30) OBJECT,
       SUBSTR(OBJECT_TYPE,1,30) TYPE, STATUS,
       CREATED
FROM   DBA_OBJECTS 
WHERE  STATUS <>'VALID' 
AND    OWNER IN ('SYS','SYSTEM','RDSADMIN','XDB');

Dépannage de la promotion de réplica pour RDS Custom for Oracle

Vous pouvez promouvoir les répliques Oracle gérées dans RDS Custom for Oracle à l'aide de la console, de la promote-read-replica AWS CLI commande ou PromoteReadReplica de l'API. Si vous supprimez votre instance de base de données principale et que tous les réplicas sont sains, RDS Custom for Oracle transforme automatiquement vos réplicas gérée en instances autonomes. Si un réplica a mis en pause l'automatisation ou se trouve en dehors du périmètre de support, vous devez réparer le réplica avant que RDS Custom puisse le promouvoir automatiquement. Pour plus d’informations, consultez Limites de promotion des réplicas pour RDS Custom for Oracle.

Le flux de travail de promotion des réplicas peut se bloquer dans la situation suivante :

  • L'instance de base de données principale est dans l'état STORAGE_FULL.

  • La base de données principale ne peut pas archiver tous ses journaux de rétablissement en ligne.

  • Il existe un écart entre les fichiers journaux de reprise archivés sur votre réplica Oracle et la base de données principale.

Pour répondre au flux de travail bloqué

  1. Synchronisez l'écart du journal de reprise sur votre réplica d’instance de base de données Oracle.

  2. Forcez la promotion de votre réplica en lecture vers le dernier journal de reprise appliqué. Exécutez les commandes suivantes dans SQL*Plus :

    ALTER DATABASE ACTIVATE STANDBY DATABASE;
SHUTDOWN IMMEDIATE
STARTUP

  3. Contactez-les AWS Support et demandez-leur de passer votre instance de base de données au available statut.