SQL Server performansında ArcGIS 10.2 Sorgu Katmanı

ArcMap SQL Server'da bir Sorgu Katmanı kullanıyorum. Sorgu Katmanı SQL Server'da anında yürütülür, ancak ArcMap'ta çizilmesi o kadar uzun sürer ki sistem yaklaşık 10 dakika veya daha uzun süre yanıt vermez görünür. ArcMap draw sırasında CPU'lardan biri SQL Server işleminde maksimize edilir.

Benim Sorgu, bir çokgen özellik sınıfına (Townlands) karşı bir çizgi unsurundaki (Shannon) bir tamponun STIntersects'i;

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

Sorgu anında 186 satır döndürür. Bunlar sorunsuz bir şekilde SQL Server Management Studio Uzamsal bölmesinde çizilebilir

ArcMap'te tam olarak aynı sözdizimiyle bir Sorgu Katmanı oluşturduğumda sistem yanıt vermiyor, ancak sonunda çiziyor. Belki de, ArcMap'ın uzamsal dizini kullanmıyor veya SQL Server'dan farklı bir şekilde yaptığı gibi, SQL Server'da geri dönme çağını alan verimsiz bir sorguya neden oluyor gibi görünüyor.

Birisi bir çare önerebilir mi?

Teşekkürler

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

Belirttiğiniz gibi, sorgunuz veritabanı düzeyinde hızlı bir şekilde yürütülüyor gibi görünüyor. SQL'i daha verimli hale getirebilseniz bile, gerçek performans mekansal düzeydedir.

Kullandığınız gibi uzamsal SQL ifadelerine, yalnızca son zamanlarda geometri türünün girişiyle izin verildi. ArcSDE için SQL Server 2008, üç geometri veri türünü destekler: SDEBINARY, GEOMETRY ve COĞRAFYA. Farklılıklar burada listelenmiştir

En iyi performans için, ister dünya uzamsal referans kullanıyor olun, ister kullanmayın, verilerinizin doğasına bağlı olarak Geometri veya Coğrafya'yı (eski ve tavsiye edilmediğinden SDEBINARY değil) kullandığınızdan emin olun. Ayrıca TOWNLANDS özellik sınıfında uzamsal indeksi yeniden oluşturduğunuzdan emin olun. Bunu ArcCatalog'dan özellik sınıfına, özelliklere sağ tıklayarak ve dizinler sekmesini seçerek yapabilirsiniz.

Umarım yardımcı olur.

Sorgunuzda katılma gereğini görmüyorum. Bunun yerine NEREDE kullanmayı deneyin.

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

Orijinal sorguda, birleştirmenin sonuca hiçbir faydası olmadığı ortaya çıktı; Seçim satırında Shannon tablosundan herhangi bir sütun görmedim. Bu nedenle, ekstra bir iş gibi görünüyor.

Bu, bildiğim kadarıyla basit bir düzeltmeye sahip olmayan SQL Server ile ArcGIS kullanımının bilinen bir sınırlamasıdır.

SQL Server sorgu planlayıcısı sorguyu yürütmek için birden fazla CPU gerektiğine karar verirse, kullanılan uzamsal dizinin olasılıkları düşüktür.

Microsoft sorunun farkındadır, ancak yalnızca uzamsal olanları değil tüm sorguları etkileyeceği için sorgu planlayıcısını geliştirmek için acele etmemektedir.

Tek güvenilir çözüm, veritabanınızdaki maksimum paralellik derecenizi (MAXDOP) 1 olarak ayarlamaktır, ancak bu, DB'deki tüm sorguların sorgu başına yalnızca 1 CPU kullanacağı ve her şeyi yavaşlatacağı anlamına gelir.

Tabloyu temsil eden ve uzamsal dizin ipucunu zorlayan bir görünüm oluşturmak, ArcGIS'in tablonun meta verilerini ve istatistiklerini sorgulaması gerektiğinden bu tür bir görünüm bu sorguları öldürür.

Benzer bir sorunum var. Geometri türü olarak SQL Server'da depolanan bir özellik sınıfı var. İçinde 30m kayıt var ve çekilişi iyi, ancak 2. tabloya bağlı bir GÖRÜNÜM oluşturursanız, bu GÖRÜNÜM askıda kalır ve görüntülenmez.

Tablo, kendisine bağlı bir ilişki sınıfları yüküne sahiptir. Bunlar sorgu / çizim performansını etkiler mi?

Ayrıca bana Microsoft'un bu sorunu tanıdığı yönünde işaret edebilir misiniz? Sorgu planlayıcısını uzamsal dizini kullanmaya zorlayabilir miyim?

fatura