На самом деле, при выполнении одного из критических заданий произошел сбой.
В сообщении об ошибке было обнаружено, что сбой вызван отсутствием хранимой процедуры.
Теперь, как мне узнать, когда на хранимую процедуру повлиял пользователь. Как мне узнать, какой пользователь это сделал и когда он это сделал?
Вы получите административный след:
select * from fn_trace_getinfo(NULL)
where property=2
and traceid = 1
Вы просматриваете административный след для событий класса 47 Объект: удаленный класс события по типам объектов 8727 Хранимая процедура:
select * from fn_trace_gettable('....trc', -1)
where EventClass = 47
and ObjectType=8727
Административная трассировка периодически перерабатывается, и сохраняется около 4-5 трассировок, вы должны использовать имя самого старого файла trc, который все еще присутствует.
Если процедура критична, администратор базы данных должен был убедиться, что только уполномоченный персонал может ее изменить или отбросить. И он должен был иметь место аудит изменений схемы. Это не вина того, кто отказался от процедуры, а полностью ошибка DBA.
По умолчанию узнать эту информацию невозможно, поскольку SQL Server не поддерживает это. Если ваша база данных находится в режиме полного восстановления, вы можете попробовать прочитать журнал транзакций и посмотреть, когда был выполнен оператор DROP PROCEDURE. К сожалению, нет простого способа сделать это.
Вы можете попробовать использовать некоторые сторонние инструменты, такие как Журнал ApexSQL или Квест Жаба но даже с этими инструментами я не уверен, что вы сможете узнать имя пользователя того, кто это сделал.
Другой вариант, который вы можете попробовать, - это проверить функцию fn_dblog и посмотреть, сможете ли вы использовать ее. Проблема в том, что эта функция плохо документирована.
Я думаю, вы задаете неправильный вопрос.
Почему люди, которым вы не доверяете, получают достаточно прав в вашей базе данных, чтобы вообще удалить этот sproc? Это вопрос, который вам нужно задать.
Это похоже на попытку выяснить, кто ограбил ваш дом после того, как вы оставили ключ на крыльце.
Предполагая "среднюю" установку SQL Server по умолчанию, сидя за вашим сервером прямо сейчас, вы не сможете определить эту информацию. По умолчанию SQL не регистрирует и не отслеживает подобные действия.
(Есть несколько способов записать эту информацию (триггеры DDL), но это не поможет вам сейчас - это поможет только в будущих действиях.)
Крис упомянул, что собирался просмотреть журнал транзакций и извлечь, какая информация там присутствует. Это могло бы работать, но SQL 2005 не предоставляет никаких «собственных» функций для просеивания журналов транзакций. Для этого вам понадобится сторонний инструмент. И это применимо только до тех пор, пока эти данные находятся в журнале транзакций; если режим восстановления базы данных установлен на «простой», эти данные будут удалены из журнала - скорее раньше, чем позже. (Если ваша база данных активно используется, возможно, ее уже нет.)
Ремус Русану рассказал, как запросить системную трассировку. Очень здорово, я поддерживаю это! По его словам, у этого файла тоже ограниченный срок хранения - вам, вероятно, следует сделать копии этих файлов. сейчас прежде, чем они будут перезаписаны.
Если описанная выше тактика невозможна, восстановление и просмотр резервных копий может отследить, когда это произошло. Это снова зависит от вашего режима восстановления и имеющихся у вас файлов резервных копий. Если вы можете выполнять восстановление на определенный момент времени для резервных копий журнала транзакций, вы сможете получить довольно точную оценку того, когда он был удален; Если у вас есть только полные или дифференциальные резервные копии, вы получите меньшую точность (например, было ли в резервной копии в 13:00, не было в резервной копии в 14:00, должно быть, было отброшено между 1 и 2).
Что касается того, кто его сбросил (или, точнее, через какой вход в систему SQL он был сброшен), я не верю, что вы можете извлечь эту информацию, если у вас не установлен и запущен какой-то специально настроенный процесс. Отправной точкой было бы определение того, кто (точнее, какие логины) мог выполните падение и двигайтесь оттуда. Настроена ли ваша установка SQL для регистрации успешных входов в систему в журналах событий Windows? Установлен ли домен для отслеживания входа в домен? ... хотя ни то, ни другое не поможет, если задействована проверка подлинности SQL.
Возможно, это невозможно, но вы сможете сделать некоторые разумные предположения. Удачи!
Вы должны иметь возможность вернуться к журналу транзакций и, по крайней мере, узнать, когда эта процедура была удалена из базы данных. Что касается пользователей, вы можете увидеть, кто вошел в систему в то время, и несколько сузить его.
Надеюсь, это кому-то поможет.
Вы можете использовать приведенный ниже сценарий для идентификации подозреваемого пользователя:
SELECT
te.name AS eventtype
,t.loginname
,t.spid
,t.starttime
,t.objectname
,t.databasename
,t.hostname
,t.ntusername
,t.ntdomainname
,t.clientprocessid
,t.applicationname
FROM sys.fn_trace_gettable
(
CONVERT
(VARCHAR(150)
,(
SELECT TOP 1
value
FROM sys.fn_trace_getinfo(NULL)
WHERE property = 2
)),DEFAULT
) T
INNER JOIN sys.trace_events as te
ON t.eventclass = te.trace_event_id
WHERE eventclass=164