ArcSDE 10.1 Willekeurige trage prestaties

Question

<\/HEAD>Hallo,<\/P> <\/P> Ik heb gebruikers die zeer willekeurige trage prestaties ervaren. De ene dag is het geweldig en de andere dag traag. Verschillende gebruikers hebben verschillende ervaringen in dezelfde ruimte op hetzelfde moment - sommigen snel en sommigen traag.<\/P> <\/P> Systeeminfo:<\/P> sql server 2008 sp3 r2 - Virtuele Machine. traceflag 4199 uitgegeven voor de sql server spatial index bug en maxdop ingesteld op -1 (heeft 24 cores)<\/P> Arcsde 10.1 sp1, Geometry opslagtype 80% van de data terwijl 20% van de data in SDEBinary is, Electric Geometric netwerkfuncties<\/P> Schneider Designer 10.1<\/P> Citrix VM XenApp 6.5<\/P> Databasegrootte: 30 GB met orthoimagery<\/P> Uitstaande versies: 778<\/P> Versies met conflicten : 123<\/P> <\/P> Elke nacht start er een compressie- en reconciliatieproces. <\/P> <\/P> Er zijn 44 - 46 gebruikers tegelijkertijd verbonden met de database.<\/P> <\/P> We merkten dat we drie keer per dag een rebuild index en statistieken met volledige scan moesten uitvoeren om verbeteringen te zien, maar op de willekeurige trage dagen werkt dit proces niet.<\/P> <\/P> Ik heb de afgelopen 3 dagen elke 2-3 uur handmatig een compressie uitgevoerd. Vandaag maakte het geen verschil.<\/P> <\/P> We controleren Citrix RDP en het maakt geen verschil. We hebben de database gemonitord en zien geen problemen.<\/P> <\/P> Alle suggesties worden gewaardeerd!<\/P> <\/P> Alvast bedankt.<\/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)?