ArcSDE 10.1 Zufällige langsame Leistung

Question

<\/HEAD>Hallo,<\/P> <\/P> Ich habe Benutzer, die sehr zufällig langsame Leistung erleben. An einem Tag ist es großartig und an einem anderen Tag langsam. Verschiedene Benutzer haben zur gleichen Zeit im selben Raum unterschiedliche Erfahrungen – einige schnell und einige langsam.<\/P> <\/P> Systeminformationen:<\/P> sql server 2008 sp3 r2 - Virtuelle Maschine. Traceflag 4199 für den sql server spatial index Bug gesetzt und maxdop auf -1 eingestellt (hat 24 Kerne)<\/P> Arcsde 10.1 sp1, Geometriespeichertyp 80% der Daten während 20% der Daten in SDEBinary sind, Electric Geometric network features<\/P> Schneider Designer 10.1<\/P> Citrix VM XenApp 6.5<\/P> Datenbankgröße: 30 GB mit Orthobildern<\/P> Ausstehende Versionen: 778<\/P> Versionen mit Konflikten : 123<\/P> <\/P> Jede Nacht startet ein Komprimierungs- und Abgleichprozess. <\/P> <\/P> Es sind gleichzeitig 44 - 46 Benutzer mit der Datenbank verbunden.<\/P> <\/P> Wir haben festgestellt, dass wir dreimal täglich einen Rebuild-Index und Statistiken mit vollständigem Scan durchführen müssen, um Verbesserungen zu sehen, aber an den zufälligen langsamen Tagen funktioniert dieser Prozess nicht.<\/P> <\/P> Ich führe seit 3 Tagen alle 2 -3 Stunden eine manuelle Komprimierung durch. Heute hat es keinen Unterschied gemacht.<\/P> <\/P> Wir überprüfen Citrix RDP und es macht keinen Unterschied. Wir überwachen die Datenbank und sehen keine Probleme.<\/P> <\/P> Jede Rückmeldung ist willkommen!<\/P> <\/P> Vielen Dank im Voraus.<\/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)?