Tempdb Configuration Best Practices in SQL Server
By: Jeremy Kadlec | Updated: 2008-02-12 | Comments (10) | Related: More > DBA Best Practices
In SQL Server 2005, TempDB has taken on some additional responsibilities. As such, some of the best practice have changed and so has the necessity to follow these best practices on a more wide scale basis. In many cases TempDB has been left to default configurations in many of our SQL Server 2000 installations. Unfortunately, these configurations are not necessarily ideal in many environments. With some of the shifts in responsibilities in SQL Server 2005 from the user defined databases to TempDB, what steps should be taken to ensure the SQL Server TempDB database is properly configured?
In an earlier tip, we discussed sizing (Properly Sizing the TempDB Database) the TempDB database properly. The intention of that tip was to determine the general growth and usage of the database in order to determine the overall storage needs. In this tip we want to take a broader look at how TempDB can be optimized to improve the overall SQL Server performance.
What is TempDB responsible for in SQL Server 2005?
- Global (##temp) or local (#temp) temporary tables, temporary table indexes, temporary stored procedures, table variables, tables returned in table-valued functions or cursors.
- Database Engine objects to complete a query such as work tables to store intermediate results for spools or sorting from particular GROUP BY, ORDER BY, or UNION queries.
- Row versioning values for online index processes, Multiple Active Result Sets (MARS) sessions, AFTER triggers and index operations (SORT_IN_TEMPDB).
- DBCC CHECKDB work tables.
- Large object (varchar(max), nvarchar(max), varbinary(max) text, ntext, image, xml) data type variables and parameters.
What are some of the best practices for TempDB?
- Do not change collation from the SQL Server instance collation.
- Do not change the database owner from sa.
- Do not drop the TempDB database.
- Do not drop the guest user from the database.
- Do not change the recovery model from SIMPLE.
- Ensure the disk drives TempDB resides on have RAID protection i.e. 1, 1 + 0 or 5 in order to prevent a single disk failure from shutting down SQL Server. Keep in mind that if TempDB is not available then SQL Server cannot operate.
- If SQL Server system databases are installed on the system partition, at a minimum move the TempDB database from the system partition to another set of disks.
- Size the TempDB database appropriately. For example, if you use the SORT_IN_TEMPDB option when you rebuild indexes, be sure to have sufficient free space in TempDB to store sorting operations. In addition, if you are running into insufficient space errors in TempDB, be sure to determine the culprit and either expand TempDB or re-code the offending process.
Where can I find additional information related to TempDB best practices?
- Check out these articles in SQL Server 2005 Books Online:
- Based on this information, take a look at your TempDB configurations across your SQL Server environment and determine what changes are needed.
- As you spec out new machines, be sure to keep TempDB in mind. If you suspect TempDB should have its own disks, be sure to account for those as you purchase and/or configure your disk drives.
- If you have a standard SQL Server deployment checklist, be sure that it includes the items from this tip that make sense in your environment.
- Check out these related tips:
- If you have some additional tips and tricks related to TempDB, please share your knowledge with the community in the forum below.
Last Updated: 2008-02-12
About the author
View all my tips