LUNS, Data Paths, Sybase Devices, RAW
807557Jan 7 2009 — edited Jan 11 2009Hi All, I apologise if this topic has been done to death somewhere else on the forum, please simply redirect me.
Over the years I have worked for many firms where layers debate have raged between DBA, UNIX SA and Storage on the optimal storage configuration for a Sybase database. Unfortunately I have never worked in an environment where time / kit has been put aside to perform a collaborative end-to-end test to determine best practice.
The challenge
For the current firm we wish to define the optimal configuration for Sybase 15 using RAW devices attached to DMX.
Technical Statements
1) DBA TEAM Will define a Sybase devices for DATA, LOG, TEMPDB and DUMPS. For optimal database performance they request that LUN(s) have an affinity with each Sybase device and the LUNS should not be split between devices. This would be achieved by creating corresponding Veritas Disk groups and adding 1 or more LUNS to each group. RAW devices would then be created using whole LUNs and assigned to each Sybase device. The idea being that every LUN has its own logical data path (queue) by creating an afinity up/down the storage stack, this way we remove contention between Sybase devices on the disk queue.
2) UNIX TEAM Concur with the DBAs and believe that the O/S has a data path per LUN
3) STORAGE Advise that presenting the largest LUN size possible, slicing this into RAW devices and then mapping to Sybase devices will yield better performance
Question
1) Does having more LUNS provide more logical (within the OS) data paths to the disk i.e. drive the SAN harder.
2) Or, is it correct that the larger the LUN and leaving the SAN Frame to do its thing yields better performance.
We get the debate around physical spindles at the back end I guess its what reduces contention within the OS, 1 LUN or 5 (one for each Sybase device)
Any feedback or pointers to white papers would be greatly appreciated