Actually, you are both right.
[BL] They cannot both be right -- either you get
ORA-1555 on a READ ONLY tablespace or you do not.
Delayed Block Cleanout can cause an ORA-1555, even in a read only
However, if the tablespace has been read only
"for a long enough period of time",
every query against it will realize that
all updates to objects in that tablespace have
been committed, and will never
try to reconstruct the table.
[BL] Disagree. What is "long enough" and how can a query "realise"
something? Problem is the ITL entries which tell the query to visit
the rollback segments cannot be cleaned out because they are in a READ ONLY
tablespace. Every time the block(s) are queried, they repeat the same exercise.
This problem is magnified when you do selective restores of tablespaces without
the rollback segments, and find you cannot read from those tablespaces without
the rollback tablespaces. Also, you don't reconstruct the table, but just
reconstruct the individual blocks.
As it happens, I have never
had an ORA-1555 on a table which is (was?) being
updated during the query;
I've had lots of them due to delayed block cleanout.
This was my first
thought when I read the original post, however, as I read the OP,
that the errors are appearing after the tablespace has been read only
[BL] A table being updated is guaranteed to have its undo entries
intact.Since this is the only way the rollback can happen if the update does not
commit. Your query will find what it needs in the rollback segments, and not get
an ORA-1555, unless the update has already committed, or rolled-back.
As a test, (if the OP is still reading, and my time sequence is spot on),
computing all statistics on all objects in the tablespace (not estimate,
compute). This will visit every block on all tables and indexes
(if any are
in the tablespace) and should clean out all the blocks.
[BL] Much easier to simply do "select max(column)..." on an un-indexed
column to cause FTS to cause cleanouts. Statistics is a bit of an