I’ve just discovered that I didn’t reply to your question.

Your guess was correct – I wasn’t expecting to see any change, but I thought I’d put in the code to check anyway since it was just a couple more lines.

Your thought about a second transaction is interesting, though. It would need to start with two active transactions on the block (INITRANS=2 by default), but it’s possible that a third transaction would be able to see free space in the block and need to compress the block because it had to push down the row directory to allow space to create a third ITL entry before it could delete a row.

Rows will keep their rowid which, in other words, means that a row cannot change the row directory entry that it’s stored in. This does have a notable side effect. In my article on the row directory I showed a block with 2017 entries in the row directory, of which the first 2016 pointed to row stubs that had been marked for deletion. When the session commits the space from the delete rows can be reclaimed in a (future) heap block compress. Similarly space from the row directory can be reclaimed – within limits.

If row 2016 had not been deleted, then the heap block compress would not be able to reclaim any space from the row directory. If it was just row 1,000 that had not been deleted then the heap block compress could reclaim the row directory entries from 1001 to 2016. There’s a type of “high watermark” effect – a row has to stay in the same row directory entry so you can only reclaim row directory space for row entries larger than the largest remaining row.

In your proof the “heap block compression” occurs on a block where only the last row is still present (row 19 in your case).
If oracle “rewrites” the whole block in such cases, what would happen to rows that still exist in the middle (let’s say that row 10 would also exist).

As the ROWID also contains the “row number” – will such a compression also change the rowid or do the rows always keep their “row number”.

Regards
Stefan

Thanks,
Flado