Re: Oracle configuration ??

From: Gregory Pucka <puckag_at_sprintmail.com>
Date: 1997/02/09
Message-ID: <32FD5B65.34FB@sprintmail.com>#1/1

oracle wrote:
>
> AlBeRt tHe GoD wrote:
> >
> > I have a HP K420 running with 2 CPUs and 850 megs ram, this HP is
> > dedicated to running Oracle 7.3.2.2 on HPUX 10.10, what type of
> > configuration can I do to the init.ora to churn out the best
performance ?
> > I have created the database on 4096 block size and span the
datafiles over
> > three disks, the database contains about 65 tables and my initial
sga size
> > is approx 55 megs.
> >
> > thanks,
> >
>
> If you are not using raw devices and async i/o you might want to
> consider
> using it. It is hard to answer your questions without being on-site
> to look
> at traces and doing tests.
>
> You should get a good tunning book.
>

Why would you try to get someone new to Oracle to use raw divices. I have known DBA's that have been working with Oracle and UNIX for a couple of years that still have a problem working with raw devices. I advise all of my clients to get away from them, unless there just isn't any other way to get the performance. And as far a async i/o I have found multiple dbwr's to do a better job. It take a lot of time to tune async for the best performance.

As far as the the sga and the rest of the tuning that depends on the amount of data, the number of users, if they are using client/server or are the users logging into the box, what other software may be on the box, etc....

Tuning is more of an art then a science. Once you think you get it tuned in 6 months or so you go through the same thing all over again.

For the datafiles and other files. Keep the redo logs away from the other files, the rollbacks also need to be separated. If you are running in an archive mode the archive logs will need to be in a totally separate disk. Tables and indexes should be kept aparts as best you can.

In the init.ora a few parameters to check into:

   db_block_buffers
   db_file_multi_block_read_count
   db_file_simultaneous_writes
   db_writers
   log_buffer

   log_small_entry_max_size
   log_sumultaneous_copies
   shared_pool_size
   sort_area_size

There are plenety of others that can be tuned, but this are some to start with. Just remember, if performance is an issue you will get more out of tuning the SQL then the database. I have been tuning systems for over 5 years and I always start with the SQL.

---
----------
Greg Pucka
Management Consultant, TUSC
puckag@tusc.com --- http://www.tusc.com

Received on Sun Feb 09 1997 - 00:00:00 CST