Desktop Help 10.0 - 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.

Sugerencia:

Para entender la compresión, primero debe comprender cómo funciona la versión. Si no está familiarizado con este concepto, consulte Comprender 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. La operación de compresión sólo la puede realizar un administrador de ArcSDE 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 ArcSDE debe ejecutar una operación de compresión periódicamente para quitar los datos sin utilizar.

Para comprimir una geodatabase puede utilizar el comando Comprimir de ArcCatalog, la herramienta de geoprocesamiento Comprimir o la secuencia de comandos de Python. Consulte Agregar el comando Comprimir a ArcCatalog para obtener información sobre cómo hacer que el comando Comprimir esté disponible en ArcCatalog 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, comprime y elimina todos los estados que no participan del linaje de una 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 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, o eliminar, 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 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. Con ArcSDE 9, se puede ejecutar la compresión con conexiones de usuario existentes. Para poder 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 suministrada con el componente ArcSDE de ArcGIS Server Enterprise para obtener detalles sobre cómo utilizar 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:

Concilie y publique todos los cambios pendientes de las versiones secundarias en la versión DEFAULT.
Elimine las versiones mismas.
Asegúrese de que ningún usuario esté conectado.*
Realice la operación de compresión.

*Los servicios de ArcIMS (excepto los servicios de mapas de ArcIMS) no adquieren bloqueos en los estados y, por lo tanto, no influyen en la operación de compresión. Los clientes de ArcGIS, incluidos los servicios de mapas de ArcIMS, sí adquieren bloqueos y, por lo tanto, influyen en la operación de compresión.

Puede ver los resultados de cada operación de compresión en la tabla COMPRESS_LOG en la geodatabase (SDE_compress_log en las bases de datos de SQL Server y PostgreSQL). También puede verificar la tabla VERSIONS (SDE_versiones en las bases de datos de 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.

Consulte Comprimir una geodatabase de ArcSDE con licencia de ArcGIS Server Enterprise para aprender cómo realizar una operación de compresión.

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.

Nota:

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. Para obtener información sobre la actualización de estadísticas, consulte Actualizar las estadísticas de la geodatabase mediante Analizar y el tema del sistema de administración de bases de datos (DBMS).

7/10/2012