Database Dropped

What do you do when a developer comes to you and asks, “Where did the database go? The database was there one minute, and the next it was not.”

What do you do when a developer comes to you and asks, “Where did the database go?  The database was there one minute, and the next it was not.”  Only one thing could be database droppedworse than the feeling of losing a database on your watch, and that would be losing a production database. It’s like magic—it’s there, and then it disappears. To compound the issue, when asking people if they know what might have happened, all will typically deny, deny, deny.

What do you do when you run into that missing database situation and the inevitable denial that will ensue?  This is when an audit can save the day.  Through an audit, you can discover who dropped the database and when it happened.  Then you have hard data to take back to the team to again ask what happened.  Taking the info from a previous article of mine, we can alter the script I published there and re-use it for our needs here.

This script will now query the default trace to determine when a database was dropped or created.  I am limiting this result set through the use of this filter: ObjectType = 16964.  In addition to that, I have also trimmed the result-set down to just look for drop or create events.

This is the type of information that is already available within the default trace.  What if you wished to not be entirely dependent on the default trace for that information?  As luck would have it, you don’t need to be solely dependent on the default trace.  Instead you can use the robust tool called extended events.  If you would like to be able to take advantage of Extended Events to track this information, I recommend you read my follow-up article here.

This has been a republication of my original content first posted here.

2 thoughts on “Database Dropped”

  1. Great post! This is an excellent addition to my toolbox. For accidental drops this script does the trick. It is possible that a deliberate/malicious drop could be pinned to a domain user or SQL account laying the blame on an innocent party using, execute as login = ‘DOMAIN\User’. However, this limits the players to those who have sufficient rights to drop a database and run the execute clause. I’d place my bet that the LoginName in the script is correct 99.9{529e71a51265b45c1f7f96357a70e3116ccf61cf0135f67b2aa293699de35170} of the time.

    1. I would agree with you there. In addition, I have the follow-up to audit for dropped databases via Extended Events that will capture the actual user and the “execute as” user. Just more ammo for the dba. 😉

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.