RE: max pages allocated issue

Floyd, Lets see if I have this straight... You have a dbspace with ~15million pages. This dbspace contains both the table and its index. You ask if you drop the indexes and then recreate them as detached and in a different dbspace if you would 'buy more time' ... Hmmm... I'd be inclined to say that if you remove something from a dbspace that either those pages are removed or at least recycled... so yeah, it should buy you more time. On a side note... wouldn't moving your indexes to a different dbspace also improve performance too? But hey! What do I know? I'm not really in to being a physical dba so I could be wrong ... -G Date: Tue, 30 Jun 2009 11:51:10 -0500 Subject: max pages allocated issue From: floyd@fwellers.com To: informix-list@iiug.org Hi, We've ran into this problem before, where we hit the limit of the number of pages that can be allocated to a dbspace for a table. It's something like 16million. After that, you can't add anymore pages to the table. I have a script to warn me when it gets close. Basically just grabbing the pages allocated from an onstat -pt. We have a table very close now, over 15million pages. My question is this just datapages for the limit or index pages also. The reason is, this table has 2 indexes created with the 'in table' clause. I am thinking that instead of reorging the whole table into fragments I can just drop the indexes and create them in another dbspace to buy some time. Would that in effect provide me with a lower number of allocated pages and solve the problem for now ? Thanks, floyd _________________________________________________________________ Windows Live™: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_BR_life_in_synch_062009