Les performances diminuent lorsque vous exécutez une instruction SELECT... DANS la requête après la mise à niveau vers SQL Server 2012 et les versions ultérieures

IMPORTANT : Cet article est issu d'une traduction automatique réalisée par un logiciel Microsoft et non par un traducteur professionnel. Cette traduction automatique a pu aussi être révisée par la communauté Microsoft grâce à la technologie Community Translation Framework (CTF). Pour en savoir plus sur cette technologie, veuillez consulter la page http://support.microsoft.com/gp/machine-translation-corrections/fr. Microsoft vous propose en effet des articles traduits par des professionnels, des articles issus de traductions automatiques et des articles issus de traductions automatiques révisées par la communauté Microsoft, de manière à ce que vous ayez accès à tous les articles de notre Base de connaissances dans votre langue. Il est important de noter que les articles issus de la traduction automatique, y compris ceux révisés par la communauté Microsoft, peuvent contenir des erreurs de vocabulaire, de syntaxe ou de grammaire. Microsoft ne pourra être tenu responsable des imprécisions, erreurs, ainsi que de tout dommage résultant d’une traduction incorrecte du contenu ou de son utilisation par les clients.

La version anglaise de cet article est la suivante: 3144525
Symptômes
Une fois que vous mettez à niveau Microsoft SQL Server 2008 R2 ou une version antérieure à SQL Server 2012 ou une version ultérieure, vous pouvez remarquer queSELECT... EN les requêtes qui contiennent des fonctions définies par l'utilisateur prennent un temps plus long que dans les versions antérieures.
Cause
Ce problème se produit car cette Sélectionner... EN les instructions qui contiennent des fonctions définies par l'utilisateur (UDF) sont des opérations entièrement consignées et prendre plus de temps dans SQL Server 2012 et les versions ultérieures.

Remarque Tout sélectionner ... EN les instructions qui contiennent des fonctions définies par l'utilisateur sont des opérations journalisées dans les versions antérieures (SQL Server 2008 R2 et versions antérieures). Cette modification a été introduite pour s'assurer de l'intégrité des données, comme la fonction définie par l'utilisateur peut effectuer des opérations de lecture/écriture sur le même objet et peut entraîner une corruption des données si la journalisation minimale est activée.
Contournement
Si vous sélectionnez des fonctions définies par l'utilisateur qui sont utilisées dans le ... DANS instruction n'exécutent pas les opérations d'accès aux données, vous pouvez spécifier la clause SCHEMABINDING pour les fonctions définies par l'utilisateur, qui définit la propriété dérivée de UserDataAccess pour les fonctions définies par l'utilisateur à 0. Après cette modification, SELECT... EN les instructions seront consignées dans le journal. Pour plus d'informations, reportez-vous à la section. l'exemple dans le blog pour obtenir un exemple sur l'utilisation de SCHEMABINDING.

Remarque Si l'instruction fait toujours référence au moins une fonction définie par l'utilisateur qui a la valeur 1 à cette propriété, l'opération est entièrement consignée.
Plus d'informations
L'exemple de code suivant illustre la différence de comportement entre SQL Server 2008 R2 et SQL Server 2012 ou 2014 :

create database DB1gouse DB1gocreate function dbo.MyTrim (@name as varchar(100))returns varchar (100)asbeginreturn (RTRIM(ltrim(@name)))endgocreate table dbo.tab_prod (c1 int, c2 varchar(10))godeclare @a int set @a = 1while @a <= 100000begin insert into tab_prodvalues (@a , '  test ')set @a = @a + 1endbegin transelect  *,  dbo.mytrim(c2) as trimc2 into tab_test from tab_prod

Le tableau suivant compare le temps processeur pour une opération select dans SQL Server 2008 R2 avec celle de SQL Server 2014 :

Version francaiseDurée d'exécution (temps UC)
SQL Server 2008 R2719 ms
SQL Server 20141360 ms

Le tableau suivant compare l'utilisation du journal des transactions pour une opération select dans SQL Server 2008 R2 avec celle de SQL Server 2014 :

Version francaiseNom de la base de donnéesTaille du journal (Mo)Espace journal utilisé (%)État
SQL Server 2008 R2DB10.742187551.578950
SQL Server 2014DB132.1796938.44380
Remarque importante Les résultats de ces tables ne sont qu'un exemple de la modification de comportement entre SQL Server 2008 R2 et SQL Server 2014 et sont très spécifiques à l'environnement de laboratoire qui a été utilisé pour ce test. La différence de performances réelles dans votre environnement dépend de votre instance SQL est en cours d'exécution sur le matériel.
Remarque Il s'agit d'un article de « PUBLICATION RAPIDE » rédigé directement au sein du service de support technique Microsoft. Les informations qui y sont contenues sont fournies en l'état, en réponse à des problèmes émergents. En raison du délai rapide de mise à disposition, les informations peuvent contenir des erreurs typographiques et, à tout moment et sans préavis, faire l'objet de révisions. Pour d'autres considérations, consultez les Conditions d'utilisation.

Avertissement : Cet article a été traduit automatiquement.

Propriétés

ID d'article : 3144525 - Dernière mise à jour : 03/03/2016 22:41:00 - Révision : 1.0

Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Workgroup Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2008 Developer, Microsoft SQL Server 2008 Enterprise, Microsoft SQL Server 2008 Express, Microsoft SQL Server 2008 Standard, Microsoft SQL Server 2008 Web, Microsoft SQL Server 2008 Workgroup, Microsoft SQL Server 2008 R2 Datacenter, Microsoft SQL Server 2008 R2 Developer, Microsoft SQL Server 2008 R2 Enterprise, Microsoft SQL Server 2008 R2 Express, Microsoft SQL Server 2008 R2 Standard, Microsoft SQL Server 2008 R2 Web, Microsoft SQL Server 2008 R2 Workgroup

  • kbsurveynew kbtshoot kbexpertiseadvanced kbmt KB3144525 KbMtfr
Commentaires