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.

• Rechercher les ID d'application db2 pour les processus SDE

  SELECT  appl_id 
  FROM  TABLE(SNAPSHOT_APPL_INFO('SDE',-1)) 
  AS SNAPSHOT_APPL_INFO 
  WHERE appl_name LIKE 'gsrvr%'
  
  SELECT  appl_id,appl_name 
  FROM  TABLE(SNAPSHOT_APPL_INFO('SDE',-1)) 

• Utilisez les instantanés pour les informations de verrou et d'application ; par exemple :

  db2 get snapshot for locks on sde > all_locks.txt
  
  db2 get snapshot for locks for application applid
  '*LOCAL.DB2.00AB42215335' > app_locks.txt
  
  db2 get snapshot for application applid '*LOCAL.DB2.00AB42215335' > app_info.txt

  Une recherche rapide des éléments pertinents au niveau de la sortie de l'instantané produit les résultats suivants :

  Application status = Lock-wait
   Locks held by application = 1254
   Number of SQL requests since last commit = 12
   Open local cursors = 1
   Most recent operation = Execute
  
   Object type	= Table
   Tablespace name	= USERSPACE1
   Table schema	= SDE
   Table name	= STATE_LINEAGES
   Mode = X
   Status	 = Converting
   Current mode = IX
   Lock escalation	= YES

• Comme indiqué ci-dessus, les généalogies étendues peuvent poser problème pour l'acquisition d'un grand nombre de verrous de ligne. Les instructions SQL suivantes peuvent permettre une vérification rapide des étendues de généalogie et de l'étendue maximale de généalogie :

  SELECT COUNT (*) 
  FROM state_lineages 
  GROUP BY lineage_name
  
  SELECT MAX(a.depth) 
  FROM (SELECT COUNT (*) FROM state_lineages GROUP BY lineage_name) a(depth)

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.