Detective By Accident – that’s what DBA really stands for, not Database Administrator. Come on, if it was really Database Administrators, we’d be DA’s. Granted, most of us don’t look like Warrick Brown or Sara Sidle, but when something disappears in the datacenter, people pick up the phone and call us.
On July 24th, Jason Hall and I are doing a webcast called CSI:DBA – Going Back in Time to Understand What Happened to Your Data. We’re going to cover how to find out who made schema changes, who deleted/truncated tables, and how to get the data back without time-consuming full restores. I’ll be talking through some of the native SQL Server tools to do it, and Jason will be showing off the Quest tools that make the job easier.
Performance Dashboard Reports
These say Performance in the name, so it would sound like they’re not the right answer to this problem, but it turns out there’s a great report in there to address this very issue. The Schema Changes History report shows what logins made schema changes in each database, and when the change was made. Here’s an example:
Clik here to view.
SQL Server Performance Dashboard
These reports run off the default server-side trace that runs all the time in SQL Server 2005 and 2008, so there’s no additional performance impact in order to capture this information. These reports are included with Microsoft SQL Server 2008, and for 2005, they’re a separate download – download the Performance Dashboard Reports.
These reports have been part of the solution in all of my recent webcasts. I’m a big believer that every DBA needs to have these installed and play around with them because they’re so useful. I was just giving career advice to a DBA yesterday: he specialized in writing reports, and I said if there’s one type of report to produce, it’s RDLC reports that integrate with SQL Server Management Studio.
That’s a great start – it does tell us who did it and a little bit about what they did – but it only works with SQL 2005 & 2008, and it doesn’t give us exactly what their statement was, and it doesn’t give us anywhere near enough to roll back their devious work. We need more information, so let’s get the toolbox out of our Hummers and check out our next tool.
Database-Wide DDL Triggers
SQL Server 2005 introduced DDL triggers that can be fired off whenever someone runs Data Definition Language code like altering a table, adding an index, or dropping a view.
People have written DDL triggers that log schema changes to a table – here’s one example of auditing DDL statements in a table, and here’s another. I’ve used some of this code myself to track schema changes, and I do love the results:
Clik here to view.
DDL Trigger Results
I get a nice table with who the guilty culprit is and I get their exact SQL statement. That’s a step in the right direction, because I can print it out and take it with me into the interrogation room. (Every DBA has an interrogation room, right?)
That gets us our confession and our guilty verdict, but it doesn’t get us back to how things used to be. For that, you’ll need to tune into our next episode – I mean, webcast!
Image may be NSFW.Clik here to view.
Image may be NSFW.Clik here to view.
Image may be NSFW.Clik here to view.
Image may be NSFW.Clik here to view.
Image may be NSFW.Clik here to view.
Image may be NSFW.Clik here to view.
Image may be NSFW.Clik here to view.
Image may be NSFW.Clik here to view.
Image may be NSFW.Clik here to view.
