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.
How to optimize tempdb
- 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.
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.
Thank you Sandeep. It’s really good to hear that you are finding these articles useful.
All the best, Andy
Great work andy keep it up 🙂
Thanks Yuvraj! 🙂
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.
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.
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.
Thank you for your comment Johnny! Glad you like the article. 🙂
Can we place Temp Data files in separate drive and Temp log file in seperate file? any advantage?