Oracle 9i Snap shot too old error

Hello All,
We are using Oracle 9i. When I refresh M Views manually they are executing fine.
Initionally while creating M Views. I did a auto refresh for every 4 hours. After a week of sucessfull execution they error out giving snap shot too old error.
Upon my DBA request We have increased UNDO space from 500 MB to 2 GB.
And also removed AUTO refresh of M Views and created a procedure to refresh M View one after the other and scheduled to run 4 times a day.
Logic is to avoid parallel M View refresh.
However, non this helped to resolve snap shot too old error.
Now My DBA is asking increase the space by 2 more GB. I think the issue is some thing else.
Similar jobs are running perfectly in my Dev environment (DATA is almost same 10% varience) with UNDO size 500 MB.
Can you please help me here.
Thanks,
Ravi.

There are some questions,
first is about undo parameters, what is the value of undo retention and how many time execute the refresh.
second. Can you modify your undo to autoextend?
third. Who is using the undo?
This can be found in my friend Google:
http://oracledisect.blogspot.com/2008/05/who-is-using-your-undo-space.html
V$UNDOSTAT: histogram-like view that shows statistics for 10-minute intervals.
V$TRANSACTION: present time view providing information on current transactions.
V$SESSTAT: individual session statistics, which includes one for undo usage.

Similar Messages

Oracle 9i: Snap Shot too old error while refreshing MV

Hello All,
We are using Oracle 9i. When I refresh M Views manually they are executing fine.
Initionally while creating M Views. I did a auto refresh for every 4 hours. After a week of sucessfull execution they error out giving snap shot too old error.
Upon my DBA request We have increased UNDO space from 500 MB to 2 GB.
And also removed AUTO refresh of M Views and created a procedure to refresh M View one after the other and scheduled to run 4 times a day.
Logic is to avoid parallel M View refresh.
However, non this helped to resolve snap shot too old error.
Now My DBA is asking increase the space by 2 more GB. I think the issue is some thing else.
Similar jobs are running perfectly in my Dev environment (DATA is almost same 10% varience) with UNDO size 500 MB.
Can you please help me here.
Thanks,
Ravi.

There are some questions,
first is about undo parameters, what is the value of undo retention and how many time execute the refresh.
second. Can you modify your undo to autoextend?
third. Who is using the undo?
This can be found in my friend Google:
http://oracledisect.blogspot.com/2008/05/who-is-using-your-undo-space.html
V$UNDOSTAT: histogram-like view that shows statistics for 10-minute intervals.
V$TRANSACTION: present time view providing information on current transactions.
V$SESSTAT: individual session statistics, which includes one for undo usage.

How to face snap shot too old error

HI,
I'm trying to get ORA-1555(snap shot too old error) how i'm doing is
i kept my undo tablespace in retention guarantee of 15 min;
user1--> inserted rows into emp table-(1,20,200)---commited---doing update operation in loop
user2-> select *from user1.emp;
i'm implementing this type of scenario but unable to get snap shot too old error.instead it is giving ora-6512(unable to extend undotbs) .please help to get snap shot too old error
Thanks in advance

>
please help to get snap shot too old error
>
Here is an AskTom blog that shows how to do it.
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:895410916429
He linked here from the bottom of this blog where he said this
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:275215756923
>
Followup March 12, 2011 - 5pm Central time zone:
depends on the size of your rollback segments, this was written way before automatic undo management - you'll probably have to configure manual undo to see this in a controlled demo.
something like this:
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:895410916429

Snap Shot too old error And UNDO Table space.

I posted [This Question|http://forums.oracle.com/forums/thread.jspa?threadID=718704&tstart=0] in PL/SQL forum. Now thought this would be a better place.
Thanks,
Karthick.

Karthik,
Its actually not the same thing when we talk about manual Rollback Segments and Automatic Undo Segments. Besides the fact that the former is created by us and thus needs to be managed properly in the terms of the size and other things, the later one is far more performance oriented. There are couple of enhancements which are done in terms of Automatic Undo , to quote a few, Undo Stealing is one .Another is the on the fly making the undo segments offfline and while starting up the database, only the needed ones are available . This enables the fast instance startup.
Wont oracle automatically adjust the UNDO_RETENTION parameter based on the UNDO table space size.
If you have read it from Orcle docs than you must have seen this advice is correct when the release is 10.2 onwards and the tablespace is autoextensible. If the tablespace is autoextensible than from 10.2 onwards, you don't need to worry about the undo_retention period. It will be set automatically. If the tablespace is not autoextensible than Oracle would set the parameter value to the duration of the query.
For the snapshot too old error, I would suggest you read this link,
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:275215756923
There is no other document AFAIK which explains it more clearly than this one.
HTH
Aman....

Regd snap shot too old

when exporting an table x which is an clob it says
ORA-01555: snapshot too old: rollback segment number with name "" too small
but if i try after some time it gets exported correctly
exporting table x 40000 rows exported
can any one of you help me why this happens regularly ??

Check the rollback usage and space while exporting the X table.
If rollback segment is small then the rollback segment will not be able to accomodate the whole data in the rollback segment. hence it will flush out the old data to regain the space.
Let us know the Oracle version.

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.

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 during drop tablespace

Hi Experts
When we are doing BW reorg and steps followed are
1. created a newtablespace with source tablespace TABART class reference.
2. Export the source tablespace to the filesystem level.
3. DROP the source tablespace now.
4. Rename the new tablespace to source tablespace name.
5. Import
Here in the third step i have received snapshot too old error.
BR0301E SQL error -604 at location BrSqlExecute-1, SQL statement:
'/* BRSPACE */ drop tablespace PSAPADSOLD including contents and datafiles cascade constraints'
ORA-00604: error occurred at recursive SQL level 1
ORA-01555: snapshot too old: rollback segment number 0 with name "SYSTEM" too small
BR1017E Execution of SQL statement 'drop tablespace PSAPADSOLD including contents and datafiles cascade constraints' failed
so i tried to rename the tablespace and set to offline and tried to import only 240 tables were imported compared to 24057 tables.Still the PSAPADS - Source tablespace shows 65000 elements.
my queries:
1. After Export of the tablespace how come the Source tablespace retain the tables.
2. why i could not able to drop the tablespace
I had increased the UNDO_RETENTION to 86400 my oracle version is 10.2.04.
Source table space PSAPADS is 80 GB and has only 30 GB data and the remaining are free.
PSAPUNDO was 17GB in size.
Kinldy suggest
Regards
Bala

Hi Stefa
Thanks for your reply.
how to find the System undo is still active.How to track which Undo which is active and their steps.
As per the metalink note our PSAPUNDO is Locally Managed Tablepsace hence the second workaround is applicable..
How to validate this will not give a problem again while i am doing reorganization.
When i checked a sap note 1039060 this note is applicable to windows i dont how it can be impleneted.
Whether any merge fix will help on this
Regards
Bala

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.

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 1555

how to over come this problem practically

I can't speak for the original poster, of course.
But snapshot too old errors are what you get when, in order to produce the last piece of data at the finish time of some report, you have to roll the data you encounter in the buffer cache back to the state it was in at the start time.
A query which starts at 10.00am, for example, and finishes at 10.03 must see the data at 10.03 in the state it was at at 10.00am. So at the end of the query process, we have to do a '3 minute rollback'.
But if your query starts at 10.00am and doesn't finish until 10.53am, then you'd better hope 53 minutes of undo still exists in your database, because you're going to need to roll 10.53 data back to the state it was at 10.00.
The larger the time difference between the start and finish of a query, therefore, the more likely it becomes that the undo needed to generate a read consistent image won't be available, and that's when you get the 1555 signalled.
Most advice on 1555s say to increase the size of your rollback segments or your undo tablespace or increase the undo_retention time, so that the necessary undo **is** still available by the time you get to the query's finish time. But it's also a reasonable suggestion (though much harder to implement!) to tune the query so that the gap between start and finish time is much smaller than before. If a query used to take 53 minutes to complete but after tuning only takes 23 minutes to run, you've reduced the age of the undo you need available to produce the report by 30 minutes.
In other words, the common approach to 1555s is to increase the amount of undo that's available on the system. The approach being suggested here is to **reduce** the need for so much undo in the first place by reducing the length of time queries run for.

What is snapshot too old error.

Hi,
Could you please explain the snapshot too old error detail manner.
And i how can i solve the problem.
Thanks,
MuthyaM

Hi,
When a transaction occur original data will be copied to an undo segment in order to make a read consistent image for other users, as well as to make rollback possible. It works as a round robin fashion so that, old expired data in the undo segment will get replaced with new data.
If you start a query and the it was found some blocks had been changed AFTER you started the query, then query will go and check undo segment for the original data. If those original data had been overwritten, then you will get snapshot too old error.
To solve this, You can enable retention grantee option and set retention period equal to the maximum query length.
Regards,
Sajeeva.

ORA-01555: snapshot too old error

While i was trying to run the following anonymous block to analyze all the tables and indexes in my schema, it ran for approx. 5 hours and ended up with
ORA-01555: snapshot too old error
Can anybody explain me why this happened?
SQL> DECLARE
2 CURSOR tab_cur
3 IS
4 SELECT table_name
5 FROM user_tables;
6
7 CURSOR indx_cur
8 IS
9 SELECT index_name
10 FROM user_indexes;
11 BEGIN
12 FOR rec IN tab_cur
13 LOOP
14 EXECUTE IMMEDIATE 'ANALYZE TABLE '
15 || rec.table_name
16 || ' COMPUTE STATISTICS';
17 END LOOP;
18
19 FOR rec IN indx_cur
20 LOOP
21 EXECUTE IMMEDIATE 'ANALYZE INDEX '
22 || rec.index_name
23 || ' COMPUTE STATISTICS';
24 END LOOP;
25 END;
26 /
DECLARE
ERROR at line 1:
ORA-01555: snapshot too old: rollback segment number 13 with name "_SYSSMU13$"
too small
ORA-06512: at line 12
Elapsed: 05:01:26.08
Thanks and Regards
--DKar

Your cursor loop uses the database catalog.
The analyze updates the database catalog -- including some of the same tables required by the cursor loop.
The undo retention was not sufficient to hold all of the undo necessary to maintain read consistency of the catalog.
Try using something like this, instead.
-- for 9i
BEGIN
DBMS_STATS.GATHER_SCHEMA_STATS (
          ownname               => '<YOUR SCHEMA>',
          estimate_percent      => DBMS_STATS.AUTO_SAMPLE_SIZE,
          block_sample          => TRUE,
          method_opt            => 'FOR ALL COLUMNS SIZE AUTO',
          degree                => 6,
          granularity           => 'ALL',
          cascade               => TRUE,
          options               => 'GATHER'
END;

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

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.

Oracle 9i Snap shot too old error

Similar Messages

Maybe you are looking for