September 15, 2008 at 2:02 pm
Hi. We have an OLAP environment that has builds that are taking 12 hours or so to finish. Along with that long load time, we are also experiencing space issues.
We currently have a RAID-5 (4 - 15K RPM Disks). We are looking to upgrade and are considering two options:
1) A bigger single RAID-5 w/15K disks all presented as one drive.
2) 2 Bigger RAID-1 w/7200 disks, presented as two drives.
Obviously the advantage of #2 is that I can split of the database files (TEmpDB specifically), but am concerned that losing the RPMs will be an issue.
So, what should I do?
September 15, 2008 at 2:07 pm
Most times when questions like these come I always have to answer with "it depends" but in this situation, go with option 1. The rpm speed is an issue and you are already reducing any read advantage with extra spindles by going from 4 spindles in the old configuration down to 2 if you move to the 2 disk RAID 1 configuration.
So, without question, option 1.
Then ask the manager for more storage. 🙂
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
September 15, 2008 at 3:03 pm
I would go for option 2, simply because RAID 5 has the slowest writes of any of the commonly used RAID levels
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
September 15, 2008 at 3:11 pm
I would be really surprised if a write on a RAID 5 15K disk group is slower than a 7200 write but, I may be wrong. I know using 7200 disks for a "cheap" backup solution was terribly painful and it was all due to disk IO.
Obviously, you see there are differences with opinions on this too. 🙂 The answer is always, test.
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
September 15, 2008 at 3:19 pm
Depends. 😉 On the stripe size, what kind of writes are done, and a bunch of other things.
With a 4 disk RAID 5 if a write only affects one of the drives, it requires another 2 reads and a write to compute and write the parity. If a write affects 3 drives, it can just require another write to do the parity, so larger writes are less affected than smaller ones.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
September 15, 2008 at 7:41 pm
DavidB (9/15/2008)
I would be really surprised if a write on a RAID 5 15K disk group is slower than a 7200 write but, I may be wrong. I know using 7200 disks for a "cheap" backup solution was terribly painful and it was all due to disk IO.Obviously, you see there are differences with opinions on this too. 🙂 The answer is always, test.
Sure...The write would likely be nearly the same. I'm just wondering how much of a benefit I would get since two reads/writes could happen at the same time if it was split into two RAID-1s.
So...A follow-up.
The server will hold 6 drives. 2 in a RAID-1 for the OS/Swap and 4 for the database stuff. If I increased the size of the 2-disk RAID-1 that also has the OS/Swap and was able to add another logical drive to that set, would it be worthwhile to put TempDB out there and then utilize the big RAID-5 with the 15k drives? At least then I'd get TempDB off onto its own set of drives. Of course that would unfortunately be shared by the OS/Swap. 🙁
September 16, 2008 at 4:48 am
You could try. It would seem like that would definitely remove some IO from the drives that are to be focused for true data activity so, it may work out for you better than what you have now. Chances are it will. There are risks in doing that as well as you alredy mentioned. So, keep an eye on things.
Ultimately as Gail and I have been saying it does depend, on multiple things, including disk configuration, write and read activity. If you move forward with this configuration use sys.dm_io_virtual_file_stats to keep an eye on things and watch your activity (great way to see the file utilization as well). Watch for IO stalls, specifically with tempdb and use the information for tuning and management reporting (i.e. justification for enhanced storage solution ;)).
Hope it goes well.
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply