- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
You give someone a certificate for showing up to a training class and they think they're a God.
Admin
How great it is to work in a company where your management is either unable or unwilling to comprehend and accept a logical presentation of facts, regardless of who it is that is presenting them.
Admin
it's just sad...
Admin
Let's be honest, this just confirms what we all know about DBAs.
Admin
So TRWTF is that Paul allowed this total nonsense article to go out in a trade magazine, read by other DBAs, perpetuating a myth about partitioning. So now every sys admin ordered to do something equally stupid has Paul to thank when the DBA pulls the article as "proof" that his method is right. This highlights the real lack of scholarship in computer science circles.
Admin
This smells fishy, Paul claims he could achieve orders of magnitude more performance by putting up a mirrored harddrive compared to many disks with dedicated partitions, and it was an I/O bottleneck? Even if the data was spanned and the DBA used some very old way of doing stuff, the fact is there are more drives available and should have had higher I/O throughput.
Also, Paul should be fired on the spot for doing this, he is messing around with something he clearly doesn't understand (not that the DBA was any wiser, it is however the DBAs responsability), having tools intentionally report faulty information will make debugging extremely problematic.
Admin
Aha! Argument from Authority strikes again.
Admin
If there's a database administration course anywhere that babbles about where to put stuff on disk, it's a rip-off.
Here in the 21st century you put it all on a SAN and assume the guys who designed the SAN knew what they were doing. Which I suppose is TRWTF here: the presumption that no one else knows what they're doing.
/CAPTCHA: Odio, part of the flying monkeys' marching song
Admin
Maybe one day people will understand that parasites can only survive if they find a resigned host to suck...
Admin
Admin
Hey, come on. 10^0 is still an order of magnitude
Admin
What was the Trade Magazine called? Have you got a scanned copy of it?
Admin
DBA here.
DBA was a moron. Stay out of SysAdmin's business, and expect him to stay out of yours. Paul wasn't much brighter. Create partitions and then create the RAID array? Was this software RAID? If so, that's TRWTF (and the real bottleneck.)
Admin
10^0 = 1.
1 bottlneck is all you need.
Admin
Yes, I second that - I'd put that on my wall too...
Admin
Substituting into the sentence, 1 more performance
Admin
More like the certifiable DBA.
Admin
Admin
Who is the guy/gal approving these spending items, and how do I sucker my company into hiring that wasteful spending chump?
Really, how the hell would all those drives get approval?
Admin
I'm rooting for Paul in this story but I have to ask - why didn't he just show his greatly improved two-drive solution to the boss?
"Hey boss, you know all these problems we've been having? Turns out the DBA doesn't know how to set up an efficient drive array, I've done it myself with just two drives and the performance is spot on. Also, you can get a refund for all these unused 10,000rpm drives he made you buy. So anyway, about that raise...".
Admin
Admin
Admin
Admin
i agree, i think this should've been the real WTF
Admin
Admin
The funny thing is each of these steps is reasonable for performance tuning but hardware RAID and the disk IO performance changes in recent years essentially invalidated these procedures.
Admin
Uh... ok, the 10 partitions per drive bit was a little screwy, but there's an obvious throughput advantage to staggering frequently-used areas of the database across different physical disks. A single RAID 1 array doesn't cut it for a 200 gig DB.
A SAN isn't some magic panacea that will fully-optimize the performance of any database. For very large databases you should still be spreading the data/indexes across different LUNs which correspond to entirely different disks.
Where did the tech even find a 7200 RPM SCSI disk? Was this 10 years ago? Or was the server using SATA disks (the real WTF)?
Admin
Ok, the 'certified' DBA was going way overboard, I'll give it that. 60 partitions? Unless we're dealing with a multi-terabyte database, that would seriously scare me.
However, there is a LOT of research into disk layout for database servers. Please look into it before you criticize either the DBA or Paul, too much here. There are valid reasons for placing logfiles on separate partitions (which I do by default), and breaking out large tables or indexes into separate files and disks.
If you really want to know the details, google "Paul Randal SQL Server" and read up on it. (He's the guy who wrote DBCC CHECKDB for Microsoft, and I think he knows a thing or two about on-disk structures for SQL Server...)
HTH
Admin
One more thing. SAN only works well if you know what you're doing, and still take some of these measures. I have standalone boxes that respond in < 3ms (Good) to disk requests, while the san responds in > 30 ms (Poor). Of course, try telling that to the SAN admins...
Admin
So, let's see:
Admin
So why can't Paul show us the magazine page?
Admin
I'm no sys admin but I'd say 10 partitions per disk is more than a little screwy - it's bloody stupid and a bottleneck waiting to happen. The story backs me up.
Admin
I'm saying optimizing disk I/O through intelligent data placement is almost always premature optimization. If you're picking data location on disk then you'd better be 100% confident that there is nothing more to be done in about 5 other areas of performance tuning that always matter much more.
And if you are talking about physical data placement within a SAN you are about 10 physical layers away from the bits anyway and you'd almost always be better served by adding hardware that's closer to the database engine, meaning network, RAM and CPU cores.
Admin
Ok, the DBA was a moran. But that doesn't mean that ALL DBAs who claim to know something about physical partitioning are idiots.
Even with a SAN, the physical configuration is certainly relevant to throughput.
RAID-10 on dedicated LUNs = happy users, happy DBAs RAID-5 on shared LUNs = unhappy users, unhappy DBAs
Admin
Stop ragging on the DBAs. There are many "DBAs" out there who really know what they are doing. Then there are others who try to emulate the "black magic" of optimization.
I agree that this story sounds like the usual exaggeration and simplification, but the bit about the article in the trade magazine sounds awfully verifiable to me if it is true.
Admin
Admin
It's not completely clear from the article but it was probably set up as RAID 5 originally. Oracle (for one) runs poorly on it. Raid 10, which is close to what the admin did, is the right way.
I had a customer who set this up for all their systems, whether they had Oracle or not, and once I pulled the DBs over to Raid 10 it improved performance and throughput considerably. (Raid 1 is much better than it was years back but I recommend RAID 10).
BAARF on.
Admin
I disagree. As a lowly developer when I say, "we need these server specs to run this new app" management doesn't question it. How many sysadmins do you know that have a server sitting at home because they "needed a new one for x project".
Admin
Admin
Raid 1 is better than it used to be??? It hasn't changed. RAID 1 is mirrored.
http://en.wikipedia.org/wiki/Nested_RAID_levels
http://en.wikipedia.org/wiki/Standard_RAID_levels
Read some before you post. There ARE purposes to each RAID configuration.
Admin
Good one :D
Admin
Let me guess, it was an ORACLE DBA, right?
Admin
That's TRWTF right there. Even monkeys fall out of trees.
Admin
Admin
Admin
Paul Randal certainly knows what he is talking about, but you apparently don't. Log files go onto separate RAID Arrays, not separate partitions. The purpose there is to segregate the sequential IO for logging from the random IO of the data files. Logical partitions don't separate IO, its still the same disk array physically. Disk subsystem misconfiguration is one of the biggest causes of performance problems for database servers, and no a SAN is not the solution to your database server IO needs unless you have someone that understands the IO patterns associated with the database platform being implemented and configures the SAN arrays properly, and the underlying disks are dedicated.
The entire configuration recommended by the DBA here is wrong, nonsensical, and would cause significant IO bottlenecks from competing IO workloads in any RDBMS that uses the Write Ahead Logging protocol.
Admin
OK, someone please find the original article in the magazine :) Must read.
Admin
No sysadmins that I know would lie, cheat, and steal like that. I'm serious -- I hate dishonesty. I don't have any servers at home because I claimed that we "needed a new one for x project". If you have done that, shame on you.
Admin
Admin
I assume this story goes back a few years, as worring about disk partitioning for DB optimisation is nonsense today (at most it should comes down to deciding on striped v mirrored v striped+mirrored RAID if the storage is even on the local system).
I'm sure most of us here work with database that are under half a terabyte anyway, and so can fit comfortably in RAM on a single x64 box.