Re: Problems with Production running slower than Development.

Hi.

1. Try to increase you SGA to 1Gb at least ( you have 8 of them in PROD - use it ). Increase the number of db_block_buffers ( you didn't specified what is you db_block_size ). If it 2K - then you are using 2K * 3200 = 6400K = 6.4M of you buffer pool now. Even if it is 16K then you are using about 50M out of 300M. Increase it to 12800 ( to be on a safe side - do it step by step ). You can increase it even more after increasing SGA size.
2. Check your hit ratios ( data and dictionary ). You are supposed to achieve > 90% at least ( > 95% is tuned system ).
3. Do you have a lot of extents? It may cause performance degradation.
4. Do you have row-chaining?

 Good luck. Michael.

In article <j%Hy3.2259$E46.1895_at_news.rdc1.pa.home.com>,   "Bob Fazio" <bob_fazio_at_hotmail.com.no.spam> 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
>
>

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't. Received on Tue Aug 31 1999 - 15:32:33 CDT