La suite de l’histoire SQE

disposition pour générer des plans de meilleure qualité. Cependant, l’introduction d’un cache de plan SQL à l’échelle du système signifie que SQE permet aussi une meilleure gestion des plans d’accès. Voyons comment le cache de plan SQL fonctionne et comment il élimine les soucis de gestion de plan de son prédécesseur.

SQE inclut un cache de plan central visant à obtenir la meilleure réutilisation des plans d’accès associés aux requêtes SQL les plus fréquentes. Le cache de plan SQE fait en sorte que les instructions SQL courantes, fréquemment exécutées par différents programmes et interfaces, partagent le même plan d’accès plutôt que de voir chacune d’elles créer sa propre copie (figure 4). En outre, le même objet programme peut choisir entre plusieurs plans d’accès pour une instruction imbriquée unique, en fonction du ou des membres de données référencés.

Tout comme CQE, SQE peut mettre à jour les plans d’accès dans son cache à la demande pour utiliser les éventuels nouveaux index ou nouvelles mémoires qui auraient pu être ajoutés au système. L’avantage de la mise à jour dynamique des plans de SQE est que chaque invoqueur d’une instruction SQL bénéfice automatiquement du plan d’accès mis à jour au lieu de mettre à jour sa propre copie du plan. Une meilleure réutilisation des plans existants signifie moins de constructions et de reconstructions des plans d’accès, et donc une amélioration de la performance système.

Observez aussi comment les plans d’accès générés par SQE sont maintenant divisés (figure 4) : les plans d’accès créés par SQE pointent vers le cache de plan au lieu d’être complètement logés dans leurs conteneurs. Le cache de plan SQL stocke la portion de l’optimiseur (par exemple la méthode de balayage d’index) du plan d’accès. L’en-tête du plan d’accès contient les composantes nécessaires pour valider une requête SQL (par exemple le texte de l’instruction SQL). Avec SQE, l’en-tête du plan d’accès reste dans le conteneur du plan d’accès original en compagnie d’un lien virtuel vers la portion plan de l’optimiseur dans le cache de plan. Dans la figure 4, les instructions SQL que SQE traite n’ont pas de relation avec le cache de plan, ce qui démontre bien que la totalité du plan réside dans le conteneur. A titre de rappel, voici la liste de quelques-uns des éléments les plus courants qui empêchent le SQE V5R4 d’exécuter une requête SQL :

• utilisation de la fonction UPPER, LOWER ou TRANSLATE
• séquence de tri en langue nationale
• fonction de table définie par l’utilisateur (UDTF, user-defined table function)
• références au fichiers logiques sur la clause From
• select/omit de fichiers logiques défini sur la table sous-jacente

Remarque: IBM envisage d’éliminer ces restrictions SQE dans les prochaines releases du système d’exploitation.

On voit clairement comment le cache de plan SQL élimine les problèmes de plans en double. Mais on voit moins bien comment le cache de plan SQL résout l’emballement du plan d’accès évoqué plus haut. Avant qu’un plan pour une instruction SQL soit placé dans le cache de plan, toutes les références aux tables et aux vues non qualifiées sont résolues. Par conséquent, si la même instruction SQL est exécutée avec différentes listes de bibliothèques ou des valeurs de schéma courantes, une autre entrée pour l’instruction est créée dans le cache de plan chaque fois que la version résolue de l’instruction SQL est unique.