> Tech > La suite de l’histoire SQE (2)

La suite de l’histoire SQE (2)

Tech - Par iTPro - Publié le 24 juin 2010
email

Avec cela présent à l’esprit, revoyons l’exemple des deux agences partageant le même programme de livraison, PgmLib/ShipPgm, mais référençant des tables (c’est-à-dire des fichiers) dans deux bases de données différentes. Après que chaque agence appelle le programme de livraison, le cache de plan contient deux entrées différentes pour l’instruction Select

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.

Téléchargez gratuitement cette ressource

Sécurité Office 365 : 5 erreurs à ne pas commettre

Sécurité Office 365 : 5 erreurs à ne pas commettre

A l’heure où les données des solutions Microsoft de Digital Workplace sont devenues indispensables au bon fonctionnement de l’entreprise, êtes-vous certain de pouvoir compter sur votre plan de sécurité des données et de sauvegarde des identités Microsoft 365, Exchange et Teams ? Découvrez les 5 erreurs à ne pas commettre et les bonnes pratiques recommandées par les Experts DIB France.

Tech - Par iTPro - Publié le 24 juin 2010