Ora-1555

hello ,
I know this question has been posted in this forum a lot of times and i have
read most of them from the archives but still can anybody help me out with
this.
Most of the activities on our system are short queries and updates and there
are no batch files doing doing huge updates/selects that are running.
initially i had 10 rollback segements with 512K of initial,next and 5M of
optimal. and the statistics that i used to get from v$rollstat was this
dbo@ENM1516>select extents,writes,gets,waits,optsize,hwmsize,shrinks,wraps,aveshrink from v$rollstat;
EXTENTS WRITES GETS WAITS OPTSIZE HWMSIZE SHRINKS WRAPS AVESHRINK
6 10416 301 0 364544 0 0 0
11 93479584 303442 0 5242880 5627904 0 212 0
11 171553042 358345 20 5242880 93179904 18 390 4864000
11 93410072 346803 42 5242880 5627904 0 213 0
11 94937792 304325 2 5242880 5627904 0 216 0
11 89638294 301663 2 5242880 5627904 0 204 0
11 169077244 340748 3 5242880 100859904 19 400 5012210
11 90504356 303184 0 5242880 5627904 0 206 0
11 91587584 303244 1 5242880 5627904 0 209 0
11 118358574 315595 3 5242880 37371904 7 276 4534857
11 96496414 303315 1 5242880 5627904 0 219 0
11 rows selected.
and i used to get the snapshot too old error
after this i changed the rollback segment parameters to intial 1M, next 1M,
optimal 50M and minextent 20 maxextent 400
Isn't this supposed to reduce the wraps? but now i get these statistics from
v$rollstat
dbo@ENM1516>select extents,writes,gets,waits,optsize,hwmsize,shrinks,wraps,aveshrink from v$rollstat
EXTENTS WRITES GETS WAITS OPTSIZE HWMSIZE SHRINKS WRAPS AVESHRINK
6 9750 300 0 364544 0 0 0
20 223812724 631736 1 52428800 21295104 0 534 0
20 223707032 673188 29 52428800 21295104 0 534 0
20 224711684 632845 2 52428800 21295104 0 537 0
50 310731946 663666 2 52428800 102510592 5 637 9859891
50 223743564 631558 0 52428800 53243904 0 534 0
20 224872176 632430 2 52428800 21295104 0 538 0
50 223026560 629640 1 52428800 53243904 0 532 0
20 223153556 628883 1 52428800 21295104 0 532 0
50 223274594 654880 17 52428800 53243904 0 533 0
50 351965640 690660 3 52428800 121401344 7 688 9736777
11 rows selected.
if you can see, the wraps have more than doubled. and as expected i am still
getting ora-1555
what should i do for this.
warm regards,
Pinto.

Thanks Paul.
You cannot use the "SET TRANSACTION" command with the export utility. If it is possible, take all but the large rollback segments off line, run the export, bring the rollback segments back online.

Similar Messages

ORA-1555 ORA-3136 errors:: elapsed time vs Query Duration

Dear all,
- My Database version is 11.2.0.2, Solaris.
- We have been having a problem in the production database where the front end nodes start going up and down for couple of hours sometimes. ; When node flapping is going on we get connection timed out alerts.
WARNING: inbound connection timed out (ORA-3136) opiodr aborting
process unknown ospid (4342) as a result of ORA-609 opiodr aborting
process unknown ospid (4532) as a result of ORA-609 opiodr aborting
process unknown ospid (4534) as a result of ORA-609 opiodr aborting....
Since this week node flapping is happening every day. Since past 2 days after or during node flapping we are getting ORA-1555 error.
Extract from alert log error:
ORA-01555 caused by SQL statement below (SQL ID: g8804k5pkmtyt, Query Duration=19443 sec, SCN: 0x0001.07bd90ed):
SELECT d.devId, d.vendor, d.model, d.productClass, d.oui, d.parentDeviceId, d.created, d.lastModified AS devLastMod, d.customerId, d.userKey1, d.userKey2, d.userKey4, d
.userKey5, d.firmwareFamily, d.softwareVer, d.serialNum, d.ip, d.mac, d.userKey3, d.userKey6, d.provisioningId, d.status, d.classification, d.population, d.name, d.ipRe
solver, d.ipExpirationTime, d.geoLocationId,contact.firstContactTime, ifaces.id, ifaces.type AS ifaceType, ifaces.lastModified AS ifaceLastMod, ifaces.timeoutname, ifac
es.username1, ifaces.password1, ifaces.username2, ifaces.password2, ifaces.connReqUrl, ifaces.connReqScheme, ifaces.srvNonce, ifaces.deviceNonce, ifaces.phoneNumber,ifa
ces.bootstrapSecMethod, ifaces.srvAuthentication, ifaces.deviceAuthentication, ifaces.userPIN, ifaces.networkID, ifaces.omaSessionID, ifaces.portNum, ifaces.mgtIp, ifac
es.cmtsIp, ifaces.mgtReadCommunity, ifaces.mgtWriteCommunity, ifaces.cmtsReadCommunity, ifaces.cmtsWriteCommunity, devto.name AS devtoName, devto.rebootTimeout, devto.sessionInitiationI run Statspack report from the whole day duration, and looking into the elapsed time in seconds no more than 3739.61 sec (too lower than run duration in the alert log file of 19443 sec); So I would like to know if there is any co-relations between the ORA-3136 errors and the ORA-1555 errors?
   CPU                  CPU per             Elapsd                     Old
Time (s)   Executions Exec (s) %Total   Time (s)    Buffer Gets Hash Value
tTime <= :3 ) AND (endTime IS NULL OR endTime >= :4 )
   2773.77    7,787,914       0.00    3.4    3739.61     112,671,645 1909376826
Module: JDBC Thin Client
SELECT d.devId, d.vendor, d.model, d.productClass, d.oui, d.pare
ntDeviceId, d.created, d.lastModified AS devLastMod, d.customerI
d, d.userKey1, d.userKey2, d.userKey4, d.userKey5, d.firmwareFam
ily, d.softwareVer, d.serialNum, d.ip, d.mac, d.userKey3, d.user
SQL> show parameter UNDO_MANAGEMENT
NAME                                 TYPE        VALUE
undo_management                      string      AUTO
SQL> show parameter UNDO_RETENTION
NAME                                 TYPE        VALUE
undo_retention                       integer     10800BR,
Diego

Thank you. Please let me know if it is enough or you need more information;
SQL ordered by Gets DB/Inst: DB01/db01 Snaps: 14835-14846
-> End Buffer Gets Threshold:    100000 Total Buffer Gets:     677,689,568
-> Captured SQL accounts for   73.6% of Total Buffer Gets
-> SQL reported below exceeded 1.0% of Total Buffer Gets
                                                     CPU      Elapsd     Old
Buffer Gets    Executions Gets per Exec %Total Time (s) Time (s) Hash Value
     21,286,248    2,632,793            8.1    3.4   666.73    666.76 3610154549
Module: JDBC Thin Client
SELECT d.devId, d.vendor, d.model, d.productClass, d.oui, d.pare
ntDeviceId, d.created, d.lastModified AS devLastMod, d.customerI
d, d.userKey1, d.userKey2, d.userKey4, d.userKey5, d.firmwareFam
ily, d.softwareVer, d.serialNum, d.ip, d.mac, d.userKey3, d.user
     17,029,561    1,176,849           14.5    2.7   417.32    416.73 1909376826
Module: JDBC Thin Client
SELECT d.devId, d.vendor, d.model, d.productClass, d.oui, d.pare
ntDeviceId, d.created, d.lastModified AS devLastMod, d.customerI
d, d.userKey1, d.userKey2, d.userKey4, d.userKey5, d.firmwareFam
ily, d.softwareVer, d.serialNum, d.ip, d.mac, d.userKey3, d.user
     17,006,795           37      459,643.1    2.7   367.61    368.95 4045552861
Module: JDBC Thin Client
SELECT d.devId, d.vendor, d.model, d.productClass, d.oui, d.pare
ntDeviceId, d.created, d.lastModified AS devLastMod, d.customerI
d, d.userKey1, d.userKey2, d.userKey4, d.userKey5, d.firmwareFam
ily, d.softwareVer, d.serialNum, d.ip, d.mac, d.userKey3, d.userAnother Statspack report for the whole day shows;
SQL ordered by CPU DB/Inst: DB01/db01 Snaps: 14822-14847
-> Total DB CPU (s):          82,134
-> Captured SQL accounts for   40.9% of Total DB CPU
-> SQL reported below exceeded 1.0% of Total DB CPU
    CPU                  CPU per             Elapsd                     Old
Time (s)   Executions Exec (s) %Total   Time (s)    Buffer Gets Hash Value
tTime <= :3 ) AND (endTime IS NULL OR endTime >= :4 )
   2773.77    7,787,914       0.00    3.4    3739.61     112,671,645 1909376826
Module: JDBC Thin Client
SELECT d.devId, d.vendor, d.model, d.productClass, d.oui, d.pare
ntDeviceId, d.created, d.lastModified AS devLastMod, d.customerI
d, d.userKey1, d.userKey2, d.userKey4, d.userKey5, d.firmwareFam
ily, d.softwareVer, d.serialNum, d.ip, d.mac, d.userKey3, d.user
SQL ordered by Gets DB/Inst: DB01/db01 Snaps: 14822-14847
-> End Buffer Gets Threshold:    100000 Total Buffer Gets:   1,416,456,340
-> Captured SQL accounts for   55.8% of Total Buffer Gets
-> SQL reported below exceeded 1.0% of Total Buffer Gets
                                                     CPU      Elapsd     Old
Buffer Gets    Executions Gets per Exec %Total Time (s) Time (s) Hash Value
     86,354,963    7,834,326           11.0    6.3 2557.34   2604.08 906944860
Module: JDBC Thin Client
SELECT d.devId, d.vendor, d.model, d.productClass, d.oui, d.pare
ntDeviceId, d.created, d.lastModified AS devLastMod, d.customerI
d, d.userKey1, d.userKey2, d.userKey4, d.userKey5, d.firmwareFam
ily, d.softwareVer, d.serialNum, d.ip, d.mac, d.userKey3, d.user
.....BR,
Diego
Edited by: 899660 on 27-ene-2012 7:43
Edited by: 899660 on 27-ene-2012 7:45

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.

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.

Fetch cross commit doens't throw ora-1555 in 10.2.0.3

in this link, Ktye put an example of fetch across commit which will throw ora-1555.
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:546822742166
But I can't reproduce it in oracle 10.2.0.3. Anything changed for undo in 10g? I set inmemory_undo to false, but can't reproduce the ora-1555.
SQL> drop table t;
Table dropped.
SQL> create table t as select * from all_objects;
Table created.
SQL> create index t_idx on t(object_id);
Index created.
SQL>
SQL> create rollback segment rbs_small storage (initial 1k next 1k maxextents 2) tablespace system;
Rollback segment created.
SQL> alter rollback segment rbs_small online;
Rollback segment altered.
SQL>
SQL> begin
2          for x in ( select * from t where object_id > 0 )
3          loop
4                  dbms_transaction.use_rollback_segment( 'rbs_small' );
5                  update t set object_name = lower(object_name)
6                    where object_id = x.object_id;
7                  commit;
8          end loop;
9 end;
10 /
PL/SQL procedure successfully completed.
SQL>
SQL> select count(*) from t;
COUNT(*)
     16627
SQL>

Thanks everyone for the suggestion
Adding the hint as /*+ index(t t_idx) */ or increase the undo tablespace to 400k doesn't help.
I found it used lots of in memory undo (65216004) in the first run, so before the second run, I tuned off the in memory undo, but still can't reproduce ora-01555
First run
SQL> create undo tablespace UNDOTBS2 datafile 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\UNDOTBS2.DBF' size 400k reuse;
Tablespace created
SQL> alter system set undo_tablespace=UNDOTBS2;
System altered
SQL> alter system flush BUFFER_CACHE;
System altered
SQL> alter session set plsql_optimize_level=0;
Session altered
SQL> select b.NAME,a.VALUE from v$mystat a , v$statname b where a.STATISTIC#=b.STATISTIC# and b.NAME like '%undo%size%';
NAME                                                                  VALUE
undo change vector size                                               47680
IMU undo allocation size                                                104
SQL> begin
2          for x in ( select /*+ index(t t_idx) */ * from t where object_id > 0 )
3          loop
4                  update t set object_name = lower(object_name)
5                    where object_id = x.object_id and rownum=1;
6                  commit;
7          end loop;
8 end;
9 /
PL/SQL procedure successfully completed
SQL> select b.NAME,a.VALUE from v$mystat a , v$statname b where a.STATISTIC#=b.STATISTIC# and b.NAME like '%undo%size%';
NAME                                                                  VALUE
undo change vector size                                            17403772
IMU undo allocation size                                           65216004
SQL> select count(*) from t;
COUNT(*)
     50249
SQL> alter system set "_in_memory_undo"=false;
System alteredAfter tune off the in memory undo, the second run
SQL> alter system set undo_tablespace=UNDOTBS2;
System altered
SQL> alter system flush BUFFER_CACHE;
System altered
SQL> alter session set plsql_optimize_level=0;
Session altered
SQL> select b.NAME,a.VALUE from v$mystat a , v$statname b where a.STATISTIC#=b.STATISTIC# and b.NAME like '%undo%size%';
NAME                                                                  VALUE
undo change vector size                                            17445460
IMU undo allocation size                                           65216004
SQL> begin
2          for x in ( select /*+ index(t t_idx) */ * from t where object_id > 0 )
3          loop
4                  update t set object_name = lower(object_name)
5                    where object_id = x.object_id and rownum=1;
6                  commit;
7          end loop;
8 end;
9 /
PL/SQL procedure successfully completed
SQL> select b.NAME,a.VALUE from v$mystat a , v$statname b where a.STATISTIC#=b.STATISTIC# and b.NAME like '%undo%size%';
NAME                                                                  VALUE
undo change vector size                                            34730428
IMU undo allocation size                                           65216004
SQL> select count(*) from t;
COUNT(*)
     50249

Ora-1555 while taking export

Hi Guys,
I am getting the below error while taking the export:
EXP-00008: ORACLE error 1555 encountered
ORA-01555: snapshot too old: rollback segment number 3 with name "_SYSSMU3$" too small
EXP-00056: ORACLE error 1555 encountered
ORA-01555: snapshot too old: rollback segment number 3 with name "_SYSSMU3$" too small
EXP-00000: Export terminated unsuccessfully
SQL> select SEGMENT_NAME,status,max_extents from dba_rollback_segs where tablespace_name='ESUT001'
and status='ONLINE';
SEGMENT_NAME STATUS MAX_EXTENTS
_SYSSMU1$                      ONLINE                 32765
_SYSSMU2$                      ONLINE                 32765
_SYSSMU3$                      ONLINE                 32765
_SYSSMU4$                      ONLINE                 32765
_SYSSMU5$                      ONLINE                 32765
_SYSSMU6$                      ONLINE                 32765
_SYSSMU7$                      ONLINE                 32765
_SYSSMU8$                      ONLINE                 32765
_SYSSMU9$                      ONLINE                 32765
_SYSSMU10$                     ONLINE                 32765
_SYSSMU11$                     ONLINE                 32765
SEGMENT_NAME STATUS MAX_EXTENTS
_SYSSMU12$                     ONLINE                 32765
_SYSSMU13$                     ONLINE                 32765
_SYSSMU14$                     ONLINE                 32765
_SYSSMU15$                     ONLINE                 32765
_SYSSMU16$                     ONLINE                 32765
_SYSSMU17$                     ONLINE                 32765
_SYSSMU18$                     ONLINE                 32765
Could you pls suggest how can resolve this issue.
Thanks
Sumit

You'd better do the export during quiet hour of your database.
Otherwise, use
consistent = N
flag
Increase your undo space will also help
consistent – [N] Specifies the set transaction read only statement for export, ensuring data consistency. This option should be set to “Y” if activity is anticipated while the exp command is executing. If ‘Y’ is set, confirm that there is sufficient undo segment space to avoid the export session getting the ORA-1555 Snapshot too old error.

ORA- 1555 problem

hi all,
im wrking in a three tier architecture & im getting ORA-1555 error frequently by a same query but im unable to trace from which progam ist executing this sql... Is there any mechanism to find out sid,serial no of that sql..?

ORA-01555 is a symptom of a completely different problem. Finding the query will likely not do anything other than create confusion - because it is NOT the cause of the 1555.
As Oracle returns a row in response to a query or subquery, Oracle tries to rebuild that row to reflect the way it looked to the world at the instant the query was issued. If necessary it uses ROLLBACK information to rebuild that row. ORA-01555 means that the rollback (aka UNDO) has been lost and is no longer available.
But UNDO information is guaranteed to stay around if a transaction has not been committed, because the transaction itself may need to rollback.
On the other hand, if the transaction is committed and the UNDO or ROLLBACK space is too small, the database may be forced to reuse that space for a new transaction.
There are 2 common causes for ORA-01055. These are
- the UNDO tablespace or public ROLLBACK SEGMENTS are too small for the transaction load; and
- there is an application or program that commits inside a loop, allowing undo space to be reused.
The solution is to
- look for programs that have COMMIT statements inside loops and rewrite them to follow Oracle programming requirements
- increase the size of the UNDO/ROLLBACK, perhaps to very very large sizes
- if available, enable 'GUARANTEED RETENTION'

Ora-1555 during exports and imports. possible causes. ?

From my understanding : I know that this error will occur due to a undo retention being smaller sizer. or rather I should put it that increasing this parameter should help fix the issue.
Whats not clear is below :
Qn. Is it possible that ORA-1555 errors can occur during 'import' even if no other sessions are connected and performing any transaction/dmls ?
Qn. Also why does a ORA-1555 occur during a 'export' ? Is the same reasons ie. there could be possible DMLs occuring ?

Hello,
About your first question:
Qn. Is it possible that ORA-1555 errors can occur during 'import' even if no other sessions are connected and performing any transaction/dmls ?I've never got this error during import but, I always care to get enough place on the UNDO Tablespace.
With classical import you have a commit after each Table's import (by default) and a commit after each row's import if COMMIT=Y so as to use less space in the Rollback Segment.
With Datapump, I often decrease the undo_retention parameter before importing so as to use less space on the UNDO Tablespace.
About the second question:
Qn. Also why does a ORA-1555 occur during a 'export' ? Is the same reasons ie. there could be possible DMLs occuring ?To get a consistent image of the exported data with the classical export you may use the parameter CONSISTENT=Y. While you may use the FLASHBACK_TIME parameter with Datapump (so it means that the undo_retention should be large enough when exporting).
Both use the Undo entries, so I imagine that's possible to get some error (may be ORA-01555) if you don't have enough place on your UNDO Tablespace.
It's possible (thank to the Rollback Segments) to have concurrent DML on the database while exporting.
Anyway, from my point of view, while exporting or importing if you have enough space on your UNDO tablespace and a correct undo_retention setting (not too large when importing not too small when exporting) it should be fine.
Hope this help.
Best regards,
Jean-Valentin

Got ORA-1555, but session is running

I ran a CTAS statement on my database. After 1 hr, I received ora-1555 error in my alert log. But, if I check the database, I can see that the session is active and the size of temp segment is growing. How is that possible? What am I missing here?
Please advice.
Update :Any advice out there?

Are you sure that the session that got the ORA-01555 error was the session running the CTAS statement? Might you have caused a different session to encounter the error?
Justin

ORA-1555 (SNAPSHOT TOO OLD)의 일반적인 원인 및 조치사항

제품 : ORACLE SERVER
작성날짜 : 2003-09-29
ORA-1555 (SNAPSHOT TOO OLD)의 일반적인 원인 및 조치사항
===========================================
PURPOSE
ORA-1555 (snapshot too old)는 db 관리 업무에 익숙하지 않은 경우, rollback
관련된 오류 중 혼란을 일으키기 쉬운 오류이다.
이미 문서 <bulletin:11152>와 그외 자료가 이 오류를 설명하고 해결하기 위해
만들어져 있지만, ORA-1555 원인 파악을 위해 내용이 다소 길고 복잡하게
구성되어 있는 편이다.
여기에서는 발생 가능한 여러가지 원인 중 일반적인 원을을 위주로, 초보자도
쉽게 이해할 수 있도록 간단히 설명한다.
Explanation
일반적으로 ORA-1555에 혼란을 일으키는 원인은 한편으로는 오류 메시지 자체에
있다고 볼 수 있다.
ORA-1555: snapshot too old: rollback segment %s too small
이와 같은 오류에서 마치 ora-1555가 rollback segment에 write시 space가
부족해서 발생하는것으로 착각하는 사용자가 많다.
중요한 것은 ORA-1555는 rollback segment에 정보를 write시에 발생하는 것이
아니고 rollback segment로 부터 before image를 읽으려는 시점에서 발생한다는
것이다.
쉬운 예를 들어보자.
(1) 사원이 천명인 회사에서 select한 문장으로 그 전체 사원의 정보를 읽는데
10분이 걸린다고 가정한다.
(2) 100번 사원 정보를 읽는데, 아직 읽지 않은 700번 사원에 대해 다른 session에서
급여를 인상하는 update문장을 수행하고 commit을 한다.
select문장은 lock을 걸지 않기 때문에 select도중 다른 update문장이
수행되고 commit하는데 아무 문제가 없다.
(3) 1번에서 수행중인 select문장이 계속 진행되면서 700번 사원 정보를 읽으려고
하면 이 정보가 수정되어 변경되었음을 알게 된다.
그럼 select문장은 정보의 일관성을 위해 첫번째 사원을 읽기 시작한 시점의
700번 사원에 대한 정보를 읽기 위해, 즉 before image를 읽기 위해
rollback segment를 찾아간다.
(4) rollback segment내에 급여 인상 전 정보가 있으면 읽는다.
단 이때,
이 시스템에 트랜잭션이 매우 많아서 commit이 매우 많이 발생한 경우
이미 2번에서 변경하고 commit한 정보는 다른 트랜잭션에서 overwrite했을
수 있다.
이런 경우 before image를 읽으러 간 select문장은 ora-1555를 만나게 되는
것이다.
(5) 4번에서 ora-1555를 만난 경우 다시 동일한 select문장을 수행하면,
이번에는 이미 급여가 인상된 후의 시점에서 시작하므로 700번 사원을
읽는 경우에도 급여 인상전의 before image가 필요하지 않아 ora-1555는
다시 발생하지 않을 수 있다.
이러한 이유로 ora-1555는 발생했다 안했다 하는 식으로 일정하게 발생되지
않고, 조치 방법이라는것도 100% 안전하기보다는 확률적으로 충분히 만나지
않을 수 있는 환경을 만드는것이라고 볼 수 있다.
결국 ora-1555가 발생하는 것은 읽어야 하는 before image가 다른 트랜잭션에
의해 이미 overwrite되어 읽을 수 없는 경우 발생하므로, 발생하지 않게 하기
위해서는 데이타를 조회시 consistency를 유지해야 하는 시점동안 가능하면
오래 동안 rollback의 image가 유지되어야 하는것이다.
이렇게 이미 기록된 정보를 가능하면 오랜 기간동안 유지한다는 것은 새로운
트랜잭션의 기록을 위해 space를 확보해야 하는 작업과는 반대된다.
즉, ORA-1562와 같이 rollback segment를 write시에 space가 부족하여
space를 확보하기 위한 조치 방법과, 이 ORA-1555의 조치 방법을 서로 상충되어
trade-off가 있음을 주의해야 한다.
두 오류를 모두 피해가기 위해서는 일반적으로 매우 큰 rollback space가
도움이 된다.
ORA-1555의 일반적인 발생 경우 및 해결 방법을 정리한다.
(1) 트랜잭션에 비해 rollback segment 갯수가 적은 경우
rollback segment하나에 동시에 기록 가능한 트랜잭션의 수는 rollback
segment header내의 transaction table의 entry갯수로 제한되어 있다.
이 수는 oracle version마다 다르지만 8i이상부터는 약 20개 정도이다.
(transactions_per_rollback_segment의 지정과는 무관한다.)
기본적으로 install시 생성되는 rollback segment는 4개인데, 이대로 놓고
사용한다면, 결국 80 (20 * 4) 만큼의 commit이 발생하고 난 뒤에는
다시 처음부터 transaction table의 entry 중 commit된 트랜잭션의
정보를 가지는 entry의 정보를 overwrite하게 되는 것이다.
해결 방법: rollback segment갯수를 증가시킨다.
즉 새로운 rollback segment를 create시킨다.
부작용: 제한된 rollback tablespace공간 내에서, 여러개의 rollback
segment를 유지하는것은 하나의 rollback segment가 평균 가질 수
있는 space가 그만큼 줄어드는 셈이다.
이 부작용까지 줄이려면, rollback tablespace자체가 충분히
커야 하고 space를 많이 요구하는 트랜잭션은 'set transaction
use rollback segment' 문장을 이용하여 큰 rollback을 지정하여
사용하도록 한다.
(2) rollback segment를 shrink하거나 optimal이 설정된 경우
rollback segment를 shrink하거나 optimal을 지정하게 되면 이미 쓰여진
rollback의 before image를 다른 트랜잭션이 overwrite도 하기 전에 미리
지워 버리게 되는 셈이다.
그러므로 이런 경우도 ora-1555의 원인이 된다.
해결 방법: optimal을 너무 적게 지정하지 말고, shrink를 너무 자주
하지 않는다. shrink를 수행 후 ora-1555가 발생하는 경우,
단지 다시 조회하는것만으로 앞의 예제 (5)번에서 설명한
이유로 인해, 해결되는 경우가 많다.
(3) proc와 같은 application에서 loop내의 fetch문장에서 자주 commit을
하는 경우
fetch문장은 loop를 도는 동안 일정하게 read consistency를 유지해야 한다.
그리고 미리 cursor를 정의시에 데이타를 읽어두는것이 아니고, fetch시에
loop를 돌면서 그때그때 데이타를 읽게 된다.
그런데 loop내의 dml에 대해 너무 자주 commit을 하게 되면 그만큼
여러개의 트랜잭션이 처리된 결과로 rollback segment의 transaction table이
빨리 사용되고 overwrite되게 된다.
해결 방법: loop내의 commit횟수를 줄인다. 예를 들어 loop를 돌때마다
commit하게 하였다면 천번에 한번 혹은 만번 loop를 돈 후
commit하는 식으로 늘려준다.
이 외에도 rollback tablespace자체의 space가 부족하여 transaction table의
entry들이 아직 overwrite되지도 않았는데, commit된 transaction이 사용한
rollback segment내의 space가 먼저 overwrite되는 경우도 있다.
그러나 일반적으로 rollback segment의 space를 너무 작게 유지하지는 않기
때문에 이렇게 space부족으로 ora-1555를 만나는 경우는 많지 않다.
이렇게 space가 절대적으로 부족한 경우는 rollback에 write하는 시점에서,
ora-1562가 먼저 발생하게 된다.
ora-1562에 대해서는 <bulletin:10823> "ORA-1562 분석 및 해결 방법
(ROLLBACK SEGMENT 크기 문제)"를 참조하고,
좀더 자세한 ora-1555의 개념에 대해서는 <bulletin:11152> "ORA-1555 원인
분석 및 조치 사항" 을 참조한다.

ORA-1555 with Parallel query problem

Hi
We are getting many ora-1555 errors with parallel query stuff. Few queries are throwing with hint /* Q98989129 NO_EXPAND INDEX or /* Q908231094 INDEX_RRS. Our applicaiton is like DSS kind with bulk loading and big reports. I have doubled the undo retention and undo size to 200G and set the trace event. But most of the queries are parallel queries. We are not using the following query in applicaiton. seems like it is parallel sub queries. I need to know the exact mechanism how to devide the parallel queries with its degree of parallalism.
SELECT /*+ Q277874009 INDEX_RRS(A1 "PK_TF_UTRAN_UCELL10_TAB") */ A1."TSTAMP" C0,A1."INSTANCE_ID" C1,A1."PMNOFOIRATHOM
ULTIGSMFAILURE" C2,A1."PMNOFOIRATHOCS57GSMFAIL" C3,A1."PMNOFOSPEECHGSMFAILURE" C
4,A1."PMNOFOHOSTANDGSMFAILURE" C5 FROM "FLEXPM"."ERC_TF_UTRAN_UCELL10_TAB" PX_G
RANULE(0, BLOCK_RANGE, DYNAMIC) A1 WHERE A1."TSTAMP"(+)<=TO_DATE('2006-09-25 23:
45:00', 'yyyy-mm-dd hh24:mi:ss')
Thanks

Hi,
probably the error is due to wrong execution plans choosen by the optimizer.
Are the table statistics up to date? Did You use parallel w/o and degree (ex. defining parallel on object using DEFAULT clause instead of a DEGREE)?
Normally, parallel execution can be done in 2 ways, considering the driving object:
1. like in previous versions, like 7.3, w/o partitioning, the object is split, by rowid, directly from the parallel coordinator to the query slaves (normally a number that can be equivalent to the degree of parallelism or the double in case of sort e/o joins).
2. considering a partitioned object, for every partition/subpartition (phisical segment), a query slaves is made in charge.
In both ways, the original session (SID) is the parallel coordinator that coordinates the salves executions.
The hints and statements that You've reported are tipical queries used by slave process.
In my experience, setting the PARALLEL degree to DEFAULT (no degree during CREATE or ALTER of the object after PARALLEL clause) will cause an "explosion" of slaves startup that can conduct to yr errors.
Hope this helps
Max

Why am i still getting Ora-1555?

Hi All
I am getting ORA-1555 snapshot old error in my alerts.
My undo tablespace is 16GB and undo_retention is set for 1Hour.
When cronjobs start expdp for one table, it throws ORA-1555 in alert logs and expdp skips that tables and moves ahead.
I want to know while my undo_retention is set to 1Hour and i have undo tablespace of 16GB which is even autoextendable on... then why am i getting this error.
I believe i should not get this error as if expdp requires more undo on this table then it should have extend the undo tablespace as it is allowed to do so.
Any help on this would be appreciated.
OS: Sun Solaris 10
DB: 10.2.0.3
Thanks
aps

Hi Oradba
i forgot to mention, from last two days we are getting this error for one new table. which is very small in size as compared to the BIGone i am taking about.
I decided to test the PL/sql method now and i choosed the new table which has given 1555 error for last two days.
when i described to see the column with BLOB in table to put in pl sql procedure.... i suddenly realize that this table dont have one.
i again described the table to confirm this and yes, there is no blob column in it and from last two days we have started getting this error. So i believe there is something more on the corrupt blob stuff.
what do you say?
Thanks
aps

Ora - 1555 error with one query

Hi
We are getting ora-1555 error for particularly one query.I am providing the details
1.Database version : 9.2.0.8
2.Database size : 1354 gb
3.Undo tablespace size : 118 GB
4.Undo retention is 18000 secs
SELECT
distinct poi.company_code po_comp_code, poi.customer_number po_customer_number, poi.purchase_order_number, poi.purchase_order_line_item, poi.purchase_order_sub_item_1, poi.purchase_order_sub_item_2, poi.material_status, dt.company_code del_company_code, dt.site_code del_site_code, dt.delivery_number FROM PURGEWORKPO pw JOIN PurchaseOrderItem poi ON (poi.company_code = pw.purchase_order_company_code AND poi.customer_number = pw.purchase_order_customer_number AND poi.purchase_order_number = pw.purchase_order_number ) JOIN MaterialReceipt mr ON (mr.purchase_order_company_code = pw.purchase_order_company_code AND mr.purchase_order_customer_no = pw.purchase_order_customer_number AND mr.purchase_order_number = pw.purchase_order_number) JOIN ReceivingItem ri ON (ri.company_code = mr.company_code AND ri.site_code = mr.site_code AND ri.receiving_number = mr.receiving_number AND ri.package_number = mr.package_number) JOIN DeliveryTicket dt ON (dt.company_code = ri.del_company_code AND dt.site_code = ri.del_site_code AND dt.delivery_number = ri.delivery_number) WHERE pw.purge_session_id = ? AND (( poi.material_status <> 7) OR (DT.CONFIRMED_DATE NOT between ? AND
?)) I am providing some part of the query which is used for purging the data.This query is failing with ora -1555 after Please let us know what action need to be taken.since undo tablespace size and retention time has enough values
Thanks
PV

user10719327 wrote:
Hi
We are getting ora-1555 error for particularly one query.I am providing the details
1.Database version : 9.2.0.8
2.Database size : 1354 gb
3.Undo tablespace size : 118 GB
4.Undo retention is 18000 secs
SELECT
distinct poi.company_code po_comp_code, poi.customer_number po_customer_number, poi.purchase_order_number, poi.purchase_order_line_item, poi.purchase_order_sub_item_1, poi.purchase_order_sub_item_2, poi.material_status, dt.company_code del_company_code, dt.site_code del_site_code, dt.delivery_number FROM PURGEWORKPO pw JOIN PurchaseOrderItem poi ON (poi.company_code = pw.purchase_order_company_code AND poi.customer_number = pw.purchase_order_customer_number AND poi.purchase_order_number = pw.purchase_order_number ) JOIN MaterialReceipt mr ON (mr.purchase_order_company_code = pw.purchase_order_company_code AND mr.purchase_order_customer_no = pw.purchase_order_customer_number AND mr.purchase_order_number = pw.purchase_order_number) JOIN ReceivingItem ri ON (ri.company_code = mr.company_code AND ri.site_code = mr.site_code AND ri.receiving_number = mr.receiving_number AND ri.package_number = mr.package_number) JOIN DeliveryTicket dt ON (dt.company_code = ri.del_company_code AND dt.site_code = ri.del_site_code AND dt.delivery_number = ri.delivery_number) WHERE pw.purge_session_id = ? AND (( poi.material_status <> 7) OR (DT.CONFIRMED_DATE NOT between ? AND
?)) I am providing some part of the query which is used for purging the data.This query is failing with ora -1555 after Please let us know what action need to be taken.since undo tablespace size and retention time has enough values
do NOT have COMMIT inside LOOP!
only have single COMMIT after all rows have been DELETED

Query to find SQL_ID of statement which causes ORA-1555

Could you please sent a query to find which SQL_ID/sql stament causes ORA-1555 error.
Hari

Look in an AWR report spanning the time frame when it occurred. Number of executions may be blank but the elapsed time will be high.
You can also find part of the statement and then trace it back.
http://asktom.oracle.com/pls/asktom/f?p=100:11:1480055079538858::::P11_QUESTION_ID:40115659055475

Query Execution Time for a Query causing ORA-1555

dear Gurus
I have ORA-01555 error , earlier I used the Query Duration mentioned in Alert Log and increased the Undo Retention as I did not find th UnDOBLKS column of v$undostat high for the time of occurence of ORA-01555..
But new ORA-01555 is coming whose query duration exceeds Undo Retention time..
My question -
1. Is it possible to accurately find the query duration time besides the Alert Log file ?

abhishek, as you are using an undo tablespace and have already increased the time that undo data is retained via undo_retention then you might want to consider the following ideas which were useful with 1555 error under manual rbs segment management.
1- Tune the query. The faster a query runs the less likely a 1555 will occur.
2- Look at the processing. If a process was reading and updating the same table while committing frequenctly then the process under manual rbs management would basically create its own 1555 error rather than just being the victum of another process changing data and the rbs data being overlaid while the long running query was still running. With undo management the process could be generating more data than can be held for the undo_retention period but because it is committed Oracle has been told it doesn't really have to keep the data for use rolling back a current transaction so it gets discarded to make room for new changes.
If you find item 2 is true then separating the select from the update will likely eliminate the 1555. You do this by building a driving table that has the keys of the rows to be updated or deleted. Then you use the driver to control accessing the target table.
3- If the cause of the 1555 is or may be delayed block cleanout then select * from the target prior to running the long running query.
Realistically you might need to increase the size of the undo tablespace to hold all the change data and the value of the undo_retention parameter to be longer than the job run time. Which brings up back to option 1. Tune every query in the process so that the job run time is reduced to optimal.
HTH -- Mark D Powell --
dear mark
Thanks for the excellent advise..I found that the error is coming because of frequent commits..which is item 2 as u righly mentioned ..
I think I need to keep a watch on the queries running , I was just trying to find the execution time for the queries..If there is any way to find the query duration without running a trace ..
regards
abhishek

Ora-1555

Similar Messages

Maybe you are looking for