RE: Tuning, RAID5, and fragmentation and DBWR

Hey Dana,

Are you kidding? A GS140 running OVMS would be my choice of OS/Hardware! OK, OS bigotry aside... ;)

The RAID5 *WILL* give you performance problems! RAID5 is the worst performer for write operations. The LGWR,and associated slave processes (and to a somewhat lesser extent, the DBWR) WILL complain LOUDLY. I hope for your sake that the GS140 at least has a lotta memory. CPU-wise, it's 2.5-to-3 times faster than our 4100 5/400, depending on MHz. CPU's not going to be your bottleneck, though.

But, if that's all you have to work with, try a few of these:

1. Make your LOG_BUFFER huge. In the 10s of MB, perhaps. Redo log buffer space requests STOP your DB from running, even if for only a very short time (milliseconds to seconds). And with the long write times you can expect, you'll probably need a large LOG_BUFFER to help prevent this.
2. Consider not duplexing your redo logs and control files. KNOW THAT THIS CAN ADD CONSIDERABLE RISK OF LOSS OF DATA! Basically, by not duplexing redo logs and control files you are relying solely on the RAID5 array and it's controllers to not trash your DB. But without duplicating the I/O, you will be saving a bunch on performance. You will have to weigh the risks and benefits. Personally, I'd wait for more drives before doing this, because it's my butt on the line if the data's gone, but that's just me.
3. I'm guessing that there's the potential that a really huge DB_BLOCK_BUFFERS and a BUFFER_POOL_KEEP with table/index caching could help. You know the data and your users better than I.
4. Once you have the SGA sized properly, make sure you make use of VMS's Resident Memory Registry for the DB's SGA. See the Oracle Install Guide for more info. Be prepared to reboot if you need to make changes to the RMR.
5. Don't use Oracle7. Get at least Oracle 8.0, preferrably 8i -- 8.1.6.2.0 with patches.
6. Get Spotlight on Oracle from http://www.quest.com to help you monitor your DB performance, so you can show your bosses/co-workers why the hell you can't run an entire DB on a single RAID5.

Ideally, if you could get them to just keep your datafiles on the RAID5, but have at least 5 more JBOD (non-RAIDed) drives to put the other Oracle files on -- 1 for each of 2 control files, 1 for each of 2 sets of redo logs, and at least 1 more for the archives, preferrably 2 if you can, for duplexing them as well. Yes, that's one 9GB or 18GB drive to store a single 10-100MB control file. Drives SAs nuts, unless you happen to be an SA/DBA. :)

If you can, have them get you the 15K-spin Seagates. Those puppies fly! Ahh, if only in a perfect world...

HTH! Good luck!

Rich Jesse                          System/Database Administrator
Rich.Jesse_at_qtiworld.com             Quad/Tech International, Sussex, WI USA

Disclaimer: This is just my opinion. Do what you want with it, but don't hold me, Quad/Graphics, it's subsidiaries or employees accountable for your (in)actions based on what's in this email!

> -----Original Message-----
> From: dana mn [mailto:danamn2000_at_yahoo.com]
> Sent: Tuesday, February 27, 2001 11:51
> To: Multiple recipients of list ORACLE-L
> Subject: Re: Tuning, RAID5, and fragmentation and DBWR
>
>
>
> Thanks Dave, Don, and Patrice.
>
> It's hardware RAID, a Compaq GS140 machine, and Oracle on VMS [not my
> choice of OS/hardware]. Limited to one large RAID5 volume.
>
> I'd like to make the most of what's there, because for political
> reasons nothing else will change.
>
> Does it make any sense to increase the number of database writer
> processes on a system with nothing but RAID5 space? Looks like there's
> a bit of slowdown on checkpoints.

This message has been scanned for viruses with Trend Micro's Interscan VirusWall.

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Jesse, Rich
  INET: Rich.Jesse_at_qtiworld.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).