Thanks Janathan, The following is some data from the statspack 9-15pm report. I am not sure whether it should be like that CPU usage should rise, or it is just some kind of fluctuation. [oracle@main-db1**biddb]$grep "table scans (short tables)" *.lst --it does increase, but I am not sure how much cpu increase it can cause. Have no idear how to measure it. 10gb.lst:table scans (short tables) 1,132,629 52.4 0.7 11gb.lst:table scans (short tables) 1,301,091 60.3 0.8 [oracle@main-db1**biddb]$grep "CR blocks created" *.lst 10gb.lst:CR blocks created 202,232 9.4 0.1 11gb.lst:CR blocks created 181,607 8.4 0.1 [oracle@main-db1**biddb]$ grep "table scans (long" *.lst 10gb.lst:table scans (long tables) 5 0.0 0.0 11gb.lst:table scans (long tables) 5 0.0 0.0 Thanks. Zhu Chao. ----- Original Message ----- From: "Jonathan Lewis" <jonathan@xxxxxxxxxxxxxxxxxx> To: <oracle-l@xxxxxxxxxxxxx> Sent: Wednesday, June 09, 2004 11:01 PM Subject: Re: see higher CPU usage after increase SGA > > A couple of thoughts: > > Increasing the db_cache_size means you may have > sufficient space to keep more clones of CR blocks, > which means that the number of clones checked for > the correct SCN could have increased - this would > use more CPU directly (checking the next clone) and > indirectly (holding the latch longer for the check causes > others to spin for longer). > > Increasing the db_cache_size will also increase the > size of a 'small table', so more tablescans would go into > the middle of the LRU rather than the end. This could > have some effect on CPU usage if you previous has a > number of tablescans which just fell short of 'small'. > > I can't see where the 1.5% drop in logical I/O would > come from - but it's small enough to be noise - I think. > > These are ideas are just conjecture, of course, and may > have nothing to do with the real reason for your increased > CPU. > > > Regards > > Jonathan Lewis > > http://www.jlcomp.demon.co.uk > > http://www.jlcomp.demon.co.uk/faq/ind_faq.html > The Co-operative Oracle Users' FAQ > > http://www.jlcomp.demon.co.uk/seminar.html > Optimising Oracle Seminar - schedule updated May 1st > > > ----- Original Message ----- > From: "zhu chao" <chao_ping@xxxxxxxxxxx> > To: <oracle-l@xxxxxxxxxxxxx> > Sent: Wednesday, June 09, 2004 2:31 PM > Subject: see higher CPU usage after increase SGA > > > : Hi, > : I once saw Jonathan said at metalink that huge SGA does not help in > many > : case, But no further discuss at that topic later. Last night we added 1Gb > : to oracle sga and we see fewer disk read but higher CPU usage. > : > : Fewer disk read of course cut CPU usage, but larger buffer cache > : management in unix and oracle, seems caused higher CPU usage. Has someone > : also have similar experience? How to explain the higher CPU usage? > : > : We have a 16GB memory sun 880 with 10G data cache. As disk read get > : higher and higher , and not much SQL to tune we deciede to increase data > : buffer from 10G to 11GB, as there is still 1.5G free memory on the host. > : > : We expect to see some CPU usage drop, as disk read drop by 30%. But > : after 1 day's run, we saw higher CPU usage then before we increase the > SGA. > : > > > ---------------------------------------------------------------- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > ---------------------------------------------------------------- > To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx > put 'unsubscribe' in the subject line. > -- > Archives are at //www.freelists.org/archives/oracle-l/ > FAQ is at //www.freelists.org/help/fom-serve/cache/1.html > ----------------------------------------------------------------- > > ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------