Disclaimer: The use case I’m going with (checking the uniqueness of a column with a function) I understand can be “solutioned” much better with a unique constraint but this is not to show the best way to do something, rather a tricky little problem with doing it with a check constraint that calls a function.

OK first lets build ourselves a test db and table:

USE master
GO
CREATE DATABASE [FunWithFunctions]
GO
USE FunWithFunctions
GO
CREATE TABLE dbo.tblCustomers
	(
	CustomerID INT NOT NULL IDENTITY (1, 1),
	CustomerName NVARCHAR(50) NULL,
	CustomerEmailAddress NVARCHAR(50) NULL
	)  ON [PRIMARY]
GO
ALTER TABLE dbo.tblCustomers ADD CONSTRAINT
	PK_tblCustomers PRIMARY KEY CLUSTERED
	(
	CustomerID
	) WITH( STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO

Now we’re going to build our function that returns the count of CustomerIDs that have the same email address:

CREATE FUNCTION dbo.fnEmailAddressUniqueness(@EmailAddress AS NVARCHAR(50))
RETURNS INT
AS
BEGIN
	DECLARE @ReturnValue INT = 0
	SELECT	@ReturnValue = COUNT(CustomerID) FROM tblCustomers WHERE CustomerEmailAddress = @EmailAddress
	RETURN	@ReturnValue
END
GO

OK now we’re going to add a check constraint that uses this function to make sure that there are no other Customers with that email address (CustomerEmailAddress = 0)

ALTER TABLE dbo.tblCustomers ADD CONSTRAINT CK_fnEmailAddressUniqueness CHECK (dbo.fnEmailAddressUniqueness([CustomerEmailAddress])=0)
GO

Fantastic… now this was where I was going to do my insert of 10 rows and show through a profiler trace that my function was going to get called 10 times (once per row) but this happened:

(click to enlarge)

Ummmmm weird…. what happened?

I thought maybe there was something wrong with my function at first so I decided to call the function manually:

SELECT dbo.fnEmailAddressUniqueness('Superman@gmail.com')

That returned 0 (zero) as expected so I was left scratching my head for a while trying to imagine how a check constraint that is checking to make sure a value is 0 would fail (especially on an empty table) then it hit me….

This check constraint that is calling a function is not getting evaluated BEFORE the insert… but DURING/AFTER.

To test this theory I changed the ADD CONSTRAINT statement to this (after I dropped it):

ALTER TABLE dbo.tblCustomers ADD CONSTRAINT CK_fnEmailAddressUniqueness CHECK (dbo.fnEmailAddressUniqueness([CustomerEmailAddress])=1)
GO

And wouldn’t you know it… I could now insert data.

I wasn’t satisfied with just that… I wanted to actually see with my own two eye that it was actually inserting the row, checking the constraint (that calls the function), and removing the row because of the failure.

As dirty as this is, in one SSMS window I did this (using the GO 100000 statement to execute the following statement 100,000 times):

INSERT INTO dbo.tblCustomers(CustomerName, CustomerEmailAddress)
VALUES
('Clark Kent', 'Superman@gmail.com')

And then in a different SSMS window I ran this statement continually:

SELECT * FROM tblCustomers WITH(NOLOCK)

and I did this till the planets aligned and I was able to execute it at the exact split second I needed to capture this:

and then the next time I ran the same SELECT it was gone! (notice the CustomerID 5601)

So I stopped the “GO 100000″ statement that was continually trying to insert that single row and ran the rest of my insert (without the Superman@gmail.com row) and the rest of the data went in fine (with the CustomerID being in the 9000′s even though those IDs really never were actually used”)

Neat/Scary huh?

Anyways I found this to be quite surprising and I figured that I wouldn’t be the only one who would so I thought I’d do a post on it.

Have a great day!

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

http://www.eventbrite.com/event/686883487

Please be sure to not only click the “Add to my calendar” but also the “Register” button so that we can plan accordingly for food and drinks. 

Date:  July 7th 2010
Time: 5:00 pm – 7:00 pm
Location: Stanley A. Milner library
Map: 7 Sir Winston Churchill Square
Meeting Room: Centennial Room – Basement
Speaker: Brent Ozar
Topic: Virtualization and Magicians: Dealing with Virtual SQL Server

Session Abstract:

Virtualization and Magicians: Dealing with Virtual SQL Server

• How to configure CPU, memory and storage for virtual environments
• How to benchmark your servers and make sure they’ll handle your loads
• Common pitfalls like antivirus definition downloads that can cripple your servers
• What to watch for after V-day

Presenter Information:  Brent Ozar

Brent is a SQL Server Domain Expert with Quest Software. Brent has a decade of broad IT experience, performing systems administration and project management before moving into database administration. In his current role, Brent specializes in performance tuning, disaster recovery and automating SQL Server management. Previously, Brent spent 2 years at Southern Wine & Spirits, a Miami-based wine & spirits distributor.

Brent has experience conducting training sessions, has written several technical articles, and blogs prolifically at http://www.BrentOzar.com. He’s currently writing SQL Server Internals and Troubleshooting for Wiley/Wrox along with Christian Bolton, and Justin Langford.  He’s Editor-in-Chief at SQLServerPedia.com, where he also records video podcasts.

Agenda:
5:00 pm – Pizza and Socializing
5:30 pm – Sponsor Presentation
5:45 pm – Feature Presentation
7:00 pm – Wrap Up and Draws

If you haven’t signed up already at EDMPASS.com please do so now to receive meeting notifications, news, and updates from EDMPASS.

Hope to see you there.

Enjoy!!

In SQL there are so many ways to solve the same problem that sometimes people just pick the first thing that works. While this may be the fastest way to get a solution in place depending on the size and scope of the problem you are trying to solve you may be having to revisit your solution down the road to find a “better way”.

Someone could make a years worth of articles of examples but the one I'm going to touch on today is using a function in a where clause.

OK for this example I'm not going to build my own table cause I don't know enough superhero characters to make a decent sample size so I'm going to be working with the AdventureWorks (SQL 2005) databases.

OK first off let's set our STATISTICS TIME ON as well as our STATISTICS IO ON using the following statement:

SET STATISTICS TIME ON
GO
SET STATISTICS IO ON
GO

OK now let's run the following statement:

SELECT FirstName, LastName, EmailAddress, Phone, ModifiedDate
FROM Person.Contact
WHERE LEFT(EmailAddress, 5) = 'cryst'
GO


So in that statement we're doing a function (LEFT) in our WHERE clause. AdventureWorks isn't the biggest database in the world so the query comes back in a subsecond and our STATISTICS (at least on my test server) look like this:

SQL Server parse and compile time: CPU time = 0 ms, elapsed time = 0 ms.

(22 row(s) affected)
Table 'Contact'. Scan count 1, logical reads 220, physical reads 0,
read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times: CPU time = 15 ms, elapsed time = 12 ms.

Now let's do the same thing but this time we're NOT going to use a function in the WHERE clause:


SELECT FirstName, LastName, EmailAddress, Phone, ModifiedDate
FROM Person.Contact
WHERE EmailAddress LIKE 'cryst%'
GO

OK subsecond results… as expected but in looking at the STATISTICS we see this:

SQL Server parse and compile time: CPU time = 0 ms, elapsed time = 0 ms.

(22 row(s) affected)
Table 'Contact'. Scan count 1, logical reads 56, physical reads 0,
read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times: CPU time = 0 ms, elapsed time = 1 ms.

OK so at this point we see that using the LIKE statement and not a function directly against a column in our WHERE clause resulted in less logical reads, less CPU time and had an overall a smaller value for elapsed time. So how could that be?

Let's include the actual exection plan (CTRL-M) and run our two queries again:

SELECT FirstName, LastName, EmailAddress, Phone, ModifiedDate
FROM Person.Contact
WHERE LEFT(EmailAddress, 5) = 'cryst'
GO
SELECT FirstName, LastName, EmailAddress, Phone, ModifiedDate
FROM Person.Contact
WHERE EmailAddress LIKE 'cryst%'
GO


In looking at the execution plan you will see the first query (using LEFT) is doing an index scan and the second query (using LIKE) is doing an index seek and as we know an index seek is preferable as it only pulls back the rows that satisfy the query.

So what's the takeaway from this article… we solved the same problem (finding email addresses that start with the characters “cryst”) 2 different ways and got very different results, not in the result set but in the way SQL Server executed the request.

By not using a function in our WHERE clause we took an index scan (expensive) and turned it into an index seek (more efficient).

Enjoy!!

Now for all those people testing in production (first hang your head in shame ) you should use ALOT of caution with these two DBCC commands (or better yet just avoid them altogether in production).

DBCC DROPCLEANBUFFERS gives you a cold buffer cache while avoiding a full service shutdown/restart.  Good to do a CHECKPOINT before running this command so all the dirty pages for your database that you’re working with will be written to disk.  Using this command will help give you a level playing field and an accurate estimation of your codes execution time.  Not using this command might end up with a cached query and your changes (while great I’m sure) might seem to make a big difference without really doing so.

DBCC FREEPROCCACHE gives you the ability to clear all (or a specific) elements from the plan cache or remove all workload groups from a specified resource pool.  Once again be very careful where you use this as clearing your plan cache will cause stored procs to be recompiled which will give you a performance degredation. 

These two DBCC commands can help out alot when trying to troubleshoot/optimize T-SQL code.  Run them both before each execution of the code you are working with to help make sure that the positive effect that you’re seeing is due to your code and not cached information.