Rendimiento lento aleatorio de ArcSDE 10.1

Question

<\/HEAD>Hola,<\/P> <\/P> Tengo usuarios que experimentan un rendimiento muy lento y aleatorio. Un día es excelente y otro día es lento. Diferentes usuarios tienen diferentes experiencias en la misma sala al mismo tiempo: algunos rápidos y otros lentos.<\/P> <\/P> Información del sistema:<\/P> sql server 2008 sp3 r2 - Máquina Virtual. se emitió el traceflag 4199 para el error del índice espacial de sql server y se configuró maxdop a -1 (tiene 24 núcleos)<\/P> Arcsde 10.1 sp1, tipo de almacenamiento Geometry 80% de los datos mientras que el 20% de los datos está en SDEBinary, características de red geométrica eléctrica<\/P> Schneider Designer 10.1<\/P> Citrix VM XenApp 6.5<\/P> Tamaño de la base de datos: 30 GB con ortoimagen<\/P> Versiones pendientes: 778<\/P> Versiones con conflictos : 123<\/P> <\/P> Cada noche se inicia un proceso de compresión y conciliación. <\/P> <\/P> Hay entre 44 y 46 usuarios conectados a la base de datos al mismo tiempo.<\/P> <\/P> Notamos que teníamos que ejecutar una reconstrucción de índice y estadísticas con escaneo completo 3 veces al día para ver mejoras, pero sin embargo, en los días lentos aleatorios este proceso no funciona.<\/P> <\/P> He estado ejecutando una compresión manual cada 2-3 horas durante los últimos 3 días. Hoy no hizo ninguna diferencia.<\/P> <\/P> Revisamos Citrix RDP y no hace ninguna diferencia. Monitoreamos la base de datos y no vemos problemas.<\/P> <\/P> ¡Cualquier aporte es apreciado!<\/P> <\/P> Gracias de antemano.<\/P><\/BODY><\/HTML>

SSMIC3038 · Answer

Personally I suspect this is the problem.

ESRI promotes those sorts of long transactions but it's at odds with best database practices of regular full compress, so it's a bit of a catch-22.

This is a difficult spot to be in, hundreds of named versions and one has to assume that not all those versions are required or that some were made by users that perhaps didn't have a full understanding of DB administration or even require a named version for their tasks.

If this is indeed the problem than there's not a lot of advice to give, if the version tree needs trimming then it will likely involve data loss.

Personally, I admin hundreds of users and corporate GIS networks for sewer, water distribution and electrical distribution (among other things) and we only keep a few named versions. We tightly regulate named versions. They have a place in a work process but not all users should be making named versions on a whim, the process should be managed/administered.

Just my 2 cents.

AntheaTung · Answer

I have 788 named versions as of now/. I cannot reconcile and post and delete all versions to state 0.  There are long transaction jobs that spans over a couple of years with outstanding versions.

There is a nightly automated task that reconciles (abort if conflicts) and then compress.

Once a month I kick off all users from the system and do reconcile and compress.

I have been manually doing compress throughout the day - like 3 - 4 times to see if more compress will make any differences and it did not make any difference at all.

Thanks

SSMIC3038 · Answer

Do you have any named versions?

Have you done a full compress (all users off - reconcile named versions then delete them - compress - state ID down to 0)?