включить профилировщик / Traceon после автоматического перезапуска SQL-сервера

Мой клиент сталкивается с некоторыми тупиками при использовании нашего приложения. Я хочу отслеживать все тупики для своих исследований и решать тупики.

В настоящее время я запускаю профилировщик SQL для графа взаимоблокировки событий, чтобы зафиксировать сценарий взаимоблокировки.

реальная проблема заключается в том, что сервер SQL перезапускается каждый день в 2 часа ночи, а профилировщик прекращает захват событий после перезапуска. к тому времени, когда я прихожу в офис при запуске профилировщика, скажем, в 10 часов утра, могут быть тупики, которые я мог бы пропустить между 2 часами утра и 10 часами утра. поэтому я ищу способ, чтобы я мог захватить тупики без запуска вручную.

я подумал, что мог бы использовать TRACEON (1204, -1), чтобы события взаимоблокировки регистрировались в журналах ошибок SQL Server. Но я обнаружил, что захват TRACE тоже отключается после перезагрузки.

Есть ли способ, которым я могу захватить взаимоблокировки либо с помощью профилировщика SQL или с помощью TRACEON без моего запуска вручную захвата?

Нихилу

9.11.2009 09:38:20
2 ОТВЕТА
РЕШЕНИЕ

Немного опоздал на вечеринку, но вы можете создать сохраненный процесс, который установит вашу трассировку, а затем настроить его на запуск при запуске.

USE master;
GO

-- define the proc
CREATE PROCEDURE usp_MakeMyTraceAtStartup AS
    DECLARE @TraceID INT;
    DECLARE @on BIT = 1;
    EXEC sp_trace_create @TraceID output, 6, 'c:\mypath\mytraceout.trc', 5, NULL;

    -- event 25 is a deadlock; see http://msdn.microsoft.com/en-us/library/ms186265.aspx
    EXEC sp_trace_setevent @TraceID, 25, 6, @on; -- NTUserName
    EXEC sp_trace_setevent @TraceID, 25, 7, @on; -- NTDomainName
    EXEC sp_trace_setevent @TraceID, 25, 8, @on; -- HostName
    EXEC sp_trace_setevent @TraceID, 25, 10, @on; -- ApplicationName
    EXEC sp_trace_setevent @TraceID, 25, 11, @on; -- LoginName
    EXEC sp_trace_setevent @TraceID, 25, 12, @on; -- SPID
    EXEC sp_trace_setevent @TraceID, 25, 14, @on; -- StartTime
    EXEC sp_trace_setevent @TraceID, 25, 23, @on; -- Success
    EXEC sp_trace_setevent @TraceID, 25, 26, @on; -- ServerName
    EXEC sp_trace_setevent @TraceID, 25, 31, @on; -- Error
    EXEC sp_trace_setevent @TraceID, 25, 35, @on; -- DatabaseName
    EXEC sp_trace_setevent @TraceID, 25, 60, @on; -- IsSystem
    EXEC sp_trace_setevent @TraceID, 25, 64, @on; -- SessionLoginName
    -- whatever other columns you want to audit

    -- turn it on
    EXEC sp_trace_setstatus @TraceID, 1;
GO

-- set it to run automatically at startup
EXEC sp_procoption 'usp_MakeMyTraceAtStartup', 'startup', 'true';
GO

Трассировка поддерживается в SQL Server 2005 и более поздних версиях.

0
29.05.2014 19:31:41

Вместо того, чтобы запускать трассировку или беспокоиться о том, что пропущено между этими определенными часами после простоя, спросите клиента, какую ошибку возвращает приложение. Если они находятся в определенной области в приложении, вы должны быть в состоянии отследить операторы, которые вызывают тупик. Просто мое мнение =).

0
9.11.2009 22:55:29
хорошо, в этом случае все, что я получаю, является только жертвой sql и это тоже только самый верхний sql выполняется. Если я получу график взаимоблокировки, я могу легко найти точный sql, вызывающий тупик. например, если хранимый процесс вызывает другого, и тот снова вызывает другой сохраненный процесс, где происходит тупик, я получу самый внутренний sql, участвующий в тупике, используя профилировщик, но не получу то же самое без них. следовательно я действительно хочу вывести след.
Nikhil 12.11.2009 06:35:02