Re: Single-disk database and I/O load balancing?

pharfromhome_at_hotmail.com (Geomancer) wrote in message news:<cf90fb89.0310101359.e7bd81c_at_posting.google.com>...
> > Seriously using one disk for an oracle database is asking for trouble in
> > most (all?) production environments. You've no safety margin - if that disk
> > fails it's game over (at least whilst you find another disk and reinstall
> > from a backup).
>
> Thanks Andy. Yes, maybe I should clarify. Of course, the disk is
> mirrored (one client is triple mirrored) and all are protected against
> disk failure with redundant controllers.
>
> My issue is cost justification and the "myth" of disk file
> segregation!
>
> When a "single" disk system (a mirrored pair) is large enough to hold
> the whole database, how do I justify asking them to buy six more
> 72-gig spindles "three mirrored disk pairs", just to segregate redo
> and indexes and undo.
>
> Bottom-line, is disk segregation on non-RAID disk really a "myth", or
> does it apply to mirrored-only disk databases where the entire
> database is under 100 gig?
>
> By the way, I have checked vendors, and it's hard to find a disk with
> less than 72-gig these days. . .

well, if they value having a quick mean time to recovery (MTTR) then you need to acquaint them with the idea of recovering from disk. with only one RAID 1 volume, that concept makes no sense with me.

start with saying (practice it now)

"We want to have 8 times the size of the database for storage."

this is not before fault tolerance is taken into effect, this is after mirroring. Why 8?

hot backup staging area.
rman backup staging area.
(use both until you are 100% comfortable with rman. if you have the space, still use both).
export staging area.
Still running 8.1.7.4.x ? 9.2.0.x testing area. application updates? clone the prod db over to a test db on this server.
might even need space for backing that up to disk. archived redo logs - keep at least all the logs since the last hot backup uncompresssed on disk (besides getting them copied off of this server asap)
old compressed sets (in case a logical recovery is required of a table).
need room for core dumps, OS and oracle. need room for trace files, after you realize how powerful 10046 tracing is.
(reading 10053 trace files still gives me a headache)

compress the backups - and have those picked up by a network backup.

multiplex the online redo logs.
duplex the archived redo logs.

one more rule of thumb: leave every filesystem that you create with 25% free space.

run through that list again until you start seeing an external storage cabinet floating before your eyes.

If you're using intel 32bit CPUs, Dell used to sell a 14 drive x 18 GB external storage unit for around $7500. Standard Edition of Oracle list price from the oracle store is 15,000 USD per CPU. Tell them that they can get by with a single CPU that is welll fed, and save the 2nd CPU license cost by giving the system an adequate storage subsytem.

not that I'm admitting doing this, but some DBAs create bogus tablespaces just so that the datafiles are there for later re-use. They can then later be renamed and used in a datafile creation with a reuse clause. In the meantime, the space does not show up as free. ok, I do this, but not on production servers. this way, if I want to test benchmarking of something later, I can use the first 512MB off of each volume for testing. I know exactly where on the disk this is, as it was the first file created on a pristine filesystem. (cut to vision of riding a lift up a mountain in nothern Vt. at 8 am on a Friday morning, after 6" of new stuff the night before).

8 times the size of the database might be on the low side.

so there is reduced benefit for storing backup sets on a single RAID 1 volume.
are they addicted to 1U servers?
do they have a SAN in place? if so, I could see only having a RAID 1 volume for OS, swap and binaries - and put everything else out on the SAN.
but I'd still copy the compressed backup set and archlogs local, just so that if the SAN becomes unavailable, that the database is still there.

try: the network backup runs nightly. if we lose that volume at 11 pm (before the network backup), we lose the entire day's worth of transactions. see how comfortable they are with that.

Hmm. how amny IOPS does a 3.06 GHz CPU need to be well fed? Hope you have lots of ram in that puppy, and have set writeback caching on the battery backup enabled RAID controller.

good luck.

Pd Received on Fri Oct 10 2003 - 23:02:50 CDT