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 nombre élevé de verrous de ligne sur la table STATE_LINEAGES, dépasse le seuil du nombre maximal de verrous et tente une promotion vers un verrou de table exclusif. Malheureusement, la requête de l’application qui appelle détient déjà un verrou partagé sur la table STATE_LINEAGES, ce qui entraîne un blocage. Les nombres élevés de verrous de ligne sont dûs à une généalogie d’états étendue. Associés à une taille de liste des verrous peu élevée, c'est la garantie de problèmes futurs. Selon le mode de traitement de promotion des verrous, 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 des 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).

En résumé, 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 d’optimisation de la 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 grâce aux variables de registre Lock Deferral de Db2 DB2_EVALUNCOMMITED, DB2_SKIPDELETED et DB2_SKIPINSERTED. Ces variables de 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 est normalement 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 liés aux 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 des instantanés pour obtenir des informations sur les verrous 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)