Ich habe vor etwa einer Woche eine Frage zu SOF über das Auditing von SQL-Datenänderungen gestellt. Die üblichen Dinge über die Verwendung von Triggern kamen auf, es gab auch die Erwähnung von CDC in SQL Server 2008.
Ich habe es heute ausprobiert und so weit, so gut, dass die eine Sache, die ich nicht sehen kann, darin besteht, zu verfolgen, wer die Änderung tatsächlich vorgenommen hat. Wer hat die Aussage ausgeführt?
Ich bin daran interessiert zu wissen, ob jemand CDC für Auditing verwendet hat und wie Sie verfolgt haben, wer die Änderung vorgenommen hat?
Ich habe die CDC-Tabelle direkt geändert mit: ALTER TABLE cdc.dbo_MyTable_CT ADD Benutzername nvarchar (50) NULL DEFAULT (SUSER_SNAME ())
Übrigens brauchen Sie die Datumsinformationen nicht, da sie bereits in den Start- und End-LSN-Feldern sind.
Mein einziges Problem ist, dass sich meine Benutzer über eine Windows-Gruppe anmelden, die ihnen erlaubt, Rechte zu ändern, aber das Feld Benutzername ist immer mein Benutzername und nicht ihr Benutzername. Ich habe keine Lösung für dieses Problem gefunden.
Change Data Capture verfolgt nicht den Benutzer, Computer, der die Änderung vorgenommen hat, oder den Zeitpunkt der Änderung.
Die beste Lösung zum Verfolgen von Benutzern, die die Änderung mit CDC vorgenommen haben, besteht darin, ein neues Feld zum Speichern von Benutzerdetails zu erstellen, das bei jeder Änderung aktualisiert wird (gefundene Idee hier ).
Ein anderer Artikel derselben Serie führte mich zu einem Drittanbieter-Tool, das eine Out-of-the-Box-Lösung bietet. Ich bin noch dabei, den Prozess zu bewerten, aber bisher sieht es ziemlich gut aus. Sie können den Vergleich der verfolgten Informationen in einer praktischen Tabelle am Ende von sehen Fortsetzung .
Hoffe, das hilft.
CDC ist wirklich nicht für das Auditing geeignet. Wenn Sie nach Auditing-Funktionen suchen, sollten Sie SQL Server-Audit verwenden.
>MrEdmundo, CDC ist meiner Meinung nach nicht bereit für die Primetime. Es scheint derzeit ziemlich schwierig zu sein, ein Datenbankprojekt aus Visual Studio mit aktivierter CDC zu implementieren (DDL-Änderungen sind nicht möglich). Darüber hinaus scheint es, dass CDC eine integrierte Daten Ende-of-Life-Cleanup-Proc hat, so kann dies schlechte Zeiten für Sie sein, wenn Sie wirklich Ihre Audit-Geschichte für eine lange Zeit pflegen möchten.
Korrigieren Sie mich auch, wenn ich missverstanden habe, aber es scheint, dass SQL Audit darauf ausgerichtet ist, eine Fülle von Ereignissen zu überwachen, die in SQL Server auftreten, wie fehlgeschlagene Anmeldungen, DDL-Änderungen usw.
Change Tracking ist nur für DDL und nicht für DML, also hast du kein Glück.
Wenn Sie wirklich beabsichtigen, den "alten" Datensatz zu erfassen, der entweder aktualisiert oder aus einer Tabelle gelöscht wurde, scheint es immer noch die beste Lösung zu sein, einen Audit.TableName und einen update + delete-Trigger für dbo.TableName zu erstellen. Stellen Sie außerdem sicher, dass TableName die Spalten CreatedBy DEFAULT SUSER, CreatedDate DEFAULT getdate (), ModifiedBy, ModifiedDate enthält.
Obwohl nicht ideal, scheint der allgemeine Konsens zu sein, dass CDC nicht erfassen wird, wer die Änderung vorgenommen hat, aber wir haben Spalten CreatedBy / Date und UpdatedBy / Date implementiert, die verwendet werden können, um zu sehen, wer die Änderung ausgelöst hat. Damit das funktioniert, muss natürlich die SP- oder SQL-Anweisung, die die Zeile aktualisiert, die Felder "UpdatedBy / Date" explizit mit "suser_name ()" und "getDate ()" festlegen. Ich stimme zu, dass es schön wäre, out of the box zu haben, und das macht CDC etwas, für das es nicht gedacht war, aber ich versuche auch CDC zu verwenden, um Datenänderungen asynchron zu prüfen, anstatt traditionelle Trigger zu verwenden.
Tags und Links sql sql-server-2008 auditing cdc