Blocages dans une base de données DB2

L'optimisation de 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 géodatabase.

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.

Cela sous-entend que les blocages peuvent se produire de temps en temps sur certains sites, selon votre application et la configuration de la 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 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. Le comportement par défaut doit être suffisant pour les géodatabases dans DB2.

Reportez-vous à la documentation DB2 disponible dans IBM Knowledge Center pour obtenir des informations détaillées sur la configuration de ces paramètres.

Vous trouverez dans la section suivante des conseils pour diagnostiquer les blocages.

Diagnostic des problèmes de verrous

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

• Recherchez les ID d'application db2 pour les processus ArcGIS.

  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)