Autoréglage

système, qu’il s’agisse de
puissance de traitement accrue ou de
mémoire supplémentaire, pour réaliser
les meilleures performances. Par
exemple, l’utilisation de la fonction
« capacity on demand » de l’iSeries
pour activer des processeurs supplémentaires
sur un serveur permet à 
l’optimiseur DB2 de reconnaître immédiatement
la nouvelle puissance de
traitement et de l’utiliser à  plein.

Pour bénéficier des récents changements
apportés aux bases de données
(nouvel index, par exemple) ou
aux systèmes (plus de mémoire, par
exemple), de nombreuses bases de
données demandent aux administrateurs
d’effectuer une opération de lien
pour forcer la mise à  jour possible d’un
plan d’accès pour une instruction SQL. Les opérations bind ne concernent généralement
que des programmes en
langage évolué (HLL) avec SQL intégré.
DB2 UDB ne comporte pas d’utilitaire
bind ou d’opération bind parce
qu’il reconnaît automatiquement ces
changements et met à  jour le plan d’accès
quand c’est opportun. C’est ce que
l’on appelle parfois late binding ou
automatic binding (lien tardif ou automatique)
qui est effectué sur l’iSeries
pour les deux SQL intégré et
dynamique (ODBC, JDBC, par
exemple). DB2 UDB analyse les changements
avec discernement afin de ne
reconstruire que les plans d’accès nécessaires,
en évitant une reconstruction
continue. Ainsi, un pool de mémoire
qui passe de 1,2 Go à  1,4 Go est
un changement de ressource qui améliorera très peu la performance
d’une instruction SQL. Dans ce cas,
DB2 UDB décide de ne mettre à  jour
aucun plan d’accès existant.

Quand une instruction SQL est
exécutée sur l’iSeries, il lui faut à  la fois
un plan d’accès et un ODP (open data
path). Le plan d’accès contient des informations
sur la manière dont l’instruction
SQL sera mise en oeuvre (balayage
de table, par exemple) et l’ODP
est le tuyau utilisé pour l’entrée ou la
sortie des données. Le moteur SQL
iSeries essaie d’améliorer la performance
des instructions SQL fréquemment
exécutées sur le serveur, en « cachant
» leur plan d’accès et ODP. Au
lieu de consacrer des ressources système
à  créer un plan d’accès ou ODP, le
système réutilise les objets mis en
cache. Les voies de données ouvertes
sont mises en cache au niveau du job
(ou de la connexion). Les plans d’accès
pour des interfaces SQL dynamiques
sont mis en cache au niveau du job (ou
de la connexion) et au niveau du système
global. Les zones de stockage servant
à  cette mise en cache sont automatiquement
allouées et peuplées par
DB2 UDB. Contrairement à  la plupart
des autres bases de données, où un administrateur
doit dégager le stockage
que la base de données utilisera pour
la mise en cache.

Toujours pour améliorer la performance
de la base de données, DB2
UDB automatise la collection et la
maintenance des statistiques. Sur la
plupart des autres bases de données,
c’est manuellement que l’on crée et rafraîchit
les statistiques. Les optimiseurs basés sur le coût se fondent sur les statistiques
d’index et de tables pour
prendre des décisions intelligentes
quant au moyen le plus rapide d’honorer
une requête.