![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[z/OS]](../images/ngzos.gif)
Paramètres de réglage DB2
Consultez cette rubrique pour les paramètres que vous pouvez définir pour améliorer les performances de la base de données.
Pour des informations plus complètes sur la configuration et l'optimisation de DB2, reportez-vous au document DB2 UDB Administration Guide: Performance.
Pour plus d'informations sur l'utilisation d'AIX avec
DB2, voir la rubrique relative à l'optimisation des systèmes AIX.
Journalisation DB2
DB2 possède des fichiers journaux correspondants pour chaque base de données qui offre des services aux administrateurs (affichage des accès à la base de données, nombre de connexions, etc.). Pour les systèmes comportant plusieurs unités de disque dur, les performances peuvent être considérablement améliorées en définissant les fichiers journaux de chaque base de données sur un disque dur différent de celui des fichiers de la base de données.
- Comment voir et définir : A partir d'une invite de commande DB2, lancez la commande suivante : db2 update db cfg for [nom_base_données] using newlogpath [chemin_complet].
- Valeur par défaut : Les journaux résident sur le même disque que la base de données.
- Valeur conseillée : Utilisez une unité haute vitesse distincte, de préférence à performances améliorées par une configuration RAID.
Assistant de configuration DB2
Situé dans le centre de contrôle DB2, ce conseiller calcule et affiche les valeurs recommandées pour la taille des pools de mémoire tampon DB2, les paramètres de configuration de la base de données et du gestionnaire de bases de données (l'application de ces valeurs est facultative). Pour plus d'informations sur ce conseiller, reportez-vous à l'aide en ligne du centre de contrôle.
Nombre de connexions à DB2 - MaxAppls et MaxAgents
Lors de la configuration des paramètres de la source de données des bases de données, confirmez que le paramètre DB2 MaxAppls a une valeur supérieure au nombre maximal de connexions pour la source de données. Si vous prévoyez de mettre en place des clones, la valeur du paramètre MaxAppls doit être égale au nombre maximal de connexions multiplié par le nombre de clones. La même relation s'applique au paramètre Nombre de connexions du Gestionnaire de sessions. La valeur du paramètre MaxAppls doit être égale ou supérieure au nombre de connexions. Si vous utilisez la même base de données pour le stockage des sessions persistantes et des données de votre application, la valeur du paramètre MaxAppls doit correspondre à la somme du nombre de connexions défini dans le Gestionnaire de sessions et du nombre maximal de connexions défini dans la source de données WebSphere.
Par exemple, MaxAppls = (nombre de connexions définies pour la source de données + nombre de connexions dans le gestionnaire de sessions) multiplié par le nombre de clones.
Une fois la valeur de chaque paramètre MaxAppls (celui de la base de données WebSphere Application Server et celui de chaque base de données d'application) calculé, vérifiez que la valeur du paramètre DB2 MaxAgents (nombre maximal d'agents) est égale ou supérieure à la somme de toutes les valeurs MaxAppls. Par exemple, MaxAgents = somme de MaxAppls pour toutes les bases de données.
Paramètre buffpage de DB2
Améliore les performances du système de base de données. Buffpage est un paramètre de configuration de base de données. Un pool de tampons est une zone de stockage de mémoire dans laquelle les pages de base de données contenant des entrées de ligne ou d'index sont temporairement lues et modifiées. L'accès aux données est beaucoup plus rapide à partir de la mémoire qu'à partir du disque.
- Comment afficher et définir : pour afficher la valeur en cours du paramètre
buffpage de la base de données x, entrez la commande DB2 get db cfg for x et recherchez la valeur BUFFPAGE.
Pour affecter la valeur n au paramètre BUFFPAGE, entrez la commande DB2
update db cfg for x en utilisant BUFFPAGE n et associez la valeur
-1 au paramètre NPAGES de la manière suivante :
db2 <-- passage en mode de commande DB2, sinon la commande "select" suivante ne fonctionne pas connect to x <-- (où x correspond à un nom de base de données DB2 spécifique) select * from syscat.bufferpools (et notez le nom par défaut, par exemple : IBMDEFAULTBP) (si la valeur de NPAGES est déjà -1, vous n'avez pas besoin d'émettre la commande suivante) alter bufferpool IBMDEFAULTBP size -1 (émettez une nouvelle fois la commande "select" ci-dessus et la valeur de NPAGES devient -1)
Effectuez une capture d'écran de la base de données alors que l'application est active et calculez le taux de réussite du pool de tampons en procédant comme suit :- Effectuez une capture d'écran :
- Exécutez la commande update monitor switches using bufferpool on.
- Assurez-vous que la fonction de contrôle du pool de tampon est activée en entrant la commande get monitor switches.
- Effacez les compteurs des contrôleurs en entrant la commande reset monitor all.
- Exécutez l'application.
- Entrez la commande get snapshot for all databases avant que les applications ne se déconnectent de la base de données. Sinon, les statistiques sont perdues.
- Lancez la commande update monitor switches using bufferpool off.
- Calculez le taux de réussite en consultant les statistiques de la capture suivante :
- Nombre de lectures logiques des données du pool de tampons
- Nombre de lectures physiques des données du pool de tampons
- Nombre de lectures logiques de l'index du pool de tampons
- Nombre de lectures physiques de l'index du pool de tampons
- Effectuez une capture d'écran :
- Valeur par défaut : 250
- Valeur conseillée : Continuez à augmenter la valeur jusqu'à ce que la capture d'écran montre un taux de réussite satisfaisant.
- P = Nombre de lectures physiques des données du pool de tampons + Nombre de lectures physiques de l'index du pool de tampons
- L = Nombre de lectures logiques des données du pool de tampons + Nombre de lectures logiques de l'index du pool de tampons
- Taux de réussite = (1-(P/L)) * 100 %
Niveau d'optimisation de requête DB2
Détermine le temps de travail et les ressources que DB2 consacre à l'optimisation du plan d'accès. Lorsqu'une interrogation de la base de données est exécutée dans DB2, différentes méthodes sont utilisées pour calculer le plan d'accès le plus efficace. Les niveaux disponibles s'échelonnent de 0 à 9. Avec le niveau 9, DB2 utilise beaucoup de temps et la totalité des statistiques dont il dispose pour optimiser le plan d'accès.
- Comment voir et définir : Le niveau d'optimisation peut être défini individuellement pour chaque base de données via la ligne de commande ou à l'aide du Centre de contrôle DB2. Les instructions SQL statiques utilisent le niveau d'optimisation spécifié dans les
commandes prep et bind. Si ce niveau n'est pas spécifié, DB2 utilise l'optimisation par défaut spécifiée
par le paramètre dft_queryopt.
Les instructions SQL dynamiques utilisent la classe
d'optimisation spécifiée par le registre spécial d'optimisation des requêtes, défini à
l'aide de l'instructions SQL Set. Par exemple, l'instruction ci-après permet d'affecter la valeur
1 à la classe d'optimisation.
Set current query optimization = 1
Si le registre d'optimisation des requêtes n'est pas défini, les instructions dynamiques sont liées à l'aide de la classe d'optimisation des requêtes par défaut. - Valeur par défaut : 5
- Valeur recommandée : Définissez le niveau d'optimisation en fonction des besoins de l'application. N'utilisez les niveaux d'optimisation élevés que pour des requêtes très complexes.
Paramètre reorgchk de DB2
Renvoie les statistiques en cours relatives aux données et à la redéfinition des accès. Utilisez ce paramètre car des mises à jour, suppressions ou insertions répétées sont susceptibles de réduire les performances des instructions SQL.
- Comment voir et définir : Utilisez la commande DB2 reorgchk update statistics on table all pour effectuer l'opération runstats sur toutes les tables utilisateur et système de la base de données à laquelle vous êtes actuellement connecté. Redéfinissez les accès aux packages à l'aide de la commande bind. Si des statistiques sont disponibles, exécutez la commande db2 -v "select tbname, nleaf, nlevels, stats_time from sysibm.sysindexes" dans DB2 CLP. S'il n'existe pas de mises à jour des statistiques, nleaf et nlevels correspondent à -1 et stats_time possède une entrée vide (par exemple : "-"). Si la commande runstats a déjà été exécutée, l'horodatage en temps réel généré à la fin de l'opération runstats s'affiche également sous stats_time. Si vous estimez que l'heure affichée pour l'opération runstats précédente est trop ancienne, exécutez de nouveau la commande runstats.
- Valeur par défaut : Aucune
- Valeur recommandée : Aucune
Paramètre locktimeout de DB2
Indique la durée en secondes pendant laquelle une application attend l'obtention d'un verrou. La définition de cette propriété permet d'éviter les interblocages globaux dans les applications.
- Comment afficher et définir : Pour afficher la valeur actuelle de la propriété du délai d'attente d'un verrou pour la base de données xxxxxx, exécutez la commande DB2 get db cfg for xxxxxx et recherchez la valeur LOCKTIMEOUT. Pour affecter à LOCKTIMEOUT la valeur n, exécutez la commande DB2 update db cfg for xxxxxx en utilisant LOCKTIMEOUT n, xxxxxx correspondant au nom de la base de données de l'application et n à la valeur comprise entre 0 et 30 000 inclus.
- Valeur par défaut : -1 (la détection du délai d'attente du verrou est désactivée).
Dans ce cas, une application attend un verrou, si aucun n'est disponible lors de la
demande, jusqu'à ce que l'un des événements suivants se produisent :
- Le verrou est octroyé
- Un interblocage s'est produit
- Valeur recommandée : Si la majorité des accès à votre base de données sont des enregistrements, définissez cette valeur de sorte à recevoir un signal anticipé lorsqu'un délai d'attente est dépassé. Pour cela, une valeur de 30 secondes est recommandée. Si la majorité des accès sont des lectures, acceptez le délai d'expiration du verrou par défaut ou affectez à la propriété une valeur supérieure à 30 secondes.
Paramètre maxlocks de DB2
Spécifie le niveau (en pourcentage) de la liste des verrous atteint lorsque le gestionnaire de base de données procède à l'escalade, de la ligne à la table, pour les verrous détenus par l'application. Le processus d'escalade ne dure pas très longtemps, mais le verrouillage de tables complètes au lieu de simples lignes réduit les accès concurrents et diminue potentiellement les performances générales de la base de données pour les tentatives d'accès ultérieures aux tables affectées.
- Comment afficher et définir : Pour afficher la valeur actuelle de la propriété maxlocks de la base de données xxxxxx, exécutez la commande DB2 get db cfg for xxxxxx et recherchez la valeur MAXLOCKS. Pour affecter à MAXLOCKS la valeur n, exécutez la commande DB2 update db cfg for xxxxxx en utilisant MAXLOCKS n, xxxxxx correspondant au nom de la base de données de l'application et n à la valeur comprise entre 1 et 100 inclus.
- Valeur par défaut : Pour connaître les valeurs par défaut des propriétés en fonction du système d'exploitation, reportez-vous aux informations actuelles sur la base de données.
- Valeur recommandée : Si les escalades de verrous nuisent aux performances, il est recommandé d'augmenter la valeur de ce paramètre ou du paramètre locklist, décrit au paragraphe suivant. Le contrôleur système de la base de données permet de déterminer s'il existe des escalades de verrous.
Paramètre locklist de DB2
Spécifie la quantité de stockage allouée à la liste des verrous.
- Comment afficher et définir : Pour afficher la valeur actuelle de la propriété locklist de la base de données xxxxxx, exécutez la commande DB2 get db cfg for xxxxxx et recherchez la valeur LOCKLIST. Pour affecter à LOCKLIST la valeur n, exécutez la commande DB2 update db cfg for xxxxxx en utilisant LOCKLIST n, xxxxxx correspondant au nom de la base de données de l'application et n à la valeur comprise entre 4 et 60 000 inclus.
- Valeur par défaut : Pour connaître les valeurs par défaut des propriétés en fonction du système d'exploitation, reportez-vous aux informations actuelles sur la base de données.
- Valeur recommandée : Si les escalades de verrous nuisent aux performances, il est recommandé d'augmenter la valeur de ce paramètre ou du paramètre maxlocks, décrit au paragraphe précédent. Le contrôleur système de la base de données permet de déterminer s'il existe des escalades de verrous. Pour plus de détails, reportez-vous au document DB2 Administration Guide: Performance.