Re: What is the purpose of segment level checkpoint before DROP/TRUNCATE of a table?

  • From: "Jonathan Lewis" <jonathan@xxxxxxxxxxxxxxxxxx>
  • To: "'free'" <oracle-l@xxxxxxxxxxxxx>
  • Date: Fri, 8 Jul 2011 17:27:49 +0100


You've given me a clue.

Cross-DDL read-consistency - e.g. long running query meets exchange partition.

The query is allowed to continue because it know the physical location of the original partition, and the query will only crash if something overwrites the original. This came in in 8.1 I think, possibly even 8.0.

I've just run:

session 1 - start long running query against IOT
session 2 - drop IOT, flush buffer cache
session 1 - carries on running, after re-reading the block from disk.

The same test fails instantly with truncate because truncate does its local write to overwrite the root block of the IOT with an empty block, so session 1 immediately gets ORA-01410 invalid rowid. However the cross-DDL requirement would explain the writes on drop, and perhaps the writes on truncate are simply a side effect of piggy-backing the same code rather than writing a new piece.


Jonathan Lewis

----- Original Message ----- From: "Mark W. Farnham" <mwf@xxxxxxxx> To: <saibabu_d@xxxxxxxxx>; "'Jonathan Lewis'" <jonathan@xxxxxxxxxxxxxxxxxx>; "'free'" <oracle-l@xxxxxxxxxxxxx>
Sent: Friday, July 08, 2011 3:07 PM
Subject: RE: What is the purpose of segment level checkpoint before DROP/TRUNCATE of a table?

I now see your concern about the ability to checksum. But that is not
guaranteed (or needed by the recovery model) and since those blocks are no
longer assigned to a segment any contents are immaterial. If someone is
doing checksums or binary diffs between datafiles through the same point in
recovery, it might break their sanity check, but it does not compromise the
integrity of the standby in any way I can grok.


Other related posts: