No, you should not move the tempdb and logs off of the SAN. What you need to do is look at the SAN and see what sort of IO your disk is getting. How is disks are in the RAID 10 array? You may need to add some disks. What other things are sharing the disks that this LUN is on? You can also try lowering the amount of cache the SAN uses for read cache which will then increase your write cache. Your write cache may be getting full, which should be the only time that your writes should ever actually be going to the disk. You might want to check out a session I gave over the weekend about SAN configuration. You can find the Power Point <a href="http://itknowledgeexchange.techtarget.com/sql-server/socal-code-camp-slide-decks-and-sample-code/">here</a>. ---------- Do you have specific evidence that your SAN is the cause of your problems? While the storage subsystem is often a contributor to database performance problems, you'd really want to get hard data before doing anything. Also, performance problem or bottleneck can mean a lot of different things. Are you suffering from contention? fragmentation? IO saturation? insufficient throughput? Hotspotting? Perfmon is the best place to start followed closely by waitstats. There aren't many hardware related perf issues that can't be identified using the two.

No, you should not move the tempdb and logs off of the SAN. What you need to do is look at the SAN and see what sort of IO your disk is getting. How is disks are in the RAID 10 array? You may need to add some disks. What other things are sharing the disks that this LUN is on? You can also try lowering the amount of cache the SAN uses for read cache which will then increase your write cache. Your write cache may be getting full, which should be the only time that your writes should ever actually be going to the disk. You might want to check out a session I gave over the weekend about SAN configuration. You can find the Power Point <a href="http://itknowledgeexchange.techtarget.com/sql-server/socal-code-camp-slide-decks-and-sample-code/">here</a>. ---------- Do you have specific evidence that your SAN is the cause of your problems? While the storage subsystem is often a contributor to database performance problems, you'd really want to get hard data before doing anything. Also, performance problem or bottleneck can mean a lot of different things. Are you suffering from contention? fragmentation? IO saturation? insufficient throughput? Hotspotting? Perfmon is the best place to start followed closely by waitstats. There aren't many hardware related perf issues that can't be identified using the two.