Code pour la disponibilité continue

Vos applications atteignent une disponibilité continue lorsque la maintenance planifiée, les coupures non planifiées et les déséquilibres de charge de la base de données sont masqués pour l'application. Par l'alliance entre meilleures pratiques pour les applications, configuration simple et Oracle Autonomous Database, vos applications sont disponibles en permanence.

Afin de dissimuler les activités de maintenance planifiées pour vos applications, la meilleure approche consiste à purger de manière transparente le travail de chaque emplacement de charge globale de base de données avant la fenêtre de maintenance de l'emplacement de charge globale. Les pools de connexions et les niveaux intermédiaires d'Oracle, y compris WebLogic Server, Oracle Universal Connection Pool (UCP), le pool de sessions OCI et le fournisseur non géré ODP.NET, tiennent compte de la fonction FAN (Fast Application Notification) et sont donc notifiés avant le déplacement programmé des services de base de données à des fins de purge progressive du travail avant la maintenance. La notification FAN déclenche automatiquement la fermeture des connexions inactives et l'ouverture de nouvelles connexions au nouvel emplacement de service, et accorde un délai configurable nécessaire à l'exécution du travail actif à l'emplacement de service sur le point d'être arrêté. Les principaux niveaux intermédiaires JDBC tiers, tels qu'IBM WebSphere, autorisent le même comportement lorsqu'ils sont configurés avec UCP. Pour les applications JDBC qui ne peuvent pas utiliser UCP, Oracle fournit des solutions à l'aide des pilotes Oracle et des tests de connexion.

Pour masquer les coupures non planifiées résultant d'un échec de composant ou de communication, Oracle propose les outils suivants :

  • Notification. La fonction FAN correspond à la première étape de dissimulation des coupures. La fonction FAN informe les clients et interrompt leur attente sur le réseau en cours lorsqu'une coupure survient. Vous évitez ainsi de bloquer les applications pendant de longues attentes réseau. Fait important : la fonction FAN appelle également le rééquilibrage des sessions lorsque les services sont à nouveau disponibles.

  • Récupération. Une fois le client averti, la continuité d'application transparente (TAC) ou la continuité d'application (AC) rétablit une connexion à un nouvel emplacement de charge globale (autre instance de base de données dans la configuration Real Application Clusters [RAC] exécutant la base de données) et réexécute le travail en attente (non validé) si possible. Grâce à la réexécution du travail en attente sur le nouvel emplacement, l'application peut généralement poursuivre son exécution sans savoir qu'une panne est survenue.

La continuité TAC ou AC est également active pendant la maintenance planifiée pour les sessions sans purge (qui effectuent l'opération de base de données en cours) pendant l'intervalle de purge alloué.

Rubriques connexes

Liste de contrôle de configuration d'application

Pour assurer la disponibilité continue de votre application, suivez les procédures ci-dessous :

Conseil :

Reportez-vous à Disponibilité continue des applications sur le livre blanc ATP-Direct pour en savoir plus sur les meilleures pratiques d'implémentation de la disponibilité continue des applications à l'aide d'une instance Autonomous Database.

Connexion à l'aide des services de base de données

Les services de base de données assurent la transparence pour l'infrastructure sous-jacente : la fonction FAN, les données de connexion, la continuité d'application transparente (TAC), la continuité d'application (AC), la permutation, les groupes de destinataires, ainsi que de nombreuses autres fonctionnalités et opérations sont basés sur l'utilisation des services.

Autonomous Database on Dedicated Exadata Infrastructure propose plusieurs paires de services de base de données prédéfinis à sélectionner, tel que décrit dans Nom de service de base de données prédéfinis pour les bases de données autonomes. Elles offrent toutes la fonction FAN et la purge, et la continuité TAC est activée par défaut pour les deux paires destinées au traitement des transactions. Une API est disponible pour modifier les paramètres TAC ou AC sur tous les services prédéfinis (reportez-vous à Activation des attributs de service pour le basculement en cas d'incident).

Configuration de la chaîne de connexion pour la haute disponibilité

Oracle recommande la configuration de chaîne de connexion présentée ci-dessous pour la connexion à Oracle Autonomous Database. Les chaînes de connexion imbriquées dans le fichier tnsnames.ora fourni par Oracle sont configurées de cette façon. N'utilisez pas la résolution de noms Easy Connect sur le client car ces connexions ne disposent pas de fonctions de haute disponibilité.

Utilisez le code TNS suivant pour tous les clients Oracle de version 12.2 ou supérieure :

alias = 
(DESCRIPTION =
(CONNECT_TIMEOUT= 120)(RETRY_COUNT=20)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3)
 (ADDRESS_LIST =
   (LOAD_BALANCE=on)
   (ADDRESS = (PROTOCOL = TCP)(HOST=scan-host)(PORT=1521)))
 (CONNECT_DATA=(SERVICE_NAME = service-name)))

Utilisez le code suivant pour les connexions JDBC utilisant le pilote Oracle version 12.1 ou antérieure :

alias =
(DESCRIPTION =
(CONNECT_TIMEOUT= 15)(RETRY_COUNT=20)(RETRY_DELAY=3)
(ADDRESS_LIST =
  (LOAD_BALANCE=on)
  (ADDRESS = (PROTOCOL = TCP)(HOST=scan-host)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME = service-name)))

Utilisation de la fonction Fast Application Notification (FAN)

La fonction FAN envoie une notification immédiate à une application en cas de coupure ou de reprise du service. Sans la fonction FAN, les applications peuvent dépendre entièrement du délai d'expiration TCP/IP suite à des pannes matérielles et réseau, et omettre le rééquilibrage à la reprise des ressources. Tous les pools Oracle et tous les serveurs d'applications Oracle utilisent la fonction FAN. Les serveurs d'applications Java tiers peuvent utiliser UCP pour activer la fonction FAN.

Aucune modification d'application n'est requise pour utiliser la fonction FAN. Il s'agit uniquement de modifications de configuration.

Pour assurer la continuité du service pendant la maintenance planifiée, utilisez la fonction FAN avec les éléments suivants, au choix :

  • Pools Oracle
  • UCP avec serveurs d'applications JDBC tiers
  • Pilotes client Oracle les plus récents

Pour assurer la continuité du service en cas de coupure non planifiée, utilisez la fonction FAN avec les éléments suivants, au choix :

  • Continuité d'application transparente
  • Continuité d'application

Portée de la fonction FAN

Les événements FAN sont intégrés aux éléments suivants :

  • Oracle Fusion Middleware et Oracle WebLogic Server
  • Broker Oracle Data Guard
  • Pilote Oracle JDBC ou Universal Connection Pool pour les interfaces JDBC Thin et Oracle Call Interface (OCI)
  • Pool de connexions ODP.NET pour les fournisseurs non gérés et gérés
  • Oracle Tuxedo
  • SQL*Plus
  • Pilotes Oracle Database pour les langages tels que Python, Node.js et PHP
  • Global Data Services
  • Serveurs d'applications JDBC tiers utilisant Oracle JDBC Universal Connection Pool
  • Processus d'écoute

Procédure d'activation de la fonction FAN dans le client

Utilisez l'alias TNS indiqué dans Configuration de la chaîne de connexion pour la haute disponibilité. Cette chaîne de connexion est utilisée pour configurer automatiquement l'abonnement ONS (Oracle Notification Service) sur client pour la réception des événements FAN lors de l'utilisation d'un pilote client Oracle Database 12c ou version ultérieure. ONS fournit un chemin de communication sécurisé entre le niveau base de données et le niveau client permettant au client d'être informé de la disponibilité du service (arrêt ou démarrage des composants), ainsi que des conseils sur l'équilibrage de charge lors de l'exécution afin d'améliorer le placement du travail pendant le fonctionnement normal.

Selon le client, activez la fonction FAN dans les propriétés de configuration d'application comme suit :

  • Universal Connection Pool ou pilote JDBC Thin (à partir de la version 12.2)

    Définissez la propriété FastConnectionFailoverEnabled.

  • WebLogic Active GridLink pour Oracle

    RAC FAN et Fast Connection Failover sont activés par défaut.

  • Oracle WebLogic Server, IBM WebSphere, IBM Liberty, Apache Tomcat, Red Hat WildFly (JBoss), applications JDBC

    Utilisez Universal Connection Pool comme pool de connexions de remplacement.

  • Clients ODP.Net (fournisseurs gérés et non gérés)

    Définissez "HA events = true;pooling=true" dans la chaîne de connexion si vous utilisez ODP.Net 12.1 ou version antérieure.

  • Clients Oracle Call Interface (OCI) et pilotes basés sur OCI

    Les clients Oracle Call Interface (OCI) sans paramètre natif peuvent utiliser un fichier oraacces.xml et définir events sur true.

    Python, Node.js et PHP comportent des options natives. Avec Python et Node.js, vous pouvez définir un mode d'événements lors de la création d'un pool de connexions. Avec PHP, modifiez php.ini et ajoutez l'entrée oci8.events=on.

  • SQL*Plus

    La fonction FAN est activée par défaut.

Les services de base de données prédéfinis offrent des connexions TCPS qui utilisent l'authentification basée sur un portefeuille TLS. Selon le type d'application (JDBC ou Oracle Call Interface), la configuration du portefeuille doit respecter des règles particulières, tel que décrit dans Configuration de clients pour la fonction FAN, y compris de portefeuilles facultatifs.

Utilisation des pratiques recommandées pour autoriser la purge

Les meilleures pratiques d'utilisation des applications consistent à extraire les connexions au moment où elles sont nécessaires, puis de les réinsérer dans le pool une fois l'action en cours terminée. Ce fonctionnement est important pour obtenir de bonnes performances, pour le rééquilibrage du travail lors de l'exécution et pour purger le travail pendant les fenêtres de maintenance.

Oracle recommande d'utiliser un pool de connexions Oracle tenant compte de la fonction FAN pour masquer la maintenance planifiée. 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. Vous n'avez pas besoin de modifier l'application pour utiliser la fonction FAN. Lorsqu'un pool de connexions Oracle reçoit l'événement FAN pour le temps d'inactivité planifié, il marque toutes les connexions de l'instance comme étant à purger. Immédiatement, les connexions réinsérées sont fermées afin de ne pas être réutilisées. A mesure que les connexions en cours d'utilisation sont renvoyées au pool, elles sont fermées. Cela permet de fermer progressivement toutes les connexions au fil du temps.

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. Les livres blancs Oracle et d'autres fournisseurs, tels qu'IBM, décrivent l'utilisation d'UCP avec ces serveurs d'applications. L'utilisation d'UCP en tant que source de données permet d'employer des fonctionnalités d'UCP telles que Fast Connection Failover, Runtime Load Balancing, la continuité d'application et la continuité d'application transparente avec une certification complète.

Activation de la continuité d'application transparente (TAC) ou de la continuité d'application (AC)

La continuité TAC assure le suivi et l'enregistrement transparents des sessions et de l'état transactionnel afin qu'une session de base de données puisse être récupérée suite à des coupures récupérables. Par défaut, la continuité TAC est activée pour les deux paires de services de base de données prédéfinis assurant le traitement des transactions.

La continuité AC est personnalisable, ce qui permet de choisir de réexécuter les effets secondaires ou d'ajouter des callbacks complexes lors du basculement, ce que la continuité TAC ne permet pas. Recourez à la continuité AC si vous utilisez des pilotes Oracle 12c (JDBC Thin ou Oracle Call Interface), si vous souhaitez une personnalisation avec effets secondaires ou callbacks, ou si vous disposez d'une application avec un état tel que les tables temporaires de durée de session et qui ne procède pas au nettoyage entre les demandes.

Etapes d'utilisation de la continuité d'application transparente

  • Si vous devez activer la continuité d'application transparente dans le service de base de données que vous utilisez, reportez-vous à Activation des attributs de service pour le basculement en cas d'incident.

  • Utilisez l'un des clients pris en charge suivants :

    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é TAC.

    • Pilote de réexécution Oracle JDBC 18c ou version ultérieure. Il s'agit d'une fonctionnalité de pilote JDBC fournie avec Oracle Database 18c pour la continuité d'application.
    • Oracle Universal Connection Pool (UCP) 18c ou version ultérieure avec pilote de réexécution Oracle JDBC 18c ou version ultérieure.
    • Oracle WebLogic Server Active GridLink ou serveurs d'applications JDBC tiers utilisant UCP avec pilote de réexécution Oracle JDBC 18c ou version ultérieure.
    • Pools de connexions Java ou applications Java autonomes utilisant le pilote de réexécution Oracle JDBC 18c ou version ultérieure.
    • Pool de sessions Oracle Call Interface 19c ou version ultérieure.
    • SQL*Plus 19c (19.3) ou version ultérieure.
    • ODP.NET en pool, pilote non géré 18c 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.

    Il n'est pas nécessaire d'apporter des modifications à votre application pour identifier les limites de demande si l'application utilise des connexions aux provenances suivantes :

    • Pools de connexions Oracle
    • Pilote de réexécution Oracle JDBC 18c ou version ultérieure
    • Applications basées sur Oracle Call Interface utilisant la version 19c ou une version ultérieure

    En cas d'utilisation de pools de connexions, l'application doit renvoyer la connexion vers le pool à la fin de chaque demande. Oracle recommande que les applications extraient les connexions uniquement pour la période sur laquelle elles en ont besoin. La rétention d'une connexion alors qu'elle n'est pas en cours d'utilisation ne fait pas partie des bonnes pratiques. La continuité d'application transparente avec les pilotes répertoriés détecte également les circonstances propices à l'ajout de limites et définit ses propres limites.

  • Utilisez FAILOVER_RESTORE.

    L'activation de la continuité d'application transparente restaure automatiquement les états de session prédéfinis. Si vous avez besoin d'états de session prédéfinis en complément à l'ensemble standard, vous pouvez inscrire un callback ou un libellé UCP pour restaurer ces états. Si vous avez besoin de restaurer des états de session complexes, tels que des tables temporaires ou SYS_CONTEXT, utilisez la continuité d'application, qui vous offre cette flexibilité.

  • Activez l'utilisation des fonctions mutables 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 est assurée pour SYSDATE, SYSTIMESTAMP, SYS_GUID et sequence.NEXTVAL. Les fonctions mutables de la continuité d'application dans les versions 19c et ultérieures sont automatiquement définies sur KEEP (conserver) pour SQL. Si votre application recourt ou est sensible aux fonctions mutables, un DBA doit émettre le privilège GRANT KEEP. Lorsque le privilège KEEP est accordé, la réexécution applique le résultat de la fonction d'origine. Exemple : 

    SQL> GRANT [KEEP DATE TIME | KEEP SYSGUID] … TO USER
    SQL> GRANT KEEP SEQUENCE mySequence TO myUser ON sequence.object

  • Les effets secondaires sont désactivés.

    Un effet secondaire est une action externe telle que l'envoi de courrier, le transfert de fichiers ou l'utilisation du protocole TCP. La continuité d'application transparente détecte les effets secondaires et ne les réexécute pas. Si vous souhaitez réexécuter les effets secondaires, utilisez la continuité d'application, qui offre cette flexibilité supplémentaire.

Procédure d'utilisation de la continuité d'application

  • Si vous devez activer la continuité d'application dans le service de base de données que vous utilisez, reportez-vous à Activation des attributs de service pour le basculement en cas d'incident.

  • Utilisez l'un des clients pris en charge suivants :

    • Pilote de réexécution Oracle JDBC 12c ou version ultérieure. Il s'agit d'une fonctionnalité de pilote JDBC fournie avec Oracle Database 12c pour la continuité d'application.
    • Oracle Universal Connection Pool (UCP) 12c ou version ultérieure avec pilote de réexécution Oracle JDBC 12c ou version ultérieure.
    • Oracle WebLogic Server Active GridLink et serveurs d'applications JDBC tiers utilisant UCP avec pilote de réexécution Oracle JDBC 12c ou version ultérieure.
    • Pools de connexions Java ou applications Java autonomes utilisant le pilote de réexécution Oracle JDBC 12c ou version ultérieure avec limites de demande ou source de données en pool.
    • Applications et pilotes de langage utilisant le pool de sessions Oracle Call Interface 12c version 2 ou ultérieure.
    • SQL*Plus 19.3 ou version ultérieure.
    • ODP.NET en pool, pilote non géré 12c version 2 ou ultérieure ("Pooling=true";"Application Continuity=true" par défaut dans les versions 12.2 et ultérieures).

  • Renvoyez les connexions vers le pool de connexions.

    Il n'est pas nécessaire d'apporter des modifications à votre application pour identifier les limites de demande si l'application utilise un pool de connexions Oracle ou un pool JDBC tiers prenant en charge les limites de demande. Les meilleures pratiques consistent à utiliser un pool Oracle et à renvoyer les connexions vers ce pool entre les demandes. Oracle recommande que les applications extraient les connexions uniquement pour la période sur laquelle elles en ont besoin. La rétention d'une connexion alors qu'elle n'est pas en cours d'utilisation ne fait pas partie des bonnes pratiques. Elle empêche une maintenance planifiée transparente.

  • Utilisez FAILOVER_RESTORE.

    La plupart des états courants sont restaurés automatiquement avec FAILOVER_RESTORE=LEVEL1. Si votre application prédéfinit des états de session en plus de l'ensemble standard, vous devez inscrire un callback ou un libellé UCP pour restaurer ces états. Définissez FAILOVER_RESTORE=LEVEL1 sur le service et utilisez l'un des éléments suivants :

    • Callback d'initialisation de connexion pour Java ou callback TAF (plus ancien) pour Oracle Call Interface
    • Libellé de connexion Universal Connection Pool ou WebLogic Server

  • Activez l'utilisation des fonctions mutables 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 est assurée pour SYSDATE, SYSTIMESTAMP, SYS_GUID et sequence.NEXTVAL. Les fonctions mutables de la continuité d'application dans les versions 19c et ultérieures sont automatiquement définies sur KEEP (conserver) pour SQL. Aucune action n'est donc requise. Si vous avez besoin de fonctions mutables pour PL/SQL, un DBA doit émettre le privilège GRANT KEEP. Lorsque le privilège KEEP est accordé, la réexécution applique le résultat de la fonction d'origine. Exemple : 

    SQL> GRANT [KEEP DATE TIME | KEEP SYSGUID] … TO USER
    SQL> GRANT KEEP SEQUENCE mySequence TO myUser ON sequence.object

  • Décidez de la réexécution des effets secondaires

    Un effet secondaire est une action externe telle que l'envoi de courrier, le transfert de fichiers ou l'utilisation du protocole TCP. Avec la continuité d'application, les effets secondaires sont réexécutés, sauf indication contraire de l'application. Si une demande comporte une action externe qui ne doit pas être réexécutée, cette demande peut utiliser une connexion pour laquelle la continuité d'application n'est pas activée, ou la réexécution peut être désactivée pour cette demande à l'aide de l'API disableReplay() pour Java ou OCIRequestDisableReplay() pour Oracle Call Interface. Si vous ne voulez pas réexécuter tous les effets secondaires, utilisez la continuité d'application transparente.