Major Myths About Microsoft SQL Server

Tempdb Parasites
Jason Hall
Dir. of Client Services @ SQL Sentry
[email protected]
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
Table Variables
Query Plan Operations
LOB Variables
Eager Writes
Not 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
• 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
Fumigating 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
Query Plan Operations
Cursors & Triggers
• Cursors
• Keyset cursors store their keyset in a tempdb table and
static cursors store the entire result set in a tempdb
• 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
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
Eager Writes
• Post by Bob Dorr:
• Bottom Line
• In SQL Server 2014 and 2012 SP1 CU10, bulk
operations in tempdb, including select into [email protected],
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.
Tested By – Kendra Little:
A 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
• Read this:
• Be mindful of correct sizing, parasites affect this
Wrap Up
1. Check out
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 Parasites
Jason Hall
Dir. of Client Services @ SQL Sentry
[email protected]

similar documents