En una geodatabase versionada, ¿qué impacto tablas delta y el árbol del estado tiene en el rendimiento de la consulta?

Question

Tenemos un versionado de una geodatabase de arcsde (arcgis 9.3.1 en oracle 10g) con bastante complejo modelo de datos que incluye alrededor de 100 featureclasses y no las tablas espaciales, una red geométrica y muchas clases de relación.

Los datos se editan diariamente por 5 o 6 de arcmap los usuarios la utilización de sde el control de versiones. Además se crean las versiones automáticas de los servicios de la interfaz con otros sistemas de negocio para realizar modificaciones en la geodatabase. El rendimiento de las consultas se redujera notablemente durante el transcurso del día, por lo que hemos implementado durante la noche, una secuencia de comandos para realizar una completa comprimir. En ocasiones, cuando un número relativamente grande de las ediciones se realizan, el sistema puede quedar inutilizable hasta que después de una compresa.

Se ha sugerido que oracle como configurado no puede venir hasta con decente planes de ejecución cuando se enfrentan con estos volátiles tablas delta. Es esta una explicación razonable? Cuál es la estrategia que deben ser adoptadas para resolverlo?

Actualización en respuesta a los comentarios

• Al final del día, el árbol del estado es muy lineal, con sólo un poco de ramificación.
• Comprimimos noche (una comprimir mediante la eliminación de todas las versiones).
• Tablas de negocio son analizados periódicamente.
• Tablas Delta no son analizados. Están bloqueados (Intento de analizar devuelve el error "ORA-20005 objeto estadísticas bloqueado"). Tampoco lo son los volátiles de las tablas en la sde esquema -, STATE_LINEAGES.

Answer 1

Las tablas delta y el árbol del estado, tiene un directo impacto en el rendimiento de las consultas.

En primer lugar, usted necesita entender el control de versiones; hice una breve explicación de la relación del estado del árbol y la versión de etiquetas en una respuesta diferente. Creo que ayudaría a ir a través de ella.

Después de leer la respuesta, usted puede darse cuenta de cómo un largo identificación del estado de la rama (de la raíz a la del estado-id que se refiere a una etiqueta tendría un impacto en el rendimiento. Por qué? Porque tiene más complejo se une a recrear el "actual" a la vista de la versión. Desde la compresa es podar el árbol, el interior se une a ser más fácil de procesar por el subyacente db y su ArcMap sesiones se hacen más rápidas.

Echa un vistazo a las Versiones de los flujos de trabajo de documentos de ESRI, que te enseñará cómo mantener el estado de versión del árbol de la cuerda de control. El uso de la GDBT a mirar el árbol del estado antes y después de que usted puede ver cómo un buen flujo de trabajo afecta el árbol.

En segundo lugar, si usted puede conseguir lejos con no tener que hacer uso de la Red Geométrica para la mayoría de sus casos de uso, y luego hacerlo. Se va a ralentizar el FeatureClasses que están involucrados, porque utiliza complejos de mensajería para cada Fila::tienda llamada (frente a sólo el almacenamiento de la fila en la tabla y se hace con ella).

Para actualizar las estadísticas, el uso de las Herramientas de Administración de Datos " Analizar la función (marque todos ellos). Él sabrá cómo lidiar con las tablas delta (y cualquier otro tablas) que son necesarios.

Answer 2

[Primer post de disculpas: Este está destinado a ser un comentario no una respuesta definitiva.] Si usted tiene cualquier editar versiones que son relativamente antiguas y no han sido publicados deberán ser eliminados, publicado o reconciliarse. Un viejo sin conciliar versión mantiene una antigua vista de forma predeterminada, lo que impide delta registros pertenecientes a las versiones más recientes de ser comprimido en la base de las tablas. No puede ser que un gran número de estos sin comprimir registros de delta anclados a una versión antigua y el rendimiento se ve afectado debido a que todas las versiones son vistas en el delta y en las tablas base. El rendimiento del sistema está relacionado con el número de ediciones, ya que cada versión última reconciliados (o creado). Así que, en resumen; si hay versiones de que usted no puede publicar, a continuación, conciliar con regularidad, y comprimir.