Using NOEXPAND Hints

Paul White expands upon NOEXPAND:

There is another consequence of not using the NOEXPAND hint, which I mentioned in passing a couple of years ago in my article, Optimizer Limitations with Filtered Indexes:

The NOEXPAND hints are needed even in Enterprise Edition to ensure the uniqueness guarantee provided by the view indexes is used by the optimizer.

If you use indexed views in your environment, read this article.

Parameterizing Procedures

Monica Rathbun shows how to combine several report queries:

I try to parameterize as many stored procedures as possible. This not only minimizes the amount of procedures I need to maintain, it in my opinion is a much cleaner way to code. It disturbs me when I see multiple stored procedures that pull the exact same data, but may have slight differences between them. Whether it be a sort, a where clause, or even just an extra field or two that makes it different, some developers think you need a different procedure for each one . Why not consolidate and parameterize?

The next step might be using dynamic SQL to build a query if there’s as much overlap as we see in Monica’s example.

Where Am I?

Kevin Feasel

2015-12-23

T-SQL

Kenneth Fisher shows how to use DB_NAME() and DB_ID():

I actually use them this way on a somewhat regular basis when I don’t want to have to tie back into sys.databases to just get the database name. And also in the WHERE clause when I want to restrict based on a database name.

It’s important to know where you are.  Also, where your keys are.

Optimizing Update Queries

Paul White has an article.  Read it:

The point is that there is an awful lot more going on inside SQL Server than is exposed in execution plans. Hopefully some of the details discussed in this rather long article will be interesting or even useful to some people.

It is good to have expectations of performance, and to know what plan shapes and properties are generally beneficial. That sort of experience and knowledge will serve you well for 99% or more of the queries you will ever be asked to tune. Sometimes, though, it is good try something a little weird or unusual just to see what happens, and to validate those expectations.

Optimizing update queries seems trivial at first, but as Paul shows, we have a few more tools at our disposal than is apparent at first glance.

Table Sampling

Kevin Feasel

2015-12-17

T-SQL

Ginger Grant shows a couple of techniques for sampling from tables:

The random sample that TABLESAMPLE provides is based on the number of data pages, not the number of records. If you want the number of rows to be specifically limited you will need to use Top(n) as well. I’ve written all my samples based upon AdventureWorksDW so you can run them for yourself later. I’ve listed the variety of ways to call TABLESAMPLE and shown the number of records returned.

TABLESAMPLE is useful for spelunking, but is somewhat limited otherwise.

Dynamic Pivoting

Kevin Feasel

2015-12-16

T-SQL

Michael Bourgon has a pivot script:

Say you have records from your monitor that happens to Track EventLogs.
We’ll call it EventLog_Tracking for argument’s sake (hint hint http://thebakingdba.blogspot.com/2015/05/powershell-eventlogtracking-capturing.html) and want to look at trends over time.

Dynamic pivoting is possible (I have an example en passant in a tally table presentation I created a couple years back), but it’s not the easiest thing in the world.

Table Migration In SSDT

Ed Elliott shows us how to use pre-deployment and post-deployment scripts to migrate table data when the tables change:

You sometimes want to do things like split a table into two or move a column into another table and when you use SSDT or the compare / merge type of deployments it can be hard to migrate the data in a single deploy as you can’t insert the data into a table that doesn’t exist and you can’t drop the data before it has bee migrated. To fix this we can use pre/post deploy scripts in SSDT. The overall process is:

  • Pre-Deploy Script, check for column to be migrated

  • Save data in new table not in SSDT (you could have it in SSDT if you use it for multiple releases etc)

  • Let SSDT drop the column and create the new one – you will need to have the option set allow data loss on incremental deployments

  • In the post-deploy copyw the data to the new table

Using separate migration tables is an interesting solution to an old problem.

Categories

May 2017
MTWTFSS
« Apr  
1234567
891011121314
15161718192021
22232425262728
293031