First of all thnks for your valuable time and suggestions. However, there is no change in our transaction rate, they are almost the same value at any given time. However, I am not doing it for any testing or learning purpose. We are facing some transactions time-out in our production database uding texudo middleware. The tables which I increased the freelist are the one who are referring almost in every transaction. Server configuration, 9gb of RAM with 5cpu, AIX 5m on D240 storage. I dont see 'buffer busy wait' as top 5 timed events in any statspack report but very seldomly I can see them in v$session_wait. My thinking was, all these tables have only 1 freelist (default value), when they are involving heavy concurent insertion, it would be a good idea to play with its freelist. On 5/18/05, Mark W. Farnham <mwf@xxxxxxxx> wrote: > Did your transactional throughput go up, down, or not change much? >=20 > Asked another way, are these higher waits insignificant side effects of > un-jambing some other problem? >=20 > It is not possible to know without the times, and even with the times, we > cannot know whether this is a problem or simply a report of a change in > statistics unless you tells us whether throughput is now changed, and how= . >=20 > Asked yet another way, is some process materially slower than you need it= to > be due to the amount of TIME spent waiting for these waits. >=20 > Abstract attempts to change the values of statistics reports from running > systems without correlation to a process or task that is running slower t= han > required have little (little includes nothing) to do with making things > actually process faster. >=20 > Collection and observation of some statistics without correlation to prob= lem > processes can be useful, but that is part of capacity planning and load > management, not optimization. Even then (unless you're using systems > statistics as a proxy for company business growth in an attempt to predic= t > stock outcomes or something like that) you need to correlate the statisti= cs > you observe to known scaling limits of your existing environment. >=20 > So, are you trying to fix some process that is going slower than you thin= k > it should (or more appropriately, slower than your service level > requirement), > or are you just trying to manipulate the statistics? >=20 > Now I will not deprecate that activity if you're doing it as a learning > exercise or even if you're just servicing your CTD. But I would like to k= now > if you have a throughput problem you're trying to solve (or not). >=20 > To answer your question, if changes you made ungated pent up demand for > these tables, sure, you could have driven the load on the tables higher. = If > your throughput went up, then the higher frequency of wait events is a ha= ppy > side effect. If your throughput went down, the times and a correlation wi= th > the now slower process(es) *might* show that the increase in waits > represents a problem to solve. >=20 > Regards, >=20 > mwf >=20 > -----Original Message----- > From: oracle-l-bounce@xxxxxxxxxxxxx > [mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of The Human Fly > Sent: Wednesday, May 18, 2005 2:11 AM > To: gorbyx@xxxxxxxxx > Cc: Cary.Millsap@xxxxxxxxxx; Oracle-L Freelists > Subject: Re: buffer busy waits PUZZLES >=20 > However, I haven't have buffer busy wait as my tops events nor I see > any session execessively waiting for this event. I have already > mentioned in my previous replies that I have grabbed these values from > v$segment_statistics dynamic view. >=20 > The following are today's result for the buffer busy waits. >=20 > TRANSACTION_LOG 211143 > FM_AUDIT_FORM 39906 > C_INTIMATION 37029 > CIS_AUDIT_TRAILH 15001 > OUTWARD_CLEARING_CHEQUES 8310 > C_CUSTOMER 5793 > FM_OLTP_LOG 2727 > INWARD_CLEARING_CHEQUES 2347 > RB_RESTRAINTS 2239 > SYSTEM_PARAMETER_VALUE 1492 > RB_TRAN_HIST 1102 >=20 > I have increased default freelist 1 to 5 to those tables and now I can > clearly see that those tables buffer busy wait event has increased > madly. This could be due to heavy access on those tables? >=20 > However, I have been reading Cary's book past 1 year and still I > enjoying reading it. Thank god, now, I started undertanding the > concept behind method R and the true power of 10046 trace for > resolving performance issues. >=20 > On 5/18/05, Alex Gorbachev <gorbyx@xxxxxxxxx> wrote: > > My bad... > >=3D20 > > 2005/5/17, Cary Millsap <Cary.Millsap@xxxxxxxxxx>: > > > Ah! Credit to Gaja and Kirti for that one... > > >=3D3D20 > > > Cary Millsap > > > Hotsos Enterprises, Ltd. > > > http://www.hotsos.com > > > * Nullius in verba * > > >=3D3D20 > > > Visit www.hotsos.com for curriculum and schedule details... > > >=3D3D20 > > >=3D3D20 > > > -----Original Message----- > > > From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@freelists= .o=3D > rg=3D3D > > ] > > > On Behalf Of Alex Gorbachev > > > Sent: Tuesday, May 17, 2005 2:42 PM > > > To: sjaffarhussain@xxxxxxxxx > > > Cc: K Gopalakrishnan; oracle-l@xxxxxxxxxxxxx > > > Subject: Re: buffer busy waits PUZZLES > > >=3D3D20 > > > sessions/transactions than you you've got CTD ("Compulsive Tuning > > > Disorder") speaking Carry's language. > >=3D20 > > --=3D3D20 > > Best regards, > > Alex Gorbachev > > -- > > //www.freelists.org/webpage/oracle-l > >=3D20 >=20 > --=3D20 > Best Regards, > Jaffar, OCP DBA > Banque Saudi Fransi > Saudi Arabia > -------------------------------------------------------------------------= --=3D > ------------- > "It is your atittude, not your aptitude that determins your altitude." > -- > //www.freelists.org/webpage/oracle-l >=20 >=20 --=20 Best Regards, Jaffar, OCP DBA Banque Saudi Fransi Saudi Arabia ---------------------------------------------------------------------------= ------------- "It is your atittude, not your aptitude that determins your altitude." -- //www.freelists.org/webpage/oracle-l