Moreover, CLARiiON CX700 support cache upto 4 GB/processor, 2 processors, 4 FC port/processor. This highest end model in mid class system can certainly keep the smile for people with tight budget, yet keeping the performance.

Anyone who plan for quick migration for production database, or upgrade, go get a aloner unit of SATA storage system. Here goes a practical usage of high capacity disk with good performance.

Note 1: CLARiiON CX series are CX300, CX500, CX700
Note 2: 700 GB SATA disks are not supported yet by EMC
Note 3: Seagate haven’t release 15k rpm 300 GB SCSI disk yet. Only 10k rpm 300 GB available under Cheetah 10K.7 product

Ref: CLARiiON CX300 Spec Sheet http://www.emc.com/products/systems/clariion_cx300/pdf/C1078_cx300_ss_ldv.pdf
CLARiiON CX700 Spec Sheet
http://www.emc.com/products/systems/clariion_cx700/pdf/C1080_cx700_ss_ldv.pdf
EMC CLARiiON Family
http://www.emc.com/products/systems/clariion.jsp

A couple of points to pause for thought. First up the same company already supplies 300gb fibre channel and U320 scsi discs. The future isn’t as far away as you might think.

Second a lot of purchasers will exactly be looking at ditching SCSI based RAED arrays (where the E stands for expensive) for SATA based RAID arrays where the I stands for inexpensive. Things like the Apple XSERVE Raid arrays. 7tb for 13k what could possibly go wrong with that.

[Mike pulls flame proof body armour from cupboard and stuggles into it, noting that it doesn’t fit like it did last year. He makes a mental note to get some excercise - perhaps some running, but little does he realise that he may be running sooner than he thinks..]

Once upon a time when I was a junior sysadmin, we’d just taken delivery of our first 4GB drives. Quantity was absolutely required, as it was for storing seismic datasets. At the time, I opposed the rollout on the basis that 4GB was an awful lot of data to lose at one go and have to restore from 4mm DAT, should the drive fail (this was in the days before easy mirroring). Of course… I lost that debate - the engineers required the larger dataset in order to do their job, and we simply couldn’t stick to 2GB drives.

I see a lot of this situation in this for/against the 750GB drives - the circumstances are somewhat different, but I don’t think it’s acceptable to have a blanket dislike for a large capacity drive, simply because it has limitations over the previous generation (in this case, the capacity is increasing faster than overall performance).

There is *of course* opportunity for the inadequecies of the drive/interconnect to be abused and for that to cause performance problems - technical staff WILL stick a pair of 750GB drives into a 1U high machine and run the OS/DBMS and App from the same mirrored pair of spindles. Is this so much a crime? - A nice small system with a tiny power/space footprint - it might not run as fast as it *could*, but sometimes 75% of potential performance is sufficient (probably also worth mentioning that a huge amount of performance issues are due to application inadequacies, bottlenecking peformance before it gets anywhere near the database).

As I said to Doug.. “Do *all* parts of *all* databases have to run at phenomenal speed? - what happens when quantity is more important than delivery?”

Of course - there are absolutely exceptions to this - some databases really do merit performant environments, which doesn’t necessarily preclude them from these large capacity spindles.. it just requires that the topography and usage of the drives be managed with a lot more care.

The physical characteristics of these drives also need to be considered.. I suspect that in many situations, the DBA team is (WARNING..vast generalisation alert…) one degree of separation away from the physical datacentre requirements. This is a particularly hot topic at the current client, but I know of many, many places that are in similar situations.

We have a number of Symetrix currently configured with 73GB drives. We also have business requirements for more storage.. and we’ve got next to no power available in our datacentres. If we can swap our 73GB drives for 500GB drives, with a relatively small increase in power draw, the benefits can be enormous.

Right - there you go.. I said it.

[sound of running, wheezing sysadmin fades to distance ]

Therefore, this battle is not valid at all at the moment, at least for another 3 years.

I believe a 750 GB storage is certainly require for desktop database. Firstly, expansion for desktop is limited. Unless it uses SAN, or external storage, using EIDE, and SATA connection, it will requires big size HD to archive a terabyte database.

Moreover, this hard disk can be used for hot backup, archive log, database duplication, (low cost) standby database, database archival, RMAN catalog database, OEM database, OID database, AS10g App Svr metadata repository, low priority standby disk, user storage, storage area for data warehouse data load, multimedia storage, audio/video streaming server, voice (media) recorder database.

In most OLTP database, the popular access tables are always limited. Mostly less than 10 tables are very active. With careful planning of the data distribution, 10 units of 750 GB HD, proper indexing, SGA, it is still possible to archive high respond time. Moreover, it is possible to implement partitioning to make some old data off, so that table access could be faster. This will require effort from both developer, and users to the DBA, and storage engineer to archive this.

I don’t agree so much that it is suitable to hold online redo log, unless the writing (update, insert, delete) activities is low, or the storage sub-system’s cache size is near 30% of the online redo log size.

I checked HP StorageWorks EVA 4000, and entry level SAN, but it doesn’t support SATA disk, nor EIDE disk. Therefore, it is very likely that it cannot use in storage sub-system with decent RAID controller, 8 GB cache (HP StorageWorks EVA 8000), and high redundancy.

In short, the battle should not be now. Even if now, reasonable performance is archiveable with careful planning. High performance storage system are suitable for high performance database, which equips with multi channels 32 GB cache, and big size HD is still logical

My favourite, most likely and reasonable use. I’ve spent some time recently debating this with a sys admin who is too frightened to put in an appearance here ;-) (Hi, Mike!)

They will have perfectly valid uses.

However, we all know that some of those horrible, slimy big things will inevitably slide into the system where they are not welcome!

You could also use them for the hot backup. You could argue that the bandwith wont be sufficient, but consider it like natural bandwith limitation devices.

If you ask me, those are perfect for flash recovery area, as long as the $ per GB is there.

With 10 of these I could flashback to 3 months ago !

Big fat tapes, with decent random access speed. How is that bad ?

If you can convince the powers that be to allow you to use only the outer 1% to 10% of the disk, you now (almost) effectively have a drum. And a pretty fast one, too; I’m pretty sure that back in the 60’s and 70’s when people actually manufactured these things, I’m pretty sure nobody was crazy enough to try and manufacture one that spins at 15,000 RPM! (Did they even do 1,000 RPM? I’m afraid I don’t remember, as they are well before my time…)

But then, that’s the whole issue with BAHD, isn’t it? As far as the “decision makers” are concerned, even though I have managed to build myself a very fast (and very cheap!) 10GB “drum” using the outer edge of a 750GB disk, all they can see is 740GB of “perfectly good” storage that has “gone to waste”. And you just know they’re gonna use it for something stupid. Surely, there can’t be a problem with placing the corporate e-mail system on the unused space on the “drum” you’re using for online REDO, right?

Still, a good quality 750GB disk should cost less than $10k. The outer track is probably pretty big. Maybe if we could get the storage vendors to sell these devices as 2GB “virtual drums”, so our pointy-haired bosses wouldn’t know that there is “wasted” space on them, we could achieve something pretty cool.

Personally, I blame most of this mess on the craze for “consolidation”. Server consolidation, and storage consolidation. Ultimately, it is the slavish devotion to the idea (planted by hardware vendors, of course) that it is somehow “evil” to allow a CPU to go less than 90% utilised, or to “waste” a single kilobyte of storage that seems to be at the root of these problems…

But then, on the storage side, there is also the lack of basic understanding. Few managers seem to understand the differences between capacity, throughput, and reponse time; perhaps this is because many harken from the days when purchasing sufficient capacity almost always assured you of also having enough of the other two. Or not… (Oddly, though, many of the ones I know did understand these things before they were managers…)