La operación de compresión de la geodatabase

La operación de compresión de la geodatabase quita las filas y los estados que no son necesarios de las tablas del sistema que rastrean las versiones y las ediciones versionadas.

SugerenciaSugerencia:

Para entender la compresión, primero debe comprender cómo funciona la versión. Si no está familiarizado con este concepto, consulte Un rápido recorrido por las versiones.

¿Qué es una operación de compresión?

La operación de compresión quita los estados a los que una versión ya no hace referencia, y puede mover las filas de las tablas delta a la tabla de negocios. Una operación de compresión solo la puede realizar un administrador de geodatabase y funciona con todos los estados en la geodatabase, independientemente del propietario de la versión.

Las operaciones de compresión son necesarias porque, como con el transcurso del tiempo la geodatabase se edita, las tablas delta aumentan de tamaño y aumenta la cantidad de estados. Mientras más grandes sean las tablas y más estados tengan, más datos debe procesar ArcGIS cada vez que se visualiza o consulta una versión. Por lo tanto, el mayor impacto en el rendimiento no es la cantidad de versiones sino la cantidad de cambios contenidos en las tablas delta para cada versión. Como resultado, las versiones pueden tener diferentes tiempos de respuesta a la consulta.

Para mantener el rendimiento de la base de datos, el administrador de la geodatabase debe ejecutar una operación de compresión periódicamente para quitar los datos sin utilizar.

Puede usar el comando Comprimir de ArcGIS for Desktop o la herramienta de geoprocesamiento Comprimir o la secuencia de comandos de Python para comprimir una geodatabase. Consulte Comprimir una geodatabase corporativa para información acerca de la compresión de una geodatabase desde el Árbol de catálogo o Comprimir para obtener información sobre la herramienta de geoprocesamiento o la secuencia de comandos.

¿Qué sucede durante una operación de compresión?

Primero la operación de compresión escanea en la memoria la configuración de la jerarquía de estado de la instancia. Con esta información, la compresión elimina todos los estados que no participan dentro de un linaje de versión. Al eliminar un estado se eliminan todas las filas de las tablas delta que están asociadas con ese estado.

El próximo paso que realiza la operación de compresión es contraer cualquier linaje candidato de estados en un estado. Un linaje candidato es un conjunto de estados que se pueden comprimir en un estado sin que afecte la representación lógica de ninguna tabla en una versión dada.

El paso final, cuando corresponde, es mover las filas de las tablas delta a las tablas base (o de negocios).

Por cada paso de la operación, se inician y se detienen transacciones de la base de datos para cada tabla que se comprime. La transacción verifica que cada tabla sea consistente durante cada paso del proceso.

La operación de compresión se puede detener mientras se está ejecutando porque la operación está diseñada para ser consistente de manera transaccional. Por lo tanto, si la operación encuentra un error, falla o finaliza abruptamente, las tablas versionadas que se están comprimiendo siguen siendo lógicamente correctas con respecto a la representación de cualquier versión. Un motivo por el que puede detener la operación de compresión es si la ejecuta cuando los usuarios están conectados a la geodatabase y después descubre que la compresión consume una gran cantidad de recursos del sistema. En ese caso, puede desear detener la operación de compresión y ejecutarla nuevamente cuando haya menos o ningún usuario conectado.

Asegúrese de crear suficientes registros lógicos como para manejar la transacción más larga. Por lo general, cuando comprime una geodatabase, ocurren transacciones largas. Debe hacer una copia de seguridad de los registros lógicos antes de alcanzar el porcentaje de valor máximo de la transacción larga definido por el parámetro LTXHWM en el archivo onconfig de Informix. No debe cambiar los parámetros LTXHWM o LTXEHWM sin el consentimiento de un experto en soporte técnico de Informix que conozca el comportamiento de Informix Spatial DataBlade. Si una transacción no se puede completar y se vuelve atrás porque alcanza el valor máximo de la transacción larga, no posee suficientes registros lógicos.

Durante la compresión de geodatabases largas, la base de datos de Informix se suele quedar sin bloqueos disponibles. Para evitar esto, durante la compresión las tablas se bloquean en un modo exclusivo. Si desea comprimir con conexiones de usuario existentes, se debe deshabilitar el bloqueo exclusivo durante la compresión. El parámetro USE_EXCLUSIVE_LOCKING DBTUNE se puede establecer en falso para permitir la compresión con conexiones de usuario concurrentes. Puede alterar el valor del parámetro USE_EXCLUSIVE_LOCKING con la operación de modificación sdedbtune. Consulte la Referencia de comandos de administración, que se instala con el servidor de aplicaciones de ArcSDE o los Comandos de administración para obtener detalles acerca de cómo usar este comando.

Comprimir por completo una geodatabase

En una geodatabase completamente comprimida, no hay filas en las tablas delta y la jerarquía de estado está recortada en cero. La mejora en el rendimiento es mayor si la geodatabase está comprimida por completo. Para lograrlo, realice lo siguiente:

Puede ver los resultados de cada operación de compresión en la tabla COMPRESS_LOG en la geodatabase (SDE_compress_log en las geodatabases en SQL Server y PostgreSQL). También puede verificar la tabla VERSIONS (SDE_versiones en las geodatabases en SQL Server y PostgreSQL) para ver si el Id. de estado de la versión DEFAULT ha regresado a cero. Si es así y no hay otras versiones pendientes, se ha logrado la compresión completa.

Tal vez no sea siempre posible conciliar, publicar, eliminar versiones y desconectar a todos los usuarios antes de la operación de compresión. Por ejemplo, si está rastreando el historial mediante versiones o necesita mantener las versiones de diseño para un proyecto, las versiones de diseño e históricas permanecen ancladas a un estado en la jerarquía de estado y, por lo tanto, estos estados no se quitarán durante la compresión de la geodatabase. Puede comprimir correctamente sin realizar todos estos pasos y aún verá algunas mejoras en el rendimiento.

Frecuencia de las operaciones de compresión

La frecuencia con que debe realizar una operación de compresión está basada en la cantidad de modificaciones que ocurren en la geodatabase. Si tiene un alto volumen de modificaciones, es posible que deba comprimir la geodatabase una vez al día. Para volúmenes de edición promedio o bajos, debe comprimirla al menos una vez por semana.

NotaNota:

Es importante que no deje pasar mucho tiempo entre las operaciones de compresión, porque mientras ocurre una mayor cantidad de actividad de edición versionada, más tiempo se tarda en comprimir la geodatabase. Si no comprime la geodatabase al menos una vez por semana, la compresión puede tardar varias horas hasta completarse cuando finalmente la ejecute.

Después de comprimir una geodatabase

Debe actualizar las estadísticas de la geodatabase después de ejecutar una operación de compresión. El administrador de la geodatabase debe actualizar las estadísticas en las tablas del sistema y los usuarios individuales pueden actualizar estadísticas en los datasets que se editaron. Para más información sobre la actualización de estadísticas, consulte Uso de la herramienta Analizar datasets para actualizar las estadísticas en las tablas del sistema de la geodatabase o Actualizar estadísticas en una geodatabase mediante Analizar.

9/11/2013