A place for everything
-
We are moving from SS2000 to SS2005 on a new server, an HP DL-380. The new server has these parallel SCSI drives:
Array A: 2-74GB mirrored set (partitioned into C and D drives)
Array B: 2-146GB mirrored set (E drive)
Array C: 2-300GB mirrored set (F drive)
Drive C will hold the OS, drive D the SQL Server 2005 executables, leaving E and F for data. The databases on the old server are not mirrored and total about 35GB of data. These databases serve applications with VB6 clients and a few intranet web apps. On the old server we have split the databases so that one drive has .mdf files, another has .ldf and a filegroup for indexes, and another holds tempdb. Given that we only have two drives on the new server (that's the immutable corporate standard now) where should we put .mdf, .ldf, and such?
There is no "i" in team, but idiot has two. -
Firstly, I would suggest you take the people responsible for that absurd standard out and shoot them repeatedly.
:hehe:Seriously now...
How active is the db in question? (transactions/sec)
Is it more read-heavy or write heavy?
How much usage does tempDB see?
How many databases are there and how many data files in total?
Hmmm. Are you allowed only 2 drive letters or 2 drives? Are you allowed to use mount points?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverabilityWe walk in the dark places no others will enter
We stand on the bridge and no one may pass -
I'm not sure I follow - you mention 6 physical drives, mapping to 4 logical drives, and yet the policy it to allow only 2?
If the standard is in fact as you described, I'd tend to agree with Gila, although I'd go with disabling all but two of their fingers (and not their thumbs), and see how well they make out.
Still - how did you manage to get 6 if you have this immutable policy?
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again? -
GilaMonster (6/10/2008)
Firstly, I would suggest you take the people responsible for that absurd standard out and shoot them repeatedly. :hehe:Why do people always say, "take them out and shoot them"? Shouldn't you blast them where they stand, and leave their lifeless bodies crumpled on the floor in the data center to serve as a reminder for the others? But that's an implementation detail...
Seriously now...
How active is the db in question? (transactions/sec) No measured numbers available, light duty for 9 databases
Is it more read-heavy or write heavy? More read heavy for one, the rest are fairly evenly distributed.
How much usage does tempDB see? It doesn't get very large (currently 28MB on the old server)
How many databases are there and how many data files in total? 9 databases, each with one data file on D and one log file on E. Total space used for data is 35GB.
Hmmm. Are you allowed only 2 drive letters or 2 drives? Are you allowed to use mount points?
We're allowed E and F drives, which must be mirrored. No one has mentioned mount points to me. What are those?
There is no "i" in team, but idiot has two. -
Matt Miller (6/10/2008)
I'm not sure I follow - you mention 6 physical drives, mapping to 4 logical drives, and yet the policy it to allow only 2?Still - how did you manage to get 6 if you have this immutable policy?
Matt, C & D can have only the OS and application executables, respectively. That leaves E and F for data. C & D are one set of two mirrored drives, E is another set of two, and F is the last one. They want to sell us some SAN space ($8.65/GB/year, backups are extra) to stand in for more physical drives.
There is no "i" in team, but idiot has two. -
This just in: the DBAs who work at the corporate mothership have recommended logs and tempdb on E drive, and data and indexes in separate files on F drive. Since we are stuck with the 2-drive letter config, that's probably the end of the discussion. Thanks for your help, folks.
There is no "i" in team, but idiot has two. -
Dave (6/10/2008)
Why do people always say, "take them out and shoot them"? Shouldn't you blast them where they stand, and leave their lifeless bodies crumpled on the floor in the data center to serve as a reminder for the others? But that's an implementation detail...Because it's so much work to clean up a data center after all of the servers have blood on them
The recomendation you got is probably about the best, if TempDB doesn't see much usage.
It's still a stupid standard though.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverabilityWe walk in the dark places no others will enter
We stand on the bridge and no one may pass -
GilaMonster (6/11/2008)
It's still a stupid standard though.Is it just me, or is there really a requirement that all corporate standards have to have at least one stupid element? I used to argue with people when they told me, "this is our standard". I would ask to see the standards document, and when there wasn't one, I would tell them that makes it a convention, not a standard, which was really just another form of "we've always done it like this, and we're used to doing it this way." Real standards have thought and discussion behind them. This particular "standard" arose from they like to buy HP servers, this model has room for six drives, they like to mirror drives, and they like to put the OS on one and binaries on another. Ipso facto, you have two mirrored sets left. Voila, you have a standard.
There is no "i" in team, but idiot has two. -
Dave (6/11/2008)
GilaMonster (6/11/2008)
It's still a stupid standard though.Is it just me, or is there really a requirement that all corporate standards have to have at least one stupid element? I used to argue with people when they told me, "this is our standard". I would ask to see the standards document, and when there wasn't one, I would tell them that makes it a convention, not a standard, which was really just another form of "we've always done it like this, and we're used to doing it this way." Real standards have thought and discussion behind them. This particular "standard" arose from they like to buy HP servers, this model has room for six drives, they like to mirror drives, and they like to put the OS on one and binaries on another. Ipso facto, you have two mirrored sets left. Voila, you have a standard.
Agreed - there's always a "duhhhhh" element to certain standards. Usually because the standard is written at a time when there is a compelling need to have it this way, but the standard is written without the requisite background to make it make sense 2 years later..... So you're stuck with the rule long after the reason for the rule has been fixed.
I did have a secondary thought for you. If you're restricted to the local drives like you mentioned, then yes - you were probably given a reasonable recommendation. That being said - you did mention that they "encourage" you to get/use SAN space, which might then be a plausible way to get access to a LOT more volumes should you need them. If the SAN performance is decent - i'd even consider moving the data and log volumes onto the SAN, and keep the local volumes for paging file and tempDB.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again? -
Matt Miller (6/11/2008)
If the SAN performance is decent - i'd even consider moving the data and log volumes onto the SAN, and keep the local volumes for paging file and tempDB.That's a real good point, and will be our plan B. Here's a quote from our SAN guys:
"The SAN switching Fabric consists of four Brocade 48000 Director Class switches. All ports are 4 gigabit/sec. All SAN attaches servers have 2 HBA connecting to different Brocade switches for a total of 8 gb/sec bandwidth.
Typically we see 20-30 Megabytes/Sec. disk throughput from windows servers. Lately we have been testing 64-bit windows and the SAN has been able to provide 200-300 Megabytes/sec. We still have to do additional testing to validate this major change in throughput.
On the disk side we use all 10k 147G drives, RAID 5 in a 3+1 RAID group. These RAID groups are carved into 1, 32, 145, and 306 GB LUNs. Severs can be assigned any multiple of the standard size LUNs. The 9990 disk system currently has 32 connections to the SAN to spread out the I/O from multiple servers using this storage.
Both the Brocades and Hitachi 9990 support hot upgrades. We have had no down time in the last 3 years. "
It sounds good, but I'm not a HW guy. I especially like the "no down time in last 3 years" bit. As usual, however, it's all about the money. The server guys called us late last year and told us they were planning to replace all servers that are 3+ years old at no cost to our department (who doesn't love free stuff?). But if we want to be on the SAN, it will cost us annually for space plus more $$ for backups. So we'll see how the new box works out right off the showroom floor before we look at buying acreage on the SAN.
Thanks for your help on this.
There is no "i" in team, but idiot has two.
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply