As I understand, you have the local disk instead of SAN. In this case, I think you may use the following recomendations:

1. As with any other database, placing data file and log file on separate disks may improve performace.

2. Check the number of processors on the server installed and divide tempdb into multiple data files of equal size. These multiple files don’t necessarily be on different disks/spindles unless you are also encountering I/O bottlenecks as well. The general recommendation is to have one file per CPU because only one thread is active per CPU at one time.

Look ath article "Compilation of SQL Server TempDB IO Best Practices", there is lot of another recomendations.

As I understand, you have the local disk instead of SAN. In this case, I think you may use the following recomendations:

1. As with any other database, placing data file and log file on separate disks may improve performace.

2. Check the number of processors on the server installed and divide tempdb into multiple data files of equal size. These multiple files don’t necessarily be on different disks/spindles unless you are also encountering I/O bottlenecks as well. The general recommendation is to have one file per CPU because only one thread is active per CPU at one time.

Look ath article "Compilation of SQL Server TempDB IO Best Practices", there is lot of another recomendations.

As I understand, you have the local disk instead of SAN. In this case, I think you may use the following recomendations:

1. As with any other database, placing data file and log file on separate disks may improve performace.

2. Check the number of processors on the server installed and divide tempdb into multiple data files of equal size. These multiple files don’t necessarily be on different disks/spindles unless you are also encountering I/O bottlenecks as well. The general recommendation is to have one file per CPU because only one thread is active per CPU at one time.

Look ath article ["Compilation of SQL Server TempDB IO Best Practices"][1], there is lot of another recomendations. [1]: http://blogs.msdn.com/b/cindygross/archive/2009/11/20/compilation-of-sql-server-tempdb-io-best-practices.aspx

As I understand, you have the local disk instead of SAN. In this case, I think you may use the following recomendations:

1. As with any other database, placing data file and log file on separate disks may improve performace.

2. Check the number of processors on the server installed and divide tempdb into multiple data files of equal size. These multiple files don’t necessarily be on different disks/spindles unless you are also encountering I/O bottlenecks as well. The general recommendation is to have one file per CPU because only one thread is active per CPU at one time.

Look ath article "Compilation of SQL Server TempDB IO Best Practices", there is lot of another recomendations.