Does splitting out Data, Logs, and TempDB matter using a SAN with SQL 2008

I'm not a server admin. So be gentle. But I was just at a conference and in one of the training classes the Instructor explained some SQL DBA best practices. One of which was to separate out Mdf,Ldf, and TempDB onto different drives to increase performance.

Now at our office we have a san. The Sys Admins created 3 san drives one for data, one for Logs, and one for TempDB.

My intuition tells me that was a wasted effort...was it?

I don't know alot of the details, but if you ask i'll try to fill in any specs needed to answer this question accurately.

Database files, transaction log files and temporary data files are usually placed on different volumes to reduce I/O contention between them, and this can also be extended further by creating multiple data files for each database, spreading them across even more volumes and telling SQL Server where specific tables and indexes should be stored; so, yes, this is a common practice for DBAs, and can indeed lead to significant performance gains.

It is also true than it can become completely meaningless when using a SAN; depending on how that SAN has been actually configured, different LUNs (volumes) can be mapped to any set of phsyical disks, RAID arrays and storage controllers, and thus the I/O contention between two LUNs can range anywhere from "completely isolated" to "effectively sharing the same disks". So, unless the DBA is working closely together with the storage admin, asking for different LUNs in order to spread database files between them can indeed become a completely wasted effort.

However, separating database files and transaction log files is considered a best practice not only for performance, but also for reliability: due to the transactional storage engine being used by SQL Server (and to similar engines used by almost any existing DBMS), log files can be used to replay transactions in a disaster recovery scenario, enabling the system to recover what happened after the last backup was taken. But, in order for this to work, you don't want to lose data files and log files at the same time, so it's better to at least place them on different volumes, even if there is no performance gain from this.

The reason you separate the database files from the log files is because database access is random and log access is sequential. Best practice dictates that you don't mix those two I/O types on the same disk, regardless of how that disk is presented to the server (Local, DAS, iSCSI, etc.). So no, it wasn't a wasted effort.

As for tempdb, it seems to be Microsoft's recommendation that you separate that from the databases:

http://msdn.microsoft.com/en-us/library/ms175527(v=sql.105).aspx