I'm using a Query Layer on SQL Server in ArcMap. The Query Layer executes instantly in in SQL Server but but takes so long to draw in ArcMap that the system appears unresponsive for about 10 minutes or longer. During the ArcMap draw the one of the CPU's is maxed out on the SQL Server process.

My Query is the STIntersects of a buffer on a line feature (Shannon) against a polygon feature class (Townlands) , as follows;

JOIN dbo.Shannon on townlands.Shape.STIntersects 

The query returns 186 rows instantly. These can be draw in the SQL Server Management Studio Spatial pane without a problem

When I build a Query Layer in ArcMap with exactly the same syntax the system becomes unresponsive but does draw eventually. It looks as though, perhaps, ArcMap s not using the spatial index or is doing so differenlt from SQL Server causing an inefficient query on SQL Server that takes an age to return.

Can anyone advise on a remedy?


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

As you stated, your query seems to execute swiftly on the database level. Even if you were able to make the SQL more efficient, the real performance is on the spatial level.

Spatial SQL statements, like the one you are using, were allowed only recently with the introduction of the geometry type. SQL Server 2008 for ArcSDE supports three geometry data type, SDEBINARY, GEOMETRY and GEOGRAPHY. The differences are listed here

For best performance make sure you are using the Geometry or Geography (not SDEBINARY though since it is obsolete and not recommended) based on the nature of your data whether you are using earth spatial reference or not. Also make sure to rebuild spatial index on the TOWNLANDS featureclass. You can do that from ArcCatalog by right clicking on the featureclass, properties and select the indexes tab.

Hope that helps.

|improve this answer|||||

I don't see in your query the need to do a join. Try instead using WHERE.

FROM dbo.TOWNLANDS as townlands
WHERE townlands.Shape.STIntersects 

In the original query the join appeared of no benefit to the result; I didn't see any columns from the Shannon table in the select line. Therefore, it seems like extra work.

|improve this answer|||||
  • Welcome to GIS SE! Your Answer is very brief so to help this Asker and later readers would you be able to use the edit button to expand upon what you are suggesting, please? – PolyGeo Nov 13 '13 at 5:00

This is a known limitation of using ArcGIS with SQL Server that doesn't have a simple fix as far as I am aware.

If the SQL Server query planner decides it needs more than one CPU to execute the query, the odds of the spatial index being used are low.

Microsoft are aware of the issue but aren't in a hurry to improve the query planner because it would affect all queries, not just the spatial ones.

The only reliable solution is to set your maximum degree of parallelism (MAXDOP) on your database to 1, but this means all queries on that DB will only use 1 CPU per query, slowing everything down.

Creating a view that represents the table and forces the spatial index hint doesn't work as ArcGIS needs to query the table's metadata and stats and such a view kills those queries.

|improve this answer|||||

I have a similar problem. I have a feature class stored in SQL Server as Geometry type. It has 30m records in it & its draws fine, but if you create a VIEW linked to a 2nd table, this VIEW hangs and won't display.

The table has a load of relationship classes attached to it. Will these affect the query/drawing performance?

Also can you point me in the direction of Microsoft's acknowledgement of this problem. Can I force the Query planner to use the spatial index ?


|improve this answer|||||
  • Please ask a new question. – Mapperz Mar 9 '15 at 15:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.