September 13, 2012 at 12:27 pm
Another post got me thinking, so I figured I should post....
What do you think about SAN LUNs? My storage guys here just gives me LUNs for each SQL component(tempdb, data files, log files, system dbs, backups) Technically it's 5 different LUNs but they all live on the same physical array. I think it would be better to set up a physical array on the SAN that is used ONLY for SQL logs and then create LUNs on that array for the logs of all of the SQL instances. Really, the logs are the only component that is sequential, correct? The rest of the LUNs could all exist on the same physical array?
Really, in the end I guess it comes down to I/O latency. If I'm not seeing any latency, then I guess it doesn't matter? I'm not sure of the exact specs, but I think each physical array on our SAN has 24 physical disks, not sure how many spindles and heads are in each though. So I guess each LUN is accessing all of those disks.
September 14, 2012 at 2:16 am
scogeb (9/13/2012)
Another post got me thinking, so I figured I should post....What do you think about SAN LUNs? My storage guys here just gives me LUNs for each SQL component(tempdb, data files, log files, system dbs, backups) Technically it's 5 different LUNs but they all live on the same physical array. I think it would be better to set up a physical array on the SAN that is used ONLY for SQL logs and then create LUNs on that array for the logs of all of the SQL instances. Really, the logs are the only component that is sequential, correct? The rest of the LUNs could all exist on the same physical array?
Really, in the end I guess it comes down to I/O latency. If I'm not seeing any latency, then I guess it doesn't matter? I'm not sure of the exact specs, but I think each physical array on our SAN has 24 physical disks, not sure how many spindles and heads are in each though. So I guess each LUN is accessing all of those disks.
Carving out LUNs on the same disks will just create multiple I\O queues to the same array.
Creating an array for log based LUNs with similar I\O patterns is one way. It all depends on the size of the cache to and how its configured as essentially the cache should negate the disk performance. This is a well blogged topic with many different takes on what is and is not correct.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
September 14, 2012 at 6:42 am
I have been using databases on large SAN's for about 15 years. A well managed SAN should not need DBA's to micro manage for hot storage. Typically I request LUN's for data, log, tempdb data, tempdb log, backup and installation. I might fragment data and log based on space growth requirements more than performance requirements. This break down is to allow the SAN administrators to move hot LUN's.
Most of the time you do not have multiple SAN arrays to write to so trying to break log, data, tempdb, backup, indexes etc over multiple arrays is not an option. The idea of having a dedicated array just for log would probably be a bad idea as this would potentially be an extremely high write array, maybe if you had all SSD disks in the array it would be feasible.
Most SAN's have write cache which provide sub 5ms write times. If this is exceeded then the SAN administrators need to organise redistribution. The best idea is to talk frequently with the SAN administrators and understand what performance metrics they can provide you and what capabilities your SAN has. Talk to them and explain your requirements and come up with a compromise. This is not a one of task it is a reoccurring activity.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply