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:Una búsqueda rápida de elementos de interés en el resultado de la instantánea produce lo siguiente:
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.txtApplication 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)