LINQ-to-Entities se débarrasser de sp_executesql

Question

J'essaie d'optimiser ma base de données maintenant en utilisant Database Engine Tuning Advisor, et le problème que je suis confronté est que ma trace de profileur SQL montre des tonnes de requêtes effectuées en utilisant sp_executesql - et le conseiller ne parvient pas à traiter les . Il semble que ces requêtes proviennent de LINQ-to-Entities que j'utilise, donc il suffit de se demander s'il existe un moyen de faire en sorte que LINQ-to-Entities invoque directement les instructions.

Answer 1

D'accord avec Adam. L'utilisation de sp_executesql dans entity framework/ADO.net est intentionnelle. Les requêtes sont ensuite exécutées de manière similaire à la procédure stockée paramétrée et l'optimiseur SQL peut réutiliser le plan de requête.

Si vous souhaitez optimiser votre base de données, vous devez également prendre en compte ces requêtes. Je vous suggère, prenez une sauvegarde de votre base de données, capturez les requêtes en utilisant le modèle de trace de relecture (dans votre profileur SQL), restaurez votre base de données, réglez votre charge de travail sur cette trace

Answer 2

L'utilisation de sp_executesql est un effet ADO.NET, et non spécifique à Entity Framework. Pour autant que je sache, il n'y a aucun moyen de ne pas utiliser cette procédure stockée.

Answer 3

Ceci est juste un artefact de comment Les appels RPC sont affichés dans le profileur. Il existe deux principaux types de requêtes client: Language (type 0x01) et RPC (type 0x03), comme documenté par le Free TDS protocol documentation. Lorsque l'appel est un lot SQL avec des paramètres, l'appel RPC sera de type 0x03 avec une longueur 0x0A qui est un raccourci pour sp_executesql.

Donc, vous voyez, ce qui se passe vraiment est que lorsqu'un client, tout client, soumet un lot qui contient des paramètres, il apparaît comme si sp_executesql est appelé. Cela est vrai avec ODBC, avec OleDB, SqlClient, Sql Native Client, comme je l'ai dit, tout client. Ainsi, Entity Framework, ni ADO.Net n'appelle réellement sp_executesql (en fait, la procédure n'est même pas appelée, bien que les requêtes s'exécutent comme si elles étaient appelées. C'est un artefact du protocole qui se produit chaque fois que vous ajoutez un @parameter à votre demande.

Answer 4

LINQ/.NET exécute des requêtes SQL en les envoyant en tant qu'appels sp_executesql au serveur SQL. Toutefois, Database Engine Tuning Advisor ne peut pas analyser, par SQL Server Profiler, les instructions capturées, de sorte que le résultat de la session d'optimisation sera faible.

Voici comment je "décompose" les instructions sp_executesql avant de les transmettre à Database Engine Tuning Advisor afin qu'il puisse les analyser correctement.

1. Après avoir exécuté (ou ouvert une existante) session de mise au point dans Profiler SQL Server, utilisez Fichier> Exporter> Extrait des événements SQL Server> Extraire des événements Transact-SQL ... pour économiser. Fichier SQL contenant toutes les instructions SQL.
2. Ouvrez le fichier .SQL (par exemple, dans Notepad ++ 6-http://notepad-plus-plus.org/) et exécutez la commande suivante Trouver & Remplacement Expression régulière à unbox toutes sp_executesql déclarations à TSQL ordinaire. Trouver: ^EXEC[\s]+SP_EXECUTESQL[\s]+[N]*'((''|[^'])*)'[\s]*,[\s]*[N]*'((''|[^'])*)'[\s]*,[\s]*([^\n]+)$ Remplacer: BEGIN\nDECLARE \3\nSELECT \5\n\1\nEND
3. Ensuite, utilisez le 'Unboxed' .SQL a déposé que nous venons de construit Database Engine Tuning Advisor pour savoir quels indices vous NEEED à ajouter.

Bon réglage! Veuillez noter que j'ai sélectionné Notepad ++ 6 (ou plus), car il a une très bonne implémentation d'expressions régulières, d'autres texteditors peuvent échouer lors de l'exécution de l'expression ci-dessus.