Определить, как произошло изменение схемы?

Что-то плохое случилось вчера.

Представление, которое было создано некоторое время назад, было изменено кем-то, что в итоге сломало отчеты. К несчастью. кто-то (сознательно или неосознанно) сделал эту модификацию в базе данных PRODUCTION.

Мой вопрос: есть ли способ (скрипт / программное обеспечение / бесплатное программное обеспечение и т. Д.), С помощью которого мы можем узнать, кто (имя пользователя) сделал эту модификацию, чтобы я мог отозвать доступ к производственной базе данных для этого пользователя.

Если мой вопрос неясен, пожалуйста, прокомментируйте.

Это записывается в трассировку по умолчанию, поэтому, пока она включена и не переворачивается, она должна появиться в отчете «История изменений схемы».

Для доступа к этому в Management Studio щелкните правой кнопкой мыши базу данных, затем из контекстного меню выберите Reports -> Standard Reports -> Schema Changes History

Для получения той же информации через TSQL вы можете использовать

SELECT StartTime
       ,LoginName
       --,f.*
FROM   sys.traces t
       CROSS APPLY fn_trace_gettable(REVERSE(SUBSTRING(REVERSE(t.path),
                                                       CHARINDEX('\', REVERSE(t.path)), 
                                                       260)
                                             ) + N'log.trc', DEFAULT) f
WHERE  t.is_default = 1
       AND ObjectName = 'FOO'
       AND EventClass IN (46, /*Object:Created*/
                          47, /*Object:Dropped*/
                          164 /*Object:Altered*/ )

Мартин уже указал на лучшую дорогу - трассу административного аудита, которая обычно включена (если она явно не отключена). Если вы не можете найти информацию в трассировке администратора (была отключена или была переработана), вы можете получить информацию из резервных копий журнала. Поскольку это производственная БД, я предполагаю, что у вас есть регулярный цикл резервного копирования с периодическим полным резервным копированием и резервным копированием журнала. Вам потребуется восстановить базу данных на отдельном сервере примерно до времени происшествия, чтобы DDL находился в текущем восстановленном журнале. Тогда это простой вопрос использования fn_dblog()и проверки журнала.

Один из способов - выполнить операции начала транзакции:

select [Begin Time], [Transaction Name], [Transaction SID], * 
from fn_dblog(null, null)
where Operation = 'LOP_BEGIN_XACT';

Если он ALTER VIEWбыл выпущен в отдельной транзакции (то есть не окружен BEGIN TRANSACTION/ COMMIT), он запустит транзакцию с именем CreatProc transaction. Ищите его, и [Transaction SID]это SID логина, который вы хотите.

Другой возможностью является поиск транзакции, которая получила SCH_M в желаемом представлении:

select [Lock Information], * 
from fn_dblog(null, null)
where [Lock Information] like '%' + cast(object_id('...') as varchar(10))+'%'
and [Lock Information] like '%LOCK_SCH_M%'
go

Обратите внимание, что если представление было изменено с помощью DROP, а затем CREATE, идентификатор объекта, вероятно, был изменен, но, по крайней мере, вы получите транзакцию, которая в последний раз выполняла CREATE (текущий идентификатор объекта представления в восстановленной базе данных). С идентификатором транзакции вы возвращаетесь и получаете информацию о начале транзакции:

select [Begin Time], [Transaction Name], [Transaction SID], *
from fn_dblog(null, null)
where [Transaction ID] = '...'
and Operation = 'LOP_BEGIN_XACT';

[SID транзакции], опять же, ваш парень. Используйте SUSER_SNAMEдля получения имени входа из SID входа в систему. Если SID равен 0x01, это означает, что логин был sa, что означает, что любой человек, который знает saпароль, мог это сделать.

Нет, если вы не зарегистрировали его с помощью триггера DDL или чего-то подобного

Вы хотите посмотреть, кто имеет права ALTER в этой базе данных или членство в роли sysadmin / db_owner / ddl_admin. Это было бы лучше как общий обзор, а не охота на ведьм. Возможно, есть и другие люди, которые имеют право вносить несанкционированные и несанкционированные изменения.

Если вы этого еще не сделали, возможно, вы захотите ознакомиться с отчетом «История изменений схемы», доступным в SQL Server Management Studio. Похоже, что SQL Server регистрирует изменения по умолчанию ( трассировка по умолчанию ), и вы сможете просматривать эти данные в этом отчете. Единственное, к сожалению, то, что эти файлы трассировки автоматически удаляются / переносятся с течением времени, поэтому данные уже могут быть утеряны. Удачи!