David Benoit (2/14/2011)
One question too; how are they determining that tempdb needs to be put on local drives? Why not properly configure a SAN presentation to support the activity?
They had a nice shiny new SAN installed to improve performance, but nobody told them that to get the volume they were using 600GB drives, the result is SQL is sharing disk resources with things like Outlook and half a dozen other applications. Their system architect thinks moving the high IO TempDB files off the SAN may help.
The SAN administrators feel the SAN isn't the issue. To some extend I must agree, the vendor is running an old version of JDE on SQL 2005 SP2. The DB is 600GB, but still all in one data file, they are also using non-JDE apps to access some of the data and they are struggling to get through month ends.
One problem is the server is old hardware, so can't take SSDs. The local disk will have to be SCSI (NOT even iSCSI). We've raised the idea of putting SSDs in the SAN but it sounds like the cost is prohibitive.
Everything I've read says TempDB on local disk within a cluster isn't supported by MS and requires some hacking to get it to work. If anything turns to custard MS won't help much.