Excellent: Dilbert on data analysts
The best part is the last quote: I like how you punctuate your ignorance with certainty.
Excellent: Dilbert on data analysts
The best part is the last quote: I like how you punctuate your ignorance with certainty.
I read this piece from Troy Hunt, which is a long look at the password reset process for a web application. It’s one of the first that I’ve seen which talks about the different implementations, along with the pitfalls and advantages of each.
It’s a great look at passwords, and there are definitely a few things in there I think should be built into authentication frameworks. I know we need to change a few things at SQLServerCentral and I’ve added them to the list.
Pass this one along to your developers. They should be aware of this stuff.
One of the most amazing features to an old SQL Server 4.2 guy was the addition of DDL triggers to the server. As with any trigger, these can be problematic in that they can overload a server, and they ALWAYS fire, so you can cause yourself problems, but in terms of auditing, I think they’re great.
As a quick example, perhaps you’re worried about new logins, as I talk about in my AlwaysOn and Contained Databases in SQL Server 2012 presentation. You want to capture when a new login is created. You can do this with a DDL trigger like this one:
USE master GO CREATE trigger CatchLogins on ALL Server for CREATE_LOGIN as declare @data xml set @data = eventdata() SELECT @data
That doesn’t do much, but if I run this code:
CREATE LOGIN Delaney WITH PASSWORD = 'test'
I get this result:
Not overly helpful, but if you click on it, you see the event data as an XML document
<EVENT_INSTANCE> <EventType>CREATE_LOGIN</EventType> <PostTime>2012-07-23T11:47:41.427</PostTime> <SPID>62</SPID> <ServerName>SEVENFALLS</ServerName> <LoginName>SevenFalls\Steve</LoginName> <ObjectName>Delaney</ObjectName> <ObjectType>LOGIN</ObjectType> <DefaultLanguage>us_english</DefaultLanguage> <DefaultDatabase>master</DefaultDatabase> <LoginType>SQL Login</LoginType> <SID>Djwpf8IHNUicam9m2DkoBQ==</SID> <TSQLCommand> <SetOptions ANSI_NULLS="ON" ANSI_NULL_DEFAULT="ON" ANSI_PADDING="ON" QUOTED_IDENTIFIER="ON" ENCRYPTED="FALSE" /> <CommandText>CREATE LOGIN Delaney WITH PASSWORD = '******' </CommandText> </TSQLCommand> </EVENT_INSTANCE>
I can parse this out and store it. What do I want? Probably I want the server and object, the date for tracking, maybe the creator, but definitely the SID. The text doesn’t help since it doesn’t have the password. All I can do then is go find the user or admin and ask them to recreate this login on the secondary servers.
Let’s start parsing. You have two choices here with the XML: the .data or .query methods. There may be more, but that’s what I know. I’ll parse in two ways here:
ALTER trigger CatchLogins on ALL Server for CREATE_LOGIN as declare @data xml set @data = eventdata() select @data.value('(/EVENT_INSTANCE/PostTime)[1]', 'datetime') , @data.value('(/EVENT_INSTANCE/ServerName)[1]', 'nvarchar(1000)') , @data.query('(/EVENT_INSTANCE/ServerName)')
This returns some data.
You can see the .query returns XML, which (to me) is a hassle. So I’ll stick with the .value clause.
I would probably create a table here that stores this data. If I used a generic table for multiple types of audit data, I’d need to include the type of event as well. You can just use the first XML document for different audit types to see what’s returned, and then deal with it as appropriate.

Do you have a DBA database on all your instances? I’ve always kept a small database on all instances, usually standardized with a set of tables and procedures that I used to monitor and track activity on the instance. By keeping this fairly standard, I could script and deploy it during all new installs as well as easily aggregate information from all instances on a central server, usually in a slightly larger version of my DBA database.
It’s nice to see more and more DBAs using this same technique in their environments. Over the last few years I’ve seen lots of articles and blog posts that recommend building a DBA database and populating it with DBA-stuff. That DBA-stuff can be anything from tracking backup sizes, to storing performance metrics, to keeping trace data. I’ve seen some neat implementations with Service Broker that use the DBA database as a repository for a queue to which they can send messages. Based on those message, they can have the instance perform some action.
There are any number of standards or corporate reasons not to include extra databases, but none of them really make sense. The DBA database, and any administrative tasks that use this database essentially act as a proxy for the DBA. Almost every piece of data stored in this database is data that the DBA would query or use on a regular basis. Keeping it inside a database set aside for this purpose allows the DBA to act more efficiently.
If you haven’t built a DBA database, I’d encourage you to do so on all your instances. Secure it so only sysadmins can access it, but use it to capture and store information about the ongoing health of your SQL Server.
Steve Jones
We publish three versions of the podcast each day for you to enjoy.


