ver usar recuperar log historial developer consultas como apexsql actividad sql-server logging ssms

usar - Cómo ver el historial de consultas en SQL Server Management Studio



ver historial de consultas en sql developer (9)

Como han señalado otros, puede usar el Analizador de SQL, pero también puede aprovechar su funcionalidad a través de los procedimientos almacenados del sistema sp_trace_ *. Por ejemplo, este fragmento SQL (al menos en 2000, creo que es lo mismo para SQL 2008 pero deberá verificarlo dos SQL:BatchCompleted eventos RPC:Completed y SQL:BatchCompleted para todas las consultas que tarden más de 10 segundos en ejecutarse y guarde el resultado en un archivo de rastreo que puede abrir en el generador de perfiles de SQL en una fecha 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

Puede encontrar la identificación para cada evento de seguimiento, columnas, etc. de Libros en línea; solo busque los sp_trace_create , sp_trace_setevent y sp_trace_setfiler sprocs. A continuación, puede controlar el seguimiento de la siguiente manera:

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

... donde ''15'' es el ID de seguimiento (según lo informado por sp_trace_create, que el primer script ejecuta, más arriba).

Puede verificar para ver con qué rastros se está ejecutando:

select * from ::fn_trace_getinfo(default)

Lo único que diré con precaución : no sé cuánta carga esto pondrá en su sistema; agregará algo, pero qué tan grande sea ese "algunos" depende probablemente de cuán ocupado está su servidor.

¿El historial de consultas está almacenado en algunos archivos de registro? Si es así, ¿puedes decirme cómo encontrar su ubicación? Si no, ¿puedes darme algún consejo sobre cómo verlo?

El sistema no registra consultas de esa manera. Sin embargo, si sabes que quieres hacerlo con anticipación, puedes usar el Analizador de SQL para registrar lo que está entrando y hacer un seguimiento de las consultas durante el tiempo en que Profiler se está ejecutando.

Si las consultas que le interesan son consultas dinámicas que fallan intermitentemente, puede registrar el SQL y la fecha y el usuario en una tabla en el momento en que se crea la declaración dinámica. Sin embargo, se haría caso por caso, ya que requiere una programación específica y requiere un tiempo de procesamiento adicional, así que hágalo solo para las pocas consultas que le preocupan más. Pero tener un registro de las instrucciones específicas ejecutadas realmente puede ayudar cuando intenta averiguar por qué falla solo una vez al mes. Las consultas dinámicas son difíciles de probar exhaustivamente y, a veces, se obtiene un valor de entrada específico que simplemente no funciona y este registro en el momento en que se crea el SQL suele ser la mejor manera de ver qué wasn específicamente en el sql que se creó.

Uno más tarde pero con suerte útil ya que agrega más detalles ...

No hay forma de ver las consultas ejecutadas en SSMS de manera predeterminada. Sin embargo, hay varias opciones.

Lectura de registro de transacciones: no es una tarea fácil porque está en formato propietario. Sin embargo, si necesita ver consultas que se ejecutaron históricamente (excepto SELECT), esta es la única forma.

Puede utilizar herramientas de terceros para esto, como ApexSQL Log y SQL Log Rescue (gratuito, pero solo SQL 2000). Consulte este hilo para obtener más detalles aquí Analizador / Analizador de registro de transacciones de SQL Server

Perfilador de SQL Server: es más adecuado si solo desea comenzar la auditoría y no le interesa lo que sucedió antes. Asegúrese de usar filtros para seleccionar solo las transacciones que necesita. De lo contrario, terminarás con toneladas de datos muy rápidamente.

Rastreo de SQL Server: es más adecuado si desea capturar todos o la mayoría de los comandos y mantenerlos en el archivo de rastreo que se puede analizar posteriormente.

Disparadores: es el más adecuado si desea capturar DML (excepto seleccionar) y almacenarlos en algún lugar de la base de datos.

Uso la consulta siguiente para rastrear la actividad de la aplicación en un servidor SQL que no tiene habilitado el perfilador de seguimiento. El método usa Query Store (SQL Server 2016+) en lugar del DMV. Esto proporciona una mejor capacidad para examinar datos históricos, así como búsquedas más rápidas. Es muy eficiente capturar consultas de ejecución corta que no pueden ser capturadas por sp_who / sp_whoisactive.

/* 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())

[Dado que esta pregunta probablemente se cerrará como un duplicado.]

Si SQL Server no se ha reiniciado (y el plan no se ha desalojado, etc.), es posible que pueda encontrar la consulta en la memoria caché del 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 perdió el archivo porque Management Studio se colgó, es posible que pueda encontrar archivos de recuperación aquí:

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

De lo contrario, tendrá que utilizar algo más en el futuro para ayudarlo a guardar su historial de consultas, como SSMS Tools Pack como se menciona en la respuesta de Ed Harper, aunque no es gratuito en SQL Server 2012+. O puede configurar algún rastreo ligero filtrado en su nombre de usuario o de inicio de sesión (pero utilice un rastreo del lado del servidor, no un Analizador, para esto).

Como @Nenad-Zivkovic comentó, podría ser útil unirse a sys.dm_exec_query_stats y ordenar 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;

puede usar "Generar secuencia de comandos automáticamente en cada operación de guardado", si está utilizando Management Studio. Esto no es, ciertamente, un registro. Marque si es útil para usted ...;)