I’m presenting right now at the Professional Association for SQL Server Summit in Seattle, and I’m just about to show my attendees the latest incarnation of my Blitz script.
In the past, my manual Blitz script has helped DBAs all over the world discover ugly problems in SQL Servers. However, one thing has been bothering me a lot for the last year or so. One of the lines in the script said, “Change this email address to your own, then execute this line and make sure you can receive emails from Database Mail.” You can probably guess what happened – a lot of people didn’t bother changing the email address. I used my own email in the script because I wanted to know when people ran it that way, and I got at least a dozen emails a week. I talked to some of the users, and they confessed that they didn’t even bother to read the script – they just clicked F5.
At first that bugged me. The Blitz script really has two purposes: to enlighten DBAs about their SQL Server’s risks, and to start teaching the basics of DMVs. These users weren’t learning anything – they just wanted to run the script and make the magic happen. So I figured – why not give it to ‘em?
sp_Blitz: One-Minute Server Takeovers
Say hello to sp_Blitz – a simple stored procedure that runs a bunch of health checks and exports the results in a prioritized list. Here’s what the output looks like:
sp_Blitz Output (click to enlarge)
The URL column includes a link for each problem we found in the SQL Server. Copy/paste that link into a web browser and you’ll be able to learn more about the particular issue you’re facing. I also include a quick snippet about the general source of the data, like which DMVs I’m querying to catch the issue.
The stored procedure can take a minute or two to run on larger servers, and this is very much a version 1.0. If you find things you’d like to improve, please feel free to let me know – especially if you include sample code to improve it, heh. I expect sp_Blitz to undergo some rapid improvements over the coming weeks as people holler about bugs, which leads me to the next fun idea I’m playing with in the session.
sp_BlitzUpdate: Easy Updates Using the Cloud
Don’t you just hate going to somebody’s site to update your utility scripts? Most of us end up using vastly out-of-date versions of popular tools just because we can’t be bothered to do updates. I’ve got a solution.
At its simplest, updating a script means doing this:
ALTER STORED PROC dbo.sp_Blitz AS BLAH BLAH BLAH; GO
But if we take a step back, we’re really building a string, and then executing that string:
DECLARE @StringDDL VARCHAR(MAX) SET @StringDDL = 'ALTER STORED PROC dbo.sp_Blitz AS BLAH BLAH BLAH; GO; EXEC (@StringDDL)
And if we take a step back even farther – what if we got that string from the cloud? That’s what I’m doing with sp_BlitzUpdate; I open a connection to a SQL Server in Amazon EC2, fetch the most up-to-date version of sp_Blitz, store that in a string variable, and then execute that variable. Just by executing sp_BlitzUpdate, you get the latest version of sp_Blitz.
Here’s a simplified version of sp_BlitzUpdate to illustrate the basics of the concept:
CREATE PROCEDURE dbo.sp_BlitzUpdate AS
DECLARE @ScriptDDL VARCHAR(MAX);
/* Fetch the script definition from THE CLOUDZ */
SELECT @ScriptDDL = a.ScriptDDL
FROM OPENROWSET('SQLNCLI', 'Server=publicsql.brentozar.com;UID=ReadOnly;PWD=PainRelief;',
'SELECT TOP 1 ScriptDDL FROM dbo.Scripts WHERE ScriptName = ''sp_Blitz'' ORDER BY ScriptID DESC') AS a;
/* Drop the existing Blitz script if it already exists */
IF OBJECT_ID('master.dbo.sp_Blitz') IS NOT NULL
DROP PROC dbo.sp_Blitz ;
EXEC(@ScriptDDL);
Warning: this approach is fraught with peril. Somebody could hack my SQL Server in Amazon EC2 and put malicious code up there. Even if they don’t, you’re still counting on me to have safe code inside that database, because you might be running it on your production box. This is like the ultimate in dangerous SQL injection. This is purely experimental, and I don’t know that I’ll keep using it permanently, but it’s something really fun to play with.
Hey, not everything I do is productive – sometimes it’s just about stunt driving. Enjoy!
...
Free webcasts coming up: how to tell when TempDB is a problem, There's Something About Nolock, and how to take over SQL Servers in 60 seconds. Register now.