Post reply

Separate Data Files, Log Files, tempDB, Backups, etc. onto separate LUNS on a SAN with High Speed Solid State Drives

  • January 9, 2015 at 4:32 pm

    #300178

    I proposed on a new server that we separate Data Files, Log Files, tempDB, Backups, etc. onto separate LUNS on a SAN with High Speed Solid State Drives.

    I was told that with the new technology with solid state SAN's that it would decrease performance and that it did not work the same way as it did when you had RAID 5's etc.

    I thought that if things were cared out correctly by a SAN Administrator they would know how to configure for optimal performance.

    Do I need to rethink?

    Thanks.:-)

    For better, quicker answers on T-SQL questions, click on the following...
    http://www.sqlservercentral.com/articles/Best+Practices/61537/

    For better answers on performance questions, click on the following...
    http://www.sqlservercentral.com/articles/SQLServerCentral/66909/

  • January 10, 2015 at 4:30 am

    #1769233

    You can't think about LUNs the same way you think about drives. They're not the same. Instead, the focus has to be in IOPS. What are you getting? If it's inadequate, then you start looking at breaking things apart and working with the SAN team to reconfigure drives where necessary. Otherwise, to a degree, with the modern technology, you can sort of dump things into a single location. But only as long as you've got the ability to measure and gauge in place.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • January 10, 2015 at 1:48 pm

    #1769257

    Still, there are some physics involved and people tend to forget that when it comes to SANs. The more sets of read/write heads and platters (collectively referred to as "spindles") you can bring into play, the faster things will run. The biggest problem with SANs is that hard drives are freakin' huge and it's real difficult to justify something like giving TempDB it's own harddrive(s) when the size of the smallest drive in your SAN is over 450GB.

    --Jeff Moden

    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply