Desempenho aleatório lento do ArcSDE 10.1

Question

<\/HEAD>Oi,<\/P> <\/P> Tenho usuários que experimentam um desempenho muito aleatório e lento. Um dia está ótimo e no outro está lento. Usuários diferentes têm experiências diferentes na mesma sala ao mesmo tempo - alguns rápidos e outros lentos.<\/P> <\/P> Informações do sistema:<\/P> sql server 2008 sp3 r2 - Máquina Virtual. flag de rastreamento 4199 emitida para o bug do índice espacial do sql server e maxdop definido para -1 (possui 24 núcleos)<\/P> Arcsde 10.1 sp1, tipo de armazenamento Geometry 80% dos dados enquanto 20% dos dados estão em SDEBinary, recursos da rede geométrica elétrica<\/P> Schneider Designer 10.1<\/P> Citrix VM XenApp 6.5<\/P> Tamanho do banco de dados: 30 GB com ortoimagem<\/P> Versões pendentes: 778<\/P> Versões com conflitos : 123<\/P> <\/P> Cada noite há um processo de compressão e reconciliação que é iniciado. <\/P> <\/P> Há 44 - 46 usuários conectados ao banco de dados ao mesmo tempo.<\/P> <\/P> Notamos que tivemos que executar uma reconstrução de índice e estatísticas com varredura completa 3 vezes ao dia para ver melhorias, mas nos dias aleatórios lentos esse processo não funciona.<\/P> <\/P> Tenho executado uma compressão manual a cada 2 -3 horas nos últimos 3 dias. Hoje não fez diferença.<\/P> <\/P> Verificamos o Citrix RDP e não faz diferença. Monitoramos o banco de dados e não vemos problemas.<\/P> <\/P> Qualquer contribuição é apreciada!<\/P> <\/P> Obrigado antecipadamente.<\/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)?