The system is a data mart, and it was increased to reduce the number of disk
sorts. It has helped with the loading. If needed when the 10-100 users
get into the system, I will reduce it if necessary.
<harronc_at_ibm.net> wrote in message news:37CB53E6.20B67E04_at_ibm.net...
> Not such what sort of application you're running against the database, but
if it
> is OLTP your sort_area_size is much too big. This is allocated per user so
for
> 100 users 600M will be allocated. If you need this much for sorts maybe
you need
> to look at your indexing.
>
> Ciaran Harron
>
> Bob Fazio wrote:
>
> > I realize how hard it is to tune without all the information. But if
you
> > have any insight it would be appreciated.
> >
> > I have to instances, dev and production. Dev on a 4500 and Prod on a
6500
> > (SUN)
> >
> > The 4500 (4 processors and 4GB Ram) 6500 (8 processors and 8GB of RAM)
> >
> > The obvious problem (which I am resolving) is that I am I/O bound, and I
am.
> > I am working on resolving that as I write this. I was hoping some of
the
> > other things might be obvious to someone.
> >
> > shared_pool_size 300M - prod and 60Meg Dev
> > db_block_buffers 3200 - prod and 1000 - Dev
> > log_buffer 163840 prod and 252144 - dev (not running archivelog in
either
> > instance)
> >
> > sort_area_size 6M prod 5M dev
> > sort_area_retained_size 6M prod 1M dev
> >
> > The following are set in production , but left to the defaults in dev.
> >
> > sort_write_buffer_size 2M
> > optimizer_search_limit 10
> > bitmap_merge_area_size 2m
> > hash_multiblock_io_count 64
> >
> > --
> > Bob Fazio
> > rfazio_at_home.com
>
>
>
Received on Tue Aug 31 1999 - 06:11:54 CDT
