Suchen oder Löschen von Datensätzen

In den letzten Monaten gab es drei Vorfälle, in denen Datensätze in einer Tabelle gelöscht oder Werte in einer gesamten Tabelle auf Null aktualisiert wurden. Wir haben ein Team von vier Personen, die über die Erlaubnis verfügen und für die Aktualisierung der Datenbank verantwortlich sind und dies hätten tun können. Enttäuschenderweise hat niemand zugegeben, die Änderungen vorgenommen zu haben.

In Zukunft möchte ich in der Lage sein, diese Transaktionen aufzuzeichnen. Ich habe mich gefragt, was andere Leute verwenden, um diese Änderungen zu verfolgen. Verwenden sie Software, die Änderungen verfolgt, oder erstellen Sie gespeicherte Prozeduren oder Trace-Dateien? Wenn jemand dies in seiner Einrichtung eingerichtet hat, würde ich gerne wissen, was er verwendet. Die Tracedateien enthalten die Informationen, nach denen ich suche, wie z. B. den Namen des Anmeldenamens und die SQL-Anweisung, sodass ich die Informationen erhalten kann, wenn ich sie im Voraus eingerichtet habe.

Ich habe Kopien der Datenbank und der Transaktionsprotokolle, als diese Änderungen stattfanden. Kann ich mit diesen alten Dateien etwas tun, um den Täter aufzuspüren? Vielen Dank im Voraus an alle, die antworten. Wir verwenden SQL Server 2005.

fn_dblog ist der Weg, rückwärts zu schauen, wie die anderen Kommentatoren gesagt haben.

Nur den Benutzern zu erlauben, die Daten durch gespeicherte Prozeduren zu ändern, ist eine gute Möglichkeit, dies zu verhindern, da Sie Logik hinzufügen können, um zu verhindern, dass Benutzer Datensätze, die sie nicht sollten, massenweise ändern oder sicherstellen müssen, dass sie korrekte Werte bereitstellen müssen für Updates. Dies kann bedeuten, dass Sie Anwendungsänderungen vornehmen müssen, je nachdem, wie sie aktuell auf die Daten zugreifen. Was für Sie möglich oder nicht möglich ist.

Wenn Sie dies nicht tun können, können Sie mit SQL 2005 schnell und einfach einen Trigger verwenden, um eine DML-Prüfung auf Tabellenebene durchzuführen. (Ab SQL Server 2008 sind Überwachungstools integriert.)

Eine einfache Lösung für Ihr Problem könnte sein:

drop table audit_test
go
create table audit
(
uname varchar(50),
[date] datetime,
what nvarchar(4000),
host varchar(50),
)
go 

create trigger ddlcheck on tbl_example 
for update, delete
as
declare @tbltmp table(eventtype nvarchar(30),para smallint, strsql nvarchar(4000))
insert into @tbltmp exec ('dbcc inputbuffer('+@@spid+')')
insert into audit_test select SUSER_NAME(), GETDATE(),  strsql ,  HOST_NAME() from @tbltmp

Dies wird jedes Mal ausgelöst, wenn eine Abfrage versucht, die Tabelle zu aktualisieren oder aus der Tabelle zu löschen. Es verwendet DBCC inputbuffer( http://msdn.microsoft.com/en-us/library/ms187730(v=sql.90).aspx ), um den ausgegebenen Befehl abzurufen . Auf diese Weise erhalten Sie eine Tabelle mit allen Aktualisierungs- und Löschanweisungen, die für eine bestimmte Tabelle ausgegeben wurden. Außerdem wird aufgezeichnet, wer eine Erklärung abgegeben hat und wo und wann sie war.

Dies können nun viele Protokolldaten in einer ausgelasteten Tabelle sein, sodass dies darauf beschränkt sein kann, nur "schlechte" Abfragen abzufangen (z. B. solche, die mehr als 1000 Zeilen aktualisieren / löschen), indem Sie den Auslöser auf Folgendes ändern:

create trigger ddlcheck on tbl_example 
for update, delete
as
declare @cnt integer
select @cnt=count(1) from deleted
if @cnt>1000
begin
  declare @tbltmp table(eventtype nvarchar(30),para smallint, strsql nvarchar(4000))
  insert into @tbltmp exec ('dbcc inputbuffer('+@@spid+')')
  insert into audit_test select SUSER_NAME(), GETDATE(),  strsql ,  HOST_NAME() from @tbltmp
end

Dadurch werden weniger Daten protokolliert, aber der Auslöser muss immer noch für jede Operation "ausgewertet" werden. Dies kann Auswirkungen auf die Leistung haben, die gemessen und getestet werden müssen. Dadurch werden auch die Aktionen übersehen, wenn der Benutzer viele einzelne Anweisungen übermittelt, z.

wird nicht fangen:

delete from tbl_example where id=1
delete from tbl_example where id=2
.....
delete from tbl_exampe where id=1000

werde fangen

delete from tbl_example where id>0 and id<1001

Ich hoffe, dies ist eine Hilfe für die Zukunft.

Wir verwenden ApexSQL Log zur Prüfung unserer Produktionsdatenbanken. Es kann Ihnen zeigen, wer und wann die Datensätze gelöscht oder aktualisiert hat. Außerdem werden Einfügungen und Anweisungen zum Erstellen / Ändern / Löschen von Datenobjekten verfolgt.

Es ist gut, dass Sie Kopien der Datenbank und der Transaktionsprotokolle haben, als diese Änderungen vorgenommen wurden, da ApexSQL Log diese Transaktionen aus den Transaktionsprotokollen lesen kann. Wenn Sie es in Zukunft zum Verfolgen von Änderungen verwenden möchten, müssen sich Ihre Datenbanken im vollständigen Wiederherstellungsmodell befinden, da Sie nur dann sicher sein können, dass das Online-Transaktionsprotokoll oder eine Transaktionsprotokollsicherung alle Transaktionen enthält, die Sie lesen möchten. Wir komprimieren unsere Transaktionsprotokollsicherungen, um Platz zu sparen

Wir haben einen nächtlichen Job geplant, um die Transaktionsprotokollsicherungen der letzten 24 Stunden zu lesen und die Transaktionen in eine HTML-Datei zu exportieren. Wenn wir Informationen benötigen, überprüfe ich die Datei und mache mir keine Sorgen, wenn die Transaktionsprotokollsicherungen gelöscht werden (wir löschen sie nach 30 Tagen).