Bij zeldzame gelegenheden laat ArcCatalog een transactie lopen zonder dat er SQL-activiteit plaatsvindt. Ik ben op zoek naar anderen die dit probleem misschien ook hebben opgemerkt en, als ik echt geluk heb, een oplossing hebben.<\/P>
<\/P>
Het lijkt geassocieerd te zijn (nog niet 100% bevestigd) met het wisselen tussen databaseverbindingen in de ArcCatalog-boomweergave.<\/P>
De omgeving is ArcGIS 10.5.1 draaiend op een SQL Server-backend<\/P>
Zoals besproken in http:\/\/desktop.arcgis.com\/en\/arcmap\/latest\/manage-data\/geodatabases\/concurrency-and-locking.htm <\/A>eginnen met ArcGIS 10.4 moeten geodatabases in SQL Server de SQL Server databaseopties READ_COMMITTED_SNAPSHOT en ALLOW_SNAPSHOT_ISOLATION op ON hebben staan, en ArcGIS gebruikt het READ COMMITTED isolatieniveau voor transacties<\/EM><\/P><\/P>Vanuit een SQL-perspectief zorgt dit ervoor dat de geschiedenis van een transactie wordt bewaard in TEMPDB totdat de transactie eindigt.<\/P><\/P>Als een transactie open blijft, wordt de ruimte in TEMPDB niet vrijgegeven. Bovendien wordt alle TEMPDB-transactie-informatie voor andere transacties over de hele SQL-instance behouden totdat de oorspronkelijke langdurige transactie is voltooid (Dit is niet 100% waar, maar voldoende detail om het probleem uit te leggen).<\/P><\/P>Daarom wordt het belangrijk dat ArcGIS-transacties niet voor langere (zoals uren) periodes blijven lopen.<\/P><\/P>We zien de situatie dat, bij zeldzame gelegenheden, een gebruiker van ArcCatalog een actieve transactie heeft die uren duurt, terwijl hij vanuit zijn perspectief alleen maar naar de boomweergave van databaseverbindingen kijkt. Wanneer we naar de client-pc gaan, zien we een ArcCatalog-scherm zoals<\/P><\/P>Als we dan rechtsklikken op SDIDIV_SQLP2_PRD2.sde en vervolgens de rechtsklik loslaten, wordt het probleem opgelost.<\/P><\/P>In een SQL-trace (gestart net voor de rechtsklik) zien we een reeks SQL-query's, gevolgd door een COMMIT van een transactie met een starttijd van 01\/-08\/-2018 10:51 en een eindtijd van 01\/-08\/-2018 14:37 (bijna 4 uur!)<\/P><\/P>Mijn conclusie is dat ArcCatalog vergeten is om wat verwerking te committen om 10:51 (waarschijnlijk de gebruiker die tussen databaseverbindingen wisselde). Mijn DeLorean is momenteel voor onderhoud, dus ik kan je de trace rond 10:51 niet laten zien.<\/P><\/P>De eenvoudigste conclusie (vanuit mijn perspectief) is om ESRI te vragen hun programmeerfout te identificeren en te verhelpen, maar ik denk dat dat zonder verdere documentatie wat onrealistisch zou zijn.<\/P><\/P>Een tweede optie is om de gebruiker het probleem opnieuw te laten creëren en tijdens dit proces een trace uit te voeren (Dit is tot nu toe niet gelukt).<\/P><\/P>Aangezien we de oorzaak niet kunnen achterhalen, is de volgende optie om de situatie te mitigeren.<\/P> Kunnen we een time-out instellen voor een transactie?<\/P> Kunnen we een idle-time-out instellen voor een transactie?<\/P><\/P>Het probleem lijkt beperkt tot één gebruiker. Zijn gebruiksprofiel is zodanig dat hij vaak wisselt tussen databaseverbindingen, terwijl een normale gebruiker kiest voor één databaseverbinding en deze voor langere tijd gebruikt.<\/P><\/P>Alle suggesties zijn welkom<\/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
Aangemelde leden kunnen berichten plaatsen, updates volgen en meer. Nieuw hier? Registreer een gratis account.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.