I’m taking on a new topic today. Titled “ How to capture who did what in your SQL Server databases”, it’s a good overview of some of the techniques that can be used for auditing. Much like disaster recovery options, there is quite an assortment of auditing/logging options in SQL and just picking one (or more) takes some thought. Auditing always comes down to trade-offs; you could log everything, but it would be expensive, so you have to figure out what you have to have, what you really want, and set the rest aside. Making that decision is hard.

Here’s something to think on. We tend to think of logging events as an instance level problem, though we certainly hope to come up with a standard we can use across the environment. From a security/compliance perspective that’s just part one – what we really need is to make sure the logs can’t be altered and that we get them all into one place/format so we can do correlation. As much as I like tables, for true compliance auditing there is nothing better than writing to the event log (preferably the security log) and let someone else take it from there.

I have a tendency to go long, so today if anything I’m hoping to finish a little early. Almost always better to get done early than go over on time. I’ll also be taking notes and thinking about what resonates – is it the “how”, or is it the “what” that people find more interesting?