Tempdb ParasitesJason Hall - Dir. of Client Services @ SQL Sentry

Email - jhall@sqlsentry.com

Twitter - @SQLSaurus

Blog - jasonhall.blogs.sqlsentry.net

Who am I?

• Director of Client Services @ SQL Sentry, Inc.• Microsoft Platform Developer Since 1998

• SQL Server Developer Since 6.5• Microsoft Certified <Insert Stuff Here>• Former US Army Paratrooper• Horror Genre Fan

2

Agenda

• Overview/Intro• Table Variables• Query Plan Operations• Cursors• Triggers• LOB Variables• Eager Writes

IntroductionNot terribly long ago I was working with a customer, and we discovered that their use of VARBINARY(MAX) to hold multiple large files as variables variables in a stored procedure was actually having a negative impact on the entire SQL Server instance by bloating the tempdb database. While they already knew the use of these variables was not ideal, they never considered that it might have such an effect on tempdb. This lead me to search for other “not so obvious” users of tempdb.

“Generic” table variables are not in –memory…• I say generic, because in SQL Server 2014 you can have

an in memory table variable based on a memory optimized table type. This requires a little more planning than “standard” table variables. In addition, in 2014 (and 2012 SP1 CU 10) the temp operations are not as likely to cause disk IO as before (more on this later)

• Generic table variables are stored in tempdb, always• May or may not be in memory, remember it depends on

where the tempdb pages are• Not efficient for large number of rows, no statistics

(SQL Server assumes 1 row), no indexes. Using these really earns you… not much

TABLE VARIABLESFumigating the myth

Query Plan Operations

• Sorts (including DISTINCT)• When this happens the full row set is stored in tempdb for

performing the sort operation. This is typically referred to as a spill, and in SQL Server 2012 you will see a warning about it in the execution plan.

• Hash (aggregates and joins)• In order to perform hash operations, you need a hash table.

If the hash table is big enough, it will be stored in tempdb.

• Spools (table and index)• In this case, the entire input for the operator is stored in

tempdb.

Query Plan OperationsExposed!

Cursors & Triggers• Cursors• Keyset cursors store their keyset in a tempdb table and

static cursors store the entire result set in a tempdb table

• Triggers• Since SQL Server 2005, triggers use the version store,

which is kept in tempdb. So, if you’re using triggers, they are implicitly using tempdb. Remember that triggers are set-based, and you’ll get version data for every affected row. For really big batches, this can turn out to be quite a bit of version data

CURSORS & TRIGGERSDeloused

LOB Variables

• If you have a variable holding a big XML document or maybe a parameter holding a large nvarchar(max), they can get stored as internal objects in tempdb

• Used liberally this can translate to a very real problem for the entire SQL Server instance

LOB VARIABLESExterminated

Eager Writes

• Post by Bob Dorr:• http://

blogs.msdn.com/b/psssql/archive/2014/04/09/sql-server-2014-tempdb-hidden-performance-gem.aspx

• Bottom Line• In SQL Server 2014 and 2012 SP1 CU10, bulk

operations in tempdb, including select into #tbl/@tbl, may not be written to disk as often by the checkpoint process and/or lazywriter. This results in a performance boost by allowing more of these operations to remain in buffer for the lifetime of their use.

EAGER WRITESTested By – Kendra Little:

http://www.brentozar.com/archive/2014/04/memory-ssd-tempdb-temp-table-sql-2014/

BEST PRACTICESA preemptive strike against parasites!

Best Practices

• Depends a lot on how tempdb gets used• Avoiding tempdb contention• A note from Jon Kehayias & Bob Ward: As a general rule, if the

number of logical processors is less than 8, use the same number of data files as logical processors. If the number of logical processors is greater than 8, use 8 data files and then if contention continues, increase the number of data files by multiples of 4 (up to the number of logical processors) until the contention is reduced to acceptable levels or make changes to the workload/code.

• Read this: http://bit.ly/1v4fUs3• Be mindful of correct sizing, parasites affect this

Wrap Up

1. Check out http://www.sqlperformance.com/

2. PLEASE stop by and thank the sponsors. Yes they are here trying to sell stuff, but they are also giving up their weekend to sponsor this event, and they don’t even get to attend sessions (sad face).

3. Make sure and thank the event organizers for their heroic efforts in putting this SQL Saturday together!

Tempdb ParasitesJason Hall - Dir. of Client Services @ SQL Sentry

Email - jhall@sqlsentry.com

Twitter - @SQLSaurus

Blog - jasonhall.blogs.sqlsentry.net