2009-06-25 8 views

Respuesta

10

Si ha habido poca o ninguna actividad desde la eliminación, la traza de fábrica puede ser de ayuda. Pruebe a ejecutar:

DECLARE @path varchar(256) 

SELECT @path = path 
FROM sys.traces 
where id = 1 

SELECT * 
FROM fn_trace_gettable(@path, 1) 

[Además de la traza fuera de la caja, hay también el menos conocido rastro 'cuadro negro', que es útil para el diagnóstico de servidor se bloquea intermitentes. Esta publicación, SQL Server’s Built-in Traces, le muestra cómo configurarla.]

+1

+1 - Gracias, que es muy útil. Acabo de ejecutar eso y me da aproximadamente 2 días de copias de seguridad. ¿Hay alguna manera de obtener más? ¿Qué opciones se encargan de controlar esas configuraciones de rastreo? –

+0

@mitch: es un consejo increíble. sin embargo, es un rastro muy pequeño. ¿Hay alguna manera en que pueda configurar esto para que sea un rastro más grande? –

+0

@Tapori: publiqué sobre los rastros incorporados de SQL Server aquí: http://mitch-wheat.blogspot.com/2009/01/sql-servers-built-in-traces.html: es posible modificar el tamaño de el rastreo Black Box ... –

3

La mejor manera de recuperar la información es restaurar la última copia de seguridad.

Ahora para discutir cómo evitar tales problemas en el futuro.

Primero asegúrese de que su proceso de copia de seguridad se esté ejecutando correctamente y con frecuencia. Haga el registro de transacciones cada 15 minutos o media hora si es una base de datos altamente transaccional. Entonces, lo máximo que pierde es media hora de trabajo. Practique restaurar la base de datos hasta que pueda hacerlo fácilmente bajo estrés.

En SQL Server 2008 puede agregar activadores DDL (no estoy seguro si puede hacer esto en 2005) que le permiten registrar quién hizo cambios en la estructura. Puede valer la pena verlo.

NO permita que más de dos personas tengan acceso de administrador a su base de datos de producción: un dba y una persona de respaldo para cuando el dba esté desactivado. Estas personas deberían cargar todos los cambios en la estructura de la base de datos y el código, y todos los cambios deberían tener una secuencia de comandos, revisar el código y probarse primero en QA. No se debe ejecutar ningún código sin guión, "ejecutar por el asiento de tus pantalones" en prod.

+2

HLGEM - Buena respuesta, lástima que no fue a la pregunta que hice. -1 – MagicAndi

+0

+1, esta es la respuesta a la pregunta que tenía que hacer antes de esta pregunta actual: "¿cómo puedo prevenir y/o tratar con alguien borrando mi base de datos? ... –

+0

+1: una excelente respuesta debido a pensando lateralmente para identificar la raíz de la causa subyacente del problema IE un error debido a la falta de procesos de gestión y auditoría de la plataforma de la base de datos. –

4

Primero le preguntaría a todos los que tienen acceso de administrador al servidor Sql si lo eliminaron.

+6

Y si tuviera que preguntarle a más de tres personas, también le preguntaría al DBA por qué hay tantas ... – stephan

3

Aquí es poco TSQL más precisa

SELECT DatabaseID,NTUserName,HostName,LoginName,StartTime 
FROM 
sys.fn_trace_gettable(CONVERT(VARCHAR(150), 
     (SELECT TOP 1 
        f.[value] 
      FROM sys.fn_trace_getinfo(NULL) f 
      WHERE f.property = 2 
     )), DEFAULT) T 
JOIN sys.trace_events TE ON T.EventClass = TE.trace_event_id 
WHERE TE.trace_event_id =47 AND T.DatabaseName = 'delete' 
-- 47 Represents event for deleting objects. 

Esto se puede utilizar en los eventos tanto de saber o no saber el nombre de base de datos/objeto. Los resultados se ven así:

enter image description here

Cuestiones relacionadas