Mat Stephen's SQL Server WebLog : T-SQL

Getting to know SQL 2005 Service Broker

Mat_Stephen — Tue, 13 Sep 2005 00:27:00 GMT

Looks likes I've got to do a presentation on Service Broker for the SQL 2005 launch - so I've been doing some home work on the subject.

The best primer I've found is http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsql90/html/sqlsvcbroker.asp?frame=true this is refernenced in the webcast http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?EventID=1032263311&EventCategory=5&culture=en-us&CountryCode=US.

Once you've got your head round the basics you'll want to create your ow broker service and queues. Best I've found is "Setting Up a Service Broker Service and Queue" from SQL Server 2005 Books on line at ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/smo9/html/f6f1c8b5-393b-48f2-a2b0-184fef683b5c.htm. Problem with this is there's a bug in the code. I can't remember the delta between what's printed and what I have working, but my suggestion is to use the code below to create the TargetStoredProcedure and then comment out the sp.Create(); line in the sample code with //.

Hope you enjoy this new technology - if I discover some new usefulties (a new word I've just invented) in this area, I'll post them in my new 'Service Broker' category

USE [AdventureWorks]
GO
/****** Object: StoredProcedure [dbo].[TargetStoredProcedure] Script Date: 09/12/2005 23:17:28 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
create procedure dbo.TargetStoredProcedure as
DECLARE @message_body varbinary(MAX);
DECLARE @message_type_name nvarchar(128);
DECLARE @conversation_handle uniqueidentifier;
DECLARE @message_iduniqueidentifier uniqueidentifier;
DECLARE @message nvarchar(max);
DECLARE @MessageType nvarchar(max);
Declare @message_id nvarchar(max);

WHILE (1 = 1)
BEGIN
BEGIN TRY
BEGIN TRANSACTION;
WAITFOR (

RECEIVE top(1)
@message_type_name = message_type_name,
@message = message_body,
@conversation_handle = conversation_handle,
@message_id = message_id

FROM TargetQueue
), TIMEOUT 500

IF (@@ROWCOUNT = 0)
BEGIN
ROLLBACK TRANSACTION
BREAK
END;
select @message = N'<Hello>Pong</Hello>';
set @MessageType = '//microsoft.com/ssbdemo/PongMessageType';
SEND ON CONVERSATION @conversation_handle
MESSAGE TYPE @MessageType
(@message);
END CONVERSATION @conversation_handle
COMMIT TRANSACTION
END TRY
BEGIN CATCH
print @@error;
ROLLBACK
CONTINUE
END CATCH
END;
GO
SET ANSI_NULLS OFF
GO
SET QUOTED_IDENTIFIER OFF

SQL 2005: Making sense of the new Optimistic Concurrency Controls and the readers that block writers

Mat_Stephen — Tue, 06 Sep 2005 20:11:00 GMT

For a long time now Oracle enthusiasts have bashed SQL Server for not having Optimistic Concurrency Controls. They would demonstrate a SQL Server reader blocking a writer and possibly a writer blocking a reader. Thus, having appeared to demonstrate that SQL can't handle these two operations concurrently, they would therefore conclude that SQL can't scale - certainly not to enterprise level workloads; workloads that involve lots of people writing to a database at the same time as lots of people wanting to read from it.

This, of course, is a rather dirty trick; you only have to look at http://www.microsoft.com/sql/evaluation/compare/benchmarks.mspx to see SQL Server 2000 performance against various typical 3rd party LOB application workloads that involve reading and writing. So how did/do they perform these mischievous tricks - here's how:

Open connection 1

USE AdventureWorks

BEGIN TRANSACTION

UPDATE Production.Product

SET StandardCost = 5.0,

ListPrice = 11.50

WHERE Name LIKE '%sock%'

Open connection 2

USE AdventureWorks

SELECT Name,

StandardCost,

ListPrice

FROM Production.Product

WHERE Name LIKE '%Sock%'

You will now see that connection 2 will not return anything - instead it just sits there doing nothing. Here the writer on connection 1 blocks the reader on connection 2. This blocking will continue until connection 1 either commits or rollbacks the transaction it started with BEGIN TRANSACTION.

Well it would be very easy, at this stage, to get into a religious slanging match - and you know I don't do religion very easily. Luckily, with SQL 2005, I don't even have to think about get religious about this situation, because SQL Server 2005 now supports the necessary isolation levels to stop this happening.

At this point I'm reminded of an old joke told by Tommy Cooper: Bloke goes to see a Doctor, he lifts his arm in the air and says, "Doctor, every time I do this it hurts." And the Doctor says, "Well don't do it then."

I'm reminded of this joke because if you begin a transaction, update a value and then you find it causes other people problems - I would suggest you don't do it. Why begin a transaction, do some work and then walk off without committing it?

Okay - so you might have a 'really big update' that takes ages to run and it can't be batched up into smaller transactions and you need to run some very long running reports that have to have a transactionally consistant view of the data. Indeed; you might also be very unlucky and get struck by lightening!

In SQL 2000 there are various ways to obviate the encumbrance of this 'really big update' and nasty report – but I don't want to go down that road, like I said I want to avoid a religious debate. Now, in SQL 2005, we have exactly the same capability as Oracle to make such an operation very easy for the developer. Like Oracle, this capability employs the concept of 'versioning', which means each connection in the above scenario will work with its own version of the data, thus avoiding contention.

However as with Oracle, versioning takes up both processing and i/o at the server, resources that are potentially very expensive and not to be wasted if you don't have to. Does Oracle do any benchmarks with this feature turned on? I don't think so, and nor would SQL for that matter.

I will argue that versioning is frequently used as a way to make developers jobs easier and not because it’s actually necessary. By that I also mean it makes it easier for developers to write sloppy code - and by that you can happily infer I believe it makes it easier to employ cheaper developers.

So how do we go about ~~employing these cheaper developers~~, sorry, reducing contention on the database? To do this we now have two new isolation levels:

1. SNAPSHOT ISOLATION (Transaction-level Snapshot)

Administrators must set the new ALLOW_SNAPSHOT_ISOLATION database option to allow Snapshot Isolation.

In order to start a transaction that uses Snapshot Isolation a developer must SET TRANSACTION ISOLATION LEVEL SNAPSHOT

RESULT: Every statement within a Snapshot Isolation Transaction sees the same version of data comprised only of committed changes which occurred before the start

of the transaction. Other statements inside other transactions do not see the changes made inside this Snapshot Isolation Transaction.

2. READ COMMITTED WITH SNAPSHOT ISOLATION (Statement-level Snapshot)

Administrators must set the new READ_COMMITTED_SNAPSHOT database option to allow Read Committed Snapshot Isolation

No further application level changes are required to have statements use Read-Committed Isolation.

RESULT: Each statement sees a version of the data that was committed just before the statement began, instead of when the resource is read. This is merely a new implementation of read committed that is non-locking and non-blocking; the data is accurate only as at the start of the statement.

SQL 2005 - UPSERT: In nature but not by name; but at last!

Mat_Stephen — Wed, 31 Aug 2005 12:34:00 GMT

SQL Server has long been criticised for not having an UPSERT command, well now in SQL 2005 we have some good news, we have two new TSQL set operators that give us the complex insert/update logic that constitute an UPSERT. These are INTERSECT and EXCEPT

e.g.

-- UPDATE Destination FROM (Source INTERSECT Destination)

-- INSERT INTO Destination FROM (Source EXCEPT Destination)

These statements obviate the need to construct complex correlated sub-queries or WHERE EXISTS logic.

And what's more, these operators deliver high performance by exposing core engine functions.

Are you still using @@IDENTITY?

Mat_Stephen — Tue, 19 Jul 2005 11:50:00 GMT

Are you still using @@IDENTITY? It seems many people are. If you are, are you aware that it might not always return what you expect? No? then read on. @@IDENTITY will return the last IDENTITY column value inserted across any scope in the current session. This means that if a trigger, or similar, were to insert a row in another table (T2), other than the one you're interested in (T1), inside the same transaction and after you insert into T1, you will get the Identity value of T2 instead of T1.

SCOPE_IDENTITY returns values inserted only within the current scope and obviates this problem. You may also be interested in IDENT_CURRENT as this is not limited by scope and session; it is limited to a specified table.

For more info and an example, check these functions out in Books On Line.

Cool new OVER Clause (Transact-SQL) in SQL Server 2005

Mat_Stephen — Thu, 23 Jun 2005 18:40:00 GMT

Cool new OVER Clause (Transact-SQL) in SQL Server 2005 to circumvent the not so efficient correlated subquery.

Imagine a table:

create table grades(
StudentID int not null
,StudentName varchar(10) not null
,Subject varchar(10) not null
,Score int not null)

With some values:

insert into grades values(1,'John','Math',87)
insert into grades values(1,'John','Geography',76)
insert into grades values(1,'John','History',98)
insert into grades values(1,'John','Science',85)
insert into grades values(2,'Sally','Crafts',89)
insert into grades values(2,'Sally','Science',88)
insert into grades values(2,'Sally','History',76)
insert into grades values(3,'Molly','English',87)
insert into grades values(3,'Molly','Science',76)
insert into grades values(3,'Molly','Geography',83)

You want to return each student with their highest two scoring subjects e.g.

John    History    98
John    Math       87
Sally   Crafts     89
Sally   Science    88
Molly   English    87
Molly   Geography  83

In SQL 2000 you may have used a correlated subquery thus:

select studentname, subject, score
from grades o
where score in (select top 2 score from grades i where i.studentname = o.studentname order by score desc)
order by studentname,score desc

However much more efficient and simpler in SQL 2005 is the new OVER clause:

select studentname, subject, score
from
(
   select studentname, subject, score,
   row_number() over (partition by studentid order by score desc) as rownum
   from grades
) dt
where rownum<=2

The OVER clause: Determines the partitioning and ordering of the rowset before the associated window function is applied. Applies to: Ranking Window functions

Very cool me thinks. My thanks to David Browne and Alfredo Ramirez for bringing this to my attention.