Уровень запросов ArcGIS 10.2 на производительность SQL Server

Я использую Query Layer на SQL Server в ArcMap. Уровень запросов выполняется мгновенно в SQL Server, но рисование в ArcMap занимает так много времени, что система перестает отвечать на запросы в течение 10 минут или дольше. Во время отрисовки ArcMap один из процессоров максимально используется процессом SQL Server.

Мой запрос - это STIntersects буфера на линейном объекте (Shannon) по отношению к классу объектов многоугольника (Townlands) следующим образом;

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

Запрос возвращает 186 строк мгновенно. Их можно без проблем нарисовать на пространственной панели SQL Server Management Studio.

Когда я создаю слой запросов в ArcMap с точно таким же синтаксисом, система перестает отвечать на запросы, но в конечном итоге рисует. Похоже, что, возможно, ArcMap не использует пространственный индекс или делает это в отличие от SQL Server, что приводит к неэффективному запросу на SQL Server, который требует времени для возврата.

Кто-нибудь может посоветовать лекарство?

Спасибо

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

Как вы заявили, ваш запрос выполняется быстро на уровне базы данных. Даже если вы смогли сделать SQL более эффективным, реальная производительность находится на пространственном уровне.

Пространственные операторы SQL, как и те, которые вы используете, были разрешены только недавно с введением типа геометрии. SQL Server 2008 для ArcSDE поддерживает три типа данных геометрии: SDEBINARY, GEOMETRY и GEOGRAPHY. Различия перечислены здесь

Для достижения наилучших результатов убедитесь, что вы используете геометрию или географию (но не SDEBINARY, хотя она устарела и не рекомендуется) в зависимости от характера ваших данных, независимо от того, используете ли вы пространственную привязку Земли или нет. Также убедитесь, что перестроили пространственный индекс в классе объектов TOWNLANDS. Вы можете сделать это из ArcCatalog, щелкнув правой кнопкой мыши класс объектов, свойства и выбрав вкладку индексов.

Надеюсь, это поможет.

Я не вижу в вашем запросе необходимости делать соединение. Попробуйте вместо этого использовать ГДЕ.

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

В исходном запросе соединение оказалось бесполезным для результата; Я не увидел ни одной колонки из таблицы Шеннона в строке выбора. Поэтому это похоже на дополнительную работу.

Это известное ограничение использования ArcGIS с SQL Server, которое, насколько я знаю, не так просто исправить.

Если планировщик запросов SQL Server решит, что для выполнения запроса ему требуется более одного ЦП, шансы используемого пространственного индекса невелики.

Microsoft знает об этой проблеме, но не спешит улучшать планировщик запросов, потому что это затронет все запросы, а не только пространственные.

Единственное надежное решение - установить максимальную степень параллелизма (MAXDOP) в вашей базе данных на 1, но это означает, что все запросы к этой БД будут использовать только 1 ЦП на запрос, что замедляет все.

Создание представления, представляющего таблицу с принудительной подсказкой о пространственном индексе, не работает, так как ArcGIS должен запрашивать метаданные и статистику таблицы, и такое представление убивает эти запросы.

У меня аналогичная проблема. У меня есть класс пространственных объектов, хранящийся в SQL Server как тип геометрии. Он имеет 30-метровые записи и хорошо рисует, но если вы создадите VIEW, связанный со второй таблицей, этот VIEW зависнет и не будет отображаться.

К таблице прикреплено множество классов отношений. Повлияет ли это на производительность запроса / рисования?

Также вы можете указать мне в направлении признания Microsoft этой проблемы. Можно ли заставить планировщик запросов использовать пространственный индекс?

Билл