Performance lente aléatoire d'ArcSDE 10.1

Question

<\/HEAD>Bonjour,<\/P> <\/P> J'ai des utilisateurs qui rencontrent des performances très lentes et aléatoires. Un jour c'est excellent et un autre jour c'est lent. Différents utilisateurs ont des expériences différentes dans la même salle au même moment - certains rapides et d'autres lents.<\/P> <\/P> Informations système :<\/P> sql server 2008 sp3 r2 - Machine Virtuelle. flag de trace 4199 activé pour le bug de l'index spatial sql server et maxdop réglé à -1 (possède 24 cœurs)<\/P> Arcsde 10.1 sp1, type de stockage Geometry pour 80 % des données tandis que 20 % des données sont en SDEBinary, fonctionnalités Electric Geometric network<\/P> Schneider Designer 10.1<\/P> Citrix VM XenApp 6.5<\/P> Taille de la base de données : 30 Go avec orthoimagery<\/P> Versions en attente : 778<\/P> Versions avec conflits : 123<\/P> <\/P> Toutes les nuits, un processus de compression et de réconciliation est lancé. <\/P> <\/P> Il y a entre 44 et 46 utilisateurs connectés à la base de données en même temps.<\/P> <\/P> Nous avons remarqué que nous devions exécuter une reconstruction d'index et des statistiques avec analyse complète 3 fois par jour pour voir des améliorations, mais lors des jours lents aléatoires ce processus ne fonctionne pas.<\/P> <\/P> Je réalise une compression manuelle toutes les 2 à 3 heures depuis les 3 derniers jours. Aujourd'hui cela n'a pas fait de différence.<\/P> <\/P> Nous vérifions Citrix RDP et cela ne fait aucune différence. Nous avons surveillé la base de données et n'avons constaté aucun problème.<\/P> <\/P> Toute suggestion est appréciée !<\/P> <\/P> Merci d'avance.<\/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)?