Blocages dans une base de données DB2

Optimiser votre base de données pour minimiser les conflits d'E/S de disque aidera à limiter les blocages, mais il peut encore arriver que l'appel de procédure stockée new_edit_state génère un blocage de l'application appelante et bloque toute autre utilisation de la base de données ArcSDE.

Imaginez un scénario dans lequel la procédure stockée acquiert un grand nombre de verrous de lignes sur la table STATE_LINEAGES, dépassant le nombre maximal de verrous et essayant de poser un verrou de table exclusif. Malheureusement, la requête de l'application appelante comporte déjà un verrou partagé sur la table STATE_LINEAGES, ce qui mène à un blocage. Les nombres élevés de blocages de lignes surviennent d'une généalogie d'état étendue. Ceci, outre un paramètre bas de taille de la liste des verrous, garantit les problèmes. Etant donné la manière dont la promotion de verrous est gérée, d'autres scénarios de blocage sont également possibles.

L'implication ici est que les blocages peuvent ne pas être un événement rare sur certains sites, selon les applications et la configuration de base de données. Encore une fois, notez que le problème peut être aggravé par des généalogies d'état étendues.

Heureusement, IBM DB2 fournit des paramètres d'optimisation permettant de contrôler la taille de la liste de verrous (LOCKLIST), le pourcentage maximal de verrous qu'une application peut contenir (MAXLOCKS), la durée d'attente d'une requête pour l'acquisition d'un verrou (LOCKTIMEOUT), l'intervalle de détection entre deux blocages (DLCHKTIME) et le comportement de l'annulation d'un blocage (DB2LOCK_TO_RB).

Brièvement, pour augmenter la capacité de la liste des verrous et le seuil de promotion de verrous, modifiez les paramètres LOCKLIST et MAXLOCKS.

La valeur par défaut pour LOCKLIST et MAXLOCKS dans DB2 9 est AUTOMATIC, ce qui a pour effet d'activer le réglage automatique de ces paramètres. Cela permet au système de réglage de mémoire DB2 de dimensionner dynamiquement les ressources de mémoire entre les différents consommateurs. Le réglage automatique de la mémoire se produit uniquement si cette option est activée pour la base de données (SELF_TUNING_MEM=ON).

En outre, vous pouvez peut-être améliorer l'accessibilité simultanée au moyen de l'annulation de verrou en utilisant les variables de registre Lock Deferral de DB2, DB2_EVALUNCOMMITED, DB2_SKIPDELETED et DB2_SKIPINSERTED. Ces variables du registre permettent aux analyses d'ignorer, de manière inconditionnelle, les suppressions et insertions non validées.

Par défaut, une temporisation de verrou annule la transaction de requête. Pour changer ce comportement afin d'annuler uniquement l'instruction à l'origine de la requête de verrou, modifiez DB2LOCK_TO_RB avec db2set DB2LOCK_TO_RB=STATEMENT. Cependant, le comportement par défaut convient normalement à ArcSDE.

Consultez la documentation ou les manuels d'optimisation des performances DB2 pour obtenir des informations détaillées sur la définition correcte de ces paramètres. Une présentation de l'utilisation de ces paramètres est fournie ci-dessous.

Diagnostic des problèmes de verrous

Quelques outils utiles pour diagnostiquer les problèmes de verrous sont décrits ci-dessous.

Paramètres ayant trait aux blocages

Pour afficher les paramètres de la liste des verrous, exécutez la commande suivante :

db2 get db cfg

Voici un exemple des informations retournées à la suite de l'exécution de cette commande :

Max storage for lock list (4KB)		(LOCKLIST) = 50
Interval for checking deadlock (ms)	(DLCHKTIME) = 10000
Percent. of lock lists per application	(MAXLOCKS) = 22
Lock time out (sec)			(LOCKTIMEOUT) = -1
Max number of active applications	(MAXAPPLS) = AUTOMATIC

Consultez le Centre d'informations DB2 IBM pour plus d'informations sur la définition de ces paramètres.


3/6/2012