Affichage des informations de patch et de fenêtre de maintenance, définition du niveau de patch

Autonomous Database utilise des fenêtres de maintenance prédéfinies pour appliquer automatiquement des patches à votre base de données. Vous pouvez visualiser les informations de maintenance et de patch, ainsi que les détails de l'historique de maintenance d'Autonomous Database.

A propos de la maintenance programmée et de l'application de patches

Toutes les instances Autonomous Database sont automatiquement affectées à une fenêtre de maintenance et différentes instances peuvent avoir des fenêtres de maintenance différentes.

Autonomous Database utilise ces fenêtres de maintenance pour appliquer des patches à l'ensemble de la pile utilisée pour exécuter la base de données, y compris le logiciel de base de données, le dictionnaire de base de données, les systèmes d'exploitation, le stockage Exadata, les microprogrammes, etc.

Les patches incluent des correctifs de bogues, des correctifs de sécurité et de nouvelles fonctionnalités. Les correctifs de sécurité critiques sont toujours appliqués dès qu'ils sont disponibles. Les patches sont déployés de manière uniforme dans toutes les bases de données. Vous n'avez donc pas besoin de suivre les patches exceptionnels. Une fois le correctif d'un problème implémenté, par exemple dans une base de données, il est déployé sur toutes les instances Autonomous Database.

Tous les correctifs sont soumis à un processus de test et de validation rigoureux qui fait partie d'un pipeline d'intégration et de développement continus. Les correctifs sont validés en plusieurs étapes et environnements avant d'être déployés vers les bases de données Early Patch et Always Free, suivies des bases de données Regular Patch Level. Ce pipeline permet d'intercepter et de corriger les régressions avant le déploiement du patch sur toutes les bases de données. Dans le cas peu probable où l'application de patches introduit une régression, Oracle dispose de processus pour atténuer le problème, notamment les actions suivantes :

  • Annulation d'un sous-ensemble du patch ou de l'ensemble du patch.

  • Définir les paramètres de base de données pour désactiver le patch qui a introduit la régression.

  • Application d'un patch en ligne pour résoudre le problème sans temps d'arrêt ni interruption de connexion.

Détection automatique de régression pour Autonomous Database ⁇ fournit une gestion proactive des régressions et permet la détection, le diagnostic et l'atténuation automatisés des problèmes. ⁇ Cela peut réduire ou éliminer la nécessité pour vous d'enquêter manuellement sur les problèmes et les demandes de service de fichiers. ⁇ La détection automatique de régression surveille toutes les bases de données, à la fois les niveaux de patch précoce et régulier, mais il est particulièrement utile lorsque vous testez une charge de travail sur une base de données de niveau ⁇ Précédent ⁇ patch. ⁇ Si la détection automatique de régression détecte un problème et identifie une régression, elle signale automatiquement le problème avec des informations détaillées pour le diagnostiquer. Ce reporting automatisé, dans le cadre du cycle d'application de patches de distribution continue, permet à Oracle de limiter ou de résoudre le problème avant que les modifications n'atteignent les bases de données de production (normales bases de données de niveau patch). La détection automatique de régression peut ne pas être en mesure de trouver tous les problèmes ; dans les cas où vous voyez des problèmes vous-même, vous pouvez déposer une demande de service.

La détection automatique de régression comprend les éléments suivants :

  • Automatic Regression Detection surveille la base de données et, en cas d'incident, enregistre un bogue pour l'incident avec des informations de diagnostic détaillées extraites du référentiel AWR (Automatic Workload Repository).

  • Le système de reporting des incidents génère des notifications pour les équipes des opérations et du développement Oracle Cloud Infrastructure avec Oracle Automatic Incident Monitoring.

  • Les problèmes sont atténués en analysant les alertes de détection automatique de régression.

  • L'apprentissage et les améliorations sont faits à la détection automatique de régression sur une base continue.

La page Détails d'Autonomous Database affiche le champ Niveau de patch et le champ Prochaine maintenance qui inclut la date et l'heure de la fenêtre de maintenance à venir. La date est mise à jour automatiquement lorsque la prochaine fenêtre de maintenance est programmée. Le lien Afficher l'historique fournit des détails sur la maintenance passée. Le champ Composant cible affiche le composant à mettre à jour dans la fenêtre de maintenance suivante.

Description de l'image adb_patch_level.png
Description de l'illustration adb_patch_level.png

Lorsque Autonomous Data Guard est activé, la console affiche également des informations de maintenance pour une base de données de secours locale.

La zone Maintenance contient les informations suivantes :

Champ de maintenance Description

Niveau de patch

Affiche le niveau de patch de l'instance. Il existe deux options de niveau de patch : Normal et Précédent. Cliquez sur Modifier pour gérer les paramètres de niveau de patch.

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

Prochaine maintenance

Indique la période de la prochaine fenêtre de maintenance programmée. Cliquez sur Afficher l'historique pour afficher les détails de la maintenance passée.

Pour plus d'informations, voir Afficher l'historique des événements de maintenance.

Composant cible

Répertorie les composants cible de la fenêtre de maintenance à venir. Les valeurs possibles sont les suivantes :

  • Base de données : lorsque le patch s'applique au répertoire de base et aux exécutables de la base de données.

  • Dictionnaire : lorsque le patch s'applique au dictionnaire de données et à Oracle APEX.

  • Infrastructure : lorsque le patch s'applique au matériel Exadata ou à Grid Infrastructure.

Prochaine maintenance (homologue local)

Indique la période de la prochaine fenêtre de maintenance programmée pour une base de données de secours Autonomous Data Guard locale. Cliquez sur Afficher l'historique pour afficher les détails de la maintenance passée.

Composant cible (homologue local)

Répertorie les composants cible de la fenêtre de maintenance à venir sur Autonomous Data Guard. Les valeurs possibles sont les suivantes :

  • Base de données : lorsque le patch s'applique au répertoire de base et aux exécutables de la base de données.

  • Dictionnaire : lorsque le patch s'applique au dictionnaire de données et à Oracle APEX.

  • Infrastructure : lorsque le patch s'applique au matériel Exadata ou à Grid Infrastructure.

Contacts client

Lorsque des contacts client sont définis, Oracle envoie des notifications aux adresses électroniques indiquées pour les problèmes liés au service Autonomous Database.

Pour plus d'informations, reportez-vous à Affichage et gestion des contacts client pour des problèmes opérationnels et des annonces.

Remarques concernant la maintenance programmée et l'application de patches :

  • L'équipe chargée des opérations Autonomous Database n'accède jamais à vos données, sauf si vous accordez explicitement des droits d'accès via une demande de service pour une durée spécifiée.

  • Si la base de données est à l'état arrêté pendant la fenêtre de maintenance, les modifications de la base de données à partir du patch sont appliquées lorsque vous démarrez la base de données.

  • La base de données reste disponible pendant la fenêtre de maintenance. Les nouvelles connexions à la base de données réussiront toujours. Les connexions de base de données existantes peuvent être rapidement déconnectées, en fonction du composant auquel les patches sont appliqués. Toutefois, vous pouvez immédiatement vous reconnecter et continuer à utiliser la base de données :

    • Pour les patches de base de données, les connexions existantes peuvent être déconnectées si elles s'exécutent plus longtemps que la durée de purge après le démarrage de l'application de patches.

    • Pour les patches d'infrastructure, les connexions existantes peuvent être déconnectées si elles s'exécutent plus longtemps que la durée de purge après le démarrage de l'application de patches.

    • Pour les patches de dictionnaire, les connexions existantes peuvent être déconnectées si elles contiennent des verrous sur les objets de dictionnaire auxquels des patches sont appliqués. Sinon, les connexions existantes ne seront pas impactées. Par exemple, si votre application exécute une procédure dans le package DBMS_CLOUD pendant l'application de patches et que des patches doivent être appliqués au package, la session utilisant ce package peut être déconnectée.

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

  • Vous pouvez utiliser Oracle Cloud Infrastructure Events pour être informé du début et de la fin de la maintenance. Pour plus d'informations, reportez-vous à Evénements d'informations sur Autonomous Database.

  • Si vous souhaitez remplacer la fenêtre de maintenance affectée par une autre fenêtre de 2 heures le samedi ou le dimanche dans le fuseau horaire local de la région, enregistrez une demande de service auprès du support technique Oracle Cloud.

    Si vous souhaitez une période spécifique pour votre fenêtre de maintenance le samedi ou le dimanche dans le fuseau horaire local de la région, vous pouvez demander la période avec la même demande de service. Si vous demandez une période spécifique pour la fenêtre de maintenance, la modification ne peut être effectuée que si la période demandée est disponible pour la base de données.

  • Si le stockage alloué à votre base de données est de 384 To, vous pouvez choisir une fenêtre personnalisée de 2 heures en déposant une demande de service auprès du support technique Oracle Cloud (vous pouvez déposer une demande de service pour demander un jour et une période spécifiques le samedi ou le dimanche dans le fuseau horaire local de la région pour votre fenêtre de maintenance).

Reportez-vous à Test des charges globales par rapport à un patch à venir pour plus d'informations sur la capture d'une charge globale à partir d'une base de données de production et la réexécution de la charge globale sur un clone actualisable de niveau de patch précoce cible.

Reportez-vous à Objectif de niveau de service Zéro-régression pour plus de détails sur l'objectif de niveau de service Zéro-régression pour Autonomous Database.

Voir l'historique des événements de maintenance

Vous pouvez visualiser l'historique des événements de maintenance Autonomous Database pour obtenir des détails sur les événements de maintenance passés, tels que le titre, l'état, l'heure de début et l'heure d'arrêt.

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

  • Ouvrez la console d'Oracle Cloud Infrastructure en cliquant sur icône de navigation 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 base de données Autonomous Database dans les liens sous la colonne Nom d'affichage.

Pour afficher l'historique de maintenance, procédez comme suit :

  1. Sur la page Détails d'Autonomous Database, sous Prochaine maintenance, cliquez sur Afficher l'historique.
  2. La console Oracle Cloud Infrastructure affiche la page Historique de maintenance.
  3. (Facultatif) Utilisez le sélecteur Rechercher et filtrer pour filtrer les événements par état.

    Par exemple, si vous sélectionnez Succès, la page Historique de maintenance affiche uniquement les événements de maintenance dont l'état est Succès.

La page Historique de maintenance affiche les détails de chaque événement de maintenance, notamment :
Champ Description

Titre

Nom de l'événement de maintenance.

Type de maintenance

Planifié ou imprévu.

Composant cible

Type de la ressource sur laquelle l'événement de maintenance se produit : base de données, dictionnaire ou infrastructure.

Département

Succès, Echec ou En cours.

Heure de début

Heure de début de la maintenance.

Heure de fin

Heure de fin de la maintenance.

Remarque

L'historique des événements de maintenance est disponible à partir des événements de maintenance postérieurs à février 2021.

Afficher les détails du niveau et du patch

Vous pouvez visualiser les informations sur les patches d'Autonomous Database, y compris la liste des composants et des problèmes résolus.

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 :

  1. Sélectionnez le patch Autonomous Database à afficher. La page Historique de maintenance de la console Oracle Cloud Infrastructure affiche la liste des patches sous la colonne Titre.
  2. Pour un patch sélectionné, recherchez des détails supplémentaires en interrogeant la vue DBA_CLOUD_PATCH_INFO.

    Par exemple, pour le patch ADBS-25.4.4.2, utilisez l'interrogation suivante :

    SELECT * FROM DBA_CLOUD_PATCH_INFO WHERE PATCH_VERSION = 'ADBS-25.4.4.2';
  3. Pour un problème intéressant, interrogez la vue afin d'obtenir des détails sur le problème :
    SELECT * FROM DBA_CLOUD_PATCH_INFO WHERE PATCH_VERSION = 'ADBS-25.4.4.2' and BUG_NUM = bug_number;

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

SELECT * FROM DBA_CLOUD_PATCH_INFO;

Remarques concernant l'affichage des informations de patch :

  • 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 de ADBS-21.7.1.1 (à partir de juillet 2021).

  • La vue DBA_CLOUD_PATCH_INFO comporte les colonnes suivantes :

    BUG_NUM, BUG_TITLE, COMPONENT_NAME, PATCH_VERSION

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

Définir le niveau de patch

Lorsque vous provisionnez ou clonez une instance Autonomous Database, vous pouvez sélectionner un niveau de patch à appliquer aux patches à venir. Vous pouvez également modifier le niveau de patch une fois qu'une instance Autonomous Database est provisionnée. Il existe deux options de niveau de patch : Normal et Précédent.

Lorsque vous sélectionnez le niveau de patch Début, les patches sont appliqués à l'instance Autonomous Database une semaine avant le patch programmé standard. Le champ Prochaine maintenance de la console Oracle Cloud Infrastructure reflète la date et l'heure de la 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 le niveau de patch 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 Précédent 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 Précédent pour vos bases de données de développement et de test si vous souhaitez tester les patches à venir avant que les patches 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 Early. Pour plus d'informations, reportez-vous à Test des charges globales avec Oracle Real Application Testing.

Remarque

La définition du niveau de patch n'est disponible que sur une instance Autonomous Database qui utilise le modèle de calcul ECPU.
Pour définir le niveau de patch lors du provisionnement ou du clonage d'une instance, procédez comme suit :

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

  1. Sur la page Détails d'Autonomous Database, sous Maintenance, 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 la version de base de données.
    • Si Autonomous Data Guard est activé pour votre base de données.
    • Si la base de données est au niveau des patches initiaux et qu'il n'est pas possible de la déplacer vers le niveau des patches standard. Dans ce cas, vous devez réessayer après la prochaine fenêtre de maintenance.
  2. Sélectionnez le niveau de patch Normal ou Précédent, 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.

Signaler des problèmes de patch au support technique Oracle

Lorsque vous signalez un problème pour une base de données de niveau patch Début, le support technique Oracle prend les mesures nécessaires pour empêcher le problème de se propager vers des bases de données de niveau patch Régulier. 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 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 standard de niveau patch.

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

Si vous rencontrez un problème pour générer un rapport, enregistrez une demande d'assistance sur le support technique d'Oracle Cloud ou contactez votre représentant du support.

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 à régression zéro.

Remarques concernant le 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 du patch standard.

  • Autonomous Data Guard est uniquement disponible pour les instances avec un niveau de patch Standard. Lorsque vous configurez une instance Autonomous Database avec un niveau de patch Early, vous ne pouvez pas activer Autonomous Data Guard.

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

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

Afficher les notifications de statut de maintenance

La vue DB_NOTIFICATIONS stocke des informations sur les notifications de statut de maintenance pour votre instance Autonomous Database.

Pour afficher les informations de notification :

  1. Connectez-vous à votre instance Autonomous Database.
  2. Utilisez la requête suivante pour afficher les informations de maintenance (application de patches).
    SELECT * FROM DB_NOTIFICATIONS WHERE TYPE = 'MAINTENANCE';

Les informations suivantes fournissent des détails sur les valeurs de 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 horodatages 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 horodatages de début et de fin attendus 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. La valeur MAINTENANCE_STATUS indique la valeur IN_PROGRESS et la valeur ACTUAL_START_DATE stocke l'horodatage de début.

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

Colonne Type de données Description
TYPE VARCHAR2(128)

Spécifie le type de notification.

La valeur valide est : MAINTENANCE.

TIME TIMESTAMP(6) WITH TIME ZONE

Heure à laquelle l'entrée de notification a été ajoutée.

EXPECTED_START_DATE TIMESTAMP(6) WITH TIME ZONE

Date et heure de début de maintenance programmées.

EXPECTED_END_DATE TIMESTAMP(6) WITH TIME ZONE

Date et heure de fin de maintenance programmées.

ACTUAL_START_DATE TIMESTAMP(6) WITH TIME ZONE

Heure réelle de début de maintenance.

ACTUAL_END_DATE TIMESTAMP(6) WITH TIME ZONE

Heure réelle de fin de maintenance.

MAINTENANCE_PRODUCT VARCHAR2(128)

Produit/composant pour lequel la maintenance est programmée/en cours.

MAINTENANCE_STATUS VARCHAR2(128)

Statut actuel de la maintenance.

DESCRIPTION VARCHAR2(128)

Détails du message de notification.

PATCH_ID VARCHAR2(128)

Version de patch.

Meilleures pratiques pour maintenir la disponibilité des applications pendant les fenêtres de maintenance

Fournit des informations sur les meilleures pratiques pour maintenir la disponibilité des applications et pour minimiser les perturbations des applications pendant une fenêtre de maintenance programmée.

Les patches Autonomous Database sont appliqués pendant une fenêtre de maintenance programmée en tant que patches non simultanés. A l'aide de patches non simultanés, votre instance Autonomous Database est disponible sur les nouveaux noeuds de cluster avant le démarrage de l'application de patches sur les noeuds d'origine sur lesquels elle était exécutée. Une fois la base de données disponible sur les nouveaux noeuds de cluster, toutes les nouvelles connexions sont dirigées vers les nouveaux noeuds. Cela signifie que la base de données reste en ligne et disponible pendant la maintenance et que les nouvelles demandes de connexion à la base de données réussiront pendant la fenêtre de maintenance.

Les connexions de base de données existantes sur les noeuds d'origine risquent d'être purgées pendant 5 minutesRéinitialisation 1. Pendant la période de purge, la base de données attend que le client libère les connexions existantes. Après la période de purge, s'il reste des connexions de base de données sur les noeuds d'origine, les connexions restantes sont déconnectées et l'application de patches démarre. Les meilleures pratiques suivantes peuvent vous aider à vous assurer que les connexions de base de données sont purgées pendant la période de purge et reconnectées aux nouveaux noeuds, afin que les applications ne voient pas d'interruptions pendant une fenêtre de maintenance.

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.

Pool de connexions Version Version du pilote Oracle JDBC Paramètres recommandés
Pool de connexions universel (UCP) 23ai 23ai Utilisez les paramètres par défaut.
Pool de connexions universel (UCP) 19.12 ou plus tard 19.13 ou plus tard ValidateConnectionOnBorrow=true

Ajoutez oracle.jdbc.defaultConnectionValidation=LOCAL aux propriétés de connexion du pilote JDBC.

Weblogic 14.1.1 ou plus tard 19.13 ou plus tard

test-connections-on reserve=true

test-table-name=SQL ISVALID

seconds-to-trust-an-idle-pool-connection=0

Appliquez le patch pour ce bug 35731335. Pour plus d'informations, reportez-vous à Patch 35731335.

Hikari 6.0.0 ou plus tard 19.21 ou plus tard

Définissez com.zaxxer.hikari.aliveBypassWindowMs sur -1.

Définissez oracle.jdbc.defaultConnectionValidation sur SOCKET dans vos propriétés JDBC.

Définissez com.zaxxer.hikari.enableRequestBoundaries sur true.

Tomcat 9.0, 10.0, ou 11.0 N'importe quelle version

Si vous utilisez Tomcat avec UCP, suivez les recommandations UCP ci-dessus.

Si vous utilisez Tomcat avec le pilote JDBC, appelez une API de purge JDBC Oracle : isValid(), isUsable(), pingDatabase() ou endRequest().

Définissez oracle.jdbc.defaultConnectionValidation sur SOCKET dans vos propriétés JDBC.

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.



Légende de la note de bas de page

Note de bas de page 1 : Notez que ce temps de vidange peut changer dans les versions futures.