Problème de longue durée avec ArcCatalog

JohnCuthbertson

<\/HEAD>

Dans de rares occasions, ArcCatalog laisse une transaction en cours sans activité SQL. Je cherche quelqu'un d'autre qui aurait remarqué ce problème et, si j'ai vraiment de la chance, qui aurait une solution.<\/P>

<\/P>

Il semble être associé (pas encore confirmé à 100 %) au passage entre les connexions de base de données dans la vue arborescente d'ArcCatalog.<\/P>

<\/P>

L'environnement est  ArcGIS 10.5.1 fonctionnant sur un backend SQL Server<\/P>

<\/P>

Comme discuté dans http:\/\/desktop.arcgis.com\/en\/arcmap\/latest\/manage-data\/geodatabases\/concurrency-and-locking.htm <\/A>À partir d'ArcGIS 10.4, les géodatabases dans SQL Server doivent avoir les options de base de données SQL Server READ_COMMITTED_SNAPSHOT et ALLOW_SNAPSHOT_ISOLATION activées, et ArcGIS utilise le niveau d'isolation READ COMMITTED pour les transactions<\/EM><\/P><\/P>D'un point de vue SQL, cela fait que l'historique d'une transaction est conservé dans TEMPDB jusqu'à la fin de la transaction.<\/P><\/P>Si une transaction reste ouverte, l'espace dans TEMPDB n'est pas libéré. De plus, toute information de transaction TEMPDB pour d'autres transactions sur l'ensemble de l'instance SQL sera conservée jusqu'à ce que la transaction longue initiale soit terminée (ceci n'est pas 100 % exact, mais suffisamment détaillé pour expliquer le problème).<\/P><\/P>Par conséquent, il devient important que les transactions ArcGIS ne durent pas des périodes prolongées (comme des heures).<\/P><\/P>Nous constatons que, dans de rares cas, un utilisateur d'ArcCatalog a une transaction active pendant des heures alors que, de son point de vue, il se contente de regarder la vue arborescente des connexions aux bases de données. Lorsque nous allons sur le PC client, nous voyons un écran ArcCatalog comme...<\/P><\/P>Si nous faisons ensuite un clic droit sur SDIDIV_SQLP2_PRD2.sde puis relâchons le clic droit, le problème est résolu.<\/P><\/P>Dans une trace SQL (démarrée juste avant le clic droit), nous voyons une série de requêtes SQL, suivies d'un COMMIT d'une transaction avec un début à 01\/08\/2018 10:51 et une fin à 01\/08\/2018 14:37 (près de 4 heures !)<\/P><\/P>Ma conclusion est qu'ArcCatalog a oblié de valider certains traitements à 10:51 (probablement l'utilisateur passant entre les connexions aux bases). Ma DeLorean est en service en ce moment donc je ne peux pas vous montrer la trace autour de 10:51.<\/P><\/P>La conclusion la plus simple (de mon point de vue) est de demander à ESRI d'identifier leur erreur de codage et de la corriger, mais je pense que, sans documentation supplémentaire, cela serait un peu irréaliste.<\/P><\/P>Une deuxième option est de faire recréer le problème par l'utilisateur et effectuer une trace pendant qu'il fait cela (cela a jusqu'à présent échoué).<\/P><\/P>Étant donné que nous ne pouvons pas identifier la cause première, l'option suivante est d'atténuer la situation.<\/P> Pouvons-nous définir un délai d'expiration pour une transaction ?<\/P> Pouvons-nous définir un délai d'inactivité pour une transaction ?<\/P><\/P>Le problème semble isolé à un utilisateur. Son profil d'utilisation est tel qu'il change souvent entre les connexions aux bases, alors qu'un utilisateur normal choisit une connexion et s'y tient pendant des périodes prolongées.<\/P><\/P>Toute suggestion est bienvenue<\/P><\/BODY><\/HTML>

bixb0012

Sharing with Geodatabase‌