SEO

I understand that enhancements have been made to V10 so that you can
control the tblspace tblspace and thereby reduce some of the situations
which lead to not being able to drop a chunk. But is that all
situations? What about if some extents of one of the system catalog
tables are in the chunk concerned?

I am wondering if a better solution to this problem would be to add a
FORCE option to dropping a chunk whereby any extents of tables
currently in the chunk would be relocated to another chunk of the
dbspace - if space is available.

Would this group support a feature request to change functionality in
this way.

regards

Malcolm

Yes. In fact I'd like a move extent feature.

onspaces -me (move extent) -p <oldpath>... -o ...<old_offset>
-ne (new extent) -p <newpath>... -o ...<new offset> [ -s
<number_of_pages> ]

Move extent at offset old_offset in chunk old_path to
offset new_offset in chunk newpath.

Worst case is that the new place for the extent has less free space
that the extent size and you get some of the old extent in the original

chunk. You can just then move the new extent.

The optional -s <number of pages> allows you to distribute a
massive extent (2Gb?) whereever you want it to go even if it does
not fill the free space in the new chunk. E.g. spread it across
several chunks (spindles).

Perhaps something for Quiescent mode? I don't think the new
IDS 10 Single User Informix User only mode is restrictive enough for
this since you don't want even Informix access the old extent when
you try this!

This could be a feature implemented like the In-Place alter table
i.e. not cover all cases in the first release but gets better over
time.

We can do online index rebuilds and I heard online table reorgs
are in the pipeline (DB2 has online table reorgs already!).
So if IBM are reviewing online reorgs then the above onspaces
extension would be great.

Ultimate control over space management!