ORA-01555 in flashback

Hello to all
My database has bigfile undo tablespace that is autoextended and is retention guarantee
and my disk has enough space
undo_retention is equal 1800 when I execute
select *
from mdb.trde VERSIONS BETWEEN TIMESTAMP
to_timestamp('08/11/2008 22:01:00','dd/mm/yyyy hh24:mi:ss') and
to_timestamp('08/11/2008 22:02:00','dd/mm/yyyy hh24:mi:ss');
I recieve ora-30052 error when i increase undo_retention to 172800 the query
executes fine
but while undo_retention=172800 I execute
select count(*)
from mdb.trde VERSIONS BETWEEN TIMESTAMP
to_timestamp('08/11/2008 22:01:00','dd/mm/yyyy hh24:mi:ss') and
to_timestamp('08/11/2008 22:02:00','dd/mm/yyyy hh24:mi:ss');
I recieve ORA-01555 error, even I set undo_retention=2147483648 I recieve that error too
I expect since the undo tablespace is autoextended and retention quarantee, it increased and I don't
recieve ORA-01555 but it don't happened
do you know what is problem?
thanks
Edited by: ARKH on Nov 9, 2008 3:12 AM

Hi
response to Aman
Undo_retention is equal 172800 it's 48 hour my table has just 350163 record and that query is simple
I expect that query complete in very short time
don't oracle adjust Undo_retention when undo tablespace is autoextended
and in alert i found it :
Sun Nov 9 14:16:47 2008
ORA-01555 caused by SQL statement below (SQL ID: b2gr2cx5acptt, Query Duration=0 sec, SCN: 0x0000.0e3e3068):
Sun Nov 9 14:16:47 2008
select count(*)
from mdb.trde VERSIONS BETWEEN TIMESTAMP
to_timestamp('08/11/2008 22:01:00','dd/mm/yyyy hh24:mi:ss') and
to_timestamp('08/11/2008 22:02:00','dd/mm/yyyy hh24:mi:ss')
Sun Nov 9 14:17:52 2008
ALTER SYSTEM SET undo_retention=8388608 SCOPE=BOTH;
Sun Nov 9 14:18:18 2008
Thread 1 advanced to log sequence 406
Current log# 3 seq# 406 mem# 0: /u01/app/oracle/oradata/tehrep/redo03.log
Sun Nov 9 14:21:31 2008
ALTER SYSTEM SET undo_retention=2147483647 SCOPE=BOTH;
Sun Nov 9 14:21:38 2008
ORA-01555 caused by SQL statement below (SQL ID: b2gr2cx5acptt, Query Duration=2 sec, SCN: 0x0000.0e3e3068):
Sun Nov 9 14:21:38 2008
select count(*)
from mdb.trde VERSIONS BETWEEN TIMESTAMP
to_timestamp('08/11/2008 22:01:00','dd/mm/yyyy hh24:mi:ss') and
to_timestamp('08/11/2008 22:02:00','dd/mm/yyyy hh24:mi:ss')
Sun Nov 9 14:27:43 2008
ORA-01555 caused by SQL statement below (SQL ID: 56fdpt2h9nn33, Query Duration=0 sec, SCN: 0x0000.0e3dc5d9):
Sun Nov 9 14:27:43 2008
select count(*)
from mdb.trde AS OF TIMESTAMP to_timestamp('08/11/2008 21:00:00','dd/mm/yyyy hh24:mi:ss')
Sun Nov 9 14:37:49 2008
Read of flashback database logfile 152, block 1958 found corrupted data.
See trace file for more information.
Reread of flashback database logfile 152, block 1958 found valid data.
Sun Nov 9 14:49:42 2008
Starting background process EMN0
EMN0 started with pid=22, OS id=7975
Sun Nov 9 14:49:46 2008
Shutting down instance: further logons disabled
Sun Nov 9 14:49:50 2008
Stopping background process QMNC
Sun Nov 9 14:49:50 2008
Stopping background process CJQ0
Sun Nov 9 14:49:52 2008
Stopping background process MMNL
Sun Nov 9 14:49:53 2008

Similar Messages

Flashback Query ORA-01555

Gurus,
I'm receiving an ora-01555 error when attempting to run a flashback query. How can I get this resolve as I need to recover records that were deleted!
SQL> show parameter undo
NAME TYPE
VALUE
undo_management string
AUTO
undo_retention integer
604800
undo_tablespace string
UNDOTBS1
Undo Tablespace is 6GB!
select count(*) from bld as of timestamp (sysdate-5);
ORA-01555: snapshot too old: rollback segment number 19 with name "_SYSSMU19_1281712960$" too small
01555. 00000 - "snapshot too old: rollback segment number %s with name \"%s\" too small"
*Cause:    rollback records needed by a reader for consistent read are
overwritten by other writers
*Action:   If in Automatic Undo Management mode, increase undo_retention
setting. Otherwise, use larger rollback segments
All help is greatly appreciated.

Based on what you have posted you are toast. The data you are trying to read is no longer in the undo tablespace and therefore is unavailable to you.
Why you might ask? I suspect you would find great value in reading the most current issue of Oracle magazine: Especially Tom Kyte's article where he specifically addresses this issue.
SQL> select 604800/86400 from dual;
604800/86400
           7Your undo retention exceeds 5 days ... thus all you have accomplished is to waste disk space.

ORA-01555 Snapshot too old, rollback segment too small after flashback tab

Hello
Further to an update on a table in database, I realize that I have done an error and I want to come back in the state of table before this operation.
For this I use 'Flashback table' as this command :
flashback table 'table_name' to timestamp to_timestamp('2010-11-08 08:00:00 AM','YYYY-MM-DD HH:MI:SS PM')
and I get this error :
ORA-01555 :Snapshot Too Old rollback segment N° x , "_SYSSMU9$", too small
What I can do to not have this problem ? can I avoid it ?
Please helps .
Regards
Edited by: 794982 on 12 nov. 2010 05:05
Edited by: 794982 on 12 nov. 2010 05:05
Edited by: 794982 on 12 nov. 2010 05:06

To set the undo retention period:
Do one of the following:
• Set UNDO_RETENTION in the initialization parameter file.
UNDO_RETENTION = 1800
• Change UNDO_RETENTION at any time using the ALTER SYSTEM statement:
ALTER SYSTEM SET UNDO_RETENTION = 2400;
The effect of an UNDO_RETENTION parameter change is immediate, but it can only be honored if the current undo tablespace has enough space.
For more reference.
http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/undo.htm

Help to produce an ora-01555 error.

Hello all,
I've been gotten wind of about UNDO management, but I'm not able to reproduce an ora-01555. I tried one way that I found in some metalink notes but I didn't succeed. I know that using some PL/SQL statements I get there, but how can I achieve it?
I appreciate your help.
Thanks in advance,
Regards,
Emerson

Easy to reproduce. Just use flashback query to an SCN that has aged out of undo.
E.g
SQL> select object_id from test as of scn 5936742 where object_id = 20;
select object_id from test as of scn 5936742 where object_id = 20
ERROR at line 1:
ORA-01555: snapshot too old: rollback segment number 6 with name
"_SYSSMU6_2443381498$" too smallAnother option is to reduce undo retention, shrink the undo tablespace and turn off autoextend. Then in one session run a long select, and in another session run a loop with an update and a commit.
E.g
begin
for i in 1..10000 loop
update test set object_id = object_id where object_id = 20;
commit;
end loop;
end;
/

ORA-01555 while gathering table statistics

Hello All,
While running a job to gather table statics it failed and I saw in my alert logs ORA-01555, below is the job:
DBMS_STATS.GATHER_TABLE_STATS (SCHEMA_NAME, TABLE_NAME, PARTITION_NAME, ESTIMATE_PERCENT => DBMS_STATS.AUTO_SAMPLE_SIZE, METHOD_OPT=> 'FOR ALL COLUMNS SIZE AUTO');What is the reason behind the ORA-01555 ?
How can I prevent it in the future ?
Regards,

There are two queries,
Below query for optimal undo size based on your undo retention
select d.undo_size / (1024 * 1024) "ACTUAL UNDO SIZE (MEGS)",
substr(e.value, 1, 25) "UNDO RETENTION (Secs)",
(to_number(e.value) * to_number(f.value) * g.undo_block_per_sec) /
(1024 * 1024) "NEEDED UNDO SIZE (MEGS)"
from (select sum(a.bytes) undo_size
from v$datafile a, v$tablespace b, dba_tablespaces c
where c.contents = 'UNDO'
and c.status = 'ONLINE'
and b.name = c.tablespace_name
and a.ts# = b.ts#) d,
v$parameter e,
v$parameter f,
(select max(undoblks / ((end_time - begin_time) * 3600 * 24)) undo_block_per_sec
from v$undostat) g
where e.name = 'undo_retention'
and f.name = 'db_block_size';
Below is the result from my database;
        ACTUAL UNDO SIZE (MEGS)     UNDO RETENTION (Secs)     NEEDED UNDO SIZE (MEGS)
       20860                     900          955.6171875
Another query is based how much undo retention you have to configure as per the undo size
select d.undo_size / (1024 * 1024) "ACTUAL UNDO SIZE (MEGS)",
substr(e.value, 1, 25) "UNDO RETENTION (Secs)",
round((d.undo_size / (to_number(f.value) * g.undo_block_per_sec))) "OPTIMAL UNDO RETENTION (Secs)"
from (select sum(a.bytes) undo_size
from v$datafile a, v$tablespace b, dba_tablespaces c
where c.contents = 'UNDO'
and c.status = 'ONLINE'
and b.name = c.tablespace_name
and a.ts# = b.ts#) d,
v$parameter e,
v$parameter f,
(select max(undoblks / ((end_time - begin_time) * 3600 * 24)) undo_block_per_sec
from v$undostat) g
where e.name = 'undo_retention'
and f.name = 'db_block_size';
Below is the result from my database;
        ACTUAL UNDO SIZE (MEGS)     UNDO RETENTION (Secs)     OPTIMAL UNDO RETENTION (Secs)
     20860                           900                         19646
BTW, have you tried again by executing the same ?Yes with no problem, it only happened once
In the link you mention I read the below
"The ORA-1555 happens when people try to save space typically. They'll have small
rollback segments that could grow if they needed (and will shrink using OPTIMAL). So,
they'll start with say 10 or so 1meg rollback segments. These rollback segments COULD
grow to 100meg each if we let them (in this example) however, they will NEVER grow unless
you get a big transaction.
If your database does lots of little transactions, the RBS will never grow on their own.
They will stay small.
Now, someone needs to run a query that will take 5 minutes. On your system however the
rollback wraps every 2 minutes due to lots of little transactions going on. In this
system, ORA-1555's will happen frequently. What you need to do here is size rollback so
that it wraps less frequently (less frequently then your long running queries). Here if
I sized the rollback so that I had 10, 10meg segments (not so they could GROW to 10meg
but that they are starting at 10meg) we would wrap maybe every 20minutes now. that'll
give that 5minute query plenty of time to complete without reusing rollback it needs.
I Think this is exactly my case, how can I resize my redo segments ? and how can I check its current size?

ORA-01555 error ?

I found one ora-01555 error in alert log at 14:37PM.But when i run the following query
select ssolderrcnt from v$undostat where to_char(begin_time,'hh:mi:ss')='14:00:00' and to_char(end_time,'hh:mi:ss')='15:00:00'
no rows selected is getting
It has to show 1 as ora-01555 occured at 14:37pm.
Whats wrong.?

g, the reference material really does not apply to the question of this thread which is finding the v$undostat information for the time period when an ORA-015555 error occurred.
Try this:
select * from v$undostat
where ssolderrcnt <> 0
or nospaceerrcnt <> 0
This should find all v$undostat periods where a 1555 occurred along with periods where you ran short of undo tablespace.
Also v$undostat is only populated where undo management is in effect. There should be 404 rows in this view if undo management is in effect otherwise this view is not useable for this purpose.
HTH -- Mark D Powell --

Refresh Collection Snapshots Error ORA-12008 ORA-01555

Need some insight!
Ct is implementing R12.1.1 ASCP using existing 11.5.10 EBS as source.
In source EBS, when running Refresh Collection Snapshots (RCS) in COMPLETE mode, we encounter this error:
ORA-12008: error in materialized view refresh path
ORA-01555: snapshot too old: rollback segment number 13 with name "_SYSSMU13$" too small
ORA-12008: error in materialized view refresh path
ORA-01555: snapshot too old: rollback segment number 13 with name "_SYSSMU13$" too small
All the snapshot entities got refreshed successfully (in 5 minutes) but the Refresh Collection Snapshot request itself ends with ERROR (after 4 hrs).
Appreciate your input on this one.
Thanks,
Jake

Welcome to the forums !
ORA-01555 is a common error condition. There are typically two solutions (or a combination of both) -
1. Increase rollback / undo tablespace size
2. Run your process when the database is not active (i.e. few or no updates/deletes/inserts etc).
More information may be available in these MOS Docs
211121.1 - How To Run MSRFWOR - Refresh Collections Snapshots Concurrent Request From The Application
207644.1 - Data Collections is Failing - All Errors - First Diagnostic Steps
306418.1 - 11.5.10 MSRFWOR: Refresh Collection Snapshot Performance Is Poor and Fails with Errors
369173.1 - MSRFWOR Refresh Collection Snapshots Performance Database Bug 4196039
308487.1 - Refresh Collection Snapshot Request Fails Yet The Request Shows Complete Normal
HTH
Srini

ORA-01555: snapshot too old: rollback segment number 3 with name "_SYSSMU3$

A Materalized view is scheduled to update every 12 hours . When it has tried to update it has thrown the error ...
ORA-12008: error in materialized view refresh path
ORA-01555: snapshot too old: rollback segment number 3 with name "_SYSSMU3$"
too small
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 803
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 860
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 841
ORA-06512: at line 1

Hi,
Can you increase the size of the UNDO Tablespace ?
For more information, you can find on this link below:
http://forums.oracle.com/forums/search.jspa?threadID=&q=ORA-01555&objID=c84&dateRange=all&userID=&numResults=15
Cheers

ORA-01555: snapshot too old

Hi,
We have audit component, one responsibility of which is to archive audit messages from Oracle database. The component fails on a simple select statement (provided below) that retrieves number of records to be archived based on age parameter:
SELECT COUNT(*) FROM blobobjtable blbt, auditmessagetable msgt WHERE msgt.blobobjtablepk = blbt.blobobjtablepk AND trunc(to_number(substr((SYSTIMESTAMP-msgt.credtimeutc),1,instr(SYSTIMESTAMP-msgt.credtimeutc,' ')))) >= age
We tried the following 3 select statements directly from SQL Plus. The result was that the first two succeeded and the last one failed with "ORA-01555: snapshot too old" exception. We tried these select statements after restart of Oracle database but still got last select statement failed. One thing that we noticed was that the last select statement takes extremely long time to complete. Also, analyzing the index table used during the join failed with the same exception. The same is true when the primary key indices are analyzed.
1) select count(*) from blobobjtable
2) select count(*) from auditmessagetable
3) select count(*) from blobobjtable blbt, auditmessagetable msgt WHERE msgt.blobobjtablepk = blbt.blobobjtablepk
Can somebody explain what might be the cause of ORA-01555 exception for such simple select statement? Does Oracle persists information of UNDO buffers before restart? Is there any way to clean UNDO buffers manually?
If somebody has experience in resolving "ORA-01555: snapshot too old" exception problem please share you experience with us. Any help will be appreciated.
Thanks,
Aleks

how many rows in ur tables.
select count(*) from blobobjtable blbt
SQL> show parameter undo
NAME                                 TYPE        VALUE
undo_management                      string      AUTO
undo_retention                       integer     300
undo_tablespace                      string      UNDOTBS1
SQL> select count(*) from sm;
COUNT(*)
   1326661
Elapsed: 00:00:03.53
SQL> select count(*) from sm;
COUNT(*)
   1326661
Elapsed: 00:00:03.45
SQL> select count(*) from sm ss,ac_taj@taj ac
2 where ss.nserial = ac.nserial;
COUNT(*)
     88763
Elapsed: 00:00:38.35
SQL> show parameter db_name
NAME                                 TYPE        VALUE
db_name                              string      db02
SQL>i have some configuration of undo tbs. but i am not getting any error. also i am just startup my database if right know i am only one user connected to database.
SQL> select bytes/1024/1024 "UNTO MB" from dba_data_files
2 where tablespace_name = 'UNDOTBS1'
3 /
   UNTO MB
       930

Direct Path SQL Loader get error ORA-01555

Hi All,
11.2.0.1 DB
Has anyone here used sqlloader direct path option?
Is there special setting I need for the Undo TS?
I am testing my sqlloader direct path but I got error : ORA-01555: snapshot too old: rollback segment number 10 with name "_SYSSMU10$" too small
I am only testing 100 records and I shutdown the database. And I am only the one using it. :(
Does dropping the Undo TS and creating new one help resolve my issue?
Thanks a lot,
Kinz
Edited by: KinsaKaUy? on 07-Nov-2012 03:33

I drop my UNDOTS1 and recreate it to resolve if there are framentation in the TS itself , but to no avail, the same error persist :(
Record 1: Rejected - Error on table EMPLOYEE.
ORA-00604: error occurred at recursive SQL level 1
ORA-01555: snapshot too old: rollback segment number with name "" too small
SYSTEM                         ONLINE
_SYSSMU87_2780657351$          ONLINE
_SYSSMU88_120427686$           ONLINE
_SYSSMU89_1588874193$          ONLINE
_SYSSMU90_2571046414$          ONLINE
_SYSSMU91_1803654754$          ONLINE
_SYSSMU92_2477693864$          ONLINE
_SYSSMU93_1908993412$          ONLINE
_SYSSMU94_985867735$           ONLINE
_SYSSMU95_4165893730$          ONLINE
_SYSSMU96_1502488804$          ONLINE
_SYSSMU97_3533816217$          ONLINE
_SYSSMU98_3954380786$          ONLINE
_SYSSMU99_1314687851$          ONLINE
_SYSSMU100_3542148152$         ONLINE
_SYSSMU101_1249002234$         ONLINE
_SYSSMU102_1520886654$         ONLINE
_SYSSMU103_2785416951$         ONLINE
_SYSSMU104_1530388055$         ONLINE
_SYSSMU105_1995830672$         ONLINE
_SYSSMU106_4584952$            ONLINE
_SYSSMU107_1177768351$         ONLINE
_SYSSMU108_3896986945$         ONLINE
_SYSSMU109_2576315174$         ONLINE
_SYSSMU110_2786589320$         ONLINE
_SYSSMU111_1195961439$         ONLINE
_SYSSMU112_2612035115$         ONLINE
_SYSSMU113_1697198479$         ONLINE
_SYSSMU114_3939726644$         ONLINE
_SYSSMU115_467875145$          ONLINE
_SYSSMU116_2826382876$         ONLINE
_SYSSMU117_3650068864$         ONLINE
_SYSSMU118_92260707$           ONLINE
_SYSSMU119_2322108460$         ONLINE
_SYSSMU120_2583709550$         ONLINE
_SYSSMU121_1279604730$         ONLINE
_SYSSMU122_2128414833$         ONLINE
_SYSSMU123_1365970622$         ONLINE
_SYSSMU124_1855929876$         ONLINE
_SYSSMU125_1511578664$         ONLINE
_SYSSMU126_3219352797$         ONLINE
_SYSSMU127_2412556110$         ONLINE
_SYSSMU128_2102547636$         ONLINE
_SYSSMU129_447164998$          ONLINE
_SYSSMU130_3851265156$         ONLINE
_SYSSMU131_3046352603$         ONLINE
_SYSSMU132_2987406815$         ONLINE
_SYSSMU133_983809304$          ONLINE
_SYSSMU134_928979873$          ONLINE
_SYSSMU135_3248183819$         ONLINE
_SYSSMU136_811112856$          ONLINE
_SYSSMU137_1958351427$         ONLINE
_SYSSMU138_2222543$            ONLINE
_SYSSMU139_3962620689$         ONLINE
_SYSSMU140_2711665463$         ONLINE
_SYSSMU141_3724825495$         ONLINE
_SYSSMU142_1818253355$         ONLINE
_SYSSMU143_1370485269$         ONLINE
_SYSSMU144_2442636386$         ONLINE
59 rows selected.
SQL>Is there something missing in my sqlloader parameter? but if I use "ordinary" path it will load successfully. But not with "direct" path :( Any ideas please

Receiving error ORA-01555: snapshot too old:

Need some info...
Currently seeing ORA-01555: snapshot too old: rollback segment number 18 with name "_SYSSMU18$" too small.
Info:
SQL> show parameter undo
NAME TYPE VALUE
undo_management string AUTO
undo_retention integer 4200
undo_suppress_errors boolean FALSE
undo_tablespace string UNDOTBS_1
SQL> select max(maxquerylen) from v$undostat;
MAX(MAXQUERYLEN)
35792
SQL>
run this based on threads in here:
SQL> select (35792/60)/60 query,(4200/60)/60 retention from dual;
QUERY RETENTION
9.94222222 1.16666667
I need some help figuring out what to set my undo_retention to? Should it be 36000?
Any help is appreciated.
Thanks

Jamie CC wrote:
The query that was in the alert log was running against a table with 779 rows. The query uses the index (not worried if it wouldn't for that small a table) and came back in one second... This makes no sense. Is it possible that there was a sub-query running and the wrong query was put into the alert log?More likely the query in the alert log was one that died, but the cause was a different query. Remember, the meaning of an ORA-1555 is that the query needed to go back to undo in order to gather a view of the data to a certain SCN, and the data had already been aged out. So the alert log gets the one that died, but the cause is another one. Feel lucky at that, in older versions it was considered an app error IIRC.
Search for the error on asktom.oracle.com for a number of scenarios, and you might want to review the part of the concepts manual about read consistency to make sense of it all. You might also find Tom's book explanation about it with a google search.
Also, depending on your version, there may be things to set like retention guarantee.
I've found on the ERP/MRP systems I work on these errors will appear weekly from people leaving sessions connected after they go home, so I kill 'em off at night. And that's with an undo nearly as big as the db data, that's normally almost empty.

The nature of "ORA-01555: snapshot too old..." error

Hi all,
Please help me to understand the nature of this error:
ORA-01555: snapshot too old: rollback segment number 23 with name "_SYSSMU23_755263746$" too small
One of reports returns this error. Yes, I googled it, but honestly I can't understand deeply what causes it. Usually I resolve it by performing sql request on yesterday's copy of production database. Is it correct to say that this error happens when I try to perform request on tables that are changed in the same moment? What is correct solution to resolve it other than using yesterday's copy of production database?

marco wrote:
Antonio,
The problem is generally small segments of undo, you need to add more space or put guaranty the tablespaces.
How do I describe it for our DBA (how much extra space do I need and what is the name of tablespace)?
Before you go to your DBA, you should figure out how much space your largest query/update uses. That is, your biggest transaction, how much space does it need? 10M? 100M? 1G? From there, your DBA can then size your UNDO properly (or at least "more better" ). Yes he "name of the tablespace" is just called "UNDO").
As mentioned before, the solution might not even be to increase your UNDO size, but rather to identify the "problem job", and fix it. That's not easy, however, talk to your DBA, he may be able to help with that as well.
Things to look for:
1) a job that issues a lot of commits. (suspicious - try to reduce # of commits).
2) a job that runs for a long time and updates along the way (suspicious - try to reduce run time).
3) a job that runs for a long time and has no updates (try to reduce run time - in this case, if this job starts running, and then takes a long time, a lot of other jobs may be reasonably doing updates, and this long run query needs to reference a row that was updated - it might lose it in the UNDO, though).
4) long running queries running at same time as updates on same table. (not always possible, but think about it: a "long running query" is often a "report" of some sort (not always, but often). Try to schedule the reports when less update activity is expected. Or, if the updates are part of the same batch, try to schedule them after each other so they don't overlap. (if the updates are online users, there isn't much you can do except try to decrease runtime of the long running query).
You DBA can help find candidates for those cases.

UNdo error (ora-01555) - Snapshot too old error

Hi,
If undo get filled and if we get a snapshot too old error then what is the solution for this error, plz give step by step solution for this.

You prevent ORA-01555 errors by
1) Setting UNDO_RETENTION equal to or greater than the length of the longest running query/ serializable transaction in the system
2) Ensuring the UNDO tablespace is large enough to accomodate the amount of UNDO generated over that period of time.
You would need to determine things like the length of your longest running query, the amount of UNDO getting generated, etc. and adjust your UNDO_RETENTION and UNDO tablespace accordingly.
Justin

Ora-01555 in 9i Datawarehouse db

Hi,
We have some ora-01555 , mostly on insert /* append */ select from and create tables as select with big tables, the source tables are 2000 millions rows.
The undo tablespace has 49 Gb.
The undo_retention is set to 2500.
It`s true that the executions fails between 4000 and 9000 seconds and the undo_retention is lower, but in v$undostat UNXPSTEALCNT, EXPSTEALCNT, NOSPACEERRCNT, UNXPBLKRELCNT, UNXPBLKREUCNT ara alway 0 so my point of view is that there is no problem of space or undo_retention.
Could you please confirm this ?
If so, could it be a delayed block clenaout problem ?
Regars
Xavi

What is the value of TUNED_UNDORETENTION column of V$UNDOSTAT?
I think you should try increasing undo_retention.

Snapshot too old ORA-01555 from select statement (discoverer)??

Hi All
Am I loosing the plot .. but we have a select statement run from discoverer which is causing the famous snapshot too old error.
My understanding is that undo is generated from select/insert/update.
So why is the following discoverer Select statement causing the error?
from alert
ORA-01555 caused by SQL statement below (SQL ID: gk0wxgqmx66sh, Query Duration=3866 sec, SCN: 0x001e.089cf3f9):
SELECT ( ROUND(( TO_DATE(SYSDATE)-o101038.HIRE_DATE )/365,2) ) as
" bla bla
ORDER BY o101020.SUB_ORGANIZATION_NAME ASC
Thanks in Advance

simon.9999 wrote:
Hi All
Am I loosing the plot .. but we have a select statement run from discoverer which is causing the famous snapshot too old error.
My understanding is that undo is generated from select/insert/update.
So why is the following discoverer Select statement causing the error?
from alert
ORA-01555 caused by SQL statement below (SQL ID: gk0wxgqmx66sh, Query Duration=3866 sec, SCN: 0x001e.089cf3f9):
SELECT ( ROUND(( TO_DATE(SYSDATE)-o101038.HIRE_DATE )/365,2) ) as
" bla bla
ORDER BY o101020.SUB_ORGANIZATION_NAME ASC
Thanks in Advance
The SELECT statement is the victim.
Some session is doing DML against the same table against which the SELECT occurs & is likely doing COMMIT inside a LOOP.

ORA-01555 in flashback

Similar Messages

Maybe you are looking for