it-swarm-eu.dev

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

Eine Idee wäre, jeden Tag einen Snapshot zu erstellen und die Größe der Snapshot-Datei auf der Festplatte mithilfe eines Dateimonitors zu überwachen. Der Snapshot vergrößert sich nur, wenn dort Daten hinzugefügt werden. Daher ist es eine gute Idee, wenn Sie ein Tool zur Überwachung der tatsächlichen Größe (gemeldete Größe) finden.

Nun .. Ich habe das nicht benutzt, kann dir also keine technischen Einblicke geben :-).

Eine andere Idee wäre, das Transaktionsprotokoll jeder Datenbank (wenn Sie natürlich den vollständigen Wiederherstellungsmodus verwenden) mit einer Funktion zu überprüfen, die ich in den Foren gesehen habe (db_fnlog .. oder so), die Operationen aus dem Protokoll liest und prüfen Sie, ob Sie Löschungen/Einfügungen/Aktualisierungen haben.

Das sind keine einfachen Dinge, aber ich hoffe, Sie werden sie nützlich finden.

PS: Ich habe den Artikel mit der Protokolllesefunktion gefunden (es ist übrigens fndblog :-): Lesen Sie das Transaktionsprotokoll von Jens K. Suessmeyer .

7
Marian
  • Für DDL-Änderungen können Sie Standard-Trace lesen.
  • Bei DML-Änderungen, da Sie feststellen, dass CDC etwas schwer ist, können Sie Ihren eigenen leichten serverseitigen Trace ausführen, der nur die relevanten Ereignisse verfolgt
1
Nomad

Für DML-Änderungen können Sie eine der folgenden nativen SQL Server-Überwachungsfunktionen verwenden:

  • SQL Server-Änderungsverfolgung
  • SQL Server Change Data Capture
  • SQL Server-Überwachung

Jedes hat seine Vor- und Nachteile, aber das Auditing ist das neueste, das von Microsoft eingeführt wurde. Daher ist es eine gute Idee, Ihre aktuellen und zukünftigen Lösungen damit zu erstellen.

Beachten Sie, dass nur die Überwachungsfunktion Informationen zu Wer/Wann/Wie enthält

1
Ivan Stankovic

Für DDL-Änderungen, die Sie DDL-Trigger, aber DML-Änderungen können Sie versuchen, 3 verschiedene Optionen zu verwenden

1) Änderungsverfolgung 2) CDC (Datenerfassung ändern) 3) Überwachungsfunktion

Informationen zur Änderungsverfolgung finden Sie unter folgendem Link http://www.mssqltips.com/sqlservertip/1819/using-change-tracking-in-sql-server-2008/

diese Änderungsverfolgung wird nur verwendet, wenn sich die Tabelle geändert hat oder nicht ... aber es ist sehr schwierig zu finden, welche Daten sich geändert haben. Wenn Sie herausfinden möchten, welche Daten sich geändert haben, können Sie Chnage data Capture verwenden.

Für Aduit in sqlserver können Sie den folgenden Link überprüfen http://blogs.msdn.com/b/manisblog/archive/2008/07/21/sql-server-2008-auditing.aspx

1
Anil Inampudi

Sie können alle DDL-Änderungen mithilfe der Trace-Datei erkennen. Unten finden Sie ein Skript, um Änderungen zu erhalten.

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

Mit diesem Skript können Sie Änderungen an Tabellen und gespeicherten Prozeduren erkennen:

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')
0
Anvesh