In this edition of T-SQL Tuesday, Jorge Segarra (Blog | Twitter) asks us what our favorite new feature of SQL 2008 or 2008 R2 is.  I’ve decided to focus on the T-SQL and query writing enhancements of 2008.  Before I do so though, let me preface this by noting that in no way do I believe these changes are the biggest improvements or best new things in SQL 2008, but things like Data compression are bound to be covered by several others.  Also, while writing this post I noticed that most of this has already been covered better than I could hope to by Itzik Ben-Gan in his white paper (Link).  Please refer to that for more information on the new features of 2008.

Your New home for One stop Variable Declaration

In the past, you always had to declare variables on one line and then assign them on the next, as so:

DECLARE @MyInt int

SET @MyInt = 44

Now, you can do this in one statement. 

DECLARE @MyInt int = 44

That might seem small, but it’s significant when you’re dealing with large numbers of variables.

SQL++ … almost

While you still can’t do something like:

SET @MyInt++

You can do the slightly longer version of:

SET @MyInt+=@Myint

– OR

SET @MyInt+=5

Instead of :

SET @MyInt = @MyInt + @MyInt

– OR

SET @MyInt = @MyInt + 5

This applies to:

+= (plus equals)

-=  (minus equals)

*=  (multiplication equals)

/=  (division equals)

%=  (modulo equals)

This one isn’t too huge a deal in my opinion, but it’s a nice shortcut for those used to using it in other programming languages.

Values of all rows, Union of None

In 2008, you can create multiple lines of data using the VALUES clause.  This one is really handy when I’m doing code examples in blog posts / on forums / in presentations etc.  It serves as an excellent replacement for the UNION ALL or repeated insert values pairs you used to have to use when supplying sample data. 

Say you have a simple table:

CREATE TABLE #Cake(

SomeInt           int,

SomeChar    char(5)

)

You want to provide some sample data for that table.  The most common ways prior to now were either:

INSERT INTO #Cake(SomeInt,SomeChar)

VALUES(1,‘AAA’)

INSERT INTO #Cake(SomeInt,SomeChar)

VALUES(2,‘BBB’)

INSERT INTO #Cake(SomeInt,SomeChar)

VALUES(3,‘CCC’)

– OR

INSERT INTO #Cake(SomeInt,SomeChar)

SELECT 1,‘AAA’ UNION ALL

SELECT 2,‘BBB’ UNION ALL

SELECT 3,‘CCC’

Now, you can use the much cleaner:

INSERT INTO #Cake(SomeInt,SomeChar)

VALUES(1,‘AAA’),

      (2,‘BBB’),

      (3,‘CCC’)       

– Or, on 1 line:

INSERT INTO #Cake(SomeInt,SomeChar)

VALUES(1,‘AAA’),(2,‘BBB’),(3,‘CCC’)

Lack of Intellisense

No conversation on the topic of coding enhancements would be complete without mentioning Intellisense in some way.  So… it’s there.  It works (kinda).  It could use a whole lot more fine tuning and configuration options than are there right now, but if you don’t have a copy of SQL Prompt, it’s better than not having anything (sometimes).  If you *do* have a copy of SQL Prompt and want to use a couple of the cool things SQL intellisense has that SQL Prompt does not, you can use the hybrid approach that I’ve gone with.  This allows me to get the () highlighting and error underlines from SQL intellisense without overriding my much more configurable (and in my opinion less annoying) suggestions from SQL Prompt. 

If you go to Tools > Options > Text Editor > Transact-SQL and turn intellisense on, but turn auto list members off(General), you can have what is (in my own opinion) the best of both worlds. 

That about wraps up what I wanted to point out this go round, hopefully you found something new that you didn’t know about before.  Don’t forget to check out all the other T-SQL Tuesday posts (Click the image at the top for a link to the others) that will no doubt point out many of the much bigger improvements in SQL Server 2008 and R2.

A couple of the known problems right now are: 

• Index names could already be taken, there’s nothing here that checks to make sure they are unique based on other indexes in your database.
• No compression options are taken into account.

That said, I still found this fairly useful and hopefully somebody else will as well.  Thanks again to Glenn for all his excellent work at creating queries to pull information from the DMV’s.

;WITH I AS (

– Missing Indexes current database by Index Advantage

– This DMV Query written by Glenn Berry

SELECT user_seeks * avg_total_user_cost *

      (avg_user_impact * 0.01) AS [index_advantage],

migs.last_user_seek,

mid.[statement] AS [Database.Schema.Table],

mid.equality_columns, mid.inequality_columns,

mid.included_columns,migs.unique_compiles, migs.user_seeks,

migs.avg_total_user_cost, migs.avg_user_impact

FROM sys.dm_db_missing_index_group_stats AS migs WITH (NOLOCK)

INNER JOIN sys.dm_db_missing_index_groups AS mig WITH (NOLOCK)

ON migs.group_handle = mig.index_group_handle

INNER JOIN sys.dm_db_missing_index_details AS mid WITH (NOLOCK)

ON mig.index_handle = mid.index_handle

WHERE mid.database_id = DB_ID()

      AND user_seeks * avg_total_user_cost *

      (avg_user_impact * 0.01) > 9000 – Set this to Whatever

)

SELECT ‘CREATE INDEX IX_’

            + SUBSTRING([Database.Schema.Table],

                              CHARINDEX(‘].[',[Database.Schema.Table],

                              CHARINDEX(‘].[',[Database.Schema.Table])+4)+3,

                              LEN([Database.Schema.Table]) - 

                              (CHARINDEX(‘].[',[Database.Schema.Table],

                              CHARINDEX(‘].[',[Database.Schema.Table])+4)+3))

            + ‘_’ + LEFT(REPLACE(REPLACE(REPLACE(REPLACE(

            ISNULL(Equality_Columns,inequality_columns),

            ‘[',''),']‘,”),‘ ‘,”),‘,’,”),20)

            + ‘ ON ‘

            + [Database.Schema.Table]

            + ‘(‘

            + ISNULL(equality_columns,”)

            + CASE WHEN equality_columns IS NOT NULL AND

                              inequality_columns IS NOT NULL

                  THEN ‘,’

                  ELSE ”

              END

            + ISNULL(inequality_columns,”)

            + ‘)’

            + CASE WHEN included_columns IS NOT NULL

                  THEN ‘ INCLUDE(‘ + included_columns + ‘)’

                  ELSE ”

              END CreateStatement,

            ‘IX_’

            + SUBSTRING([Database.Schema.Table],

                              CHARINDEX(‘].[',[Database.Schema.Table],

                              CHARINDEX(‘].[',[Database.Schema.Table])+4)+3,

                              LEN([Database.Schema.Table]) - 

                              (CHARINDEX(‘].[',[Database.Schema.Table],

                              CHARINDEX(‘].[',[Database.Schema.Table])+4)+3))

            + ‘_’ + LEFT(REPLACE(REPLACE(REPLACE(REPLACE(

            ISNULL(Equality_Columns,inequality_columns),

            ‘[',''),']‘,”),‘ ‘,”),‘,’,”),20)

                  IndexName

FROM I

I like babysitter reports.  What is a "babysitter" report?  It’s a report that you schedule to run on a recurring basis that checks things for you.  I call them babysitter reports because they can monitor things without you having to worry about it.  Every environment has different things that they need to look for.  Maybe a certain value found its way into a certain table and you need to take action because of it.  Maybe a certain query is on a rampage again and you need to kill it.  There are all kinds of things that you know you should keep an eye on that you don’t always remember to do.  Instead of putting that burden on your memory or calendar, these automated reports do the work for you.

Here I will show you how to create one simple babysitter report.  I intentionally chose one of the more complicated ones (CPU Threshold) to note how far it could be expanded upon, but more basic things would not require this level of customization.  Here are a few examples of things that you could create babysitter reports for:

• Long Running Queries
• Blocking SP’s
• Index fragmentation
• Log Size
• System Info
• Specific entries into tables

The sky is the limit.  The same strategies can be used to get information to your users when rare events occur that require immediate action if your system doesn’t already provide a means to get this information to them in a timely manner.  There are certain reports in my environment that can run for *days* if the wrong parameters are sent to them… and while ideally these would be fixed in other ways, it’s good to identify the situations that occur in the interim and take action until that can be accomplished.

Here are a few sample queries for finding queries with abnormally high CPU usage.   There are two basic parts to these.  The first is the data driven subscription.  You want this to be as streamlined as possible.  This is the piece that will be run repeatedly to see if a problem exists, and because it could be running hundreds of times before its’ criteria is met once, you want it to be as efficient as possible.

/*
  =============================================================================================
CREATE DATE:     04/12/2010
LAST MODIFIED:    04/12/2010
CREATED BY:        SETH PHELABAUM
PURPOSE:        Data Driven Subscription that monitors for queries using high CPU.
ISSUES:            Will Notify you Repeatedly.
Notes:            This can be expanded upon quite a bit.  For instance, you could also:                 Set up a Logging table / set of tables to control how often this notifies you (To stop you from getting multiple emails overnight)                 Set up a list of excluded sp's                 Set up a list of different actions depending on the time of day (You could also change the schedule in reporting services)                 Much more...
=============================================================================================
*/ 

CREATE PROCEDURE DDS_HighCPU
  AS 

SELECT DISTINCT spid, 'youremailaddress@yourdomain.com' Notify
  FROM sys.sysprocesses
WHERE [dbid] > 4 -- May Need to filter out additional Databases here for your setup     and cpu > 10000    -- Adjust to whatever you consider worth knowing about.     and cmd <> 'AWAITING COMMAND'  -- Don't want to be notified about these.     and spid IN (SELECT spid                  FROM sys.dm_exec_connections DMV_EC                  WHERE DMV_EC.last_read > DATEADD(mm,-2,GETDATE())                         OR DMV_EC.last_write > DATEADD(mm,-2,GETDATE())) -- Another filter to hopefully stop some excess emails

The second part is the actual report query.  This can be a bit more in depth and contain all kinds of information that helps you take action based on the event that transpired.

/*
  =============================================================================================
CREATE DATE:     04/12/2010
LAST MODIFIED:    04/12/2010
CREATED BY:        SETH PHELABAUM
PURPOSE:        Pulls information about queries that use a large amount of CPU
ISSUES:            Will Notify you Repeatedly.
Notes:            This can be expanded upon quite a bit.  For instance, you could also include:                 Trace events                 Blocked Processes                 system stats (current cpu usage/io etc.)                 Much more...
============================================================================================= 

*/
CREATE PROCEDURE Rpt_HighCPU(     @SPID            int
)
AS

DECLARE @sql_handle varbinary(64),         @stmt_start Int,         @stmt_end    Int,         @FNGS        nvarchar(max),         @DBIB        nvarchar(4000) 

SELECT top 1 @sql_handle = sql_handle, @stmt_start = stmt_start, @stmt_end = stmt_end from sys.sysprocesses (nolock)
  WHERE spid = @spid

ORDER BY sql_handle DESC --Or stmt_start DESC 

SELECT @FNGS = CASE WHEN @stmt_start > 0                 THEN SUBSTRING(text, (@stmt_start + 2)/2,                       CASE @stmt_end                         WHEN -1 THEN (datalength(text))                         ELSE (@stmt_end - @stmt_start +2)/2                       END)                 ELSE [Text]                 END               FROM ::fn_get_sql(@sql_handle) 

CREATE TABLE #B(eventtype nvarchar(30), parameters int, eventinfo nvarchar(4000))

 INSERT INTO #B(EventType, Parameters, EventInfo)
EXEC ('dbcc inputbuffer (' + @spid + ') with no_infomsgs') 

SELECT @DBIB = EventInfo FROM #B 

SELECT    TOP 1         @FNGS FNGS,         @DBIB DBIB,         cpu,         physical_io,         memusage,         status,         nt_username,         last_batch
from sys.sysprocesses

where spid = @SPID

ORDER BY sql_handle DESC

We also need something that will put a strain on the server to demonstrate the report in action, so I created this ridiculous little SP to run for a while.

/CREATEPROCEDURE dbo.SillyLongRun
  AS
exec dbo.SillyLongRun2
  GO 

/*
  =============================================================================================
CREATE DATE:     04/12/2010
LAST MODIFIED:    04/12/2010
CREATED BY:        SETH PHELABAUM
PURPOSE:        To run for a while.
ISSUES:            Totally Pointless
Notes:            Header here mainly to demonstrate the usage of stmt_start and stmt_end with fn_get_sql.                 This thing sucks up resources, so don't run it on a production box.
=============================================================================================
exec dbo.SillyLongRun2 

*/
  CREATE PROCEDURE dbo.SillyLongRun2

AS 

; WITH
  -- Tally table Gen            Tally Rows:         X2                        X3
t1 AS (SELECT 1 N UNION ALL SELECT 1 N),        -- 4                ,    8
t2 AS (SELECT 1 N FROM t1 x, t1 y),                -- 16                ,    64
t3 AS (SELECT 1 N FROM t2 x, t2 y),                -- 256                ,    4096
t4 AS (SELECT 1 N FROM t3 x, t3 y),                -- 65536            ,    16,777,216
t5 AS (SELECT 1 N FROM t4 x, t4 y),                -- 4,294,967,296    ,    A lot
Tally AS (SELECT CAST(ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) as bigint) N
FROM t5 x, t5 y) -- Change the t3's to one of the other numbers above for more/less rows 

SELECT N, CAST(N as varchar(30)), DATEADD(ms,n,0)
  FROM Tally

(You can call the above with exec dbo.SillyLongRun)

As mentioned in the headers, you would ideally keep a log of when you were notified about things.  Different alerts could be scheduled to have a different frequency.  Perhaps you only want to be notified about certain things once a week, but other things you want to be notified about once an hour until they are taken care of.  This is where a logging table comes in.  I won’t go into that here, but wanted to mention it.

Now that we have the queries, we need to set up the report.  I’m going to assume that you already have Reporting Services set up.  Here is a Screenshot of a very basic report that I created to pull in the data.

Once you deploy this report, there are a couple more things you need to do before you can create a data driven subscription for it.  The first is to set up a shared Schedule.  Log into your reports server (http://localhost/reports) and go to Site Settings at the top.  Then click on schedules at the left and New Schedule.  For this one I’m just going to create a basic 15m recurring schedule.

Next we need to modify the credentials of the shared data source used for the report.  My data source name for the report is SS2K8CL100.  To modify it, I go back to Home –> Data Sources –> SS2K8CL100.  The below screenshot shows me modifying it to use a windows account.

Now, we’re ready to create the data driven subscription.  Rather than explain it in text, I’ve taken screenshots of each step of creating a data driven subscription.

Click Finish and you have your report.

In closing, I’ll note that I had a lot of problems getting Reporting Services to function correctly on my windows 7 installation, so this isn’t as polished as I would have liked.  I didn’t get the email working and I forgot to include SPID anywhere on the report (pretty useful piece of information to have)

Differences

• fn_get_sql returns the last *statement* executed, where as DBCC INPUTBUFFER returns the first statement in the batch.  See the example below for a better idea of what that means.
• fn_get_sql returns a TEXT field containing the statement that ran, DBCC INPUTBUFFER returns only a varchar(255).  This is important as you often won’t get the full line here… and unfortunately there’s not a lot you can do about that.  To my knowledge, DBCC INPUTBUFFER is still your only means of getting the first statement in the batch, however it returns an nvarchar(4000) in 2005/2008.
• fn_get_sql requires a SQL_Handle binary type passed in which has to be pulled out of the sysprocesses table, DBCC INPUTBUFFER only requires the SPID as a parameter.
• fn_get_sql will return the actual creation text for an SP(or trigger, etc.) that is executing instead of all the name of the object with the parameters that DBCC INPUTBUFFER returns.

Note that fn_get_sql is available in SQL 2000 if you have sp3 and above.  You may actually have it with SP2 as well if you have the correct hotfix applied.  An easy way to tell if it will work on your system is to do a simple SELECT sql_handle FROM sysprocesses.  If that works, so will fn_get_sql.  If it doesn’t, you need to patch.   There are a couple other specifics about fn_get_sql that are mentioned in the article linked at the bottom by Andrew Novick.

Sample Code

Both of these often require insertion into a table to work with.  Here is some sample code that will create the tables for you and insert the rows of the currently running SPID.

Additional Links:

Andrew Novick: Find out what they’re doing with fn_get_sql
BOL: sys.dm_exec_sql_text
BOL: fn_get_sql
BOL: DBCC INPUTBUFFER: 2008 | 2005 | 2000

Examples:

Here are a couple examples that show some of the differences between the two in action.

What to do with this
Let’s say you have a table containing names of your favorite fruits.  (In case you were wondering… No, these aren’t my favorite fruits; they were just ones that immediately came to mind when writing this.  I don’t even like half of these.)

You then ask someone else what their favorite fruits are and want to see what fruits you have in common.  You might think you could just write a query for that like this:

However, this won’t work because in all these cases SQL is looking for a single fruit named : ‘Orange,Apple,Banana,Pear,Watermelon,Grape’ not any fruit in what is really a list.

A common solution for this is to use Dynamic SQL which would make your query this:

This works and will properly match up your fruits.

The above function allows you to accomplish your goal without Dynamic SQL with a query that looks like this:

You can also simply join to the table instead of using the IN keyword which gives you more flexibility in your query writing.

Note that because I wanted to keep the function somewhat simple, it does not handle extra spaces around the commas.  Single quotes within the string will also break it which limits its usage somewhat.  If this is a concern for your implementation, you either need to replace the single quotes on both sides or use a different method.  Despite the fact that the example above uses a list of strings, in real life situations I use this mainly for lists of uniqueidentifiers or numbers where single quotes/spaces are never an issue.

This isn’t a topic that I’m real familiar with, so I had to do some research / tests of my own to write this.  I’ve had to fix the varchar/nvarchar one several times, but others I can’t truly explain.  Why does a char->varchar comparison not trigger an implicit conversion?  Honestly, I’m not sure.  My guess would be that the optimizer is simply smart enough to not do it, but as I said, that’s just a guess.  While attempting to find the answer to this online, I stumbled across a brilliant script written by Jonathan Kehayias that focuses on finding implicit conversions in the plan cache.

The examples below focus on non-numeric conversions.  I did a good amount of testing on different numeric conversions, and although I’ve read that SQL 2000 had specific issues, I was not able to easily duplicate this with the numeric types in any compatibility level with my 2K8 installation (so I left those examples out).  If anyone has any good examples of this behavior with numeric data types, I’d be happy to add them.

Test Setup: (Note that because I am dropping/creating a real table and user defined types, you should be careful which database you execute this against.  I would suggest creating a new one and executing it there)

Tests:

[/cc_sql]– Test 4:  Compare varchar and sql_variant against varchar column.
– Here you get the massive difference you would expect because you must convert the entire column to a sql_variant.
– This one actually has a different plan all together and not just an index scan.
DECLARE @a sql_variant
SET @a = ‘A’
SELECT VCCol FROM DTP WHERE VCCol = ‘A’
SELECT VCCol FROM DTP WHERE VCCol =  @a[/cc_sql]

The varchar/nvarchar conversions can be especially painful / tricky when the code is being passed in from elsewhere.  One of the places that I’ve seen issues with this is LINQ to SQL.  It is entirely possible that it was just our setup that was mismatched (I wasn’t involved in that end of it), but I figured I’d throw it out there anyways.

• ISNULL can accept only two arguments where as COALESCE can accept any number of input parameters
• ISNULL is not ANSI standard and is proprietary to TSQL.
• With ISNULL, the datatype of the second argument is converted to equal the data type of the first argument where as COALESCE converts according to data type precedence. 
• ISNULL is generally accepted to be faster than COALESCE.
• COALESCE is a much cooler word and will usually earn you either an impressed glance or a blank confused stare when slipped into casual conversation. 

Here are a few examples that demonstrate some of the functional differences between the two conversion methods.

declare @a varchar(5)
select ISNULL(@a, 'ISNULL Test 1')        -- Result: ISNUL
SELECT COALESCE(@a, 'COALESCE Test 1')    -- Result: COALESCE Test 1

declare @b tinyint
SELECT ISNULL(@b, 99999)                -- Result: **Error**
SELECT COALESCE(@b, 99999)                -- Result: 9999

declare @c char(5)
SELECT ISNULL(@c, 'a') + 'B'            -- Result: a    B
SELECT COALESCE(@c, 'a') + 'B'            -- Result: aB

They aren’t completely dissimilar; they behave exactly as you would expect them to… with the exception of NULL’s.  Because nothing EQUALS NULL (Dependent upon settings, see below) the difference in the internal logic matters.  Gail Shaw initially explained this to me when I asked the question on the forums and I wanted to use her explanation here, but I can’t seem to find it; so here’s my own version of an explanation:

When you use IN, you’re really saying "WHERE myvalue = ‘A’ OR myvalue = ‘B’ OR myvalue = NULL"
Your NULLS won’t cause the entire statement to fail because it’s only an OR.

When you use NOT IN you’re really saying ‘WHERE myvalue <> ‘A’ AND myvalue <> ‘B’ AND myvalue <> NULL “
This is where the problem arises.  Since a NULL in SQL is an unknown value, you can’t test = or <> on it and you get no results.  Without the NULL, you’d be fine.

Here’s a simple example to demonstrate.

DECLARE @T TABLE(
Val varchar(5)) 

DECLARE @T2 TABLE(
Val varchar(5)) 

INSERT INTO @T(Val)
SELECT 'A' UNION ALL SELECT 'B' UNION ALL SELECT 'C' UNION ALL
SELECT 'D' UNION ALL SELECT 'E' UNION ALL SELECT 'F' 

INSERT INTO @T2(Val)
SELECT 'A' UNION ALL SELECT 'B' UNION ALL SELECT 'C' UNION ALL
SELECT NULL 

SET ANSI_NULLS ON
SELECT * FROM @T WHERE Val IN (SELECT * FROM @T2)
SELECT * FROM @T WHERE Val NOT IN (SELECT * FROM @T2)
SELECT * FROM @T WHERE Val NOT IN (SELECT * FROM @T2 WHERE Val IS NOT NULL) 

This issue is further complicated by the ANSI_NULLS setting.  While I believe most people have this turned ON, the fact that it is an option introduces another variable into the mix.  NOT IN will not fail in the same way if you have ANSI_NULLS set to OFF.  (Try the above example again after changing ON to OFF)