Livello di query ArcGIS 10.2 sulle prestazioni di SQL Server

Sto usando un livello di query su SQL Server in ArcMap. Il livello di query viene eseguito immediatamente in SQL Server, ma impiega così tanto tempo a disegnare in ArcMap che il sistema non risponde per circa 10 minuti o più. Durante l'estrazione di ArcMap, quella della CPU è al massimo nel processo di SQL Server.

La mia query è la STIntersects di un buffer su una feature linea (Shannon) contro una poligono feature class (Townlands), come segue;

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

La query restituisce 186 righe all'istante. Questi possono essere disegnati nel riquadro spaziale di SQL Server Management Studio senza problemi

Quando creo un livello di query in ArcMap con esattamente la stessa sintassi, il sistema non risponde ma alla fine disegna. Sembra che ArcMap non stia usando l'indice spaziale o lo stia facendo diversamente da SQL Server causando una query inefficiente su SQL Server che impiega un'età per tornare.

Qualcuno può consigliare un rimedio?

Grazie

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

Come hai affermato, la query sembra eseguirsi rapidamente a livello di database. Anche se sei stato in grado di rendere SQL più efficiente, le prestazioni reali sono a livello spaziale.

Le istruzioni SQL spaziali, come quella che si sta utilizzando, sono state consentite solo di recente con l'introduzione del tipo di geometria. SQL Server 2008 per ArcSDE supporta tre tipi di dati geometrici, SDEBINARY, GEOMETRY e GEOGRAPHY. Le differenze sono elencate qui

Per prestazioni ottimali, assicurati di utilizzare Geometria o Geografia (non SDEBINARY anche se è obsoleto e sconsigliato) in base alla natura dei tuoi dati, indipendentemente dal fatto che tu stia utilizzando o meno il riferimento spaziale terrestre. Assicurati anche di ricostruire l'indice spaziale sulla featureclass di TOWNLANDS. Puoi farlo da ArcCatalog facendo clic con il tasto destro sulla featureclass, proprietà e selezionare la scheda degli indici.

Spero che aiuti.

Nella tua query non vedo la necessità di unirsi. Prova invece a utilizzare 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

Nella query originale il join appariva senza alcun beneficio per il risultato; Non ho visto alcuna colonna dalla tabella Shannon nella riga selezionata. Pertanto, sembra un lavoro extra.

Questa è una limitazione nota dell'utilizzo di ArcGIS con SQL Server che non ha una soluzione semplice per quanto ne so.

Se il pianificatore di query di SQL Server decide che è necessaria più di una CPU per eseguire la query, le probabilità dell'indice spaziale in uso sono basse.

Microsoft è a conoscenza del problema, ma non ha fretta di migliorare il pianificatore di query perché influirebbe su tutte le query, non solo su quelle spaziali.

L'unica soluzione affidabile è impostare il massimo grado di parallelismo (MAXDOP) sul database su 1, ma ciò significa che tutte le query su quel DB useranno solo 1 CPU per query, rallentando tutto.

La creazione di una vista che rappresenta la tabella e forza il suggerimento dell'indice spaziale non funziona in quanto ArcGIS deve eseguire query sui metadati e le statistiche della tabella e tale vista uccide tali query.

Ho un problema simile. Ho una classe di caratteristiche archiviata in SQL Server come tipo Geometry. Ha 30 milioni di record e disegna bene, ma se si crea una VISTA collegata a una seconda tabella, questa VISTA si blocca e non verrà visualizzata.

La tabella ha un carico di classi di relazione associate ad essa. Questi influenzeranno le prestazioni di query / disegno?

Puoi anche indicarmi il riconoscimento da parte di Microsoft di questo problema. Posso forzare il pianificatore di query a utilizzare l'indice spaziale?

Conto