Визначення способу зміни схеми?

Щось погане трапилося вчора.

Вид, який був створений колись тому, був модифікований кимось, хто врешті-решт порушив звіти. На жаль, хтось (свідомо чи несвідомо) здійснив цю модифікацію в базі даних ВИРОБНИЦТВО.

Моє запитання: Чи існує спосіб (скрипт / програмне забезпечення / безкоштовна програма тощо), за допомогою якого ми можемо дізнатися, хто (ім’я користувача) здійснив цю модифікацію, щоб я міг відкликати доступ до виробничої бази для цього користувача.

Якщо моє запитання незрозуміле, будь ласка, прокоментуйте.

Це заноситься до сліду за замовчуванням, тому доки він включений і тим часом не перевернувся, він повинен відображатися у звіті "Історія змін схеми".

Для доступу до цього в студії управління правою кнопкою миші клацніть базу даних, а потім виберіть у контекстному меню пункт 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 (поточний ідентифікатор об'єкта подання у відновленому db). Ідентифікатор транзакції повертається назад та отримує інформацію про початок транзакції:

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. Схоже, що журнали SQL Server змінюються за замовчуванням змін ( слід за замовчуванням ), і ви повинні мати можливість переглядати ці дані через цей звіт. Єдине прикро, що ці файли слідів автоматично видаляються / згортаються з плином часу, тому дані можуть вже бути відсутніми. Удачі!