Esiste un modo per determinare chi ha lasciato cadere un tavolo?

Una tabella nel database di produzione è "misteriosamente" scomparsa.

Qualcuno sa come diagnosticare cosa diavolo gli è successo? E chi l'ha fatto?

Modifica 1: questa è un'app interna, con sicurezza debole. Tutte le app (tranne la mia ovviamente ;-) sono vulnerabili a SQL Injection, ma i nostri utenti sono molto poco sofisticati e il nome della tabella non era uno che potrebbe essere immediatamente ovvio, quindi non penso che fosse una SQL Injection (non che importa ... un po 'oltre l'ambito della domanda).

Modifica 2: Inoltre, solo una FYI; questa tabella esiste da molto tempo, quindi non è stata "annullata" con un ripristino.

È possibile riuscire a ottenere le informazioni dal registro utilizzando la funzione non documentata :: fn_dblog che interpreta i record del registro. Sono nel mezzo dell'insegnamento di una lezione di disaster recovery in questo momento, ma se puoi aspettare 2-3 ore posterò come farlo per te - dovrei essere in grado di ottenere anche il nome utente senza dover acquistare alcun strumento ( Nel 2000 scrivevo un sacco di cose intorno al registro mentre scrivevo un sacco di codice di analisi del registro interno che DBCC CHECKDB utilizza nel 2000).

[Modificato per includere le istruzioni] Ok - ho terminato l'insegnamento e ho eliminato un post sul blog per mostrarti come analizzare il registro nel 2000, 2005, 2008 per scoprire quando il tavolo è stato abbandonato e chi lo ha fatto. Dai un'occhiata al mio post sul blog su Scopri chi ha lasciato cadere una tabella usando il registro delle transazioni . [/modificare]

Hai ancora il log delle transazioni in giro? In quale modello di recupero si trova il database? Se è SEMPLICE, non fare nulla che possa causare un checkpoint. Se è FULL o BULK_LOGGED, non eseguire un backup del registro. Ognuno di questi causerà il troncamento del registro e quindi potresti perdere la possibilità di guardare indietro nel registro, anche se ho incluso un flag di traccia nel post del blog che potrebbe aiutarti anche in questo.

Grazie

PS Un modo per prevenire la caduta di tabelle nel 2000 senza aggiungere sicurezza è quello di creare una semplice vista schematica su di essa - DROP TABLE fallirà se la vista esiste.

Forse erano i tavolini Bobby ...

Potrebbe essere possibile recuperare queste informazioni dai registri SQL.

Se il registro di traccia predefinito è in esecuzione, tutte le informazioni vengono archiviate nella cartella del registro. Dovresti essere in grado di vedere quando l'oggetto (tabella) è stato eliminato e da quale connessione lo ha fatto. Ma questo tipo di autorizzazione dovrebbe essere concesso solo ai DBA comunque

Sto cercando di riparare un MSDB corrotto. Mi dispiace non sono in grado di elaborare.

Esegui questi e dovrebbe dare un'idea generale di dove cercare, supponendo che la traccia predefinita sia attiva.

SELEZIONA * FROM :: fn_trace_getinfo (impostazione predefinita)

SELEZIONA t.EventID, t.ColumnID, e.name come Event_Description, c.name come Column_Description FROM :: fn_trace_geteventinfo (1) t JOIN sys.trace_events e ON t.eventID = e.trace_event_id JOIN sys.trace_columns c ON t.columnid = c.trace_column_id

L'unico modo per scoprire queste informazioni è leggere il registro delle transazioni (supponendo che sia in modalità di recupero completo).

Due modi per farlo:

• Strumenti di terze parti come ApexSQL Log o SQL Log Rescue (gratuito ma solo sql 2000)
• Usando comandi come DBCC LOG o fn_dblog - nessuno dei quali purtroppo è ben documentato

In SSMS puoi provare a fare clic con il pulsante destro del mouse su dB e navigare tra Rapporti -> Rapporti standard -> Cronologia modifiche schema.

Fare clic con il tasto destro del mouse sul rapporto ed Excel "SaveAs" e trovare il nome dell'oggetto.

Non sarà possibile ottenere nulla se il server è stato riavviato più di cinque volte dopo che l'oggetto è stato eliminato.