So erkennen Sie Änderungen an einer Datenbank (DDL und DML)

Auf dem SQL Server meines Clients befinden sich viele Datenbanken. Diese Datenbanken befinden sich in der Entwicklung, sodass Entwickler entwerfen, umgestalten, Datenänderungen vornehmen usw. können. Es gibt einige Datenbanken, die sich selten ändern. Mein Client muss alle sicher (gesichert) halten und einige Zeit mit der Verwaltung der Umgebung verbringen. (Es gibt keine DB-Administratorposition im Unternehmen.) Nach langen Diskussionen hat sich der Client aufgrund der einfachen Wiederherstellung für eine tägliche vollständige Sicherungsstrategie entschieden.

Hier ist die Zusammenfassung der Situation:

• Die Anzahl der Datenbanken kann täglich variieren.
• Geänderte Datenbanken (dh Daten und/oder Struktur wurden geändert) müssen gesichert werden.
• Datenbanken, die nicht geändert wurden, dürfen NICHT gesichert werden.
• Die Lösung hat keinen Einfluss auf die Datenbankstruktur (dies ist keine eingeschränkte Anforderung).
• Diese "Backup-Engine" soll automatisch funktionieren.

Das Hauptproblem: Wie erkennt man, dass eine Datenbank geändert wurde? Der erste Teil des Problems (DDL-Änderungen) kann mit gelöst werden. -DDL löst aus . Die Datenänderungen (DML-Änderungen) sind jedoch ein Problem. Es ist unmöglich, DML-Trigger auf alle Tabellen aller Datenbanken anzuwenden, um Änderungen zu verfolgen (Leistung, Verwaltung erweiterter Objekte ...). Die Backup-Engine muss alle Änderungen verfolgen, um jede Datenbank als Backup-fähig zu markieren.

• Change Data Capture ist eine Lösung, scheint aber zu schwer zu sein (es erfordert auch SQL Server Enterprise Edition).

• Eine andere Möglichkeit besteht darin, Änderungen an Datenbankdateien (Größe oder letzte Änderungszeit) zu verfolgen, die jedoch nicht ordnungsgemäß funktionieren: Eine Datenbank kann ihre Größe ändern, wenn sie den gesamten reservierten freien Speicherplatz überschreitet und sp_spaceused nicht a ist Lösung.

• Die Ablaufverfolgung ist eine Lösung, verursacht jedoch Leistungsprobleme und erfordert zusätzliche Verwaltung.

Gibt es Lösungen zur Berechnung der tatsächlichen Datenbanknutzungsgröße ohne Auswirkungen auf andere Datenbankverwaltungsobjekte (z. B. Statistiken ..)? Zugegeben, eine Änderung der Daten einer Tabelle, die die Größe der Tabelle nicht ändert, würde nicht auslösen (glaube ich), aber es ist besser als nichts. Ich bin wirklich auf der Suche nach einer direkten oder indirekten Lösung für SQL Server 2008.

Vielen Dank für Kommentare, Lösungen und Gedanken.

HINZUGEFÜGT:

Hier ist die Lösung (danke an Marian ):

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%')
    )