I received ORA-01555. That in itself wouldn't be much to brag about, but
the circumstances are curious. Being aware that this is a large table
I imposed a shared lock on the table to prevent any concurrent updates.
Despite the lock and despite manually executing a global checkpoint (yes,
I need the keyword "global", there are 2 instances accessing the DB).
The lock was granted, there were no commits in my transaction nor was the
table updated. I checked the audit records, nothing there.
How is it possible? Usually, I was receiving ORA-01555 when long running
query was accessing table that has been concurrently modified. This time,
there were no concurrent updates.



--
http://mgogala.byethost5.com

On Wed, 13 Oct 2010 21:14:20 +0000, Mladen Gogala wrote:

BTW, I am re-running now with the entire tablespace being turned to read
only. If I get ORA-01555, I will start drinking.



--
http://mgogala.byethost5.com

On Wed, 13 Oct 2010 21:18:37 +0000, Mladen Gogala wrote:

DB is 64bit oracle 10.2.0.5 on RH Linux 5.5

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi
PL/SQL Release 10.2.0.5.0 - Production
CORE 10.2.0.5.0 Production
TNS for Linux: Version 10.2.0.5.0 - Production
NLSRTL Version 10.2.0.5.0 - Production

Elapsed: 00:00:00.11


--
http://mgogala.byethost5.com

On Oct 13, 6:26*pm, Mladen Gogala <n... (AT) email (DOT) here.invalid> wrote:
Have you considered the possibility of delayed block cleanout?


David Fitzjarrell

On Oct 13, 2:18*pm, Mladen Gogala <n... (AT) email (DOT) here.invalid> wrote:
Re-running... what? I take it you've seen Jonathan's explanation in
http://groups.google.com/group/comp....662de595de9014
I'm wondering if there could be a time-based recursion error - updates
near the end of your needed data wind up in blocks that need to be
cleaned out, and the (perhaps recursive) undo needed to build your
view of those has been rolled off.

So often, to understand ora-1555 you have to think backwards, anything
except your statement could be the real problem.

Do you see any other oddities? I take it you are tracing?

Just don't start drinking recursively. Iterate your drinking, but
exit loop when I start to make sense.

jg
--
@home.com is bogus.
Everybody wants to rule the world.
http://www.signonsandiego.com/news/2...der-biz-stone/

Mladen:

# I received ORA-01555. That in itself wouldn't be much to brag about,
but the circumstances are curious ...

How about a test case that you post and we can then check it out in
other environments?

On Oct 14, 12:52*pm, joel garry <joel-ga... (AT) home (DOT) com> wrote:

avoid infinite loops at all costs!

-- T