ArcGIS 10.2 Query Layer no desempenho do SQL Server

Estou usando uma camada de consulta no SQL Server no ArcMap. A Camada de consulta é executada instantaneamente no SQL Server, mas leva tanto tempo para atrair o ArcMap que o sistema parece não responder por cerca de 10 minutos ou mais. Durante o desenho do ArcMap, uma das CPUs é maximizada no processo do SQL Server.

My Query é o STIntersects de um buffer em um recurso de linha (Shannon) contra uma classe de recurso de polígono (Townlands), como 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

A consulta retorna 186 linhas instantaneamente. Eles podem ser desenhados no painel Espacial do SQL Server Management Studio sem problemas

Quando eu construo uma Camada de Consulta no ArcMap com exatamente a mesma sintaxe, o sistema fica sem resposta, mas acaba atraindo. Parece que, talvez, o ArcMap não esteja usando o índice espacial ou esteja fazendo isso diferente do SQL Server, causando uma consulta ineficiente no SQL Server que leva uma eternidade para retornar.

Alguém pode aconselhar sobre um remédio?

obrigado

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

Como você afirmou, sua consulta parece ser executada rapidamente no nível do banco de dados. Mesmo se você fosse capaz de tornar o SQL mais eficiente, o desempenho real é no nível espacial.

Instruções SQL espaciais, como a que você está usando, foram permitidas apenas recentemente com a introdução do tipo de geometria. O SQL Server 2008 para ArcSDE suporta três tipos de dados geométricos, SDEBINARY, GEOMETRY e GEOGRAPHY. As diferenças estão listadas aqui

Para obter o melhor desempenho, verifique se você está usando Geometria ou Geografia (embora não SDEBINÁRIA, pois é obsoleta e não recomendada) com base na natureza de seus dados, esteja você usando referência espacial da Terra ou não. Também certifique-se de reconstruir o índice espacial na classe de característica TOWNLANDS. Você pode fazer isso no ArcCatalog clicando com o botão direito do mouse na classe de característica, propriedades e selecione a guia Índices.

Espero que ajude.

Não vejo na sua consulta a necessidade de fazer uma associação. Tente usar 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

Na consulta original, a junção parecia não ter benefício para o resultado; Não vi nenhuma coluna da tabela Shannon na linha de seleção. Portanto, parece um trabalho extra.

Essa é uma limitação conhecida do uso do ArcGIS com o SQL Server que não possui uma correção simples, pelo que sei.

Se o planejador de consultas do SQL Server decidir que precisa de mais de uma CPU para executar a consulta, as chances de o índice espacial estar sendo usado são baixas.

A Microsoft está ciente do problema, mas não tem pressa de melhorar o planejador de consultas, pois isso afetaria todas as consultas, não apenas as espaciais.

A única solução confiável é definir o seu grau máximo de paralelismo (MAXDOP) no seu banco de dados como 1, mas isso significa que todas as consultas nesse banco de dados usarão apenas 1 CPU por consulta, tornando tudo mais lento.

Criar uma visão que represente a tabela e force a dica de índice espacial não funciona, pois o ArcGIS precisa consultar os metadados e as estatísticas da tabela e essa visão mata essas consultas.

Eu tenho um problema similar. Eu tenho uma classe de recurso armazenada no SQL Server como tipo de geometria. Ele possui 30m de registros e atrai muito, mas se você criar uma VIEW vinculada a uma segunda tabela, essa VIEW será interrompida e não será exibida.

A tabela possui uma carga de classes de relacionamento anexadas a ela. Isso afetará o desempenho da consulta / desenho?

Você também pode me indicar a direção do reconhecimento da Microsoft desse problema. Posso forçar o planejador de consultas a usar o índice espacial?

Conta