La edición versionada en rama puede encontrar bloqueo protección (locking), bloqueo (blocking) e interbloqueo (deadlocking) cuando los datos están almacenados en una geodatabase corporativa en SQL Server

Descripción

Las aplicaciones cliente de ArcGIS pueden encontrarse comportamientos de bloqueo protección (locking), bloqueo (blocking) e interbloqueo (deadlocking) al editar datos versionados en rama almacenados en una geodatabase corporativa en SQL Server. Estos problemas de bloqueo protección (locking) pueden dar lugar a errores durante la edición y la posible pérdida de ediciones.  

Causa

El bloqueo (blocking) es una característica inevitable y de diseño de cualquier sistema de gestión de bases de datos relacionales (RDBMS) con concurrencia basada en bloqueos de protección.En SQL Server, el bloqueo (blocking) ocurre cuando una sesión mantiene un bloqueo de protección sobre un recurso específico y una segunda sesión intenta adquirir un tipo de bloqueo de protección en conflicto sobre el mismo recurso.La duración y el contexto de la transacción de una consulta determinan el tiempo que se mantienen sus bloqueos de protección y, por tanto, su impacto en otras consultas.

• Si la consulta no se ejecuta dentro de una transacción (y no se utilizan sugerencias de bloqueo), los bloqueos de las declaraciones SELECT solo se mantendrán sobre un recurso en el momento en que se esté leyendo, no mientras dure la consulta. Para las declaraciones INSERT, UPDATE y DELETE, los bloqueos se mantienen durante la consulta, tanto para garantizar la coherencia de los datos como para permitir deshacer la consulta si es necesario.

• Para las consultas ejecutadas dentro de una transacción, la duración del mantenimiento de los bloqueos viene determinada por el tipo de consulta, el nivel de aislamiento de la transacción y si se utilizan sugerencias de bloqueo en la consulta.  

Las aplicaciones de ArcGIS editarán los datos versionados en rama mediante transacciones y con READ COMMITTED SNAPSHOT ISOLATION (RCSI). La arquitectura del versionado en rama consigue que dos sesiones nunca editen la misma fila dentro de una tabla determinada, pero en ocasiones el optimizador de SQL Server puede decidir utilizar bloqueos de página en lugar de bloqueos de fila e incluso ocasionalmente puede elegir o escalar aún más hasta un bloqueo de tabla.

Solución alternativa

Si encuentra problemas relacionados con la página exclusiva y los bloqueos de tabla que dan lugar a bloqueos graves y un comportamiento de bloqueo al trabajar con datos versionados en rama en SQL Server, póngase en contacto con Soporte técnico de Esri para proporcionar los detalles de su problema de problema de bloqueo y mencionar el BUG-000138033. Si se confirma el comportamiento de bloqueo, se puede proporcionar un script para deshabilitar los bloqueos de página y el escalado del bloqueo para estas tablas.

Nota: La posibilidad de encontrar un error 1204 de SQL Server aumenta después de implementar esta estrategia de bloqueo. Esto indica que SQL Server no puede obtener un recurso LOCK en este momento, que el procesamiento de la declaración actual se detuvo y que se revierte la transacción. Esta reversión en sí misma también puede bloquear a los usuarios o puede dar lugar a un largo tiempo de recuperación de la base de datos si se reinicia el servicio de SQL Server.

Nota: ALTER INDEX …REORGANIZE no es compatible con índices con ALLOW_PAGE_LOCKS configurados como OFF.

Nota: Las clases de entidad registradas como versión en rama mediante ArcGIS Pro 2.8 o versiones posteriores tendrán esta configuración de bloqueo de forma predeterminada en SQL Server. Si una clase de entidad se registra como versionada en rama (o se agregan nuevos índices a una clase versionada en rama) mediante versiones anteriores a la 2.8, se debe ejecutar el script mencionado anteriormente para configurar este esquema de bloqueo de fila.