Défis de la gestion de plans

RPG. La duplication des plans signifie que DB2 doit dupliquer le travail chaque fois que des plans d’accès sont mis à jour. Par exemple, un index est ajouté pour accélérer l’exécution de cette instruction Select Into. Dans un tel cas, DB2 doit reconstruire le plan d’accès dans chacune des trois objets programmes. Cette duplication conduit DB2 à consommer davantage de ressources serveur. La même duplication des plans d’accès peut aussi se produire avec les conteneurs pour SQL dynamique et SQL dynamique étendu.

On voit clairement les limitations de la gestion du plan d’accès pour des instructions SQL dynamiques. Comme les plans d’accès sont stockés en mémoire de travail pour une connexion job ou base de données, les plans disparaissent dès que le job ou la connexion se termine. Ce comportement transitoire peut ralentir nettement la performance d’applications qui ne maintiennent pas des connexions avec la base de données. Avec ce genre d’applications, vous devez créer des plans d’accès pour toutes les instructions SQL dynamiques chaque fois qu’une connexion base de données est initiée. La nature temporaire des plans d’accès est une raison pour laquelle IBM a ajouté la prise en charge de SQL dynamique étendu. SQL dynamique étendu vous permet de stocker de façon permanente les plans d’accès provenant d’interfaces SQL dynamiques comme Call Level Interface (CLI), ODBC et JDBC dans un objet package SQL après la fin d’une connexion. Toutefois, les packages SQL sont limités par le fait qu’il faut une action manuelle pour valider leur utilisation et qu’ils ne sont pas mis à la disposition de toutes les interfaces SQL dynamiques.

Le principe des conteneurs multiples pour le stockage de plans pose un dernier problème : lorsqu’une application SQL sur un serveur unique est utilisée pour accéder à différentes bases de données. C’est le cas par exemple d’une société dont deux agences utilisent la même application. Les programmes que cette application utilise ressemblent au programme PgmLib/ShipPgm (figure 2). Toutes les instructions SQL utilisent des noms de tables non qualifiés, donc vous pouvez utiliser la liste de bibliothèques ou un remplacement de fichiers à l’exécution, pour déterminer à quelle base de données accéder.