Auswirkungen auf die Leistung der Verwendung von OPENQUERY in einer Ansicht

Bitte sehen Sie diese Frage auf Stackoverflow:

Ich verwende einen EasySoft-ODBC-Treiber, um eine SQL Server 2008 R2 Express-Instanz mit Interbase zu verknüpfen, und habe Probleme, Metadaten vom Remoteserver abzurufen. Ausgehend von der Suche im Internet erwähnen alle Hauptvorschläge die Verwendung von OPENQUERY anstelle der vierteiligen Syntax für verknüpfte Server.

EG Mein aktueller (problematischer) Ansatz ist ...

CREATE VIEW [LIVE].[vwPRDETS]
AS

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

Aber bei einigen Tabellen erhalte ich den Fehler beim Aufruf der Ansicht ...

Meldung 7353, Ebene 16, Status 1, Zeile 1 Der OLE DB-Anbieter "MSDASQL" für den Verbindungsserver "LBLIVE" hat inkonsistente Metadaten bereitgestellt. Während der Ausführung wurde eine zusätzliche Spalte angegeben, die zum Zeitpunkt der Kompilierung nicht gefunden wurde.

Einige Ansichten kann ich auch nicht erstellen, da ich Folgendes erhalte ...

Meldung 7315, Ebene 16, Status 1, Zeile 1 Der OLE DB-Anbieter "MSDASQL" für den Verbindungsserver "LBLIVE" enthält mehrere Tabellen, die mit dem Namen "SYSDBA". "AUDIT_LBABKP" übereinstimmen.

Obwohl es nur eine der genannten Tabellen gibt.

Der alternative Ansatz zum Durchsuchen des Netzes scheint eher ...

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

Meine Frage ist also, ob SQL Server das an Interbase gesendete SQL optimieren kann, wenn ich OPENQUERY in meiner Ansichtsdefinition verwende. Oder gibt es wirklich keinen großen Unterschied zwischen den beiden Ansätzen?

Es ist ein Cross-Over-Thema und würde die POV einer DBA lieben.

Zusammenfassung

Lassen Sie den Verbindungsserver so viel wie möglich tun.
Es ist für SQL Server unmöglich , eine Abfrage auf einem Verbindungsserver zu optimieren, auch auf einem anderen SQL Server

Lange

Der Schlüsselfaktor ist, wo die Abfrage ausgeführt wird.

In diesem Fall handelt es sich um ein einfaches SELECT, sodass alle Zeilen aus einer Tabelle über die Leitung gesendet werden. Es spielt keine Rolle.

Wenn Sie JOINs und WHEREs hinzufügen, kann dies von Bedeutung sein. Sie möchten, dass SQL Server dem Verbindungsserver ermöglicht, so viel wie möglich zu filtern, um die Größe der über das Netzwerk eingehenden Daten zu verringern.

Beispielsweise sollte der zweite Fall hier effizienter sein.

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 ...

Eine Einschränkung von OPENQUERY ist, dass Sie nicht parametrisieren können. Daher benötigen Sie dynamisches SQL, um WHERE-Klauseln usw. hinzuzufügen.

Die Leistung von Verbindungsservern kann durch beeinträchtigt werden sp_serveroption. Die Einstellung collation compatiblesagt alles

Wenn diese Option auf true gesetzt ist, geht SQL Server davon aus, dass alle Zeichen im Verbindungsserver in Bezug auf Zeichensatz und Sortierreihenfolge (oder Sortierreihenfolge) mit dem lokalen Server kompatibel sind. Dadurch kann SQL Server Vergleiche für Zeichenspalten an den Anbieter senden. Wenn diese Option nicht festgelegt ist, wertet SQL Server Vergleiche für Zeichenspalten immer lokal aus.

Versuchen Sie also, SQL Server die Daten nicht lokal verarbeiten zu lassen.

Hinweis: In meinem foo = 'bar'zweiten Beispiel oben wird der Filter an den Verbindungsserver gesendet, da er nur eine Zeichenfolgekonstante für SQL Server ist. Die echte WHERE-Klausel im ersten Beispiel kann remote gesendet werden oder nicht.

Schließlich habe ich auch festgestellt, dass das Staging der Daten in einer temporären Tabelle und das Verknüpfen dieser Daten mit lokalen Tabellen oft besser ist als das direkte Verknüpfen mit der OPENQUERY.