onstat -P buffer percentages
Glen Johnson asked what the 'Other' category in onstat -P buffer percentages (Data 28.23, Btree 36.69, Other 35.08) contains. Bill said it covers partition, bitmap and other non-data, non-btree pages, and suggested LRUAGE=1 if Btree stays above 35%. Art Kagel added that Other includes unused buffers, so a consistently high partnum-zero figure may mean too much cache. The numbers returned to normal.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
Percentages: Data 28.23 Btree 36.69 Other 35.08 What is in Other and why would it be so large?
Glen, The "Other" includes table partition pages,bitmap pages for a table, etc. "Other" encompasses all of the non data and non btree pages that must be read into the LRU Buffers to be able to access data. When the load is large enough and the amount of data access grows the percentage of "Other" should shrink to pretty small number. Also, once you have your system under a load and you notice that Btree is consistently above 35% then you should consider setting the environment variable LRUAGE = 1 and restart the instance. This should bring the priority of Btree pages back down and allow more data pages to stay in the buffers. Thus when needed this env variable will increase data throughput. Bill Glen Johnson wrote: > Percentages: > Data 28.23 > Btree 36.69 > Other 35.08 > > What is in Other and why would it be so large? > >
Thanks, It must have been a hiccup in the system because those numbers are back in line with what one would expect. Whould you guess that what ever caused "Other" to go so high would have cause a temporary slowness on the system? "Bill" <wp4iiug@bellsouth.net> wrote in message news:3FB525D1.8000409@bellsouth.net... > Glen, > The "Other" includes table partition pages,bitmap pages for a table, etc. > "Other" encompasses all of the non data and non btree pages that must be > read into the LRU Buffers to be able to access data. > When the load is large enough and the amount of data access grows the > percentage of "Other" should shrink to pretty small number. > Also, once you have your system under a load and you notice that Btree > is consistently above 35% then you should consider setting the > environment variable LRUAGE = 1 and restart the instance. This should > bring the priority of Btree pages back down and allow more data pages to > stay in the buffers. Thus when needed this env variable will increase > data throughput. > Bill > > Glen Johnson wrote: > > Percentages: > > Data 28.23 > > Btree 36.69 > > Other 35.08 > > > > What is in Other and why would it be so large? > > > > > >
On Fri, 14 Nov 2003 14:20:30 -0500, Glen Johnson wrote: > Thanks, It must have been a hiccup in the system because those numbers are > back in line with what one would expect. Whould you guess that what ever > caused "Other" to go so high would have cause a temporary slowness on the > system? ><SNIP> >> >> Glen Johnson wrote: >> > Percentages: >> > Data 28.23 >> > Btree 36.69 >> > Other 35.08 >> > >> > What is in Other and why would it be so large? The OTHER category also include unused buffer pages. Look at the first line of the report (partnum zero), the other column for that line is almost completely unused buffers. If this number is consistently more than a few dozen then likely you have more buffer cache than you need. Keep in mind that this condition will exist if you have sized your buffer cache for peak loads or for occasional or periodic bulk loading/updating/deleting and are checking during normal load levels. In this latter case the overage may be acceptable. Art S. Kagel