Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
Author |
Topic |
RandyK
Starting Member
5 Posts |
Posted - 2006-04-19 : 19:49:09
|
We are about to build our first multi TB raster database on SQL Server 2000. This will be done on a IBM SAN made up of SATA drives w/ RAID 5. We went with 250 GB SATA drives since the data is fairly static color orthophotography. Right now we are thinking of doing 4 1TB LUNs or 2 2TB LUNs. Either way is there a benefit to creating multiple database files per LUN vs 1 large database file per LUN? Before raid 5 it would be necessary to strip across separate drives. |
|
MichaelP
Jedi Yak
2489 Posts |
Posted - 2006-04-20 : 14:57:11
|
Well, I'd probably suggest going with the "more and smaller" LUN's in this case. When you need to do backups, restores, and drive rebuilds I don't think you'll want to have "half" your disks in a degraded state. For your 2TB LUN config, that puts you at 8 disks in your RAID 5 which is on the top end of the "6-8 disk max" that I've been told you should have in a RAID 5 on an IBM SAN. That number I was quoted was based on Fibre Channel drives, so it may not apply exactly to your SATA drives.How are you handling database backups with this large amount of data?It may make sense to have (4) 1TB LUN's, and use two for data and two for backing up to.Michael<Yoda>Use the Search page you must. Find the answer you will. Cursors, path to the Dark Side they are. Avoid them, you must. Use Order By NewID() to get a random record you will.</Yoda>Opinions expressed in this post are not necessarily those of TeleVox Software, inc. All information is provided "AS IS" with no warranties and confers no rights. |
 |
|
RandyK
Starting Member
5 Posts |
Posted - 2006-04-25 : 15:33:05
|
How about best practices for sizing the physical SQL database files? |
 |
|
MichaelP
Jedi Yak
2489 Posts |
Posted - 2006-04-25 : 15:51:44
|
I'm not exactly sure on that one. It's one of those "it depends on your data" sort of things. I do reccomend changing the growth rate of your database from 10% to something in the 250-500MB range. Growing a 500GB database by 10% will take some time, esp. on that SATA array.Michael<Yoda>Use the Search page you must. Find the answer you will. Cursors, path to the Dark Side they are. Avoid them, you must. Use Order By NewID() to get a random record you will.</Yoda>Opinions expressed in this post are not necessarily those of TeleVox Software, inc. All information is provided "AS IS" with no warranties and confers no rights. |
 |
|
MichaelP
Jedi Yak
2489 Posts |
Posted - 2006-04-25 : 15:52:52
|
I'm rethinking your disk config a bit. How many physical disks do you have?Michael<Yoda>Use the Search page you must. Find the answer you will. Cursors, path to the Dark Side they are. Avoid them, you must. Use Order By NewID() to get a random record you will.</Yoda>Opinions expressed in this post are not necessarily those of TeleVox Software, inc. All information is provided "AS IS" with no warranties and confers no rights. |
 |
|
RandyK
Starting Member
5 Posts |
Posted - 2006-04-28 : 16:04:43
|
We have 9 physical 250GB SATA drives. |
 |
|
MichaelP
Jedi Yak
2489 Posts |
Posted - 2006-04-28 : 16:34:01
|
If you have 9 drives, I don't see any way to get 4TB of usable space in a RAID 5 configuration. Nine times 250GB is only 2.25 TB unformatted and unRAIDed. There's no way to get to 4TB.Five 250GB drives in a RAID 5 gives you 1TB. Nine drives RAID 5 gives you 2TB. If you split it into a five drive RAID 5 (1TB usable) and a four drive RAID 5 (750GB usable) that may work for you. If you need all of the contiguous space, then the nine drive RAID 5 makes more sense. Take a look at http://www.ibeast.com/content/tools/RaidCalc/RaidCalc.aspMichael<Yoda>Use the Search page you must. Find the answer you will. Cursors, path to the Dark Side they are. Avoid them, you must. Use Order By NewID() to get a random record you will.</Yoda>Opinions expressed in this post are not necessarily those of TeleVox Software, inc. All information is provided "AS IS" with no warranties and confers no rights. |
 |
|
|
|
|
|
|