Number of TempDB files if we can't use parallelism Currently we have 4 cores and 4 tempdb files.  I just came on as the DBA about 2 months ago and, for some reason, 3 of the tempDB files are 2GB and 1 is 1GB.  Obviously, that is not best practice.

Being the OCD and proactive person that I am, I want to resize that file to match up with the other 3.

But wait, there's more.  It's used on a system that has an application that gains performance by NOT using any parallelism, so we have it disabled. MAXDOP = 1, cost threshold = 0.  It's the only application on the system and the SQL isntance is basically designed for this one application.

What are everyone's thoughts on this?  Will it help with any slowdowns that were seeing, given that our MAXDOP = 1?  Also, what implications/issues should I be on the lookout for when I change the file size?  I'll be doing it at night, off production hours.

Thanks for the help guys.
Individual queries don't use parallelism? So what? If you have two completely different users running different queries at the same time, they too can make use of different tempdb files.

Of course it doesn't help all that much if you have four tempdb files all on the same volume - the real gain is when you can spread it out into multiple I/O paths.

Hard to speculate on "any slowdowns you're seeing" without more details.

Shouldn't be any issues with changing the file size. Just make sure they are all exactly the same size, have the exact same autogrow settings, and check to see if you should run trace flags 1117 and 1118.