Many kudos goes to Jonathan and Annette Allen and the others on the team for confirming SQL Saturday 194 in Exeter on the 8th and 9th of March. The event home page is here http://www.sqlsaturday.com/194/eventhome.aspx and I delighted that myself and Dave Morrison will be presenting a full day pre-con on the 8th on favourite subjects “TSQL and Internals”.
Here is the full abstract :
TSQL and internals - When faced with performance issues there are many lines of attack. Tuning the engine itself can get you so far, however for maximum effect you need to understand how the engine and how it translates SQL statements into performable actions. This is not a simple task, it is a massive task to deal with a multi-table join and the number of permutations can be immense.
To back up this knowledge, we can create better performing TSQL and understand the impact that is has upon the engine and recognize the pitfalls and gotcha’s that exist in SQLServer. Ultimately, there is no ‘best way’ to perform a single task only many variations of ‘it depends’ , but now we can pick the most appropriate option for the required dataload.
Over the years, there have been many myths and misconceptions have grown around the product, some have basis in older versions and some are just wrong. Continuing to build on the knowledge given so far these issue will be explored and broken down and proved or disproved. Finally we will look to the future and explore SQL Server 2012 and the new functionality that that brings and some of the common uses that we will be able to address.
After completion of this days pre-con, attendees will have a more complete knowledge of execution plans, and how they relate to the physical and logical actions that SQLServer will be executing on their behalf. The attendees will also have a more rounded and fuller knowledge of TSQL and the implications of incorrectly defining a query.
Dave is a fountain of knowledge on execution plans and optimizer internals and ,though i may flatter myself, I’m no shrinking violet when it comes to TSQL and such matters. I hope that if you cant join us, then there are other pre-cons available from other experts in their fields that may ‘float you boat’ too. The pre-con page is http://sqlsouthwest.co.uk/SQLSaturday_precon.htm
Also, excitingly, this pre-con day is sponsored by Fusion-IO which is a great boon for the day.
If you want a more of this then i am offering a 2 day TSQL course starting on the 19th of March. More details on this are available here
As we are all aware, there are a number of traceflags. Some documented, some semi-documented and some completely undocumented. Here is one that is undocumented that Paul White(b|t) mentioned almost as an aside in one of his excellent blog posts.
Much has been written about residual predicates and how a predicate can be pushed into a seek/scan operation. This is a good thing to happen, it does save a lot of processing from having to be done. For the uninitiated though:
If we have a simple SELECT statement such as :
the process that SQL Server goes through to resolve this is :
The index IX_Person_LastName_FirstName_MiddleName is navigated to find the first “Smith”
For each “Smith” the middle name is checked for being a null.
Two operations!, and the execution plan doesnt fully represent all the work that is being undertaken.
As you can see there is only a single seek operation, the work undertaken to resolve the condition “MiddleName is not null” has been pushed into it. This can be seen in the properties.
“Seek predicate” is how the index has been navigated, and “Predicate” is the condition run over every row, a scan inside a seek!.
So the question is: How many rows have been resolved by the seek and how many by the scan ? How many rows did the filter remove ? Wouldn’t it be nice if this operation could be split ? That exactly what traceflag 9130 does.
Executing the query:
That changes the plan rather dramatically, and should be changing how we think about the index seek itself. The Filter operator has been added and, unsurprisingly, the condition in this is “MiddleName is not null”
So it is now evident that the seek operation found 103 Smiths and 60 of those Smiths had a non-null MiddleName.
This traceflag has no place on a production system, dont even think about it