Documentation Oracle Cloud Infrastructure

Configuration client pour la disponibilité continue sur Autonomous Database

Il n'est pas nécessaire de redémarrer les applications pour les activités de maintenance planifiée lorsque vous activez la continuité d'application 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é d'application 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é d'application 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 diffèrent en fonction de la charge globale, comme décrit dans Nom de service de base de données pour Autonomous Database.

Utilisation des pratiques recommandées qui prennent en charge la purge

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

Pour une maintenance planifiée, l'approche recommandée consiste à laisser assez de temps pour que le travail en cours soit terminé avant le démarrage de la maintenance. Sur Autonomous Database, cela se produit automatiquement et le travail est purgé avant le démarrage des activités de maintenance lorsque vous procédez comme suit :

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

Utilisez la purge en association avec la solution de basculement choisie pour les demandes qui ne sont pas terminées dans le temps alloué à la purge. Votre solution de basculement tente de récupérer les sessions qui n'ont pas été purgées dans le temps alloué.

Renvoyez les connexions vers le pool de connexions

L'application doit renvoyer la connexion au pool de connexions à chaque demande. Il est recommandé qu'une application extrait une connexion uniquement pour le temps nécessaire. Conserver une connexion au lieu de la renvoyer au pool ne fonctionne pas. Une application doit donc extraire une connexion, puis la réinsérer dès que le travail est terminé. Les connexions sont alors disponibles pour une utilisation ultérieure par d'autres threads, ou par votre thread si nécessaire. Le renvoi de connexions à un pool de connexions est une recommandation générale, que vous utilisiez la fonction FAN ou des tests de connexion pour la purge.

Utilisation d'un pool de connexions Oracle

Pour masquer une maintenance planifiée, il est recommandé d'utiliser un pool de connexions Oracle tenant compte de la fonction FAN. A la fin de la maintenance, 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 UCP, WebLogic GridLink, Tuxedo, le pool de sessions OCI et les fournisseurs gérés et non gérés ODP.NET. Aucune modification d'application n'est nécessaire pour utiliser la fonction FAN, mais assurez-vous 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 la purge et le basculement consiste à remplacer la source de données en pool par UCP. De nombreux serveurs d'applications prennent en charge cette approche, notamment Oracle WebLogic Server, IBM WebSphere, IBM Liberty, Apache Tomcat, Red Hat WildFly (JBoss), Spring, Hibernate, etc.

Utilisation des tests de connexion

Si vous ne pouvez pas utiliser un pool Oracle avec la fonction FAN, les pilotes client fournis ou Autonomous Database purgeront la session. Lorsque les services sont déplacés ou arrêtés pendant une maintenance, ou qu'il y a une commutation vers un site de secours à l'aide d'Autonomous Data Guard, les pilotes client Oracle Database et Oracle recherchent des emplacements sécurisés pour libérer des connexions, conformément aux règles suivantes :

  • Des tests de connexion standard pour la validité de la connexion lors d'un emprunt ou d'un retour à partir d'un pool de connexions
  • Des tests SQL personnalisés pour la validité de la connexion
  • Des limites appliquées et une demande en cours terminée

Utilisation des 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.

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 même test de connexion que celui activé dans la base de données sur le pool de connexions ou le serveur d'applications. Configurez également le vidage et la destruction du pool en cas d'échec du test de connexion sur deux fois la taille maximale du pool ou sur MAXINT.

Utilisation des tests de connexion avec le pilote Java léger

Si vous voulez utiliser des tests de connexion en local sur le pilote et que vous ne pouvez pas utiliser la prise en charge complète de la fonction FAN d'UCP, procédez comme suit :

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

Utilisez ensuite l'un des tests suivants :

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

Utilisation des tests de connexion avec le pilote OCI

Si vous voulez utiliser le pilote OCI directement, utilisez OCI_ATTR_SERVER_STATUS. C'est la seule méthode qui constitue une modification du code. Dans le code, vérifiez le descripteur de 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.

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

Effectuez ces étapes pour utiliser la continuité d'application :

  • En tant que prérequis, activez et configurez la continuité d'application ou la continuité d'application transparente pour votre service de base de données sur Autonomous Database. Reportez-vous à Configuration de la continuité d'application sur Autonomous Database pour plus d'informations.

  • Oracle vous recommande vivement d'utiliser les pilotes client les plus récents. Les pilotes client Oracle Database 19c et versions ultérieures fournissent une prise en charge complète de la continuité d'application et de la continuité d'application transparente. Utilisez l'un des pilotes 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 ultérieur avec pilote de réexécution Oracle JDBC 19c ou ultérieur

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

    • 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 Oracle Call Interface 19c ou supérieur. SQL*Plus 19c (19.8) ou supérieur

    • ODP.NET en pool, pilote non géré 19c ou version ultérieure ("Pooling=true" par défaut dans les versions 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 connexions

L'application doit renvoyer la connexion au pool de connexions Oracle à chaque demande. Les meilleures pratiques d'utilisation des applications consistent à extraire (emprunter) les connexions uniquement pour la durée nécessaire, puis à les enregistrer dans le pool une fois l'action en cours terminée. Ce point est important pour obtenir les meilleures performances d'exécution des applications, pour rééquilibrer le travail lors de l'exécution et de la maintenance, et lors d'événements de basculement. Cette pratique est également importante pour la purge.

Lors de l'utilisation d'un pool de connexions Oracle, comme Universal Connection Pool (UCP) ou un pool de sessions OCI, ou d'un fournisseur non géré ODP.Net, ou lors de l'utilisation de WebLogic Active GridLink, le respect de cette pratique intègre les limites de demande utilisées par la continuité d'application afin d'identifier les emplacements sécurisés pour la reprise et la fin de la capture. Ceci est requis pour la continuité d'application et recommandé pour la continuité d'application transparente.

De plus, la continuité d'application transparente détecte les limites de demande si un pool n'est pas en cours d'utilisation ou si la réexécution est désactivée. Les conditions de repérage d'une limite sont les suivantes :

  • Aucune transaction ouverte
  • Les curseurs sont renvoyés vers le cache d'instructions ou annulés.
  • Il n'existe aucun état de session ne pouvant être restauré (reportez-vous à Nettoyage de l'état de session entre les demandes dans ce guide)

Activez les mutables utilisés dans l'application.

Les fonctions mutables sont des fonctions qui peuvent renvoyer une nouvelle valeur à chaque exécution. La prise en charge de la conservation des résultats d'origine des fonctions mutables est prise en charge 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 fonctions mutuelles pour PL/SQL, exécutez GRANT KEEP si nécessaire.

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 d'un courriel ou le transfert d'un fichier, il s'agit d'un effet secondaire.

Les effets secondaires sont des actions externes, ils ne peuvent pas être annulés. Lors de la réexécution, vous pouvez choisir de réexécuter ou non les effets secondaires. De nombreuses applications choisissent de répéter les effets secondaires tels que des écritures comptables et l'envoi de courriels car les exécutions en double ne posent pas de problème. Pour la continuité d'application, 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. A l'inverse, étant donné que la continuité d'application transparente est activée par défaut, elle ne réexécute pas les effets secondaires. La capture est désactivée, puis réactivée lors de la création de limite implicite suivante par TAC.

Meilleures pratiques de développeur pour la disponibilité continue

Suivez ces meilleures pratiques de code pour la disponibilité continue sur Autonomous Database.

Renvoyez les connexions vers le pool de connexions

La pratique de développeur la plus importante est le renvoi des connexions au pool de connexions à la fin de chaque demande. Ce point est important pour obtenir des performances d'application optimales lors de l'exécution, pour purger le travail et le rééquilibrer lors de l'exécution et de la maintenance, et pour gérer les événements de basculement. Certaines applications pensent à tort que le maintien des connexions améliore les performances. Le maintien d'une connexion n'est ni performant ni évolutif.

Nettoyage de 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 ayant le statut FETCH et l'état de session défini sur cette session restent en place, sauf si une action est effectuée pour les effacer. Si votre application définit l'état, il est recommandé de renvoyer les curseurs vers le cache d'instructions et d'effacer l'état de session relatif à l'application afin d'éviter toute fuite lors de réutilisations ultérieures de cette session de base de données. Le nettoyage de l'état de session permet à la continuité d'application transparente 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. Vous éviterez ainsi les fuites d'état et l'extraction à partir des curseurs lors d'une utilisation ultérieure du pool de connexions.

If you are using Oracle Database 19c, use DBMS_SESSION.RESET_PACKAGE to clear PL/SQL global variables, use TRUNCATE to clear temporary tables, SYS_CONTEXT.CLEAR_CONTEXT to clear context and cancel your cursors by returning them to the statement cache.

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

Ne pas imbriquer COMMIT en PL/SQL et éviter de valider (COMMIT) en cas de succès et de validation automatique

Il est recommandé d'utiliser une validation de niveau supérieur (OCOMMIT, COMMIT() ou OCITransCommit). Si votre application utilise COMMIT imbriqué en PL/SQL, AUTOCOMMIT ou COMMIT ON SUCCESS, la récupération peut être impossible après une coupure ou un dépassement de délai. PL/SQL n'est pas réentrant. En PL/SQL, une fois qu'une validation est exécutée, le bloc PL/SQL ne peut pas être soumis à nouveau. Les applications doivent annuler la validation, ce qui n'est pas correct car les données peuvent avoir été lues, ou pour les batches, utiliser 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, la continuité d'application transparente, la continuité d'application et TAF Select Plus sont entièrement pris en charge. Si votre application utilise COMMIT imbriqué dans PLSQL, AUTOCOMMIT ou COMMIT ON SUCCESS, il est possible que la réexécution ne soit pas possible dans les cas où l'appel, y compris COMMIT, n'a pas abouti.

Utilisation de ORDER BY ou GROUP BY dans les requêtes

La continuité d'application fait en sorte que l'application voit les mêmes données lors de la lecture. Si les mêmes données ne peuvent pas être restaurées, la continuité d'application n'accepte pas la réexécution. Lorsque SELECT utilise ORDER BY ou GROUP BY, l'ordre est conservé. Dans Autonomous Database, l'optimiseur de requêtes utilise le plus souvent le même chemin d'accès, ce qui peut contribuer à maintenir les résultats dans le même ordre. La continuité d'application utilise également une clause AS OF pour renvoyer les résultats de requête là où AS OF est autorisé.

Points à prendre en compte pour SQL*Plus

SQL*Plus est l'outil de prédilection pour faire des essais. Comme SQL*Plus ne reflète pas l'application réelle qui sera utilisée en production, il est toujours préférable d'utiliser la suite de tests d'application réelle pour tester le plan de basculement et mesurer la protection. SQL*Plus n'est pas une application en pool 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, procédez comme suit :

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

  2. Lorsque vous utilisez SQL*plus, la clé permet de 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 la continuité d'application à 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 de serveur car cela crée un état de session pour lequel la restauration est impossible.