Bloqueos mutuos en una base de datos de Db2

La configuración de la base de datos para reducir el contenido de E/S en el disco ayuda a reducir los bloqueos mutuos. Sin embargo, es posible que la ejecución del procedimiento almacenado new_edit_state produzca bloqueos mutuos en la aplicación invocada y bloquee los demás usos de la geodatabase.

Imagine una situación en la que el procedimiento almacenado adquiere una gran cantidad de bloqueos de fila en la tabla STATE_LINEAGES, que supera el umbral de cantidad máxima y que tiende a escalar a un bloqueo de tabla exclusivo. Lamentablemente, la consulta de la aplicación que se invoca ya cuenta con un bloqueo compartido en la tabla STATE_LINEAGES, lo que producirá un bloqueo mutuo. Se producirán grandes cantidades de bloqueos de fila por tener un amplio linaje de estado. Esto, sumado a que se cuenta con una configuración limitada para el tamaño de la lista de bloqueo, garantiza que habrá problemas. Pueden darse otras situaciones de bloqueos mutuos, debido al modo de control de la extensión de bloqueos.

Esto quiere decir que los bloqueos mutuos pueden ser comunes en algunos sitios, lo que depende de su aplicación y de la configuración de la base de datos. También aquí, el problema puede agravarse con linajes de estados amplios.

Afortunadamente, IBM Db2 brinda parámetros de ajuste para controlar el tamaño de la lista de bloqueo (LOCKLIST), el porcentaje máximo de bloqueos que puede mantener una aplicación (MAXLOCKS), la cantidad de tiempo que una solicitud espera antes de que se adquiera un bloqueo (LOCKTIMEOUT), el intervalo de frecuencia para la detección de bloqueos mutuos (DLCHKTIME) y el comportamiento de reversión de los bloqueos mutuos (Db2LOCK_TO_RB).

Rápidamente, para aumentar la capacidad de la lista de bloqueo y el umbral de extensión de bloqueo, modifique los parámetros LOCKLIST y MAXLOCKS respectivamente.

El valor predeterminado para LOCKLIST y MAXLOCKS es AUTOMATIC, lo que permite el ajuste automático de estos parámetros. Esto permite que el regulador de memoria de Db2 dimensione dinámicamente los recursos de memoria de los diferentes consumidores de memoria. El ajuste automático se produce sólo cuando la memoria con esta función está habilitada en la base de datos (SELF_TUNING_MEM=ON).

Además, es posible mejorar la concurrencia a través de la prevención de bloqueos. Para ello, debe utilizar las variables de registro de aplazamiento de bloqueos de Db2: Db2_EVALUNCOMMITED, Db2_SKIPDELETED y Db2_SKIPINSERTED. Estas variables permiten que se salteen las eliminaciones e inserciones no confirmadas durante el escaneo.

Por defecto, un tiempo de espera de bloqueo elimina la transacción de solicitud. El comportamiento predeterminado debe ser suficiente para las geodatabases en Db2.

Consulte la documentación de Db2 en el IBM Knowledge Center para obtener información detallada sobre la forma de definir correctamente estos parámetros.

La sección que aparece a continuación proporciona sugerencias para el diagnóstico de bloqueos mutuos.

Diagnosticar problemas de bloqueo

A continuación se detallan algunas de las herramientas útiles para diagnosticar problemas de bloqueo.

• Busque las Id. de aplicación de db2 para procesos de 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))
  

• Para la información de aplicaciones y bloqueos, utilice instantáneas. Por ejemplo:

  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
  

  Una búsqueda rápida de elementos de interés en el resultado de la instantánea produce lo siguiente:

  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

• Como se explicó anteriormente, los linajes amplios pueden resultar problemáticos cuando se adquiere una gran cantidad de bloqueos de fila. Las sentencias SQL que se presentan a continuación pueden brindar una rápida verificación de las amplitudes de linaje y de su límite de amplitud:

  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)