Bestimmen, wie eine Schemaänderung aufgetreten ist?

Etwas Schlimmes ist gestern passiert.

Eine Ansicht, die vor einiger Zeit erstellt wurde, wurde von jemandem geändert, der schließlich die Berichte gebrochen hat. Unglücklicherweise. Jemand (wissentlich oder unwissentlich) hat diese Änderung in der PRODUCTION-Datenbank vorgenommen.

Meine Frage: Gibt es eine Möglichkeit (Skript / Software / Freeware usw.), durch die wir erfahren können, wer (Benutzername) diese Änderung vorgenommen hat, so dass ich dem Benutzer den Zugriff auf die Produktionsdatenbank entziehen kann?

Wenn meine Frage unklar ist, kommentieren Sie bitte.

Dies wird in der Standardablaufverfolgung protokolliert. Solange diese aktiviert ist und in der Zwischenzeit kein Rollover durchgeführt wurde, sollte sie im Bericht "Schema-Änderungsverlauf" angezeigt werden.

Um in Management Studio darauf zuzugreifen, klicken Sie mit der rechten Maustaste auf die Datenbank und wählen Sie dann im Kontextmenü die Option Reports -> Standard Reports -> Schema Changes History

Um die gleichen Informationen über TSQL abzurufen, können Sie verwenden

SELECT StartTime
       ,LoginName
       --,f.*
FROM   sys.traces t
       CROSS APPLY fn_trace_gettable(REVERSE(SUBSTRING(REVERSE(t.path),
                                                       CHARINDEX('\', REVERSE(t.path)), 
                                                       260)
                                             ) + N'log.trc', DEFAULT) f
WHERE  t.is_default = 1
       AND ObjectName = 'FOO'
       AND EventClass IN (46, /*Object:Created*/
                          47, /*Object:Dropped*/
                          164 /*Object:Altered*/ )

Martin wies bereits auf die beste Möglichkeit hin, nämlich die Ablaufverfolgung für Verwaltungsprüfungen, die normalerweise aktiviert ist (sofern sie nicht ausdrücklich deaktiviert wurde). Wenn Sie die Informationen im Administrator-Trace nicht finden können (deaktiviert oder wiederverwendet), können Sie sie aus den Protokollsicherungen abrufen. Da es sich um eine Produktionsdatenbank handelt, wird davon ausgegangen, dass Sie einen regelmäßigen Sicherungszyklus mit regelmäßigen vollständigen Sicherungen und Protokollsicherungen haben. Sie müssen die Datenbank auf einem separaten Server ungefähr zum Zeitpunkt des Vorfalls wiederherstellen, damit sich die DDL im aktuellen wiederhergestellten Protokoll befindet. Dann ist es eine einfache Sache, fn_dblog()das Protokoll zu verwenden und zu inspizieren.

Eine Möglichkeit besteht darin, mit der Transaktion den Betrieb aufzunehmen:

select [Begin Time], [Transaction Name], [Transaction SID], * 
from fn_dblog(null, null)
where Operation = 'LOP_BEGIN_XACT';

Wenn das ALTER VIEWin einer eigenständigen Transaktion ausgegeben wurde (dh nicht von BEGIN TRANSACTION/ umgeben ist COMMIT), startet es eine Transaktion mit dem Namen CreatProc transaction. Suchen Sie danach, und das [Transaction SID]ist die gewünschte Anmelde-SID.

Eine andere Möglichkeit besteht darin, die Transaktion, die einen SCH_M erworben hat, in der gewünschten Sicht zu suchen:

select [Lock Information], * 
from fn_dblog(null, null)
where [Lock Information] like '%' + cast(object_id('...') as varchar(10))+'%'
and [Lock Information] like '%LOCK_SCH_M%'
go

Beachten Sie, dass, wenn die Ansicht durch DROP gefolgt von CREATE geändert wurde, die Objekt-ID wahrscheinlich geändert wurde, Sie jedoch zumindest die Transaktion erhalten, die zuletzt die CREATE-ID ausgeführt hat (die aktuelle Objekt-ID der Ansicht in der wiederhergestellten Datenbank). Mit der Transaktions-ID kehren Sie zurück und rufen die Informationen zum Beginn der Transaktion ab:

select [Begin Time], [Transaction Name], [Transaction SID], *
from fn_dblog(null, null)
where [Transaction ID] = '...'
and Operation = 'LOP_BEGIN_XACT';

Die [Transaction SID] ist wieder Ihr Typ. Verwenden Sie SUSER_SNAMEdiese Option , um den Anmeldenamen von der Anmelde-SID abzurufen. Wenn die SID 0x01 ist, bedeutet dies, dass die Anmeldung durchgeführt wurde. Dies bedeutet sa, dass jede Person, die das saKennwort kennt, dies hätte tun können.

Nein, es sei denn, Sie haben es über einen DDL-Trigger oder dergleichen protokolliert

Sie möchten sich ansehen, wer als ALTER-Rechte in dieser Datenbank oder als Mitglied der Rolle sysadmin / db_owner / ddl_admin fungiert. Dies wäre besser als eine allgemeine Überprüfung als eine Hexenjagd. Es gibt wahrscheinlich auch andere Personen mit dem Recht, nicht genehmigte und nicht autorisierte Änderungen vorzunehmen

Wenn Sie dies noch nicht getan haben, möchten Sie möglicherweise den in SQL Server Management Studio verfügbaren Bericht zum Schema-Änderungsverlauf auschecken. Offenbar protokolliert SQL Server Änderungen standardmäßig ( Standardablaufverfolgung ), und Sie sollten diese Daten über diesen Bericht anzeigen können. Leider werden diese Tracedateien im Laufe der Zeit automatisch gelöscht / verschoben, sodass die Daten möglicherweise bereits gelöscht sind. Viel Glück!