Vous êtes actuellement hors ligne, en attente de reconnexion à Internet.

CORRECTIF : commande externe relie avec critères de filtre avant de jointures non sélectives et les jointures externes

Extended support for SQL Server 2005 ends on April 12, 2016

If you are still running SQL Server 2005 after April 12, 2016, you will no longer receive security updates and technical support. We recommend upgrading to SQL Server 2014 and Azure SQL Database to achieve breakthrough performance, maintain security and compliance, and optimize your data platform infrastructure. Learn more about the options for upgrading from SQL Server 2005 to a supported version here.

IMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d’articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d’avoir accès, dans votre propre langue, à l’ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que ferait une personne étrangère s’exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s’efforce aussi continuellement de faire évoluer son système de traduction automatique.

La version anglaise de cet article est la suivante: 318530
BOGUE #: 356418 (SHILOH_BUGS)
Symptômes
Au si vous envoyer une requête qui contient au moins une jointure externe qui possède une condition de filtre dans la clause WHERE de la table interne de la jointure externe (par exemple, une condition de filtre sur la table droite d'une jointure externe gauche ou la table de gauche d'une jointure externe droite), SQL Server peut jointures moins sélectives tout d'abord lieu d'effectuer exécuter plus tôt la jointure externe et en appliquant la condition de filtre. Si la condition de filtre de la jointure externe est un des critères plus sélectifs de la requête, Échec de traiter les critères très tôt dans le plan peut conduire à :
  • Plus grande taille jointure intermédiaire.
  • Utilisation des ressources plus élevée par le serveur SQL traiter.
  • Temps de réponse plus lente de la requête.
Résolution

Résolution pour SQL Server 2005

Pour résoudre ce problème, procurez-vous le dernier service pack pour SQL Server 2005. Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
913089 Comment obtenir le dernier pack service pour SQL Server 2005
Après avoir installé le service pack SQL Server 2005, vous devez activer l'indicateur de suivi 4101 pour résoudre ce problème.

Résolution pour SQL Server 2000

Pour résoudre ce problème, procurez-vous le dernier service pack Microsoft SQL Server 2000. Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
290211 Comment obtenir le dernier pack de service SQL Server 2000
Remarque : le correctif suivant a été créé avant la publication de Microsoft SQL Server 2000 Service Pack 3.

La version anglaise de ce correctif doit avoir les attributs de fichier suivants ou ceux d'une version ultérieure :
   Version       File name   -----------------------------   8.00.0584     Sqlservr.exe				
Remarque : raison des dépendances de fichiers, la plus récente correctif fonctionnalité ou qui contient les fichiers peut également contenir des fichiers supplémentaires.

Statut

État de SQL Server 2005

Microsoft a confirmé que c'est un problème dans les produits Microsoft répertoriés dans la section « S'applique à ».
Ce problème a été corrigé dans Microsoft SQL Server 2005 Service Pack 1.

État de SQL Server 2000

Microsoft a confirmé que c'est un problème dans les produits Microsoft répertoriés dans la section « S'applique à ».
Ce problème a été corrigé dans Microsoft SQL Server 2000 Service Pack 3.
Plus d'informations
Le scénario de jointure inventée suivant emploie la base de données pubs pour illustrer le scénario :
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)				
Remarque que la table titleauthor est la table de droite d'une jointure externe gauche et le WHERE condition clause sur titleauthor doit être appliquée après la jointure externe. La sortie affiche le plan de requête d'origine, plus lent, où toutes les jointures internes sont effectuées tout d'abord et la jointure externe et le filtre est effectuée en dernier, même s'il est la condition plus sélective de la requête. Le second plan de requête est un plan forcé qui illustre le plan plus rapide aspect, dans laquelle la jointure externe et le filtre est effectué tout d'abord, suivi par les autres jointures internes.

Pour ce scénario particulier, l'optimiseur continue à choisir le premier plan même après avoir appliqué le correctif. Cela est dû au fait que ces tables sont trop petites pour et le coût estimé du premier plan est faible assez qu'il est jugé préférable d'exécuter uniquement avec ce plan que de continuer la recherche d'alternatives suivantes. Que les données des tables augmente, le coût du premier plan devient supérieur et l'optimiseur commence à choisir le second plan.

Propriétés

ID d'article : 318530 - Dernière mise à jour : 02/04/2008 17:13:56 - Révision : 5.1

Microsoft SQL Server 2000 Standard, 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 KbMtfr
Commentaires