Determinando como ocorreu uma alteração no esquema?

Algo ruim aconteceu ontem.

Uma visão criada há algum tempo atrás foi modificada por alguém que acabou quebrando os relatórios. Infelizmente. alguém (consciente ou inconscientemente) fez essa modificação no banco de dados PRODUCTION.

Minha pergunta: Existe uma maneira (script / software / freeware etc) pela qual possamos conhecer quem (nome de usuário) fez essa modificação, para que eu possa revogar o acesso ao banco de dados de produção para esse usuário.

Se minha pergunta não estiver clara, comente.

Isso é registrado no rastreamento padrão e, desde que esteja ativado e não tenha rolado enquanto isso, ele deve aparecer no relatório "Histórico de alterações de esquema".

Para acessar isso no Management Studio, clique com o botão direito do mouse no banco de dados e, no menu de contexto, escolha Reports -> Standard Reports -> Schema Changes History

Para recuperar as mesmas informações via TSQL, você pode usar

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 já apontou para a melhor avenida, o rastreamento de auditoria administrativa que geralmente está ativado (a menos que tenha sido explicitamente desativado). Se você não conseguir encontrar as informações no rastreamento do administrador (foi desativado ou foi reciclado), é possível recuperar as informações dos backups de log. Como é um banco de dados de produção, presumo que você tenha um ciclo de backup regular, com backups periódicos completos de backup e log. Você precisará restaurar, em um servidor separado, o banco de dados por volta da hora do incidente, para que o DDL esteja no log restaurado atual. Então é uma simples questão de usar fn_dblog()e inspecionar o log.

Uma maneira é seguir as operações de início da transação:

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

Se o ALTER VIEWfoi emitido em uma transação independente (ou seja, não é cercado por BEGIN TRANSACTION/ COMMIT), ele iniciará uma transação denominada CreatProc transaction. Procure e [Transaction SID]é o SID de login que você deseja.

Outra possibilidade é procurar a transação que adquiriu um SCH_M na visualização desejada:

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

Observe que se a exibição foi alterada por DROP seguida por CREATE, o ID do objeto provavelmente foi alterado, mas pelo menos você obterá a transação que fez o último CREATE (o ID do objeto atual da exibição no banco de dados restaurado). Com o ID da transação, você volta e recupera as informações de início da transação:

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

O [Transaction SID] é, novamente, o seu cara. Use SUSER_SNAMEpara recuperar o nome de login do SID de login. Se o SID for 0x01, significa que o login foi sa, o que significa que qualquer pessoa que saiba que a sasenha poderia ter feito isso.

Não, a menos que você o tenha registrado através de um gatilho DDL ou

Você deseja examinar quem, como direitos ALTER nesse banco de dados, ou associação à função sysadmin / db_owner / ddl_admin. Isso seria melhor como uma revisão geral do que como uma caça às bruxas. Provavelmente, há outras pessoas com direitos para fazer alterações não aprovadas e não autorizadas também

Se ainda não o fez, consulte o relatório Histórico de alterações de esquema disponível no SQL Server Management Studio. Parece que o SQL Server registra alterações por padrão ( rastreamento padrão ) e você deve poder visualizar esses dados por meio deste relatório. A única coisa infeliz é que esses arquivos de rastreio são automaticamente excluídos / rolados com o passar do tempo, para que os dados já tenham desaparecido. Boa sorte!