>
> I was thinking of asynchonously cleaning it up rather than blocking
> DROP/DETACH ... which means you need to keep state somewhere. I don't
> think blocking DROP/DETACH is valuable -- a global index that blocks
> DROP/DETACH until the index is clean serves no useful purpose. (You
> could think of a multi-step approach with internal transaction commits,
> similar to CIC, but you still need a plan to clean that up in case the
> server crashes during that operation.)
In Oracle if you have a global unique index and a partition is dropped, the index is marked invalid and needs to be
rebuild.
IOW, an outage.
DB2's approach is better. When the partition is dropped, the index entries are marked for deletion and it starts a
async
process of cleaning it up, which can run into several days if the dropped partition is large. But at least the table is
online.
