ArcGIS 10.2 Warstwa zapytania o wydajność programu SQL Server

Korzystam z warstwy zapytań na SQL Server w ArcMap. Warstwa zapytań jest wykonywana natychmiast w SQL Server, ale rysowanie w ArcMap trwa tak długo, że system wydaje się nie reagować przez około 10 minut lub dłużej. Podczas rysowania ArcMap jeden z procesorów jest maksymalnie wykorzystywany w procesie SQL Server.

Moje zapytanie to STIntersects bufora na obiekcie liniowym (Shannon) w stosunku do klasy obiektów wielokątów (Townlands), jak następuje;

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

Zapytanie natychmiast zwraca 186 wierszy. Można je bez problemu rysować w okienku przestrzennym SQL Server Management Studio

Kiedy buduję warstwę zapytań w ArcMap z dokładnie taką samą składnią, system przestaje odpowiadać, ale ostatecznie rysuje. Wygląda na to, że ArcMap nie używa indeksu przestrzennego lub robi to inaczej niż SQL Server, powodując niewydajne zapytanie w SQL Server, którego powrót wymaga wieku.

Czy ktoś może doradzić w sprawie remedium?

Dzięki

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

Jak już wspomniałeś, twoje zapytanie wydaje się działać szybko na poziomie bazy danych. Nawet jeśli udało Ci się uczynić SQL bardziej wydajnym, rzeczywista wydajność jest na poziomie przestrzennym.

Przestrzenne instrukcje SQL, takie jak te, których używasz, były dozwolone dopiero niedawno wraz z wprowadzeniem typu geometrii. SQL Server 2008 dla ArcSDE obsługuje trzy typy danych geometrycznych: SDEBINARY, GEOMETRIA i GEOGRAFIA. Różnice wymieniono tutaj

Aby uzyskać najlepszą wydajność, upewnij się, że używasz geometrii lub geografii (nie SDEBINARY, ponieważ jest przestarzała i nie jest zalecana) w zależności od charakteru twoich danych, niezależnie od tego, czy używasz odniesienia przestrzennego Ziemi, czy nie. Upewnij się również, czy przebudujesz indeks przestrzenny w klasie obiektów TOWNLANDS. Możesz to zrobić z ArcCatalog, klikając prawym przyciskiem myszy klasę obiektów, właściwości i wybierając zakładkę indeksów.

Mam nadzieję, że to pomaga.

Nie widzę w twoim zapytaniu potrzeby wykonania złączenia. Spróbuj zamiast tego użyć GDZIE.

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

W pierwotnym zapytaniu łączenie pojawiło się bez korzyści dla wyniku; W wierszu wyboru nie widziałem żadnych kolumn z tabeli Shannona. Dlatego wydaje się to dodatkową pracą.

Jest to znane ograniczenie korzystania z ArcGIS z SQL Server, który nie ma prostej poprawki, o ile mi wiadomo.

Jeśli planista zapytań programu SQL Server zdecyduje, że do wykonania zapytania potrzebuje więcej niż jednego procesora, szanse na zastosowanie indeksu przestrzennego są niskie.

Microsoft zdaje sobie sprawę z problemu, ale nie śpieszy się z ulepszaniem narzędzia do planowania zapytań, ponieważ wpłynęłoby to na wszystkie zapytania, nie tylko na zapytania przestrzenne.

Jedynym niezawodnym rozwiązaniem jest ustawienie maksymalnego stopnia równoległości (MAXDOP) w bazie danych na 1, ale oznacza to, że wszystkie zapytania w tej bazie danych będą wykorzystywać tylko 1 procesor na zapytanie, co spowalnia wszystko.

Tworzenie widoku, który reprezentuje tabelę i wymusza wskazówkę dotyczącą indeksu przestrzennego, nie działa, ponieważ ArcGIS musi zapytać o metadane i statystyki tabeli, a taki widok zabija te zapytania.

Mam podobny problem. Mam klasę obiektów przechowywaną w SQL Server jako typ geometrii. Zawiera 30 m rekordów i dobrze się rysuje, ale jeśli utworzysz WIDOK połączony z 2. tabelą, ten WIDOK zawiesi się i nie będzie wyświetlany.

Do tabeli dołączono ładunek klas relacji. Czy wpłynie to na wydajność zapytania / rysunku?

Możesz również wskazać mi kierunek, w którym Microsoft uznaje ten problem. Czy mogę zmusić narzędzie do planowania zapytań do korzystania z indeksu przestrzennego?

Rachunek