Exécution statique et dynamique des instructions SQL avec l'optimisation client pureQuery

Dans une base de données DB2, vous pouvez exécuter les instructions SQL en mode statique ou dynamique. L'exécution statique requiert la configuration de la base de données pour l'exécution d'une instruction SQL, mais offre des performances plus régulières. L'exécution dynamique des instructions SQL est plus flexible car elle ne nécessite aucune préparation particulière sur la base de données.

La différence entre l'exécution statique et dynamique d'instructions SQL est similaire à la différence entre l'exécution d'applications écrites dans un langage de programmation compilé et dans un langage de programmation interprété. Lorsque vous utilisez un langage compilé, le code exécutable est généré avant l'exécution. Lorsque vous utilisez un langage interprété, le code exécutable est généré pendant l'exécution. Comme dans le cas de l'exécution d'un langage interprété, des coûts d'UC sont associés à l'analyse d'une instructions SQL et à la création d'un plan d'accès. L'exécution SQL dynamique peut nuire aux performances de l'application. La principale différence entre l'exécution SQL statique et dynamique tient au fait que l'exécution SQL statique requiert la préparation et la liaison du programme avant l'exécution finale de l'application. L'exécution SQL dynamique est préparée pendant l'exécution. L'exécution SQL dynamique peut engendrer des frais de traitement supplémentaires liés aux fonctions PREPARE et DESCRIBE à chaque exécution.

Les mémoires cache d'instructions SQL dynamiques peuvent permettre d'éviter les frais supplémentaires liés aux fonctions PREPARE et DESCRIBE des instructions SQL. Une mémoire cache d'instructions SQL peut se situer sur le serveur d'application, sur la base de données DB2 ou sur les deux. Toutefois, pour atteindre des taux d'occurrences élevés de la mémoire cache, il faut généralement procéder à un réglage affiné. Les instructions SQL doivent être codées correctement pour optimiser les chances d'occurrence dans la mémoire cache sans gaspiller d'espace dans la mémoire cache. Dans les environnements typiques, l'optimisation totale est difficile à obtenir.

En effet, très souvent, l'exécution SQL statique peut offrir des performances supérieures, des temps de réponse plus cohérents et des avantages significatifs en termes de sécurité. Les instructions SQL sont toutes liées dans un package de la base de données DB2, de sorte qu'on ne peut manquer une instruction SQL individuelle dans la mémoire cache. Le package reçoit des autorisations d'exécution, de sorte que l'octroi d'autorisations n'est pas nécessaire sur les objets de la base de données sous-jacente pour tous les utilisateurs. De même, une affectation de ressources basées sur des objectifs pour la gestion de la charge de travail définie pour les packages statiques et les chemins d'accès, définie lorsque vous liez des packages vous aide à atteindre des temps de réponse plus cohérents.

Une certaine planification des processus est requise pour se préparer aux différences relatives que présente une application JDBC SQL dynamique à une application JDBC SQL statique. Même si l'optimisation client pureQuery introduit de nouvelles conditions et de nouveaux outils, l'hypothèse de base et les concepts de la gestion de déploiements d'applications statiques classiques, telles qu'une application COBOL ou SQLJ, s'appliquent également aux applications statiques avec l'optimisation client pureQuery. Bon nombre d'options sont susceptibles d'affecter le déploiement selon le scénario de l'application, et une planification attentive ainsi qu'une prise en compte des options sont nécessaires pour assurer la réussite du déploiement.

Informations d'identification du package DB2

Un package DB2 est identifié par quatre composants. Au moment de l'exécution du programme, pureQuery Runtime utilise les quatre composants pour identifier le package afin d'exécuter SQL en mode statique sur un serveur de base de données DB2.
Nom de l'emplacement
Le nom est déterminé par le serveur cible spécifié au moment de la liaison. Pour l'optimisation client pureQuery. L'emplacement est spécifié dans le composant du nom de base de données de l'option de l'URL StaticBinder. Lorsque l'utilitaire pureQuery StaticBinder est appelé.

Au moment de l'exécution, la valeur du nom d'emplacement est déterminée par les informations de connexion de l'application au moment de l'exécution. Les noms d'emplacement pour DB2 for z/OS sont équivalents aux noms de la base de données sous DB2 for Linux, UNIX, and Windows.

Ensemble d'ID
Cet ID est spécifié au cours de l'étape de configuration. L'ID d'ensemble permet de grouper un ensemble de packages apparentés. Les instructions SQL pour une application se composent d'un ou plusieurs ensembles de packages. Il n'est pas recommandé de lier tous les packages de différentes applications dans un même ensemble. Les ensembles doivent être considérés comme des groupes de modules apparentés pour une application, mappés dans des packages dans la base de données DB2. La valeur d'ID d'ensemble doit être utilisée pour grouper de manière logique les ensembles apparentés. Si la valeur d'ID d'ensemble n'est pas définie, la valeur par défaut est la chaîne NULLID.

Au moment de l'exécution, la valeur d'ID d'ensemble peut être définie comme une propriété de la source de données permettant d'acquérir une connexion. Dans l'application, les registres spéciaux CURRENT PACKAGESET ou CURRENT PACKAGE PATH peuvent être définis pour remplacer la valeur par défaut. Si ces registres spéciaux sont utilisés dans l'application, il convient de veiller à lier les packages dans les ensembles spécifiés par le paramètre du registre spécial.

Nom du package
Le nom du package est dérivé du nom de l'ensemble d'instructions dans le fichier pureQueryXML lorsque l'utilitaire pureQuery StaticBinder crée des packages sur une base de données. Pour exécuter une instruction SQL en mode statique au moment de l'exécution, pureQuery Runtime met en correspondance l'instruction SQL et une instruction du fichier pureQueryXML. pureQuery Runtime utilise le nom de l'ensemble d'instructions qui contient l'instruction pour déterminer le nom du package.

Lorsque vous configurez un fichier pureQueryXML, vous spécifiez la chaîne de base à utiliser pour créer des noms d'ensembles d'instructions SQL avec l'option -rootPkgName de l'utilitaire pureQuery Configure.

Au moment de l'exécution, le nom du package qui a été créé au cours du processus de configuration ne peut plus être modifié.

Marque de cohérence
La marque est implémentée sous forme d'un horodatage hexadécimal. La marque de cohérence est déterminée par l'horodatage Java lorsque vous exécutez l'utilitaire pureQuery Configure sur un fichier pureQueryXML.

Vous pouvez utiliser le même fichier pureQueryXML pour créer des packages sur différentes bases de données cibles. Si vous utilisez le même fichier pureQueryXML pour créer des packages sur différentes bases de données cibles, la même marque de sécurité est utilisée sur les différentes bases de données cibles pour identifier le package au moment de l'exécution.

Si la marque de cohérence est modifiée dans le fichier pureQueryXML après la création de packages sur une base de données cible, pureQuery Runtime n'utilisera pas les packages sur la base de données pour exécuter les instructions SQL en mode statique.

Au moment de l'exécution, la valeur est fixée. Une fois que vous avez créé des packages sur une base de données en exécutant l'utilitaire StaticBinder avec un fichier pureQueryXML, vous ne devriez pas modifier les marques de cohérence dans le fichier pureQueryXML. Si vous modifiez une marque, pureQuery Runtime ne sera pas en mesure d'identifier le package associé à l'instruction SQL dans le fichier.

Mappage entre les données SQL capturées et les packages DB2

pureQuery Runtime détermine quand exécuter une instruction SQL en mode statique en comparant l'instruction SQL aux informations SQL telles que la chaîne SQL, le curseur et les attributs de préparation comme le type d'ensemble de résultats, les accès simultanés et la gérabilité. Lors de l'exécution statique d'instructions SQL, pureQuery Runtime mappe les instructions SQL qui sont émises par l'application sur les informations d'emplacement, d'ID de collecte, de nom de package et de marque de cohérence dans le fichier pureQueryXML. pureQuery Runtime utilise ce mappage pour accéder au package DB2 contenant les instructions SQL et exécute l'instruction SQL en mode statique.

Avec l'utilitaire pureQuery Configure, vous spécifiez les caractéristiques des packages DB2 que vous créez et qui contiennent les instructions SQL. Les caractéristiques comprennent l'ID de collecte et l'ensemble d'instructions auquel appartient l'instruction. Ces caractéristiques sont stockées dans le fichier pureQueryXML. L'utilitaire Configure stocke également une marque de cohérence avec les informations du package.

L'utilitaire pureQuery StaticBinder utilise le nom de l'ensemble d'instructions dans le fichier pureQueryXML, l'ID de collecte et la marque de cohérence pour créer l'identifiant de package sur la base de données DB2. L'emplacement est déterminé par le serveur cible que vous spécifiez lorsque vous spécifiez à quel moment utiliser l'utilitaire StaticBinder. Le nom du package est basé sur le nom de l'ensemble d'instructions. Pour plus d'informations sur la manière dont l'utilitaire StaticBinder crée un nom de package à partir du nom d'un ensemble d'instructions, reportez-vous à l'option -rootPkgName dans Configuration de l'utilitaire

Vous utilisez l'utilitaire Configure et l'utilitaire StaticBinder pour créer des packages sur un serveur de base de données DB2. Vous pouvez spécifier les options Configure et StaticBinder pour créer des ensembles de packages et des versions de package pour gérer les packages sur un serveur de base de données DB2.


Commentaires