Le moniteur d'activité dans sql2k8 nous permet de voir les requêtes les plus coûteuses. Ok, c'est bien, mais y a-t-il un moyen de consigner ces informations ou d'obtenir ces informations via un analyseur de requêtes? Je ne souhaite pas vraiment que la console de gestion SQL soit ouverte et que je regarde le tableau de bord du moniteur d'activité.
Je veux savoir quelles requêtes sont mal écrites/le schéma est mal conçu, etc.
Merci beaucoup pour toute aide!
Utilisez SQL Server Profiler (dans le menu Outils de SSMS) pour créer une trace qui enregistre ces événements:
RPC:Completed
SP:Completed
SP:StmtCompleted
SQL:BatchCompleted
SQL:StmtCompleted
Vous pouvez commencer avec le modèle de trace standard et l'élaguer. Vous n'avez pas précisé s'il s'agissait d'une base de données spécifique ou de l'ensemble du serveur; si c'était pour des bases de données spécifiques, incluez la colonne DatabaseID et définissez un filtre sur votre base de données (SELECT DB_ID('dbname')
). Assurez-vous que la colonne de données Reads logique est incluse pour chaque événement. Définissez la trace pour vous connecter à un fichier. Si vous laissez cette trace s'exécuter en arrière-plan sans surveillance, il est judicieux de définir une taille de fichier de trace maximale, par exemple 500 Mo ou 1 Go, si vous disposez de suffisamment d'espace (tout dépend de la quantité d'activité disponible sur le serveur, donc vous devrez le sucer et voir).
Commencez brièvement la trace, puis mettez-la en pause. Allez dans Fichier-> Exporter-> Définition de trace de script, choisissez votre version de base de données et enregistrez-la dans un fichier. Vous avez maintenant un script SQL qui crée une trace qui nécessite beaucoup moins de temps système que de passer par l’interface graphique du profileur. Lorsque vous exécutez ce script, l'ID de trace est généré (généralement @ID=2
); notez ceci.
Une fois que vous avez un fichier de trace (.trc) (soit la trace est terminée parce que la taille du fichier est maximale, soit vous avez arrêté la trace en cours à l’aide de
EXEC sp_trace_setstatus @ID, 0
EXEC sp_trace_setstatus @ID, 2
Vous pouvez charger la trace dans le profileur ou utiliser ClearTrace (très pratique) ou la charger dans une table comme ceci:
SELECT * INTO TraceTable
FROM ::fn_trace_gettable('C:\location of your trace output.trc', default)
Ensuite, vous pouvez exécuter une requête pour agréger les données telles que celle-ci:
SELECT COUNT(*) AS TotalExecutions,
EventClass, CAST(TextData as nvarchar(2000))
,SUM(Duration) AS DurationTotal
,SUM(CPU) AS CPUTotal
,SUM(Reads) AS ReadsTotal
,SUM(Writes) AS WritesTotal
FROM TraceTable
GROUP BY EventClass, CAST(TextData as nvarchar(2000))
ORDER BY ReadsTotal DESC
Une fois que vous avez identifié les requêtes coûteuses, vous pouvez générer et examiner les plans d'exécution réels.
Le script suivant vous donne le résultat.
SELECT TOP 10
SUBSTRING(qt.TEXT, (qs.statement_start_offset/2)+1,
((CASE qs.statement_end_offset
WHEN -1 THEN DATALENGTH(qt.TEXT)
ELSE qs.statement_end_offset
END - qs.statement_start_offset)/2)+1),
qs.execution_count,
qs.total_logical_reads,
qs.last_logical_reads,
qs.total_logical_writes, qs.last_logical_writes,
qs.total_worker_time,
qs.last_worker_time,
qs.total_elapsed_time/1000000 total_elapsed_time_in_S,
qs.last_elapsed_time/1000000 last_elapsed_time_in_S,
qs.last_execution_time,qp.query_plan
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
ORDER BY qs.total_logical_reads DESC
Je n'avais jamais entendu parler de cet outil auparavant, mais Microsoft fournit un ensemble de rapports qui font un travail fantastique en vous fournissant exactement cela, y compris les requêtes les plus lentes. Découvrez leurs Rapports de tableau de bord de performance .
Je ne sais pas s'ils sont compatibles avec SQL 2008, mais cela vaut la peine d'être vérifié.
Un nouvel outil, Performance Studio dans SQL Server 2008, construit à partir des vues de gestion dynamiques gérées automatiquement par le serveur, donne une vue d'ensemble des performances du serveur. Cela vaut la peine de vérifier.
SQL Server Profiler répondrait-il à vos besoins? Je n'ai pas encore utilisé 2008, donc je ne sais pas si l'outil y est toujours, mais si c'est le cas, vous pouvez configurer une trace pour consigner les requêtes qui répondent à des critères spécifiques un certain seuil).
Nous avons utilisé cela dans notre projet et cela nous a très bien aidé à résoudre les problèmes d'exécution de requêtes mal exécutées (mais ne le laissez pas à plein temps, utilisez les compteurs de performance Windows généraux pour le suivi de la performance).
(Dell) Quest SQL Optimizer pour SQL Server 9.0 introduit le module Find SQL qui permet aux utilisateurs de localiser le code SQL le plus gourmand en ressources. https://support.quest.com/softwaredownloads.aspx?pr=268445262