Documentation Oracle Cloud Infrastructure

Configuration client pour la disponibilité continue sur Autonomous Database

Vous n'avez pas besoin de redémarrer les applications pour les activités de maintenance planifiées lorsque vous activez la continuité des applications et que vous suivez les meilleures pratiques de codage.

Rubrique parent : Utilisation de la continuité d'application sur Autonomous Database

Connexion à l'aide des services de base de données avec continuité des applications activée

Les services de base de données Oracle assurent la transparence de l'infrastructure Autonomous Database sous-jacente.

Les opérations de haute disponibilité et de continuité des applications sont basées sur l'utilisation des services de connexion Autonomous Database. Pour assurer la continuité des applications, utilisez un service de base de données lors de la connexion à la base de données.

Les noms des services de base de données prédéfinis sur Autonomous Database sont différents, selon votre charge globale, comme décrit dans Noms de service de base de données pour Autonomous Database.

Utiliser les pratiques recommandées pour la purge

Sur Autonomous Database, il n'est jamais nécessaire de redémarrer les serveurs d'applications lorsque la maintenance planifiée suit les meilleures pratiques.

Pour la maintenance planifiée, l'approche recommandée consiste à prévoir du temps pour que le travail en cours se termine avant le démarrage de la maintenance. Sur Autonomous Database, cela se produit automatiquement et le travail est purgé avant de commencer les activités de maintenance lorsque vous suivez les instructions suivantes :

  • FAN avec pools de connexions Oracle ou pilotes Oracle
  • Tests de connexion

Utilisez la purge en combinaison avec la solution de basculement choisie pour les demandes qui ne se terminent pas dans le délai alloué pour la purge. Votre solution de basculement tentera de récupérer les sessions qui n'ont pas été purgées dans le temps alloué.

Renvoyez les connexions vers le pool de connexion

L'application doit renvoyer la connexion au pool de connexions à chaque demande. Il est recommandé que les applications extraient les connexions uniquement pour la période sur laquelle elles ont besoin. Le maintien d'une connexion au lieu de la renvoyer au pool n'a pas d'effet. Par conséquent, une application doit extraire une connexion, puis enregistrer cette connexion immédiatement le travail est terminé. Les connexions sont alors disponibles pour une utilisation ultérieure par d'autres threads, ou votre thread si nécessaire à nouveau. Le renvoi de connexions à un pool de connexions est une recommandation générale, que vous utilisiez la fonction FAN pour la purge ou que vous effectuiez des tests de connexion pour la purge.

Utiliser un pool de connexions Oracle

A l'aide d'un pool de connexions FAN, il est recommandé d'utiliser le pool de connexions Oracle pour masquer les opérations de maintenance planifiées. Au fur et à mesure que la maintenance progresse et se termine, les sessions sont déplacées et rééquilibrées. L'impact est nul sur les utilisateurs lorsque l'application emploie un pool Oracle avec la fonction FAN et renvoie les connexions au pool entre les demandes. Les pools Oracle pris en charge incluent les fournisseurs UCP, WebLogic GridLink, Tuxedo, OCI Session Pool et ODP.NET Managed and Unmanaged. Aucune modification d'application n'est nécessaire pour utiliser la fonction FAN autre que de vous assurer que vos connexions sont renvoyées au pool entre les demandes.

Utilisation d'UCP avec un pool de connexions tiers

Si vous utilisez un serveur d'applications tiers basé sur Java, la méthode la plus efficace pour réaliser l'opération de purge et de basculement consiste à remplacer la source d'informations en pool en UCP. Cette approche est prise en charge par de nombreux serveurs d'applications, notamment Oracle WebLogic Server, IBM WebSphere, IBM Liberty, Apache Tomcat, Red Hat WildFly (JBoss), Spring, Hibernate, etc.

Utiliser les tests de connexion

Si vous ne pouvez pas utiliser un pool Oracle avec la fonction FAN, la session est purgée par Autonomous Database ou les pilotes client fournis. Lorsque des services sont déplacés ou arrêtés pendant la maintenance, ou qu'une permutation vers un site de secours utilise Autonomous Data Guard, les pilotes client Oracle Database et Oracle recherchent des emplacements sécurisés pour la libération des connexions, conformément aux règles suivantes :

  • Tests de connexion standard pour la validité de la connexion lors de l'emprunt ou du retour à partir d'un pool de connexions
  • Tests SQL personnalisés pour la validité de la connexion
  • Les limites de demande sont en vigueur et la demande en cours est terminée

Utilisation de tests de connexion avec Autonomous Database

Vous pouvez ajouter, supprimer, activer ou désactiver des tests de connexion pour Autonomous Database.

Utilisez la vue DBA_CONNECTION_TESTS pour afficher les tests de connexion disponibles.

Par exemple :

SQL> EXECUTE 
   dbms_app_cont_admin.add_sql_connection_test('SELECT COUNT(1) FROM DUAL');
SQL> EXECUTE 
   dbms_app_cont_admin.enable_connection_test(dbms_app_cont_admin.sql_test, 
                                             'SELECT COUNT(1) FROM DUAL');
SQL> SELECT * FROM DBA_CONNECTION_TESTS;

Configurez le test de connexion activé dans la base de données au niveau du pool de connexions ou du serveur d'applications. Configurez également le vidage et la destruction du pool en cas d'échec du test de connexion sur au moins deux fois la taille maximale du pool ou MAXINT.

Utiliser des tests de connexion avec un pilote Java léger

Si vous souhaitez utiliser des tests de connexion locaux pour le pilote et que vous ne pouvez pas utiliser la prise en charge complète de la fonction FAN d'UCP :

  • Activer validate-on-borrow=true
  • Définissez les propriétés système Java :
    • -Doracle.jdbc.fanEnabled=true
    • -Doracle.jdbc.defaultConnectionValidation=SOCKET

Ensuite, utilisez l'un des tests suivants :

  • java.sql.Connection.isValid(int timeout)
  • oracle.jdbc.OracleConnection.pingDatabase()
  • oracle.jdbc.OracleConnection.pingDatabase(int timeout)
  • Une valeur HINT au début de l'instruction SQL de test :
    • /*+ CLIENT_CONNECTION_VALIDATION */

Utiliser des tests de connexion avec le pilote OCI

Si vous souhaitez utiliser le pilote OCI directement, utilisez OCI_ATTR_SERVER_STATUS. Il s'agit de la seule méthode qui modifie le code. Dans votre code, vérifiez le gestionnaire du serveur lors de l'emprunt et du renvoi des connexions pour voir si la session est déconnectée. Pendant la maintenance, la valeur de OCI_ATTR_SERVER_STATUS est définie sur OCI_SERVER_NOT_CONNECTED. Lors de l'utilisation du pool de sessions OCI, cette vérification de connexion est effectuée pour vous.

L'exemple de code suivant montre comment utiliser OCI_ATTR_SERVER_STATUS : 

ub4 serverStatus = 0OCIAttrGet((dvoid *)srvhp,
          OCI_HTYPE_SERVER,             
        (dvoid *)&serverStatus, (ub4 *)0, OCI_ATTR_SERVER_STATUS,
      errhp);if (serverStatus ==
        OCI_SERVER_NORMAL)printf("Connection is
        up.\n");else if (serverStatus ==
        OCI_SERVER_NOT_CONNECTED) printf("Connection is down.\n");

Etapes d'utilisation de la continuité d'application

Pour utiliser la continuité des applications, procédez comme suit :

  • Vous devez au préalable activer et configurer la continuité des applications ou la continuité transparente des applications (TAC) pour votre service de base de données sur Autonomous Database. Pour plus d'informations, reportez-vous à Configuration de la continuité des applications sur Autonomous Database.

  • Oracle vous recommande vivement d'utiliser les pilotes client les plus récents. Les pilotes client Oracle Database 19c et ultérieurs fournissent une prise en charge complète de la continuité des applications (AC) et de la continuité des applications transparente (TAC). Utilisez l'un des pilotes de client pris en charge suivants :

    • Pilote de réexécution Oracle JDBC 19c ou version ultérieure. Il s'agit d'une fonctionnalité de pilote JDBC fournie avec Oracle Database 19c pour la continuité d'application

    • Oracle Universal Connection Pool (UCP) 19c ou versions ultérieures avec pilote de réexécution Oracle JDBC 19c ou versions ultérieures

    • Oracle Weblogic Server 12c avec Active GridLink ou serveurs d'applications JDBC tiers utilisant UCP avec pilote de réexécution Oracle JDBC 19c ou version ultérieure.

    • Pools de connexions Java ou applications Java autonomes utilisant le pilote de réexécution Oracle JDBC 19c ou version ultérieure

    • Pool de sessions d'Oracle Call Interface 19c ou version ultérieure.SQL*Plus 19c (19.8) ou version ultérieure

    • ODP.NET en pool, pilote non géré 19c ou version ultérieure ("Pooling=true" par défaut dans les version 12.2 et ultérieures)

    • Applications basées sur Oracle Call Interface utilisant le pilote OCI 19c ou version ultérieure

Renvoyez les connexions vers le pool de connexion

L'application doit renvoyer la connexion au pool de connexions Oracle à chaque demande. Les meilleures pratiques d'utilisation des applications sont d'extraire les connexions (d'emprunter) au moment où elles sont nécessaires, puis de les réinsérer dans le pool lorsque l'action en cours est terminée. Ceci est important pour les meilleures performances des applications lors de l'exécution, pour le rééquilibrage des tâches lors de l'exécution et lors des événements de maintenance et de basculement. Cette pratique est également importante pour le drainage.

Lors de l'utilisation d'un pool de connexions Oracle, tel qu'UCP (Universal Connection Pool) ou OCI Session Pool, ou ODP.Net Unmanaged Provider ou lors de l'utilisation d'WebLogic Active GridLink, cet exercice intègre les limites de demande que la continuité des applications utilise pour identifier les emplacements sécurisés pour reprendre et terminer la capture. Cette option est requise pour la continuité des applications et recommandée pour la continuité transparente des applications.

En outre, la continuité transparente des applications repère les limites des demandes si un pool n'est pas utilisé ou si la réexécution est désactivée. Les conditions de découverte d'une limite sont les suivantes :

  • Aucune transaction ouverte
  • Les curseurs sont renvoyés dans le cache d'instructions ou annulés.
  • Aucun état de session non restaurable n'existe (reportez-vous à Etat de session propre entre les demandes dans ce document)

Activation des mutables utilisés dans l'application

Les fonctions mutables sont des fonctions qui peuvent renvoyer une nouvelle valeur à chaque exécution. Pour conserver les résultats d'origine des fonctions mutables, la prise en charge est assurée pour SYSDATE, SYSTIMESTAMP, SYS_GUID et sequence.NEXTVAL. Si les valeurs d'origine ne sont pas conservées et que des valeurs différentes sont renvoyées à l'application lors de la réexécution, la réexécution est rejetée.

Si vous avez besoin de mutables pour PL/SQL, exécutez GRANT KEEP selon vos besoins.

Par exemple :

SQL> GRANT KEEP DATE TIME to adb_user;
SQL> GRANT KEEP SYSGUID to adb_user;
SQL> GRANT KEEP SEQUENCE mySequence to adb_user on mysequence.myobject;

Effets secondaires

Lorsqu'une demande de base de données inclut un appel externe tel que l'envoi de MAIL ou le transfert d'un fichier, cela est appelé un effet secondaire.

Les effets secondaires sont des actions externes, ils ne sont pas annulés. Lors de la réexécution, vous pouvez décider si les effets secondaires doivent être réexécutés. De nombreuses applications choisissent de répéter les effets secondaires tels que les écritures de journal et l'envoi de courrier en tant qu'exécutions en double ne causent aucun problème. Pour la continuité des applications, les effets secondaires sont réexécutés, sauf si la demande ou l'appel utilisateur est explicitement désactivé pour la réexécution. Inversement, comme la continuité d'application transparente est activée par défaut, TAC ne réexécute pas les effets secondaires. La capture est désactivée et réactivée à la prochaine limite implicite créée par TAC.

Meilleures pratiques des développeurs en matière de disponibilité continue

Suivez ces bonnes pratiques pour coder en vue d'une disponibilité continue sur Autonomous Database.

Renvoyez les connexions vers le pool de connexion

La pratique la plus importante du développeur consiste à renvoyer les connexions au pool de connexions à la fin de chaque demande. Ceci est important pour les meilleures performances des applications lors de l'exécution, pour la purge du travail et pour le rééquilibrage du travail lors de l'exécution et pendant la maintenance, ainsi que pour la gestion des événements de basculement. Certaines applications ont une fausse idée que le maintien des connexions améliore les performances. Le maintien d'une connexion n'effectue ni n'évolue.

Nettoyer l'état de session entre les demandes

Il est recommandé de nettoyer l'état de session entre les demandes de base de données.

Lorsqu'une application renvoie une connexion au pool de connexions, les curseurs dont le statut est FETCH et l'état de session défini sur cette session restent en place, sauf si une action est entreprise pour les effacer. Si l'application définit l'état, il est recommandé de renvoyer les curseurs dans le cache d'instructions et d'effacer l'état de session associé à l'application afin d'éviter toute fuite lors des réutilisations ultérieures de cette session de base de données. Le nettoyage de l'état de la session permet à TAC de repérer les limites.

Pour nettoyer automatiquement l'état entre les demandes avec Oracle Database 23ai, définissez l'attribut de service RESET_STATE=LEVEL1. Cela évite les fuites d'état et l'extraction à partir des curseurs en utilisant ultérieurement le pool de connexions.

Si vous utilisez Oracle Database 19c, utilisez DBMS_SESSION.RESET_PACKAGE pour effacer les variables globales PL/SQL, utilisez TRUNCATE pour effacer les tables temporaires, SYS_CONTEXT.CLEAR_CONTEXT pour effacer le contexte et annuler les curseurs en les renvoyant dans le cache d'instructions.

Si votre application est sans conservation de statut, telle que REST, APEX, Microservice et la plupart des applications Web, il est recommandé d'utiliser RESET_STATE.

N'insérez pas d'instruction COMMIT dans PL/SQL et évitez d'exécuter COMMIT on Success et Autocommit

Il est recommandé d'utiliser une validation de niveau supérieur (OCOMMIT, COMMIT() ou OCITransCommit). Si votre application utilise COMMIT intégré dans PL/SQL, AUTOCOMMIT ou COMMIT ON SUCCESS, la récupération peut ne pas être possible suite à une panne ou à un dépassement de délai. Le code PL/SQL n'est pas réentrant. Une fois qu'une validation en PL/SQL a été exécutée, ce bloc PL/SQL ne peut pas être resoumis. Les applications doivent soit annuler la validation qui n'est pas saine car les données ont peut-être été lues, soit utiliser par lots une technique de point de reprise et de redémarrage. Lorsque vous utilisez AUTOCOMMIT ou COMMIT ON SUCCESS, la sortie est perdue.

Si votre application utilise une validation de niveau supérieur, il existe une prise en charge complète pour Transparent Application Continuity (TAC), Application Continuity (AC) et TAF Select Plus. Si votre application utilise COMMIT intégré dans PLSQL, AUTOCOMMIT ou COMMIT ON SUCCESS, il est possible qu'il ne soit pas possible de réexécuter l'appel lorsque l'appel incluant COMMIT n'a pas abouti.

Utiliser ORDER BY ou GROUP BY dans des requêtes

La continuité des applications garantit que l'application voit les mêmes données lors de la réexécution. Si les mêmes données ne peuvent pas être restaurées, la continuité des applications n'accepte pas la réexécution. Lorsqu'un élément SELECT utilise l'ordre ORDER BY ou GROUP BY est conservé. Dans Autonomous Database, l'optimiseur d'instructions utilise le plus souvent le même chemin d'accès, ce qui peut faciliter le même tri des résultats. La continuité des applications utilise également une clause AS OF pour renvoyer les mêmes résultats de requête que ceux pour lesquels AS OF est autorisé.

Remarques concernant SQL*Plus

SQL*Plus est souvent notre outil de test. Bien sûr, SQL*Plus ne reflète pas notre application réelle qui sera utilisée en production. Il est donc toujours préférable d'utiliser la suite de tests d'application réelle pour tester votre plan de basculement et mesurer votre protection. SQL*Plus n'est pas une application groupée et n'a donc pas de limites de demande explicites. Certaines applications utilisent SQL*Plus par exemple pour les rapports. Pour utiliser SQL*Plus avec le basculement, vérifiez les points suivants :

  1. La fonction FAN est toujours activée pour SQL*Plus. Utilisez la chaîne de connexion recommandée qui configure automatiquement les adresses ONS pour vous.

  2. Lorsque vous utilisez SQL*plus, la clé consiste à réduire les allers-retours vers la base de données : https://blogs.oracle.com/opal/sqlplus-12201-adds-new-performance-features

  3. SQL*Plus est pris en charge pour TAC à partir d'Oracle Database 19c. Pour de meilleurs résultats, définissez une grande taille de tableau. Par exemple (définissez arraysize 1000). Evitez d'activer la sortie du serveur car cela crée un état de session non restaurable.