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
[EMAIL PROTECTED] 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:[EMAIL PROTECTED]]
> 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: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
