Início / dba / Perguntas / 6860
Accepted
Rich Andrews
Asked: 2011-10-17 03:03:03 +0800 CST

Implicações de desempenho do uso de OPENQUERY em uma exibição

  • 772

Por favor, veja esta pergunta no stackoverflow:

Estou usando um driver EasySoft ODBC para vincular uma instância do SQL Server 2008 R2 Express ao Interbase e estou tendo alguma dificuldade em obter metadados do servidor remoto. Ao procurar na rede, todas as principais sugestões mencionam o uso de OPENQUERY em vez da sintaxe de servidor vinculado de quatro partes.

EG Minha abordagem atual (problemática) é...

CREATE VIEW [LIVE].[vwPRDETS]
AS

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

Porém em algumas tabelas recebo o erro ao chamar a view...

Msg 7353, Nível 16, Estado 1, Linha 1 O provedor OLE DB "MSDASQL" para o servidor vinculado "LBLIVE" forneceu metadados inconsistentes. Uma coluna extra foi fornecida durante a execução que não foi encontrada no tempo de compilação.

Além disso, algumas exibições que não consigo criar porque recebo o seguinte ...

Msg 7315, Nível 16, Estado 1, Linha 1 O provedor OLE DB "MSDASQL" para o servidor vinculado "LBLIVE" contém várias tabelas que correspondem ao nome ""SYSDBA"."AUDIT_LBABKP"".

Embora haja apenas uma das tabelas mencionadas.

A abordagem alternativa de pesquisar na net parece ser mais como...

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

Então, minha pergunta é, se eu usar OPENQUERY na minha definição de exibição, o SQL Server será capaz de otimizar o SQL resultante enviado ao Interbase? Ou realmente não há muita diferença entre as duas abordagens?

É um assunto cruzado e adoraria o ponto de vista de um dba.

sql-server-2008

1 respostas

  1. Best Answer

    Resumo

    Deixe o servidor vinculado fazer o máximo possível.
    É impossível para o SQL Server otimizar uma consulta em um servidor vinculado, mesmo outro SQL Server

    Grandes

    O fator chave é onde a consulta é executada.

    Nesse caso, é um SELECT trivial, de modo que todas as linhas de uma tabela serão enviadas pela rede. Não importa.

    Quando você adiciona JOINs e WHEREs, isso pode importar. Você deseja que o SQL Server permita que o servidor vinculado faça o máximo de filtragem possível para reduzir o tamanho dos dados provenientes da rede.

    Por exemplo, o 2º caso aqui deve ser mais eficiente.

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

    Uma limitação do OPENQUERY é que você não pode parametrizar: então você precisa de um SQL dinâmico para adicionar cláusulas WHERE etc.

    O desempenho dos servidores vinculados pode ser afetado por sp_serveroption. A configuração collation compatiblediz tudo

    Se esta opção for definida como true, o SQL Server assume que todos os caracteres no servidor vinculado são compatíveis com o servidor local, no que diz respeito ao conjunto de caracteres e à sequência de collation (ou ordem de classificação). Isso permite que o SQL Server envie comparações em colunas de caracteres para o provedor. Se essa opção não for definida, o SQL Server sempre avalia as comparações em colunas de caracteres localmente.

    Ou seja, tente não deixar o SQL Server processar os dados localmente.

    Nota: No meu foo = 'bar'2º exemplo acima, o filtro é enviado para o servidor vinculado porque é apenas uma string constante para o SQL Server. A cláusula WHERE real no primeiro exemplo pode ou não ser enviada remotamente.

    Por fim, também descobri que preparar os dados em uma tabela temporária e juntá-los em tabelas locais geralmente é melhor do que ingressar diretamente no OPENQUERY.

    • 21

relate perguntas