Ora- 1555 errors

hi guys,
if i get for example :
ORA-01555 caused by SQL statement below (SQL ID: dxswvyyhkkg43, *Query Duration=2347 sec*, SCN: 0x0915.5ce46fff):and my ->
NAME TYPE VALUE
undo_retention integer 900I can safely said that my query time is NOT well within the configured undo retention period?

flaskvacuum wrote:
I can safely said that my query time is NOT well within the configured undo retention period?Or you can say that the change vector of the data is well beyond the configured undo retention period. ;-)
The basic issue is that consuming the cursor versus the committed changes to the underlying data read by that cursor, is in conflict.
So it can be because the cursor is consumed too slowly. Could be that committed changes are coming in so thick and fast that read consistency for older versions of the data cannot be maintained very long. Could be an issue of shoddy code that is committing across fetching (an ANSI SQL violation too btw).
So it is not necessarily an undo retention period issue. Or a query time issue.

Similar Messages

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

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

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

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

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.

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

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.

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

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.

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 errors

Similar Messages

Maybe you are looking for