| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: Tbs READ ONLY and Snapshot too old
MessageActually, 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 tablespace.
[BL] Agreed.
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, I think that the errors are appearing after the tablespace has been read only for several days.
[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), try computing all statistics on all objects in the tablespace (not estimate, full 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 overkill.
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Fri Jun 18 2004 - 07:57:44 CDT
 |
 |