Interbloqueos en una base de datos DB2

La configuración de la base de datos para reducir el contenido de E/S en el disco ayuda a reducir los interbloqueos. Sin embargo, es posible que la ejecución del procedimiento almacenado new_edit_state produzca interbloqueos en la aplicación invocada y bloquee a 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 interbloqueo. 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 interbloqueos, debido al modo de control de la extensión de bloqueos.

Esto quiere decir que los interbloqueos pueden ser comunes en algunos sitios, lo que depende de la aplicación y de la configuración de la base de datos. Una vez más, 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 interbloqueos (DLCHKTIME) y el comportamiento de reversión de los interbloqueos (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 de 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 le de tamaño de manera dinámica a los recursos de memoria de los diferentes consumidores de esta. El ajuste automático se produce solo cuando la memoria con esta función está habilitada en la base de datos (SELF_TUNING_MEM=ON).

Además, puede 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 debería ser suficiente para las geodatabases de DB2.

Consulte la documentación de DB2 en IBM Knowledge Center para obtener información sobre la correcta configuración de estos parámetros.

En la sección siguiente se ofrecen algunos consejos para diagnosticar interbloqueos.

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 correspondientes a los 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 instrucciones de 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)