ArcGIS 10.2 Query Layer sur les performances de SQL Server

J'utilise une couche de requête sur SQL Server dans ArcMap. La couche de requête s'exécute instantanément dans SQL Server mais prend tellement de temps à dessiner dans ArcMap que le système ne répond plus pendant environ 10 minutes ou plus. Pendant le dessin ArcMap, l'un des processeurs est au maximum sur le processus SQL Server.

Ma requête est le STIntersect d'un tampon sur une entité linéaire (Shannon) par rapport à une classe d'entités surfaciques (Townlands), comme suit;

SELECT TOWNLANDS.TL_ID,TOWNLANDS.Shape FROM dbo.TOWNLANDS as townlands
with(index(FDO_Shape)) 
JOIN dbo.Shannon on townlands.Shape.STIntersects 
(Shannon.Shape.STBuffer(2.0))=1

La requête renvoie instantanément 186 lignes. Ceux-ci peuvent être dessinés dans le volet Spatial de SQL Server Management Studio sans problème

Lorsque je crée une couche de requête dans ArcMap avec exactement la même syntaxe, le système ne répond plus mais dessine finalement. Il semble que, peut-être, ArcMap n'utilise pas l'index spatial ou le fait différemment de SQL Server, provoquant une requête inefficace sur SQL Server qui prend un certain temps pour revenir.

Quelqu'un peut-il conseiller un remède?

Merci

ArcGIS Desktop: 10.2
ArcSDE: 10.2
RDBMS: Database and version: SQL Server 2008
OS: Windows Server 

Comme vous l'avez indiqué, votre requête semble s'exécuter rapidement au niveau de la base de données. Même si vous avez pu rendre le SQL plus efficace, les performances réelles se situent au niveau spatial.

Les instructions SQL spatiales, comme celle que vous utilisez, n'ont été autorisées que récemment avec l'introduction du type de géométrie. SQL Server 2008 pour ArcSDE prend en charge trois types de données de géométrie, SDEBINARY, GEOMETRY et GEOGRAPHY. Les différences sont listées ici

Pour de meilleures performances, assurez-vous que vous utilisez la géométrie ou la géographie (pas SDEBINARY, car elle est obsolète et déconseillée) en fonction de la nature de vos données, que vous utilisiez ou non la référence spatiale terrestre. Assurez-vous également de reconstruire l'index spatial sur la classe de caractéristiques TOWNLANDS. Vous pouvez le faire à partir d'ArcCatalog en cliquant avec le bouton droit sur la classe de caractéristiques, les propriétés et en sélectionnant l'onglet index.

J'espère que cela pourra aider.

Je ne vois pas dans votre requête la nécessité de faire une jointure. Essayez plutôt d'utiliser WHERE.

SELECT TOWNLANDS.TL_ID,TOWNLANDS.Shape 
FROM dbo.TOWNLANDS as townlands
with(index(FDO_Shape)) 
WHERE townlands.Shape.STIntersects 
(Shannon.Shape.STBuffer(2.0))=1

Dans la requête d'origine, la jointure ne semblait d'aucun avantage pour le résultat; Je n'ai vu aucune colonne de la table Shannon dans la ligne de sélection. Par conséquent, cela semble être un travail supplémentaire.

Il s'agit d'une limitation connue de l'utilisation d'ArcGIS avec SQL Server qui n'a pas de correctif simple à ma connaissance.

Si le planificateur de requêtes SQL Server décide qu'il a besoin de plus d'un processeur pour exécuter la requête, les chances de l'index spatial utilisé sont faibles.

Microsoft est conscient du problème mais n'est pas pressé d'améliorer le planificateur de requêtes car cela affecterait toutes les requêtes, pas seulement celles spatiales.

La seule solution fiable consiste à définir votre degré maximal de parallélisme (MAXDOP) sur votre base de données à 1, mais cela signifie que toutes les requêtes sur cette base de données n'utiliseront qu'un processeur par requête, ce qui ralentira tout.

La création d'une vue qui représente la table et force l'index d'index spatial ne fonctionne pas car ArcGIS doit interroger les métadonnées et les statistiques de la table et une telle vue tue ces requêtes.

J'ai le même problème. J'ai une classe d'entités stockée dans SQL Server en tant que type de géométrie. Il contient 30m d'enregistrements et ses tirages sont corrects, mais si vous créez une VIEW liée à une 2ème table, cette VIEW se bloque et ne s'affiche pas.

La table a une charge de classes de relations qui lui sont attachées. Cela affectera-t-il les performances de requête / dessin?

Pouvez-vous également me diriger vers la reconnaissance par Microsoft de ce problème. Puis-je forcer le planificateur de requêtes à utiliser l'index spatial?

Facture