buffer usage

Was hoping all you geniuses could lend a hand. Thanks in advance onstat -Pshows a large usage of buffers (14,874) on our system to be associated with partnum=0 i.e. here's a summary of onstat -P, reverse sort on total buffers partnum Total Btree Data Other Resident Dirty 2098060 86106 16023 70082 1 0 0 7340034 69052 735 68315 2 0 1 2098155 57817 863 56954 0 0 0 9437187 48451 2138 46312 1 0 24 8388613 22969 0 22969 0 0 0 13631502 15008 15008 0 0 0 1 0 14874 866 2164 11844 0 268 ... Totals: 450000 115041 322918 12041 0 6920 Percentages: Data 71.76 Btree 25.56 Other 2.68 I query systables for partnum =0 and get: partnum tabid tabname tabtype flags 0 90 GL_COLLATE 0 0 91 GL_CTYPE 0 0 99 VERSION 0 0 1608 stgkmstr V 0 0 1077 stgamstr V 0 0 1078 stxcolsv V 0 0 1609 stgcmstr V 0 What is happening with partnum=0 taking so many buffers? The views are not commonly used. Is there anything special about partnum=0 for the engine? Why are multiple entities all associated with partnum=0

Parker, J wrote: > > Was hoping all you geniuses could lend a hand. > > Thanks in advance > > onstat -P> shows a large usage of buffers (14,874) on our system to be associated with > partnum=0 [output SNIPPED] Not to worry it just means that there are 14,874 buffers unused, ie that have not valis data page loaded into them. Looks like you have one of those rare installations with enough buffers. > What is happening with partnum=0 taking so many buffers? The views are not > commonly used. > Is there anything special about partnum=0 for the engine? > Why are multiple entities all associated with partnum=0 These are all VIEWS which have not disk usage and not TABLESPACE TABLESPACE entry so a zero partnum. No worries mate. -- Art S. Kagel & Family kagel@erols.com