Undo retention and ORA-01555
Dear Experts,
Oracle 9.2.0.6 (Hp-ux 11.11).
How undo retention and snapshot too old error are related to each other ?
As per my understanding undo retention is only a request and if a transaction is running out of space, it will use space secured by undo retention.
Thanks & Regards
Sunil Kumar
user13151642 wrote:
Dear Experts,
Oracle 9.2.0.6 (Hp-ux 11.11).
How undo retention and snapshot too old error are related to each other ?
As per my understanding undo retention is only a request and if a transaction is running out of space, it will use space secured by undo retention.
Yes, that's why oracle never said in 9i, where this parameter came into existence for the first time that setting it would completely remove the ora1555 issue. If the space is not there and there are incoming transactions requiring the space for their Undo, Oracle can and will overwrite the previously stored Undo leading to the error. That's the reason, you have the Undo Retention guarantee from 10g onwards which ensures that for the time period mentioned, there won't be any overwriting of the Undo data. But, this comes with an issue as well because since now, there is no overwriting of the previosuly written Undo data. the incoming transactions would fail because they won't be able to log their Undo data anymore.
Aman....
Similar Messages
-
Difference between Delayed block clean out and ora-01555
Hi all,
After going through lot of books, blogs etc , had a doubt regarding delayed block clean out and ora-01555
1) How does oracle know that it has to perform a delayed block clean and when it has to throw the ora-01555 error as both seems to be doing the same activity.
Regrads
IDYou find an example of how an ORA-01555 is caused by delayed block cleanout in Tom Kyte's "Oracle Database Architecture", Chapter 9 starting at page 340.
You can 'see' cleanout happening in that you notice that a simple SELECT may generate REDO as in the following scenario which involves 2 sessions:
-- SESSION A, PREPARE THE TEST TABLE
create table cleanout_test as (select object_id, rpad(object_name, 200, 'x') txt from dba_objects);
-- SESSION B, DO A FIRST SELECT (JUST FOR INITIALIZATION, WARMUP, BECAUSE SOMETIMES A FIRST ACTION IS A SPECIAL CASE)
> select * from cleanout_test where object_id = -33;
no rows selected
-- SESSION B, REPEATE THE SAME SELECT AGAINST THE TEST TABLE, USE AUTOTRACE TO MEASURE THE REDO THAT IS GENERATED (0)
> set autotrace on statistics;
> select * from cleanout_test where object_id = -33;
no rows selected
Statistics
0 recursive calls
0 db block gets
11786 consistent gets
11768 physical reads
0 redo size
308 bytes sent via SQL*Net to client
465 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
0 rows processed
-- SESSION A, UPDATE THE TEST TABLE (THIS LEAVES SOME CLEANOUT WORK FOR THE NEXT SESSION ACCESSING THE TEST TABLE'S DATA BLOCKS)
update cleanout_test set object_id = object_id+1;
commit;
-- SESSION B, REPEATE THE SELECT AGAINST THE TEST TABLE, NOTICE THE AMOUNT OF REDO GENERATED BY THE SELECT - THIS STEMS FROM CLEANING UP THE DATA BLOCKS AFTER SESSION A
> select * from cleanout_test where object_id = -33;
no rows selected
Statistics
0 recursive calls
0 db block gets
18714 consistent gets
53 physical reads
494892 redo size
308 bytes sent via SQL*Net to client
465 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
0 rows processed
-- SESSION B, REPEATE THE SELECT AGAINST THE TEST TABLE, NOTICE THAT NO MORE REDO IS GENERATED, BECAUSE THE CLEANOUT HAS BEEN DONE.
> select * from cleanout_test where object_id = -33;
no rows selected
Statistics
0 recursive calls
0 db block gets
11846 consistent gets
0 physical reads
0 redo size
308 bytes sent via SQL*Net to client
465 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
0 rows processed -
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 -
Expdp fails with ORA-31693, ORA-02354 and ORA-01555
Hi,
Oracle Database 10.2.0.4.0, Windows Server 2003
I was doing a full database DATA PUMP export as follow:
expdp system/pass@SID FULL=y DIRECTORY=MY_EXPORT DUMPFILE=EXPORT_DB.dmp logfile=EXPORT_DB.log
It always worked fine but today I received an error message :
ORA-31693: Table data object "S"."TABL1" failed to load/unload and is being skipped due to error:
ORA-02354: error in exporting/importing data
ORA-01555: snapshot too old: rollback segment number 10 with name "_SYSSMU10$" too small
The undo_retention parameter is set to its default of 900 currently.
Datafile in UNDO tablespace is 5GB used and this datafile is autoextend up to 32GB.
Any idea of what may causes this error ?
Thanks!This happens only with the two largest tables which are around 11GB.
Today I do several times export, but always with one error.
First time error with one table, second time with another table... Everything else is exported without errors. -
Undo retention and tablespace size
Situation:
Oracle 9.2.0.1 configured with undo_retention=10800 but with a 2GB size limit for the
undo tablespace with no autoextend.
As far as i know, with 10800 the undo tablespace could grown to around 10GB
but i'm not sure tho. I REALLY need to know if this is clearly a wrong setup (imho it
is) or could be an acceptable situation in some scenarios.
Thanks heap in advance.Oracle 9.2.0.1 configured with undo_retention=108003 Hours? This is realy huge undo retention time.
with a 2GB size limit for the undo tablespace with no autoextend.You probably mean datafile not tablespace.
You don't need resize existing datafile you could just add another datafile to undo tablespace. -
UNDO retention causing excessive I/O ?
New DBA here.
Quick Summary:
We have an oracle 10gR2 DB on AIX 5.3. OS runs from the box, Database runs from a san. Aside from the DB, there is a web based application running on the box, which uses the DB.
System is dedicated to this application.
We have a consulting company that is making suggestions, and I am not sure about some of them.
When we set up the software, the vendor told us to set up the database with undo retention to 10800. So we did.
Our consulting group is telling me that Undo I/O represents 34% of the total database I/O, and that I should reduce the retention time to 1080. *(they also tell me that the longest running query is 100s; I don't quite understand how this is relevent).
Why would reducing the UNDO retention lenght reduce the UNDO I/O ?First you need to check the concept of UNDO, the main purpose of undo are:
Rollback an active transaction
Recover a terminated transaction
Provide read consistency
Recovery from logical corruptions
http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/logical.htm#sthref449
also check undo retention,
The undo retention period indicates the amount of time that must pass before old undo information—that is, undo information for committed transactions—can be overwritten.
As you can see, there's no direct relationship between undo retention and database I/O. Reduce undo retention will not reduce database I/O.
Besides, the UNDO_RETENTION initialization parameter is ignored unless retention guarantee is enabled.
*(they also tell me that the longest running query is 100s; I don't quite
understand how this is relevent).The relevant here is your undo retention should be longer than longest running query (and undo space is big enough to hold the undo data of longest query) , so that you don't have out-of-space conditions in the undo tablespace and ORA-1555 error for consistent reading.
However again, it's relevant to undo setting not database IO. -
ORA-01555 when UNDO Management is Auto
Hi,
I am using Oracle 10g 10.2.0.3 on linux 64 bit
My UNDO_MANAGEMENT is AUTO and Tablespace size is Auto
Undo_retention=15
Today morning, I have received following error in Alert log
ORA-01555 caused by SQL statement below (SQL ID: 9yfaam0vn51b5, Query Duration=1257324485 sec, SCN: 0x0000.084ad6ea):
EM is showing following
Snapshot Too Old Error detected: SQL ID 9yfaam0vn51b5, Snapshot SCN 0x0000.084ad6ea, Recent SCN 0x0000.084e39df, Undo Tablespace UNDOTBS1, Current Undo Retention 943.
How dio i find that which query created a problem as SQL ID: 9yfaam0vn51b5 is not in table v$sql
Do i need to do anything or Oracle will take care of UNDO?
Regardsa mock up
SQL> select max(maxquerylen)
2 from v$undostat;
MAX(MAXQUERYLEN)
62057
SQL> show parameter undo
NAME TYPE VALUE
undo_management string AUTO
undo_retention integer 25000
undo_tablespace string UNDOTBS1
SQL> select (62057/60)/60 query,(25000/60)/60 retention
2 from dual
3 /
QUERY RETENTION
17.2380556 6.94444444Above query executing tenure is 17 hours while undo retention is approximate 7 hours,either change retention period to 20% extra with yours query execution tenure and then check yours query again.
at least set undo retention to 75000,also better approach to tune query why its too taking so much time?
Khurram -
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 even after proper undo settings
Hi All,
OS : Linux
Oracle : 10.2.0.3.0
Last few weeks i am keep on facing 01555 error for some queries.
Please see my undo settings below
SQL> show parameter undo
NAME TYPE VALUE
undo_management string AUTO
undo_retention integer 1200
undo_tablespace string UNDOTBS1###############################################
SQL> declare
retention number ;
undo_ts_size number ;
begin
retention := DBMS_UNDO_ADV.REQUIRED_RETENTION ;
undo_ts_size := DBMS_UNDO_ADV.REQUIRED_UNDO_SIZE(retention) ;
dbms_output.put_line('Current retention ' || retention );
dbms_output.put_line('Required tablespace size is ' || undo_ts_size);
end ;
Current retention 1100903
Required tablespace size is 198527
PL/SQL procedure successfully completed.####################################################
Tablespace Name Ext. Mgt. Seg. Mgt. Tablespace Size (in MB) Used (in MB) Free (in MB) Pct. Used
UNDOTBS1 LOCAL MANUAL 16,500 *1,708* 14,792 10###############################################################################
As its an oracle 10.2.0 version, i read that oracle will adjust retention period based on the long running quries & undo advisor is giving recommondation to set tablespace size to 198 G but i cannot understand why my undo tablespace is only 10% used when i am getting ora 01555 error ? mence there is no problem with retention as well as space then where is the problem ?
Also i checked if there is any stealing/reuse is happening but this below query returns 0
select UNXPSTEALCNT,UNXPBLKREUCNT from V$UNDOSTAT;
0 0
0 0
576 rows selected.
SQL>#########################################################
Could you please help me to identify the problem which i am facing ?
Thanks
Nisanth Santhanbut as per the below document, in 10.2 onwards even if we set undo retention, oracle will automatically adjust the retention based on the long running query . It seems we can even set 0 for undo retention. I have checked, my current auto undo retention setting is (1100822 sec).
http://www.oracle.com/technology/products/manageability/database/pdf/ow04/1241_minhas_pres.pdf -
<p>
Hi,
My application was getting ORA-01555 (this is confirmed in alert.log).
When I query <strong>v$undostat </strong>for the involved period:
</p>
<blockquote>
<p>
select UnxpStealCnt, UnxpBlkRelCnt, UnxpBlkReuCnt, ExpStealCnt, ExpBlkRelCnt, ExpBlkReuCnt, NoSpaceErrCnt
from v$undostat where SSoldErrCnt != 0
</p>
</blockquote>
<p>
I do not understand why all theses columns have a zero value.
I was expecting to have at least 1 in ExpBlkReuCnt or in ExpStealCnt.
How is it possible to have (because I have) ORA-01555 without any value in thoses columns ?
Thanks for your bright explanations,
Leo.
</p>
Edited by: Leo Anderson on 24 oct. 2008 10:28Leo Anderson wrote:
During the "fatal" period, the MaxQueryLen = 6000 and the Tuned_UndoRetention = 6800
All columns UnxpStealCnt, UnxpBlkRelCnt, UnxpBlkReuCnt, ExpStealCnt, ExpBlkRelCnt, ExpBlkReuCnt, NoSpaceErrCnt has zero value
So, I presume increasing undo_retention parameter will have no effect ?
But why no columns has non-zero value ? (in particular ExpBlkReuCnt)
EDIT : The datafile underlying my UNDOTBS is autoextensible, and bytes/maxbytes is about 32% so it could still grow
In this case I would assume that you might suffer from an ORA-01555 due to "delayed block cleanout". This errors occurs if delayed block cleanout is being performed, the transaction slot has been overwritten and some other conditions apply. For a very good explanation under what circumstances this could happen, read MetaLink note 45895.1 (although the note applies to manual rollback segment management the explanation of the "delayed block cleanout" case still applies to automatic undo management, but the solutions mentioned there do not)
You can check if your query generates a lot of redo (and you can make sure that this redo is not generated by some other DML of the same session) then it performs "delayed block cleanout".
The best solution to prevent this from happening is to attempt to generate "clean" blocks right from the start, e.g. by using direct-path inserts (APPEND hint) or Create Table As Select (CTAS). This way you prevent the "delayed block cleanout" from happening.
Other means are performing full table scans on the modified object, e.g. by gathering statistics using DBMS_STATS or explicitly running a query on the object using a full table scan right after large modifications.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/ -
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
Thanks912294 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? -
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.
ThanksJamie 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. -
Gurus,
I'm receiving an ora-01555 error when attempting to run a flashback query. How can I get this resolve as I need to recover records that were deleted!
SQL> show parameter undo
NAME TYPE
VALUE
undo_management string
AUTO
undo_retention integer
604800
undo_tablespace string
UNDOTBS1
Undo Tablespace is 6GB!
select count(*) from bld as of timestamp (sysdate-5);
ORA-01555: snapshot too old: rollback segment number 19 with name "_SYSSMU19_1281712960$" too small
01555. 00000 - "snapshot too old: rollback segment number %s with name \"%s\" too small"
*Cause: rollback records needed by a reader for consistent read are
overwritten by other writers
*Action: If in Automatic Undo Management mode, increase undo_retention
setting. Otherwise, use larger rollback segments
All help is greatly appreciated.Based on what you have posted you are toast. The data you are trying to read is no longer in the undo tablespace and therefore is unavailable to you.
Why you might ask? I suspect you would find great value in reading the most current issue of Oracle magazine: Especially Tom Kyte's article where he specifically addresses this issue.
SQL> select 604800/86400 from dual;
604800/86400
7Your undo retention exceeds 5 days ... thus all you have accomplished is to waste disk space. -
Help to produce an ora-01555 error.
Hello all,
I've been gotten wind of about UNDO management, but I'm not able to reproduce an ora-01555. I tried one way that I found in some metalink notes but I didn't succeed. I know that using some PL/SQL statements I get there, but how can I achieve it?
I appreciate your help.
Thanks in advance,
Regards,
EmersonEasy to reproduce. Just use flashback query to an SCN that has aged out of undo.
E.g
SQL> select object_id from test as of scn 5936742 where object_id = 20;
select object_id from test as of scn 5936742 where object_id = 20
ERROR at line 1:
ORA-01555: snapshot too old: rollback segment number 6 with name
"_SYSSMU6_2443381498$" too smallAnother option is to reduce undo retention, shrink the undo tablespace and turn off autoextend. Then in one session run a long select, and in another session run a loop with an update and a commit.
E.g
begin
for i in 1..10000 loop
update test set object_id = object_id where object_id = 20;
commit;
end loop;
end;
/
Maybe you are looking for
-
File no longer shows icon in icon view
Instead of showing the cover of a music track for example, I now get this generic icon: Does anyone know why this has happened and what I can do about it?
-
I downloaded the new Pages, Keynote, and Numbers, but they're horrible so I deleted them. Now they keep trying to update my old iWorks. I don't want them they are horrible!!! It is automatically updating (I don't have it set to automatic update),
-
White box effect in documents with transparency
how do i get rid of the white box effect when placing images from photoshop whith transparent backgrounds?
-
Hi, I had few queries regarding Sales scheduling agreement. I have gone though few forum discussions and also SAP help documentation however was not able to have clear understanding and have below queries. 1. I understand that purpose of sales schedu
-
IPhone 4 & 4S MAPS iOS6 Dutch Europe voice instructions ?
Voice instructions are available on the iPhone 4S but not with iPhone 4. I tested it on diffrented model 4S and 4. Why ? How can I fix it ? Is it a bug ?