Як виявити будь-які зміни в базі даних (DDL та DML)

На SQL-сервері мого клієнта є багато баз даних. Ці бази даних перебувають на стадії розробки, тому розробники можуть проектувати, рефактор, робити зміни даних тощо. Є деякі бази даних, які змінюються рідко. Мій клієнт повинен тримати їх у безпеці (створювати резервні копії) та витрачати певний час на управління довкіллям. (У компанії немає посади адміністратора БД.) Після тривалої дискусії клієнт вирішив використовувати щоденну стратегію повного резервного копіювання, завдяки простоті відновлення.

Отже, ось короткий виклад ситуації:

• Кількість баз даних може змінюватися щодня.
• Бази даних, які були змінені (тобто дані та / або структура були змінені), повинні бути резервні копії.
• Бази даних, які не були змінені, НЕ повинні бути резервними копіями.
• Рішення не повинно впливати на структуру бази даних (це не обмежена вимога)
• Цей "резервний двигун" працює автоматично.

Основна проблема: як виявити, що база даних була змінена. Першу частину проблеми (зміни DDL) можна вирішити за допомогою тригерів DDL . Але зміни даних (зміни DML) є проблемою. Неможливо застосувати тригери DML до всіх таблиць усіх баз даних для відстеження змін (продуктивність, управління розширеними об'єктами ...). Двигун резервного копіювання повинен відстежувати всі зміни, щоб позначити кожну базу даних як готову до резервного копіювання.

• Зміна захоплення даних - це рішення, але воно здається занадто важким (для нього також потрібна версія SQL Server Enterprise Edition).

• Інший спосіб - відстежувати зміни файлів бази даних (розмір або час останньої зміни), але він працює не правильно: База даних може змінити свій розмір, коли вона перевищує весь зарезервований вільний простір, і sp_spaceused не є рішенням.

• Відстеження - це рішення, але воно спричиняє проблеми з продуктивністю та вимагає додаткового управління.

Чи існують рішення для обчислення фактичного розміру використання бази даних без впливу на інші об'єкти управління базами даних (наприклад, статистика ..)? Зрозуміло, що зміна даних таблиці, яка не змінює розмір таблиці, не спричинить (я думаю), але це краще, ніж нічого. Дійсно я шукаю пряме або непряме рішення для SQL Server 2008.

Дякуємо за будь-які коментарі, рішення та думки.

ДОДАТО:

Ось рішення (спасибі Маріан ):

Select
    NextLSN = MAX(fn.[Current LSN])
    ,Databasename = DB_NAME()
 from fn_dblog(NULL,    NULL) fn
     LEFT JOIN sys.allocation_units au
         ON fn.AllocUnitId = au.allocation_unit_id
     LEFT  JOIN sys.partitions p
         ON p.partition_id = au.container_id
     LEFT  JOIN sys.objects so
         ON so.object_id = p.object_id  
    WHERE 
    (
        (Operation IN 
       ('LOP_INSERT_ROWS','LOP_MODIFY_ROW',
            'LOP_DELETE_ROWS','LOP_BEGIN_XACT','LOP_COMMIT_XACT') 
            AND so.is_ms_shipped = 0)
        OR 
        ([Lock Information] like '%ACQUIRE_LOCK_SCH_M OBJECT%')
    )

Ідеєю було б робити знімок кожного дня та контролювати розмір файлу знімка на диску, використовуючи монітор файлів. Знімок збільшує свій розмір лише тоді, коли там додаються дані, тому було б обґрунтованою ідеєю, якщо ви знайдете інструмент для моніторингу реального розміру (розмір звіту).

Зараз .. Я цього не використовував, тому не можу дати тобі технічну інформацію :-).

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

Це непрості речі. Але я сподіваюся, що ви знайдете їх корисними.

PS: знайшов статтю з функцією читання журналу (це, до речі, fndblog :-): Прочитайте журнал транзакцій за Єнсом К. Суссмейєром .

• Для змін DDL ви можете прочитати Сліду за замовчуванням .
• Для модифікацій DML, оскільки CDC є важким, ви можете запустити власний легкий бік сервера, який відстежує лише відповідні події

Для змін DDL ви запускаєте триггери DDL, але зміни DML ви можете спробувати використовувати три різні варіанти

1) Відстеження змін 2) CDC (Зміна захоплення даних) 3) Функція аудиту

Для відстеження змін .. ви можете ознайомитись із посилання нижче http://www.mssqltips.com/sqlservertip/1819/using-change-tracking-in-sql-server-2008/

це відстеження змін буде використовуватися лише в тому випадку, коли таблиця змінилася чи ні ... але дуже важко знайти, які дані змінилися. Якщо ви хочете знайти, які дані змінилися, тоді ви можете перейти до Chnage data Capture.

Для Aduit в sqlserver .. ви можете переглянути посилання нижче http://blogs.msdn.com/b/manisblog/archive/2008/07/21/sql-server-2008-auditing.aspx

Для змін у DML ви можете використовувати будь-яку з наступних вбудованих функцій аудиту SQL Server:

• Відстеження змін SQL Server
• Запис даних про зміну SQL Server
• Аудит SQL Server

Кожен має свої переваги та недоліки, але Аудит - це останнє, представлене корпорацією Майкрософт, тому було б гарною ідеєю побудувати ваші поточні та майбутні рішення, оброблені ним.

Зауважте, що лише функція аудиту надає інформацію про те, хто / коли / як

Ви можете виявити будь-які зміни DDL, використовуючи файл сліду. нижче - сценарій, щоб отримати зміни.

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

Ви можете виявити будь-які зміни в таблиці та збереженій процедурі за допомогою цього сценарію:

SELECT 
    SO.Name
    ,SS.name 
    ,SO.type_desc 
    ,SO.create_date
    ,SO.modify_date 
 FROM sys.objects AS SO
INNER JOIN sys.schemas AS SS 
    ON SS.schema_id = SO.schema_id 
WHERE DATEDIFF(D,modify_date, GETDATE()) < 50
AND TYPE IN ('P','U')