Search results matching tags 'SQL Server 11', 'denali', and 'SQL Server 2011'

Connect Digest : 2011-05-02

AaronBertrand — Mon, 02 May 2011 11:15:00 GMT

This week, after seeing a lot of the DMV enhancements made in SQL Server 2008 R2 SP1, I thought I would take a look at some dynamic management view/function requests.

Page split personality

Michael Zilberstein blogged on Monday about how Extended Events and the transaction log differ in the way they report page split information, and that it would be useful to have accurate information about these events available in the DMVs. So he filed this Connect item:
#664900 : Please add page splits data per index, index level and page split type
I asked for a very similar item back in 2008, but thought that it belonged in sys.dm_db_index_physical_stats:
#388403 : Include page split information in sys.dm_db_index_physical_stats
They've already provided additional info via Extended Events (see #388482 : SQL Server Extended Events Page/Split Event Additions) so, hopefully, they will take our DMV requests seriously as well.

How stale is my database?

Kimberly Tripp (blog | twitter) posted this item, asking for a column in sys.databases to reflect last accessed time (I think it belongs in an existing or new DMV, not in the catalog view). An additional comment on the item suggested a terrific enhancement to this potential feature, where each individual login would be represented with their last access time, making it easy to differentiate when a database is only being accessed by system or background processes.
#659846 : Database last accessed time
They've recently rejected a similar item requesting last accessed time for objects within a database (see #454714 : I should be able to see the last time an object was accessed in sysobjects), though that one had zero votes, so I'm hopeful that Kimberly's request may be deemed both easier to implement and more important to the community.

I'm an E7-8800, what are you?

Glenn Alan Berry (blog | twitter) asked for an additional column on the sys.dm_os_sys_info DMV that reflects the CPU's description (e.g. Xeon X5505). As you may have noticed on his blog, Glenn spends a lot of effort on analyzing performance of workloads on different CPUs, and there are some pretty substantial differences between CPUs that may look quite similar to the average person - especially when seeing vastly different performance on two servers that are otherwise very similar (same amount of RAM, same SAN, etc).
#657435 : Add a processor_description column to sys.dm_os_sys_info in SQL Server Denali
An additional comment requested that the true observed speed would be shown, as opposed (or in addition) to the manufacturer's stated clock speed - the true speed is a number than can vary greatly if you are using power saving options.

You're a word, but are you reserved?

This almost certainly wouldn't be in a DMV, but I still like the idea and it almost fits here. Greg Low (blog | twitter) is requesting a system view of some kind that exposes a list of reserved words - my comment here was that relying on IntelliSense alone is a fool's errand.
#653455 : System View that lists Reserved Words
On a somewhat-but-not-really-related note, Meredith Ryan-Smith (blog | twitter) recently blogged about a workaround she used to export all of the object names from sys.all_objects into a custom dictionary for use in Word, PowerPoint, etc. to avoid the ugly red squiggly lines pointing out that you misspelled sp_server_diagnostics and sp_who2. I think that if the metadata Greg is asking for were made available, then this idea would be easy to extend to reserved words, so that Word also wouldn't try to convince you that perfectly valid "words" like COLUMNSTORE and DATA_COMPRESSION are spelled wrong.

Do you really like DBCC?

Greg Low also requested that the information returned by running DBCC SHOW_STATISTICS be made available through a DMV (another user suggested adding a column like is_stale to sys.stats, but I think a separate DMV makes more sense).
#611155 : DBCC SHOW_STATISTICS info should be available as a DMV
Exposing this information in a DMV would also, presumably, make it easier to access information like STATS_DATE without having to be in the context of that database (see #654972 : STATS_DATE only works as documented when current db is where the tables are).

SQL Bits 8: "What's New in SQL Server Denali?"

AaronBertrand — Sat, 09 Apr 2011 23:25:00 GMT

At SQL Bits I presented my "What's New in Denali?" deck in two different sessions - once on Friday to about 120 people, and once on Saturday to about 80 people. You can download the deck and samples below.

SQL Saturday #67, Chicago: "What's New in SQL Server Denali"

AaronBertrand — Sat, 26 Mar 2011 15:01:00 GMT

Today I was in Chicago for SQL Saturday #67 to present my "What's New in SQL Server Denali" deck. You can download the deck and samples below.

I mentioned during the talk that THROW is another command added to the list that require the previous statement to be terminated with a semi-colon. Here is the blog post I referenced that talked more about why you should start using semi-colons today.

I liked the feedback mechanism at this event. Everyone was handed an evaluation, and the drawings took place after each session at the chapter table downstairs. Much more compelling to get your evals in right away, and even better, I get them back right after that. Which means I can tally my scores and see what went well, and more importantly, what didn't go well (and wasn't obvious). The evals were much simpler than some other events. Two basic questions and room for comments (not everyone left comments, and not everyone answered both questions):

Expectation (circle one): Did Not Meet / Met / Exceeded

Met: 23 / 34
Exceeded: 11 / 34

Overall quality (5 = great):

3: 4 / 32
4: 11 / 32
5: 17 / 32
Average: 4.41

Not top scores, no, but I still feel pretty good about this. What I liked most? Seven comments included one of my brand words, "knowledgeable." Well, a couple used the variation "knowledge" - but that counts, right?

The comment that surprised me most was a complaint that I didn't cover any BI. Even though I stated multiple times at the beginning that I wouldn't be covering BI - and even dedicated my very first "real" slide to this fact. Still, I've taken the feedback. For future events I'm going to change the title of the session to "SQL Server Denali : What's New in Engine, Setup and Tools."

I also gave a quick demo of SQL Sentry Plan Explorer in our vendor session at lunch (we were a "You Rock!" sponsor of SQL Saturday #67, after all). I didn't use a deck and it was all demos. Plan Explorer is free; if you haven't already tried it, please go to the download page and read my previous blog posts about the tool.

Presenting "What's New in SQL Server Denali" for WVPASS

AaronBertrand — Thu, 17 Mar 2011 21:00:00 GMT

Recently I was asked by John Sterrett (blog | twitter) to present to his SQL Server user group (WVPASS) in Wheeling, West Virginia. Well, today is the day, and I will be presenting, "What's new in SQL Server Denali" at tonight's meeting, sponsored by SQL Sentry. The slide deck is attached below; the samples are available here.

If you attended this presentation, please feel free to provide feedback at SpeakerRate.

SQL Server v.Next ("Denali") : How a columnstore index is not like a normal index

AaronBertrand — Mon, 28 Feb 2011 17:34:00 GMT

At the end of my Denali presentation at SQL Saturday #65 in Vancouver, a member of the audience asked, "What makes a columnstore index different from a regular nonclustered index?" At the end of a busy day, I was at a loss for an answer, and I'll explain why.

First, I'll briefly explain the basic, core, high-level functionality of a columnstore index (you can read a lot more details in this white paper). Basically, instead of storing index data together on a page, it divvies up the data from each column into its own set of pages. If you are after the data from only one column, this doesn't provide a great advantage over a traditional index, since you're not going to be able to store that many more rows on a page.

The reason I was having a hard time articulating the benefit is because I was thinking about a simple non-clustered index with one column, and comparing it to a columnstore index with only one column defined. The benefit of the columnstore index is that you can basically declare it against most or all of the columns in a table, effectively similar to creating an index on each column - and this is where column store indexes provide the largest benefit. The differences between a column store index and a handful of indexes for each column are (1) size due to the structure of the index and the fact that compression will likely work much better when you can fit more like values on a page, and (2) you only pay for the index maintenance on a columnstore index once, because of what I'll describe next.

The columnstore index has limitations that definitely make you feel like the grass is greener on the other side. Most importantly, in Denali, due to the cost of maintenance, a columnstore index will be read only... essentially, you will need to rebuild the index when data changes. Some other limitations: only one columnstore index per table, the index must be partition-aligned, can't be filtered, and the base object must be a table (so, no indexed views).

This feature is definitely geared to data warehouse scenarios, or where you are free to rebuild indexes nightly or on some other interval. I can't give you a good idea about the cost of maintaining this index manually compared to multiple traditional indexes, since the feature did not make the cut for the publicly available CTP1. But I hope to publish some blog posts with real numbers on both the read and write sides when the next public CTP is made available. I am fairly certain I will be able to demonstrate cases where this type of index will drastically increase read performance (without losing substantial write performance), provided that you are in a scenario where you can update the data on an infrequent schedule, such as nightly.

If you want some detailed background on this technology, please check out Dr. David DeWitt's PASS Summit 2009 keynote slide deck. And if you’re a PASS member, you can access the video at sqlpass.org (login required).

[I am currently at the MVP Summit, and I just want to clarify (in case anyone was wondering), none of the material I discuss above is in violation of NDA.]

Slides and samples from SQL Saturday #65 - Vancouver

AaronBertrand — Sun, 27 Feb 2011 00:53:00 GMT

Today I presented my "What's New in SQL Server 'Denali'" deck to about 40 attendees at SQL Saturday #65 in Vancouver, British Columbia. Attached below (and here) are the slightly updated slides and samples.

Slide decks and samples from SQL Saturday #60 - Cleveland

AaronBertrand — Sat, 05 Feb 2011 22:34:00 GMT

Attached are the slide decks and demos from my two presentations at SQL Saturday #60 in Cleveland:

SQL Server v.Next (Denali) : Changes to performance counters

AaronBertrand — Sat, 08 Jan 2011 17:44:00 GMT

In a previous post about changed system objects in Denali, I talked about the changes to memory-related DMVs due to underlying changes in the memory manager. The SQLOS team has posted a great introduction to these changes, and they plan to post more details in future posts. In the meantime, and due to a question yesterday from Tom LaRock (blog | twitter) ...

... I thought I would tell you about some performance counters that have changed between SQL Server 2008 R2 and Denali - most of which involve these memory manager changes. In response to Tom, initially I just performed a count and compared, but this isn't very accurate; since many counters are database-specific, the counts depend greatly on how many databases you have installed (as well as edition and features - more on that below). So instead I wanted to query and see the actual differences ... on a 2008 R2 instance, I created a linked server pointing to a Denali instance, then I ran this query:

;WITH loc AS
(
   SELECT obj, cn
   FROM 
   (
       SELECT
           obj = SUBSTRING([object_name], CHARINDEX(':', [object_name]) + 1, 256), 
           cn = counter_name
       FROM sys.dm_os_performance_counters
   ) AS x
   GROUP BY obj, cn
),
rem AS 
(
   SELECT obj, cn
   FROM 
   (
       SELECT
           obj = SUBSTRING([object_name], CHARINDEX(':', [object_name]) + 1, 256), 
           cn = counter_name
       FROM [Denali_Linked_Server].[master].sys.dm_os_performance_counters
   ) AS x
   GROUP BY obj, cn
)
SELECT 
   [2008R2_obj] = loc.obj, 
   [2008R2_ctr] = loc.cn,
   [Denali_obj] = rem.obj,
   [Denali_ctr] = rem.cn
FROM
   loc 
FULL OUTER JOIN
   rem 
   ON loc.obj = rem.obj
   AND loc.cn = rem.cn
WHERE 
   loc.obj    IS NULL
   OR rem.obj IS NULL
ORDER BY
   [Denali_obj],
   [Denali_ctr],
   [2008R2_obj], 
   [2008R2_ctr];

The results:

2008 R2 Object 2008 R2 Counter Denali Object Denali Counter

Buffer Manager AWE lookup maps/sec <removed in Denali>

Buffer Manager AWE stolen maps/sec <removed in Denali>

Buffer Manager AWE unmap calls/sec <removed in Denali>

Buffer Manager AWE unmap pages/sec <removed in Denali>

Buffer Manager AWE write maps/sec <removed in Denali>

Buffer Manager Free pages <removed in Denali>

Buffer Manager Reserved pages <removed in Denali>

Buffer Manager Stolen pages <removed in Denali>

Buffer Manager Target pages <removed in Denali>

Buffer Manager Total pages <removed in Denali>

Buffer Node Foreign pages <removed in Denali>

Buffer Node Free pages <removed in Denali>

Buffer Node Stolen pages <removed in Denali>

Buffer Node Target pages <removed in Denali>

Buffer Node Total pages <removed in Denali>

Buffer Partition Free list empty/sec <removed in Denali>

Buffer Partition Free list requests/sec <removed in Denali>

Buffer Partition Free pages <removed in Denali>

<new in Denali> Access Methods InSysXact waits/sec

<new in Denali> Availability Replica Bytes Received from Replica/sec

<new in Denali> Availability Replica Bytes Sent to Replica/sec

<new in Denali> Availability Replica Bytes Sent to Transport/sec

<new in Denali> Availability Replica Flow Control Time (ms/sec)

<new in Denali> Availability Replica Flow Control/sec

<new in Denali> Availability Replica Receives from Replica/sec

<new in Denali> Availability Replica Resent Messages/sec

<new in Denali> Availability Replica Sends to Replica/sec

<new in Denali> Availability Replica Sends to Transport/sec

<new in Denali> Database Replica File Bytes Received/sec

<new in Denali> Database Replica Log Bytes Received/sec

<new in Denali> Database Replica Log Send Queue

<new in Denali> Database Replica Recovery Queue

<new in Denali> Database Replica Redone Bytes/sec

<new in Denali> Databases Log Flush Write Time (ms)

<new in Denali> Memory Manager Database Cache Memory (KB)

<new in Denali> Memory Manager Free Memory (KB)

<new in Denali> Memory Manager Log Pool Memory (KB)

<new in Denali> Memory Manager Reserved Server Memory (KB)

<new in Denali> Memory Manager Stolen Server Memory (KB)

<new in Denali> Memory Node Database Node Memory (KB)

<new in Denali> Memory Node Foreign Node Memory (KB)

<new in Denali> Memory Node Free Node Memory (KB)

<new in Denali> Memory Node Stolen Node Memory (KB)

<new in Denali> Memory Node Target Node Memory (KB)

<new in Denali> Memory Node Total Node Memory (KB)

2008 R2 Object	2008 R2 Counter	Denali Object	Denali Counter
Buffer Manager	AWE lookup maps/sec	<removed in Denali>
Buffer Manager	AWE stolen maps/sec	<removed in Denali>
Buffer Manager	AWE unmap calls/sec	<removed in Denali>
Buffer Manager	AWE unmap pages/sec	<removed in Denali>
Buffer Manager	AWE write maps/sec	<removed in Denali>
Buffer Manager	Free pages	<removed in Denali>
Buffer Manager	Reserved pages	<removed in Denali>
Buffer Manager	Stolen pages	<removed in Denali>
Buffer Manager	Target pages	<removed in Denali>
Buffer Manager	Total pages	<removed in Denali>
Buffer Node	Foreign pages	<removed in Denali>
Buffer Node	Free pages	<removed in Denali>
Buffer Node	Stolen pages	<removed in Denali>
Buffer Node	Target pages	<removed in Denali>
Buffer Node	Total pages	<removed in Denali>
Buffer Partition	Free list empty/sec	<removed in Denali>
Buffer Partition	Free list requests/sec	<removed in Denali>
Buffer Partition	Free pages	<removed in Denali>
<new in Denali>	Access Methods	InSysXact waits/sec
<new in Denali>	Availability Replica	Bytes Received from Replica/sec
<new in Denali>	Availability Replica	Bytes Sent to Replica/sec
<new in Denali>	Availability Replica	Bytes Sent to Transport/sec
<new in Denali>	Availability Replica	Flow Control Time (ms/sec)
<new in Denali>	Availability Replica	Flow Control/sec
<new in Denali>	Availability Replica	Receives from Replica/sec
<new in Denali>	Availability Replica	Resent Messages/sec
<new in Denali>	Availability Replica	Sends to Replica/sec
<new in Denali>	Availability Replica	Sends to Transport/sec
<new in Denali>	Database Replica	File Bytes Received/sec
<new in Denali>	Database Replica	Log Bytes Received/sec
<new in Denali>	Database Replica	Log Send Queue
<new in Denali>	Database Replica	Recovery Queue
<new in Denali>	Database Replica	Redone Bytes/sec
<new in Denali>	Databases	Log Flush Write Time (ms)
<new in Denali>	Memory Manager	Database Cache Memory (KB)
<new in Denali>	Memory Manager	Free Memory (KB)
<new in Denali>	Memory Manager	Log Pool Memory (KB)
<new in Denali>	Memory Manager	Reserved Server Memory (KB)
<new in Denali>	Memory Manager	Stolen Server Memory (KB)
<new in Denali>	Memory Node	Database Node Memory (KB)
<new in Denali>	Memory Node	Foreign Node Memory (KB)
<new in Denali>	Memory Node	Free Node Memory (KB)
<new in Denali>	Memory Node	Stolen Node Memory (KB)
<new in Denali>	Memory Node	Target Node Memory (KB)
<new in Denali>	Memory Node	Total Node Memory (KB)

You can see that several AWE-related counters have been removed, since AWE is no longer supported in Denali (this means if you are on 32-bit hardware and have > 4GB of RAM, you may as well start shopping for new hardware if you plan to be an early adopter). You'll also notice several Buffer Manager/Node/Partition objects are gone in Denali, replaced by Memory Manager/Node objects (and now measured in KB as opposed to pages). Some of these are described here. There are also some new replica counters based on the new availability and HA/DR features in Denali (described here and here). The new Log Flush Write Time (ms) counter is described in this BOL topic: SQL Server, Databases Object. I can't find any information about the InSysXact waits/sec counter; hopefully the documentation will catch up by RTM (or, ideally, by the next CTP).

So, if you're currently monitoring any of these performance counters in 2008 R2 or previous versions, take note that not only are they changing in Denali, but also that their values can mean something different.

Now keep in mind that this does not address changes to performance counters that are only present when certain features are enabled, such as database mirroring and replication. I will try to re-run these tests when I have a suitable environment with as many features enabled as possible.

SQL Server v.Next (Denali) : Metadata enhancements

AaronBertrand — Mon, 20 Dec 2010 15:09:00 GMT

In my previous job, we had several cases where schema changes or incorrect developer assumptions in the middle tier or application logic would lead to type mismatches. We would have a stored procedure that returns a BIT column, but then change the procedure to have something like CASE WHEN <condition> THEN 1 ELSE 0 END. In this case SQL Server would return an INT as a catch-all, and if .NET was expecting a boolean, BOOM. Wouldn't it be nice if the application could check the result set of the stored procedure, and construct its data types using that information? Another case would be where the schema has changed, but the applications can't all be updated at once. Wouldn't it be great to be able to tell SQL Server what the column name should be, what data type you want, or in what collation, as part of the stored procedure call? How often have you cursed the bizarre behavior of SET FMTONLY ON? And finally, how many times have you been frustrated by the output of sp_who2, which returns SPID twice - and worse yet, as a CHAR(5) column instead of an INT?

You can deal with each of these scenarios with some new procedures and dynamic management functions introduced in Denali. We will have new functionality to either discover or control the metadata of queries, without actually having to run them, store temporary results elsewhere, or use SET FMTONLY ON.

Some examples

Inspect output of queries without piecing together catalog views

Picture a very simple table like this:
CREATE TABLE dbo.x
(
    foo     INT NOT NULL,
    bar     DECIMAL(12, 2),
    blat    VARCHAR(20),
    mort    NVARCHAR(32),
    splunge NVARCHAR(MAX),
    whence  DATETIME2(4) NOT NULL
);
And then a query like this:
SELECT * FROM dbo.x;
Today, if I want the application to understand the data types that are coming back from this query, I would have to create queries against the catalog views sys.columns and sys.types, for example:
SELECT 
    c.name, 
    t.name, 
    c.max_length, 
    c.[precision], 
    c.scale, 
    c.is_nullable
FROM 
    sys.columns AS c
INNER JOIN 
    sys.types AS t
    ON c.system_type_id = t.system_type_id
    AND c.user_type_id  = t.user_type_id
WHERE 
    c.[object_id] = OBJECT_ID('dbo.x')
ORDER BY
    c.column_id;
Results:

This leaves some serious gaps, since I have to perform all kinds of manipulations to put these outputs into true data type definitions. For example, I have to check max_length for -1 and switch it to MAX, I have to check for nchar/nvarchar and cut max_length in half, and I have to piece together the precision and scale for *some* numeric- and date-based types.

There is a new dynamic management function in Denali, sys.dm_exec_describe_first_result_set, which will take a query and produce a much more concise description of the data types coming back in the query. While the function returns other columns, I'll focus on the ones that are most useful for describing resultsets and creating new tables based on them.
SELECT 
    name, 
    system_type_name, 
    is_nullable
FROM 
    sys.dm_exec_describe_first_result_set
    (
        N'SELECT * FROM dbo.x;', NULL, 0
    ) AS f
ORDER BY
    column_ordinal;
Results:

Clearly this is a lot less work and manipulation to get the data types consistent - all of the "compound" data types come back exactly as you need to define them. So let's imagine you want to generate CREATE TABLE scripts to store the data from a bunch of DMVs or your own views or other queries; again, you can do this without writing very complex queries against the catalog views or with piecing together the data types manually. A very simple example that generates a CREATE TABLE statement to store the data from sys.dm_exec_sessions in your own repository table:
SET NOCOUNT ON;

DECLARE @sql NVARCHAR(MAX);
SET @sql = N'SELECT * FROM sys.dm_exec_sessions;';

SELECT 'CREATE TABLE dbo.SessionsDMV(';

SELECT 
    CASE column_ordinal 
        WHEN 1 THEN '' ELSE ',' END 
        + name + ' ' + system_type_name + CASE is_nullable 
        WHEN 0 THEN ' not null' ELSE '' END
FROM 
    sys.dm_exec_describe_first_result_set
    (
        @sql, NULL, 0
    ) AS f
ORDER BY
    column_ordinal;

SELECT ');';
The results (not exactly how I would want them formatted, but you can play with the query above so the code conforms better to your standards):
-----------------------------
CREATE TABLE dbo.SessionsDMV(

------------------------------------------------------------------
session_id smallint not null
,login_time datetime not null
,host_name nvarchar(128)
,program_name nvarchar(128)
,host_process_id int
,client_version int
,client_interface_name nvarchar(32)
,security_id varbinary(85) not null
,login_name nvarchar(128) not null
,nt_domain nvarchar(128)
,nt_user_name nvarchar(128)
,status nvarchar(30) not null
,context_info varbinary(128)
,cpu_time int not null
,memory_usage int not null
,total_scheduled_time int not null
,total_elapsed_time int not null
,endpoint_id int not null
,last_request_start_time datetime not null
,last_request_end_time datetime
,reads bigint not null
,writes bigint not null
,logical_reads bigint not null
,is_user_process bit not null
,text_size int not null
,language nvarchar(128)
,date_format nvarchar(3)
,date_first smallint not null
,quoted_identifier bit not null
,arithabort bit not null
,ansi_null_dflt_on bit not null
,ansi_defaults bit not null
,ansi_warnings bit not null
,ansi_padding bit not null
,ansi_nulls bit not null
,concat_null_yields_null bit not null
,transaction_isolation_level smallint not null
,lock_timeout int not null
,deadlock_priority int not null
,row_count bigint not null
,prev_error int not null
,original_security_id varbinary(85) not null
,original_login_name nvarchar(128) not null
,last_successful_logon datetime
,last_unsuccessful_logon datetime
,unsuccessful_logons bigint
,group_id int not null
,authenticating_database_id int

----
);
Now, you can copy the entire result from the messages pane, and run it to create a table that will accept an INSERT statement like "INSERT dbo.SessionsDMV SELECT * FROM sys.dm_exec_sessions;"

I'll leave it as an exercise to the reader to try this out against different values of @sql.

Best guess at undeclared parameters

There is also a new stored procedure that will allow you to inspect a T-SQL batch and determine the data types of any undeclared parameters. As an example, what are the data types of the variables that will ultimately be passed into this query text? (This is often something an application developer will have to determine in order to program around these queries.)
SELECT * FROM sys.objects 
        WHERE [object_id] = @ObjectID
        OR (name LIKE @ObjectName);
On first glance, most of us will know that the first parameter, @ObjectID, should be declared as an INT, and the second parameter is likely going to be an NVARCHAR(4000). However there is now way for the system to tell us these exact answers with a lot less uncertainty:
EXEC sys.sp_describe_undeclared_parameters
    @tsql = N'SELECT * FROM sys.objects 
        WHERE [object_id] = @ObjectID
        OR (name LIKE @ObjectName);';
Partial results:

This returns a lot of other columns as well, but even the above should show how the stored procedure will be able to examine large and complicated T-SQL batches and describe all of the parameters that are used. Now, I say "best guess" because the parameter inspection is not perfect - but for most cases it is pretty spot on.

Convert data types explicitly

In this example I am showing a simple stored procedure. If we have two applications that call this stored procedure, we can call the procedure with two different WITH RESULT SETS options in order to return the data differently for the applications, allowing us to slowly change schema across our applications instead of changing them all at once. Imagine the following batch where the first column name is changing from 'Email' to 'Username' (the system no longer requires an e-mail address as the user identifier) and the second column, 'Status,' is changing from an INT to a BIT. The current procedure looks like this:
CREATE PROCEDURE dbo.Users_GetActiveList
AS
BEGIN
    SET NOCOUNT ON;

    SELECT
        Username,
        [Status] = CASE WHEN IsActive = 1 THEN 1 ELSE 0 END
    FROM dbo.Users
    ORDER BY Username;
END
GO
As we prepare for the schema changes, we could change the code above to just say:
CREATE PROCEDURE dbo.Users_GetActiveList
AS
BEGIN
    SET NOCOUNT ON;

    SELECT
        Email = Username,
        [Status] = CONVERT(BIT, CASE
            WHEN IsActive = 1 <and other conditions> THEN 1
            ELSE 0 END)
    FROM dbo.Users
    ORDER BY Email;
END
GO
But of course unless we update all of our apps at the same time, this change will break at least one of them. Instead, we can use WITH RESULT SETS to change the shape of the resultset conditionally. From the application where we can change the app immediately to use the new column names, we can say:
EXECUTE dbo.Users_GetActiveList
WITH RESULT SETS
(
    (
        Email VARCHAR(320),
        [Status] BIT
    )
);
In the results, you can't really tell from the screen shot whether Status is a BIT or an INT, but you can certainly see that the Username column has been changed to Email without changing the stored procedure and without having to change all of the consuming apps at once:

The old application can remain unchanged, and continue calling the stored procedure in the default manner - it will still see the Username column, and it will still get Status back as an Int32 instead of a Boolean (we are talking .Net data types here, not SQL). If there really are only two applications, then the WITH RESULT SETS code can be removed from the first application when the schema has changed and the second application has been updated. Otherwise, each app can make use of WITH RESULT SETS until they are all synchronized. At my previous job, I could have used this technique in many scenarios.

Fix output of system stored procedures

Every time I run sp_who2, I cringe. There are two SPID columns for some reason, and both are CHAR(5). Arguably, these could be made SMALLINT, but I think INT plays better with the .NET layer in most cases. There is also a column called BlkBy, which - unlike the rest of the columns - has a name which is unnecessarily truncated. I'll leave this as a CHAR(5) because I know the "." result is appreciated by a lot of people (it lets the true numeric values stand out better than 0 or NULL would). That all said, here is an example of using WITH RESULT SETS to make the output more consumable:
EXECUTE [master]..sp_who2
WITH RESULT SETS
(
    (
        [SPID]         INT,          -- <-- fixed the data type
        [Status]       NVARCHAR(32),
        [Login]        SYSNAME,
        HostName       SYSNAME,
        Blocker        CHAR(5),      -- <-- renamed this column
        [Database]     SYSNAME,
        Command        NVARCHAR(32),
        CPUTime        VARCHAR(30),
        DiskIO         VARCHAR(30),
        LastBatch      VARCHAR(48),
        ProgramName    NVARCHAR(255),
        Redundant_SPID INT,          -- <-- renamed this column
        RequestID      INT
    )
);
Make more usable output in Management Studio

In Denali there is a new system stored procedure called sys.sp_server_diagnostics, which returns some core system health metrics in XML format. Unfortunately, the implementation returns this data as string rather than XML data, which means the output is pretty useless in Management Studio - you either have to expand the result column and scroll horizontally forever in results to grid mode, or do all kinds of juggling to figure out where each row ends in results to text mode. (I complained about this in Connect #625262, but they didn't seem to agree with my reasoning - though I'm curious what other data type they think the output may change to in the future.) In order to make the output more useful, we can do the following to convert the last column to XML, making it clickable within SSMS grid results:
EXECUTE sys.sp_server_diagnostics
WITH RESULT SETS
(
    (
        create_time    DATETIME,
        component_name VARCHAR(20),
        [state]        INT,
        state_desc     VARCHAR(20),
        data           XML
    )
);
In the results, we can now click on the data column in any row, and it will open a new XML document that is much easier to read and parse:

Changing the output collation

This one is late to the party but since publishing I felt this nagging feeling that the article was incomplete. I can't think of an obvious and practical use for this off the top of my head, as thankfully I have not been exposed to too many collation issues over the years. But if a query is outputting a column in a certain collation, you can override that collation using WITH RESULT SETS. Here is an example that changes Albanian_BIN to Albanian_100_BIN, and I pass this batch to the DMV just to show that the output collation is obeyed:
DECLARE @sql NVARCHAR(MAX);

SET @sql = N'EXEC(''SELECT N''''foo'''' COLLATE Albanian_BIN'')
  WITH RESULT SETS
  (
    (
      foo NVARCHAR(32) COLLATE Albanian_100_BIN
    )
  );';

SELECT name, collation_name
    FROM sys.dm_exec_describe_first_result_set
    (
        @sql, NULL, 0
    );
Results:

Easier translation in SSIS

Finally, here is a blog post from fellow MVP James Rowland-Jones, where he demonstrates how EXECUTE ... WITH RESULT SETS can be very handy in SSIS:

Denali - Using EXECUTE WITH RESULT SETS (example using SSIS Source Adaptors)

Caveats

The DMVs and stored procedures for describing result sets are currently written to only inspect the *first* result set. So for something like sp_help, it will only assist in determining the very first set of output. I suspect they will correct this in the future, and am thankful they named the objects in an unambiguous way.

In addition, there are certain types of batches that will simply return an error when you try to examine them. For example, while a batch with a table variable can be passed to sys.sp_describe_first_result_set, a batch with a temp table cannot:

EXEC sys.sp_describe_first_result_set 
    @tsql = N'CREATE TABLE #y (j INT);SELECT j FROM #y;';

Results:

Msg 11525, Level 16, State 1, Procedure sp_describe_first_result_set, Line 1
The metadata could not be determined because statement 'SELECT j FROM #y;' uses a temp table.

WITH RESULT SETS requires a double-nesting of parentheses. If you try the following:

EXECUTE ('SELECT foo = N''bar'';')
WITH RESULT SETS
(
-- (
    foo NVARCHAR(3)
-- )
);

Results:

Msg 102, Level 15, State 1, Line 4
Incorrect syntax near 'foo'.

To get around this, you will need to un-comment the commented parentheses. The reason is that WITH RESULT SETS is plural; you can dictate the shape of multiple result sets, as demonstrated above.

Also note that you can't use WITH RESULTS to add or remove columns from the output; you can only mess with the column names, data types, nullability and collation. So for example, if you try to eliminate columns from the result set as follows:

EXECUTE ('SELECT foo = N''bar'', x = 1;')
WITH RESULT SETS
(
    (foo NVARCHAR(3))
);

Results:

Msg 11537, Level 16, State 1, Line 1
EXECUTE statement failed because its WITH RESULT SETS clause specified 1 column(s) for result set number 1, but the statement sent 2 column(s) at run time.

And if you try to convert to an incompatible data type, it will fail at runtime. For example, the following code will compile, but if you run it:

EXECUTE ('SELECT foo = N''bar'';')
WITH RESULT SETS
(
    (foo INT)
);

Results:

Msg 8114, Level 16, State 2, Line 1
Error converting data type varchar to int.

There are many other limitations and caveats to using these metadata enhancements; if you can see usefulness in some of these capabilities, I strongly recommend reviewing the official documentation and playing with the features for yourself.

Official links

Here are links to the official documentation about these new features:

sys.sp_describe_first_result_set
http://msdn.microsoft.com/en-us/library/ff878602(SQL.110).aspx

sys.sp_describe_undeclared_parameters
http://msdn.microsoft.com/en-us/library/ff878260(SQL.110).aspx

sys.dm_exec_describe_first_result_set_for_object
http://msdn.microsoft.com/en-us/library/ff878236(SQL.110).aspx

sys.dm_exec_describe_first_result_set
http://msdn.microsoft.com/en-us/library/ff878258(SQL.110).aspx

EXECUTE
http://msdn.microsoft.com/en-us/library/ms188332(SQL.110).aspx

Slide Deck & Demos : Charlotte SQL Server User Group, 2010-12-15

AaronBertrand — Thu, 16 Dec 2010 03:57:00 GMT

On Wednesday I presented my "What's New in Denali" presentation in Charlotte, NC. Attached is a .zip file containing the PowerPoint presentation, as well as the scripts used in the demos and some sample snippet XML files.