Comment voir l'historique des requêtes dans SQL Server Management Studio

Question

L'historique des requêtes est-il stocké dans certains fichiers journaux ? Si oui, pouvez-vous me dire comment trouver leur emplacement ? Si ce n'est pas le cas, pouvez-vous me donner des conseils sur la manière de le consulter ?

Answer 1

[Depuis cette question sera probablement fermé en tant que doublon.]

Si le serveur SQL n'a pas été redémarré (et que le plan n'a pas été évincé, etc.), vous pourrez peut-être trouver la requête dans le cache du plan.

SELECT t.[text]
FROM sys.dm_exec_cached_plans AS p
CROSS APPLY sys.dm_exec_sql_text(p.plan_handle) AS t
WHERE t.[text] LIKE N'%something unique about your query%';

Si vous avez perdu le fichier parce que Management Studio s'est planté, vous pouvez peut-être trouver des fichiers de récupération ici :

C:\Users\<you>\Documents\SQL Server Management Studio\Backup Files\

Sinon, vous devrez utiliser un autre outil pour sauvegarder l'historique de vos requêtes, comme SSMS Tools Pack, comme indiqué dans le document suivant Réponse d'Ed Harper - bien qu'il ne soit pas gratuit dans SQL Server 2012+. Vous pouvez aussi mettre en place un traçage léger filtré sur votre login ou votre nom d'hôte (mais utilisez un traçage côté serveur, pas Profiler, pour cela).

Answer 2

Tardive mais utile, je l'espère, car elle ajoute des détails supplémentaires

Il n'y a aucun moyen de voir les requêtes exécutées dans SSMS par défaut. Il existe cependant plusieurs options.

Lecture du journal des transactions - ce n'est pas une chose facile à faire car il s'agit d'un format propriétaire. Cependant, si vous avez besoin de voir les requêtes qui ont été exécutées historiquement (sauf SELECT), c'est le seul moyen.

Vous pouvez utiliser des outils tiers pour cela, tels que Journal d'ApexSQL et Sauvetage des journaux SQL (gratuit mais SQL 2000 seulement). Consultez ce fil de discussion pour plus de détails ici Explorateur/analyseur du journal des transactions du serveur SQL

Profileur SQL Server - le mieux adapté si vous voulez juste commencer l'audit et que vous n'êtes pas intéressé par ce qui s'est passé auparavant. Veillez à utiliser des filtres pour ne sélectionner que les transactions dont vous avez besoin. Sinon, vous vous retrouverez très vite avec une tonne de données.

Trace SQL Server - le mieux adapté si vous voulez capturer toutes ou la plupart des commandes et les conserver dans un fichier de trace qui peut être analysé ultérieurement.

Déclencheurs - les mieux adaptés si vous voulez capturer le DML (sauf select) et le stocker quelque part dans la base de données.

Answer 3

Le (gratuit) Pack d'outils SSMS ajoute une fonctionnalité permettant d'enregistrer l'historique des exécutions, entre autres choses.

Answer 4

Comme d'autres l'ont fait remarquer, vous pouvez utiliser SQL Profiler, mais vous pouvez également tirer parti de ses fonctionnalités grâce aux procédures stockées du système sp_trace_*. Par exemple, ce snippet SQL (sur 2000 au moins ; je pense que c'est la même chose pour SQL 2008 mais vous devrez vérifier) attrape RPC:Completed et SQL:BatchCompleted pour toutes les requêtes qui prennent plus de 10 secondes à s'exécuter, et enregistrez la sortie dans un fichier de trace que vous pouvez ouvrir dans SQL profiler à une date ultérieure :

DECLARE @TraceID INT
DECLARE @ON BIT
DECLARE @RetVal INT
SET @ON = 1

exec @RetVal = sp_trace_create @TraceID OUTPUT, 2, N'Y:\TraceFile.trc'
print 'This trace is Trace ID = ' + CAST(@TraceID AS NVARCHAR)
print 'Return value = ' + CAST(@RetVal AS NVARCHAR)
-- 10 = RPC:Completed
exec sp_trace_setevent @TraceID, 10, 1, @ON     -- Textdata
exec sp_trace_setevent @TraceID, 10, 3, @ON     -- DatabaseID
exec sp_trace_setevent @TraceID, 10, 12, @ON        -- SPID
exec sp_trace_setevent @TraceID, 10, 13, @ON        -- Duration
exec sp_trace_setevent @TraceID, 10, 14, @ON        -- StartTime
exec sp_trace_setevent @TraceID, 10, 15, @ON        -- EndTime

-- 12 = SQL:BatchCompleted
exec sp_trace_setevent @TraceID, 12, 1, @ON     -- Textdata
exec sp_trace_setevent @TraceID, 12, 3, @ON     -- DatabaseID
exec sp_trace_setevent @TraceID, 12, 12, @ON        -- SPID
exec sp_trace_setevent @TraceID, 12, 13, @ON        -- Duration
exec sp_trace_setevent @TraceID, 12, 14, @ON        -- StartTime
exec sp_trace_setevent @TraceID, 12, 15, @ON        -- EndTime

-- Filter for duration [column 13] greater than [operation 2] 10 seconds (= 10,000ms)
declare @duration bigint
set @duration = 10000
exec sp_trace_setfilter @TraceID, 13, 0, 2, @duration

Vous pouvez trouver l'ID de chaque trace-événement, colonnes, etc. sur Books Online ; il suffit de rechercher l'option sp_trace_create , sp_trace_setevent et sp_trace_setfiler sprocs. Vous pouvez alors contrôler la trace comme suit :

exec sp_trace_setstatus 15, 0       -- Stop the trace
exec sp_trace_setstatus 15, 1       -- Start the trace
exec sp_trace_setstatus 15, 2       -- Close the trace file and delete the trace settings

...où '15' est l'ID de la trace (tel que rapporté par sp_trace_create, que le premier script lance, ci-dessus).

Vous pouvez vérifier avec quoi les traces fonctionnent :

select * from ::fn_trace_getinfo(default)

La seule chose que je dirai par prudence -- Je ne sais pas quelle sera la charge de votre système ; cela en ajoutera un peu, mais l'importance de ce "peu" dépend probablement de la charge de votre serveur.

Answer 5

Le système n'enregistre pas les requêtes de cette manière. Si vous savez que vous voulez le faire à l'avance, vous pouvez utiliser SQL Profiler pour enregistrer ce qui arrive et suivre les requêtes pendant que Profiler est en cours d'exécution.