it-swarm-eu.dev

Důsledky výkonu při používání OPENQUERY v pohledu

Podívejte se prosím na tento dotaz na stackoverflow:

Používám ovladač EasySoft ODBC), který propojuje instanci SQL Server 2008 R2 Express s Interbase a mám potíže s získávání metadat ze vzdáleného serveru. všechny se zmiňují pomocí OPENQUERY namísto syntaxe propojeného serveru se čtyřmi částmi.

NAPŘ. Můj současný (problematický) přístup je ...

CREATE VIEW [LIVE].[vwPRDETS]
AS

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

Ale na některých stolech se mi při vyvolání zobrazení zobrazuje chyba ...

Msg 7353, úroveň 16, stav 1, řádek 1 OLE DB poskytovatel "MSDASQL" pro propojený server "LBLIVE" dodal nekonzistentní metadata. Během provádění byl dodán další sloupec, který nebyl nalezen při kompilaci čas.

Také některé pohledy, které nemůžu ani vytvořit, protože dostávám následující ...

Msg 7315, úroveň 16, stav 1, řádek 1 OLE DB "MSDASQL" pro propojený server "LBLIVE" obsahuje více tabulek, které odpovídají názvu "SYSDBA". "AUDIT_LBABKP" ".

I když existuje pouze jedna z uvedených tabulek.

Zdá se, že alternativní přístup z prohledávání sítě je spíše jako ...

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

Moje otázka tedy zní, že pokud v definici pohledu používám OPENQUERY, bude SQL Server schopen optimalizovat výsledné SQL odeslané do Interbase? Nebo opravdu není velký rozdíl mezi těmito dvěma přístupy?

Je to křížení nad tématem a ráda by dba POV.

15
Rich Andrews

Souhrn

Nechte propojený server dělat co nejvíce.
Je nemožné pro SQL Server optimalizovat dotaz na propojeném serveru, dokonce i na jiném serveru SQL

Dlouho

Klíčovým faktorem je kde je dotaz spuštěn.

V tomto případě se jedná o triviální VÝBĚR, takže všechny řádky z tabulky budou odeslány po drátu. Nezáleží na tom.

Když přidáte PŘIPOJENÍ a KDE, pak na tom může záležet. Chcete, aby SQL Server umožnil propojenému serveru provést co největší filtrování, aby se zmenšila velikost dat přicházejících po síti.

Například druhý případ by zde měl být efektivnější.

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

Omezení OPENQUERY je v tom, že nemůžete parametrizovat: proto potřebujete dynamický SQL, abyste mohli přidat klauzule WHERE atd.

Výkon propojených serverů může být ovlivněn sp_serveroption . Nastavení collation compatible říká vše

Pokud je tato možnost nastavena na true, SQL Server předpokládá, že všechny znaky na propojeném serveru jsou kompatibilní s místním serverem, pokud jde o znakovou sadu a pořadí řazení (nebo pořadí řazení). To umožňuje serveru SQL Server odesílat porovnání sloupců znaků zprostředkovateli. Pokud tato možnost není nastavena, SQL Server vždy vyhodnocuje porovnání na sloupcích znaků místně.

To znamená, zkuste nenechat SQL Server zpracovat data místně.

Poznámka: Na mé foo = 'bar' Druhý příklad výše je filtr odeslán na propojený server, protože je to pouze řetězcová konstanta na SQL Server. Skutečná klauzule WHERE v prvním příkladu může nebo nemusí být zaslána vzdáleně.

Nakonec jsem také zjistil, že rozložení dat do dočasné tabulky a jejich připojení k místním tabulkám je často lepší než připojení přímo k OPENQUERY.

20
gbn