ArcGIS 10.2 Шар запиту на продуктивність SQL Server

Я використовую рівень запитів на 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 Studio 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, клацнувши правою кнопкою миші класу властивостей, властивостей та виберіть вкладку індексів.

Сподіваюся, що це допомагає.

Я не бачу у вашому запиті необхідності робити приєднання. Спробуйте замість цього використовувати 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

В оригінальному запиті з'єднання виявилося не корисним для результату; У рядку вибору я не бачив стовпців із таблиці Шеннона. Тому це здається зайвою роботою.

Це відоме обмеження використання ArcGIS з SQL Server, яке не має простого виправлення, наскільки мені відомо.

Якщо планувальник запитів SQL Server вирішить, що для виконання запиту йому потрібно більше одного процесора, шанси використовуваного просторового індексу низькі.

Microsoft знає про цю проблему, але не поспішає вдосконалювати планувальник запитів, оскільки це вплине на всі запити, не лише на просторові.

Єдине надійне рішення - встановити максимальну ступінь паралелізму (MAXDOP) у вашій базі даних на 1, але це означає, що всі запити в цій БД будуть використовувати лише 1 ЦП за запит, уповільнюючи все.

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

У мене схожа проблема. У мене клас об’єктів зберігається на SQL Server як тип геометрії. У ньому є 30м записів, і це добре малює, але якщо ви створили VIEW, пов'язаний з другою таблицею, цей VIEW висить і не відображатиметься.

До таблиці додається навантаження класів відносин. Чи вплине це на ефективність запиту / малюнка?

Також ви можете вказати мені на те, що Microsoft визнає цю проблему. Чи можу я змусити планувальник запитів використовувати просторовий індекс?

Білл