Início / dba / Perguntas / 10873
Accepted
vstrien
Asked: 2012-01-19 02:21:21 +0800 CST

Desempenho do SQL Server Linked Server: Por que as consultas remotas são tão caras?

  • 772

Tenho dois servidores de banco de dados, conectados via Linked Servers. Ambos são bancos de dados SQL Server 2008R2, e a conexão do servidor vinculado é feita por meio de um link "SQL Server" regular, usando o contexto de segurança do logon atual. Os servidores vinculados estão ambos no mesmo datacenter, portanto, a conexão não deve ser um problema.

Eu uso a seguinte consulta para verificar quais valores da coluna identifierestão disponíveis remotamente, mas não localmente.

SELECT 
    identifier 
FROM LinkedServer.RemoteDb.schema.[TableName]

EXCEPT

SELECT DISTINCT
    identifier 
FROM LocalDb.schema.[TableName]

Em ambas as tabelas há índices não clusterizados na coluna identifier. Localmente são cerca de 2,6 milhões de linhas, remotamente apenas 54. No entanto, ao analisar o plano de consulta, 70% do tempo de execução é dedicado à "execução de consulta remota". Além disso, ao estudar o plano de consulta completo, o número de linhas locais estimadas é 1em vez de 2695380(que é o número de linhas estimadas ao selecionar apenas a consulta posterior a EXCEPT). Plano de execução Ao executar esta consulta, leva muito tempo.

Isso me faz pensar: Por que isso? A estimativa está "apenas" longe ou as consultas remotas em servidores vinculados são realmente tão caras?

sql-server sql-server-2008-r2

5 respostas

  1. Best Answer

    O plano que você tem no momento parece o plano mais ideal para mim.

    Não concordo com a afirmação nas outras respostas de que está enviando as linhas de 2,6 milhões para o servidor remoto.

    O plano me parece que, para cada uma das 54 linhas retornadas da consulta remota, ele está realizando uma busca de índice em sua tabela local para determinar se há correspondência ou não. Este é praticamente o plano ideal.

    Substituir por uma junção de hash ou junção de mesclagem seria contraproducente devido ao tamanho da tabela e adicionar uma #temptabela intermediária apenas adiciona uma etapa adicional que parece não oferecer nenhuma vantagem.

    • 10

  2. Conectar-se a um recurso remoto é caro. Período.

    Uma das operações mais caras em qualquer ambiente de programação é a E/S de rede (embora a E/S de disco tenda a superá-la).

    Isso se estende a servidores vinculados remotos. O servidor que chama o servidor remoto vinculado precisa primeiro estabelecer uma conexão, depois uma consulta precisa ser executada no servidor remoto, os resultados são retornados e a conexão é fechada. Tudo isso leva tempo na rede.

    Você também deve estruturar sua consulta de forma que transfira o mínimo de dados pela rede. Não espere que o banco de dados otimize para você.

    Se eu fosse escrever essa consulta, selecionaria os dados remotos em uma variável de tabela (ou em uma tabela temporária) e usaria isso em conjunto com a tabela local. Isso garante que apenas os dados que precisam ser transferidos serão transferidos.

    A consulta que você está executando pode facilmente enviar 2,6 milhões de linhas para o servidor remoto para processar a EXCEPTcláusula.

    • 6

  3. Não sou especialista, mas se você estiver usando Union, Except ou Intersect, não precisará usar "Distinct". Dependendo dos valores de LocalDb.schema.[TableName], o desempenho da consulta pode ser melhorado.

    SELECT 
    identifier 
FROM LinkedServer.RemoteDb.schema.[TableName]

EXCEPT

SELECT 
    identifier 
FROM LocalDb.schema.[TableName]
    • 1

  4. Oded está certo, o problema de desempenho é causado pelo envio de 2,6 milhões de linhas para o seu servidor remoto.

    Para corrigir esse problema, você pode forçar os dados remotos (54 linhas) sendo enviados para você usando uma tabela temporária ou na memória.

    Usando uma tabela temporária

    SELECT  identifier 
INTO    #TableName
FROM    LinkedServer.RemoteDb.schema.[TableName]

SELECT  identifier
FROM    #TableName
EXCEPT
SELECT  DISTINCT identifier 
FROM    LocalDb.schema.[TableName] 

DROP    #TableName
    • 0

  5. Acho que é melhor replicar a tabela remota para o servidor do qual você está consultando e, em seguida, executar todo o seu SQL localmente.

    • 0

relate perguntas