I am planning a fresh installation of SQL Server 2005 on a new machine, which I have to order. I know that tempdb tuning is very important to the overall performance of the SQL Server instance.
I've read that it's best practice to create as many tempdb files as you have CPU's (or cores?). Is that correct? Are there any other recommendations, e.g. for harddisk/RAID setup configuration I should pay attention to?
Thanks!
If I had to pick one person that I trust for advice on configuring a server, it would be Denny Cherry. He wrote an article explaining this.
http://searchsqlserver.techtarget.com/tip/0,289483,sid87_gci1307255,00.html
Here is what I researched myself from a variety of sources.
In order to optimize tempdb performance pay attention to physical disk configuration, file configuration, as well as some settings within the database.
Physical disk configuration
tempdb should reside on its own dedicated physical disks. This allows it to split I/O transactions from the remainder of volumes on the SQL Server.
To move tempdb to a new disk drive, use ALTER DATABASE. It is the key T-SQL command to perform this operation. Microsoft offers a good example in SQL Server 2005 Books Online. The article name is ALTER DATABASE (Transact-SQL) and the specific section is 'G. Moving tempdb to a new location.'
The tempdb is a very high-write database. So, a RAID 5 array isn't the proper place for it. You should put the tempdb on either a RAID 0 or RAID 10 array as they're optimized for high-write applications. If you can afford additional RAID 0 or RAID 10 arrays for each physical database file for the tempdb, you'll get increased performance.
Database files
You should have one physical file per CPU core in the server. So, if you have a dual-chip, dual-core server, you should have four physical database files for the tempdb database. When adding more database files, it's important to configure the files at the same initial size and with the same growth settings. That way, SQL Server will write the data across the files as evenly as possible.
Database file size
The size of the tempdb database can affect the performance of a system. For example, if the size that is defined for tempdb is too small, part of the system-processing load may be taken up with autogrowing tempdb to the size required to support the workload every time you restart the instance of SQL Server. You can avoid this overhead by increasing the sizes of the tempdb data and log file.
Determining the appropriate size for tempdb in a production environment depends on many factors including the existing workload and the SQL Server features that are used. Microsoft recommends that you analyze the existing workload by performing the following tasks in a SQL Server test environment:
- Set autogrow on for tempdb (in a test environment!).
- Execute individual queries or workload trace files and monitor tempdb space use.
- Execute index maintenance operations, such as rebuilding indexes and monitor tempdb space.
- Use the space-use values from the previous steps to predict your total workload usage; adjust this value for projected concurrent activity, and then set the size of tempdb accordingly.
Minimum size recommendations for tempdb are as follows:
Envir. Size DB Size (MB) Log Size (MB)
----------- ------------ -------------
Small 1024 256
Medium 5120 1024
Large 10024 2048
Database settings
You can further increase tempdb performance by disabling the auto update stats, which will save your tempdb some work. You can also set the auto create statistics option to false.
Disclaimer: Settings should be changed with care. Depending on the kind of load you place on your tempdb, changing settings could adversely impact system performance.
To achieve optimal tempdb performance, follow the guidelines and recommendations provided in Optimizing tempdb Performance.
How to monitor tempdb usage?
Running out of disk space in tempdb can cause significant disruptions in the SQL Server production environment and can prevent applications that are running from completing operations.
You can use the sys.dm_db_file_space_usage dynamic management view to monitor the disk space that is used by these features in the tempdb files. Additionally, to monitor the page allocation or deallocation activity in tempdb at the session or task level, you can use the sys.dm_db_session_space_usage and sys.dm_db_task_space_usage dynamic management views.
These views can be used to identify large queries, temporary tables, or table variables that are using lots of tempdb disk space. There are also several counters that can be used to monitor the free space that is available in tempdb and also the resources that are using tempdb.
Links:
- Microsoft Technet: Working with tempdb in SQL Server 2005
- SearchSQLServer.com: SQL Server tempdb best practices increase performance
- MSDN library: Optimizing tempdb Performance
- SearchSQLServer.com: Configure SQL Server 2005 TempDB for performance
- MSDN library: Capacity Planning for tempdb
- MSDN library: Troubleshooting Insufficient Disk Space in tempdb
From what I've read, it's best to put tempDB on it's own physical disk (or array). For maximum speed, you could put in on a raid 0 array. However, if one of the disks fail, the DB server will become inoperative. If you want more redundancy, put it on a raid 10 array. The real key seems to be separating it from the other databases because there can be so much activity in TempDB.
How far you go really depends on the other databases on the server and whether they do a lot of work with Temporary tables, etc.
I haven't heard anything about multiple files based on the number of CPUs or cores.
See also this posting SQL Server Transaction Log RAID which contains a discussion on server layout that touches on some of the issues around tempdb.
i would recommend to create data files between 1/2 and 1/4 * number of cores. you should place these files on the fastest disk you have
for more information you can look here: SQL Server tempdb configuration
来源：https://stackoverflow.com/questions/360088/sql-server-tempdb-optimization-tips-for-a-new-server