Você está offline; aguardando reconexão

CORRECÇÃO: Estoque associações externas com critérios de filtro antes de associações não seletivas e associações externas

IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.

Clique aqui para ver a versão em Inglês deste artigo: 318530
BUG #: 356418 (SHILOH_BUGS)
Sintomas
Se você enviar uma consulta que contém pelo menos uma associação externa que possui uma condição de filtro na cláusula WHERE na tabela interna da associação externa (por exemplo, uma condição de filtro na tabela direita de uma associação externa esquerda ou tabela à esquerda de uma associação externa direita), SQL Server podem executar associações menos seletivas primeiro em vez de executar a associação externa no início e aplicar a condição de filtro. Se a condição de filtro de associação externa é um dos critérios de consulta mais seletivos, Falha ao processar os critérios no início do plano pode levar a:
  • Tamanhos maiores de associação intermediário.
  • Processar mais alta utilização de recursos pelo SQL Server.
  • Tempo de resposta mais lento para a consulta.
Resolução

Resolução para o SQL Server 2005

Para resolver esse problema, obtenha o service pack mais recente para o SQL Server 2005. Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
913089Como obter o service pack mais recente para o SQL Server 2005
Depois de instalar o SQL Server 2005 service pack, você deve ativar o sinalizador de rastreamento 4101 para resolver esse problema.

Resolução para o SQL Server 2000

Para resolver esse problema, obtenha o service pack mais recente para o Microsoft SQL Server 2000. Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
290211Como obter o SQL Server 2000 service pack mais recente
Observação : O seguinte hotfix foi criado antes do lançamento do Microsoft SQL Server 2000 Service Pack 3.

A versão em inglês dessa correção deve ter os seguintes atributos de arquivo ou posteriores:
   Version       File name   -----------------------------   8.00.0584     Sqlservr.exe				
Observação : devido a dependências do arquivo, o hotfix mais recente ou o recurso que contém os arquivos pode também conter arquivos adicionais.

Situação

Status de SQL Server 2005

A Microsoft confirmou que este é um problema nos produtos da Microsoft listados na seção "Aplica-se a".
Esse problema foi corrigido primeiro no Microsoft SQL Server 2005 Service Pack 1.

Status de SQL Server 2000

A Microsoft confirmou que este é um problema nos produtos da Microsoft listados na seção "Aplica-se a".
Esse problema foi corrigido primeiro no Microsoft SQL Server 2000 Service Pack 3.
Mais Informações
O cenário de associação forçado a seguir usa o banco de dados pubs para demonstrar o cenário:
set ansi_nulls offgouse pubsgocreate procedure dbo.ansi_nulls_param @P1 varchar(11) asselect t.title_id, a.au_id, ta.title_id, s.stor_id from titles t    left outer join titleauthor ta on ta.title_id = t.title_id   inner join authors a on a.au_id = t.title_id   inner join sales s on s.title_id = t.title_idwhere ta.title_id = @P1goexec dbo.ansi_nulls_param '123-45-6789'godrop proc dbo.ansi_nulls_paramgo--Slower Query Plan:       |--Filter(WHERE:([ta].[title_id]=[@P1]))            |--Nested Loops(Left Outer Join, OUTER REFERENCES:([t].[title_id]))                 |--Nested Loops(Inner Join, OUTER REFERENCES:([s].[title_id]))                 |    |--Nested Loops(Inner Join, OUTER REFERENCES:([s].[title_id]))                 |    |    |--Index Scan(OBJECT:([pubs].[dbo].[sales].[titleidind] AS [s]))                 |    |    |--Clustered Index Seek(OBJECT:([pubs].[dbo].[authors].[UPKCL_auidind] AS [a]), SEEK:([a].[au_id]=[s].[title_id]) ORDERED FORWARD)                 |    |--Clustered Index Seek(OBJECT:([pubs].[dbo].[titles].[UPKCL_titleidind] AS [t]), SEEK:([t].[title_id]=[s].[title_id]) ORDERED FORWARD)                 |--Index Seek(OBJECT:([pubs].[dbo].[titleauthor].[titleidind] AS [ta]), SEEK:([ta].[title_id]=[t].[title_id]) ORDERED FORWARD)--Faster Query Plan:       |--Nested Loops(Inner Join, OUTER REFERENCES:([a].[au_id]))            |--Nested Loops(Inner Join, OUTER REFERENCES:([t].[title_id]))            |    |--Filter(WHERE:([ta].[title_id]=[@P1]))            |    |    |--Nested Loops(Left Outer Join, OUTER REFERENCES:([t].[title_id]))            |    |         |--Index Scan(OBJECT:([pubs].[dbo].[titles].[titleind] AS [t]))            |    |         |--Index Seek(OBJECT:([pubs].[dbo].[titleauthor].[titleidind] AS [ta]), SEEK:([ta].[title_id]=[t].[title_id]) ORDERED FORWARD)            |    |--Clustered Index Seek(OBJECT:([pubs].[dbo].[authors].[UPKCL_auidind] AS [a]), SEEK:([a].[au_id]=[t].[title_id]) ORDERED FORWARD)            |--Index Seek(OBJECT:([pubs].[dbo].[sales].[titleidind] AS [s]), SEEK:([s].[title_id]=[a].[au_id]) ORDERED FORWARD)				
Observe que a tabela titleauthor é a tabela à direita de uma associação externa esquerda e WHERE cláusula condição em titleauthor que deve ser aplicada após a junção externa. A saída mostra o plano de consulta original, mais lenta, onde todas as associações internas são executadas primeiro e a associação externa e o filtro é executada por último, mesmo que ele seja a mais seletiva condição para a consulta. O segundo plano de consulta é um plano forçado que demonstra o plano mais rápido aparência, em que a associação externa e o filtro é executada primeiro, seguido as restantes associações internas.

Para esse cenário específico, o otimizador continua a escolher o primeiro plano mesmo depois de você aplicar o hotfix. Isso ocorre porque essas tabelas são tão pequenas e o custo estimado do primeiro plano é baixo o suficiente para que ele é considerado melhor executar apenas com esse plano que continuar a pesquisa de alternativas subseqüentes. À medida que os dados nas tabelas aumenta, o custo do primeiro plano torna-se maior e inicia o otimizador para escolher o segundo plano.

Aviso: este artigo foi traduzido automaticamente

Propriedades

ID do Artigo: 318530 - Última Revisão: 02/04/2008 17:13:56 - Revisão: 5.1

Microsoft SQL Server 2000 Standard Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Workgroup Edition

  • kbmt kbhotfixserver kbqfe kbsqlserv2000sp3fix kbbug kbfix kbsqlserv2000presp3fix KB318530 KbMtpt
Comentários
html>