Hi Kevin,
We have multiple Oracle Databases of different sizes. However, most of our databases are around 20 - 30 gigs.
You might want to consider having each database be in its own 20 - 30GB qtree within a single volume. That way you can SnapMirror each qtree on an individual schedule, make multiple copies of the most critical databases to different locations or even backup to a NearStore R100 using SnapVault for later tape backup, etc.
Obviously this means that you wouldn't use Volume based SnapRestore if you have more than one database per volume, but you could use Single File based SnapRestore within a single qtree. Unfortunately, we don't have directory or qtree based SnapRestore, as pointed out earlier, but you could possibly use a perl script (perhaps check on NOW) to perform the directory or qtree restoration. The database files would be restored without copying the data, but new inodes are created to reference the files in the active filesystem.
All my problems would be resolved if we could justify the use and waste of so many disks. I wonder, having multiple small databases on the same volume with qtree snapshots would be something of the future. Or maybe not. Any recommendations would be appreciated.
I hope the above helps with your disk usage. I don't know your system intimately, but I'd expect that you could easily have a dozen or so databases per volume with Data ONTAP 6.2.
For more info on SnapMirror, SnapVault and SnapRestore, etc. Check out the web page at:
http://www.netapp.com/solutions/continuity
Cheers, Grant
For information on NetApp's Data Protection Solutions view http://www.netapp.com/solutions/data_protection.html.
=========== grant@netapp.com ========== Grant Melvin === === Software Development Manager === === Data Availability & Management === |\ | __ ___ /\ __ __ === Network Appliance === | \ | |__ | /__\ |__| |__| === 475 East Java Drive === | | |__ | / \ | | (R) === Sunnyvale === === California, 94089 === === Tel:(408)822-6761 =========== Network Appliance ========== Fax:(408)822-4578
We have multiple Oracle Databases of different sizes. However, most of our databases are around 20 - 30 gigs.
You might want to consider having each database be in its own 20 - 30GB qtree within a single volume. [...]
Of course, one just begs to ask: WHY is it that we continue this absurd notion that bigger is always better? Who the hell needs a 72GB BOOT DISK? Sure, maybe when Windows(tm) 2004 comes out... :-)
Yes, it is a fundamental law of computing that files and databases will always expand to fill the available disk space, but why is it that you can't even buy a 9GB drive anymore? A 20-30GB database, even if you double or triple it in size, is still going to fit on *one* shelf with 9- or 18GB drives.
If I had a 30GB database, I'm sure my DBA would agree - striping 5-6 9's together makes way, way more sense than throwing piles of higher-cost 36's or 72's at it, only to waste massive amounts of space in an effort to keep performance up. Of course, our database grows at over 30 million rows per week, so adding 36's makes sense for us. :-) Still! I echo the call for using appropriately-sized drives where it makes sense. :-)
All of my production servers have ridiculously huge boot drives because that's the only way Sun (or anyone else) sells them these days. So I mirror / & /var, interleave swap, and even after sizing things to some absurd degree, there's usually a chunk of 8-10GB of free space - 'cuz all the good stuff lives on the filers. Having that local disk space there just means that someone is going to want to USE it, and that's bad - it means I'd have to actually back up those machines, and I *hate* backups. (In the exceedingly rare case where both drives of a mirrored boot volume are corrupted or destroyed, it's always going to be faster to re-Jumpstart and cfengine the machine from scratch than to restore from tape anyway. Local data just messes up all that beautiful automation. :-)
A long time ago I was going to recommend that filers come with a pair of internal boot drives - like a mirrored pair of 4GB or 9GB drives _strictly_ for use as the boot volume, with some space for logs, etc. There's plenty of room inside the big filer heads for a pair of drives. But the move to Flash RAM cards in the newest machines is even better - fewer moving parts. :-)
Just my $0.02,
-- Chris
-- Chris Lamb, ("Old school") Unix Guy MeasureCast, Inc. 503-241-1469 x247 skeezics@measurecast.com
On Thu, 28 Mar 2002, Chris Lamb wrote:
Yes, it is a fundamental law of computing that files and databases will always expand to fill the available disk space, but why is it that you can't even buy a 9GB drive anymore? A 20-30GB database, even if you double or triple it in size, is still going to fit on *one* shelf with 9- or 18GB drives.
Going *way* out into fantasyland here: what we need are PCMCIA-sized 1-inch drives. Not like the kind you see today... these ones would have a single, tiny platter spinning at 30000 rpm with an FC-AL interface. A 2U-tall enclosure could fit 72 of those across a 19" face with some room to spare. Break that up into 5 14-disk RAID groups and 2 hot spares. If each disk is 4GB, you end up with about 230GB of useable space. Not very dense, but super-high spindle speeds and lots of them. Lots of blinkenlights too. ;-)
A long time ago I was going to recommend that filers come with a pair of internal boot drives - like a mirrored pair of 4GB or 9GB drives _strictly_ for use as the boot volume, with some space for logs, etc.
You'd lose the ability to cluster then, since the partner will not have access to those drives. I suppose you could have internal mirrored drives (plus a spare), and split them like the NVRAM. Writes would then be mirrored to both local and partner drives. However, that's a backwards step from eventualy filer/storage virtualization. It doesn't make much sense to have significant storage physically tied to a filer head when you move to N+1 clustering, a SAN fabric between filer heads and the drive pool, etc. Being able to boot off of a flash image (like on the F880 and newer models) seems like the right way to go though.
-
Brian Tao -
Chris Lamb -
Melvin, Grant