Caractéristiques et avantages de l'optimisation client pureQuery

L'activation d'une application Java avec l'optimisation client pureQuery peut améliorer la sécurité, la durabilité et les performances de l'application. La capacité à convertir l'application de l'exécution SQL dynamique en exécution SQL statique est l'un des avantages clés de l'activation de l'optimisation client pureQuery.
Parmi les autres avantages liés à l'optimisation client pureQuery, nous pouvons citer : Avec l'optimisation client pureQuery, un administrateur de base de données peut utiliser les compétences existantes dans l'organisation pour gérer les applications.
Les sections suivantes décrivent les avantages de l'optimisation client pureQuery et de l'exécution SQL statique dans les domaines suivants :

Récapitulatif des caractéristiques et avantages

La liste suivante récapitule les fonctionnalités disponibles avec l'optimisation client pureQuery :
  • Développement de l'indépendance des infrastructures
  • Intégration des outils (avec les produits InfoSphere Optim Optim)
  • Récupération des instructions SQL
  • Identification des instructions SQL aux performances médiocres (en cas d'utilisation avec d'autres produits InfoSphere Optim)
  • Capture de données de performance SQL (en cas d'utilisation avec d'autres produits InfoSphere Optim)
  • Capture des informations de type données des instructions SQL
  • Choix d'une exécution des instructions SQL en mode dynamique ou statique
  • Exécution exclusive des instructions SQL capturées au préalable
  • Aptitude à remplacer les littéraux SQL par des marqueurs de paramètres SQL
  • Remplacement des instructions SQL
La liste suivante récapitule les avantages de l'exécution des instructions SQL en mode statique :
  • Performances SQL cohérentes
  • Plans d'accès SQL prévisibles
  • Sécurité accrue de la base de données lors de l'exécution SQL
  • Trafic réseau réduit
  • Elimination des instructions d'exécution PREPARE et DESCRIBE
  • Récupération des instructions SQL
  • Suivi de l'exécution SQL
  • Prise en charge de DB2 Explain
  • Aptitude à identifier les instructions SQL aux performances médiocres
  • Informations sur les erreurs spécifiques à l'exécution

Avantages du processus de développement

Vous pouvez développer, tester et déployer des applications dans un environnement flexible.

Les avantages comprennent :
Choix de l'infrastructure au cours du développement
Plusieurs technologies sont disponibles pour le développement d'applications Java et sont utilisées par les développeurs d'application pour accéder aux données. L'optimisation client pureQuery fonctionne avec les infrastructures et ne fournit aucune restriction quant au choix d'une infrastructure particulière pour le développement d'applications.

Par exemple, les infrastructures telles que Hibernate, Spring, iBatis et Java Persistence Architecture (JPA) peuvent être utilisées au moment du développement. L'optimisation client pureQuery fonctionne avec le pilote JDBC et n'est pas affectée par les couches supérieures de la logique d'application situées. Les développeurs peuvent continuer à développer des applications qui utilisent SQL dynamique et n'ont pas à s'inquiéter de la sémantique du SQL statique ni des considérations de déploiement.

L'optimisation client pureQuery est davantage une étape de configuration qu'une étape de développement. L'optimisation client pureQuery doit être activée au cours du test des applications intégrées. La capture d'instructions SQL au cours du test garantit que la plupart des instructions SQL sont capturées et converties pour s'exécuter en mode statique, de sorte que les meilleurs performances de l'exécution SQL statique soient obtenues.

Un fichier pureQueryXML contient des instructions SQL et peut être utilisé par une application activée avec l'optimisation client pureQuery. Vous pouvez créer un fichier pureQueryXML avec l'une des ressources suivantes :
  • Fichiers XML d'application JPA : si vous utilisez l'implémentation JPA IBM®, vous pouvez recourir à l'utilitaire wsdb2gen pour générer un fichier XML contenant les instructions SQL utilisées dans les unités de persistance.

    Le fichier généré par l'utilitaire wsdb2gen est compatible avec l'optimisation client pureQuery. Vous pouvez éventuellement utiliser ce fichier pour capturer des instructions SQL supplémentaires pour une application activée avec l'optimisation client pureQuery. Le fichier contiendra les instructions SQL créées par l'utilitaire wsdb2gen et toute instruction SQL supplémentaire capturée par pureQuery Runtime. Vous utilisez le fichier avec les utilitaires pureQuery Configure et StaticBinder pour créer des packages DB2 contenant les instructions SQL et lier les packages à la base de données.

  • Fichiers texte SQL : certaines applications isolent les instructions SQL utilisées dans l'application dans un fichier texte et utilisent la logique d'application pour traiter le fichier. Le fichier suivant contient les instructions SQL séparées par un séparateur tel que le point-virgule (;). Vous pouvez utiliser l'utilitaire pureQuery GeneratePureQueryXml pour générer un fichier pureQueryXML à partir du fichier texte.

    Une fois que vous avez créé un fichier pureQueryXML avec l'utilitaire GeneratePureQueryXml, vous pouvez utiliser le fichier avec pureQuery Runtime pour capturer des instructions SQL supplémentaires ou vous pouvez utiliser le fichier avec les utilitaires pureQuery Configure et StaticBinder pour créer des packages DB2 contenant les instructions SQL et lier les packages à la base de données.

Choix d'une exécution SQL en mode statique ou dynamique
Lorsqu'une application est activée avec l'optimisation client pureQuery, vous pouvez spécifier les instructions SQL qui seront exécutées par l'application en mode statique et celles qui seront exécutées en mode dynamique. Par exemple, vous pouvez choisir d'exécuter les instructions SQL les plus critiques en mode statique en laissant les autres s'exécuter en mode dynamique.

Les développeurs n'ont pas à connaître ni à comprendre les détails des artefacts de la base de données qui affectent l'exécution SQL statique ni les étapes de développement nécessaires pour convertir l'application pour une exécution SQL statique. Les développeurs peuvent développer des applications qui exécutent les instructions SQL en mode dynamique en fonction de l'infrastructure qu'ils connaissent. Les développeurs peuvent se concentrer sur les caractéristiques fonctionnelles de l'application et sur la logique métier de l'application. Les administrateurs de base de données peuvent se concentrer sur le déploiement et l'optimisation des instructions SQL utilisées par l'application.

Lors de l'exécution statique des instructions SQL, l'optimisation client pureQuery peut utiliser la fonctionnalité de gestion des versions de SQL statique dans un serveur de base de données DB2. L'exécution SQL statique permet un déploiement par phases avec exécution simultanée d'un nouveau code d'application et de changements du plan d'accès DB2. La gestion des versions du package vous permet d'enregistrer les packages DB2 existants et de créer des packages. Vous pouvez utiliser les versions du package pour créer une procédure de rétromigration claire et simple pour le cas où les changements auraient des effets négatifs.

Dans les applications SQL dynamique à base JDBC, il n'existe aucune procédure de rétromigration pour les changements du plan d'accès à DB2. Lors de l'exécution statique de SQL, vous pouvez utiliser la gestion des versions de package pour exécuter SQL avec un plan d'accès généré au préalable.

Remarque : Pour les applications activées avec l'optimisation client pureQuery pour exécuter SQL en mode statique, il est recommandé que les étapes de configuration et de liaison de l'application terminée se déroulent au cours d'une phase de test avant de migrer l'application vers un environnement de production. La réalisation des étapes lors de la phase de test garantit des tests et des vérifications complets du processus de déploiement et d'exécution statiques des instructions SQL. Pour plus d'informations sur l'activation de l'optimisation client pureQuery, voir Etapes de l'activation de l'optimisation client pureQuery.
Intégration des outils
L'optimisation du client pureQuery est intégrée à IBM Data Studio. Vous pouvez activer pureQuery pour un projet Java. IBM Data Studio fournit de nombreux points de vue utiles permettant d'obtenir de nouvelles informations concernant l'application et ses packages associés.

Avantages en termes d'optimisation et d'identification des problèmes

pureQuery Runtime capture avec succès les instructions SQL exécutées et des informations connexes telles que les informations relatives aux paramètres SQL et des informations sur l'ensemble de résultats. Vous pouvez optimiser les instructions SQL capturées par pureQuery Runtime et utiliser les informations capturées par pureQuery Runtime pour déterminer la source des problèmes.

Les avantages comprennent :
Paramètre de type et métadonnées de l'ensemble de résultats pour les instructions SQL capturées
Lorsqu'une instruction SQL est exécutée en mode dynamique, elle est préparée et décrite par le pilote JDBC. Ces actions garantissent la syntaxe de l'instruction SQL et sa validité sémantique. De plus, les paramètres et les colonnes de résultats sont vérifiés en termes de type, de longueur, de CCSID et d'autres attributs par rapport aux colonnes de la base de données cible. Avec l'exécution SQL statique, la vérification de type intervient une seule fois au moment de la préparation du programme et non au moment de l'exécution, comme dans le cas de l'exécution SQL dynamique.

Au cours du processus de capture, pureQuery Runtime intercepte les appels au pilote JDBC et capture les informations. L'instruction SQL est capturée uniquement si elle est exécutée avec succès.

Le processus de création de packages à partir des instructions SQL capturées par pureQuery et de liaison des packages à la base de données peut se dérouler de manière fluide car les instructions SQL ont été exécutées avec succès par rapport à la base de données. De plus, à l'aide des informations de type, le processus de liaison peut sélectionner les index appropriés pour les chemins d'accès.

Comptabilité au niveau package et informations d'instantané avec l'exécution statique des instructions SQL
Les informations comptables au niveau des packages sont disponibles à la fois pour DB2 for Linux, UNIX, and Windows et DB2 for z/OS. Dans DB2 for Linux, UNIX, and Windows, les informations figurent dans l'instantané du package et dans DB2 for z/OS, les informations figurent dans un rapport de comptabilité.

Les informations de performance au niveau des packages permettent aux administrateurs de base de données d'identifier les sections spécifiques d'une application qui posent problème, sans se heurter au problème des traces au niveau de l'application. Les informations de performance au niveau du package permettent également d'identifier les sections de code les plus fréquemment exécutées et celles sur lesquelles il convient de se concentrer pour une analyse détaillée des réglages. Dans un environnement dynamique, il peut être difficile d'identifier les sections de code sans définir les traces intégrées spécifiques à l'utilisateur dans l'application.

pureQuery Runtime capture également les traces de pile dans l'application. L'administrateur de base de données peut utiliser les traces de pile et travailler avec le développeur en vue de diagnostiquer la source d'un problème.

Récupération des instructions SQL
Les administrateurs de base de données peuvent utiliser différentes approches pour récupérer les instructions SQL individuelles afin de procéder à un réglage affiné. Pour capturer les instructions SQL dans une application qui exécute SQL en mode dynamique, il faut activer une trace SQL, récupérer des informations figurant dans une mémoire cache, ou utiliser l'instruction SQL avec DB2 EXPLAIN et l'exécuter en mode dynamique. En revanche, les instructions SQL statiques sont prédéfinies et les informations relatives aux instructions sont faciles à récupérer. Les instructions SQL sont capturées et préservées dans les tables du catalogue DB2 et leurs plans d'accès peuvent être capturés dans les tables DB2 Explain à l'avance. L'interrogation des tables du catalogue et Explain peut permettre de récupérer l'instruction SQL en question et le plan d'accès associé.
Fonctionnalité DB2 EXPLAIN

Vous pouvez recueillir les caractéristiques de performance d'une instruction SQL soit en utilisant Visual Explain au moment du développement dans IBM Data Studio, soit en utilisant l'option de liaison EXPLAIN YES lors de l'exécution de l'utilitaire pureQuery StaticBinder.

En utilisant l'option de liaison EXPLAIN YES, un administrateur de base de données peut réviser les décisions concernant le chemin d'accès prises par l'optimiseur DB2. Les administrateurs peuvent déterminer les statistiques de données à collecter pour améliorer la sélection du chemin d'accès. D'autres outils peuvent aussi aider à analyser les instructions SQL dans les tables Explain et d'émettre des recommandations de réglage en fonction de leur contenu. L'analyse du plan d'accès et le réglage sont effectués au moment de la préparation du programme et un plan d'accès prédéfini peut être inclus avec le package créé pour les instructions SQL qui seront exécutées en mode statique. Lorsque vous exécutez SQL en mode dynamique, les plans d'accès ne peuvent pas être prédéfinis.

Messages d'erreur DB2
Lorsque vous utilisez une base de données DB2, les messages d'erreur concernant par exemple les délais de verrouillage, les interblocages et les erreurs pour ressources indisponibles comprennent souvent un nom de package lorsque SQL est exécuté en mode statique. En liant l'erreur à un module d'application, un administrateur de base de données peut utiliser les informations sur le package pour identifier l'instruction SQL qui provoque l'erreur ou qui est affectée par l'erreur.

Les messages d'erreur DB2 for z/OS comprennent des informations relatives au package qui est en cours d'exécution. Ces messages d'erreur contiennent des informations concernant l'emplacement, le nom du package et la marque de cohérence. Ces informations peuvent servir à identifier rapidement la source de l'application. Un message d'erreur similaire, généré lorsqu'une instruction SQL est exécutée en mode dynamique, ne fournit pas d'informations relatives à l'application qui a émis cette instruction SQL. Toutes les instructions SQL passent par les mêmes packages JDBC.

Avec DB2 for Linux, UNIX, and Windows, des outils tels que le moniteur d'événements db2deadlock, lorsqu'ils sont utilisés avec des instructions SQL statiques, fournissent le nom du package et le numéro de la section pour l'événement d'interblocage en plus des ressources de verrouillage spécifique impliquées dans l'interblocage. Ces informations peuvent être affichées avec l'outil DB2 db2evmon.

Traces de pile de l'application
Si vous avez accès au code Java pour l'application, vous pouvez utiliser les informations de trace de pile capturées par pureQuery Runtime pour associer une instruction SQL à un emplacement dans le code source Java. pureQuery Runtime stocke les informations de trace de pile avec l'instruction SQL dans le fichier pureQueryXML. Avec IBM Data Studio, vous pouvez utiliser les informations de trace de pile pour localiser le code Java qui a émis l'instruction.

Avantages opérationnels

Lorsqu'une application activée avec l'optimisation client pureQuery exécute des instructions SQL en mode statique, les instructions SQL sont fournies à la base de données avant l'exécution du programme. L'identification des instructions SQL permet aux administrateurs de base de données d'exploiter l'ensemble complet d'outils à leur disposition et ne requiert pas une trace en ligne pour identifier les instructions SQL.

Parmi les avantages opérationnels, citons :
Modèle de sécurité lors de l'exécution statique des instructions SQL
Dans le modèle d'exécution statique SQL, l'ID d'autorisation utilisé au moment de l'exécution n'est pas requis pour accéder aux objets de la base de données. Au lieu de fournir un accès à des objets de base de la base de données, comme dans le cas d'une implémentation JDBC dynamique, l'ID d'autorisation de l'environnement d'exécution reçoit un accès à un package spécifique prédéfini et aux instructions SQL incluses.

L'autorisation d'un package permet une implémentation améliorée de la sécurité car les ID d'autorisation ne peuvent pas modifier les instructions SQL en utilisant une logique de programmation. En outre, si l'ID est utilisé pour se connecter à partir d'un autre mécanisme d'accès en raison d'une violation de sécurité, l'ID ne peut pas exécuter SQL en mode dynamique. L'autorisation d'un package permet également un audit strict de toutes les instructions SQL qui seront exécutées par rapport à un ensemble de tables.

Dans le modèle statique, un utilisateur qui dispose de l'autorité nécessaire pour accéder à la table de base lie les packages et devient ainsi leur propriétaire. Le propriétaire du package peut alors octroyer le droit d'exécuter le package à un ID d'autorisation d'environnement d'exécution, tel que l'ID d'utilisateur stocké dans la définition de source de données de WebSphere Application Server. L'ID d'utilisateur WebSphere ne peut pas exécuter d'autre instruction SQL en mode dynamique sur les objets de la base de données en dehors des instructions SQL définies dans le package.

En revanche, dans un environnement SQL dynamique, un ID d'utilisateur est utilisé pour tous les accès aux données au nom des utilisateurs connectés au serveur d'applications. Cet ID d'utilisateur peut exécuter SQL en mode dynamique sur la base de données en dehors de l'environnement du serveur d'applications.

Substitution de littéraux SQL
pureQuery Runtime dispose d'une fonctionnalité de substitution de littéraux SQL permettant de convertir des instructions SQL non paramétrées que l'application exécute en instructions SQL paramétrées. Cette fonctionnalité est utile pour les applications qui génèrent des instructions SQL à la volée au cours de l'exécution. En outre, pour les instructions SQL qui s'exécutent en mode dynamique, la substitution de littéraux SQL réduit le nombre total d'instructions SQL dans la mémoire cache dynamique du serveur, ce qui augmente le taux de mise en cache-occurrence pour les instructions.
Fonctionnalité d'exécution exclusive des instructions SQL capturées
L'optimisation client pureQuery permet d'exécuter seulement les instructions SQL capturées. Cette fonctionnalité limite les instructions que l'application peut exécuter à celles que l'administrateur de base de données a approuvées et qui figurent dans le fichier pureQueryXML, même si les instructions SQL s'exécutent en mode dynamique. L'exécution des seules instructions SQL capturées améliore la sécurité de toute application. Cette fonctionnalité est utile dans les environnements qui ne prennent pas en charge le SQL statique. Cette fonctionnalité peut permettre d'éviter les attaques par injection SQL.

L'optimisation client pureQuery peut également limiter l'exécution des instructions SQL à celles qui peuvent être exécutées en mode statique.

Remplacement des instructions SQL
L'utilisation de l'optimisation client pureQuery pour une application JDBC existante facilite la substitution des instructions SQL exécutées par des instructions SQL équivalentes optimisées. Un administrateur de base de données peut remplacer une instruction SQL optimisée si une instruction présente des performances médiocres et ce, sans modifier l'application.

L'instruction SQL remplacée peut contenir des changements tels que des clauses WHERE supplémentaires pour une meilleure sélectivité d'index. L'instruction SQL remplacée ne peut pas ajouter de paramètres ni de colonnes de résultats car les métadonnées sont déjà capturées.

Avantages en termes de performances

Outre les avantages sur le plan opérationnel, du réglage et du développement, l'exécution SQL statique peut améliorer les performances.

Les avantages en termes d'affinage des performances comprennent :
Elimination des instructions d'exécution PREPARE et DESCRIBE

Dans le cas d'une exécution SQL statique, la préparation des instructions est effectuée avant l'exécution de l'instruction dans l'environnement d'exécution et ne se produit qu'une seule fois. En conséquence, les activités de préparation et de description ne sont pas répétées pour l'instruction SQL dans chaque transaction car elles sont répétées avec l'exécution SQL dynamique. L'exécution SQL statique aboutit à une réduction de la consommation d'UC aussi bien sur le serveur de base de données où la préparation intervient, que sur le serveur d'applications où un objet PreparedStatement est créé.

Dans un environnement JDBC, vous pouvez tenter de réduire les coûts de ces instructions de préparation en améliorant les occurrences de la mémoire cache SQL. Toutefois, les implémentations de mise en cache ne garantissent pas un ratio d'occurrences de 100 %.

Flux réduit sur le réseau
Sans la nécessité de préparer chaque instruction SQL, il n'est pas nécessaire d'envoyer les instructions de préparation ni de décrire l'activité dans l'ensemble du réseau avec chaque instruction. Ainsi, le trafic réseau et la durée des transactions sont réduits.
Sélection d'un chemin d'accès prévisible
Les plans d'accès aux instructions SQL sont créés à l'avance et non au moment de l'exécution. Les chemins d'accès ne changent pas à la suite de l'exécution de RUNSTATS ou de la modification de la distribution des données. Une application testée peut exécuter la même instruction SQL à plusieurs reprises et les chemins d'accès sélectionnés ne changent pas en raison des variations de données ou de la maintenance de la base de données.

Commentaires