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'applications, 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.
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.
Au moment de l'exécution, la valeur d'ID collection 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.
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é.
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.
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 collection, 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 collection 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 collection 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 Utilitaire Configure
Vous exécutez 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.