Défis de la gestion de plans (3)

instructions SQL précédemment stockés dans PgmLib/ShipPgm pour la base de données Office #2, sont remplacés et mis à jour par les nouveaux plans. Une fois que ce second appel du programme de livraison par un utilisateur d’Office #1 se termine, l’objet programme de livraison contient les plans d’accès construits pour accéder aux tables dans LIB1A et LIB1B.

On voit tout de suite que lorsque les utilisateurs de chaque emplacement alternent les appels au programme de livraison, le moteur DB2 est pris rapidement dans un scénario d’emballement. Dès que l’optimiseur de requêtes a fini de reconstruire les plans d’accès pour accéder à la base de données Office #1, on lui demande de nouveau de reconstruire et de mettre à jour les plans d’accès pour accéder à la base de données Office #2.

La charge des mises à jour continues du plan d’accès freine la performance des deux emplacements qui utilisent le programme. Avec le CQE (Classic Query Engine), la seule solution (sauf à déplacer toutes les données dans une base de données centrale) était de dupliquer les objets programme. Chaque emplacement doit invoquer sa copie privée du programme.

Le fait d’utiliser une copie « dédiée » du programme laisse les plans d’accès stockés seuls dans le programme, parce que l’objet programme est appelé avec la même liste de bibliothèques à chaque fois. L’emballement peut aussi se produire quand on partage un programme basé sur SQL sur des bases de données stockées dans des IASP (independent auxiliary storage pools) différents.