Secrets of SQL Server Execution plan (1/5)

In this blog we are going to see some basic things on how to interpret a execution plan for a query . The first first step on enhancing a query for optimal performance is to understand the query execution on cost basis , which part of the of the query is costly and which part is not . To do so, SQL Servers query execution plan is the best choice, by which we can point out which part of our query is more costlier.

Learning a query execution plan is like learning a new language, which is iconic language. Just explaining each and every icon of this language will be wage for you. More things on execution plan can be garbed while practicing it .

Before dive deeper into the subject , we should know the limitations of the execution plan. Execution plan doesn’t tell you below things

• Locks acquired
• Wait statistics
• Data is in the cache or not
• Not a replacement of SET STATISTICS IO
• Not a replacement of SET STATISTICS TIME

Below are some easy usage ways to get full benefit of the execution plan

“We have to read the execution plan from right to left and from down to top”. 

I am using AdventureWorks2008 database on my examples. In this blog we will see only some basic things and spice up things on the coming series

Query execution plan secrets

Haja Batcha

As part of my Job i was optimizing a Data warehouse query which builds the update for the Fact table . The query Contains numerous update statements. Run The query and it took 365 Seconds to complete .

I saw the Execution plan , there is no missing index and most of the thinks looks normal at the First glance.Hence i had too many update statements i was puzzled, there is no missing index showing from the execution plan. A Big question mark. Didn’t gave up and continued about which update is causing me the trouble, best thing i did was. I Started executing one by one. From among the updates , one of the update statement took more than 340 seconds . So i got the area where i need to do my analysis .

Breaking a query into smaller parts and examine one by one helped me in lot of cases . So a part which gave a challenge is a single update statement,  updating the a  value to a column based on the numerous case statements.

This image throws me big hint. Resembling update on your clustered index. I saw the execution plan and noticed 75% cost on updating the clustered index , also this update statement affects 15 Lacks records .

Performance Improvements in SQL 2014(3/4)

Hi dears, so for we have seen about the incremental update statistics and index enhancement on our previous blog post.

Now we will see about, how SQL server 2014 can cache temp tables.  Before we move further into the subject, will see about temp tables in crisp. These are the tables created at the run time and  these tables are created within the “tempdb” database.  To identify a table as a Temporary Table within the SQL statement, prefix the table name with the “#” character. And also we should know one more fact the caching is not per procedure , the caching is per objects.

SQL Server 2014 has given us some room, by which if we make our temp table in a proper way the temp table can be cached. We will see how this is possible.

Analyzing the indexes using DMVs

Hi,

This article is about assessing the index, regarding which one is needed and which one is not.  By the way it willbe  helpful for intermediate level guys on SQL Server

SQL Server has no magic to improve the performance of your query, it is the correct utilization of indexes which will do the magic for you. We are going to do our assessment based on Dynamic Management View(DMV)  which is  the out of box feature from SQL Server 2005 on wards.

We should know one common fact regarding DMVs, the informations obtained on a DMV will last upto the restart of that instance. So it is the best practice to store those information on a table periodically.

Here we go, we are going to do our assessment based on below DMV

sys.dm_db_index_usage_stats

SELECT db.name AS [database] ,

ob.name [table],

ix.name [index],

dm_ix.user_seeks ,

dm_ix.user_scans ,

dm_ix.user_lookups

FROM sys.dm_db_index_usage_stats dm_ix

INNER JOIN sys.databases db ON db.database_id = dm_ix.database_id

INNER JOIN sys.indexes ix ON ix.object_id = dm_ix.object_id

INNER JOIN sys.objects ob ON ob.object_id = dm_ix.object_id

WHERE ob.type = 'U'

Now we are done, the above SQL will show you the database name, table name, and what are all the index exist etc.  Now we should concentrate on below threee columns

• user_seeks
• user_scans
• user_lookups

user_seeks :-  A seek is when the index is used, as an index, to retrieve data. The key values and the b-tree that make up the index are referenced to find exact values and locations within the index.

user_scans:- A scan is when the index is used, well, like a stack of papers. They’re gone through one at a time to find the interesting values. Needless to say, in most situations, seeks are preferable to scans.

user_lookups:- Number of bookmark lookups by user queries.

You can filter the results of one database by using database id on the where class.

Feel free to pass your comments and feedback.

Performance Improvements in SQL 2014(2/4)

Haja Batcha

Hi dears, on my previous blog we saw about a enhancement regarding a update statistics on SQL 2014. Will see yet another enhancement on SQL Server 2014 which is non clustered indexes on temporary table, and which can also be called inline indexes.

“Non clustered indexes on table variable”

First we will see ‘Which is not possible in previous edition, which is now possible in 2014′ secondly we will see ‘Which is possible in previous edition, which can be coded very easily’  

The table variables are one the wonderful feature which was introduced on SQL Server 2000. Because with table variable excessive recompilation will be avoided, it doesn’t need statistics when you create them. And the one big disadvantage was, you cannot create non clustered index on them, that too resolved from SQL Server 2014 CTP1 .

With SQL Server 2014 CTP1 , now it is possible to create Non Clustered Index on table variable.

Performance Improvements in SQL 2014(1/4)

Hi dears, it is always nice to know something new. Would like to start with a wisdom i like “Learning brains will stay younger”. It is always advised by many performance tuning expertise,

“Update Statistics before you take any other steps to tune performance”.

SQL server 2014 has new feature called incremental statistics. Really it was a nice a feature, if you are having your tables spread into many partitions. Tables on single partition won’t be benefited by this feature.  Before we know about this feature, will have a glance about Update statistics, if you did’t update statistics on the database. The query optimized will struggle to give you best execution plan, which will ruin the performance of your query for sure.

Sales Data Partitions January Partition1 February Partition2 March Partition3

Now we will see about the new feature, imagine you have a table exist over partitions. which will fill the data monthly on every partitions. For example, sales data will filled into the Sales table as given below.

Now the tables will populate the data as given above, in the middle of march you would like to make update statistics on this table.Given below is normal update statistics before SQL Server 2014.