ORA-01555 in RAC

Hello experts,
I am having 4 node oracle 9i on IBM AIX .
We are having different size of undo tablespace but same value of undo_retention in each node .
In our application we are running reports from a particular node and getting ORA - 01555 frequently. what if i increase the undo_retention in this node only ?
Regards
Mals

Thank you Hoek,
Our application is designed such that maximum load/ activity in on node one thats why undo tablespace of 50 GB.
Rest of the nodes are not much active so have less size of undo 15 GB each .
So longest running queries are different on each node ( node one 90036 and node four 12948 ) Than how the same undo_retention = 25000 solves the purpose ?
Regards

Similar Messages

ORA-01555: snapshot too old: - export- RAC

We are getting ORA-01555: snapshot too old: rollback segment number , in 3 node RAC while doing export for multiple schemas. undo rentention is set more than a day for all nodes,. undo tablespace has got enough space. Can anyone tell me what i need to look here.

hi,
can you please post below details...
oracle version,os version?
and what export command your using...
hope your using consistent =y ..while using this parameter we require big size of undo tablespace size....
refer metalink note...113450.1
thanks,
DBC,
Sr DBA,
Oracle certified expert.

Ora-01555 when export DB on RAC 11GR2

Hi all,
I run a full export on my 11GR2 DB and i have 6 errors on sysman tables :
ORA-31693: Table data object "SYSMAN"."MGMT_POLICY_ASSOC_EVAL_SUMM" 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 21 with name "_SYSSMU21_2772229671$" too small
Do you have an idea ?
Thanks.

$ oerr ora 1555
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 segmentsIf you increase undo_retention parameter you may also need to increase undo tablespace datafiles.

Active Data Guard and Undo and ora-01555

Hi
We have an 11.1.0.7 two-node RAC primary with a single instance Active Data Guard physical standby. When running a datapump export from the standby, we get an ORA-01555 although the undo_retention is set way beyond the run time for the export.
I'm looking to better understand undo within the context of Active Data Guard. Is there any dependency for undo between the primary(s) and standby? Are the undo settings (undo_retention, undo tablespace size..) on the primary and standby independent of each other?
Thanks.

The standby is a Physical Standby. An exact copy of the Primary. The undo at the standby is controlled by the redo coming from the Primary. When the undo gets overwritten at the Primary it gets overwritten at the standby regardless of what is running there. You can't have undo kept around longer at the standby, it is an EXACT copy of the Primary.
Increasing the undo tablespace and the undo_retention at the Primary will allow more undo to be kept at both the Primary and the Standby but the standby is still controlled by the Primary's management of the undo. Of course you should change the parameter at the standby too so that everything behaves the same when you make the standby a Primary database.
Hope this helps.
Larry

ORA-01555: snapshot too old error while ANALYZE command!!!

Hi All,
I have 2-node 10gR2 RAC on RHEL4. The database is working fine. And i am able to import the schema also. But when i try to analyze all the tables in schema..i'm getting the following error...my undo_tablespace is of 1.2GB in both instances of RAC. and unde_retention is set to 900 (default).
ORA-01555: snapshot too old: rollback segment number with name "" too small
Please, can anybody tell me what might be the problem?
Thanks
Praveen.

Hi,
When the analyze of the table is going on, lot of dml activity is also going on to the table. So run the analyze when there is minimal dml activity on the table. Increase undo_tablespace,undo_retention might help your scenarios.
10g has got guaranteed undo retention, you can also use that.
Regards,
Satheesh Babu.S
http://www.satheeshbabus.blogspot.com

ORA-01555 even though undo tablespace is with autoextend ON

Hi,
I don't get it, how come I get ORA-01555 even though my undo tablespaces are (it's a RAC system) both autoextend ON
Thanks

912294 wrote:
Hi,
I don't get it, how come I get ORA-01555 even though my undo tablespaces are (it's a RAC system) both autoextend ON
Thanksthe session that reports ORA-01555 is the victim; not the culprit.
typically the session that throws ORA-01555 has LONG running SELECT against some table (TAB_A).
ORA-01555 results when another session is doing DML against TAB_A & doing COMMIT inside LOOP.

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 RAC

Similar Messages

Maybe you are looking for