TempDB best practices

Continuing on from my post describing what SQL Server TempDB is used for, I wanted to write about tempdb best practices and how on a busy system, modifications to the default setup of tempdb and its placement can boost performance.

Some guidance points

  • Place tempdb on a separate disk to user databases. See my post on how to move tempdb.
  • Place tempdb on the fastest IO subsystem possible.
  • Size tempdb accordingly and configure autogrow. This is especially important if your system cannot tolerate performance degradation. If you size the database too small with autogrow enabled, tempdb will automatically grow according to the size increments you have set up. Imagine you have set it to grow in increments of 10Mb and you have a busy workload requiring tempdb to be used. If tempdb needs to expand a number of times to accommodate load, these sizing operations can generate lots of IO. Better to try and set your tempdb to be based on a staging server workload where you have witnessed how large it can grow.
  • Create multiple data files for tempdb, but how many? Allocate 1 data file per physical or virtual CPU core.
  • Keep tempdb data files equally sized and have autogrow increments configured equally across data files.
  • If your SAN administrator can provide it, split the multiple data files over different LUNs as opposed to holding everything on one LUN.
  • Configure the data files to be of equal size.
Please note that there will be many systems out there which have had no modifications done at all to tempdb and they run fine.

Whether you choose to apply all or some of these methods will largely depend on your budget and your knowledge of the system based on projected or analysed workload. I would recommend that for any system, that you try and size tempdb accordingly however.

It's only fair to share...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInPin on PinterestBuffer this pageShare on RedditShare on StumbleUpon
About Andy Hayes

Andy Hayes is a DBA working with SQL Server since version 7.0. He has a wonderful wife and two beautiful children. He loves database technology, playing cricket, and blogging. He is passionate about sharing his experiences as a DBA and learning more to further his understanding and knowledge. You can follow me on Twitter, check out my Facebook page or follow me on

Comments

  1. Great job Andy. I have been reading your articles from last week which I found very useful for the person from beginner to expert level in DBA field. I think you should publish a book of this articles and real life experiences faced by you as DBA. I will definitely buy it.
    Thank you so much.

    Sandeep.

  2. Great work andy keep it up 🙂

  3. I wonder about the tempdb transaction log. Is it advisable for it to also be on its own LUN, or can it be on the same LUN that all regular database transaction logs are written.

  4. Hi Andy Hayes,
    First, i would like to thank you for the articles. those are very helpful.
    I need some information regarding
    1. multiple tempdb files. even I configured multiple, only one is taking most of the disk space. can I know why & how to solve it.
    2. when tempdb used space will be cleared. It didn’t clear leading to out of disk space. I don’t prefer the sqlserver restart, because most of my operations are on mass data. please suggest me a way to clear tempdb, if it not using.

  5. Johnny Boy says:

    This article is nice – very simplistic, down to the basics, and not a lot of wording. I came here after visiting cc.davelozinski.com/sql/increase-sql-server-tempdb-performance and like how you keep your articles easy enough to read for us non DBA types. 🙂 My only suggestion for improvement is perhaps include some sample SQL scripts you use (if any). For example, when you created multiple data files for your tempdb.

Speak Your Mind

*


*