Well there was limited feedback on this one. I was hoping for the
flood-gates to open, but alas no.
It seems there is limited knowledge out there about specifically tuning
oracle and dunix. I find this very surprising.
I have included all the replies here.
Thanks
Viktor
------------------------------------------------------------------------
--------------------------------------
>From : Randall R. Cable[SMTP:randy.cable_at_mci.com]
First part of your question regarding file systems... Unless youa re
planning to run OPS, I would stay away from raw files... I would
recommend
Advfs, as well as LSM... Work between DBA and sysadmin to design your
containers, do your raid striping in both hardware and software...
As far as tunig for Oracle, there are books aon the subject... Oracle
has a
set of manuals that I know my last DBA's constantly had me changing
kernel
params to optimize their performance...
The following web site is a good place to start, Think of your database
as
a web site taking many small hits...
>http://www.digital.com/info/internet/document/ias/tuning.html#Recommend
ations
------------------------------------------------------------------------
--------------------------------------
From : alan_at_nabeth.cxo.dec.com[SMTP:alan_at_nabeth.cxo.dec.com]
There's not a lot of file system parameters that can be
tuned, but the guide to tuning may offer some clues. On
the HSZ side your only choices are:
o RAID level
o Whether to use the Writeback cache.
If the database can issue multiple I/O requests in parallel
a RAID level has some advantage over plain disks, since the
array controller can spread the load evenly among the disks.
Setting the chunk size for striping and RAID-5 is the most
interesting tunable. The documentation for the controller
should offer clues how to select the chunk size. RAID-0
offers the best capacity/performance, but no redundancy.
RAID-1 offers the best redundancy and better read performance,
but uses more disks and the write performance is worse. RAID-5
offers redundancy and striping like read performance, but
also has relatively poor write performance. Combining striping
and RAID-1 offers good performance and redundancy, but uses
more devices.
The write back cache can significantly help write performance,
except in cases where the write load is constant. It also
helps for RAID-5 and RAID-1 performance in general. But it
places the data at a slight risk. The memory used to implement
the cache is non-volatile due to the presense of a battery
to keep it on during a power failure. If the battery fails,
the NVRAM fails. The HSZ40 had a very poor battery history,
so the HSZ50 and HSZ70 batteries were redesigned. I'm lead
to believe that in the presense of good batteries, the NVRAM
is much more reliable than the underlying disks.
If the I/O load seen by the controller consists of lots of
write and read-back, then read caching on the controller
can help a lot. If Oracle does no data caching when run
on top of a raw device, this is a possible I/O load. If
Oracle does their own caching or relies on the file system
cache, the reads will satisfied by the cache on the host
and the controller read cache won't be of much value.
Using raw devices has the advantage of avoiding a data copy
from the kernel buffer cache to user space. It also may have
a slightly shorter I/O path. In a purely random I/O load
this may be an advantage to performance. In a sequential
load, UFS and I think AdvFS will do read-ahead in the file
system, which can significantly improve performance.
So, a lot of the choices depend on how you use the database.
------------------------------------------------------------------------
--------------------------------------
>From larry.magnello_at_usa.net
you can start by running unicensus with sys_check. It will tell you what
parameters to add to sysconfigtab.
------------------------------------------------------------------------
--------------------------------------
-------------------------------------------------------------
This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity
to whom they are addressed. This communication may contain
material protected by attorney-client privilege. If you are
not the intended recipient or the person responsible for
delivering the email to the intended recipient, be advised
that you have received this email in error and that any use,
dissemination, forwarding, printing, or copying of this email
is strictly prohibited.
If you have received this email in error please notify the
IT department at postmaster_at_abnamro.co.uk or by telephone
on +44 (0)171 601 0101.
Received on Mon Oct 26 1998 - 14:57:30 NZDT