Determinare come si è verificato un cambio di schema?

Ieri è successo qualcosa di brutto.

Una vista che è stata creata qualche tempo fa è stata modificata da qualcuno che alla fine ha rotto i rapporti. Sfortunatamente. qualcuno (consapevolmente o inconsapevolmente) ha fatto questa modifica nel database di PRODUCTION.

La mia domanda: esiste un modo (script / software / freeware ecc.) Con cui possiamo sapere chi (nome utente) ha apportato questa modifica, in modo da poter revocare l'accesso al database di produzione per quell'utente.

Se la mia domanda non è chiara, si prega di commentare.

Questo viene registrato sulla traccia predefinita, quindi, fintanto che è abilitato e non è stato eseguito il roll over nel frattempo, dovrebbe essere visualizzato nel rapporto "Cronologia modifiche schema".

Per accedervi in ​​Management Studio, fare clic con il pulsante destro del mouse sul database, quindi scegliere dal menu di scelta rapida Reports -> Standard Reports -> Schema Changes History

Per recuperare le stesse informazioni tramite TSQL è possibile utilizzare

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 ha già indicato la strada migliore, la traccia di controllo amministrativo che di solito è attiva (a meno che non sia stata esplicitamente disabilitata). Se non è possibile trovare le informazioni nella traccia di amministrazione (è stata disabilitata o è stata riciclata) è possibile recuperare le informazioni dai backup del registro. Poiché è un DB di produzione, suppongo che tu abbia un ciclo di backup regolare, con backup periodici completi e backup dei log. Sarà necessario ripristinare, su un server separato, il database al momento dell'incidente in modo che il DDL si trovi nel registro ripristinato corrente. Quindi è una semplice questione di utilizzo fn_dblog()e controllo del registro.

Un modo è seguire le operazioni di inizio transazione:

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

Se è ALTER VIEWstato emesso in una transazione autonoma (cioè non circondata da BEGIN TRANSACTION/ COMMIT), avvierà una transazione denominata CreatProc transaction. Cercalo e [Transaction SID]è il SID di accesso che desideri.

Un'altra possibilità è cercare la transazione che ha acquisito un SCH_M nella vista desiderata:

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

Si noti che se la vista è stata modificata da DROP seguita da CREATE, probabilmente è stato modificato l'id oggetto, ma almeno si otterrà la transazione che ha eseguito l'ultima volta CREATE (l'attuale ID oggetto della vista nel db ripristinato). Con l'ID transazione si torna indietro e si recuperano le informazioni di inizio transazione:

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

Il [Transaction SID] è, ancora una volta, il tuo ragazzo. Utilizzare SUSER_SNAMEper recuperare il nome di accesso dal SID di accesso. Se il SID è 0x01 significa che il login lo era sa, il che significa che chiunque sapesse che la sapassword avrebbe potuto farlo.

No, a meno che non sia stato registrato tramite un trigger DDL o simile

Volete vedere chi come diritti ALTER in quel database o appartenenza al ruolo sysadmin / db_owner / ddl_admin. Sarebbe meglio come una recensione generale piuttosto che una caccia alle streghe. Probabilmente ci sono altre persone con il diritto di apportare modifiche non approvate e non autorizzate

Se non lo hai già fatto, potresti voler consultare il rapporto Cronologia modifiche schema disponibile in SQL Server Management Studio. Sembra che SQL Server registri le modifiche per impostazione predefinita ( traccia predefinita ) e dovresti essere in grado di visualizzare quei dati tramite questo rapporto. L'unica cosa spiacevole è che questi file di traccia vengono automaticamente cancellati / rollover col passare del tempo, quindi i dati potrebbero già essere andati. In bocca al lupo!