ORA-1555 (SNAPSHOT TOO OLD)의 일반적인 원인 및 조치사항

제품 : ORACLE SERVER
작성날짜 : 2003-09-29
ORA-1555 (SNAPSHOT TOO OLD)의 일반적인 원인 및 조치사항
===========================================
PURPOSE
ORA-1555 (snapshot too old)는 db 관리 업무에 익숙하지 않은 경우, rollback
관련된 오류 중 혼란을 일으키기 쉬운 오류이다.
이미 문서 <bulletin:11152>와 그외 자료가 이 오류를 설명하고 해결하기 위해
만들어져 있지만, ORA-1555 원인 파악을 위해 내용이 다소 길고 복잡하게
구성되어 있는 편이다.
여기에서는 발생 가능한 여러가지 원인 중 일반적인 원을을 위주로, 초보자도
쉽게 이해할 수 있도록 간단히 설명한다.
Explanation
일반적으로 ORA-1555에 혼란을 일으키는 원인은 한편으로는 오류 메시지 자체에
있다고 볼 수 있다.
ORA-1555: snapshot too old: rollback segment %s too small
이와 같은 오류에서 마치 ora-1555가 rollback segment에 write시 space가
부족해서 발생하는것으로 착각하는 사용자가 많다.
중요한 것은 ORA-1555는 rollback segment에 정보를 write시에 발생하는 것이
아니고 rollback segment로 부터 before image를 읽으려는 시점에서 발생한다는
것이다.
쉬운 예를 들어보자.
(1) 사원이 천명인 회사에서 select한 문장으로 그 전체 사원의 정보를 읽는데
10분이 걸린다고 가정한다.
(2) 100번 사원 정보를 읽는데, 아직 읽지 않은 700번 사원에 대해 다른 session에서
급여를 인상하는 update문장을 수행하고 commit을 한다.
select문장은 lock을 걸지 않기 때문에 select도중 다른 update문장이
수행되고 commit하는데 아무 문제가 없다.
(3) 1번에서 수행중인 select문장이 계속 진행되면서 700번 사원 정보를 읽으려고
하면 이 정보가 수정되어 변경되었음을 알게 된다.
그럼 select문장은 정보의 일관성을 위해 첫번째 사원을 읽기 시작한 시점의
700번 사원에 대한 정보를 읽기 위해, 즉 before image를 읽기 위해
rollback segment를 찾아간다.
(4) rollback segment내에 급여 인상 전 정보가 있으면 읽는다.
단 이때,
이 시스템에 트랜잭션이 매우 많아서 commit이 매우 많이 발생한 경우
이미 2번에서 변경하고 commit한 정보는 다른 트랜잭션에서 overwrite했을
수 있다.
이런 경우 before image를 읽으러 간 select문장은 ora-1555를 만나게 되는
것이다.
(5) 4번에서 ora-1555를 만난 경우 다시 동일한 select문장을 수행하면,
이번에는 이미 급여가 인상된 후의 시점에서 시작하므로 700번 사원을
읽는 경우에도 급여 인상전의 before image가 필요하지 않아 ora-1555는
다시 발생하지 않을 수 있다.
이러한 이유로 ora-1555는 발생했다 안했다 하는 식으로 일정하게 발생되지
않고, 조치 방법이라는것도 100% 안전하기보다는 확률적으로 충분히 만나지
않을 수 있는 환경을 만드는것이라고 볼 수 있다.
결국 ora-1555가 발생하는 것은 읽어야 하는 before image가 다른 트랜잭션에
의해 이미 overwrite되어 읽을 수 없는 경우 발생하므로, 발생하지 않게 하기
위해서는 데이타를 조회시 consistency를 유지해야 하는 시점동안 가능하면
오래 동안 rollback의 image가 유지되어야 하는것이다.
이렇게 이미 기록된 정보를 가능하면 오랜 기간동안 유지한다는 것은 새로운
트랜잭션의 기록을 위해 space를 확보해야 하는 작업과는 반대된다.
즉, ORA-1562와 같이 rollback segment를 write시에 space가 부족하여
space를 확보하기 위한 조치 방법과, 이 ORA-1555의 조치 방법을 서로 상충되어
trade-off가 있음을 주의해야 한다.
두 오류를 모두 피해가기 위해서는 일반적으로 매우 큰 rollback space가
도움이 된다.
ORA-1555의 일반적인 발생 경우 및 해결 방법을 정리한다.
(1) 트랜잭션에 비해 rollback segment 갯수가 적은 경우
rollback segment하나에 동시에 기록 가능한 트랜잭션의 수는 rollback
segment header내의 transaction table의 entry갯수로 제한되어 있다.
이 수는 oracle version마다 다르지만 8i이상부터는 약 20개 정도이다.
(transactions_per_rollback_segment의 지정과는 무관한다.)
기본적으로 install시 생성되는 rollback segment는 4개인데, 이대로 놓고
사용한다면, 결국 80 (20 * 4) 만큼의 commit이 발생하고 난 뒤에는
다시 처음부터 transaction table의 entry 중 commit된 트랜잭션의
정보를 가지는 entry의 정보를 overwrite하게 되는 것이다.
해결 방법: rollback segment갯수를 증가시킨다.
즉 새로운 rollback segment를 create시킨다.
부작용: 제한된 rollback tablespace공간 내에서, 여러개의 rollback
segment를 유지하는것은 하나의 rollback segment가 평균 가질 수
있는 space가 그만큼 줄어드는 셈이다.
이 부작용까지 줄이려면, rollback tablespace자체가 충분히
커야 하고 space를 많이 요구하는 트랜잭션은 'set transaction
use rollback segment' 문장을 이용하여 큰 rollback을 지정하여
사용하도록 한다.
(2) rollback segment를 shrink하거나 optimal이 설정된 경우
rollback segment를 shrink하거나 optimal을 지정하게 되면 이미 쓰여진
rollback의 before image를 다른 트랜잭션이 overwrite도 하기 전에 미리
지워 버리게 되는 셈이다.
그러므로 이런 경우도 ora-1555의 원인이 된다.
해결 방법: optimal을 너무 적게 지정하지 말고, shrink를 너무 자주
하지 않는다. shrink를 수행 후 ora-1555가 발생하는 경우,
단지 다시 조회하는것만으로 앞의 예제 (5)번에서 설명한
이유로 인해, 해결되는 경우가 많다.
(3) proc와 같은 application에서 loop내의 fetch문장에서 자주 commit을
하는 경우
fetch문장은 loop를 도는 동안 일정하게 read consistency를 유지해야 한다.
그리고 미리 cursor를 정의시에 데이타를 읽어두는것이 아니고, fetch시에
loop를 돌면서 그때그때 데이타를 읽게 된다.
그런데 loop내의 dml에 대해 너무 자주 commit을 하게 되면 그만큼
여러개의 트랜잭션이 처리된 결과로 rollback segment의 transaction table이
빨리 사용되고 overwrite되게 된다.
해결 방법: loop내의 commit횟수를 줄인다. 예를 들어 loop를 돌때마다
commit하게 하였다면 천번에 한번 혹은 만번 loop를 돈 후
commit하는 식으로 늘려준다.
이 외에도 rollback tablespace자체의 space가 부족하여 transaction table의
entry들이 아직 overwrite되지도 않았는데, commit된 transaction이 사용한
rollback segment내의 space가 먼저 overwrite되는 경우도 있다.
그러나 일반적으로 rollback segment의 space를 너무 작게 유지하지는 않기
때문에 이렇게 space부족으로 ora-1555를 만나는 경우는 많지 않다.
이렇게 space가 절대적으로 부족한 경우는 rollback에 write하는 시점에서,
ora-1562가 먼저 발생하게 된다.
ora-1562에 대해서는 <bulletin:10823> "ORA-1562 분석 및 해결 방법
(ROLLBACK SEGMENT 크기 문제)"를 참조하고,
좀더 자세한 ora-1555의 개념에 대해서는 <bulletin:11152> "ORA-1555 원인
분석 및 조치 사항" 을 참조한다.

Similar Messages

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.

ORA-01555: snapshot too old / set transaction

Hello,
When I execute a query in a script I have the following error: ORA-01555: snapshot too old...
At the beginning of the script I have SET TRANSACTION use rollback segment XX.
On the other hand I used SET TRANSACTION READ ONLY and I had no errors.
It is a fate or it is the solution?
What is the difference?
Thanks

It's probably just fate. SET TRANSACTION READ ONLY guarantees a read consistent view during the whole transaction rather than an individual statement, but it is not a sovereign remedy against ORA-1555.
SET TRANSACTION USE ROLLBACK SEGMENT XXXX is meaningless in the context of a SELECT only transaction.
The ORA-1555 is casued by someone else doing DML that the rollback segment holding the undo information that Oracle uses to provide read consistency. The way to prevent it is to manage the rollback segments properly - big, numerous, high minextents, no shrinking - or to use 9i UNDO tablespace instead.
Cheers, APC

ORA-01555: snapshot too old: rollback segment number

I getting error while i am taking export one of the table.
EXP-00056: ORACLE error 1555 encountered
ORA-01555: snapshot too old: rollback segment number with name "" too small
ORA-22924: snapshot too old
Export terminated successfully with warnings.
can someone advise me

1) What version of Oracle?
2) Is UNDO_MANAGEMENT set to AUTO? Or are you still using manual undo management?
3) What is your UNDO_RETENTION? How quickly are you generating UNDO? How big is your UNDO tablespace?
4) How long does the export run?
5) Did you specify CONSISTENT=Y in the export? If so, is that necessary?
6) What else is going on? Is it possible to run the export during a quieter period?
Justin

ORA-01555 Snapshot too old - opening scheduled report

This seems to happen to long running scheduled reports - but not consistentlly. This one in particular ran for 14 hours and then ended with an this error - ORA-01555 snapshot too old: rollback segment number 2 with name "_SYSSMU2_1285383686$" too small. What does this mean?

Pl post details of OS, database and discoverer versions.
This is a common error - you will need to get your DBA team involved, and it is fixed easily. See these MOS Docs
ORA-01555: "Snapshot too old" - Overview (Doc ID 10630.1)
ORA-01555 "Snapshot too old" - Detailed Explanation (Doc ID 40689.1)
ORA-1555 Using Automatic Undo Management - How to troubleshoot (Doc ID 389554.1)
HTH
Srini

Why ORA-01555 (Snapshot too old) occures on an unchanged table

Hello,
we have to add a not null column into a large table. The simple update is not good, due to UNDO space.
alter table T add F INTEGER default 0 not null;
ORA-30036: unable to extend segment by in undo tablespace ''It is OK. (We cannot use create + insert + drop + rename due to not enough free space. The table is not partitioned current) So we try this script:
--create the column without default and not null
alter table T add F INTEGER;
--create temp table with the rowids of T (nologging -> minimal log)
create table TMP (row_id rowid) nologging;
--save the rowid-s. (direct -> minimal undo usage)
insert /*+APPEND*/ into TMP(row_id) select rowid from T;
commit;
--the "insert method"
--set the column to "0" with frequently commit
declare
i integer := 0;
commit_interval integer := 10000;
begin
for c in (select * from TMP) loop
    update T set F=0 where rowid=c.row_id;
    i := i + 1;
    if( mod(i,commit_interval)=0) then commit;
    end if;
end loop;
commit;
end;
--set to not-null
alter table T modify F default 0 not null;
--drop the temp table
drop table TMP;the insert method occures
ORA-01555: Snapshot too old (in row 5)The row 5 is the cursor "select * from TMP" in the insert method. The undo usage of this method is below 2 MB.
My question is:
Why oracle need snapshot, while the TMP table does not change during the insert method? The TMP table was populated and commited before the insert method. Why oracle try to read the rows of the TMP table from the undo tablespace?
Thx: lados.

Thank, I have read this article, but there is something, what I don't understand.
As I see, the DML does not clear all the modified datablock header, but it clears only the rollback segment slots. Only the next SQL (even if this is a query) clears the datablock header. This next SQL can clear only when the info is still available in the rollback segment, else ORA-1555 occures.
My question is:
What happens when the next SQL comes only one year later on this block? I don't believe that oracle doesn't handle this situation, but I didn't find how it is handled.
Thx: lados.

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

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.

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: snapshot too old: rollback segment number 8 with name

Hi,
Database version is Oracle8i Enterprise Edition Release 8.1.7.4.0
I am struggling to fix this error, since I have not worked on 8I DATABASE.
We getting this kind of error very frequently in one of the 8i database.
ORA-01555: snapshot too old: rollback segment number 8 with name "ROLLBACK08" too small
How do i fix this permantely.
I have verified the RBS configured in the db.
SEGMENT_NAME TABLESPACE_NAME OWNER STATUS
SYSTEM SYSTEM SYS ONLINE
ROLLBACK0 SYSTEM SYS OFFLINE
ROLLBACK02 RBS1 SYS ONLINE
ROLLBACK03 RBS1 SYS ONLINE
ROLLBACK04 RBS1 SYS ONLINE
ROLLBACK05 RBS1 SYS ONLINE
ROLLBACK06 RBS1 SYS ONLINE
ROLLBACK07 RBS1 SYS ONLINE
ROLLBACK08 RBS1 SYS ONLINE
ROLLBACK09 RBS1 SYS ONLINE
ROLLBACK10 RBS1 SYS ONLINE
ROLLBACK01 RBS1 SYS ONLINE
SQL> SELECT t1.name, t2.extents, t2.rssize, t2.optsize, t2.hwmsize, t2.xacts, t2.status FROM v$rollname t1, v$rollstat t2 WHERE t2.usn = t1.usn ;
NAME EXTENTS RSSIZE OPTSIZE HWMSIZE XACTS STATUS
SYSTEM 7 770048 770048 0 ONLINE
ROLLBACK02 2 41934848 262144000 41934848 0 ONLINE
ROLLBACK03 3 62906368 262144000 62906368 1 ONLINE
ROLLBACK04 3 62906368 262144000 62906368 0 ONLINE
ROLLBACK05 2 41934848 262144000 41934848 0 ONLINE
ROLLBACK06 3 62906368 262144000 62906368 1 ONLINE
ROLLBACK07 3 62906368 262144000 62906368 1 ONLINE
ROLLBACK08 3 62906368 300146688 62906368 0 ONLINE
ROLLBACK09 3 62906368 262144000 62906368 1 ONLINE
ROLLBACK10 3 62906368 262144000 62906368 1 ONLINE
ROLLBACK01 3 62906368 300146688 62906368 0 ONLINE
NAME0     USER0          RSSIZE Wraps Extents Shrinks     OPTSIZE     COMM0
ROLLBACK01          62906368     19     3     0 300146688 lookup
ROLLBACK02          41934848     0     2     0 262144000 lookup
ROLLBACK03 OPS$RTRADM     62906368     20     3     0 262144000 lookup 50
ROLLBACK04          62906368     34     3     0 262144000 lookup
ROLLBACK05 OPS$RTRADM     41934848     28     2     0 262144000 No Command
ROLLBACK06 OPS$RTRADM     62906368     21     3     0 262144000 lookup 50
ROLLBACK07 OPS$RTRADM     62906368     25     3     0 262144000 lookup 50
ROLLBACK08          62906368     32     3     0 300146688 lookup
ROLLBACK09 OPS$RTRADM     62906368     20     3     0 262144000 Select
ROLLBACK10 OPS$RTRADM     62906368     24     3     0 262144000 lookup 50
SYSTEM               770048     0     7     0     lookup
Can someone help ... who to set the RBS size here... i dont want this error happens here.. what i need to look or check.

lm**** wrote:
Hi,
Database version is Oracle8i Enterprise Edition Release 8.1.7.4.0
I am struggling to fix this error, since I have not worked on 8I DATABASE.
We getting this kind of error very frequently in one of the 8i database.
ORA-01555: snapshot too old: rollback segment number 8 with name "ROLLBACK08" too small
How do i fix this permantely. upgrade to supported Oracle version since V8.1.7 has not been supported this Century.

Request got errror as ORA-01555: snapshot too old: rollback segment number

hi Consultants,
reqeust gor errores as ORA-01555: snapshot too old: rollback segment number 50 with name "_SYSSMU50$" too small ORA-06512: at line 90
anyone please advice me on this.
Thanks,
Anu.

Thanks for ur reply
Is this a standard or custom concurrent program?This is customer program it is working fine if run as individual
Thanks,
Anu

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 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

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-1555 (SNAPSHOT TOO OLD)의 일반적인 원인 및 조치사항

Similar Messages

Maybe you are looking for