¿Determinar cómo ocurrió un cambio de esquema?

Algo malo sucedió ayer.

Una vista que se creó hace algún tiempo fue modificada por alguien que finalmente rompió los informes. Desafortunadamente. alguien (a sabiendas o sin saberlo) realizó esta modificación en la base de datos PRODUCTION.

Mi pregunta: ¿Hay alguna forma (script / software / freeware, etc.) mediante la cual podamos llegar a saber quién (nombre de usuario) realizó esta modificación, para que pueda revocar el acceso a la base de datos de producción para ese usuario.

Si mi pregunta no está clara, por favor comente.

Esto se registra en la traza predeterminada, por lo tanto, siempre que esté habilitado y no se haya transferido mientras tanto, debería aparecer en el informe "Historial de cambios de esquema".

Para acceder a esto en Management Studio, haga clic derecho en la base de datos y luego en el menú contextual elija Reports -> Standard Reports -> Schema Changes History

Para recuperar la misma información a través de TSQL puede 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 ya señaló hacia la mejor vía, la traza de auditoría administrativa que generalmente está activada (a menos que se haya desactivado explícitamente). Si no puede encontrar la información en el seguimiento del administrador (se deshabilitó o se recicló), puede recuperar la información de las copias de seguridad del registro. Como es una base de datos de producción, supongo que tiene un ciclo de copia de seguridad regular, con copias de seguridad completas periódicas y copias de seguridad de registro. Deberá restaurar, en un servidor separado, la base de datos a la hora del incidente para que el DDL esté en el registro restaurado actual. Entonces es una simple cuestión de usar fn_dblog()e inspeccionar el registro.

Una forma es ir por operaciones de inicio de transacción:

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

Si ALTER VIEWse emitió en una transacción independiente (es decir, no está rodeada por BEGIN TRANSACTION/ COMMIT), se iniciará una transacción denominada CreatProc transaction. Búscalo y [Transaction SID]es el SID de inicio de sesión que deseas.

Otra posibilidad es buscar la transacción que adquirió un SCH_M en la vista que desea:

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

Tenga en cuenta que si DROP cambió la vista seguida de CREATE, es probable que la identificación del objeto haya cambiado, pero al menos obtendrá la transacción que realizó CREATE por última vez (la identificación del objeto actual de la vista en la base de datos restaurada). Con la identificación de la transacción, regresa y recupera la información de inicio de la transacción:

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

El [SID de la transacción] es, de nuevo, tu chico. Use SUSER_SNAMEpara recuperar el nombre de inicio de sesión del SID de inicio de sesión. Si el SID es 0x01 significa que el inicio de sesión fue sa, lo que significa que cualquier persona que conozca la sacontraseña podría haberlo hecho.

No, a menos que haya iniciado sesión a través de un desencadenador DDL o tal

Desea ver quién tiene los derechos ALTER en esa base de datos o la pertenencia a la función sysadmin / db_owner / ddl_admin. Esto sería mejor como una revisión general en lugar de una cacería de brujas. Probablemente haya otras personas con derechos para hacer cambios no autorizados y no autorizados también.

Si aún no lo ha hecho, puede consultar el informe Historial de cambios de esquema disponible en SQL Server Management Studio. Parece que SQL Server registra los cambios de forma predeterminada ( rastreo predeterminado ) y debería poder ver esos datos a través de este informe. Lo único desafortunado es que estos archivos de rastreo se eliminan / vuelven automáticamente a medida que pasa el tiempo, por lo que los datos ya pueden haberse ido. ¡Buena suerte!