tags:

views:

97

answers:

5

Hey all,

I think someone with shared access to my SQL Server '05 DB is deleting records from a table in a DB for their own reasons.

Is there any audit table I can check to see manual delete queries which may have been run on the DB in the last X number of days?

Thanks for your help.

Ed

+1  A: 

SQL Server Profiler is probably the easiest way to do this. You can set it to dump all executed queries to a table in the database, or to a file which might be more suitable in your case. You can also set a filter to capture just the queries you're interested in, or the log files become huge.

Nestor
+3  A: 
SELECT deqs.last_execution_time AS [Time], dest.TEXT AS [Query]
FROM sys.dm_exec_query_stats AS deqs
CROSS APPLY sys.dm_exec_sql_text(deqs.sql_handle) AS dest
ORDER BY deqs.last_execution_time DESC
David
Good idea, but only if the execution plans are still in memory
Philip Kelley
thanks David - i'll try that out
Ed Bloom
actually think i'll need to go with one of the trigger suggestions at this stage to monitor future deletes
Ed Bloom
+4  A: 

I'd add an on delete trigger to the table in question. That would allow you to keep an exact log of deleted records (ie, if on your trigger you insert into another table, etc)

gmagana
+4  A: 

May want to consider using a trigger temporarily.

Here's an example.

asp316
great suggestion and thanks for the link
Ed Bloom
...plus a DDL trigger to ensure they don't temporarily DROP the trigger... but what if they drop the DDL trigger?!
onedaywhen
Indeed, the trigger can just be dropped and re-created after deleting the record!
Nestor
A: 

Unless you've set things up beforehand (via triggers, running Profiler traces, or the like) no, there is no simple native way to "pull out" commands that have been run against a SQL Server database.

@David's idea of querying the procedure cache is one possibility, but would only work if the execution plan(s) are still in memory.

There are third-party transaction log readers available. They could be used to read the contents of the transaction log, but again that only helps if the data/commands are still in there, and after "X days" that seems unlikely.

Another work-around would depend on backups.

  • Restore a copmlete backup from before your problem time, and compare and contrast with the current version. This would show if data has been deleted, but not how.
  • If you are in Full backup mode and you have transaction log backups, you can perform various types of incremental restores and actually observer the deletions happening (if they are), but this would probably require a lot of point-in-time recoveries and would be very time intensive.
Philip Kelley