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

dba.stackexchange https://dba.stackexchange.com/questions/985

  •  16-10-2019
  •  | 
  •  

Frage

Auf dem SQL -Server meines Clients gibt es viele Datenbanken. Diese Datenbanken befinden sich in der Entwicklung, sodass Entwickler entwerfen, refaktor, Datenveränderungen usw. entwerfen, refaktor, Datenmodifikationen vornehmen können. Es gibt einige Datenbanken, die sich selten ändern. Mein Kunde muss alle sicher (gesichert) aufbewahren und einige Zeit damit verbringen, die Umgebung zu verwalten. (Es gibt keine DB -Administratorposition im Unternehmen.) Nach langwieriger Diskussion hat der Kunde aufgrund der einfachen Wiederherstellung eine tägliche vollständige Sicherungsstrategie anwenden.

Hier ist also die Zusammenfassung der Situation:

  • Die Anzahl der Datenbanken kann jeden Tag variieren.
  • Datenbanken, die geändert wurden (was bedeutet, dass Daten und/oder Struktur geändert wurden), werden geändert.
  • Datenbanken, die nicht geändert wurden, werden nicht gesichert.
  • Die Lösung wirkt sich nicht auf die Datenbankstruktur aus (es ist keine eingeschränkte Anforderung)
  • Diese "Backup -Engine" funktioniert automatisch.

Das Hauptproblem: So erkennen Sie, dass eine Datenbank geändert wurde. Der erste Teil des Problems (DDL -Änderungen) kann durch Verwendung aufgelöst werden DDL -Auslöser. 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 Sicherung bereit zu machen.

  • Datenerfassung ändern ist eine Lösung, aber es scheint zu schwer (es erfordert auch SQL Server Enterprise Edition).

  • Eine andere Möglichkeit besteht darin, Änderungen der Datenbankdatei (Größe oder letzte Änderungszeit) zu verfolgen, funktioniert jedoch nicht korrekt: Eine Datenbank kann ihre Größe ändern, wenn sie alle reservierten freien Speicherplatz überschreitet und SP_SPACEUTEULE ist keine Lösung.

  • Verfolgung ist eine Lösung, aber sie verursacht Performance-Probleme und erfordert zusätzliches Management.

Gibt es Lösungen zur Berechnung der tatsächlichen Datenbankverwendungsgröße ohne Auswirkungen auf andere Datenbankverwaltungsobjekte (wie Statistiken ..)? Zugegeben, dass eine Änderung der Daten einer Tabelle, die die Größe der Tabelle nicht ändert, nicht auslösen würde (glaube ich), aber sie ist besser als nichts. Wirklich, ich suche eine direkte oder indirekte Lösung für SQL Server 2008.

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

HINZUGEFÜGT:

Hier ist die Lösung (dank 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%')
    )
War es hilfreich?

Lösung

Eine Idee wäre, jeden Tag einen Schnappschuss zu erstellen und die Snapshot -Dateigröße auf der Festplatte mit einem Dateimonitor zu überwachen. Der Snapshot erhöht seine Größe nur dann, wenn Daten hinzugefügt werden. Daher wäre es eine gültige Idee, wenn Sie ein Tool zur Überwachung der realen Größe (gemeldete Größe) finden würden.

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

Eine andere Idee wäre, das Transaktionsprotokoll der einzelnen DB (wenn Sie natürlich den vollständigen Wiederherstellungsmodus für sie verwenden) zu überprüfen, mit einer Funktion, die ich in den Foren (db_fnlog .. oder so), die Operationen aus dem Protokoll liest und prüfen Sie, ob Sie Delets/Einfügungen/Updates haben.

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

PS: Fand den Artikel mit der Log-Lesefunktion (es ist übrigens fndblog :-): Lesen Sie das Transaktionsprotokoll von Jens K. Suessmeyer.

Andere Tipps

  • Für DDL -Änderungen können Sie die lesenStandardverfolgung.
  • Für DML -Modifikationen, da Sie CDC als bitter schwer sind

Für DDL -Änderungen können Sie DDL -Auslöser, DML -Änderungen jedoch versuchen, 3 verschiedene Optionen zu verwenden

1) Änderung der Verfolgung 2) CDC (Änderung der Datenerfassung) 3) Prüfungsfunktion

Für Änderungsverfolgung. Sie können den folgenden Link sehen 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 geändert haben. Wenn Sie herausfinden möchten, welche Daten geändert haben, können Sie die Datenerfassung der Daten entscheiden.

Für ADIT in SQLServer. Sie können den folgenden Link überprüfen http://blogs.msdn.com/b/manisblog/archive/2008/07/21/SQL-SERVER-2008-auditing.aspx

Für DML -Änderungen können Sie die folgenden Funktionen für native SQL Server -Prüfungsfunktionen verwenden:

  • SQL Server -Änderungsverfolgung
  • SQL Server Änderung der Datenerfassung
  • SQL Server Auditing

Jedes hat seine Vor- und Nachteile, aber die Prüfung ist die neueste von Microsoft eingeführt. Daher wäre es eine gute Idee, Ihre aktuellen und zukünftigen Lösungen aufzubauen, die damit eingehackt sind.

Beachten Sie, dass nur die Prüfungsfunktion Informationen darüber enthält, wer / wann / wie

Sie können alle DDL -Änderungen mithilfe von Trace -Datei erkennen. Unten ist das 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

Sie können jede Änderung in der Tabelle und in der gespeicherten Prozedur mit diesem Skript 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')
Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit dba.stackexchange
scroll top