Comprimir una geodatabase en Oracle puede dar lugar a condiciones de bloqueo en ArcGIS, lo que provoca que deje de responder

Descripción

Los usuarios que editan una clase versionada pueden encontrar condiciones de bloqueo en Oracle cuando la geodatabase versionada se comprime. La experiencia del usuario con ArcGIS cuando se bloquea una sesión de Oracle es que la aplicación no responde.

Nota: El software de ArcSDE, incluido el servidor de aplicaciones, las herramientas de comando y el SDK con API de C y Java, quedó obsoleto en ArcGIS 10.2.2 y ya no se distribuye.

La situación solo puede ocurrir cuando el usuario de edición realiza una actualización o eliminación versionada con la misma clase versionada que la geodatabase comprime actualmente o cuando el propio proceso de compresión se bloquea esperando la compresión.

La duración de la condición de bloqueo depende de la duración de la sesión de edición, que actualmente mantiene el bloqueo en la clase versionada o la duración de la transacción de la operación de compresión para una clase específica.

Causa

Para garantizar la coherencia de los datos versionados mientras los usuarios editan y realizan una operación de compresión, se deben adquirir bloqueos en la tabla de borrados de una clase versionada para garantizar la coherencia de la lectura.

Debido a que Oracle utiliza un modelo de bloqueo optimista en el cual los escritores no bloquean a los lectores, para garantizar que una sesión no lea una fila mientras una segunda sesión actualiza la fila, la aplicación debe implementar un modelo de bloqueo para evitar situaciones competitivas.

ArcGIS evita la condición de competición al colocar un bloqueo exclusivo de fila en la tabla de borrados de una clase versionada al realizar una actualización o eliminación, mientras que la operación de compresión obtiene un bloqueo de modo de uso compartido en la tabla de borrados de la clase versionada al recortar la tabla. Ambos bloqueos solo se mantienen lo que dure la transacción que se realiza. En el caso de que una aplicación realice una actualización o eliminación, la duración de la transacción es el tiempo de la operación de edición (al llamar a stopeditoperation, se confirma la transacción; aborteditoperation deshace la transacción). La compresión mantiene el bloqueo solo mientras se comprime la tabla individual, no la duración de toda la operación de compresión.

El bloqueo exclusivo de filas no deriva en condiciones de bloqueo cuando varios usuarios editan una clase versionada. Solo bloquea la operación de compresión, como hace el bloqueo de la operación de compresión que impide a los editores realizar actualizaciones y eliminaciones.

Una vez que la compresión obtiene el bloqueo del modo de uso compartido, no se bloqueará a los editores para operaciones de actualización o eliminación. La experiencia del usuario final es que la aplicación no responde. La duración del bloque depende totalmente del tiempo requerido para que la compresión recorte la tabla versionada, que se relaciona directamente con el volumen de filas en la clase que se recorta y elimina (si una organización se comprime con frecuencia/cada noche, el volumen debe ser mínimo).

Otra condición que puede derivar en condiciones de bloqueo es cuando un editor obtuvo el bloqueo exclusivo de fila en la clase, pero no detuvo su operación de edición (lo que resulta en una confirmación y eliminación del bloqueo). Si la sesión de edición conserva el bloqueo durante periodos de tiempo prolongados (posiblemente debido al volumen de datos que se actualizan o eliminan), la sesión del editor bloqueará la operación de compresión. Una vez bloqueada la operación de compresión, Oracle mantiene una cola de sesiones primero en entrar/primero en salir que solicitan bloqueos. Por lo tanto, la compresión está bloqueada por la sesión de edición y la solicitud de compresión bloquea otras sesiones de edición que solicitan el bloqueo. Este efecto en cascada es un comportamiento esperado en Oracle (el único mecanismo para garantizar que las solicitudes de bloqueo se procesen en orden).

El resultado final del comportamiento de bloqueo es el impacto que pueda tener sobre los editores y las esperas extendidas al solicitar bloqueos para garantizar la coherencia de los datos.

Solución o solución alternativa

Programe la operación de compresión para que se ejecute durante las horas de producción fuera de las horas punta cuando pocos usuarios editan clases versionadas.

Si uno descubre que la operación de compresión provoca condiciones de bloqueo en la instancia de Oracle, lo que evita que los usuarios editen, es seguro finalizar la sesión ejecutando el comando de compresión.

La operación de compresión se ha escrito para que sea consistente de manera transaccional, lo que garantiza la integridad de los datos si alguna vez se anula el proceso.