Row Movement

Here’s a question that appeared recently on OTN, and it’s one I’ve wondered about a few times – but never spent any time investigating. Are there any overheads to enabling row movement on a table ? If not, why is it not enabled by default and eliminated as an option ?

Obviously there are costs when a row moves – it will be updated, deleted and re-inserted with all relevant index entries adjusted accordingly – but is there an inherent overhead even if you do nothing to move a single row ?

Equally obviously you’ve made it possible for some to “accidentally” shrink the table, cause short term locking problems, and longer term performance probems; similarly it becomes possible to update rows in partitioned tables in a way that causes them to move; but “someone might do it wrong” doesn’t really work as an argument for “de-featurising” something that need not have been a feature in the first place.

What have I missed ?
Answers in the comments gratefully received – and possibly discussed.

Related posts:

1. Oracle 12c Gives Fresh Life to the Relational Database Movement
2. Oracle 12c Gives Fresh Life to the Relational Database Movement
3. Storage Allocation
4. Testing Partitions
5. Don’t be a Crash Test Dummy
6. RAC – It’s all about the node affinity
7. Solving VMware network problems on Linux VMware guests
8. Capturing DDL for Database Objects Not Managed by PeopleTools
9. Bitmap / Btree
10. Incremental Statistics Maintenance – what statistics will be gathered after DML occurs on the table?