February 25, 2011 at 7:40 am
I usually separate data / log / tempdb / backups onto separate luns. My questions are, if the disk group I pull from is say 50 drives of shared storage, what's the point of carving separate luns ? Does this help with the I/O in any way? Why don't I just dump everything into the same folder on one giant drive? Is there a benefit with multi-pathing or more cache availability? At one point I almost knew what I was doing, but now I'm not sure...Any suggestions or advice/links appreciated.
Thanks
Chris
February 25, 2011 at 7:56 am
Haha. You are funny.
One advantage is separate LUNs will allow for more control to tune which hot indexes go on specific isolated disk sets. With one giant set, you do get many benefits as you mentioned, but less control.
Jim
Jim Murphy
http://www.sqlwatchmen.com
@SQLMurph
February 25, 2011 at 8:10 am
But the separate luns would need to pull from different disk pools(or dedicated storage) to gain the benefit, correct? I'm at a new job and they share everything. The storage is tiered, but I don't even ask for a RAID level anymore. I say I need some storage, beg for a while, then I log onto the server and format the disks. Since it all pulls from the same shared set, does separating I/O do anything?
- on a side note, i just became a ssc rookie with this post...awesome.:cool:
February 25, 2011 at 8:25 am
Ha! You have to beg too? I have a client which is a large health care company who has extensive procedures for changing anything. <sigh>.
Even if you have multiple disks in a set on the same LUN, it would provide some benefit, assuming the controller can handle the throughput. Of course, separate LUNs are best. Most of the disk delay is typically waiting on the platter to rotate around again to the spindles, which is why 15k rpm drives are so much nicer than 10k. So likely, the controller is not the problem and adding more drives to the LUN will provide better performance even if not separated for you to control what files go on which drives.
Now, this was just a performance discussion. Disaster recovery is another topic.
Jim
Jim Murphy
http://www.sqlwatchmen.com
@SQLMurph
February 25, 2011 at 8:40 am
It depends, there are I guess pro's and con's either way. Let the storage guys and girls worry about it 😀
Carlton.
February 25, 2011 at 9:22 am
But what's the point of taking the time to separate the I/O load if it's all going to the same place?
This is how I'm looking at it, and I might be wrong, but
-disk pool A has 50 disks
from disk pool A, I carve out
D:\ Data - 100 GB
L:\ Log - 50 GB
T:\ TempDB – 50 GB
Z:\ Backups – 100 GB
All of these drives are from the disk pool A. So the random read/write & sequential read/write loads are all going to the same place. So I don't know if I'm wasting my time requesting the luns. Thanks so far for the help.
Chris
February 25, 2011 at 9:30 am
Personally: In your shoes I would be more concerned about the raid levels of your disk pools than whether it's 'lunned'.
Carlton.
February 25, 2011 at 10:07 am
fenwicc - ya, you are right. I was just saying that a 50 disk set is better than a simple 4 disk RAID 10 set because the load will be absorbed 'evenly' over the 50 disks. Well, not evenly at all, but somewhat spread out. Hopefully. :w00t:
So there is some advantage to having a 50 disk giant set. However, I'm with you in that it is WAY better to have a ton of smaller sets so you can go 'wide' on your file groups and have better control over which hot tables/indexes belong on separate drives and spreading out tempdb over a ton of sets. Oh well, sounds like your hands are tied.
Also, recovery gets tricky if your tlog backup's are landing on the same shared underlying disks. If too many physical disks fail, I really hope that the participating drives don't have the trn AND (mdf or ldf). That could be a problem and hard to control with a single giant set.
So if you can carve out some dedicated space on its own LUN, then I might recommend using it for the trn backups, or better yet one for the trn's and one for the ldf and let the MDF float on the 50. Course, you may run into ldf contention depending on how active that database is. But this seems like a better recoverability (is that a word? It is now) choice than using the separate LUN for a 'hot' file group (with performance in mind) but putting the system at risk of data loss. Unless your trn's are going direct to tape or something.
Jim
Jim Murphy
http://www.sqlwatchmen.com
@SQLMurph
February 25, 2011 at 8:46 pm
Since you are on shared storage, performance issues are going to harder to track down because you won't know who else is actually hitting those spindles.
If your SAN guys are good, they will be able to balance the systems accessing that disk group. If not, then you could suffer performance issues because of large IO processes on other systems.
All of my systems (well, most of them - anyways) are on Enterprise level SAN's where the storage is also shared. I also split out multiple LUN's for my larger systems - and there are some benefits to doing so.
A couple of weeks ago, on one of my systems where the previous DBA did not do this - we had a runaway process that caused the temp database to grow by 220GB and fill the drive. This caused other processes that needed space on the drive to fail.
On still other systems, I have had log files grow out of control and fill the drive - causing yet again other processes to fail because there wasn't space available.
Separating out so I have a dedicated LUN for tempdb, logs, data files and backups allows for easier management and prevention of those kinds of issues. If the above systems had dedicated LUNs for tempdb or logs, those other processes would not have been affected and the issue could have been dealt with much easier.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
February 28, 2011 at 7:25 am
Ok, so what I'm taking from this is the following:
If the database is connected to DEDICATED SAN disks – meaning disk group A is only for data files, disk group b is only for log files, etc. - then separating the I/O load is a performance benefit(obviously).
If the database is connected to SHARED SAN disks – meaning disk group A has data/log/tempdb/backups / etc. - then separating the I/O load is more for administrative benefit, safety from runaway processes, and the safety of LUNS being in different RAID groups of the disk group.
Thanks everyone for the input, I appreciate the time to respond. 😀
Chris
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply