Using Synonyms to Decouple

Synonyms were first introduced in SQL 2005 and prove to be a great feature so far. What they basically do is decouple the database you are working in from other databases or objects you reference. This helps because it allows you to move objects (tables, procedures) to other locations without having to change the existing objects that reference them. I used this recently in a project where I implemented a new system within an existing system. From a purist standpoint, the system should be on it’s own, but since there was no time to create subscriptions, we implemented it where most of the data was. While I did not like this method, I still to reference the data that should be external via synonyms. To create a synonym, you can either use the dialog, or code. The dialog is pretty intuitive. Synonyms are created within a database, so expand the database and right click on Synonyms. Once you do that, a dialog pops up: Synonym Name Akin to the table or procedure name Synonym Schema Akin to the schema Server Name Server to reference, blank for current Database name Database to reference Schema external schema to reference Object Type [Drop down values] Object Name [Drop down values] And the code to create a synonym is: [cc lang=”sql”] CREATE SYNONYM [Subs].[Employees] FOR [ServerX].[AdventureWorks].[dbo].[Employee] [/cc] Reference it in your code the same way you do a table: [cc lang=”sql”] SELECT * FROM Subs.Employees [/cc] *Intellisense doesn’t work with it as of this […] Continue reading ...

Using NOT IN with NULL values

I’m writing this out of a revelation that when querying to see if a particular value is NOT IN a column that contains NULLS, you will not get the correct result set back.  This is somewhat distressful because you would expect when a specific value is not in the result set, then the query would return so.  Well, unfortunately that’s not the case.  Let’s look at an example: [cc lang=”sql”] — Insert two values (null and 1) SELECT VAL INTO #HASNULL FROM ( SELECT VAL = NULL UNION SELECT VAL = 1 ) t SELECT 1 WHERE 5 NOT IN (SELECT VAL FROM #HASNULL) [/cc] From above, we see that we create a table named #HASNULL and insert two values, a one and a null. So when we query to see if the value 5 is in the result set, it should return a 1. But it does not. A little scary. While there may be a logistical reason for this, I’m not able to see it. Let’s just make sure that the null is the problem. So, let’s delete the NULL and re-query: [cc lang=”sql”] DELETE FROM #HASNULL WHERE VAL IS NULL SELECT 1 WHERE 5 NOT IN (SELECT VAL FROM #HASNULL) [/cc] There we have it. Now we see that a 1 is returned. This brings me to my next point. Use Exists when checking for existence. [cc lang=”sql”] SELECT 1 WHERE NOT EXISTS ( SELECT 1 FROM #HASNULL WHERE VAL = 5 ) [/cc] As most developers […]

Finding the Slowest Query using the Execution Plan

If you’ve stumbled upon this post, then you’re likely at a point where you’ve got a crap query that is slowing you down. This article tells you how to find that one slow query, within a procedure. You also probably know that the execution plan is what you need to use to find out how to fix it, so let’s set that up. First, enable the execution plan: From the SSMS menu, select: Query » Include Actual Execution Plan Ok, so there you’ve enabled it for the session (or window). It is going to be enabled until you close the window or turn it off. Now let’s execute this procedure and see what is slow. [cc lang=”sql”] EXEC dbo.MyCrappyProcedure [/cc] Ahh.. so now that I’ve executed the procedure and it completed, I see this new weird tab on the output pane labeled “Execution Plan”. Select on this new tab. You should see something like this: Now let’s look at each section that states: Query x: Query cost (relative to the batch): x% Hmm.. so if the entire procedure equals 100%, then each of these individual SQL statements shown equal the other x% that is shown? Yep, that’s how it works; on paper at least..  The cost is somehow calculated by SQL Server by probably combining resource usage (CPU, IO, Time etc.) So that’s how you find the most offending SQL Statement. Now in order to begin the troubleshooting it you’ll have to look at the execution plan for that  statement. Continue reading ...

How to Optimize a Stored Procedure using the Execution Plan

Find the most costly statements Determine why the statement is costly Get an accurate baseline for the procedure Optimize Find the Most Costly Statments There are two main ways to determine costly queries. One is to execute the procedure including an Actual Execution Plan. The other is to get a time difference of a before and after for each statement.  The are also other ways (including IO usage and CPU usage but we won’t cover those here). I like to start with the execution plan method. Though this is not the most precise method, it is the easiest.. so let’s start there. Here is how to find the slowest query in a procedure using the execution plan. Determine why the statement is costly This can be them most difficult task. With the use of the execution plan, we can help deduce the most common issues. Now that we’ve found the statement, we need to drill down even further to find out what is causing the statement to be slow. This is done by looking at the cost for each operation in the execution plan. Under each operation, you will see a “cost: x%”. You want to find the operation with the highest percentage and focus on that. When you do find it, many times it will be one of the following operations: Interpreting the Execution Plan Symptom Cause(s) example Table scan, index scan, clustered index scan Missing or improper Indexes, cardinality < 5% thick lines (arrows) from one operation to […]