Dans une base de données SQL Server sp_recompile
peut être exécuté sur une procédure stockée pour mettre à jour le plan d'exécution. Je voudrais exécuter ceci sur toutes les procédures stockées dans une base de données. De plus, je voudrais exécuter son équivalent sur toutes les fonctions table mais je ne sais pas quelle procédure sys exécuter.
Est-il possible de le faire sans taper manuellement un sp_recompile
ligne pour tous les noms de procédures stockées dans SQL Server Management Studio? De même pour les fonctions table?
Je pense que je dois le faire parce que le VM SQL Server a vu sa mémoire considérablement augmentée mais je ne vois qu'une augmentation marginale du temps d'exécution. Les plans d'exécution affichent 80+ pour cent du temps d'exécution est sur une recherche d'index clusterisé donc je ne pense pas que je puisse faire beaucoup plus pour optimiser les procédures stockées.
Tu peux courir sp_recompile
sur tout en utilisant un curseur pour produire du SQL ad hoc pour chacun et l'exécuter, si vous pensez que cela vous aidera:
DECLARE C CURSOR FOR (SELECT [name] FROM sys.objects WHERE [type] IN ('P', 'FN', 'IF'));
DECLARE @name SYSNAME;
OPEN C;
FETCH NEXT FROM C INTO @name;
WHILE @@FETCH_STATUS=0 BEGIN
EXEC sp_recompile @name;
FETCH NEXT FROM C INTO @name;
END;
CLOSE C;
DEALLOCATE C;
ou vous pouvez produire du SQL ad-hoc et l'exécuter via EXEC
, prend moins de code qui pourrait être légèrement plus efficace:
DECLARE @sql NVARCHAR(MAX) = '';
SELECT @sql += 'EXEC sp_recompile '''+[name]+''''+CHAR(10) FROM sys.objects WHERE [type] IN ('P', 'FN', 'IF');
EXEC (@sql);
(bien que je trouve que ce formulaire jette parfois des personnes en raison de en regardant basé sur un ensemble mais en construisant la chaîne de manière itérative, et n'étant pas un modèle SQL standard)
Un autre ensemble d'objets qui pourrait être un problème similaire ici est les vues. Vous pouvez également les marquer comme devant être réévalués pour vous assurer que les plans stockés et autres métadonnées ne sont pas périmés avec sp_refreshview
, par de petites modifications du curseur ou des méthodes SQL ad hoc ci-dessus:
DECLARE @sql NVARCHAR(MAX) = '';
SELECT @sql += 'EXEC sp_refreshview '''+[name]+''''+CHAR(10) FROM sys.objects WHERE [type] IN ('V');
EXEC (@sql);
Les plans d'exécution montrent que plus de 80% du temps d'exécution est sur une recherche d'index cluster, donc je ne pense pas que je puisse faire beaucoup plus pour optimiser les procédures stockées.
Il y a parfois plus à optimiser que de préférer les recherches aux analyses et ainsi de suite, parfois une analyse d'index est plus efficace que de nombreuses exécutions d'opérations de recherche, et les estimations de coûts sur lesquelles les pourcentages que vous regardez sont calculées sont les suivantes (estimations) à meilleur (un guide utile mais parfois loin d'être précis).
Alors que "jeter plus de mémoire" peut aider certains problèmes de performances de la base de données, au moins temporairement, si vos goulots d'étranglement sont très liés au processeur plutôt qu'à la mémoire et/ou IO lié alors ajouter plus de mémoire aura très peu d'effet.
Si vous ajoutez de la mémoire (même si elle est ajoutée à chaud à une machine virtuelle) et augmentez la mémoire maximale du serveur pour correspondre, le cache de votre plan s'effacera.
Cela recompile efficacement toutes les choses que vous avez mentionnées, car ils n'auront pas de plan stocké dans le cache à réutiliser. SQL Server devra en créer un nouveau.
Cependant, vous n'avez peut-être jamais défini la mémoire maximale du serveur. Si vous n'êtes pas sûr de cela, vous pouvez exécuter DBCC FREEPROCCACHE
pour vider le cache du plan.
Vous faites cela à vos risques et périls en production. Je ne peux pas garantir que le nouveau plan sera meilleur.
La mémoire ne résout pas tous les problèmes de performances dans SQL Server, et une recherche n'est pas nécessairement la ligne d'arrivée du réglage des performances.
Si vous avez besoin d'aide pour une requête spécifique, vous devez poser une question distincte.