Re: Problems with Production running slower than Development.

I am curious about the sort_area_size parameter, I looked pretty hard in the docs to find out if this is allocated on a per user basis and I could not find it, can someone please point me to a some docs on this? We are running JDEdwards OneWorld on our DB and the sort_area_size is set to 10MB, at the moment we are not suffering from any memory problems. I also got the sense from the docs that the sort_area_size is somewhat dynamic and allocates memory as needed and can shrink after a sort to sort_area_retained_size.

http://home.san.rr.com/epost/overlook.doc

<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 Mon Aug 30 1999 - 15:15:51 CDT