Snapshot too old

I have written a procedure that populates a temp table which does a commit on every thousand rows. Now, this job has been running for 3 yrs now. Unfortunately though, lately, i have been getting the following error:
Declare
ERROR at line 1:
ORA-01555: snapshot too old: rollback segment number with name "" too small
ORA-06512: at line 189This program have been tuned through out those years, like doing a commit on every n thousand of rows, putting hints and some other things as suggested by our dba. It is also understood that new jobs.. big jobs.. have been created that runs a long side this process.
Now, my questions is, if i am doing a select on this table for example member_history table in a cursor then doing an insert. Then another job which is running at the same time as my job is doing a
INSERT /*+ append */ INTO temp_table (column1, column2, column3)
select column1, column2, column3
from member_history@dbprod.
where ... Would this have caused the problem? We are talking about number of rows 64,033,608 on this history table.
I would very much appreciate all your help!
Thanks,
Marilyn

Well, the primary reason for this error in my experience is fetching across commits. Which sounds exactly what your code is doing.
Thus for 3 years the code has been wrong. Violating ANSI SQL standards that say you are not allowed to fetch across commits. You were simply lucky that the rollbacks/undo did not wrap as there were little or no other transactions running at the same time.
Do not commit every n number of rows. Oracle is not SQL-Server or Ingres. It works very different ito concurrency as it has no lock manager and there are no locking overheads.
Refer to Metalink Note ORA-01555 "Snapshot too old" - Detailed Explanation, note id 40689.1.
Also refer to asktom.oracle.com on this:
http://asktom.oracle.com/pls/ask/f?p=4950:8:9219002089752914987::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:275215756923

Similar Messages

Snapshot too old error occured, kindly need solution for it...

Dar friends
I got snapshot too old error on most used database
Kindly give me the solution....
my solution was
Alter rollback segment <rollback segmnt name>
datafile '<path>/filename.dbf' resize <no>k;
or
alter rollback segment <rollback segmnt name>
add datafile '<path>/filename.dbf' size <no>k
storage(initial 1k nxt 1k minextnts 2 maxextents unlimited)
Kindly suggest me wheather my code is currect or not...
Ur
Friend

I don't know what version of the database you are running? I'm only using 8.1.7.4. But where I come from, you add datafiles to the tablespace, not the rollback segment.
alter tablespace rollback
add datafile '<blah, blah>'
size 147m
autoextend on next 100m maxsize 2047m;
Make sure that you have a suitable number of rollback segments that are well-sized extents. But mostly, listen the Tom Best, and try and introduce some best practices (no pun intended) to reduce the likelihood of this situation arising.

Snapshot too old when deleting from a "big" table

Hello.
I think this is a basic thing (release 8.1.7.4). I must say I don't know how rollback segments really work.
A table, where new records are continuously inserted and the old ones can be updated in short transactions, should be purged every day by deleting old records.
This purge has never been done and as a result it has now almost 4 million records, and when I launch the stored procedure that deletes the old records I get the "snapshot too old" error because of the read consistency.
If I launch the procedure after stopping the application that inserts and updates in the table, then I don't get the error. I guess the problem is that meanwhile the procedure is being executed other transactions also need to use rollback segments so that the rollback segment space that the snapshot needs isn't enough. Do you think this is the problem?
If this is the case then I suppose that the only solution is increasing the size of the only datafile of the only tablespace for my 4 rollback segments. Am I wrong?
(Three more questions:
- Could the problem be solved by locking some rollback segments for the snapshot? How could I do that?
- What is a discrete transaction?
I'm a developer, not a dba, but don't tell me to ask my dba because it isn't that easy. Thanks in advance.

"snapshot too old indicates the undo tablespace does not have enough free space for a long running query" what does this mean? why do I get the same error in two different databases, in the first the size of the datafile of the undo tablespace is 2GB whilst in the second it is only 2MB? How can I know how big the datafile has to be?
One possible solution could be not deleting the whole table at once but only a few records? Would this work? Why when I try "select count(*) from my_table where rownum = 1" I also get "snapshot too old" when other transactions are running.

Export with consistent=y raise snapshot too old error.

Hi,
Oracle version:9204
It raises
EXP-00056: ORACLE error 1555 encountered
ORA-01555: snapshot too old: rollback segment number 2 with name
"_SYSSMU2$" too small
when I do an export with consistent=y option.
And I find below information in alert_orcl.log
Wed Apr 20 07:50:01 2005
SELECT /*NESTED_TABLE_GET_REFS*/ "XXX"."TABLENAME".* FROM
"XXX"."TABLENAME"
ORA-01555 caused by SQL statement below (Query Duration=1140060307
sec, SCN: 0x0000.00442609):
The undo parameters:
undo_retention=10800(default value)
undo_retention is larger than the seconds run export(only 1800
seconds),so I think the default value is enough.
undo_management=auto(default value)
Maybe the rollback tablespace is too small(about 300M)? But I think oracle should increase the size of datafile in this mode.Is that right?
undo_tablespace=undotbs1
undo_suppress_errors=false
I think I must miss something.
Any suggestions will be very appreciated.
Thanks.
wy

UNDO_RETENTION is a request, not a mandate. If your UNDO tablespace is too small, Oracle may have to discard UNDO segments before UNDO_RETENTION is reached.
How much UNDO is your database generating every second?
SELECT stat.undoblks * param.value / 1024 / 1024 / 10 / 60 undo_mb_per_sec
FROM v$undostat stat,
v$parameter param
WHERE param.name = 'db_block_size'Justin
Distributed Database Consulting, Inc.
http://www.ddbcinc.com/askDDBC

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

Snapshot too old error

Hi All,
need suggestions for tuning a query failing with the error "Rollback segment too small; snapshot too old”. The query is taking a long time to run.

Here is the Explain plan (if you can understand !!!). Unable to generate the tkprof as the query is taking exceptionally long time.
EXECUTION_PLAN
0 SELECT STATEMENT Cost = 18675
1 NESTED LOOPS Cost = 1
100 TABLE ACCESS BY INDEX ROWID MTL_SYSTEM_ITEMS_B Cost = 2
101 INDEX UNIQUE SCAN MTL_SYSTEM_ITEMS_B_U1 UNIQUE
2 NESTED LOOPS Cost = 1
98 TABLE ACCESS BY INDEX ROWID WSH_NEW_DELIVERIES Cost = 2
99 INDEX UNIQUE SCAN WSH_NEW_DELIVERIES_U1 UNIQUE
3 NESTED LOOPS Cost = 1
96 TABLE ACCESS BY INDEX ROWID WSH_DELIVERY_ASSIGNMENTS Cost = 2
97 INDEX RANGE SCAN WSH_DELIVERY_ASSIGNMENTS_N3 NON-UNIQUE
4 NESTED LOOPS Cost = 1
94 TABLE ACCESS BY INDEX ROWID WSH_DELIVERY_DETAILS Cost = 2
95 INDEX RANGE SCAN WSH_DELIVERY_DETAILS_N3 NON-UNIQUE
5 NESTED LOOPS Cost = 1
92 TABLE ACCESS BY INDEX ROWID HZ_PARTIES Cost = 2
93 INDEX UNIQUE SCAN HZ_PARTIES_U1 UNIQUE
6 NESTED LOOPS Cost = 1
7 NESTED LOOPS Cost = 1
8 NESTED LOOPS Cost = 1
9 NESTED LOOPS Cost = 1
10 NESTED LOOPS Cost = 1
EXECUTION_PLAN
11 NESTED LOOPS Cost = 1
12 NESTED LOOPS Cost = 1
13 NESTED LOOPS Cost = 1
14 NESTED LOOPS Cost = 1
15 NESTED LOOPS Cost = 1
16 NESTED LOOPS Cost = 1
17 NESTED LOOPS Cost = 1
18 NESTED LOOPS Cost = 1
19 NESTED LOOPS Cost = 1
20 NESTED LOOPS Cost = 1
21 NESTED LOOPS Cost = 1
22 NESTED LOOPS Cost = 1
23 HASH JOIN Cost = 1
24 TABLE ACCESS BY INDEX ROWID OE_ORDER_HEADERS_ALL Cost = 1
25 NESTED LOOPS Cost = 1
26 NESTED LOOPS Cost = 1
27 NESTED LOOPS Cost = 1
28 HASH JOIN Cost = 1
29 TABLE ACCESS BY INDEX ROWID HR_ORGANIZATION_INFORMATION Cost = 1
30 INDEX RANGE SCAN HR_ORGANIZATION_INFORMATIO_IX1 NON-UNIQUE Cost = 1
31 NESTED LOOPS Cost = 2
EXECUTION_PLAN
32 NESTED LOOPS Cost = 1
33 NESTED LOOPS Cost = 1
34 NESTED LOOPS Cost = 1
35 NESTED LOOPS Cost = 1
36 NESTED LOOPS Cost = 1
37 NESTED LOOPS Cost = 1
38 NESTED LOOPS Cost = 1
39 TABLE ACCESS BY INDEX ROWID FND_FLEX_VALUE_SETS Cost = 1
40 INDEX UNIQUE SCAN FND_FLEX_VALUE_SETS_U2 UNIQUE Cost = 1
41 TABLE ACCESS BY INDEX ROWID FND_FLEX_VALUE_SETS Cost = 2
42 INDEX UNIQUE SCAN FND_FLEX_VALUE_SETS_U2 UNIQUE
43 TABLE ACCESS BY INDEX ROWID FND_FLEX_VALUES Cost = 2
44 INDEX RANGE SCAN FND_FLEX_VALUES_N3 NON-UNIQUE
45 TABLE ACCESS BY USER ROWID FND_FLEX_VALUES Cost = 2
46 TABLE ACCESS BY INDEX ROWID HZ_LOCATIONS Cost = 2
47 INDEX RANGE SCAN HZ_LOCATIONS_N5 NON-UNIQUE Cost = 1
48 TABLE ACCESS BY INDEX ROWID HZ_PARTY_SITES Cost = 2
49 INDEX RANGE SCAN HZ_PARTY_SITES_N2 NON-UNIQUE
50 TABLE ACCESS BY INDEX ROWID HZ_CUST_ACCT_SITES_ALL Cost = 2
51 INDEX RANGE SCAN HZ_CUST_ACCT_SITES_N1 NON-UNIQUE
52 TABLE ACCESS BY INDEX ROWID HZ_CUST_SITE_USES_ALL Cost = 2
EXECUTION_PLAN
53 INDEX RANGE SCAN HZ_CUST_SITE_USES_N1 NON-UNIQUE Cost = 1
54 INDEX UNIQUE SCAN HR_ORGANIZATION_UNITS_PK UNIQUE
55 TABLE ACCESS BY INDEX ROWID HR_ORGANIZATION_INFORMATION Cost = 2
56 INDEX RANGE SCAN HR_ORGANIZATION_INFORMATIO_FK2 NON-UNIQUE
57 INDEX UNIQUE SCAN HR_ALL_ORGANIZATION_UNTS_TL_PK UNIQUE
58 INDEX RANGE SCAN OE_ORDER_HEADERS_N4 NON-UNIQUE
59 TABLE ACCESS FULL FND_FLEX_VALUES Cost = 2
60 TABLE ACCESS BY INDEX ROWID FND_FLEX_VALUES Cost = 2
61 INDEX RANGE SCAN FND_FLEX_VALUES_N3 NON-UNIQUE
62 TABLE ACCESS BY INDEX ROWID OE_ORDER_LINES_ALL Cost = 2
63 INDEX RANGE SCAN OE_ORDER_LINES_N1 NON-UNIQUE
64 TABLE ACCESS BY INDEX ROWID MTL_PARAMETERS Cost = 2
65 INDEX UNIQUE SCAN MTL_PARAMETERS_U1 UNIQUE
66 TABLE ACCESS BY INDEX ROWID OE_ORDER_LINES_ALL Cost = 2
67 INDEX RANGE SCAN XXCTS_OE_OE_ORDER_LINES_ALL_N3 NON-UNIQUE
68 TABLE ACCESS BY INDEX ROWID OE_TRANSACTION_TYPES_TL Cost = 2
69 INDEX RANGE SCAN OE_TRANSACTION_TYPES_TL_U1 UNIQUE Cost = 1
70 TABLE ACCESS BY INDEX ROWID HZ_CUST_SITE_USES_ALL Cost = 2
71 INDEX UNIQUE SCAN HZ_CUST_SITE_USES_U1 UNIQUE
72 INDEX UNIQUE SCAN HR_ORGANIZATION_UNITS_PK UNIQUE
73 TABLE ACCESS BY INDEX ROWID HR_ORGANIZATION_INFORMATION Cost = 2
EXECUTION_PLAN
74 INDEX RANGE SCAN HR_ORGANIZATION_INFORMATIO_FK2 NON-UNIQUE
75 TABLE ACCESS BY INDEX ROWID HR_ORGANIZATION_INFORMATION Cost = 2
76 INDEX RANGE SCAN HR_ORGANIZATION_INFORMATIO_FK2 NON-UNIQUE
77 INDEX UNIQUE SCAN HR_ALL_ORGANIZATION_UNTS_TL_PK UNIQUE
78 TABLE ACCESS BY INDEX ROWID HZ_CUST_ACCT_SITES_ALL Cost = 2
79 INDEX UNIQUE SCAN HZ_CUST_ACCT_SITES_U1 UNIQUE
80 TABLE ACCESS BY INDEX ROWID XXCTS_OE_ORDER_HEADERS_ALL Cost = 2
81 INDEX UNIQUE SCAN XXCTS_OE_ORDER_HEADERS_ALL_U1 UNIQUE
82 TABLE ACCESS BY INDEX ROWID HZ_PARTY_SITES Cost = 2
83 INDEX UNIQUE SCAN HZ_PARTY_SITES_U1 UNIQUE
84 TABLE ACCESS BY INDEX ROWID HZ_LOCATIONS Cost = 2
85 INDEX UNIQUE SCAN HZ_LOCATIONS_U1 UNIQUE
86 TABLE ACCESS BY INDEX ROWID HZ_CUST_ACCOUNTS Cost = 2
87 INDEX UNIQUE SCAN HZ_CUST_ACCOUNTS_U1 UNIQUE
88 TABLE ACCESS BY INDEX ROWID HZ_PARTIES Cost = 2
89 INDEX UNIQUE SCAN HZ_PARTIES_U1 UNIQUE
90 TABLE ACCESS BY INDEX ROWID HZ_CUST_ACCOUNTS Cost = 2
91 INDEX UNIQUE SCAN HZ_CUST_ACCOUNTS_U1 UNIQUE
102 rows selected.

Advanced Queues Snapshot too old error

I am using the advanced queues to submit work for parallel processes running through the Oracle Job Queue.
I have attempted running anywhere from 1 to 5 simultaneous processes (in addition the the process which submits them to the Oracle job queue and populates the advanced queues) and I am getting sporadic Snapshot too old errors when the other processes are attempting to dequeue. The Advanced queues are populated before the other processes are submitted to the job queue, so I don't see that there could be conflicts between one process enqueuing while another is dequeuing.
The reason I am attempting this is to try and gain some performance by running processes in parallel.
Has anyone else had problems like this? Is this a bug in Oracle 8.1.6? Is there a parameter setting I need to adjust? Are there any suggestions for getting around this problem?

I don't know what version of the database you are running? I'm only using 8.1.7.4. But where I come from, you add datafiles to the tablespace, not the rollback segment.
alter tablespace rollback
add datafile '<blah, blah>'
size 147m
autoextend on next 100m maxsize 2047m;
Make sure that you have a suitable number of rollback segments that are well-sized extents. But mostly, listen the Tom Best, and try and introduce some best practices (no pun intended) to reduce the likelihood of this situation arising.

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

Snapshot too old error - disambiguation required.

[http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:275215756923]
It is known that Oracle provides row-level locks, meaning, two different transactions can update two different rows,
1. Is this true even if they reside in the same block?
2. If yes, as per the reasons stated in the above reference, Oracle should not find that the block has been modified for that particular, different, row. I am baffled at this point.
Resue needed.
Thanks in adv.
Aswani V.

if your concern is abou snapshoot too old (ora-01555) error, you know the reason for this undo tablespace size and the length of the longest running query. If you need to be able to get consistent read version of the block, which is needed for your long running query(which raises snapshot too old error), you have two options. 1) you can increase the size of your undo tablespace and find the optimum size considering your pick workload and longest running query. I mean your undo tablespace size should be enough to hold the undo data generated during the peak workload and provide read consistent version of the block for your longest running query. Again, it does not guarantees snapshot tooo old error could not happen. 2) in the second choise, you can change your undo tablespaces for guaranteed retention. In this case, despite the time of running of your longest query, you will not get snapshot too old errors. But, it measn that, during the heavy workload period, you can get errors with transactions which involve DML operations, if they could not find enough space for UNDO. So, i would increase the size of Undo tablespace and measure if it is ok or not. Oracle itself smartly choses which undo data is gonna be overwritten, even in the case of noguarantee undo tablespace. I.e. it will not overwrite the read consistent versions of undo blocks if there is some free(or expired) undo blocks.

Snapshot too Old Error - Help needed

One of the batch job is failing due to oracle error “snapshot too old.”
Please let me know what are the possible reason’s this problem occurs and suggest me the possible solutions to rectify this problem.
Thanks in advance

> this can mean different things:
1. your rollback / undo is too small for this
transaction,
Incorrect. A snapshot too old means that a consistent read cannot be maintained. A read is not a transaction - it does not cause any locks on rows.
What is can mean that rollback is too small to maintain a consistent read for a sufficiently long enough period for the consistent read to be completed.
> 2. commits aren't made often enough,
NOT TRUE!! Not in Oracle. (sorry for the emphatic bold, but this an OWT within Oracle - it is very far from the truth in Oracle and Oracle is not SQL-Server)
> 3. there are concurrent transactions which act on the
same tables.
This is usually the case - more accurately, fetching across commits. This is caused by creating a consistent read on a table (opening a cursor in PL/SQL), reading the rows (fetching from cursor in PL/SQL) and then updating those exact same rows.
The consistent read deals with version n of the table. At the same time the exact same process updates those very same rows creating new versions of those rows.
Rollbacks are overwritten (it is a circular buffer) and the version n of the rows cannot be maintained and "goes out of scope" as the rollbacks containing that version of the rows are re-used.

Avoiding Snapshot too Old

What is the best way to avoid Snapshot too old error without the need to increase the rollback segment.
If I am using a cursor to fetch data in a PL/SQL procedure to update the same table, what should be the coding to avoid the snapshot too old error?

Dear
What is the best way to avoid Snapshot too old error without the need to increase the rollback segment.
If I am using a cursor to fetch data in a PL/SQL procedure to update the same table, what should be the coding to avoid the snapshot too old error?I suggest you to do two things
(a) enhance your query (or your update) using direct SQL instead of procedural PL/SQL code
(b) if you still want to use a cursor and fetch within a PL/SQL stored procedure then
(1) avoid to commit inside the loop (avoid commit across fetch)
(2) try to accomplish your PL/SQL work when there is less activity into your database if possible
Best Regards
Mohamed Houri

ORA01555"snapshot too old:rollback segment num %s with name "%s" to small

Hi All
i have and 11gR1(11.1.0.6) DB source instance in wich i have i a partitioned table of 1TB size.
I want to IMPDP this table using NETWORK_LINK in a 11gR2(11.2.0.3) destination RAC instance.
when a try to import a get the following error message
ORA 01555 "snapshot too old: rollback segment number %s with name \"%s\" too small"
UNDO_RETENTION=130000
UNDOTBS1=300GB
UNDOTBS2=220GB
i have searche dhte metalink docs but did not find any solution.
is there any hint or document to follow?
thanks in advance
Soni

Hi,
Stopping the loading may work - it there is no other activity going on then you should be OK.
If you want to guarantee the undo doesn't get overwritten for the length of the export you can run switch on guarantee undo retention for the undo tablespace - by default it is just a target not a guarantee - see this link for more details:
http://www.oracle-base.com/articles/10g/space-object-transaction-management-10g.php
Regards,
Harry

Snapshot too old

Similar Messages

Maybe you are looking for