Tuning de DB2 pour améliorer la rapidité sur un gros volume de donnée – Partie 1

Afin de bien comprendre le fonctionnement de DB2 et savoir comment améliorer ces performances, il faut commencer par connaitre chacun de ses composants:

• client (db2agent) est le point de contact entre un client et le serveur, un agent sera créé par chaque nouvelle connexion.
• listener i.e. ce qui écoute les points de connexions à DB2: db2ipccm (local), db2tcpcm (distant TCP/IP), db2tcpdm (distant TCP/IP, service répondant aux demandes de découverte de services).
• base de donnée quand un utilisateur se connecte, un client db2agent est créé et va faire l’ensemble des traitements sauf si (comme dans mon cas), vous avez une base de données réparties sur plusieurs disques (i.e. DPF Database Partition Feature) et/ou plusieurs processeurs (i.e. intra_query parallélisme activé). Dans ce cas, db2agent va distribué les tâches à db2agntp (DPF) et db2agnts (intra_query) respectivement. C’est l’agent db2agntp qui va effectivement calculer les requêtes SQL.
• Les sous agents qui sont actuellement lié avec une application mais qui ne sont pas utilisés sont nommés db2agnta.
• db2agnti a comme tâche d’éxecuter les tâches de monitoring d’événements.
• db2agnsc permet de parallélisé le redémarrage d’une base de donnée après un arrêt brutal.
• db2fmp execute les procédures.
• db2vend permet de lancer le logging d’un agent.
• db2pfchr est l’administrateur de la piscine de buffer réservés au prefetch (mise en mémoire de données issues de la base de données).
• db2pclnr permet de gérer les buffer réservés aux pages cleaner (écriture des modifications en mémoire sur le disque).
• db2loggr permet la manipulation de logs afin de permettre le traitement et la reprise en cas de panne.
• db2loggw permet d’écrire les logs dans les fichiers de logs.
• db2logts permet de tracer dans quels fichiers de logs sont stockés les informations relatives à chaque table et le résultat est stocké dans un fichier (DB2TSCHG.HIS). Cela va permettre d’accélérer les étapes de rollfoward.
• db2dlock est l’agent en charge de la détection des deadlocks. Dans un environnement multipartitions, un agent db2glock est également présent pour coordonner les informations de chaque db2dlock sur chaque partition de la base de donnée. db2glock tourne lui au niveau du catalog.
• db2taskd est l’agent en charge de la distribution des agents de fond de tâches. Ces tâches sont exécutées de manière threader par db2taskp.
• db2hadrp est le thread du serveur primaire HADR (High Availability Disaster Recovery i.e. reprise sur panne avec support de la disponibilté).
• db2hadrs est le thread du serveur secondaire HADR.
• db2lfr est l’agent en charge de la lecture de la lecture des fichiers de logs.
• db2shred permet de traiter individuellement chaque ligne des fichiers de logs.
• db2redo (pour redo master) permet pendant une phase de reprise sur pannes d’éxecuter les tâches de reprise à proprement dite.
• db2redow (pour redo worker) exécute les instructions que lui donne db2redo.
• db2logmgr prend en charge le management des fichiers de logs pour la restauration de la base de données.
• db2wlmd permet le calcul automatique de statistiques sur la base de données et sur les calculs effectués.
• un ensemble d’agent de monitoring d’événements nommé db2evm$1$2$3 avec $1 égale à g pour moniteur d’événements globaux, l pour moniteur d’événements locaux, t pour table, gp pour les tubes globaux, lp pour les tubes locaux. %2 permet de désigner si l’agent est coordinateur (i) ou non (p). Et finalement $3 est le nom du moniteur d’événements.
• un ensemble d’agent de sauvegarde et restauration pour les contrôleurs de données db2med$1$2 et pour les manipulations de buffer db2bm$1$2. Dans ces deux cas, $1 correspond à l’EDU ID de l’agent qui contrôle la sauvegarde ou la restauration et $2 permet de différencier les threads les uns par rapport aux autres.
• db2resync est l’agent en charge de la lecture des listes de demande de resynchronisation.
• db2wdog est un “watchdog” Unix/Linux permettant de gérer les fins de programmes anormales.
• db2fcms est le daemon d’envoi du protocole de communication rapide de management.
• db2fcmr est le daemon de réception du protocole de communication rapide de management.
• db2pdbc est l’agent de contrôle du parallélisme qui va prendre en charge les demandes de requêtes provenant de neouds distants. Il est utilisé uniquement dans le cas de base de données multipartitions.
• db2cart est l’agent chargé de l’archivage des fichiers de logs quand on accéde à la base de données en utilisant le mode USEREXIST.
• db2fmtlg est en charge du formatage des fichiers de logs quand on accéde à la base de donnée en utilisant le mode LOGRETAIN et sans le mode USEREXIST.
• db2panic permet de prendre en charge les requêtes urgentes après quand le nombre d’agent limite est atteint sur un noeud particulier (utiliser uniquement dans le cas d’une base de donnée monopartition).
• db2srvlst prend en charge la liste des adresses dans les systèmes tel que DB2 for z/ OS.
• db2fmd est le moniteur d’erreurs.
• db2disp est le dispatcheur de connexion client.
• db2acd est l’agent qui calcule automatiquement la quantité de ressources et le bon fonctionnement de la base mais également il surveille le bon fonctionnement des agents de maintenances automatiques.
• db2licc est en charge du management des licenses.
• db2thcln permet de réutiliser/recycler les ressources quand un agent a fini son exécution.
• db2aiothr permet de gérer les demandes d’entrées/sorties asynchrones dans la partition de la base de données.
• db2alarm notifie les autres EDU quand leur timer de requête a expiré.
• db2sysc est l’agent principal en charge du contrôle des autres EDU et qui prend en charge les erreurs critiques sur le serveur.