Exemple : Enquête sur une augmentation des escalades de blocage à l'aide du moniteur d'événements de l'historique des modifications

Vous pouvez utiliser le moniteur d'événements de l'historique des modifications pour détecter les modifications susceptibles d'avoir entraîné une dégradation des performances de la base de données.

Scénario

Dans cet exemple, les utilisateurs signalent une baisse des performances de la base de données. L'administrateur de la base de données (DBA) remarque qu'un nombre anormalement élevé d'escalades de verrous s'est produit au cours des dernières 24 heures. Le DBA constate également une augmentation correspondante des temps d'attente des verrous d'application au cours de la même période.

L'administrateur de bases de données a surveillé les changements de configuration, les changements d'index et les opérations de chargement à l'aide d'un moniteur d'événements de l'historique des changements. Le moniteur d'événements a été créé avec l'instruction suivante :

    CREATE EVENT MONITOR CFGHIST 
    FOR CHANGE HISTORY WHERE EVENT IN (DBCFG, DBMCFG, DBCFGVALUES,
         DBMCFGVALUES,REGVAR,REGVARVALUES, DDLDATA, LOAD)
    WRITE TO TABLE

Le moniteur d'événements a été activé avec la déclaration suivante :

    SET EVENT MONITOR CFGHIST STATE=1

Le tableau suivant présente des exemples de données que le moniteur d'événements CFGHIST peut écrire dans la table CHANGESUMMARY_CFGHIST. Tous les moniteurs d'événements de l'historique des modifications écrivent dans le groupe de données logique CHANGESUMMARY. Comme décrit dans le groupe de données logiques CH ANGESUMMARY , le groupe de données logiques CHANGESUMMARY renvoie un certain nombre d'éléments de moniteur d'événements qui résument les événements capturés, seul un sous-ensemble de ces éléments est présenté dans la sortie suivante. Le nom de la table est obtenu en concaténant le nom du groupe de données logique utilisé pour alimenter la table (CHANGESUMMARY) et le nom donné au moniteur d'événements dans l'instruction CREATE EVENT MONITOR (CFGHIST).

APPL_ID                      APPL_NAME .... EVENT_ID EVENT_TIMESTAMP    
---------------------------- --------- .... -------- -------------------
*LOCAL.tripathy.111028110756 db2bp     .... 1        28/10/2011 07:12:02  

EVENT_TYPE MEMBER ....
---------- ------ ....
EVMONSTART 0      ....

Étant donné que les performances n'étaient pas un problème auparavant, l'administrateur de bases de données soupçonne qu'une modification récente pourrait être à l'origine du problème et effectue les opérations suivantes :

Vérifiez le groupe de données logiques CHANGESUMMARY pour voir si des modifications ont été apportées au cours des dernières 24 heures. Pour cet exemple, supposons que l'heure actuelle est le 31/10/2011 06:00:00.
```
 SELECT EVENT_TYPE FROM CHANGESUMMARY_CFGHIST
    WHERE EVENT_TIMESTAMP > CURRENT TIMESTAMP - 24 HOURS
```
La requête renvoie le résultat suivant :
```
  EVENT_TYPE
  ----------
  DBCFG
  DBCFG
```
La sortie indique qu'il y a eu deux mises à jour de la configuration de la base de données au cours des dernières 24 heures.
Interrogez le groupe de données logiques DBDBMCFG pour obtenir les détails des modifications de configuration.

 SELECT EVENT_TIMESTAMP, CFG_NAME, CFG_VALUE, CFG_OLD_VALUE, DB_DEFERRED
    FROM DBDBMCFG_CHGHIST

La requête renvoie le résultat suivant :

  EVENT_TIMESTAMP       CFG_NAME      CFG_VALUE   CFG_OLD_VALUE   DB_DEFERRED
  -------------------   -----------   ---------   -------------   -----------
  30/10/2011 08:41:39   LOCKLIST           1024            2048   N 
  30/10/2011 08:42:35   LOCKTIMEOUT           0              -1   Y

Le résultat indique que des changements de fermeture ont été effectués pendant la période où les performances ont baissé.

L'administrateur de bases de données remarque que la modification de LOCKTIMEOUT a été différée et lance une requête pour vérifier si la base de données a été activée après cette modification de la configuration. Ce contrôle permet de déterminer si la modification de la configuration a été prise en compte par la base de données. Si la modification n'a pas été prise en compte, il est peu probable qu'elle soit à l'origine du problème de performance. L'heure d'activation de la base de données est enregistrée dans le groupe de données logiques EVMONSTART. Tous les moniteurs d'événements de l'historique des modifications écrivent par défaut dans le groupe de données logique EVMONSTART.

   SELECT COUNT (*)as POST_CFG_ACTIVATIONS FROM EVMONSTART_CHGHIST
      WHERE DB_CONN_TIME > TIMESTAMP(2011-10-30-08:42:35)

La requête renvoie une valeur non nulle.

  POST_CFG_ACTIVATIONS
  --------------------
                     1

Cette valeur non nulle confirme que la base de données a été activée après la modification du paramètre de configuration LOCKTIMEOUT, ce qui signifie que la nouvelle valeur est en vigueur. L'administrateur de bases de données comprend maintenant ce qui a changé sur le système et peut essayer d'ajuster les paramètres de configuration liés au verrouillage à leurs valeurs d'origine pour voir si cela résout le problème.

Remarque : si le moniteur d'événements de l'historique des modifications était inactif lorsque les paramètres de configuration ont été modifiés, le moniteur d'événements ne capturera pas les événements DBCFG. Au lieu de cela, le moniteur d'événements de l'historique des modifications capturerait un événement DBCFGVALUES au démarrage du moniteur d'événements. Dans le groupe de données logiques DBDBMCFG, chaque ligne représente un paramètre de configuration mis à jour dans le cadre d'un événement DBCFG ou DBMCFG, ou capturé au démarrage du moniteur d'événements dans le cadre d'un événement DBCFGVALUES ou DBMCFGVALUES. L'élément de moniteur CFG_COLLECTION_TYPE indique si l'enregistrement décrit une mise à jour des paramètres de configuration ou une valeur initiale enregistrée au démarrage du moniteur d'événements. L'administrateur de bases de données devra comparer les valeurs capturées au début du moniteur d'événements de l'historique des modifications actuel avec les valeurs de la capture précédente afin de rechercher les valeurs modifiées susceptibles d'être à l'origine du problème. Il serait également utile d'examiner le journal de diagnostic.