In seltenen Fällen lässt ArcCatalog eine Transaktion laufen, ohne dass SQL-Aktivität stattfindet. Ich suche nach anderen, die dieses Problem ebenfalls bemerkt haben und, wenn ich wirklich Glück habe, eine Lösung besitzen.<\/P>
<\/P>
Es scheint (noch nicht zu 100 % bestätigt) mit dem Wechsel zwischen Datenbankverbindungen im ArcCatalog-Baumansichtsfenster zusammenzuhängen.<\/P>
Die Umgebung ist ArcGIS 10.5.1, das auf einem SQL Server-Backend läuft.<\/P>
Wie in http:\/\/desktop.arcgis.com\/en\/arcmap\/latest\/manage-data\/geodatabases\/concurrency-and-locking.htm <\/A>10.4 beginnend mfcssen Geodatabases in SQL Server die Datenbankoptionen READ_COMMITTED_SNAPSHOT und ALLOW_SNAPSHOT_ISOLATION auf ON gesetzt haben, und ArcGIS verwendet die Isolationsebene READ COMMITTED ffcr Transaktionen7<\/EM><\/P><\/P>Aus SQL-Sicht bewirkt dies, dass die Historie einer Transaktion in TEMPDB gespeichert wird, bis die Transaktion endet.<\/P><\/P>Wenn eine Transaktion offen bleibt, wird der Speicherplatz in TEMPDB nicht freigegeben. Audferdem werden alle TEMPDB-Transaktionsinformationen ffcr andere Transaktionen ber die gesamte SQL-Instanz hinweg beibehalten, bis die ursprfcngliche lang laufende Transaktion abgeschlossen ist (Dies ist nicht zu 100 % korrekt, aber ausreichend detailliert zur Erle4uterung des Problems).<\/P><\/P>Daher ist es wichtig, dass ArcGIS-Transaktionen nicht ber le4ngere (wie Stunden) Zeitre4ume laufen.<\/P><\/P>Wir beobachten die Situation, dass gelegentlich ein Benutzer von ArcCatalog eine aktive Transaktion hat, die stundenlang le4uft, obwohl er aus seiner Sicht nur den Baumansichtsfenster der Datenbankverbindungen betrachtet. Wenn wir zum Client-PC gehen, sehen wir einen ArcCatalog-Bildschirm wie ...<\/P><\/P>Wenn wir dann mit der rechten Maustaste auf 1SDIDIV_SQLP2_PRD2.sde7 klicken und dann die rechte Maustaste loslassen, wird das Problem behoben.<\/P><\/P>In einem SQL-Trace (gestartet kurz vor dem Rechtsklick) sehen wir eine Reihe von SQL-Abfragen, gefolgt von einem 1COMMIT7 einer Transaktion mit Startzeit 01.08.2018 10:51 und Endzeit 01.08.2018 14:37 (fast 4 Stunden!)<\/P><\/P>Mein Fazit ist, dass ArcCatalog vergessen hat, einige Verarbeitung um 10:51 zu committen (wahrscheinlich der Benutzerwechsel zwischen Datenbankverbindungen). Mein DeLorean ist gerade zur Wartung, daher kann ich Ihnen den Trace um 10:51 nicht zeigen.<\/P><\/P>Die einfachste Schlussfolgerung (aus meiner Sicht) ist ESRI zu bitten, ihren Programmierfehler zu identifizieren und zu beheben, aber ich denke ohne weitere Dokumentation we4re das etwas unrealistisch.<\/P><\/P>Eine zweite Option ist, den Benutzer das Problem reproduzieren zu lassen und dabei einen Trace durchzuffchren (bisher erfolglos).<\/P><\/P>Da wir die Ursache nicht identifizieren kf6nnen, ist die ne4chste Option die Situation abzumildern.<\/P> Kf6nnen wir ein Transaktions-Timeout setzen? Kf6nnen wir ein Leerlauf-Timeout ffcr eine Transaktion setzen?<\/P><\/P>Das Problem scheint auf einen Benutzer beschre4nkt zu sein. Sein Nutzungsprofil ist so, dass er oft zwischen Datenbankverbindungen wechselt, we4hrend ein 1normaler7 Benutzer eine Datenbankverbindung ausw0e4hlt und diese 7flange Zeit nutzt.<\/P><\/P>Jede Meinung willkommen<\/P><\/BODY><\/HTML>
Sharing with Geodatabase
Further clarification..
In the above description, when I am talking about 'live/open transactions' I am referring to SQL transactions, not ESRI transactions/lock tables etc
I have progressed this investigation further and I am now in a position that I can recreate the problem (or at least a manifestation of the problem) 100% of the time.
In ArcCatalog (with SQL 2016 FP2 backend)
We are raising an issue with ESRI but any confirmation that you too can create the problem (or not) would be appreciated
Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.