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

Mark,

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.

Regards

Jonathan Lewis
http://jonathanlewis.wordpress.com

• Original Message ----- From: "Mark W. Farnham" <mwf_at_rsiz.com> To: <saibabu_d_at_yahoo.com>; "'Jonathan Lewis'" <jonathan_at_jlcomp.demon.co.uk>; "'free'" <oracle-l_at_freelists.org> 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.
>

--
http://www.freelists.org/webpage/oracle-l