Documentation sur Oracle Cloud Infrastructure

Configuration de client pour la disponibilité continue dans une base de données d'intelligence artificielle autonome

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

Rubrique parent : Utiliser la continuité des applications dans une base de données d'intelligence artificielle autonome

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

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

Les opérations de haute disponibilité et de continuité des applications sont basées sur l'utilisation des services de connexion Autonomous AI 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 dans Autonomous AI Database sont différents, selon votre charge de travail, comme décrit dans Noms de service de base de données pour Autonomous AI Database.

Utiliser les pratiques recommandées pour soutenir le drainage

Dans Autonomous AI Database, il n'est jamais nécessaire de redémarrer les serveurs d'application lorsque la maintenance planifiée respecte les meilleures pratiques.

Pour la maintenance planifiée, il est recommandé de prévoir le temps nécessaire à l'achèvement du travail courant avant le démarrage de la maintenance. Dans Autonomous AI Database, cela se produit automatiquement et le travail est drainé avant le démarrage des activités de maintenance lorsque vous suivez ces directives :

  • Ventilateur dynamique avec réserves de connexions Oracle ou pilotes Oracle
  • Tests de connexion

Utilisez le drainage en combinaison avec la solution de basculement choisie pour les demandes qui ne se terminent pas dans le délai imparti pour le drainage. Votre solution de basculement tentera de récupérer les sessions qui ne se sont pas drainées dans le temps alloué.

Replacez les connexions dans la réserve de connexions

L'application doit renvoyer la connexion à la réserve de connexions à chaque demande. Il est recommandé qu'une application n'extrait une connexion que pour la durée nécessaire. Le maintien d'une connexion au lieu de la renvoyer à la réserve ne fonctionne pas. Une application doit donc extraire une connexion, puis l'enregistrer immédiatement. Les connexions sont ensuite disponibles pour une utilisation ultérieure par d'autres threads, ou votre thread si nécessaire. Le retour des connexions à un pool de connexions est une recommandation générale, que vous utilisiez la fonction FAN pour le drainage ou que vous utilisiez des tests de connexion pour le drainage.

Utiliser une réserve de connexions Oracle

À l'aide d'une réserve de connexions FAN, Oracle est la solution recommandée pour masquer la maintenance planifiée. Au fur et à mesure que la maintenance progresse et se termine, les sessions sont déplacées et rééquilibrées. Les utilisateurs ne subissent aucun impact lorsque votre application utilise une réserve Oracle avec l'avis rapide des applications et qu'elle renvoie les connexions dans la réserve entre les demandes. Les groupes Oracle pris en charge comprennent UCP, WebLogic GridLink, Tuxedo, le groupe 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 FAN autre que de s'assurer que vos connexions sont renvoyées au pool entre les demandes.

Utiliser UCP avec une réserve de connexions de tierce partie

Si vous utilisez un serveur d'applications de tierce partie basé sur Java, la méthode la plus efficace pour effectuer le drainage et le basculement consiste à remplacer la source de données avec pool de données par 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 et Hibernate.

Utiliser les tests de connexion

Si vous ne pouvez pas utiliser un groupe Oracle avec FAN, la base de données Autonomous AI Database ou les pilotes de client fournis draineront la session. Lorsque les services sont déplacés ou arrêtés pendant la maintenance, ou lors d'une permutation vers un site de secours à l'aide d'Autonomous Data Guard, les pilotes de client Oracle Database et Oracle recherchent des endroits sûrs pour libérer des connexions conformément aux règles suivantes :

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

Utiliser des tests de connexion avec Autonomous AI Database

Vous pouvez ajouter, supprimer, activer ou désactiver des tests de connexion pour Autonomous AI 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 test de connexion qui est activé dans votre base de données au niveau de votre réserve de connexions ou du serveur d'applications. Configurez également le vidage et la destruction de la réserve lors de l'échec du test de connexion à au moins deux fois la taille maximale de la réserve ou MAXINT.

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

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

  • Activer validate-on-borrow=true
  • Définissez les propriétés du 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)
  • Un HINT au début de l'énoncé 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. C'est la seule méthode qui soit une modification de code. Dans votre code, vérifiez le descripteur du serveur lors de l'emprunt et du retour des connexions pour voir si la session est déconnectée. Pendant la maintenance, la valeur de OCI_ATTR_SERVER_STATUS est réglée à OCI_SERVER_NOT_CONNECTED. Lors de l'utilisation de la réserve 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");

Étapes d'utilisation de la continuité des applications

Effectuez les étapes suivantes pour utiliser la continuité des applications :

  • Vous devez au préalable activer et configurer la continuité des applications ou la continuité transparente des applications pour votre service de base de données dans Autonomous AI Database. Pour plus d'informations, voir Configurer la continuité des applications dans une base de données d'IA autonome.

  • Oracle recommande vivement d'utiliser les derniers pilotes de client. Les pilotes du client Oracle Database 19c, puis fournissent une prise en charge complète de la continuité des applications et de la continuité transparente des applications. Utilisez l'un des pilotes suivants pour les clients pris en charge :

    • Oracle JDBC Replay Driver 19c ou version ultérieure. Il s'agit d'un pilote JDBC fourni avec Oracle Database 19c pour la continuité des applications

    • Oracle Universal Connection Pool (UCP) 19c ou version ultérieure avec Oracle JDBC Replay Driver 19c ou version ultérieure

    • Oracle Weblogic Server 12c avec Active GridLink ou serveurs d'applications JDBC de tierce partie utilisant UCP avec Oracle JDBC Replay Driver 19c ou version ultérieure

    • Réserves de connexions Java ou applications Java autonomes utilisant Oracle JDBC Replay Driver 19c ou version ultérieure

    • Oracle Call Interface Session Pool 19c ou version ultérieure.SQL*Plus 19c (19.8) ou version ultérieure

    • Pilote ODP.NET non géré et groupé 19c ou supérieur ("Pooling=true" par défaut dans les versions 12.2 et supérieures)

    • Applications basées sur l'interface d'appel Oracle utilisant un pilote OCI version 19c ou ultérieure

Replacez les connexions dans la réserve de connexions

L'application doit retourner la connexion à la réserve de connexions Oracle pour chaque demande. La meilleure pratique pour l'utilisation des applications consiste à extraire (emprunter) les connexions uniquement pendant le temps nécessaire, puis à les enregistrer dans le groupe lorsque les actions courantes sont terminées. Ceci est important pour une meilleure performance des applications lors de l'exécution, pour le rééquilibrage du travail lors de l'exécution et pendant les événements de maintenance et de basculement. Cette pratique est également importante pour le drainage.

Lors de l'utilisation d'une réserve de connexions Oracle, comme Universal Connection Pool (UCP) 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 utilisées par la continuité des applications pour identifier les endroits sûrs où reprendre et terminer la capture. Cela est requis pour la continuité des applications et est recommandé pour la continuité transparente des applications.

La continuité transparente des applications détecte également 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 frontière 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 (voir État de session propre entre les demandes dans ce document)

Activer les variables mutables utilisées dans l'application

Les fonctions mutables sont des fonctions qui peuvent retourner une nouvelle valeur à chaque exécution. La prise en charge du maintien des résultats initiaux des fonctions mutables est fournie pour SYSDATE, SYSTIMESTAMP, SYS_GUID et sequence.NEXTVAL. Si les valeurs initiales 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 variables mutables pour PL/SQL, émettez GRANT KEEP au besoin.

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 s'appelle un effet secondaire.

Les effets secondaires sont des actions externes, ils ne sont pas repositionnés. Lors de la réexécution, il est possible de déterminer si les effets secondaires doivent être réexécutés. De nombreuses applications choisissent de répéter des effets secondaires tels que les écritures de journal et l'envoi de courriels car les exécutions en double ne posent 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 Transparent Application Continuity est activé par défaut, TAC ne rejoue pas les effets secondaires. La capture est désactivée et réactive au niveau de la limite implicite suivante créée par TAC.

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

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

Replacez les connexions dans la réserve de connexions

L'exercice le plus important pour les développeurs consiste à renvoyer des connexions à la réserve de connexions à la fin de chaque demande. Ceci est important pour optimiser les performances des applications lors de l'exécution, pour drainer le travail et pour rééquilibrer le travail lors de l'exécution et pendant la maintenance, et pour gérer les é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 ne fonctionne ni ne s'adapte.

Nettoyer l'état de session entre les demandes

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

Lorsqu'une application renvoie une connexion à la réserve 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 entreprise pour les effacer. Si votre application définit l'état, il est recommandé de renvoyer vos curseurs dans le cache d'instructions et d'effacer l'état de session associé à l'application pour éviter toute fuite vers les réutilisations ultérieures de cette session de base de données. Le nettoyage de l'état de votre session permet à TAC de détecter les limites.

Pour nettoyer automatiquement votre état entre les demandes avec Oracle AI Database 26ai, définissez l'attribut de service RESET_STATE=LEVEL1. Cela évite les fuites d'état et l'extraction à partir des curseurs par une utilisation ultérieure de la réserve 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 vos curseurs en les retournant dans la mémoire cache d'énoncés.

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

N'intégrez pas COMMIT dans PL/SQL et évitez COMMIT on Success et Autocommit

Il est recommandé d'utiliser une validation de niveau supérieur (OCOMMIT ou COMMIT() ou OCITransCommit). Si votre application utilise COMMIT intégré dans PL/SQL, AUTOCOMMIT ou COMMIT ON SUCCESS, il se peut qu'il ne soit pas possible de procéder à une récupération après une interruption ou une temporisation. 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 sonore car ces données ont peut-être été lues, soit utiliser un point de reprise et une technique de redémarrage par lots. Lorsque vous utilisez AUTOCOMMIT ou COMMIT ON SUCCESS, la sortie est perdue.

Si votre application utilise une validation de niveau supérieur, les options Transparent Application Continuity (TAC), Application Continuity (AC) et TAF Select Plus sont prises en charge. Si votre application utilise COMMIT intégré dans PLSQL ou AUTOCOMMIT ou COMMIT ON SUCCESS, il se peut que la réexécution ne soit pas possible pour les cas où l'appel, y compris COMMIT, n'a pas été exécuté jusqu'à sa fin.

Utiliser ORDER BY ou GROUP BY dans les interrogations

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'acceptera pas la réexécution. Lorsqu'une commande SELECT utilise ORDER BY ou GROUP BY est conservée. Dans Autonomous AI Database, l'optimiseur d'interrogations utilise le plus souvent le même chemin d'accès, ce qui peut aider dans le même ordre des résultats. La continuité des applications utilise également une clause AS OF pour retourner les mêmes résultats d'interrogation lorsque AS OF est autorisé.

Considérations relatives à SQL*Plus

SQL*Plus est souvent notre outil de test. Bien entendu, 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 ne comporte donc pas de limites de demande explicites. Certaines applications utilisent par exemple SQL*Plus pour les états. 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 points d'extrémité ONS pour vous.

  2. Lors de l'utilisation de 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 obtenir de meilleurs résultats, définissez une grande taille de tableau. Par exemple (définissez la taille de tableau 1000). Évitez d'activer la sortie du serveur car cela crée un état de session non restaurable.