ORA-01555 and v$undostat

Hi,
My application was getting ORA-01555 (this is confirmed in alert.log).
When I query v$undostat for the involved period:

<blockquote>

select UnxpStealCnt, UnxpBlkRelCnt, UnxpBlkReuCnt, ExpStealCnt, ExpBlkRelCnt, ExpBlkReuCnt, NoSpaceErrCnt
from v$undostat where SSoldErrCnt != 0

</blockquote>

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.

Edited by: Leo Anderson on 24 oct. 2008 10:28

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

Similar Messages

ORA-01555: snapshot too old: rollback segment number 6 with name "R05" too

Can someone please help me how to overcome this dreaded ORA-01555 and how to know what exactly is causing this. There can be number of reasons this can occur :
1. Fewer and smaller rollback segments for a very actively changing database
2. Corrupted rollback segment
3. Fetch across commit
4. Fetch across commits with delayed block clean out
Thanks

http://asktom.oracle.com/pls/ask/f?p=4950:8:802460143396322798::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:275215756923
<quote source="asktom">
the only CAUSE of a 1555 is improperly sized rollback segments.
</quote>
http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:275215756923#10100046218454
Message was edited by:
Kamal Kishore

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.

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

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
ID

You 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

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

I found one ora-01555 error in alert log at 14:37PM.But when i run the following query
select ssolderrcnt from v$undostat where to_char(begin_time,'hh:mi:ss')='14:00:00' and to_char(end_time,'hh:mi:ss')='15:00:00'
no rows selected is getting
It has to show 1 as ora-01555 occured at 14:37pm.
Whats wrong.?

g, the reference material really does not apply to the question of this thread which is finding the v$undostat information for the time period when an ORA-015555 error occurred.
Try this:
select * from v$undostat
where ssolderrcnt <> 0
or nospaceerrcnt <> 0
This should find all v$undostat periods where a 1555 occurred along with periods where you ran short of undo tablespace.
Also v$undostat is only populated where undo management is in effect. There should be 404 rows in this view if undo management is in effect otherwise this view is not useable for this purpose.
HTH -- Mark D Powell --

Receiving error ORA-01555: snapshot too old:

Need some info...
Currently seeing ORA-01555: snapshot too old: rollback segment number 18 with name "_SYSSMU18$" too small.
Info:
SQL> show parameter undo
NAME TYPE VALUE
undo_management string AUTO
undo_retention integer 4200
undo_suppress_errors boolean FALSE
undo_tablespace string UNDOTBS_1
SQL> select max(maxquerylen) from v$undostat;
MAX(MAXQUERYLEN)
35792
SQL>
run this based on threads in here:
SQL> select (35792/60)/60 query,(4200/60)/60 retention from dual;
QUERY RETENTION
9.94222222 1.16666667
I need some help figuring out what to set my undo_retention to? Should it be 36000?
Any help is appreciated.
Thanks

Jamie CC wrote:
The query that was in the alert log was running against a table with 779 rows. The query uses the index (not worried if it wouldn't for that small a table) and came back in one second... This makes no sense. Is it possible that there was a sub-query running and the wrong query was put into the alert log?More likely the query in the alert log was one that died, but the cause was a different query. Remember, the meaning of an ORA-1555 is that the query needed to go back to undo in order to gather a view of the data to a certain SCN, and the data had already been aged out. So the alert log gets the one that died, but the cause is another one. Feel lucky at that, in older versions it was considered an app error IIRC.
Search for the error on asktom.oracle.com for a number of scenarios, and you might want to review the part of the concepts manual about read consistency to make sense of it all. You might also find Tom's book explanation about it with a google search.
Also, depending on your version, there may be things to set like retention guarantee.
I've found on the ERP/MRP systems I work on these errors will appear weekly from people leaving sessions connected after they go home, so I kill 'em off at night. And that's with an undo nearly as big as the db data, that's normally almost empty.

Ora-01555 in 9i Datawarehouse db

Hi,
We have some ora-01555 , mostly on insert /* append */ select from and create tables as select with big tables, the source tables are 2000 millions rows.
The undo tablespace has 49 Gb.
The undo_retention is set to 2500.
It`s true that the executions fails between 4000 and 9000 seconds and the undo_retention is lower, but in v$undostat UNXPSTEALCNT, EXPSTEALCNT, NOSPACEERRCNT, UNXPBLKRELCNT, UNXPBLKREUCNT ara alway 0 so my point of view is that there is no problem of space or undo_retention.
Could you please confirm this ?
If so, could it be a delayed block clenaout problem ?
Regars
Xavi

What is the value of TUNED_UNDORETENTION column of V$UNDOSTAT?
I think you should try increasing undo_retention.

ORA-01555 in Oracle 9.2.0.5

we running Baan IV on a Oracle 9.2.0.5 database.
Sometimes we got an error in the alert log file like:
ORA-01555 caused by SQL statement below (Query Duration=60440 sec, SCN: 0x0001.a452e41c)
Now, i want to know which user with which sql-statement (if possible) get this error.
So this error is mostly at night, i try to write a trigger to get this information.
But i don't know how to do this.
Can somebody help me ?
T.Kindermann

Now, i want to know which user with which sql-statement (if possible) get this error.If you see the alert log file, you will also have the sql that caused ora-1555 errors along with time stamp.
If you are using AUM (automatic Undo management), tune your undo parameters and tablespace using v$undostat. If you are using MUM (manual rollback segment), create a big rollback segment and assign to this transaction.
Jaffar

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

R3load export of table REPOSRC with lob col - error ora-1555 and ora-22924

Hello,
i have tried to export data from our production system for system copy and then upgrade test. while i export the R3load job has reported error in table REPOSRC, which has lob column DATA. i have apsted below the conversation in which i have requested SAP to help and they said it comes under consulting support. this problem is in 2 rows of the table.
but i would like to know if i delete these 2 rows and then copy from our development system to production system at oracle level, will there be any problem with upgrade or operation of these prorgams and will it have any license complications if i do it.
Regards
Ramakrishna Reddy
__________________________ SAP SUPPORT COnveration_____________________________________________________
Hello,
we have are performing Data Export for System copy of our Production
system, during the export, R3load Job gave error as
R3LOAD Log----
Compiled Aug 16 2008 04:47:59
/sapmnt/DB1/exe/R3load -datacodepage 1100 -
e /dataexport/syscopy/SAPSSEXC.cmd -l /dataexport/syscopy/SAPSSEXC.log -stop_on_error
(DB) INFO: connected to DB
(DB) INFO: DbSlControl(DBSL_CMD_NLS_CHARACTERSET_GET): WE8DEC
(DB) INFO: Export without hintfile
(NT) Error: TPRI_PAR: normal NameTab from 20090828184449 younger than
alternate NameTab from 20030211191957!
(SYSLOG) INFO: k CQF :
TPRI_PAR&20030211191957&20090828184449& rscpgdio 47
(CNV) WARNING: conversion from 8600 to 1100 not possible
(GSI) INFO: dbname = "DB120050205010209
(GSI) INFO: vname = "ORACLE "
(GSI) INFO: hostname
= "dbttsap "
(GSI) INFO: sysname = "AIX"
(GSI) INFO: nodename = "dbttsap"
(GSI) INFO: release = "2"
(GSI) INFO: version = "5"
(GSI) INFO: machine = "00C8793E4C00"
(GSI) INFO: instno = "0020111547"
(DBC) Info: No commits during lob export
DbSl Trace: OCI-call 'OCILobRead' failed: rc = 1555
DbSl Trace: ORA-1555 occurred when reading from a LOB
(EXP) ERROR: DbSlLobGetPiece failed
rc = 99, table "REPOSRC"
(SQL error 1555)
error message returned by DbSl:
ORA-01555: snapshot too old: rollback segment number with name "" too
small
ORA-22924: snapshot too old
(DB) INFO: disconnected from DB
/sapmnt/DB1/exe/R3load: job finished with 1 error(s)
/sapmnt/DB1/exe/R3load: END OF LOG: 20100816104734
END of R3LOAD Log----
then as per the note 500340, i have chnaged the pctversion of table
REPOSRC of lob column DATA to 30, but i get the error still,
i have added more space to PSAPUNDO and PSAPTEMP also, still the same
error.
the i have run the export as
exp SAPDB1/sap file=REPOSRC.dmp log=REPOSRC.log tables=REPOSRC
exp log----
dbttsap:oradb1 5> exp SAPDB1/sap file=REPOSRC.dmp log=REPOSRC.log
tables=REPOSRC
Export: Release 9.2.0.8.0 - Production on Mon Aug 16 13:40:27 2010
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Connected to: Oracle9i Enterprise Edition Release 9.2.0.8.0 - 64bit
Production
With the Partitioning option
JServer Release 9.2.0.8.0 - Production
Export done in WE8DEC character set and UTF8 NCHAR character set
About to export specified tables via Conventional Path ...
. . exporting table REPOSRC
EXP-00056: ORACLE error 1555 encountered
ORA-01555: snapshot too old: rollback segment number with name "" too
small
ORA-22924: snapshot too old
Export terminated successfully with warnings.
SQL> select table_name, segment_name, cache, nvl(to_char
(pctversion),'NULL') pctversion, nvl(to_char(retention),'NULL')
retention from dba_lobs where
table_name = 'REPOSRC';
TABLE_NAME | SEGMENT_NAME |CACHE | PCTVERSION | RETENTION
REPOSRC SYS_LOB0000014507C00034$$ NO 30 21600
please help to solve this problem.
Regards
Ramakrishna Reddy
Dear customer,
Thank you very much for contacting us at SAP global support.
Regarding your issue would you please attach your ORACLE alert log and
trace file to this message?
Thanks and regards.
Hello,
Thanks for helping,
i attached the alert log file. i have gone through is, but i could
not find the corresponding Ora-01555 for table REPOSRC.
Regards
Ramakrishna Reddy
+66 85835-4272
Dear customer,
I have found some previous issues with the similar symptom as your
system. I think this symptom is described in note 983230.
As you can see this symptom is mainly caused by ORACLE bug 5212539 and
it should be fixed at 9.2.0.8 which is just your version. But although
5212539 is implemented, only the occurrence of new corruptions will be
avoided, the already existing ones will stay in the system regardless of the patch.
The reason why metalink 452341.1 was created is bug 5212539, since this
is the most common software caused lob corruption in recent times.
Basically any system that was running without a patch for bug 5212539 at some time in the past could be potentially affected by the problem.
In order to be sure about bug 5212539 can you please verify whether the
affected lob really is a NOCACHE lob? You can do this as described in
mentioned note #983230. If yes, then there are basically only two
options left:
-> You apply a backup to the system that does not contain these
corruptions.
-> In case a good backup is not available, it would be possible to
rebuild the table including the lob segment with possible data loss . Since this is beyond the scope of support, this would have to be
done via remote consulting.
Any further question, please contact us freely.
Thanks and regards.
Hello,
Thanks for the Help and support,
i have gone through the note 983230 and metalink 452341.1.
and i have ran the script and found that there are 2 rows corrupted in
the table REPOSRC. these rows belong to Standard SAP programs
MABADRFENTRIES & SAPFGARC.
and to reconfirm i have tried to display them in our development system
and production system. the development systems shows the src code in
Se38 but in production system it goes to short dump DBIF_REPO_SQL_ERROR.
so is it possible to delete these 2 rows and update ourselves from our
development system at oracle level. will it have any impact on SAP
operation or upgrade in future.
Regards
Ramakrishna Reddy

Hello, we have solved the problem.
To help someone with the same error, what we have done is:
1.- wait until all the processes has finished and the export is stopped.
2.- startup SAP
3.- SE14 and look up the tables. Crete the tables in the database.
4.- stop SAP
5.- Retry the export (if you did all the steps with sapinst running but the dialogue window in the screen) or begin the sapinst again with the option: "continue with the old options".
Regards to all.

Refresh Collection Snapshots Error ORA-12008 ORA-01555

Need some insight!
Ct is implementing R12.1.1 ASCP using existing 11.5.10 EBS as source.
In source EBS, when running Refresh Collection Snapshots (RCS) in COMPLETE mode, we encounter this error:
ORA-12008: error in materialized view refresh path
ORA-01555: snapshot too old: rollback segment number 13 with name "_SYSSMU13$" too small
ORA-12008: error in materialized view refresh path
ORA-01555: snapshot too old: rollback segment number 13 with name "_SYSSMU13$" too small
All the snapshot entities got refreshed successfully (in 5 minutes) but the Refresh Collection Snapshot request itself ends with ERROR (after 4 hrs).
Appreciate your input on this one.
Thanks,
Jake

Welcome to the forums !
ORA-01555 is a common error condition. There are typically two solutions (or a combination of both) -
1. Increase rollback / undo tablespace size
2. Run your process when the database is not active (i.e. few or no updates/deletes/inserts etc).
More information may be available in these MOS Docs
211121.1 - How To Run MSRFWOR - Refresh Collections Snapshots Concurrent Request From The Application
207644.1 - Data Collections is Failing - All Errors - First Diagnostic Steps
306418.1 - 11.5.10 MSRFWOR: Refresh Collection Snapshot Performance Is Poor and Fails with Errors
369173.1 - MSRFWOR Refresh Collection Snapshots Performance Database Bug 4196039
308487.1 - Refresh Collection Snapshot Request Fails Yet The Request Shows Complete Normal
HTH
Srini

Dreaded ORA 1555 and EXP-00056 and LOB Corruption

I am on Oracle 10.2.0.4 on HP UNIX 11.2.
I have started getting
EXP-00056: ORACLE error 1555 encountered
ORA-01555: snapshot too old: rollback segment number with name "" too small
ORA-22924: snapshot too old
I have looked into various causes and still no clue why it happening:
1.     Undo_retention, it Is set to 5 hours (converted to seconds0> My export backup lasts
For 1.5 to 2 hours.
2.     My undo tablespace size is 28GB. Looking at undo advisor I only need 5GB.
3.     Yes, my table where error message comes consistent has LOB (BLOB) column.
I did check for LOB corruption as per metalink note (script shown below) and it gives
Me messages:
rowid AABV8QAAJAAGAn6AAM is corrupt. ORA-01403: no data found
rowid AABV8QAAKAAAcaAAAX is corrupt. ORA-01403: no data found
rowid AABV8QAAKAAAcamABr is corrupt. ORA-01403: no data found
rowid AABV8QAAKAAAcamABu is corrupt. ORA-01403: no data found
I do not know what to make of these messages because when I look in my table where problem
Where error occurs:
Select pr_id, col1, col2 from pr where rowed in (above rowids)’; there are
No rows. What does this mean? Why it is corruption.
Below is the script used to find LOB corruption…
declare
pag number;
len number;
c varchar2(10);
charpp number := 8132/2;
begin
for r in (select rowid rid, dbms_lob.getlength (LS_VALUE) len
from PR_ADDTL_DATA) loop
if r.len is not null then
for page in 0..r.len/charpp loop
begin
select dbms_lob.substr (LS_VALUE, 1, 1+ (page * charpp))
into c
from PR_ADDTL_DATA
where rowid = r.rid;
exception
when others then
dbms_output.put_line('rowid ' || r.rid || ' is corrupt. ' || sqlerrm);
commit;
end;
end loop;
end if;
end loop;
end;
/

user632098 wrote:
Thanks; but script in my therad one supplied by Oracle to check for lob corruption. It has nothing to do with the export error.
What I am asking is if there in no row on a page (ORA_1403) , that does not mean that there is a corruption. If I was getting execption like ORA-1555 when running this script; that will mean there is lob corruption,ORA-01555 has NOTHING to do a "corruption"; LOB related or otherwise!
Most likely cause is that some session is doing DML against table & doing "frequent" COMMIT;
while some (other?) session is doing SELECT against same table.

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

ORA-01555 and v$undostat

Similar Messages

Maybe you are looking for