Effectuez les étapes prérequises suivantes, le cas échéant :

• Ouvrez la console d'Oracle Cloud Infrastructure en cliquant sur en regard du nom cloud.

• Dans le menu de navigation de gauche d'Oracle Cloud Infrastructure, cliquez sur Oracle Database, puis sur Autonomous Database.

• Sur la page Bases de données autonomes, sélectionnez une instance Autonomous Database dans les liens sous la colonne Nom d'affichage.

Pour afficher l'historique des maintenances, procédez comme suit :

Affichage du niveau de patch pour une instance Autonomous Database

Sur la page de détails de la console Autonomous Database Oracle Cloud Infrastructure, vous pouvez visualiser le niveau de patch de l'instance.

1. Dans l'onglet Informations sur Autonomous Database, la zone Maintenance affiche le niveau de patch de l'instance. Les choix sont : régulier et précoce.
2. Pour modifier ce niveau, cliquez sur Modifier.

Pour plus d'informations, reportez-vous à Définition du niveau de patch.

La vue DBA_CLOUD_PATCH_INFO fournit des informations sur les patches liés aux bogues signalés (liste des bogues signalés par un client). Vous pouvez utiliser ces informations pour déterminer si un bug que vous avez signalé est résolu et pour déterminer la version du patch dans laquelle le correctif a été appliqué à votre instance Autonomous Database. S'il n'y avait aucun bogue client dans un patch, DBA_CLOUD_PATCH_INFO n'inclut aucune ligne pour ce patch.

Pour afficher les informations relatives à un patch spécifique, procédez comme suit :

Pour afficher les informations sur les patches disponibles, procédez comme suit :

SELECT * FROM DBA_CLOUD_PATCH_INFO;

Remarques relatives à l'affichage des informations sur les patches :

• La vue DBA_CLOUD_PATCH_INFO est disponible pour l'utilisateur ADMIN.

• Les informations sur les patches et les détails sur les problèmes résolus sont disponibles à partir du patch ADBS-21.7.1.1 (à partir de juillet 2021).

• La vue DBA_CLOUD_PATCH_INFO se compose des colonnes suivantes :

  BUG_NUM, BUG_TITLE, COMPONENT_NAME, PATCH_VERSION

Pour plus d'informations sur les patches appliqués lors de la maintenance, reportez-vous à Affichage des notifications de statut de maintenance.

Si vous sélectionnez le niveau de patch Anticipé, les patches sont appliqués à l'instance Autonomous Database une semaine avant la programmation de patch Normal. Le champ Next Maintenance de la console Oracle Cloud Infrastructure reflète la date et l'heure d'une fenêtre de maintenance en fonction du niveau de patch.

Le niveau de patch par défaut pour le provisionnement d'une instance Autonomous Database est Standard. Le niveau de patch par défaut pour le clonage est celui indiqué pour la base de données source.

Le provisionnement ou le clonage d'une instance et la définition du niveau de patch sur Anticipé vous permettent d'utiliser et de tester les patches à venir avant qu'ils ne soient appliqués à tous les systèmes. Oracle vous recommande de sélectionner le niveau de patch Anticipé pour vos bases de données de développement et de test si vous souhaitez tester les patches à venir avant qu'ils n'atteignent la production. Vous pouvez également tester vos charges globales à l'aide d'Oracle Real Application Testing pour capturer une charge globale sur un système de production et la réexécuter avec le niveau de patch Anticipé. Pour plus d'informations, reportez-vous à Test des charges globales avec Oracle Real Application Testing.

Pour modifier le niveau de patch d'une instance Autonomous Database existante, procédez comme suit :

1. Sur la page Détails de l'instance Autonomous Database, sous Gestion, dans le champ Niveau de patch, cliquez sur Modifier.
   Remarque
   
   Le bouton Modifier peut être désactivé dans les cas suivants :

   • Si le niveau de patch anticipé n'est pas disponible dans votre région pour votre version de base de données.
   • Si Autonomous Data Guard est activé pour votre base de données.
   • Si votre base de données est au niveau de patch anticipé et qu'il n'est pas possible de la déplacer vers le niveau de patch standard. Dans ce cas, réessayez après la fenêtre de maintenance suivante.
2. Sélectionnez le niveau de patch, Normal ou Anticipé, puis cliquez sur Soumettre.

   Le temps nécessaire pour modifier le niveau de patch dépend de la taille de la base de données. Vous pouvez voir de brèves coupures de connexion pendant cette période.

Signalement des problèmes de patch au support technique Oracle

Lorsque vous signalez un problème pour une base de données de niveau de patch Anticipé, le support technique Oracle prend les mesures nécessaires pour empêcher la propagation du problème vers des bases de données de niveau de patch standard. Voici quelques exemples d'actions possibles :

• Le patch à l'origine du problème est supprimé avant l'application des patches aux bases de données de niveau patch standard.

• Le patch à l'origine du problème est désactivé à l'aide des paramètres de base de données lorsqu'il est appliqué aux bases de données de niveau patch standard.

• L'application de patches aux bases de données de niveau patch standard est suspendue jusqu'à ce que des mesures correctives soient prises.

Si vous rencontrez un problème lors du rapport, enregistrez une demande de service auprès du assistance technique Oracle Cloud ou contactez un représentant du support technique.

Oracle fournit un objectif de niveau de service de zéro régression dans votre base de données de production. Pour plus d'informations, voir Objectif de niveau de service à progression zéro.

Remarques relatives au niveau d'application de patches :

• L'option permettant de définir le niveau de patch n'est pas disponible dans toutes les régions. Dans certaines régions, toutes les instances Autonomous Database sont provisionnées ou clonées au niveau de patch Standard.

• Autonomous Data Guard est disponible uniquement pour les instances avec le niveau de patch Normal. Lorsque vous configurez une instance Autonomous Database avec le niveau de patch Anticipé, vous ne pouvez pas activer Autonomous Data Guard.

• Les instances Autonomous Database Toujours gratuit ne fournissent pas l'option de niveau de patch Anticipé.

• Lorsque le niveau de patch d'une instance Autonomous Database source est Normal, dans les régions qui prennent en charge le niveau de patch Anticipé, vous pouvez définir le niveau de patch d'un clone sur Anticipé.

Pour afficher les informations sur les notifications, procédez comme suit :

Voici des détails sur les valeurs du champ DESCRIPTION.

• L'exécution de maintenance est terminée : indique que la maintenance est terminée. MAINTENANCE_STATUS affiche la valeur COMPLETED avec les heures de début et de fin de la maintenance terminée dans ACTUAL_START_DATE et ACTUAL_END_DATE.

• L'exécution de maintenance est programmée pour l'instance : indique qu'une nouvelle maintenance a été programmée. MAINTENANCE_STATUS affiche la valeur SCHEDULED avec les heures de début et de fin attendues pour la maintenance programmée dans EXPECTED_START_DATE et EXPECTED_END_DATE.

• L'exécution de maintenance a commencé : indique que la maintenance est en cours et fournit l'horodatage de début de la maintenance active. MAINTENANCE_STATUS affiche la valeur IN_PROGRESS et ACTUAL_START_DATE stocke l'horodatage de début.

Le tableau suivant présente les colonnes et les types de données de DB_NOTIFICATIONS.

Utilisation d'un pool de connexions et renvoi de connexions au pool

Il est recommandé d'utiliser un pool de connexions pour masquer la maintenance programmée de l'application. L'exécution d'une application pendant la fenêtre de maintenance n'a aucun impact sur une application lorsque l'application effectue les opérations suivantes :

• Utilise un pool de connexions avec les paramètres recommandés.
• Extrait une connexion du pool de connexions.
• Utilise la connexion pendant moins de temps de vidange (5 minutes).
• Renvoie la connexion au pool de connexions.

La meilleure pratique pour une application qui utilise un pool de connexions consiste à suivre ces étapes. L'application extrait une connexion, utilise la connexion pour le traitement de la base de données, puis libère la connexion au pool de connexions immédiatement lorsque le travail est terminé (ce qui rend la connexion disponible pour utilisation par d'autres threads).

Lorsque la période de purge démarre, le pool de connexions gère le rétablissement des connexions disponibles dans le pool de connexions afin que les nouvelles connexions se connectent aux nouveaux noeuds disponibles. Lorsqu'une application extrait une nouvelle connexion, elle ne voit aucune interruption (les nouvelles connexions utilisent les nouveaux noeuds). Toutefois, si une connexion est extraite avant le début de la maintenance ou pendant le temps de vidange et qu'elle effectue un traitement qui se poursuit pendant plus de temps de vidange, la connexion est déconnectée. Dans ce cas, pour éviter les interruptions, vous pouvez arrêter ces opérations longues avant le démarrage de la maintenance et les redémarrer à la fin de la maintenance. Pour savoir quand arrêter et quand redémarrer des opérations à longue durée d'exécution, vous pouvez vous abonner à des événements, comme expliqué dans la section suivante, "S'abonner à des événements d'information".

Le tableau suivant présente certains types de pool de connexions courants, ainsi que les versions et paramètres recommandés.

Utiliser des tests de connexion sur le pilote JDBC si vous ne pouvez pas utiliser un pool de connexions

Si vous ne pouvez pas utiliser un pool de connexions, les pilotes client Oracle 19.13 (ou version ultérieure) peuvent purger les connexions afin que votre application ne voie pas d'interruptions. Pour vous assurer que les connexions sont correctement purgées, vous pouvez appeler n'importe quelle API de purge JDBC Oracle : isValid(), isUsable(), pingDatabase() ou endRequest().

S'abonner aux événements d'information

Si votre application a des opérations de base de données à longue durée d'exécution qui s'exécutent pendant plus de 5 minutes, le pool ou le pilote JDBC ne peut pas purger les connexions, car elles ne seront pas libérées avant la fin du temps de purge. Pour les opérations à longue durée d'exécution, vous ne devez pas démarrer les processus et les travaux pendant ou juste avant une fenêtre de maintenance.

Autonomous Database publie des événements d'information dans le service OCI Events pour vous informer des fenêtres de maintenance, y compris les événements d'information suivants (avec la catégorie d'événement Maintenance) :

• Lorsqu'une nouvelle fenêtre de maintenance est programmée
• 24 heures avant le début de l'application de patches
• 60 minutes avant le début de l'application de patches
• Au démarrage de l'application de patches
• A la fin de l'application de patches

Vous pouvez vous abonner aux événements d'informations Autonomous Database, et éventuellement indiquer la maintenance de la catégorie d'événements, pour recevoir des notifications et limiter les notifications que vous recevez aux événements de maintenance. Ensuite, en fonction de la notification et des règles que vous définissez, vous pouvez prendre des mesures pour arrêter les opérations à longue durée d'exécution et les redémarrer après la fin de la maintenance. Même si les fenêtres de maintenance annoncées durent généralement 2 heures, l'application de patches se fait en 5 à 10 minutes pendant cette fenêtre. A l'aide de ces événements et de vos connaissances sur les opérations à longue durée d'exécution, vous pouvez déterminer quand arrêter les opérations à longue durée d'exécution et quand les redémarrer.

Pour plus d'informations, reportez-vous à Utilisation des événements Autonomous Database.

Gérer l'état d'une session PL/SQL si votre application utilise PL/SQL

Le paramètre de base de données SESSION_EXIT_ON_PACKAGE_STATE_ERROR indique la gestion d'un package PL/SQL avec conservation de statut exécuté dans une session. Lorsqu'un tel package est modifié, par exemple lors de la maintenance planifiée des objets fournis par Oracle, les sessions qui ont une instanciation active du package reçoivent l'erreur suivante lorsqu'elles tentent d'exécuter le package : ORA-04068: existing state of packages has been discarded.. Toutefois, le code d'application qui reçoit l'erreur ORA-4068 peut ne pas être équipé pour gérer cette erreur avec sa logique de nouvelle tentative.

La définition de SESSION_EXIT_ON_PACKAGE_STATE_ERROR sur TRUE offre un traitement différent pour ce cas. Lorsque SESSION_EXIT_ON_PACKAGE_STATE_ERROR est défini sur TRUE, au lieu de générer simplement l'erreur ORA-4068 lorsque l'état du package est supprimé, la session se ferme immédiatement. Cela peut être avantageux car de nombreuses applications peuvent gérer la terminaison de session en rétablissant automatiquement et de manière transparente la connexion.

Pour plus d'informations, reportez-vous à SESSION_EXIT_ON_PACKAGE_STATE_ERROR.