Quels facteurs dois-je prendre en compte lorsque j'effectue la mise à niveau d'une version majeure dans Amazon RDS for Oracle ?

Date de la dernière mise à jour : 28/09/2021

J'ai une instance de base de données Amazon Relational Database Service (Amazon RDS) qui exécute Oracle. Je veux connaître les facteurs à prendre en compte lorsque j'effectue la mise à niveau d'une version majeure.

Brève description

Lorsqu'Amazon RDS commence à prendre en charge une nouvelle version de la base de données Oracle, vous pouvez mettre à niveau votre version de base de données Oracle existante en choisissant une version supérieure, puis en effectuant une mise à niveau de version majeure. Une version majeure peut inclure des mises à jour, de nouvelles fonctions, des correctifs de sécurité ainsi que des améliorations d'optimiseur et de performances. Il est recommandé de tester les fonctionnalités, la compatibilité et les performances de votre application par rapport à la nouvelle version de la base de données Oracle dans des environnements hors production avant de mettre à niveau votre base de données de production.

Remarque : en cas d'erreurs lors de l'exécution des commandes AWS CLI, assurez-vous d'utiliser la version AWS CLI la plus récente.

Résolution

Avant la mise à niveau

Voici quelques éléments à garder à l'esprit avant d'effectuer la mise à niveau de la version majeure :

Chemin de mise à niveau : vérifiez le chemin de mise à niveau pris en charge depuis votre version de base de données Oracle actuelle vers la version majeure prévue de la base de données Oracle. Vous pouvez vérifier les chemins de mise à niveau valides en exécutant la commande AWS Command Line Interface (AWS CLI) suivante.

Pour Windows :

aws rds describe-db-engine-versions --engine engine-edition --engine-version current-engine-version --query "DBEngineVersions[*].ValidUpgradeTarget[?IsMajorVersionUpgrade==`true`].EngineVersion"

Pour Linux, macOS ou Unix :

aws rds describe-db-engine-versions --engine engine-edition --engine-version current-engine-version --query 'DBEngineVersions[*].ValidUpgradeTarget[?IsMajorVersionUpgrade==`true`].EngineVersion'

Veillez à remplacer les valeurs suivantes dans les commandes précédentes :

  • engine-edition par l'édition du moteur de base de données
  • current-engine-version par la version actuelle du moteur de base de données

Supposons que vous disposez d'une instance Amazon RDS for Oracle 12.1.0.2.v10. Pour en savoir plus sur toutes les versions majeures valides vers lesquelles vous pouvez mettre à niveau vos instances RDS for Oracle, exécutez la commande suivante.

Pour Windows :

aws rds describe-db-engine-versions --engine oracle-ee --engine-version 12.1.0.2.v10 --query "DBEngineVersions[*].ValidUpgradeTarget[?IsMajorVersionUpgrade==`true`].EngineVersion"

Pour Linux, macOS ou Unix :

aws rds describe-db-engine-versions --engine oracle-ee --engine-version 12.1.0.2.v10 --query 'DBEngineVersions[*].ValidUpgradeTarget[?IsMajorVersionUpgrade==`true`].EngineVersion'

Classe d'instance : vérifiez que votre classe d'instance actuelle est prise en charge pour la version majeure que vous allez mettre à niveau. Pour plus d'informations sur les classes d'instances prises en charge par RDS for Oracle, consultez Classes d'instances de bases de données Oracle prises en charge. Vous pouvez également vérifier la classe d'instance prise en charge en exécutant la commande AWS CLI suivante.

Pour Windows :

aws rds describe-orderable-db-instance-options --engine engine-edition --engine-version new-engine-version --region example-region --query "OrderableDBInstanceOptions[*].DBInstanceClass"

Pour Linux, macOS ou Unix :

aws rds describe-orderable-db-instance-options --engine engine-edition --engine-version new-engine-version --region example-region --query 'OrderableDBInstanceOptions[*].DBInstanceClass'

Veillez à remplacer les valeurs suivantes dans les commandes précédentes :

  • engine-edition par l'édition du moteur de base de données
  • new-engine-version par la nouvelle version vers laquelle vous envisagez d'effectuer la mise à niveau
  • example-region par la région que vous utilisez

Par exemple, supposons que vous souhaitiez effectuer une mise à niveau vers une instance RDS for Oracle 12.2.0.1.ru-2020-10.r1. Pour en savoir plus sur les classes d'instances qui prennent en charge la version majeure dans une région spécifique, exécutez la commande suivante :

aws rds describe-orderable-db-instance-options --engine oracle-ee --engine-version 12.2.0.1.ru-2020-10.rur-2020-10.r1 --region us-east-1 --query "OrderableDBInstanceOptions[*].DBInstanceClass"

N'oubliez pas de remplacer us-east-1 dans la commande par la région de votre choix.

Compatibilité du client : vérifiez que les versions du client/pilote Oracle sont compatibles avec la nouvelle version majeure. Vérifiez si les pilotes doivent être mis à niveau en même temps que la mise à niveau de la version majeure. Pour plus d'informations sur l'interopérabilité, consultez Interopérabilité entre les clients de bases de données Oracle et les bases de données Oracle dans la documentation Oracle.

Méthode de mise à niveau : vous pouvez effectuer la mise à niveau de la version majeure de l'une des manières suivantes.

  • Modifiez l'instance RDS et appliquez la nouvelle version majeure.
    Remarque : cette méthode implique un certain temps d'arrêt.
  • Créez une nouvelle instance RDS avec la version majeure et effectuez la migration des données à l'aide d'AWS Data Migration Service (AWS DMS).
    Remarque : AWS DMS utilise une approche minimaliste pour effectuer la migration des données, et ne crée que les objets nécessaires à la migration efficace des données. AWS DMS crée des tables, des clés primaires et, dans certains cas, des index uniques, mais ne crée pas d'autres objets qui ne sont pas nécessaires pour la migration efficace des données depuis la source. Par exemple, AWS DMS ne crée pas d'index secondaires, de contraintes de clés non primaires ou de valeurs par défaut des données. Pour plus d'informations, consultez Vue de haut niveau d'AWS DMS.

Choisissez l'une de ces méthodes pour effectuer la mise à niveau en fonction de votre cas d'utilisation.

Groupe de paramètres personnalisés : si votre instance possède un groupe de paramètres personnalisés, créez un nouveau groupe de paramètres pour la nouvelle version majeure et définissez les paramètres personnalisés de manière appropriée. Pour identifier les paramètres personnalisés que vous utilisez actuellement, comparez le groupe de paramètres personnalisés existant avec le groupe de paramètres par défaut de la version actuelle.

Groupe d'options personnalisées : si votre instance dispose d'un groupe d'options personnalisées, créez un nouveau groupe d'options personnalisées pour la version majeure. Si vous avez des options persistantes ou permanentes, telles que le fuseau horaire ou Oracle Transparent Data Encryption, dans votre groupe d'options, les mêmes options persistantes ou permanentes doivent être incluses dans le nouveau groupe d'options personnalisées. Pour mettre à niveau la version du fichier de fuseau horaire vers la dernière version disponible dans l'instance de base de données en même temps que la mise à niveau de votre version majeure, ajoutez l'option TIMEZONE_FILE_AUTOUPGRADE au nouveau groupe d'options personnalisées.

Statistiques de dictionnaire : la collecte des statistiques de dictionnaire et d'objets fixes peut réduire le temps d'arrêt de l'instance pendant la mise à niveau. Vous pouvez collecter les statistiques en exécutant les requêtes suivantes :

SQL> EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;
SQL> EXEC DBMS_STATS.GATHER_FIXED_OBJECTS_STATS;

Objets non valides : vérifiez et assurez-vous que votre base de données ne contient pas d'objets non valides. Pour ce faire, exécutez la requête suivante :

SQL> SELECT OWNER, STATUS, COUNT (*) FROM DBA_OBJECTS GROUP BY OWNER, STATUS;

Si des objets non valides sont trouvés, vérifiez quel objet n'est pas valide en exécutant la requête suivante :

SQL> SELECT OWNER, OBJECT_NAME, OBJECT_TYPE FROM DBA_OBJECTS WHERE STATUS != 'VALID';

Vous pouvez compiler tous les objets non valides du schéma en exécutant la requête suivante :

SQL> EXEC DBMS_UTILITY.compile_schema(schema => 'ADMIN', compile_all => false);

N'oubliez pas de remplacer ADMIN dans la requête par le nom de votre schéma.

Journaux d'activité d'audit : assurez-vous que les journaux d'activité d'audit ne sont pas longs. Les vérifications préalables à la mise à niveau et les mises à niveau peuvent prendre plus de temps avec de longs journaux d'activité d'audit. Pour tronquer des journaux d'activité d'audit, consultez Comment tronquer la table sys.aud$ sur mon instance de base de données Amazon RDS qui exécute Oracle ? Vous pouvez également utiliser la procédure DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL pour supprimer les journaux d'activité d'audit.

Mots de passe : vérifiez que vous n'utilisez pas une ancienne version des mots de passe en exécutant la requête suivante :

SQL> SELECT USERNAME,PASSWORD_VERSIONS FROM DBA_USERS;

À partir des résultats de la requête, si vous constatez qu'un utilisateur utilise uniquement la version 10g des mots de passe, vérifiez si l'utilisateur peut être recréé avec une version plus récente du mot de passe. Si vous ne parvenez pas à corriger la version du mot de passe utilisateur, définissez le paramètre SQLNET.ALLOWED_LOGON_VERSION_SERVER de manière appropriée pour éviter les erreurs de connexion.

Lorsque le paramètre sqlnetora.sqlnet.allowed_logon_version_server est défini dans une instance RDS for Oracle, le paramètre indique la version minimale du protocole d'authentification autorisée lors de la connexion au serveur de base de données. Un paramètre de 8 autorise la plupart des versions de mots de passe ainsi que toute combinaison des valeurs DBA_USERS.PASSWORD_VERSIONS 10G, 11G et 12C.

Lorsque le paramètre sqlnetora.sqlnet.allowed_logon_version_client est défini dans une instance RDS for Oracle, le paramètre indique le protocole d'authentification minimum à utiliser lorsque la base de données fait office de client.

Pour plus d'informations, consultez la documentation Oracle relative à la vérification des comptes à l'aide d'une version de mot de passe insensible à la casse.

DBMS_JOB : le package DBMS_JOB est interrompu avec la mise à niveau de la base de données Oracle 12c version 2. Si vous effectuez une mise à niveau vers la version 19c, il est recommandé de convertir toutes les tâches DBMS_JOB en tâches DBMS_SCHEDULER avant la mise à niveau. Au cours de la mise à niveau, Oracle convertit les tâches DBMS_JOB en tâches DBMS_SCHEDULER. Pour plus d'informations, reportez-vous à la documentation Oracle relative à la prise en charge de DBMS_JOB. Si vous disposez d'un grand nombre d'entrées DBMS_JOB, la mise à niveau peut prendre plus de temps.

FreeStorageSpace : vérifiez que votre instance n'est pas proche de sa capacité de stockage. Assurez-vous que vous disposez de suffisamment d'espace de stockage disponible pour que la mise à niveau se termine correctement, en vérifiant la métrique CloudWatch FreeStorageSpace. Pour en savoir plus, consultez Comment puis-je créer des alarmes CloudWatch pour surveiller l'espace de stockage Amazon RDS libre et éviter les problèmes de saturation de l'espace de stockage ?

Actions de maintenance : vérifiez si votre instance comporte des actions de maintenance en attente dans la console Amazon RDS. Ces actions sont appliquées pendant la fenêtre de mise à niveau. Pour les instances multi-AZ, si aucune mise à jour du système d'exploitation n'est requise, les mises à niveau principale et de secours sont effectuées en même temps. Si des mises à jour du système d'exploitation sont nécessaires, Amazon RDS applique la mise à niveau comme indiqué dans la section Mises à niveau Oracle dans un déploiement multi-AZ.

Instantané manuel : créez un instantané manuel de votre instance de base de données RDS for Oracle pour les raisons suivantes :

  • L'instantané peut être utilisé pour revenir à la version précédente, à condition que la version soit prise en charge par Amazon RDS.
  • Un instantané automatisé est généralement créé dans le cadre du processus de mise à niveau de la version majeure. Comme les instantanés Amazon Elastic Block Store (Amazon EBS) sont progressifs, le nouvel instantané comporte moins de modifications à sauvegarder. Par conséquent, la création d'un instantané manuel peut réduire le temps nécessaire à la création de l'instantané automatisé ainsi que le temps total consacré à la mise à niveau.

Configuration actuelle : exécutez la requête suivante pour afficher la configuration actuelle de votre instance et enregistrer la sortie. La sortie vous fournit des informations sur le groupe d'options, le groupe de paramètres, les groupes de sécurité et les identifications qui sont attachés à l'instance RDS for Oracle actuelle. Pour revenir en arrière et effectuer une restauration à partir d'un instantané ou effectuer une restauration à un instant dans le passé, utilisez les informations que vous récupérez à partir de cette commande :

> aws rds describe-db-instances --db-instance-identifier example-instance-name --region example-region

Assurez-vous de remplacer les valeurs suivantes dans la requête :

  • example-instance-name par le nom de votre instance RDS for Oracle.
  • example-region par la région de votre choix.

Undo tablespace : assurez-vous que votre paramètre Undo tablespace est défini à la bonne taille pour éviter les opérations de redimensionnement pendant la mise à niveau.

Déclencheurs : exécutez la requête suivante pour répertorier vos déclencheurs d'ouverture de session, de fermeture de session et de démarrage –

SQL> SELECT OWNER, TRIGGER_NAME, TRIGGER_TYPE, TRIGGERING_EVENT, TABLE_OWNER, STATUS, ACTION_TYPE, TRIGGER_BODY FROM DBA_TRIGGERS WHERE TRIGGERING_EVENT LIKE '%LOGO%' or TRIGGERING_EVENT LIKE '%STARTUP%';

Vérifiez si les déclencheurs sont valides et fonctionnels. Bien que le déclencheur soit valide et se compile correctement, il peut générer une erreur lors de l'exécution et interférer avec les redémarrages de la base de données. Vérifiez s'il existe des déclencheurs d'ouverture de session, de fermeture de session ou de démarrage qui renvoient une erreur lors de leur exécution. Vous pouvez désactiver ces déclencheurs en exécutant les requêtes suivantes :

SQL> ALTER TRIGGER EXAMPLE-OWNER.EXAMPLE-TRIGGER DISABLE;

Assurez-vous de remplacer les valeurs suivantes dans la requête :

  • EXAMPLE-OWNER par le nom du schéma dans lequel vous avez créé le déclencheur.
  • EXAMPLE-TRIGGER par le nom du déclencheur.

Par exemple :

--To disable AUDIT_USERS trigger in MYADMIN schema
SQL> ALTER TRIGGER MYADMIN.AUDIT_USERS DISABLE;

Pendant la mise à niveau

Une fois la mise à niveau lancée, vous pouvez en suivre la progression en vérifiant les points suivants dans la console Amazon RDS :

  • Journal des alertes situé sous l'onglet Logs & events (Journaux et évènements) de votre instance
  • Section Recent events (Évènements récents) situés sous l'onglet Logs & events (Journaux et évènements) de votre instance

Après la mise à niveau

  • Exécutez les requêtes suivantes pour vérifier la version du correctif après la connexion à la base de données :
SQL> SELECT * FROM sys.registry$history;
SQL> SELECT INSTALL_ID,PATCH_ID,ACTION,STATUS,ACTION_TIME,DESCRIPTION FROM DBA_REGISTRY_SQLPATCH;
  • Amazon RDS met à jour les fichiers lsinventory-dbv.txt dans l'heure suivant l'application du correctif. Vous pouvez télécharger ce fichier depuis l'onglet Logs & events (Journaux et évènements) de votre instance dans la console Amazon RDS. Vérifiez les correctifs appliqués en lisant le fichier Isinventory-dbv.txt.
  • Exécutez les requêtes suivantes pour collecter les statistiques du dictionnaire et d'objets fixes :
SQL> EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;
SQL> EXEC DBMS_STATS.GATHER_FIXED_OBJECTS_STATS;
  • Exécutez la requête suivante pour vérifier que le nombre d'objets valides et non valides correspond à ceux d'avant la mise à niveau :
SQL> SELECT OWNER, STATUS, COUNT(*) from DBA_OBJECTS GROUP BY OWNER, STATUS;
  • Exécutez la requête suivante pour compiler tous les objets non valides du schéma :
SQL> EXEC DBMS_UTILITY.compile_schema(schema => 'ADMIN', compile_all => false);
  • Si vous rencontrez des problèmes de performances de requête après la mise à niveau en raison des fonctions d'optimiseur de la nouvelle version majeure, envisagez d'utiliser le paramètre OPTIMIZER_FEATURES_ENABLE. Vous pouvez modifier ce paramètre au niveau de la session et du système. Par exemple, si vous mettez à niveau votre base de données de la version 18.1 vers la version 19.1, mais que vous souhaitez conserver le comportement de l'optimiseur de la version 18.1, vous pouvez le faire en définissant la valeur du paramètre OPTIMIZER_FEATURES_ENABLE sur 18.1.0.

Cet article vous a-t-il été utile ?


Besoin d'aide pour une question technique ou de facturation ?