Como ver o histórico de pesquisas no SQL Server Management Studio

[Uma vez que esta questão será provavelmente fechada como uma duplicata.]

Se o servidor SQL não tiver sido reiniciado (e o plano não tiver sido despejado, etc.), você pode ser capaz de encontrar a consulta no cache do plano.

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%';

Se você perdeu o arquivo porque o Estúdio de gestão estoirou, você pode ser capaz de encontrar arquivos de recuperação aqui:

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

Caso contrário, terá de usar outra coisa para o ajudar a salvar o seu histórico de consultas, como o pacote de ferramentas SSMS, tal como mencionado em a resposta de Ed Harper - embora não seja gratuita no SQL Server 2012+. Ou você pode configurar algum rastreamento leve filtrado em seu nome de login ou host (mas por favor use um trace do lado do servidor, não um Profiler, para isso).

Como @Nenad-Zivkovic comentou, pode ser útil juntar-se a sys.dm_exec_query_stats e pedir por last_execution_time:

SELECT t.[text], s.last_execution_time
FROM sys.dm_exec_cached_plans AS p
INNER JOIN sys.dm_exec_query_stats AS s
   ON p.plan_handle = s.plan_handle
CROSS APPLY sys.dm_exec_sql_text(p.plan_handle) AS t
WHERE t.[text] LIKE N'%something unique about your query%'
ORDER BY s.last_execution_time DESC;

Não existe forma de ver as consultas executadas no SSMS por omissão. No entanto, existem várias opções.

Ler o diário de operações – isto não é uma coisa fácil de fazer porque está em formato proprietário. No entanto, se você precisar ver consultas que foram executadas historicamente (exceto selecionar) esta é a única maneira.

Pode usar ferramentas de terceiros para isto, tais como ApexSQL Log e SQL Log Rescue (livre, mas SQL 2000 apenas). Confira este tópico para mais detalhes aqui SQL Server Transaction Log Explorer / Analyzer

O perfil do servidor SQL é o mais adequado para começar a auditoria e não está interessado no que aconteceu anteriormente. Certifique-se que usa filtros para seleccionar apenas as transacções de que necessita. Caso contrário, você vai acabar com toneladas de dados muito rapidamente.

SQL Server trace-mais adequado se quiser capturar todos ou a maioria dos comandos e mantê-los no ficheiro de trace que pode ser analisado mais tarde.

Gatilhos-mais adequados se quiser capturar DML (excepto seleccionar) e guardá-los algures na base de dados

SSMS tools pack adiciona funcionalidade ao histórico de execução, entre outras coisas.

Como outros observaram, você pode usar o perfil SQL, mas também pode alavancar a sua funcionalidade através de procedimentos armazenados no sistema sp_trace_*. Por exemplo, este fragmento de SQL irá (em 2000, pelo menos, eu acho que é o mesmo para o SQL 2008, mas você vai ter que verificar) catch RPC:Completed e SQL:BatchCompleted eventos para todas as consultas que levam mais de 10 segundos para executar e salvar a saída em um tracefile que você pode abrir no SQL profiler em uma data posterior:

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

Você pode encontrar o ID para cada rastreamento de eventos, colunas, etc a partir de Livros On-line; é só procurar o sp_trace_create, sp_trace_setevent e sp_trace_setfiler sprocs. Você pode então controlar o traço da seguinte forma:

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

...em que " 15 " é o ID de traço (conforme reportado por sp_ trace_create, que o primeiro script reproduz, acima).

Você pode verificar para ver com que vestígios estão a correr:

select * from ::fn_trace_getinfo(default)

a única coisa que vou dizer com cautela -- não sei quanto carregar isto irá colocar no seu sistema; irá adicionar alguns, mas quão grande esse "alguns" é provavelmente depende de quão ocupado o seu servidor é.

Pode monitorizar consultas SQL por SQL Profiler Se precisar dele

Uso a pesquisa abaixo para localizar a actividade da aplicação num servidor SQL que não tem o Trace profiler activo. O método usa Query Store (SQL Server 2016+) em vez do DMV. isso dá uma melhor capacidade de olhar para os dados históricos, bem como pesquisas mais rápidas. É muito eficiente capturar consultas de curta duração que não podem ser capturadas por sp_who/sp_whoesactive.

/* Adjust script to your needs.
    Run full script (F5) -> Interact with UI -> Run full script again (F5)
    Output will contain the queries completed in that timeframe.
*/

/* Requires Query Store to be enabled:
    ALTER DATABASE <db> SET QUERY_STORE = ON
    ALTER DATABASE <db> SET QUERY_STORE (OPERATION_MODE = READ_WRITE, MAX_STORAGE_SIZE_MB = 100000)
*/

USE <db> /* Select your DB */

IF OBJECT_ID('tempdb..#lastendtime') IS NULL
    SELECT GETUTCDATE() AS dt INTO #lastendtime
ELSE IF NOT EXISTS (SELECT * FROM #lastendtime)
    INSERT INTO #lastendtime VALUES (GETUTCDATE()) 

;WITH T AS (
SELECT 
    DB_NAME() AS DBName
    , s.name + '.' + o.name AS ObjectName
    , qt.query_sql_text
    , rs.runtime_stats_id
    , p.query_id
    , p.plan_id
    , CAST(p.last_execution_time AS DATETIME) AS last_execution_time
    , CASE WHEN p.last_execution_time > #lastendtime.dt THEN 'X' ELSE '' END AS New
    , CAST(rs.last_duration / 1.0e6 AS DECIMAL(9,3)) last_duration_s
    , rs.count_executions
    , rs.last_rowcount
    , rs.last_logical_io_reads
    , rs.last_physical_io_reads
    , q.query_parameterization_type_desc
FROM (
    SELECT *, ROW_NUMBER() OVER (PARTITION BY plan_id, runtime_stats_id ORDER BY runtime_stats_id DESC) AS recent_stats_in_current_priod
    FROM sys.query_store_runtime_stats 
    ) AS rs
INNER JOIN sys.query_store_runtime_stats_interval AS rsi ON rsi.runtime_stats_interval_id = rs.runtime_stats_interval_id
INNER JOIN sys.query_store_plan AS p ON p.plan_id = rs.plan_id
INNER JOIN sys.query_store_query AS q ON q.query_id = p.query_id
INNER JOIN sys.query_store_query_text AS qt ON qt.query_text_id = q.query_text_id
LEFT OUTER JOIN sys.objects AS o ON o.object_id = q.object_id
LEFT OUTER JOIN sys.schemas AS s ON s.schema_id = o.schema_id
CROSS APPLY #lastendtime
WHERE rsi.start_time <= GETUTCDATE() AND GETUTCDATE() < rsi.end_time
    AND recent_stats_in_current_priod = 1
    /* Adjust your filters: */
    -- AND (s.name IN ('<myschema>') OR s.name IS NULL)
UNION
SELECT NULL,NULL,NULL,NULL,NULL,NULL,dt,NULL,NULL,NULL,NULL,NULL,NULL, NULL
FROM #lastendtime
)
SELECT * FROM T
WHERE T.query_sql_text IS NULL OR T.query_sql_text NOT LIKE '%#lastendtime%' -- do not show myself
ORDER BY last_execution_time DESC

TRUNCATE TABLE #lastendtime
INSERT INTO #lastendtime VALUES (GETUTCDATE()) 

Pode usar "gerar automaticamente o programa em cada gravação", se estiver a usar o estúdio de gestão. Isto não é certamente madeira. Verifique se é útil para si.. ;)

Se as consultas em que você está interessado São consultas dinâmicas que falham intermitentemente, você pode registrar o SQL e o datetime e usuário em uma tabela no momento em que a declaração dinâmica é criada. Isso seria feito caso a caso, embora como requer programação específica para acontecer e leva um pouco de tempo extra de processamento, então fazê-lo apenas para as poucas consultas que você está mais preocupado. Mas ter um registro das declarações específicas executadas pode realmente ajudar quando você está tentando descobre porque falha uma vez por mês. Pesquisas dinâmicas são difíceis de testar completamente e às vezes você tem um valor de entrada específico que simplesmente não vai funcionar e fazer este registro no momento em que o SQL é criado é muitas vezes a melhor maneira de ver o que especificamente estava no sql que foi construído.