How much space do I have left?

Hi there, I'm trying figure out how much space is left on the system. According to our vendor there is 88% used space on the metrodbs dbspace. In the past they had to create fake tables or chunks ( the story changes with every phone call) to spread the data over a couple controllers so not to get a bottleneck on any one controller. Now they say those tables or chunks had been dropped a while ago and there are only 2 tables of size that are not needed, but if they drop those tables it won't show up in the onstat -d command, according to the vendor. Is the onstat -d command dynamic to show the changes in size up and down? Or does it just show the peak at one time. This also seems odd. We have 9 9 gig drives with 1 hot swap spare in a raid 5 setup. Giving us about 72 gigs of drive space. The total space according to the onstat -d command is 53.583 gigs of space. And the used space is 45.177 gigs of space. Leaving only 8.406 gigs of space. This is short of the 72 gig's of space that the disks can hold. They are raw partitions. I understand there is some overhead but 17 gigs seems to be too much. Also when we do a level zero backup, using ontape command we back up the rootdbs,logical,physical,metrodbs, and histdbs. All totaling about 44gig. Our tape drive only has a 20 gig uncompressed / 40 gig compressed capacity. If there is 44 gigs of data then we should be going to a 2nd tape. But when we verify the backup using archecker it only shows 27 gig's of data. Is there something i'm missing? Thanks in advance, Pat Militzer pmilitzer@metromls.com Here is a copy of the onstat -d command output: INFORMIX-OnLine Version 7.24.UC5 -- On-Line -- Up 27 days 22:36:13 -- 1259168 Kbytes Dbspaces address number flags fchunk nchunks flags owner name 50c36100 1 2 1 1 M informix rootdbs 50c37f58 2 1 2 1 N informix logical 50c5b038 3 1 3 1 N informix physical 50c5b0a8 4 2001 4 1 N T informix dbtmp1 50c5b118 5 2001 5 1 N T informix dbtmp2 50c5b188 6 1 6 31 N informix metrodbs 50c5b1f8 7 1 35 5 N informix histdbs 7 active, 2047 maximum Chunks address chk/dbs offset size free bpages flags pathname 50c36170 1 1 2 50000 48907 PO- /dev/rootdbs 50c36248 1 1 2 50000 0 MO- /dev/rootmirro 50c36da0 2 2 2 32000 1947 PO- /dev/logical 50c36e78 3 3 2 50000 4947 PO- /dev/physical 50c36f50 4 4 2 150000 147597 PO- /dev/dbtmp1 50c37028 5 5 2 150000 147565 PO- /dev/dbtmp2 50c37100 6 6 2 975000 289 PO- /dev/metrodbs 50c371d8 7 6 2 800000 25 PO- /dev/chk1 50c372b0 8 6 2 930000 92 PO- /dev/chk2 50c37388 9 6 2 975000 0 PO- /dev/chk3 50c37460 10 6 2 930000 1167 PO- /dev/chk4 50c37538 11 6 2 685000 891 PO- /dev/chk5 50c37610 12 6 2 975000 0 PO- /dev/chk6 50c376e8 13 6 2 655000 633 PO- /dev/chk7 50c377c0 14 6 2 930000 9 PO- /dev/chk8 50c37898 15 6 2 975000 0 PO- /dev/chk9 50c37970 16 6 2 975000 0 PO- /dev/chk10 50c37a48 17 6 2 975000 0 PO- /dev/chk11 50c37b20 18 6 2 975000 11 PO- /dev/chk12 50c37bf8 19 6 2 975000 619 PO- /dev/chk13 50c37cd0 20 6 2 975000 279 PO- /dev/chk14 50c37da8 21 6 2 950000 56 PO- /dev/chk15 50c37e80 22 6 2 975000 26431 PO- /dev/chk16 50c5a030 23 6 2 975000 88226 PO- /dev/chk17 50c5a108 24 6 2 975000 0 PO- /dev/chk18 50c5a1e0 25 6 2 530000 0 PO- /dev/chk19 50c5a2b8 26 6 2 500000 499499 PO- /dev/chk20 50c5a390 27 6 2 530000 529353 PO- /dev/chk21 50c5a468 28 6 2 535000 534589 PO- /dev/chk22 50c5a540 29 6 2 535000 53620 PO- /dev/chk23 50c5a618 30 6 2 494000 493709 PO- /dev/chk24 50c5a6f0 31 6 2 535000 439138 PO- /dev/chk25 50c5a7c8 32 6 2 535000 0 PO- /dev/chk26 50c5a8a0 33 6 2 535000 216 PO- /dev/chk27 50c5a978 34 6 2 500500 0 PO- /dev/chk28 50c5aa50 35 7 2 500500 0 PO- /dev/histdbs 50c5ab28 36 7 2 500000 90397 PO- /dev/histChk1 50c5ac00 37 7 2 500000 90397 PO- /dev/histChk2 50c5acd8 38 7 2 500000 499997 PO- /dev/histChk3 50c5adb0 39 7 2 500000 499997 PO- /dev/histChk4 50c5ae88 40 6 2 500000 0 PO- /dev/chk34 50c5af60 41 6 2 500000 103 PO- /dev/chk35 41 active, 2047 maximum

Pat Militzer wrote: > > Hi there, > > I'm trying figure out how much space is left on the system. According > to our vendor there is 88% used space on the metrodbs dbspace. In the > past they had to create fake tables or chunks ( the story changes with > every phone call) to spread the data over a couple controllers so not Sounds like they fragmented the tables to spread the I/O load out. OK... > to get a bottleneck on any one controller. Now they say those tables > or chunks had been dropped a while ago and there are only 2 tables of > size that are not needed, but if they drop those tables it won't show > up in the onstat -d command, according to the vendor. Is the onstat Of course it will, it they are really dropping tables and not just deleting rows from the tables and leaving them there. Deleting rows does not return allocated space from a table back into the free extent pool. However, if a table is dropped ALL of its extents are made available for reuse and WILL show up in the onstat -d report. > -d command dynamic to show the changes in size up and down? Or does it > just show the peak at one time. onstat -d shows actual current unallocated free space. There have beenbugs from time to time (my developement server and one production server each have one chunk whose free space is -1048575) but in general this works fine. > This also seems odd. We have 9 9 gig drives with 1 hot swap spare in a > raid 5 setup. Giving us about 72 gigs of drive space. The total > space according to the onstat -d command is 53.583 gigs of space. And > the used space is 45.177 gigs of space. Leaving only 8.406 gigs of > space. This is short of the 72 gig's of space that the disks can This just means that the vendor has not allocated the remaining 17GB of space on the virtual drives to any server chunks that the Informix engine knows about. Have them add some of these missing 9 or so chunks to the server. They were probably reserved for future use and noone remembers that they are there. Either the devices for the remaining partitions were created and are sitting unused in /dev or they are still recorded as free space on the pseudo drive that represents the RAID5 set. If the latter you can use your volume manager's tools to create logical drives out of the remaining 17GB and then add them to the engine. Hmmm looking at your onstat -d another possibility occurs to me. I see chunks that point to device files chk1 -> chk35. If these were all created as 2GB logical devices that would make 70GB. However, several of these chunks are only using 1GB (500,000 pages assuming 2K page size which seems right looking at the almost 2GB, 975,000 page, chunks you do have)! Looks like you can add additional chunks using offsets of 500,002 or 530,002 (the original chunks used an offset of 2 so you just add the original offset to the original size to get the offset for the next chunk). > hold. They are raw partitions. I understand there is some overhead > but 17 gigs seems to be too much. Also when we do a level zero > backup, using ontape command we back up the > rootdbs,logical,physical,metrodbs, and histdbs. All totaling about > 44gig. Our tape drive only has a 20 gig uncompressed / 40 gig > compressed capacity. If there is 44 gigs of data then we should be > going to a 2nd tape. But when we verify the backup using archecker it > only shows 27 gig's of data. > > Is there something i'm missing? Art S. Kagel