Как обнаружить любые изменения в базе данных (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_fnlog .. или что-то в этом роде), которая считывает операции из журнала и посмотреть, есть ли у вас какие-либо удаления / вставки / обновления.

Это не легко сделать, но я надеюсь, что вы найдете их полезными.

PS: нашел статью с функцией чтения журнала (кстати, это fndblog :-): прочитал журнал транзакций от Jens K. Suessmeyer .

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

Для изменений DDL вы используете триггеры DDL, но для изменений DML вы можете попробовать использовать 3 различных варианта

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

Каждый из них имеет свои преимущества и недостатки, но Audit - это последняя версия, представленная Microsoft, поэтому было бы неплохо создать свои текущие и будущие решения в сочетании с ней.

Обратите внимание, что только функция аудита предоставляет информацию о том, кто / когда / как

Вы можете обнаружить любые изменения 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')