La suite de l’histoire SQE (2)

et deux entrées différentes pour l’instruction Update. La figure 5 montre une vue détaillée des deux plans d’accès dans le cache de plan pour l’instruction Select imbriquée dans le programme de livraison. A noter que le texte d’instruction pour le plan d’accès ne correspond pas au texte d’instruction SQL original provenant du programme (figure 2). L’optimiseur de requêtes construit l’entrée cache de plan en utilisant la version résolue de l’instruction Select.

Le fait d’utiliser la version résolue de l’instruction SQL peut causer des reconstructions de plan d’accès supplémentaires quand on utilise des tables temporaires – à la fois des tables temporaires créées avec l’instruction Declare Global Temporary et une instruction Create Table qui spécifie la bibliothèque QTEMP. Pour prendre connaissance d’une méthode susceptible de minimiser les reconstructions de plan d’accès pour les applications qui utilisent intensivement des tables temporaires, voir l’encadré « Utiliser les plans d’accès de table temporaire ».

La figure 5 démontre aussi un autre avantage de l’utilisation du cache de plan : on peut stocker jusqu’à trois plans d’accès différents pour une même instruction SQL. Cela permet à DB2 de minimiser les reconstructions du plan d’accès quand la même instruction SQL est exécutée avec différents paramétrages de serveur. Dans cet exemple, l’optimiseur de requêtes construit des plans d’accès différents d’après la taille du pool mémoire et le paramétrage de degré parallèle pour la fonction SMP (symmetric multiprocessing) DB2. Dans certaines installations, on a davantage de mémoire et de ressources à la disposition de DB2 SMP, quand le serveur est moins sollicité. Plutôt que de voir l’optimiseur reconstruire le plan d’accès pour cette instruction Select pendant la nuit, puis reconstruire le plan quand Select est exécutée avec la configuration serveur de jour, l’optimiseur de requêtes SQE peut simplement faire la navette entre les différents plans d’accès qui existent pour l’instruction Select.

Le cache de plan SQL résout également le problème de disparition des plans d’accès pour des requêtes SQL dynamiques. L’objet cache de plan persiste jusqu’à la fin des connexions et jobs base de données. Les plans d’accès ne sont pas supprimés du cache de plan quand le job ou la base de données propriétaire arrive à son terme.