Prior Winners:

• Lara Rubbelke – (post link | blog | @SQLGal) – Enterprise Policy Management Framework
• Tim Ford – (post link | blog | @SQLAgentMan) – Determine Free Space, Consumed Space, and Total Space Allocated for SQL Server databases

This “award” has (unintentionally) not been handed out in a while but something that I’ve used (or a variation of) for a while now that I think needs to get bumped back up to the top of everyone’s RSS Feed is Mladen Prajdic’s I.D.N.W.C.E.C (a not so catchy acronym that I just came up with).

Immediate Deadlock Notifications Without Changing Existing Code

Mladen describes how to use the server wide deadlock notification (Event Notifications) to capture the deadlock graph (or deadlock chain, deadlock, escalation) to a table as soon as a deadlock occurs (as well as optionally to send an email at time of capture).

Now what I like about this over the more “traditional” way of detecting deadlocks with Trace Flags 1204 and 1222 (MSDN Link) is that we’re able to capture the deadlock graph event like we were running a Profiler trace against the server.  Using trace flags 1204 and 1222 you get all the same information but I’m a picture person….

and as a picture person I much prefer to see the deadlock graph over the “texty” / XMLish type of information you get back from Trace Flags 1204 and 1222.

Big thanks and props to Mladen for this blog post as I’ve come back to it time and time again

If you’d like to chat with me about this or anything else (SQL or other) please leave a comment or hit me up on my Twitter: @ColinStasiuk

OK maybe not “harder” but I just found a DMV that I didn’t know existed that is going to help me make “better, faster, stronger” an old way of doing things.

I wrote a blog post back in 2009 called: Check SQL Server Agent Status on all SQL Servers

This scripted used the sysprocesses table to check for the existence of a row where the program_name = ‘SQLAgent – Generic Refresher’.  If the row existed then that told me the SQL Server Agent was up and running.

While poking around SQL 2012 CTP3 I stumbled upon the sys.dm_server_services DMV (which basically returns information about the SQL Server and SQL Server Agent services… information like whether or not they are running ).

I thought I’d check books online to see if this was something new introduced in SQL 2012 and apparently this has been around since SP1 of SQL 2008 R2.

Whenever I find something like this and can tweak / fix /modernize something I’ve used for what seems like forever I feel like I’m evolving

If you’d like to chat with me about this or anything else (SQL or other) please leave a comment or hit me up on my Twitter: @ColinStasiuk

Deep huh?

Well if the job actually does something important of course it will get noticed. 

So the bigger question is:

What can you do to make sure that YOU know about it before anyone else does? 

Cause who likes surprise phone calls?

This is a multipart-answer so bare with me…

Step 1.  Setup a Policy Based Management condition to find SQL Server Agent Jobs with NO notification on Failure

DOWNLOAD CONDITION

Step 2.  Setup a Policy Based Management policy to check the condition created in Step 1

DOWNLOAD POLICY

OK so this will do nothing more then tell you whether or not the SQL Server you are evaluating this policy against has jobs that do not have a notification on failure configured. 

What if my SQL Server Agent has 500 jobs? How do I find the ones without failure notifications configured?

Step 3. 

SELECT * 
FROM msdb.dbo.sysjobs 
WHERE [enabled] = 1 AND notify_level_email NOT IN (1,2,3)

Fantastic so what if you have 500 jobs and 499 of these jobs DO NOT have any notification on failure configured?

Step4.  Script to update all jobs to include a notification on failure

*** MAKE SURE YOU UNDERSTAND WHAT THIS IS DOING BEFORE RUNNING THE OUTPUT ***

What this script will do is provide you with the commands to update ALL your jobs to notify BY EMAIL to the operator you provide in the @NotifyOperator variable

USE [msdb] 
DECLARE @NotifyOperator nvarchar(100) 
SELECT @NotifyOperator = 'DBA' 
SELECT 'EXEC msdb.dbo.sp_update_job @job_id=N''' + convert(nvarchar(50),job_id) + ''', @notify_level_email=2, @notify_email_operator_name=N''' + @NotifyOperator + '''' FROM msdb.dbo.sysjobs

Tweak this as you see fit:

• Include a WHERE clause to exclude or include only certain jobs
• Change additional notification options (page? net send? etc?)

 So there you go… you now have:

• A check condition and policy to identify jobs that DO NOT have some level of notification
• A script to identify which jobs those are
• A script to blanket update all jobs to a particular notification level and settings.

Enjoy!! (Follow me on Twitter: @ColinStasiuk)

I’ll be doing a Pain-Of-The-Week webcast with Kevin Kline and Iain Kick on some of the auditing options that are available to you in SQL Server 2008.  Microsoft has come a LONG way in providing DBAs the tools needed to audit SQL Server activity so if you haven’t had a chance to investigate this on your own hopefully this webcast will give you some motivation to give them a try.

Here is the abstract and link to the POW page:

Audits, Audits, Audits. 

 Microsoft has given DBAs many options when it comes to auditing SQL Server activity, so it’s important to understand what methodologies you have available to you.  Your options vary depending on your version and edition and the type of information you’re looking to capture. 

 Join Kevin Kline, Iain Kick, and Colin Stasiuk as they discuss some of their experiences, how-to’s, and do’s and dont’s for some of the more common and popular auditing options, including change data capture, trigger-based auditing, and other techniques.

Register Here

Enjoy!! (Follow me on Twitter: @ColinStasiuk and @Tier1OnSQL)

Use Case: I want to be able (using CMS- Central Management Server)  connect to all my SQL Servers (2000, 2005, and 2008) and get the most recent job execution status for all enabled SQL Server Agent Jobs.

At first I thought I was going to be smart (keep your jokes to yourself and try to concentrate )…. so like I was saying… at first I thought I was going to be smart and create a temp table to store the value of sp_help_job and then work with the data from there.

Apparently sp_help_job uses INSERT EXEC itself so when I tried to run my fancy code I got this:

An INSERT EXEC statement cannot be nested.

Fail

So yeah… that pretty well stopped me in my tracks with that idea.   There are a couple tricks to get around that one but I either couldn’t use them cause I’m querying against SQL 2000 still or I wasn’t comfortable with the “workaround” as it felt a bit hack-fu.

So this is what I came up with…

SELECT	A.Name as 'JobName', Sub5.MaxRunDate, Sub5.MaxRunTime, Sub5.MostRecentJobStatus
FROM	msdb.dbo.sysJobs A LEFT OUTER JOIN
		(SELECT	A.Job_ID, Sub4.MaxRunDate, Sub4.MaxRunTime,
				CASE	A.run_status
						WHEN 0 THEN 'Failed'
						WHEN 1 THEN 'Successful'
						WHEN 2 THEN 'Retry'
						WHEN 3 THEN 'Cancelled'
						WHEN 4 THEN 'In Progress'
				END as 'MostRecentJobStatus'
		FROM	msdb.dbo.sysJobHistory A INNER JOIN
				(	SELECT	A.Job_ID, Sub3.MaxRunDate, Sub3.MaxRunTime, Sub3.MaxStepID, MAX(A.Instance_ID) as 'MaxInstanceID'
					FROM msdb.dbo.sysJobHistory A INNER JOIN
						(	SELECT	A.Job_ID, Sub2.MaxRunDate, Sub2.MaxRunTime, MAX(A.Step_ID) as 'MaxStepID'
							FROM msdb.dbo.sysJobHistory A INNER JOIN
								(	SELECT	A.Job_ID, Sub1.MaxRunDate, MAX(A.run_time) as 'MaxRunTime'
									FROM	msdb.dbo.sysJobHistory A INNER JOIN
									(	SELECT	A.Job_ID, MAX(A.run_date) as 'MaxRunDate'
										FROM	msdb.dbo.sysJobHistory A
										GROUP BY A.Job_ID) Sub1 ON
											A.Job_ID = Sub1.Job_ID AND
											A.run_date = Sub1.MaxRunDate
									GROUP BY A.Job_ID, Sub1.MaxRunDate) Sub2 ON
										A.Job_ID = Sub2.Job_ID AND
										A.run_date = Sub2.MaxRunDate AND
										A.run_time = Sub2.MaxRunTime
							GROUP BY A.Job_ID, Sub2.MaxRunDate, Sub2.MaxRunTime) Sub3 ON
									A.Job_ID = Sub3.Job_ID AND
									A.run_date = Sub3.MaxRunDate AND
									A.run_time = Sub3.MaxRunTime AND
									A.Step_ID = Sub3.MaxStepID
						GROUP BY A.Job_ID, Sub3.MaxRunDate, Sub3.MaxRunTime, Sub3.MaxStepID) Sub4 ON
							A.Job_ID = Sub4.Job_ID AND
							A.run_date = Sub4.MaxRunDate AND
							A.run_time = Sub4.MaxRunTime AND
							A.Step_ID = Sub4.MaxStepID AND
							A.Instance_ID = Sub4.MaxInstanceID) Sub5 ON
		A.Job_ID = Sub5.Job_ID
WHERE	A.[Enabled] = 1
ORDER BY A.Name

Now I’m the first to admit that this looks… well horrible…but it seems to work and get me the information I want.

Add in a simple Sub5.MostRecentJobStatus = ‘Failed’ and now you’re querying your whole environment for any job that has failed.

I do have notifications setup to email me whenever a job fails, but being a bit on the anal retentive side I like to have a script like this ready to go just in case I ever want a quick ad-hoc view of things

Like I said at the start of this post… I’m hoping that someone has something much easier to look at and use… so if you got it… flaunt it and comment below!!

Enjoy!!

Have  I mentioned how much I love the SQL community….

Hey… have you heard that Jonathan Kehayis wrote a blog post about some uses for DBINFO and the dbi_version and dbi_createVersion values?

Yeah but did you hear that Paul Randal wrote a blog post about Checking if Data Purity check will be run based off of the dbi_createVersion ?

Yeah but did you hear that Sankar Reddy wrote a blog post about pulling the dbi_createVersion, dbi_version, and dbi_crdate for all databases in a single script?

Yeah but did you hear that Ken Simmons wrote a blog post about checking every databases data purity flag and identifying which databases will not perform the data purity check?

Like I said… I love the community… a single persons blog post spawns multiple variations and building of ideas and thoughts… and even though each persons blog post is different then the rest each author makes sure to call out the others posts as excellent related reading and “inspiration” for their post.

Hey… did you hear that Colin Stasiuk (thanks to an idea and email request from Ken Simmons ) added a Policy Based Management Check Condition and Policy to check every database’s data purity check value in his environment…

CONDITION

Download .sql file: DataPurityFlag_Cdn

POLICY

Download .sql file: DataPurityFlag_Ply

(Yeah I know I said I’d do a non-PBM post this time around but it wasn’t TOTALLY my fault hehehe )

Enjoy!!

I’m sorry but I’m loving me some PBM right now.

Something that I’ve found to be very useful is creating a custom Policy Category.  I have scheduled jobs that evaluates all the policies that belong to a specific category.  So what I do is I categorize the Policies that I want ran based on when I want them run.  Currently I have 2 custom categories (Daily and Weekly).

A question you may be asking is why wouldn’t you just check all your policies every day?  If you’ve played with Policy Based Management and have been running it against multiple server, multiple dbs, etc you’ll know that it doesn’t take long before your job takes 15, 20, 30 minutes to finish… I’m a fan of minimizing the amount of “admin” work being done on my instances so if there are some policies that I don’t feel are critical then I wont run them every day.

Some Examples Below:

Daily – Last Successful Full Backup Date, Database has less then 10 Pct Free Space

Weekly -  Database Auto Shrink, Data and Log File Location

Now these aren’t ALL my policies that I check but just some examples. 

The daily policies are what I consider to be the most critical and I want to know the status every day so that if something does not conform it can be immediately actioned.  Now I would have alerts and notifications setup for some of these scenarios as well but some things are important enough (backups) that I don’t like relying on only one check.

The weekly policies are ones that I consider to be VERY unlikely to change but still want and like the weekly sniff test to make sure things are inline with what my expectations are. 

Creating a new Policy Category is as easy as right clicking on a Policy and going to the properties.  If you click on the Description page on the left hand side you’ll see the following window:

If you click on the “New” button you can enter a new category and then start assigning policies to that category.

And once you’ve started going “Category-Crazy” you might be wanting a query to see your categories and the policies assigned to those categories so I’ll save you some trouble:

SELECT	B.name as 'CategoryName', A.name as 'PolicyName', A.is_enabled
FROM	msdb.dbo.syspolicy_policies_internal A INNER JOIN
		msdb.dbo.syspolicy_policy_categories_internal B ON A.policy_category_id = B.policy_category_id
ORDER BY B.name, A.name

(I promise the next post will not be about PBM…. well I’ll try at least LOL )

Enjoy!!

Translation: Fail Whale for SQL Server Management Studio and Central Management Server for Policy Based Managment using PowerShell…. lol simple eh?

So this is a Microsoft Connect Item in the making…

I had created a PowerShell script to run a bunch of policies against a list of servers that I defined in a ServerList.txt file.  I decided that I didn’t like the idea of needing to maintain a text file and instead of storing the Instance Names in a table somewhere I decided to hook into the Central Managment Server.

So I logged into the server that is currently running the SQL Server Agent job that was doing all this using a ServerList.txt file.  I changed the PowerShell Script to point to my CMS server instead and ran the .ps1 directly on the server using “sqlps F:\PBM\EvaluatePolicies.ps1″.  The script ran as expected, used my CMS server, and everything was tickidyboo.  Or so I thought….

I decided to do my final check and run the SQL Server Agent job itself… and it failed.

Hmmmm that’s weird… so I confirmed that the SQL Server Agent account had access to the CMS server and even granted it explicit sysadmin rights (just for my troubleshooting).

FAIL

I started tweeting about the problem and got some immediate advice from @afernandez, @russjohnson, @wendy_dance, and @SQLChicken.  While none of the advice solved my problem it was great to have some other “eyes” reading my problem and confirming the stuff that I had already thought of and tested.

The SQL Server Agent Service Account is a secure account that I don’t even have access or the password for so I asked for some help from one of our Server Admins for my troubleshooting… he logged into the server for me and I tried to run the ps1 file….

FAIL

So I opened up SSMS and checked if I could connect to the CMS directly….

SOLUTION:  In order to use a PowerShell script to connect to the Central Management Server using the SQL Server Agent the service account that SQL Server Agent is running under must REGISTER the CMS Server through SSMS on the Server that is running the job.

Did you get all that…. because I had never Remote Desktopped onto the Server using the SQL Server Agent service account and Registered the CMS Server in SSMS using that account when I tried to access the CMS Server through my PowerShell script it failed.

I registered the CMS Server using the SQL Server Agent Service Account and everything started sizzling like bacon on a hot pan.

Enjoy!!

If you’ve never watched Stuart from MadTV the Title of this blog post will probably be lost on you but if you want to get up to speed just Watch This Video on YouTube

So if you read my blog (first thanks!! ) you know that I’ve been having a love affair lately with Policy Based Management.  I’m starting to look outside of the canned Policies and working on creating my own.  I wanted to start simple just to get something going so I came up with an idea for a policy:

Jobs That Do Not Have Email Operator On Failure Enabled

So first I created my Condition:

• Name: SQLAgentJobsWithNoNotificationOnFailure
• Facet: Server (I picked server because the query I’m going to be only needs to be ran once vs msdb)

I built my SQL Statement:

SELECT	COUNT(*)
FROM	msdb.dbo.sysjobs
WHERE	[enabled]  = 1 AND
		notify_level_email != 2

and went to add it to the “Field” column of my condition but I remembered the Podcast by Brent Ozar and Thomas LaRock where they demoed the ExecuteSQL() function within Policy Based Management.

So my code in my field column ended up looking like this instead:

EXECUTESQL('numeric', 'SELECT	COUNT(*)
FROM	msdb.dbo.sysjobs
WHERE	name NOT LIKE ''%TestDatabaseMail%'' AND
		[enabled]  = 1 AND
		notify_level_email != 2')

 So then I populated the expected value….   = 0 and I was ready to go.

I next created my Policy using my new Check condition and voila, I just built my first custom Policy.  I evaluated the Policy and saw immediate value as there were a couple production jobs that did NOT have any email notification set on failure.

My love affair with Policy Based Management continues… I think I’m ready to commit and start picking out china together.

Happy Friday!!!

P.S. Already working on v.2 of the policy… I want to be able to filter particular jobs as well as return the list of non conforming jobs stay tuned LOL

Enjoy!!

One guess on who’s having WAY TOO MUCH FUN blogging these day?? LOL

Too often DBAs don’t take the time to review their environments and their surface area exposure.  You want to evaluate the features that you’ve enabled and determine if they are required.  The less features enabled, the less likelyhood that you will have a successful attack on your environment.

In SQL Server 2005 the SQL Server Surface Area Configuration Tool was used by DBAs to review and manually turn on/off features in the product.  The Surface Area Configuration Tool has been removed in SQL Server 2008.  So where would one go now to review their surface area exposure?

Enter one of my new best friends… Policy Based Management.

SQL Server 2008 Policy Based Management comes with 4 policies for Surface Area evaluation

• Surface Area Configuration for Database Engine 2005 and 2000 features
• Surface Area Configuration for Database Engine 2008 features
• Surface Area Configuration for Service Broker Endpoints
• Surface Area Configuration for SOAP Endpoints

The Policy we’re going to look at in this post is the Surface Area Configuration for Database Engine 2008 Features.  This Policy uses the condition Surface Area Configuration for Database Engine 2008 Features which ties to the Surface Area Configuration facet.

By default the following settings are used:

• AdHocRemoteQueriesEnabled – False
• ClrIntegrationEnabled – False
• DatabaseMailEnabled – False
• OleAutomationEnabled – False
• RemoteDacEnabled – False
• ServiceBrokerEndpointActive – False
• SoapEndpointsEnabled – False
• SQLMailEnabled – False
• xpcmdshellEnabled – False

Now keep in mind that these are configurable (from within the check condition) and in your environment you might not be able to conform to the point where this Policy will come back with the nice happy green arrow.  I for one use DatabaseMail so this is something that I’ve had to change in the check condition.

The idea here is that Policy Based Managment can give you a great look into your surface area exposure and where you might be able to investigate and possibly disable some features to minimize the likelyhood of a successful attack… and don’t you SQL 2000 and SQL 2005 DBAs fret as noted above there is a policy built as well just for you (Surface Area Configuration for Database Engine 2005 and 2000 features).

So do your best review and to minimize your surface area exposure and not have your “kibbles and bits” out there for the world to see

Enjoy!!