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

a 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

Similar Messages

Ora-01555 when export DB on RAC 11GR2

Hi all,
I run a full export on my 11GR2 DB and i have 6 errors on sysman tables :
ORA-31693: Table data object "SYSMAN"."MGMT_POLICY_ASSOC_EVAL_SUMM" failed to load/unload and is being skipped due to error:
ORA-02354: error in exporting/importing data
ORA-01555: snapshot too old: rollback segment number 21 with name "_SYSSMU21_2772229671$" too small
Do you have an idea ?
Thanks.

$ oerr ora 1555
01555, 00000, "snapshot too old: rollback segment number %s with name \"%s\" too small"
// *Cause: rollback records needed by a reader for consistent read are
// overwritten by other writers
// *Action: If in Automatic Undo Management mode, increase undo_retention
// setting. Otherwise, use larger rollback segmentsIf you increase undo_retention parameter you may also need to increase undo tablespace datafiles.

ORA-01555 when performing refresh of materialized views via DBMS_JOB

All,
With this project needing to be finished soon and an issue occuring on the local database, I am hopefuly one of you will have the answer or resolution so that I may complete this project soon....
Here is the setup..
10g database (remote)
9i database (local
DB Link from local to remote database
103 materialized views in local database that are refreshed by pulling data from dblink to remote database.
A PL/SQL procedure has been created which sets the v_failures variable = 0 and then performs a check to see if the current job has a failure and if so, inserts that value into the v_failures variable. When that reaches "1", then the procedure does nothing and closes out. If the failures are equal to "0" then it performs a DBMS_MVIEW.REFRESH procedure for each materialized view.
This worked the first time but its continually failing now with the ORA-01555 error (snapshot too old). From what I can tell, the dbms_job duration is 4 seconds and the Last_Exec is 2m 7s after it starts (8:30 PM). With that said, our DBAs working o nthe project have increased the Undo_Retention settings and assure us that shouldn't be the problem. Odd thing is, this never happened in the dev environment when we were developing/testing - only in the production environment once it got migrated.
I am looking for possible causes and possible solutions to the ORA-01555 error. A sample of the code in my procedure is below:
CREATE OR REPLACE PROCEDURE Ar_Mviews IS
V_FAILURES NUMBER := 0;
BEGIN
BEGIN
          SELECT FAILURES INTO V_FAILURES FROM USER_JOBS WHERE SCHEMA_USER = 'CATEBS' AND WHAT LIKE '%DISCO_MVIEWS%';
          IF V_FAILURES = 1 THEN NULL;
          ELSE
DBMS_MVIEW.REFRESH ('AR_BATCH_RECEIPTS_V', 'C');
          DBMS_OUTPUT.PUT_LINE(V_FAILURES); END IF;
END;
BEGIN
     SELECT FAILURES INTO V_FAILURES FROM USER_JOBS WHERE SCHEMA_USER = 'CATEBS' AND WHAT LIKE '%DISCO_MVIEWS%';
          IF V_FAILURES = 1 THEN NULL;
          ELSE
DBMS_MVIEW.REFRESH ('AR_BATCHES_ALL_V', 'C');
          DBMS_OUTPUT.PUT_LINE(V_FAILURES); END IF;
END;
END Ar_Mviews;
---------------------------------------------------------------------------------------------------------------

We are doing complete refreshes and doing it that way for consistency in the data presented. Because some materialized views are dependent upon data in other materialized views, we have them ordered in a procedure so that when one finishes, the next starts and they are also in a specific order as to ensure accurate data.
The condition for v_failures is done so that the job doesn't get, lets say, 90% finished and hit an error and start over again. We do the IF statement which results in NULL (do nothing) so that the job doesn't repeat itself over and over again. If one MV fails, we have to consider the job a failure and do nothing else because the one MV that failed may have been a dependency of another MV down the line. (i.e. MV7 calls MV3 and MV3 fails, so the whole job fails because MV7 can't be accurate without the most current data from MV3).
As well, this is being performed in off-business hours after backup to tape, etc. and prior to start of business so that no one is using the system when we run this job. That won't always be the case when we move to high availability with this system for varying time-zone end-users.
I hope I have answered your question and look forward to continued feedback.
Thanks!

ORA-01555?

I am trying to create an index on a huge table around(200gigs). I have 10gigs undo which is autoextensible to 50 gigs.
Earlier the undo_retention was 900, and i tried to create the index. It failed with ORA-01555.
I increased the undo_retention to 7200 but again it failed. I am running 10g with undo_management=auto
What should i do?

Libra DBA wrote:
I looked into the delayed block cleanout and ran
I am using UNDO_MANAGEMENT=AUTO and the UNDOTBS1 and UNDOTBS2 of 5 gigs with autoextend upto 50 gigs.There are servral things that could cause ORA-01555 when using Automatic Undo Management. However, there are simply things that need to be checked when using it.
First of all, one mistake we make is to use AUTO EXTEND for UNDO and TEMPORARY Segments. Please calculate/estimate and allocate the required space to UNDO and TEMP and turn off AUTO EXTEND on them.
Secondly, check your UNDO_RETENTION setting and see if it is correctly set for your longest running transactions.
Thirdly, check the application code for the DOs and DONTs to pervent ORA-01555. If you do not get all these right, 100GB will not be enough for you to complete your transactions. But if you get them right, only 20GB out of the 50GB may be sufficient for you.
I would suggest you read more on Automatic Undo Management. If you are using Enterprise Manager, Undo Advisor will help you to estimate your UNDO Space allocation.

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 Santhan

but 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

Active Data Guard and Undo and ora-01555

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

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

ORA-01555 with ORA-02063 when submitted Concurrent Requests

Hello,
My development team has reported some CM Requests got failed with some errors.When i checked the request log file i saw :java.sql.SQLException: ORA-01555: snapshot too old: rollback segment number with name "" too small ORA-02063: preceding line from EIHFDM .Could you please help me out this to solve this issue.
We are on Oracle Database 10g Release 10.2.0.5.0 - 64bit
Application 11.5.10
I have checked the UNDO Parameter values
ACTUAL UNDO SIZE (MEGS) UNDO RETENTION (Secs)                OPTIMAL UNDO RETENTION (Secs)
                                 304849                               40000                4860
Thanks,
Prabhat.

Hi Asif,
This is a customized program.
I have checked the UNDO Parameter values
SQL> show parameter undo
NAME                                 TYPE        VALUE
_in_memory_undo                 boolean     TRUE
_undo_debug_usage              integer     2
undo_management                 string      AUTO
undo_retention                       integer     40000
undo_tablespace                    string      APPS_UNDOTS
SQL>
ACTUAL UNDO SIZE (MEGS) UNDO RETENTION (Secs)                OPTIMAL UNDO RETENTION (Secs)
                                 304849                               40000                4860

ORA-01555 even though undo tablespace is with autoextend ON

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

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

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

To change manul to auto undo management in 9i

Hi
My production database on manul undo management means (RBS) . I want to change this on auto mode Please Help me what steps i follow to do this
DB 9.2 and OS AIX 5.2
Thanks

SQL> alter system set undo_management=manual scope=spfile;
System altered.
SQL> shutdown immediate;
SQL> startup
SQL> show parameter undo
NAME TYPE VALUE
undo_management string MANUAL
undo_retention integer 1800
undo_tablespace string UNDONEW
SQL>
do this same for auto....
regards

ORA-01555 error when assigning values based on geometry

Hello,
I have a table with 220,000+ records with street information, and I am trying to assign a municipal area (stored in another table) based on the geometry of the road line and the geometry of the municipal boundary.
CREATE TABLE TEMP AS SELECT A.ID, B.AREA FROM ROADS A, PLACES B WHERE B.TYPE IN (33,35,36,37) AND mdsys.sdo_relate (a.geometry,b.geometry,'
mask=inside querytype = window')='TRUE';
This took a long time to run and it came back with a series of errors, one of which was ORA--01555 'snapshot too old'. I was running other queries on the table (in a separate SQL window) because I'm under a deadline, so i figured that doing multiple things at one time while the spatial query was running was causing the problem. I didn't have time to run it again (it was the end of the day when the error came up, conveniently) so I am trying to work out a solution to this issue.
Would it be better if I: a) ran the statement again on the whole dataset and did nothing else while it is running, even though it will still take a while, or
b) broke it up into groups of 50,000 records and run the statement on one group at a time and hope for the best.
Thanks in advance!

Assuming you have less municipal areas than roads, the query should perform better by specifying the join order:
CREATE TABLE TEMP AS (
     SELECT /*+ ORDERED */ A.ID, B.AREA
     FROM PLACES B, ROADS A
     WHERE B.TYPE IN (33,35,36,37)
     AND mdsys.sdo_relate (a.geometry, b.geometry,'mask=inside querytype = window') = 'TRUE');Also, are you sure 'inside' is the right mask to use here? What if a road intersects the edge of the municipality? In that case it wouldn't be returned by this query.

How do I cancel a Newsstand subscription when there is no auto-renew facility/option through Settings? After removing the item on Newsstand it still shows as Active in Store Settings/Manage Subscriptions.

How do I cancel a Newsstand subscription when there is no auto-renew option via Settings/Manage Subscriptions? After removing the item from the Newsstand site it still shows as Active via Settings/Manage Subscriptions. The publisher tells me it is not a subscription rate that is theirs, they have no knowledge of it, I subscribed through iTunes Store. Thank you!

Hi qwerty,
Dun tink that creative customer support sucks cos I had been dealing with them in the past and I can say that their service are quite gd and fast. If you wanted a refund, I tink you need to contact the store that sells you the product. Dun tink creative will refund you though.

When will ora-01555 error not be recorded in alert file?

Application side repeatably gets ora-01555 error, but from alert log, there is no such error recorded. I recalled normally this error will be recorded, so under which condition we can't find this error in alert file?

You would get ORA-0155 on a LOB if
a) the LOB storage has been defined with PCTVERSION which is low (Oracle doesn't use Undo Segments but uses space in the LOB Segment itself and if this is inadequate for multiple updates, an ORA-0155 is raised, which is not really related to Undo Segments but the space in the LOB segment)
b) the LOB storage has been defined with RETENTION which is low
(Even if you increase undo_retention, you'd have to modify the LOB segment to PCTVERSION and then back to RETENTION for it to use the new undo_retention value).
See MetaLink Notes 162345.1, 66431.1 and 563470.1
Since the ORA-01555 error doesn't really relate to Undo segments, I believe that it would not be reported in the alert.log file -- but I haven't verified this.
Hemant K Chitale
http://hemantoracledba.blogspot.com

Flashback Query ORA-01555

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.

ORA-01555 while gathering table statistics

Hello All,
While running a job to gather table statics it failed and I saw in my alert logs ORA-01555, below is the job:
DBMS_STATS.GATHER_TABLE_STATS (SCHEMA_NAME, TABLE_NAME, PARTITION_NAME, ESTIMATE_PERCENT => DBMS_STATS.AUTO_SAMPLE_SIZE, METHOD_OPT=> 'FOR ALL COLUMNS SIZE AUTO');What is the reason behind the ORA-01555 ?
How can I prevent it in the future ?
Regards,

There are two queries,
Below query for optimal undo size based on your undo retention
select d.undo_size / (1024 * 1024) "ACTUAL UNDO SIZE (MEGS)",
substr(e.value, 1, 25) "UNDO RETENTION (Secs)",
(to_number(e.value) * to_number(f.value) * g.undo_block_per_sec) /
(1024 * 1024) "NEEDED UNDO SIZE (MEGS)"
from (select sum(a.bytes) undo_size
from v$datafile a, v$tablespace b, dba_tablespaces c
where c.contents = 'UNDO'
and c.status = 'ONLINE'
and b.name = c.tablespace_name
and a.ts# = b.ts#) d,
v$parameter e,
v$parameter f,
(select max(undoblks / ((end_time - begin_time) * 3600 * 24)) undo_block_per_sec
from v$undostat) g
where e.name = 'undo_retention'
and f.name = 'db_block_size';
Below is the result from my database;
        ACTUAL UNDO SIZE (MEGS)     UNDO RETENTION (Secs)     NEEDED UNDO SIZE (MEGS)
       20860                     900          955.6171875
Another query is based how much undo retention you have to configure as per the undo size
select d.undo_size / (1024 * 1024) "ACTUAL UNDO SIZE (MEGS)",
substr(e.value, 1, 25) "UNDO RETENTION (Secs)",
round((d.undo_size / (to_number(f.value) * g.undo_block_per_sec))) "OPTIMAL UNDO RETENTION (Secs)"
from (select sum(a.bytes) undo_size
from v$datafile a, v$tablespace b, dba_tablespaces c
where c.contents = 'UNDO'
and c.status = 'ONLINE'
and b.name = c.tablespace_name
and a.ts# = b.ts#) d,
v$parameter e,
v$parameter f,
(select max(undoblks / ((end_time - begin_time) * 3600 * 24)) undo_block_per_sec
from v$undostat) g
where e.name = 'undo_retention'
and f.name = 'db_block_size';
Below is the result from my database;
        ACTUAL UNDO SIZE (MEGS)     UNDO RETENTION (Secs)     OPTIMAL UNDO RETENTION (Secs)
     20860                           900                         19646
BTW, have you tried again by executing the same ?Yes with no problem, it only happened once
In the link you mention I read the below
"The ORA-1555 happens when people try to save space typically. They'll have small
rollback segments that could grow if they needed (and will shrink using OPTIMAL). So,
they'll start with say 10 or so 1meg rollback segments. These rollback segments COULD
grow to 100meg each if we let them (in this example) however, they will NEVER grow unless
you get a big transaction.
If your database does lots of little transactions, the RBS will never grow on their own.
They will stay small.
Now, someone needs to run a query that will take 5 minutes. On your system however the
rollback wraps every 2 minutes due to lots of little transactions going on. In this
system, ORA-1555's will happen frequently. What you need to do here is size rollback so
that it wraps less frequently (less frequently then your long running queries). Here if
I sized the rollback so that I had 10, 10meg segments (not so they could GROW to 10meg
but that they are starting at 10meg) we would wrap maybe every 20minutes now. that'll
give that 5minute query plenty of time to complete without reusing rollback it needs.
I Think this is exactly my case, how can I resize my redo segments ? and how can I check its current size?

ORA-01555 when UNDO Management is Auto

Similar Messages

Maybe you are looking for