| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: Problems with Production running slower than Development.
Bob Fazio wrote:
>
> db_block_size 16K
> I did do a check and I am only using currently (after a few days up and
> running, we re-booted) about 15% of the 300M in my SGA.
>
> Hit ratio's I'm not sure, but the numbers I saw were acceptable, but not
> great(guessing 90%). Again the system has only been back up for a few days,
> and they are in between runs. Just one run a week.
>
> Very few extents, even in the data dictionary. I think that the max there
> was about 30. The rest of the tables, are all under 10.
>
> No row chaining.
>
> I am going to increase the db_block_buffers, and see what effect it has.
>
> Thanks.
>
> <michael_bialik_at_my-deja.com> wrote in message
> news:7qhe50$7cj$1_at_nnrp1.deja.com...
> > 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.
Look for disk hot spots...All the RAM and CPU in the world isn't going to help you if you have a particular disk that is getting hammered...In particular, check the disks that the redo logs are on...
On the topic of redo logs, check you waitstat tables to see if you are going any long waits on rollback or redo ... Either of these can devastate ins/upd/del performance...
HTH
--
"Some days you're the pigeon, and some days you're the statue." Received on Wed Sep 01 1999 - 06:49:03 CDT
 |
 |