Я использую 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
Это известное ограничение использования ArcGIS с SQL Server, которое, насколько я знаю, не так просто исправить.
Если планировщик запросов SQL Server решит, что для выполнения запроса ему требуется более одного ЦП, шансы используемого пространственного индекса невелики.
Microsoft знает об этой проблеме, но не спешит улучшать планировщик запросов, потому что это затронет все запросы, а не только пространственные.
Единственное надежное решение - установить максимальную степень параллелизма (MAXDOP) в вашей базе данных на 1, но это означает, что все запросы к этой БД будут использовать только 1 ЦП на запрос, что замедляет все.
Создание представления, представляющего таблицу с принудительной подсказкой о пространственном индексе, не работает, так как ArcGIS должен запрашивать метаданные и статистику таблицы, и такое представление убивает эти запросы.
источник
У меня аналогичная проблема. У меня есть класс пространственных объектов, хранящийся в SQL Server как тип геометрии. Он имеет 30-метровые записи и хорошо рисует, но если вы создадите VIEW, связанный со второй таблицей, этот VIEW зависнет и не будет отображаться.
К таблице прикреплено множество классов отношений. Повлияет ли это на производительность запроса / рисования?
Также вы можете указать мне в направлении признания Microsoft этой проблемы. Можно ли заставить планировщик запросов использовать пространственный индекс?
Билл
источник