Re: Chunk really full??? Puzzling . . .

ODS 7.22 According to my Online Administrator's Guide 7.2, pg 39-19, `oncheck -pt` has the same problem of not showing free space w/in extents. " Output for both -pt and -pT contains listings for "Number of pages used." The value shown in the output for this field is never decremented because the disk space allocated to a tblspace as part of an extent remains dedicated to that extent even after space is freed by deleting rows. For an accurate count of the number of pages currently used, refer to the detailed information on tblspace use (organized by page type) that the -pT option provides. " Now, I've run `oncheck -pT`, but I'm not sure what the above paragraph refers to, which will give me the "accurate count of the number of pages currently used". Below is some of the "-pT" output which differs from the "-pt" option - I'm assuming that this is what the paragraph is referring to. Does anybody know what they are referring to here? And where can I look to get a decent explaination of what the specific verbiage means - I can't seem to find details in the Guide. Your help is *much* appreciated. `oncheck -pT` (diff from -pt) output: TBLspace Report for debit:informix.allcards Table fragment in DBspace allcards_dbs_1 TBLspace Usage Report for debit:informix.allcards Type Pages Empty Semi-Full Full Very-Full ---------------- ---------- ---------- ---------- ---------- ---------- Free 45 Bit-Map 15 Index 0 Data (Home) 58964 ---------- Total Pages 59024 Unused Space Summary Unused data slots 1 Unused bytes per data page 5 Total unused bytes in data pages 294820 Home Data Page Version Summary Version Count 0 (current) 58964 Rick Bernstein wrote: > The "onstat -d" reports free pages which are not assigned to an > extent. > Your display shows that no space exists for additional extents. > It does NOT mean that all extents in this dbspace are full. > Use the "oncheck -pt <database>:<table-name>" command or query the > corresponding SMI tables to determine how full your fragments are. > > Rick Bernstein > Alaris Medical Systems > San Diego, CA 92121 > Internet: rbernste@alarismed.com > > At 12:13 AM 8/31/97 -0700, you wrote: > }The following is the output of an `onstat -d` for a particular chunk > - > }calldata_dbs_4_cnd_1. > } > }de04c18 13 13 0 400000 0 PO- /chunks/calldata_dbs_4_cnk_1 > } ^ > } zero free space > } > }Notice that the amount of free space is 0. I have a table defined > which > }fragments inserts for the month of August to this chunk: > } > } fragment by expression > } (MONTH (calldate ) IN (1 ,5 ,9 )) in calldata_dbs_1 , > } (MONTH (calldate ) IN (2 ,6 ,10 )) in calldata_dbs_2 , > } (MONTH (calldate ) IN (3 ,7 ,11 )) in calldata_dbs_3 , > } (MONTH (calldate ) IN (4 ,8 ,12 )) in calldata_dbs_4 > } > }Dbspace "calldata_dbs_4" and chunk "calldata_dbs_4_cnk_1" are > }equivalent, and there are no other chunks allocated to dbspace > }"calldata_dbs_4". > } > }Although the current status of the calldata_dbs_4_cnk_1, as reported > by > }`onstat -d` is that it has no free space, we are still able to > insert > }rows into the table for the month of August. > } > }How is this possble? > } > }The only thing that I can think of is that at some point all of the > }chunk was allocated, then some rows were deleted. But the extents > are > }still allocated for the table and not shown as being free even though > > }rows have been deleted from the table. If this is the case, how does > > }one find out the "real" free space in a chunk? > > }Thanks for any clarification on this. -- * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * ADDRESS ALTERED TO FOIL SPAMMERS: Remove "*NO-SPAM*" to reply. Cosmo Lee Multi-User Computer Systems Brooklyn, NY "JUST SAY 'NO' TO SPAM" * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *