Auditing Dropped Databases

Jason Brimhall shows how to figure out who dropped that database:

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 is available in the default trace or, as Jason points out, you can create an Extended Event (which data can live much longer than that in the default trace).

Related Posts

Azure Kubernetes Service Max Volume Count

Chris Taylor explains an error message in Azure Kubernetes Service: Whilst playing around with my session for Techorama.nl I encountered an error I hadn’t seen previously whilst deploying SQL Server on Linux in Azure Kubernetes Service (AKS) 0/1 nodes are available: 1 node(s) exceed max volume count The yaml I used was only slightly modified (mainly names) […]

Read More

Read-Only versus Read-Write and SQL Server

Jack Vamvas takes us through what it takes to turn a read-write database in SQL Server read-only and vice versa: There are some considerations for deciding if a Developer should be able to include as part of an ETL process , the capacity to change the READ STATE of a SQL database 1) Requires ALTER permission on the […]

Read More

Categories

September 2016
MTWTFSS
« Aug Oct »
 1234
567891011
12131415161718
19202122232425
2627282930