Using special functions for querying and executing commands at linked servers is not very convenient, and sometimes even very problematic.
For example, I need to execute some code on several linked servers but the linked server names are dynamic (queried from a table for example).
On each such linked server I need to execute a dynamic query.
However because I must use the EXECUTE() AT [...] command I'm exposing a big hole here for SQL Injection.
I found myself wishing I could use sp_executesql with linked servers but there's no such way as far as I know.

For example, this is what I’m forced to do:

CREATE PROCEDURE BackupOnRemoteServer

    @Path NVARCHAR(4000)

AS

    DECLARE

        @Statement    NVARCHAR(MAX)

    SET @Statement = N'    

    BACKUP DATABASE [MyDB]

    TO DISK = ''' + @Path + ''''

    EXECUTE (@Statement) AT [SQLINS1]

I’ve posted a suggestion on Microsoft Connect for the following feature:

It would be very helpful if we were able to connect to databases on linked servers with the "USE" keyword.

Technically, it would be like "opening a new session" from one SQL Server to another.

The sample I’ve posted above could be executed like this:

CREATE PROCEDURE BackupOnRemoteServer

    @Path NVARCHAR(4000)

AS

    DECLARE

        @ServerName VARCHAR(200),

        @Statement    NVARCHAR(MAX),

        @Parameters NVARCHAR(MAX)

    SET @ServerName = 'SQLINS1';

    SET @Parameters = N'@Path NVARCHAR(4000)';

    SET @Statement = N'

    USE [' + @ServerName + N'].[MyDB]

    BACKUP DATABASE [MyDB]

    TO DISK = @Path'

    EXEC sp_executesql @Statement, @Parameters, @Path

Once the USE command was executed, theoretically it's like I'm connected directly to the linked server using a query window.

Security could be improved versus SQL Injection (use sp_executesql with parameters instead of EXECUTE() AT) like the example above.

Usability could be improved due to cleaner and more readable code.

If you like this idea, please visit this page and vote for it so it’ll get higher priority on Microsoft’s to-do list:

https://connect.microsoft.com/SQLServer/feedback/details/742327/use-keyword-with-linked-servers#details

Introduction

Service Broker is a cool new feature since SQL Server 2005. Yes, SQL 2012 just came out so it’s hardly “new” anymore. But in reality, many DBAs and DB users are still not aware of this feature, or don’t know how to utilize it, or are afraid to do so because they’re not familiar with it.

Using this short series of posts, I’m hoping to ease the minds of such people

In short, Service Broker is an asynchronous queuing engine working inside SQL Server. Using this engine we can send and receive binary or XML messages between queues. When a message is inserted in a queue, Service Broker executes an “activation procedure” that you specified, which is supposed to handle messages from that queue.

Since we have a lot to cover in our sample, I won’t go into too much detail introducing Service Broker. But Microsoft has an excellent and detailed chapter about Service Broker available right here: http://msdn.microsoft.com/en-us/library/bb522893.aspx

Sample 1: Multi-Threading

I managed to encounter several times a scenario where an application needed to execute several queries independent of each other, and then group them together somehow. However, each of these queries takes a while to execute.
One might wonder: If only we could use some kind of multi-threading mechanism to execute them in parallel, and then the total running time will be of the slowest query only and not the total of them.

Well, it just so happens that our first sample will show how you can implement “multi-threading” in SQL Server using Service Broker queues!

The Design

First, I’ll explain the general idea of the design:

Since Service Broker only works with binary or XML messages, we’ll use XML to send a “query request”, and wait for a “query response”.
Specifically, we’ll send a message containing some kind of a dynamic query. But that dynamic query must return its result in XML form using an output parameter. Then, Service Broker will execute the query, retrieve the result from the output parameter, and send the result back as the response.
After that, it’s up to us to gather all the responses together and do whatever it is we wanted to do with it.

Also, for the sake of our sample, we’ll need to simulate long execution times. We’ll do this simply by adding a WAITFOR DELAY command into our dynamic queries which will cause the query to wait for a random number of seconds (between 10 and 30).

The Scripts

Available below is a ZIP file with the two scripts we’ll use:
One is the installation script, responsible for creating all the objects we require – the database, the service broker procedures, endpoints and queues. Everything you need to implement multi-threading in SQL Server.
The other is a sample of how to use this mechanism, using simple queries and a WAITFOR DELAY command to simulate long execution times.

The scripts are commented to help you understand what’s going on. But we’ll go over them bit by bit just in case.

The Installation Script

In order to explain the installation script, I’ll list all the objects that we’re creating and explain the purpose of each object. More detailed information about the implementation can be found in the script itself.

• SB_PQ_Test:
  That’s the database we’ll be using to create all the necessary objects.
• SB_PQ_ServiceBrokerLogs:
  This is a logging table which will be used to log the start and end of each query execution, and any errors that may occur.
• SB_PQ_ExecuteDynamicQuery:
  This is the procedure which will actually execute the dynamic queries. It builds the dynamic command, uses sp_executesql to execute it, and returns the result as an output parameter. The name of the output parameter itself can be dynamic.
• SB_PQ_HandleQueue:
  This is the activation procedure that Service Broker executes when it creates a “reader instance”. Or in other words, when there’s something in the request queue.
  This procedure is the most important part because it’s responsible for retrieving messages from the request queue, execute the query (using SB_PQ_ExecuteDynamicQuery), and handle any errors that may occur in-between.
• SB_PQ_Request_Queue:
• This is the queue where all query requests will be waiting to be processed. Its activation procedure is SB_PQ_HandleQueue.
• SB_PQ_Response_Queue:
  This is the queue into which query responses will be sent. Its doesn't have an activation procedure because query response extraction is done manually.
• [//SB_PQ/Message]:
  This is a simple message type of “Well Formed XML”. We’ll be using it to verify our messages.
• [//SB_PQ/Contract]:
  This is a contract defining that both target and initiator must send messages of type [//SB_PQ/Message].
• [//SB_PQ/ProcessReceivingService]:
  This is the service endpoint working as the “address” of request queries. We will be sending messages into this service. The queue it’ll be using to receive messages is SB_PQ_Request_Queue.
• [//SB_PQ/ProcessStartingService]:
  This is the service endpoint working as the “address” of response queries.
  We will be sending messages from this service. The queue it’ll be using to receive messages is SB_PQ_Response_Queue.
• SB_PQ_Start_Query:
  This is the public procedure that will used for starting an execution thread, by sending a request query to [//SB_PQ/ProcessStartingService].
  You can think of it as an API simplifying our use of all the above objects.
  It receives as parameters the SQL command that should be executed, the name of the output parameter (without the @), and the conversation group ID.
• SB_PQ_Get_Response_One:
  This is the public procedure that will be used to retrieve the results of our queries. It receives as a parameter the conversation group ID to be used, and returns the first result it finds as an output parameter. You may also think of it as part of the API simplifying our use of the above objects.

Whew, that was a long list! Please note that since Service Broker works asynchronously in the background, error handling is extremely important. Note all the error handling, especially in the SB_PQ_HandleQueue procedure.

The Sample Script

Now we can really get down to business. I’ll go over the important parts in the script and explain each of them:

-- random workload simulation settings

SET @MinDelay = 10

SET @MaxDelay = 30

SET @ConvGroup = NEWID();    -- the messages will be grouped in a specific conversation group

SET @NumOfSegments = 3;        -- number of "threads" to use

-- create several segments

SET @Segment = 1;

WHILE @Segment <= @NumOfSegments

BEGIN

In our sample, we create several “segments” (or threads) where each of them will have a random delay between 10 and 30 seconds, and execute a simple query returning its details. In the above script we define the minimum and maximum delay in seconds, set the conversation group ID by which our threads will be grouped, total number of threads (3 in our case), and we start looping per each of the threads.

-- random delay between @MinDelay and @MaxDelay seconds to simulate long execution time

SET @Delay = '00:00:' + CONVERT(varchar(8), ROUND(RAND() * (@MaxDelay - @MinDelay),0) + @MinDelay)

The above script simply prepares the delay representation by generating a random number of seconds as we defined earlier (between 10 and 30).

-- build our dynamic SQL command. note the use of XML as the result.

SET @SQL = N'

WAITFOR DELAY ''' + @Delay + ''';

SET @SB_PQ_Result = 

(

    SELECT

        Segment = ' + CONVERT(nvarchar(max), @Segment) + N',

        Delay = ''' + @Delay + N''',

        StartDate = GETDATE(),

        Name = QUOTENAME(name),

        object_id, type, modify_date

    FROM

        SB_PQ_Test.sys.tables AS Tab

    FOR XML AUTO, ELEMENTS

);

';

In the script above we create the dynamic SQL command which will be executed by the current thread. Note the use of XML AUTO, ELEMENTS to format the results in XML and put them in the output parameter.

Also note the use of WAITFOR DELAY at the start to simulate long execution time.

-- Send request to queue

EXEC SB_PQ_Start_Query @SQL, @OutputParam, @ConvGroup;

The above script executes the API procedure SB_PQ_Start_Query with the SQL command we prepared, the name of the output parameter, and the conversation group ID. This will put the message in the request queue and continue executing without waiting for a response (the magic of asynchronous work).

    -- increment segment index

    SET @Segment = @Segment + 1;

END

The above script increases the thread index so we can continue to the next one.

-- init final result

DECLARE @TotalResult XML;

SET @TotalResult = '<Tables> </Tables>'

The above script initializes an XML variable called @TotalResult which will contain all the results we’re about to receive.

-- count based on number of segments that we created earlier

SET @Segment = 1;

WHILE @Segment <= @NumOfSegments

BEGIN

In this part of the script we’re resetting the @Segment index and looping again based on the number of threads in @NumOfSegments.

    -- Get segment from response queue

    EXEC SB_PQ_Get_Response_One @ConvGroup, @CurrentResult OUTPUT

In the above script, we use the API procedure SB_PQ_Get_Response_One to retrieve a single result from any of the threads (whichever finished executing first). The result will be returned in the output variable @CurrentResult.

-- insert into TotalResults using XML DML (syntax for SQL2008 and newer)

SET @TotalResult.modify('

insert sql:variable("@CurrentResult")

into (/Tables)[1] ');

The above script uses XML DML language with reference to the @CurrentResult variable to insert its contents into the @TotalResult variable.

Please note that this method of “inserting” a SQL variable into an XML document is SQL 2008 syntax and won’t work in older versions.

If you have SQL Server 2005, you will need to work a little harder to collect the results (for example, declaring @TotalResult as nvarchar(4000) without a closing tag, concatenating the results one-by-one, and only at the end concatenate the closing tag as well).

    -- increment segment index

    SET @Segment = @Segment + 1;

END

The above script increases the thread index so we can continue to the next one.

-- return final result (as XML)

SELECT @TotalResult.query('.') AS FinalResult

-- return final result (as relational table)

SELECT

    Segment        = T.XRecord.query('.').value('(/Tab/Segment)[1]','varchar(100)'),

    Delay        = T.XRecord.query('.').value('(/Tab/Delay)[1]','varchar(8)'),

    StartDate    = T.XRecord.query('.').value('(/Tab/StartDate)[1]','datetime')

FROM

    @TotalResult.nodes('/Tables/Tab') AS T(XRecord)

The above script shows two methods of how you can return your final data.

The first method returns the simple XML representation of @TotalResult.

The second method shows how you can break down each element in @TotalResult (using the nodes() method) and display the values of each element (using the value() method).

-- check the SB logs to see how many unique sessions executed our requests

DECLARE @NumOfSessions INT;

SELECT @NumOfSessions = COUNT(DISTINCT SPID)

FROM SB_PQ_ServiceBrokerLogs

WHERE LogDate >= @StartTime

PRINT CONVERT(nvarchar(100),@NumOfSessions) + ' unique sessions participated in execution'

SELECT *

FROM SB_PQ_ServiceBrokerLogs

WHERE LogDate >= @StartTime

The above script is a sort of “debug” script which will display information from our Service Broker logging table, specifically showing how many unique sessions participated in execution since the start of the script, and displays the contents of the logging table from that period of time.

Execution Delay

It takes Service Broker several seconds before activating more than one reader instance. However, because our activation procedure continues waiting for new requests even after finishing an execution, once a reader instance is activated it’ll stay active until it’s manually shut down.

As a result of this behavior, your first execution in multi-threading may not be as fast as you’d expect. But from the second try onwards it shouldn’t take longer than the longest running query.

Customizing for Your Version

The above sample script is a very crude sample of how to use the API we created using the installation script. But this architecture can be used for just about anything you want to execute multi-threaded.

Your own implementation will probably be much different.

You may want to perform a query on a large range of records, and prefer to break down that range to several sub-ranges, where each sub-range will be a separate thread / segment.

Maybe you have several different queries and you need to do different things with them, so you’ll have several different executions of the API procedures (you’d need to think how to identify each query though, perhaps by adding that information in the XML somewhere).

Maybe you’re not even performing queries. Maybe it’s some maintenance tasks you wish to perform simultaneously (you still should expect a response of some kind, for example a message notifying of success or failure).

In any case, you’ll need to follow these rules:

• Your SQL command must make use of an output parameter of type XML. You don’t need to declare it inside your command, but simply put into it the XML result you want to expect.
• Take note of the name of the output parameter you’re using and provide it during the execution of the SB_PQ_Start_Query procedure.
• If there’s a chance other sessions will be using this API at the same time, it’s extremely important to make use of the Conversation Group ID parameter so you’d have a way of separating between the data of different sessions.
• In any case, the thread will try to return a response even if there was an error in your query (NULL will be returned). So in order to prevent clogging on the response queue, don’t forget to use the SB_PQ_Get_Response_One procedure to take them out of the queue.

Conclusion

This was but one example of how you can use Service Broker to improve your work with SQL Server. I’ll be working on new examples so check back soon!

I hope my post wasn’t too complicated or confusing. But if you have any questions, please post them in the comment section below, and I’d be happy to help!

Microsoft SQL Server Reporting Services is an excellent and easy-to-use platform for creating, viewing, managing, and subscribing to reports of all shapes and sizes.

Technically, this platform is meant for nothing more than reports. It’s true that reporting is a huge field and you can do all kinds of cool stuff with it, but it’s still just reporting – or in other words: Viewing data.

However, it’s also possible to use this platform for updating data. Whether it’s deleting items, updating them, or even inserting new records.
It’s especially good when your organization doesn’t have skilled programmers that can create a pretty-looking graphical user interface (GUI). Or when there are budget and / or time restrictions.

The key to this special usage of Reporting Services is the Data Sets of type “Stored Procedure”. In SQL Server Reporting Services, one form of getting data for your report is executing a stored procedure in your database.
However, a stored procedure (as you probably know) can do a lot more than just querying data. Technically, when you use stored procedures in SSRS, all they need to do is:

1. Receive parameter values.
2. Do some processing.
3. Return a set of data.

The 2nd step can be absolutely anything. It can be an insertion of new data, updating or deleting, and even some complex combination of everything.

Actually, you don’t really need a stored procedure to do this. You can also use the Text data set and write all your logic directly in the report. But in my opinion it’s not so comfortable and a lot more cumbersome to work like that, especially when you need to debug your logic, or when the same logic is used in several reports.

Also, it’s important to remember that your stored procedure must return a single result set at the end. Don’t forget this is Reporting Services we’re dealing with, and it expects to receive a single result set for the data it needs to display.

Personally, I like implementing this using what I call an “output temporary table”. The idea is that throughout your logic, you may have several steps, and you want to know the outcome of each of these steps (success or failure, number of rows affected etc.),. To do so, I create a temporary table (best if it’s a variable table), and at the success or failure of each step, I insert a record with a message in that table. At the end, I simply SELECT the entire table and display it in the report.

Updating Rows

For example, here is a sample procedure that I wrote which transfers all the employees from one manager to another (in the AdventureWorks database):

CREATE PROCEDURE MoveEmployeesFromManagerToManager

    @SourceManagerID INT,

    @DestinationManagerID INT

AS

DECLARE @RCount INT

DECLARE @Output AS TABLE

    ( Msg NVARCHAR(MAX) )

BEGIN TRY

    INSERT INTO @Output

    VALUES(

    N'Moving employees from ManagerID '

    + CONVERT(nvarchar(50), @SourceManagerID)

    + ' to ManagerID '

    + CONVERT(nvarchar(50), @DestinationManagerID)

    + '...'

    )

    BEGIN TRANSACTION

    UPDATE Employees

    SET

        ManagerID = @DestinationManagerID

    OUTPUT

        N'Moved EmployeeID '

        + CONVERT(nvarchar(50), INSERTED.EmployeeID)

    INTO

        @Output

    FROM

        HumanResources.Employee AS Employees

    WHERE

        ManagerID = @SourceManagerID

    SET @RCount = @@ROWCOUNT;

    IF @RCount > 0

    BEGIN

        INSERT INTO @Output

        VALUES(

        N'Moved '

        + CONVERT(nvarchar(50), @RCount)

        + ' employee(s).')

    END

    ELSE

    BEGIN

        INSERT INTO @Output

        VALUES(N'No employees were updated.')

    END

    COMMIT TRANSACTION

END TRY

BEGIN CATCH

    IF @@TRANCOUNT > 0

        ROLLBACK TRANSACTION;

    INSERT INTO @Output

    VALUES(N'CRITICAL ERROR: ' + ERROR_MESSAGE())

END CATCH

SELECT * FROM @Output

As you can see, before performing the actual update, I put a message into the @Output table informing of the operation. Then I use the UPDATE…OUTPUT…INTO syntax to save in the @Output table all the employees that were updated. Finally, I insert another message in @Output informing of the success or failure of the operation.

Most importantly, note that the entire logic is enveloped in a TRY..CATCH block, and in the CATCH segment I put into the @Output table the error message that occurred.

When you create a Reporting Services report which uses this procedure, you specify this procedure as the source of the data set, and add a table which will display the contents of the query (from the @Output table).

Defining the stored procedure as the source of the data set.

It will look something like this:

Deleting Rows

Here is  another sample where I have two reports:

1. A report displaying the contents of the DatabaseLog table.
2. A report which deletes a record from DatabaseLog table.

The first report will feature a button which will navigate me to the second report, and on the way pass on the DatabaseLogID which I want to delete. The second report will use a procedure which will delete the record with the provided ID, and display a message about it.

The first report:

The second report:

And here is the script for its procedure:

CREATE PROCEDURE DeleteDatabaseLogRow

    @DatabaseLogID INT

AS

DECLARE @Output AS TABLE

(Msg NVARCHAR(MAX))

BEGIN TRY

    INSERT INTO @Output

    VALUES ('Deleting record with DatabaseLogID ' + CONVERT(varchar(50),@DatabaseLogID))

    DELETE FROM DatabaseLog

    WHERE DatabaseLogID = @DatabaseLogID

    IF @@ROWCOUNT > 0

        INSERT INTO @Output

        VALUES('Successfully deleted record.')

    ELSE

        INSERT INTO @Output

        VALUES('Error: No such record found.')

END TRY

BEGIN CATCH

    IF @@TRANCOUNT > 0

        ROLLBACK TRANSACTION;

    INSERT INTO @Output

    VALUES(N'CRITICAL ERROR: ' + ERROR_MESSAGE())

END CATCH

SELECT * FROM @Output

Inserting Data

Another example (which I will not demonstrate here), is performing an INSERT to a table, where the report parameters represent the values you wish to enter into each column.

XP_CMDSHELL

Another interesting example would be to execute something that’s even outside SQL Server. That could be a standalone EXE file, or some DOS command that copies or deletes files, etc.. These commands will be executed using XP_CMDSHELL (assuming  it’s enabled and your login has the correct permissions). Remember that XP_CMDSHELL returns a query which contains the resulting output from the operation. This output can be saved in our @Output table and then displayed in the report.

For example, suppose we have a table with file or folder paths, and we create a report where we move these files or folders to a new location.

For this you’d need to be familiar with the basic CMD commands such as XCOPY, DEL, MOVE and possibly DIR. But that is beyond the scope of this blog post. Don’t worry though, there’s plenty of resources on the internet for this.

Here is a sample of using XP_CMDSHELL in conjunction with our @Output table in order to move an entire folder from one location to another. It’s pretty straightforward, so I’ll leave the rest to you:

SET @CMD = 'xcopy /E /C "' + @Source + N'\*.*" "' + @Destination + '\*.*"'

INSERT INTO @Msg

EXEC xp_cmdshell @CMD

Conclusion

As you can guess, the possibilities are  almost endless. The only problem I could think of is when you need to insert a large amount of rows into some table. Using the report parameters is convenient for providing column values of a single row, but a group of rows is another matter altogether. At the least you could use Microsoft Access linked to a SQL Server to easily enter groups of rows in a grid view. Theoretically, you can use SSIS to import Excel files with multiple records to insert, but that’s also outside our scope of Reporting Services. Other than that, and the built-in graphical interface of SQL Server Management Studio, I don’t know a simpler way to do this (without programming your own GUI obviously).

Thoughts? More interesting ideas? Post them in the comments!

Today I'll talk about the available JOIN operator types in SQL Server (Nested Loops, Hash and Merge Joins), their differences, best practices and complexity.

For the samples in this post, we'll use the free AdventureWorks database sample available here: http://msftdbprodsamples.codeplex.com/releases/view/4004

Introduction: What are Join Operators?

A join operator is a type of an algorithm which the SQL Server Optimizer chooses in order to implement logical joins between two sets of data.

The SQL Server Optimizer may choose a different algorithm for different scenarios based on the requested query, available indexes, statistics and number of estimated rows in each data set.

It's possible to find the operator which was used by looking at the execution plan that SQL Server has prepared for your query.

For more information on execution plans and how to read them, I recommend checking out the first chapter out of Grant Fritchey's excellent book:
http://www.simple-talk.com/sql/performance/execution-plan-basics/

NESTED LOOPS

"Nested Loops" is the simplest operator of the bunch.

We'll take the following query as an example (which gets some order detail columns for orders placed during July 2001):

SELECT
OH.OrderDate, OD.OrderQty, OD.ProductID, OD.UnitPrice
FROM
    Sales.SalesOrderHeader AS OH
JOIN
    Sales.SalesOrderDetail AS OD
ON
    OH.SalesOrderID = OD.SalesOrderID
WHERE
    OH.OrderDate BETWEEN '2001-07-01' AND '2001-07-31'

The resulting execution plan looks like this:

The operator on the top right is called the outer input and the one just below it is called the inner input.

What the "Nested Loops" operator basically does is: For each record from the outer input – find matching rows from the inner input.

Technically, this means that the clustered index scan you see as the outer input is executed once to get all the relevant records, and the clustered index seek you see below it is executed for each record from the outer input.

We'll verify this information by placing the cursor over the Clustered Index Scan operator and looking at the tooltip:

We can see that the estimated number of executions is 1. We'll look at the tooltip of the Clustered Index Seek:

This time we can see that the estimated number of executions is 179 which is the approximate number of rows returned from the outer input.

In terms of complexity (assume N is the number of rows from the outer output and M is the total number of rows in the SalesOrderDetail table): The complexity of this query is: O(NlogM) where "logM" is the complexity of each seek in the inner input.

The SQL Server Optimizer will prefer to choose this operator type when the outer input is small and the inner input has an index on the column(s) by which the two data sets are joined. The bigger the difference in number of rows between the outer and inner inputs, the more benefit this operator will provide over the other operator types.

Having indexes and up-to-date statistics is crucial for this join type, because you don't want SQL Server to accidently think there's a small number of rows in one of the inputs when in fact there are a whole lot. For example: Performing 10 times index seek is nothing like performing 100,000 times index seek, especially if the table size of the inner input is around 120,000 and you'd be better off doing one table scan instead.

MERGE Join

The "Merge" algorithm is the most efficient way to join between two very large sets of data which are both sorted on the join key.

We'll use the following query as an example (which returns a list of customers and their sale order identifiers):

SELECT
    OC.CustomerID, OH.SalesOrderID
FROM
    Sales.SalesOrderHeader AS OH
JOIN
    Sales.Customer AS OC
ON
    OH.CustomerID = OC.CustomerID

The execution plan for this query is:

• First, we'll notice that both of the data sets are sorted on the CustomerID column: The Customer table because that's the clustered primary key, and the SalesOrderHeader table because there's a nonclustered index on the CustomerID column.
• By the width of the arrows between the operators (and by placing the cursor over them), we can see that the number of rows returned from each set is rather large.
• In addition, we used the equality operator (=) in the ON clause (the Merge join requires an equality operator).

These three factors cause SQL Server Optimizer to choose the Merge Join for this query.

The biggest performance gain from this join type is that both input operators are executed only once. We can verify this by placing the cursor over them and see that the number of executions is 1 for both of the operators. Also, the algorithm itself is very efficient:

The Merge Join simultaneously reads a row from each input and compares them using the join key. If there's a match, they are returned. Otherwise, the row with the smaller value can be discarded because, since both inputs are sorted, the discarded row will not match any other row on the other set of data.

This repeats until one of the tables is completed. Even if there are still rows on the other table, they will clearly not match any rows on the fully-scanned table, so there is no need to continue. Since both tables can potentially be scanned, the maximum cost of a Merge Join is the sum of both inputs. Or in terms of complexity: O(N+M)

If the inputs are not both sorted on the join key, the SQL Server Optimizer will most likely not choose the Merge join type and instead prefer the Hash join (will be explained soon). However if it does anyway (whether it's because it was forced to due to a join hint, or because it was still the most efficient), then SQL will need to sort the table which is not already sorted on the join key.

HASH Match

The "Hash" join type is what I call "the go-to guy" of the join operators. It's the one operator chosen when the scenario doesn't favor in any of the other join types. This happens when the tables are not properly sorted, and/or there are no indexes. When SQL Server Optimizer chooses the Hash join type, it's usually a bad sign because something probably could've been done better (for example, adding an index). However, in some cases (complex queries mostly), there's simply no other way.

We'll use the following query as an example (which gets the first and last names of contacts starting with "John" and their sales order identifiers):

SELECT
    OC.FirstName, OC.LastName, OH.SalesOrderID
FROM
    Sales.SalesOrderHeader AS OH
JOIN
    Person.Contact AS OC
ON
    OH.ContactID = OC.ContactID
WHERE
    OC.FirstName LIKE 'John%'

The execution plan looks like this:

Because there's no index on the ContactID column in the SalesOrderHeader table, SQL Server chooses the Hash join type.

Before diving into the example, I'll first explain two important concepts: A ”Hashing" function and a "Hash Table".

"Hashing" is a programmatic function which takes one or more values and converts them to a single symbolic value (usually numeric). The function is usually one-way meaning you can't convert the symbolic value back to its original value(s), but it's deterministic meaning if you provide the same value as input you will always get the same symbolic value as output. Also, it's possible for several different inputs to result in the same output hash value (meaning, the function isn't necessarily unique).

A "Hash Table" is a data structure that divides all rows into equal-sized "buckets", where each "bucket" is represented by a hash value. This means that when you activate the hash function on some row, using the result you'll know immediately to which bucket it belongs.

As with the Merge join, the two input operators are executed only once. We can verify this by looking at the tooltips of the input operators.

Using available statistics, SQL Server will choose the smaller of the two inputs to serve as the build input and it will be the one used to build the hash table in memory. If there's not enough memory for the hash table, SQL Server will use physical disk space in TEMPDB. After the hash table is built, SQL Server will get the data from the larger table, called the probe input, compare it to the hash table using a hash match function, and return any matched rows. In graphical execution plans, the build input will always be the one on top, and the probe input will be the one below.

As long as the smaller table is very small, this algorithm can be very efficient. But if both tables are very large, this can be a very costly execution plan.

SQL Server Optimizer uses statistics to figure out the cardinality of the values. Using that information, it dynamically creates a hash function which will divide the data into as many buckets with sizes as equal as possible.

Because  it’s so dynamic,  it’s difficult to estimate the complexity of the creation of the hash table and the  complexity of each hash match. Because SQL Server Optimizer performs this dynamic operation during execution time and not during compilation time, sometimes the values you see in the execution plan are incorrect. In some cases, you could compare a hash join and a nested loops join, see that according to the execution plans the nested loop is more expensive (in terms of logical reads etc.), when in fact the hash join executes much slower (because its cost estimation is incorrect).

For our complexity terms, we’ll assume h_c is the complexity of the hash table creation, and h_m is the complexity of the hash match function. Therefore, the complexity of the Hash join will be O(N*h_c + M*h_m + J) where N is the smaller data set, M is the larger data set and J is a “joker” complexity addition for the dynamic calculation and creation of the hash function.

Microsoft has an interesting page in Books Online that describes further Hash Join sub-types and additional aspects about them. I highly recommend you read it: http://msdn.microsoft.com/en-us/library/ms189313.aspx

Query Hints

Using Query Hints, it's possible to force SQL Server to use specific join types. However, it's highly not recommended to do so especially in production environments, because the same join type may not be the best choice forever (because data can change), and SQL Server Optimizer usually has it right (assuming statistics are up-to-date).

I'll talk about them just so you can experiment with the different join types on your test environment and see the differences.

To force SQL Server to use specific join types using query hints, you add the OPTION clause at the end of the query, and use the keywords LOOP JOIN, MERGE JOIN or HASH JOIN.

Try executing the above queries with different join hints and see what happens:

SELECT OC.CustomerID, OH.SalesOrderID
FROM Sales.SalesOrderHeader AS OH
JOIN Sales.Customer AS OC
ON OH.CustomerID = OC.CustomerID
OPTION (HASH JOIN)

SELECT OC.FirstName, OC.LastName, OH.SalesOrderID
FROM Sales.SalesOrderHeader AS OH
JOIN Person.Contact AS OC
ON OH.ContactID = OC.ContactID
WHERE OC.FirstName LIKE 'John%'
OPTION (LOOP JOIN)

SELECT OC.FirstName, OC.LastName, OH.SalesOrderID
FROM Sales.SalesOrderHeader AS OH
JOIN Person.Contact AS OC
ON OH.ContactID = OC.ContactID
WHERE OC.FirstName LIKE 'John%'
OPTION (MERGE JOIN)

Summary

Nested Loops

• Complexity: O(NlogM)
• Used usually when one table is significantly small
• The larger table has an index which allows seeking it using the join key

Merge Join

• Complexity: O(N+M)
• Both inputs are sorted on the join key
• An equality operator is used
• Excellent for very large tables

Hash Match

• Complexity: O(N*h_c+M*h_m+J)
• Last-resort join type
• Uses a hash table and a dynamic hash match function to match rows

Resources

The following resources were used for the making of this post:

• Inside the SQL Server Query Optimizer by Benjamin Nevarez
• SQL Server Execution Plans by Grant Fritchey
• Advanced Query Tuning Concepts at Microsoft's SQL Server Books Online
• Blog post about Hash Joins by Craig Freedman

Recently I've stumbled upon an apparently little known fact about SQL Server – specifically SQL Server collations and how they affect performance.

During a normalization upgrade to their database, one of my clients had weird and inconsistent performance problems and couldn't find a solution for it for quite a while.

They had two queries:

1. The Original (Un-Normalized) Query: Scanned 2.5 million rows and executed for 3 seconds.
2. The New (Normalized) Query: Scanned 10 million similar rows and executed for 50 seconds.

Each query was executed against a different table, but the data in the tables was identical (the difference was due to the normalization). The column we searched against was varchar(255) in both tables.

For a while we couldn't wrap our heads around the reason for the huge difference in performance.

Something just didn't seem right.

During my investigation I noticed an intriguing difference in the execution plans, and that is in the first query (the fast one) an implicit conversion was performed for the varchar column, but no such conversion occurred in the slow query. At first I didn't pay attention to it because, as a DBA, I was trained to think that implicit or explicit conversions HURT performance, and not the other way around – so this couldn't have been the reason.

But eventually (and with a little push from Shy Engelberg – Thank you Shy!) I took a closer look to find out why this conversion was happening in the first place.

We found that the collation of the varchar column was different between the two tables.

The first table had a Latin SQL collation, yet the second table had an ANSI collation (or windows collation if you prefer to call it that).

We tried to change the collation of the second table to the SQL collation as well – and presto! The query now executed for 5 seconds – 10 times faster! (and only 2 times slower than the 3 second query, a lot more logical difference)

I looked for materials regarding this issue, and couldn't find much except this (apparently important) white paper:

http://support.microsoft.com/kb/322112

The highlight:

Unicode sorting rules are much more complex than the rules for a non-Unicode SQL sort order. When SQL Server compares Unicode data, the characters are assigned a weight that is dynamically modified based on the collation's locale. The data is also modified by comparison style settings such as width, accent, or Kana-sensitivity. The Unicode sort routines support more intelligent sort behaviors like word sorting.

[…]

•        If you are storing and handling your data by using non-Unicode data types (char, varchar, text), and you are using a SQL collation, string comparisons will be performed with a non-Unicode SQL sort order.

•        If you are storing and handling your data by using non-Unicode data types (char, varchar, text), and you are using a Windows collation, string comparisons will be performed with the Unicode sorting rules. This may cause certain operations that are unusually dependent on string sorting performance to take longer and to use more CPU than a similar operation that is performed with a SQL collation.

•        If you are using Unicode data types (nchar, nvarchar, ntext), there is no difference in the sorting behavior for the SQL and the Windows collations. Both will use Unicode sorting rules.

In short, windows collations perform as slow as Unicode data types, and SQL collations perform much faster.

Later we also tested the performance of a binary collation and saw that it was even faster in queries that required comparison and grouping, but it performed worse in queries that required sorting. This makes sense since binary collations must be parsed textually before being sorted – a heavier operation than doing the same for SQL collations – as opposed to a comparison operation which can be as fast as doing XOR of two values.

Conclusion

SQL or Windows Collations seem like another consideration we need to take when designing a database and checking for performance – but beware! Changing the collation may change the sorting order of your text, so if your application depends on a certain form of sorting – you need to make sure the new collation matches it.

The same white paper mentioned above claims that changing indexes or how a query is written will make a bigger difference than changing collations, but it's surprising what a huge difference in performance a collation caused in the case of my client, and we did try to rewrite the query several times and changing indexes, but nothing made a big difference such as the collation.

Did you encounter a similar scenario? Did you have similar (or even more interestingly – different) results? Tell us about it in the comments!

Thanks again to Shy Engelberg for his very helpful advice on this one.

Since SQL Server 2005, Microsoft added the nice addition to the common DML statements UPDATE and DELETE by allowing the use of the TOP keyword. Unfortunately for many of us, SQL Server doesn't support the use of this keyword in conjunction with the ORDER BY clause. So when we do need to update or delete the top x rows in a table based on a specific order, we're bound to use all kinds of workarounds.

However, many of the commonly used workarounds are not very efficient as they can be.

Here's an example of a common method to update the top x rows in a table based on a specific order:

UPDATE MyTable SET Col1 = Whatever
WHERE ID IN (SELECT TOP (100) ID FROM MyTable ORDER BY Col2 DESC)

As you can see, this method uses a subquery to get the list of unique IDs of the top 100 rows that we want to update. The problem with this method is that we're accessing the table twice and performing a JOIN between the two sets of data (even though we didn't explicitly write "JOIN" in the statement, that's what SQL Server does in the background).

There are actually several variations to this method. Here's another example:

UPDATE MyTable SET Col1 = Whatever
FROM
MyTable
JOIN
(SELECT TOP (100) ID FROM MyTable ORDER BY Col2 DESC) AS ToDelete
ON
MyTable.ID = ToDelete.ID

This is an explicit JOIN statement with a subquery. This practically results in the same execution plan as the previous method, except that it allows the use of composite primary keys in the JOIN condition.

Another method is to do the same by first putting the results of the subquery in a temporary table and then doing the UPDATE by joining with that temporary table, but that would result in even worse performance due to the extra overhead.

Another method is to use the SET ROWCOUNT statement which would limit any statement to affect a specific maximum number of rows. However, this method is not recommended because unlike the TOP keyword, SQL Server doesn't take it into consideration when building the execution plan – which could result in an execution plan optimized for many rows of data even though we put a small number in SET ROWCOUNT.

All of the above is relevant to DELETE statements as well.

So, what's the best way to do this?

I found that the best way to execute a DML statement on a limited number of rows based on specific ordering is actually by updating the subquery itself. This ability in SQL Server is not trivial to all DBAs, which is a shame. Here's an example of what I mean:

UPDATE TheSubQuery SET Col1 = Col1 + Col3
FROM (
SELECT TOP(100) Col1, Col3
FROM MyTable
ORDER BY Col2 DESC
) AS TheSubQuery

Note that I need to select in the subquery all the columns used outside the subquery (such as Col1 and Col3). All the data that you're using outside the subquery must be available (so, suppose you perform a JOIN with another table, the columns used in the join must also be queried in the sub query).

Notice how I'm accessing the table only once (you can see it in the execution plan), and obviously not doing any self-joins as a result of that.

This method works similarly using CTE:

WITH TheCTEQuery
AS
(
SELECT TOP(100) Col1, Col3
FROM MyTable
ORDER BY Col2 DESC
)
UPDATE TheCTEQuery SET Col1 = Col1 + Col3
FROM TheCTEQuery

And even by creating a VIEW instead of the subquery, and updating that view:

CREATE VIEW MyView
AS
SELECT TOP(100) Col1, Col3
FROM MyTable
ORDER BY Col2 DESC
GO
UPDATE MyView SET Col1 = Col1 + Col3
FROM MyView

The result and performance of all three methods are practically the same.

Again, all of the above is relevant to DELETE statements as well.

Conclusion

It is indeed a shame that Microsoft added the TOP keyword to DML statements but castrated it this much, since the combination of TOP and ORDER BY seems quite trivial. So until this ability will be built-in, I hope you can make good use of the above workarounds that I've showed you.

How To:
Remove the IDENTITY property from an existing column using T-SQL

(without changing the order of the columns or moving the data into a new table)

Recently I had a scenario at a client where I needed to remove the IDENTITY property of a column in an existing table. The two common methods to do this were quite problematic and were no good for us:

1.       Move the data into a new table

This is the most common method, and it's the one performed behind the scenes when you try to remove the IDENTITY property using SQL Server Management Studio.

Algorithm:

1. Create an identical new table (excluding the IDENTITY property) with a temporary name.
2. Copy/move all the data from the old table to the new one.
3. Rename the tables to replace the old with the new.

Problem:

The main problem with this method is that it's a pain in the a** if your table is huge. It could take hours to move or copy the data between the tables, and it's especially a problem if your table needs to be operational 24/7 (as was the case with my client).

 2.       Add a new column

This is the second most common method, and it's the one most commonly found on the internet when looking for solutions to the problem of the previous method.

Algorithm:

1. Add a new column with a temporary name, with identical properties as the identity column (besides the IDENTITY property of course).
2. Execute an UPDATE statement to set the value of the new column to the value of the identity column in each row.
3. Drop the identity column.
4. Rename the new column to replace the original identity column.

Problem:
The problem is that the only way to add a new column to a table without recreating the entire table is to the end of the column list. This means that if your identity column was first in the columns list, it will be the last after the above algorithm is executed. You can't add a new column using ALTER TABLE… ADD … in the middle of the column list.

Most of my client's stored procedures relied on the order of the columns. Then it's easy to see that this method is also out of the question.

Then I came up with a workaround that worked extremely well.

The workaround: ALTER TABLE… SWITCH TO…

After coming up with this workaround, I was surprised that it's not more commonly used. I tried to look in the internet to see if anyone else came up with this, and found around 2-3 sites and blogs that mention this method. Also, it's practically impossible to find these sites unless you know exactly what to look for.

 Algorithm:

a.  Create a new table with a temporary name, identical to the original table (excluding the IDENTITY property).
Let's assume the name of our original table is "OriginalTableWithIdentity", and the name of our new table is "NewTableWithoutIdentity".

b.  Execute the following command:

ALTER TABLE OriginalTableWithIdentity SWITCH TO NewTableWithoutIdentity

c.  Rename the tables to replace the old with the new (using sp_rename).

Restrictions:

1. This method only works in SQL Server 2005 and newer. It won't work in SQL 2000 and older.
2. The SWITCH TO command has several restrictions (most notably regarding foreign keys and indexes). Please visit here for more information about this command: http://msdn.microsoft.com/en-us/library/ms191160(v=SQL.90).aspx

What SWITCH TO does is simply changing the meta data of the partition underlining the table, by changing the ownership on the block of data to another table. There's no data movement or modification involved at all.

Although this command is related to partitions (a feature which is available in Enterprise edition only), the SWITCH TO command actually works in all other editions of SQL Server as well. So even if you have Standard edition it will work just fine (I didn't test it in other editions though, but I think it should work, so let me know if it doesn't).

Using this method, I was able to remove the identity property instantly and efficiently, and without locking the table for more than several milliseconds.

If you have any comments let me know!

אהלן חברים, שמי איתן בלומין.

את דרכי בעולם ההיי-טק התחלתי בתור מתכנת אתרים חובבן עוד בתקופת התיכון.
בעקבות גיוסי לצבא וכניסתי למסלול ממר"ם, זכיתי לרכוש מיומנויות רבות בתחום התכנות (וביניהן גם DB באופן כללי), וחיזקתי את כישוריי בלימוד עצמי.
לעולם בסיסי הנתונים בכלל, ו-SQL Server בפרט, נכנסתי כבר בסיום הקורס כשתקופת השירות שלי התחילה באופן רשמי.
במהלך השירות הצבאי, כולל תקופת קבע של שנתיים וחצי, צברתי כשש שנים של ניסיון מעשי נרחב בעולם ה-SQL Server והשתכשכתי בכל התחומים הקשורים אליו.

ל-Madeira "אותרתי" עוד כשנה לפני השיחרור שלי, והצטרפתי לחברה כמעט מיד אחר כך.
במהלך עבודתי עבדתי עם חברות שונות ברחבי הארץ, נתקלתי בהמון מקרים מעניינים, שעליהם אשמח לכתוב בבלוג בזמן הקרוב (ובעתיד הרחוק).

ניתן למצוא אותי מדי פעם משוטט בפורום הרשמי של SQL Server הישראלי (של MSDN) עונה לשאלות כשאפשר, וכמובן ניתן ליצור איתי קשר אם ברצונכם לשאול שאלות.

נשתמע בקרוב…