Défis de la gestion de plans (2)

3 montre cette double utilisation du programme de livraison. Pour livrer les commandes, les utilisateurs des deux agences appellent le même programme, PgmLib/ShipPgm. Le premier utilisateur à appeler Pgm Lib/ShipPgm travaille dans Office #2. A la première exécution du programme, l’optimiseur de requêtes construit des plans d’accès pour les deux instructions SQL pour cibler les tables qui résident en LIB2A et LIB2B. Le premier appel du programme se déroule parfaitement et les plans d’accès stockés dans PgmLib/ ShipPgm sont construits pour accéder aux tables dans LIB2A et LIB2B.

Dix minutes plus tard, un utilisateur à Office #1 doit livrer une commande et appelle le même programme de livraison (PgmLib/ShipPgm). Avant d’exécuter les instructions SQL, l’optimiseur de requêtes détecte que la liste de bibliothèques a changé depuis la dernière exécution. Par conséquent, l’optimiseur de requêtes doit reconstruire les plans d’accès pour accéder aux tables dans LIB1A et LIB1B, parce qu’un utilisateur de Office #1 est en train d’appeler le programme. Pour plusieurs raisons, les plans d’accès doivent être reconstruits, bien que les objets base de données dans les deux ensembles de bibliothèques de données soient structurellement les mêmes. Faute de quoi, les agences ne partageraient pas le même programme.

Bien que les définitions de tables soient probablement identiques à celles qui résident en LIB2A et LIB2B, l’optimiseur de requêtes doit vérifier cela et construire des plans d’accès précis qui pointent vers les objets de la base de données Office #1. En outre, il n’est pas sûr que le nombre de clients et de commandes dans la base de données pour chaque agence soit identique. Les plans d’accès générés par l’optimiseur sont sensibles aux données stockées dans une table. Avant de choisir le meilleur plan d’accès pour une instruction SQL, l’optimiseur examine le nombre de lignes dans une table ainsi que le nombre de valeurs distinctes dans une colonne.