ORA-01555 in Oracle 9.2.0.5

we running Baan IV on a Oracle 9.2.0.5 database.
Sometimes we got an error in the alert log file like:
ORA-01555 caused by SQL statement below (Query Duration=60440 sec, SCN: 0x0001.a452e41c)
Now, i want to know which user with which sql-statement (if possible) get this error.
So this error is mostly at night, i try to write a trigger to get this information.
But i don't know how to do this.
Can somebody help me ?
T.Kindermann

Now, i want to know which user with which sql-statement (if possible) get this error.If you see the alert log file, you will also have the sql that caused ora-1555 errors along with time stamp.
If you are using AUM (automatic Undo management), tune your undo parameters and tablespace using v$undostat. If you are using MUM (manual rollback segment), create a big rollback segment and assign to this transaction.
Jaffar

Similar Messages

Oracle error: Ora-01555 : snapshot too old: rollback segment number 1......

System Error: Unknown Database error (type qqdb_ResourceException) on WMS_WH1: Execute failed for SQL statement ............... error from database is: ORA-01555: snapshot too old: rollback segment number 1 with name "_SYSSMU1$" too small...
Any ideas ? Please help.
Thank you.

You either have
- an UNDO tablespace that is way too small (rollback segments that are too small); or
- an application that does way too many COMMITs (common with apps ported from SQL Server)
From the added info, I would guess that the Java program has a major loop and does processing on each of the values it gets in that loop. At the end of each turn in the loop, it does a commit. Then it tries to look at the next record in the master list. After a while (say around 388 loops ;-) ) it dies.
The reason is that when it looks for information in the master query, it needs to rebuild that information to the moment that query was initiated. It uses rollback (AKA undo) to rebuild that. But rollback is not guaranteed to exist after a commit (unless forced) and once a commit happens, that area can be reused. When it is reused, the information is no longer there to rebuild the row, and that raises an ORA-01555
Edited by: Hans Forbrich on Sep 11, 2009 3:44 PM

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

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.

Expdp fails with ORA-31693, ORA-02354 and ORA-01555

Hi,
Oracle Database 10.2.0.4.0, Windows Server 2003
I was doing a full database DATA PUMP export as follow:
expdp system/pass@SID FULL=y DIRECTORY=MY_EXPORT DUMPFILE=EXPORT_DB.dmp logfile=EXPORT_DB.log
It always worked fine but today I received an error message :
ORA-31693: Table data object "S"."TABL1" failed to load/unload and is being skipped due to error:
ORA-02354: error in exporting/importing data
ORA-01555: snapshot too old: rollback segment number 10 with name "_SYSSMU10$" too small
The undo_retention parameter is set to its default of 900 currently.
Datafile in UNDO tablespace is 5GB used and this datafile is autoextend up to 32GB.
Any idea of what may causes this error ?
Thanks!

This happens only with the two largest tables which are around 11GB.
Today I do several times export, but always with one error.
First time error with one table, second time with another table... Everything else is exported without errors.

ORA-01555: snapshot too old: rollback segment number with name "" too smal

Hi,
I'm working on Oracle Database 11g Release 11.1.0.6.0 - 64bit Production With the Real Application Clusters option.
I'm exepriencing the error in the subject executing a procedure.
This procedure run at 2am, reading from a table all records written the day before:
... WHERE date_write between d1 and d1+1 ....
d1 = trunc(sysdate-1)So I suppose that the recordset cannot be changed during the execution of the procedure.
The recordset extracs more or less 10milions of records.
The procedure than read few records from another table and then insert a new record into a table (trying to delete it if already existing).
I commit every 10k records.
What I noticed is that the procedure always fails after 1 hour, that's the undo_retention value.
I tried to change the param to 2 hours, and last run failed after 2 hours...
I think I understood the ORA-01555 causes, but I thought the commit would have avoid it.
So, any suggestion?
Thanks in advance!
Samuel

What's then the logic why the commit is causing it?When you commit a transaction, involved undo blocks are "released", and they might be overwritten : if those blocks are needed for consistency, then you get ORA-01555 error.

ORA-01555: snapshot too old while creating large index

Dear All,
I have a newly created partitioned table of size 300GB.
On which i am creating a composite unique index having 5 columns(local partitioned).
The size of the index may be around 250GB(assume from a similar type table).
My DB version in Oracle 9i release 2.
Size of my undo tablespace is 12GB.
Undo related parameters are as below:
undo_management AUTO
undo_retention 18000
undo_suppress_errors FALSE
At 10:40:36 AM i fired the "create index .... local;" query
All day long i was monitoring using "select used_ublk,addr from v$transaction" and same below output all the times:
USED_UBLK ADDR
1 C000000185ECF458
[ using v$session(column TADDR) i found that "C000000185ECF458" is the ADDR of my transaction (if i am not wrong) ]
But at 11:09:27 PM (about 12 hours later) i found: ORA-01555: snapshot too old
I am sure that at that time my undo tablespace usages was below < 30%
At that time some insertion & selection was going on but those were not on this table.
Why this happened ? As far as i know oracle in AUM oracle doesn't overwrite existing undo data as long as there
is free space available.
While searching on web i found one post as below:
like

Thanks guys for your prompt replys.
Yes i've monitored v$TEMPSEG_USAGE and DBA_SEGMENTS for the progress of the index creation, but this are not related to my question and yes i could use nologging or parallel (in gact i'm going to try all these options for faster index creation). On my original post i missed below part, please go through it:
While searching on web i found one post as below:
metalinknote #396863.1 which describes it
=> 2) When are UNDO segments OFFLINED?
Answer:
SMON decides on the # of undo segs to offline and drop based on the max transaction concurrency over a 12 hour period in 9i. This behavior is altered in 10g where the max concurrency is maintained over a 7-day period. Moreover, in 10g SMON doesn't drop the extra undo segs, but simply offlines them. SMON uses the same values with "fast ramp up" to adjust the number of undo segments online.
Link:[http://kr.forums.oracle.com/forums/thread.jspa?threadID=620489]
I says "SMON decides on the # of undo segs to offline and drop based on the max transaction concurrency over a 12 hour period in 9i.".
what does it mean ? Is this the cause for me, as my query war 12 hours old and my undo_retention is set to 5 hours ?
I'll be very grateful if some one explains the cause.
BR
Obaid

ORA-01555 thrown at DB Startup

Hello guys :)
We have the following situation on one of our test DBs. We are trying to open a DB after restore from hot backup with no archivelogs. The situation is rather interesting, since we don't have a prerequisite for 100% data consistency. We just need to open up the DB after the restore.
The restore finishes and now comes the tricky part. When we try to open the DB it throws the obvious "You need more recovery" error. OK, we startup nomount and recreate the controlfile. Still you need more DB recovery. OK, next option was putting this line in the init file
ALLOWRESETLOGS_CORRUPTION=TRUE
We can now open resetlogs! Yes, but no!
alter database open resetlogs; crashes with ORA-01555
Tue Aug 17 22:11:17 2010
ORA-01555 caused by SQL statement below (SQL ID: 4krwuz0ctqxdt, Query Duration=1282072277 sec, SCN: 0x0012.8c929e0c):
Tue Aug 17 22:11:17 2010
select ctime, mtime, stime from obj$ where obj# = :1
Tue Aug 17 22:11:17 2010
Errors in file /appli/oracle/admin/???/udump/???_ora_3141812.trc:
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 1
ORA-01555: snapshot too old: rollback segment number 19 with name "_SYSSMU19$" too small
Error 704 happened during db open, shutting down database
USER: terminating instance due to error 704
Instance terminated by USER, pid = 3141812
ORA-1092 signalled during: alter database open resetlogs...
So, next guess is to put this in the init file:
corruptedrollback_segments=('_SYSSMU19$')
and try to open up again.
Have you ever tried such an approach and succeeded? Any suggestions and comments are greatly appreciated :)

Beco wrote:
Do you think putting the rollback segment offline and after that dropping it may help?
It is just a suggestion, but if does not work I will have to restore the DB again :) So any thoughts?Dear Beco ,I can not say exactly what happen after implement offlinerollback_segments parameter.
I before say there are two problem.When recovery process oracle need request(need get information of undo) undo tablespace.But undo segment actually corrupted therefore you got this error.To testing purpose you need on ly apply this one parameter(hidden) only one(in this case).You say that is test db then create new test db and shutdown abort then move online log to other location.Then you can implement ALLOWRESETLOGS_CORRUPTION.But never implement these parameters production database.

Ora-01555 even after proper undo settings

Hi All,
OS : Linux
Oracle : 10.2.0.3.0
Last few weeks i am keep on facing 01555 error for some queries.
Please see my undo settings below
SQL> show parameter undo
NAME                                 TYPE                              VALUE
undo_management                      string                            AUTO
undo_retention                       integer                           1200
undo_tablespace                      string                            UNDOTBS1###############################################
SQL> declare
retention number ;
undo_ts_size number ;
   begin
   retention := DBMS_UNDO_ADV.REQUIRED_RETENTION ;
   undo_ts_size := DBMS_UNDO_ADV.REQUIRED_UNDO_SIZE(retention) ;
   dbms_output.put_line('Current retention ' || retention );
   dbms_output.put_line('Required tablespace size is ' || undo_ts_size);
end ;
Current retention 1100903
Required tablespace size is 198527
PL/SQL procedure successfully completed.####################################################
Tablespace Name                     Ext. Mgt. Seg. Mgt. Tablespace Size (in MB)       Used (in MB)       Free (in MB) Pct. Used
UNDOTBS1                            LOCAL      MANUAL                     16,500              *1,708*             14,792        10###############################################################################
As its an oracle 10.2.0 version, i read that oracle will adjust retention period based on the long running quries & undo advisor is giving recommondation to set tablespace size to 198 G but i cannot understand why my undo tablespace is only 10% used when i am getting ora 01555 error ? mence there is no problem with retention as well as space then where is the problem ?
Also i checked if there is any stealing/reuse is happening but this below query returns 0
select UNXPSTEALCNT,UNXPBLKREUCNT from V$UNDOSTAT;
           0             0
           0             0
576 rows selected.
SQL>#########################################################
Could you please help me to identify the problem which i am facing ?
Thanks
Nisanth Santhan

but as per the below document, in 10.2 onwards even if we set undo retention, oracle will automatically adjust the retention based on the long running query . It seems we can even set 0 for undo retention. I have checked, my current auto undo retention setting is (1100822 sec).
http://www.oracle.com/technology/products/manageability/database/pdf/ow04/1241_minhas_pres.pdf

ORA-01555 & ORA-00704

After restoring a cold backup I tried to start the DB and got the below mentioned error,
ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced
In alert log,
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 1
ORA-01555: snapshot too old: rollback segment number 7 with name "_SYSSMU7$" too small
Error 704 happened during db open, shutting down database
USER: terminating instance due to error 704
Instance terminated by USER, pid = 21163
ORA-1092 signalled during: Alter database open...
Please help. We do not have archival log backup and also backup files.

I tried that option, still having the same problem.
Mon Jan 2 23:04:08 2012
alter database open resetlogs
Mon Jan 2 23:04:08 2012
RESETLOGS is being done without consistancy checks. This may result
in a corrupted database. The database should be recreated.
RESETLOGS after incomplete recovery UNTIL CHANGE 47645958449
Resetting resetlogs activation ID 2847169495 (0xa9b45bd7)
Mon Jan 2 23:04:37 2012
Online log /stage2/donotdelete/Cold_untar_P2P/PSP2PATW/log02/log03a.dbf: Thread 1 Group 3 was previously cleared
Online log /stage2/donotdelete/Cold_untar_P2P/PSP2PATW/log03/log03b.dbf: Thread 1 Group 3 was previously cleared
Mon Jan 2 23:04:38 2012
Setting recovery target incarnation to 3
Mon Jan 2 23:04:39 2012
Assigning activation ID 2847160009 (0xa9b436c9)
Thread 1 opened at log sequence 1
Current log# 1 seq# 1 mem# 0: /stage2/donotdelete/Cold_untar_P2P/PSP2PATW/log02/log01a.dbf
Current log# 1 seq# 1 mem# 1: /stage2/donotdelete/Cold_untar_P2P/PSP2PATW/log03/log01b.dbf
Successful open of redo thread 1
Mon Jan 2 23:04:39 2012
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Mon Jan 2 23:04:39 2012
SMON: enabling cache recovery
Mon Jan 2 23:04:39 2012
ORA-01555 caused by SQL statement below (SQL ID: 4krwuz0ctqxdt, SCN: 0x000b.17eba136):
Mon Jan 2 23:04:39 2012
select ctime, mtime, stime from obj$ where obj# = :1
Mon Jan 2 23:04:39 2012
Errors in file /usr/oracle/admin/RECOVER/udump/recover_ora_22114.trc:
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 1
ORA-01555: snapshot too old: rollback segment number 7 with name "_SYSSMU7$" too small
Error 704 happened during db open, shutting down database
USER: terminating instance due to error 704
Instance terminated by USER, pid = 22114
ORA-1092 signalled during: alter database open resetlogs...

ORA-01555 with ORA-02063 when submitted Concurrent Requests

Hello,
My development team has reported some CM Requests got failed with some errors.When i checked the request log file i saw :java.sql.SQLException: ORA-01555: snapshot too old: rollback segment number with name "" too small ORA-02063: preceding line from EIHFDM .Could you please help me out this to solve this issue.
We are on Oracle Database 10g Release 10.2.0.5.0 - 64bit
Application 11.5.10
I have checked the UNDO Parameter values
ACTUAL UNDO SIZE (MEGS) UNDO RETENTION (Secs)                OPTIMAL UNDO RETENTION (Secs)
                                 304849                               40000                4860
Thanks,
Prabhat.

Hi Asif,
This is a customized program.
I have checked the UNDO Parameter values
SQL> show parameter undo
NAME                                 TYPE        VALUE
_in_memory_undo                 boolean     TRUE
_undo_debug_usage              integer     2
undo_management                 string      AUTO
undo_retention                       integer     40000
undo_tablespace                    string      APPS_UNDOTS
SQL>
ACTUAL UNDO SIZE (MEGS) UNDO RETENTION (Secs)                OPTIMAL UNDO RETENTION (Secs)
                                 304849                               40000                4860

ORA-01555 caused by SQL statement below on production

Hi
i got ORA-01555 caused by SQL statement below on my prodution adn database undo_retention = 18000 what can i do my database performance is going down pls tail me what i do .
Regards
Digvijay

1) I don't see a SQL statement here
3) How did you determine that UNDO_RETENTION of 18000 was appropriate?
4) How much UNDO is your system generating?
6) Do you believe this is related to your performance problems? If so, why do you believe that?
At the risk of stating the obvious... You've told Oracle to try to maintain UNDO for 18,000 seconds (5 hours). You have a query that runs for roughly 6.25 hours. If, after running for 6.25 hours, that query needs a block that was modified, say, 6 hours ago, it may not find it because you've told Oracle you don't need it any longer.
Your UNDO_RETENTION needs to be greater than the longest-running query you expect to run. You can bump up UNDO_RETENTION if you'd like. However, I tend to believe that a query that died after 6.25 hours is probably a query that is in desparate need of tuning. If you reduce the query runtime to something less than 5 hours, you could keep UNDO_RETENTION at the current setting.
Justin

Diagnosing ORA-01555: what table had the unreconstructable block?

We have some very long-running batch processes (i.e. > 20 hours for a single INSERT statement) and we sometimes get ORA-01555 (snapshot too old) failures. Our undo_retention is 10800 seconds=3 hours.
We have discussed (with the development team) the combination of events that are needed for this situation to arise. They are unable to think of a situation where any of the tables (in today's incident, there are 7 of them) would have been updated after this job started.
Is there a method for analyzing the trace file to determine which table had the block that could not be reconstructed due to overwritten UNDO? This might give us ideas for how to avoid this via operational changes (i.e. changing the job schedule).
Of course, we are also pursuing tuning efforts for this query.
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 Solaris: Version 10.2.0.5.0 - Production
NLSRTL Version 10.2.0.5.0 - Production
Thanks,
Mike

Well you could still check to see if there are any uncommitted transactions for those tables:
Query the DBA_DML_LOCKS view (and/or DDL view)
http://docs.oracle.com/cd/E11882_01/server.112/e25513/statviews_3157.htm
select * from DBA_DML_LOCKS
SESSION_ID,OWNER,NAME,MODE_HELD,MODE_REQUESTED,LAST_CONVERT,BLOCKING_OTHERS
10,SCOTT,EMP_READ_ONLY,Row-X (SX),None,1163,Not Blocking
69,SCOTT,EMP_READ_ONLY,Row-X (SX),None,1648,Not Blocking
That shows that two session are holding exclusive row lock on the EMP_READ_ONLY TABLE. As a test I inserted a row from two different sessions but did NOT commit it yet.
The DDL version of the view can be used in addition.
See my reply Sep 4, 2013 12:23 AM in this thread from yesterday for more info.
https://forums.oracle.com/message/11174417#11174417
At least in 10g you can tell before you start if there are any issues to resolve. If there are no issues then once you start your query there won't be any issues that could cause the snapshot problem since your query will be first in line.

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 in Oracle 9.2.0.5

Similar Messages

Maybe you are looking for