Bir görünümde OPENQUERY kullanımının performans sonuçları

Lütfen stackoverflow ile ilgili şu soruya bakın :

Bir SQL Server 2008 R2 Express örneğini Interbase'e bağlamak için bir EasySoft ODBC sürücüsü kullanıyorum ve uzak sunucudan meta veri alma konusunda bazı zorluklar yaşıyorum. Net üzerinden bakıldığında ana öneriler tüm dört bölüm bağlantılı sunucu sözdizimi yerine OPENQUERY kullanarak söz.

EG Şu anki (sorunlu) yaklaşımım ...

CREATE VIEW [LIVE].[vwPRDETS]
AS

SELECT *
FROM [LBLIVE]...[PRDETS] WITH (NOLOCK)

Ancak bazı tablolarda görünümü çağırırken hata alıyorum ...

Msg 7353, Seviye 16, Durum 1, Satır 1 Bağlı sunucu "LBLIVE" için OLE DB sağlayıcısı "MSDASQL" tutarsız meta veriler sağladı. Yürütme sırasında derleme zamanında bulunmayan fazladan bir sütun sağlandı.

Ayrıca, aşağıdakileri bile elde edemediğim bazı görünümler bile oluşturamıyorum ...

Msg 7315, Düzey 16, Durum 1, Satır 1 Bağlantılı sunucu "LBLIVE" için OLE DB sağlayıcısı "MSDASQL", "" SYSDBA "adıyla eşleşen birden çok tablo içeriyor." AUDIT_LBABKP "".

Belirtilen tablolardan sadece biri olmasına rağmen.

İnternette arama yapmanın alternatif yaklaşımı daha çok ...

SELECT *
FROM OPENQUERY(<linked sevrer>, 'SELECT <column list> FROM MyTable')

Benim sorum, benim açıklamamda OPENQUERY kullanırsanız SQL Server Interbase gönderilen sonuç optimize edecek? Yoksa iki yaklaşım arasında gerçekten fazla bir fark yok mu?

Bu konu üzerinde bir haç ve bir dba POV isterdim.

özet

Bağlı sunucunun mümkün olduğunca yapmasına izin verin.
Öyle imkansız SQL Server, bağlantılı bir sunucu üzerinde bile başka SQL Server bir sorgu optimize etmek için

Uzun

Anahtar faktör, sorgunun çalıştığı yerdir .

Bu durumda, önemsiz bir SELECT olur, böylece bir tablodaki tüm satırlar telden gönderilir. Önemli değil.

JOIN ve NEREDE eklediğinizde önemli olabilir. SQL Server'ın, bağlı sunucunun ağ üzerinden gelen verilerin boyutunu azaltmak için mümkün olduğunca fazla filtreleme yapmasına izin vermesini istiyorsunuz.

Örneğin, buradaki 2. durum daha verimli olmalıdır.

SELECT *
FROM OPENQUERY(<linked server>, 
            'SELECT <column list> FROM MyTable') T1
     JOIN
     SomeLocalTable T2 ON ...
WHERE T1.foo = 'bar'

SELECT *
FROM OPENQUERY(<linked server>, 
           'SELECT <column list> FROM MyTable WHERE foo = ''bar''')
     JOIN
     SomeLocalTable T2 ON ...

OPENQUERY'in bir sınırlaması parametre edememenizdir: bu nedenle WHERE yan tümceleri vb. Eklemek için dinamik SQL'e ihtiyacınız vardır.

Bağlantılı sunucuların performansı bundan etkilenebilir sp_serveroption. Ayar collation compatibleher şeyi söylüyor

Bu seçenek true olarak ayarlanırsa, SQL Server, bağlantılı sunucudaki tüm karakterlerin, karakter kümesi ve harmanlama sırası (veya sıralama düzeni) bakımından yerel sunucu ile uyumlu olduğunu varsayar. Bu, SQL Server'ın karakter sütunları üzerinde karşılaştırmayı sağlayıcıya göndermesini sağlar. Bu seçenek ayarlanmazsa, SQL Server karakter sütunlarındaki karşılaştırmaları her zaman yerel olarak değerlendirir.

Yani, SQL Server'ın verileri yerel olarak işlemesine izin vermemeye çalışın.

Not: foo = 'bar'Yukarıdaki 2. örneğimde, filtre yalnızca SQL Server için bir dize sabiti olduğundan bağlantılı sunucuya gönderilir. İlk örnekteki gerçek WHERE yantümcesi uzaktan gönderilebilir veya gönderilmez.

Son olarak, verileri geçici bir tabloya yerleştirmenin ve yerel tablolara katılmanın genellikle doğrudan OPENQUERY'e katılmanın daha iyi olduğunu da buldum.