There is an incredible amount of complexity (and permutations) going on here.

The fundamental concept for insert is fairly simple:

- determine a block that is candidate for the new row
- determine where we can record undo information for the change
- record the redo for the undo information
- record the undo information
- record the redo for the actual block change
- make the block change

For each of these, lots of potential complexity, eg

- ASSM or freelist managed tablespace
- do I need to extend the table high water mark
- how many concurrent transactions are going on on a candidate block
- private versus public redo
- in-memory undo vs normal undo
- is there an index on the table ?
- do I need to split a leaf/branch/root block ?
- are the candidate blocks already in the buffer cache
- is this part of a small operation or large operation
- any constraints in play ? foreign keys etc
- is the table locked ?
- is the new row "locked" ? ie, does the new row clash with any other uncommitted changes due to unique/primary key

etc etc etc, so we could spend days on it...

For an update the *fundamentals* are similar, with the additional complexity of locking an existing row. We have a lock byte on each row, which points to the transaction list entry in this block (ie, the set of current transactions on this block) - that's how we can either lock, or know if a row is already locked.