ORA-1555

Similar Questions

• This is how a SELECT query fails with ORA-1555 occur?

  11 GR 2/RHEL 6.2

  I would like to know exactly how a SQL fails with error ORA-1555.

  Please take a look at the following simple example.

  INVENTORY_DETAIL is a table that stores information about items in a store.

  For this DB UNDO_RETENTION is set to 3 600 (1 hour) and TUNED_UNDO_RETENTION Meanwhile 5400 (1.5 hours)

  At 15:00, there's 12 Logitek involved in inventory.

  ITEM_ID NOM_ELEMENT STOCK_LEFT

  --------- -------------------- ----------

  8432 LOGITEK 12 SPEAKER

  At 15:00 Session1, starts a SELECT large with several tables joins query. Something like

  Select id.item_id, id.item_name, su.supplier_price, su.supplier_code

  Su.batch_code...
  

  of INVENTORY_DETAIL id join in-house suppliers knew on (id.supplier_id = su.supplier_id)

  ...

  ..

  03:02, Session1 reads the block that stores the line with item_id = 8432 and learns that he has 12 Logitek left speakers.

  15:10, Session2 delivers the next UPDATE and he agrees immediately.

  Update inventory_detail set stock_left = 7 where item_id = 8432;

  commit;

  The UNDO data for Session2 transaction are stored in the measure of cancellation remaining, and the UNDO data gets debusquees at 04:40 when the TUNED_UNDO_RETENTION of 1.5 hours is crossed at 16:40.

  Because of the bad of e/s, query SELECT of Session1 manages to retrieve all the records only from 17:00.

  But session1 notice this line with item_id = 8432 changed. Now, there's only 7 Logitek speakers which is inconsistent with what he learned at 15:02 (who was then at 12). Because of this incompatibility SO not able to recover data UNDO on this gap, ORA-1555 is thrown. My assumptions are good?

  3:10PM                             4:10PM                          4:40PM                       5:00PM

  |===================================|-------------------------------|-----------------------------|

  UNDO_RETENTION = 1 HR retention Undo Tuned = 1.5 h finishes of request for enforcement

  Martin, you asked, "are the correct on the circumstances that led to ORA-1555 my explanations?  The answer is no.  Oracle does not notice at the end of the query that changed a line he read.  Instead, each read line is at the same point in time.  When Oracle sees that a row has changed Oracle reads the UNDO segments to find the version of the data corresponding to the query start time.  If these data cannot be found the ORA-01555 error is raised.

  - -

  HTH - Mark D Powell.

• ORA-1555 metalink Note

  Steps to follow:

  1 session 1 begins the query at time T1 and QENV 50

  2 session 1 selects the B1 block in this query

  3 session 1 updates the block at SNA 51

  4 session 1 performs another work which generates information restoration.

  5 session 1 commits the changes to ' 3 'and ' 4' step.

  (Now other transactions are free to crush this rollback information)

  6 1 session revisits the same block B1 (perhaps for a different line).

  Now, Oracle can see the header of the block that it has been changed and it is

  later than the necessary QENV (which was 50). That's why we need to get a picture of the

  block it from this QENV.

  If a fairly old version of the block are in the buffer cache then we

  It will use the case, we need to restore the current block generate a new one

  version of the block as to the necessary QENV.

  It is under this condition that Oracle may not being able to get the needed

  Restore information because changes in Session 1 were generated to restore information which

  has crushed it and return the error ORA-1555.

  Q: in step 6 If session 1 revisits the same block then its should be at SNA 51 then why it requires older block Yvert (YVERT 50). Not able to unserstand point 6.

  Delete and update q also get ora-1555 error?

  That note MetaLink are you referring to?  There are a number of remarks on the ORA-01555.  Please specify the ID of Note/Article/Document.

  This case resembles a Fetch through commit.  The session opened a cursor in step 1 time T1.  This cursor is always opened in step 6.  He did not start a new query, but still running the same query, looking for another line in the same block.  So, he needs a consistent read version of the cursor at the moment when it opened - that is to say the time T1.  If he is unable to build a coherent picture, it triggers an ORA-01555.

  You can search "Search through committing".

  Hemant K Collette

• ORA 1555 - snapshot to old when querying on a DB link

  Hi guys,.
  
  I have a difficult question for you. I'm not an expert of the Oracle and I have a problem with a production database, when executing a query via a link DB - ORA - 1555 snapshot to the former, we met. The query does not take too long, it ends normally taking less than a second. The error occur only at the weekend, when the application does not have a lot.
  
  From what I've read, Oracle creates a distributed transaction and holds an entry in the rollback segment when querying on a DB connection - please see http://www.jlcomp.demon.co.uk/faq/dblink_commit.html
  
  I have reproduced this error on the test server by reducing the size UNDO_TABLASPACE and UNDO_RETENTION 5 minutes.
  
  Now, I'm trying to fix it. The only solution I have right now is to run a COMMIT operation after every query that uses a DB_LINK. It does not concern a very nice difficulty, it's more a hack.
  
  Do you know a better solution? Should not be distributed transaction oracle creates automatically for that matter. We just query this database, we never insert/update / delete data.
  
  I tried SET TRANSACTION READ ONLY, does not help, the transaction is created.
  
  Thank you very much!

  982257 wrote:
  Hi guys,.

  I have a difficult question for you. I'm not an expert of the Oracle and I have a problem with a production database, when executing a query via a link DB - ORA - 1555 snapshot to the former, we met. The query does not take too long, it ends normally taking less than a second. The error occur only at the weekend, when the application does not have a lot.

  From what I've read, Oracle creates a distributed transaction and holds an entry in the rollback segment when querying on a DB connection - please see http://www.jlcomp.demon.co.uk/faq/dblink_commit.html

  I have reproduced this error on the test server by reducing the size UNDO_TABLASPACE and UNDO_RETENTION 5 minutes.

  Now, I'm trying to fix it. The only solution I have right now is to run a COMMIT operation after every query that uses a DB_LINK. It does not concern a very nice difficulty, it's more a hack.

  No, this is not a hack, it is the right solution. When you open a db link it starts a transaction on the remote database, and t hat transaction needsto be completed before the db connection can be closed. As long as the transaction remains open entry into the segment (undo segment these days) cancellation is required and cannot be released as a result of the 1555. If you do not commit after a select statement, you can always restore :-)

  Do you know a better solution? Should not be distributed transaction oracle creates automatically for that matter. We just query this database, we never insert/update / delete data.

  I tried SET TRANSACTION READ ONLY, does not help, the transaction is created.

  Thank you very much!

  You won't have the distributed transaction, but Oracle does.

  John

• Exclude the montitoring ORA-1555.

  Hello
  I am in the SGD 10.2.0.4 and 10.1.0.4 as repository DB.
  And I wonder if we can exclude some errors ORA-monitored.
  Particularly, that I'm not interested ora-1555 :).
  Kind regards.
  Greg

  When the "metric and policy setting"-online Edit Advanced Settings: generic alert "error log"I would change the existing"
  "Expression of alert log filter" of

  .*ORA-0*(54|1142|1146)\D.*

  TO

  .*ORA-0*(54|1555|1142|1146)\D.*

  At least this is the way I understand this logic :-)
  Even if I can't try it in our environment, it could be a value that give you it a try in your environment...

• ORA-1555 details

  Hi all;
  
  I want to get the details of the session of the user who is responsible for the query causing ORA-01555
  I can't leave my alert log file as it has been deleted.

  Hello
  Tom kyte link below has the answer to your query. Check in the test database.

  http://asktom.Oracle.com/pls/asktom/f?p=100:11:0:P11_QUESTION_ID:40115659055475

  Best regards

  Rafi.
  http://rafioracledba.blogspot.com/

• ORA-01555

  Hi exports.
  
  I get the following error in my database...
  
  
  ORA-31693: Data Table object 'ORISSA_TRANSACTION '. "' SELLER_BIOMETRICS_TBL ' failed to load/unload and being ignored because of the error:
  ORA-02354: Error exporting/importing data
  ORA-01555: snapshot too old: rollback segment number 140 with the name ' _SYSSMU140$ ' too small
  06-02-2013 02:58:14.090
  ORA-31693: Data Table object 'ORISSA_TRANSACTION '. "' BUYER_BIOMETRICS_TBL ' failed to load/unload and being ignored because of the error:
  ORA-02354: Error exporting/importing data
  ORA-01555: snapshot too old: rollback segment number 232 with the name ' _SYSSMU232$ ' too small
  
  
  Here is my SETUP to cancel...
  
  
  SQL > set line 180 pages 400
  SQL > show Cancel parameter
  
  VALUE OF TYPE NAME
  ------------------------------------ ----------- ------------------------------
  UNDO_MANAGEMENT string AUTO
  UNDO_RETENTION around 5400
  undo_tablespace string UNDOTBS1
  SQL >
  
  Improve undo_retention parameter...
  
  Please suggest the solution...
  
  
  Concerning
  ASIT

  See the MOS notes:
  "ORA-01555" snapshot too old: rollback segment %s with name \"%s\ number ' too small ' [ID 1555.1]
  Note to master to find errors ORA-1555 [ID 1307334.1]

• "ORA-01555: snapshot too old" during the cursor loop

  Hello
  
  I have a procedure which loop the records in a table, extracted SQL stored in one of the fields and execute it. In addition, it updates the State of education.
  Here is the code in the procedure.
  
  PROCEDURE RunStatements (inType IN NUMBER) IS
  -Declaration of the cursor:
  CURSOR cur_stmt (vType NUMBER) IS
  SELECT stmt_id, status, sql_stmt
  OF Stmts
  WHERE stmt_type = vType
  ORDER BY stmt_order;
  BEGIN
  
  -loop and run the statements:
  FOR r IN cur_stmt (inType) LOOP
  -updates the State
  UPDATE stmt
  SET status = 'On '.
  WHERE stmt_id = r.stmt_id;
  COMMIT;
  -running the SQL
  EXECUTE IMMEDIATE r.sql_stmt;
  COMMIT;
  -updates the State
  UPDATE stmt
  SET status = 'Off '.
  WHERE stmt_id = r.stmt_id;
  COMMIT;
  END LOOP;
  
  END;
  
  To parallelize the execution of the instructions, they are divided into two types: type 1 and type 2. The procedure is called via DBMS_JOB twice:
  
  Job 1:
  call RunStatements (1)
  Job 2:
  call RunStatements (2)
  
  The two executions of the procedure are running simultaneously for about 3 hours at night. Everything was OK until last week when an error began to occur every day.
  
  Here's the problem:
  
  One of the instructions is executed very long - around 1.5 hours. Successfully around 20 M, it inserts records into a table. However, after his arrival, Oracle triggers the following error:
  ORA-01555: snapshot too old: rollback segment number 7 with the name ' _SYSSMU7$ ' too small
  This error is issued after that Oracle is trying to retrieve the record next to the slider.
  After that I will carry out the rest of the statements manually and there is no problem.
  
  Oracle lost somehow, information about data in the cursor!
  
  Can someone help me understand why this is happening? Is it possible that the long running operation consumes the space reserved for the cursor? Is it possible that after a certain period of time without fetch all the records Oracle decides you don't need the cursor? Is it possible that the error is caused by using two identical slider?
  
  I tried to increase the tablespace UNDO as stated in some articles, but the error continues to appear.
  
  Any help will be appreciated. We are in production and I have to wake up every morning at 04:00 to start manually non-executed statements.
  
  Database: Oracle 10 g 2
  OS: Enterprise Linux RH
  
  Thank you in advance.
  
  Best regards
  Beroetz

  The reading consistency mechanism, this is what triggers the ORA-1555. We will try to explain what is happening:

  -T0, you open the slider. This locks "full" all the time the extraction will be requested (all read lines will be "full" t0). Note that Oracle does not have a copy of data of the cursor. When you check out lines, Oracle will read them disk/memory for now, ask you, not before (it will logically build the image in t0 if data has been changed since).

  -At t1, you update the validation and the stmt. When you retrieve a line of the cursor after t1, Oracle will see stmt has changed since t0 and logically will build the data as it was at t0, using the rollback segment information.

  ...
  time passes
  ...

  -To the t2 (2 hours after t0), you get a new line of the cursor. Oracle attempts to logically reconstruct the data as it was at t0, but information was crushed in the rollback segment. Oracle may come back in time indefinitely. The setting for the withholding of information of cancellation you defined is too low.

  You can either increase the retention time (undo_retention), it will have the effect to say Oracle: "wait longer before overwriting the cancellation information so that I can query the data to an earlier point in time. Or you can 'save cursor data' yourself, read all the lines, while you can (as before).

  I hope that this will help you understand why you get this error.

• Error connecting to vCenter Server

  After that a sudden loss of power I got the following error trying to connect to vcenter server:

  Internal server error

  2013-05-15 17:47:44, 772 | DEBUG | 23b4fe43-1f29-4c6f-adc1-1048b2a8845cListener (260). JobManager | Add the activity log: JOB_VC_START
  _CONNECTION > < cloudvcs0(com.vmware.vcloud.entity.vimserver:23b4fe43-1f29-4c6f-adc1-1048b2a8845c) > |
  2013-05-15 17:47:44, 773 | DEBUG | 23b4fe43-1f29-4c6f-adc1-1048b2a8845cListener (260). CJob                           | updateFailedJob (com.vmware.vcloud.ap
  i.presentation.service.InternalServerErrorException) with locale = null |
  com.vmware.vcloud.api.presentation.service.InternalServerErrorException: internal server error
  at com.vmware.vcloud.vimproxy.internal.impl.VcUpdateListenerImpl.onOuterLoopBreakWithException(VcUpdateListenerImpl.java:721)
  at com.vmware.vcloud.vimproxy.internal.impl.VcUpdateListenerImpl.outerWaitForUpdatesLoop(VcUpdateListenerImpl.java:633)
  at com.vmware.vcloud.vimproxy.internal.impl.VcUpdateListenerImpl.run(VcUpdateListenerImpl.java:343)
  Caused by: org.hibernate.exception.GenericJDBCException: could not execute the query
  at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:126)
  at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:114)
  at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66)
  at org.hibernate.loader.Loader.doList(Loader.java:2231)
  at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2125)
  at org.hibernate.loader.Loader.list(Loader.java:2120)
  at org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:118)
  at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1596)
  at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:306)
  at com.vmware.vcloud.inventory.cache.PropertyMapDao.validateOrGet(PropertyMapDao.java:336)
  at com.vmware.vcloud.inventory.cache.PropertyMapDao.bulkValidateOrGet(PropertyMapDao.java:321)
  at com.vmware.vcloud.inventory.cache.PropertyMapDao.bulkValidateAndGetNewer(PropertyMapDao.java:267)
  at com.vmware.vcloud.inventory.cache.InventoryCacheManagerImpl.bulkGetInternal(InventoryCacheManagerImpl.java:418)
  at com.vmware.vcloud.inventory.cache.InventoryCacheManagerImpl.bulkGet(InventoryCacheManagerImpl.java:549)
  at com.vmware.vcloud.inventory.impl.InventoryServiceImpl.processUpdateSet(InventoryServiceImpl.java:931)
  to com.vmware.vcloud.inventory.impl.InventoryServiceImpl.access$ 300 (InventoryServiceImpl.java:145)
  to com.vmware.vcloud.inventory.impl.InventoryServiceImpl$ 5.run(InventoryServiceImpl.java:860)
  to com.vmware.vcloud.inventory.impl.InventoryServiceImpl$ 5.run(InventoryServiceImpl.java:826)
  at com.vmware.vcloud.common.persist.ConversationContextExecutor.execute(ConversationContextExecutor.java:46)
  at com.vmware.vcloud.inventory.impl.InventoryServiceImpl.processAndBatchUpdates(InventoryServiceImpl.java:826)
  at com.vmware.vcloud.inventory.impl.InventoryServiceImpl.handleUpdate(InventoryServiceImpl.java:799)
  at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
  at sun.reflect.NativeMethodAccessorImpl.invoke (unknown Source)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke (unknown Source)
  at java.lang.reflect.Method.invoke (unknown Source)
  at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)
  at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
  at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
  at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
  at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
  at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
  to $Proxy187.handleUpdate (Unknown Source)
  at com.vmware.vcloud.vimproxy.internal.impl.VcUpdateListenerImpl.dispatchUpdates(VcUpdateListenerImpl.java:1080)
  at com.vmware.vcloud.vimproxy.internal.impl.VcUpdateListenerImpl.innerWaitForUpdatesLoop(VcUpdateListenerImpl.java:925)
  at com.vmware.vcloud.vimproxy.internal.impl.VcUpdateListenerImpl.outerWaitForUpdatesLoop(VcUpdateListenerImpl.java:594)
  ... 1 more
  Caused by: java.sql.SQLException: ORA-01555: snapshot too old: rollback segment number with the name "" too small
  ORA-22924: snapshot too old

  at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:439)
  at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:388)
  at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:381)
  at oracle.jdbc.driver.T4C8TTILob.processError(T4C8TTILob.java:789)
  at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:436)
  at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:186)
  at oracle.jdbc.driver.T4C8TTILob.read(T4C8TTILob.java:146)
  at oracle.jdbc.driver.T4CConnection.getBytes(T4CConnection.java:2313)
  at oracle.sql.BLOB.getBytes(BLOB.java:319)
  at oracle.sql.BLOB.getBytes(BLOB.java:209)
  at oracle.jdbc.driver.T4CBlobAccessor.getBytes(T4CBlobAccessor.java:464)
  at oracle.jdbc.driver.OracleResultSetImpl.getBytes(OracleResultSetImpl.java:676)
  at oracle.jdbc.driver.OracleResultSet.getBytes(OracleResultSet.java:398)
  at org.hibernate.type.AbstractBynaryType.get(AbstractBynaryType.java:101)
  at org.hibernate.type.NullableType.nullSafeGet(NullableType.java:184)
  at org.hibernate.type.NullableType.nullSafeGet(NullableType.java:173)
  at org.hibernate.type.AbstractType.hydrate(AbstractType.java:105)
  at org.hibernate.persister.entity.AbstractEntityPersister.hydrate(AbstractEntityPersister.java:2124)
  at org.hibernate.loader.Loader.loadFromResultSet(Loader.java:1404)
  at org.hibernate.loader.Loader.instanceNotYetLoaded(Loader.java:1332)
  at org.hibernate.loader.Loader.getRow(Loader.java:1230)
  at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:603)
  at org.hibernate.loader.Loader.doQuery(Loader.java:724)
  at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:259)
  at org.hibernate.loader.Loader.doList(Loader.java:2228)
  ... 32 more
  2013-05-15 17:47:44, 774. DEBUG | 23b4fe43-1f29-4c6f-adc1-1048b2a8845cListener (260). JobString | Object - object: cloudvcs0 (com.
  name of the VMware.vCloud.Entity.vimserver:23b4fe43-1f29-4c6f-adc1-1048b2a8845c operation): JOB_VC_START_CONNECTION |
  2013-05-15 17:47:44, 842. DEBUG | 23b4fe43-1f29-4c6f-adc1-1048b2a8845cListener (260). CJob                           | Not the last pending work: [cloudvcs0 (c
  OM. (VMware.vCloud.Entity.vimserver:23b4fe43-1f29-4c6f-adc1-1048b2a8845c)], status [3] = |
  2013-05-15 17:47:44, 846. DEBUG | 23b4fe43-1f29-4c6f-adc1-1048b2a8845cListener (260). CJob                           | Last jobs update: [cloudvcs0 (c
  OM. (VMware.vCloud.Entity.vimserver:23b4fe43-1f29-4c6f-adc1-1048b2a8845c)], status = [3], [15/05/13 17:47] |
  2013-05-15 17:47:44: 964 | DEBUG | 23b4fe43-1f29-4c6f-adc1-1048b2a8845cListener (260). ValidationServiceImpl | Jump queuing of the validator for co
  validator of m.vmware.ssdc.backend.valeventhandler.ProviderVdcVALStateValidator since it is a duplicate, current validation queue length: 1 |
  2013-05-15 17:47:44, 966 | INFO | 23b4fe43-1f29-4c6f-adc1-1048b2a8845cListener (260). InventoryServiceImpl | Reception earphone stopped for VC 23 b
  4fe43-1f29-4c6f-adc1-1048b2a8845c |
  2013-05-15 17:47:44, 966 | WARN | 23b4fe43-1f29-4c6f-adc1-1048b2a8845cListener (260). InventoryRecordPurger | Records of the inventory for 23b4fe4 trap
  3 1f29-4c6f-adc1-1048b2a8845c is not active.
  2013-05-15 17:47:44, 968 | INFO | 23b4fe43-1f29-4c6f-adc1-1048b2a8845cListener (260). VcUpdateListenerImpl | Releasing the proxy property of VC
  23b4fe43-1f29-4C6F-ADC1-1048b2a8845c |
  2013-05-15 17:47:44, 968 | INFO | 23b4fe43-1f29-4c6f-adc1-1048b2a8845cListener (260). VcUpdateListenerImpl | trying to clear the instance of cell id on
  VC 23b4fe43-1f29-4c6f-adc1-1048b2a8845c (current number of retries to 0). |
  2013-05-15 17:47:44, 969 | INFO | 23b4fe43-1f29-4c6f-adc1-1048b2a8845cListener (260). VcUpdateListenerImpl | 23b4fe43-1f29-4c6f-adc1-1048b2a88 VC
  45 c: attempt to set the instance id of cells from 70 to 0.

  Caused by: java.sql.SQLException: ORA-01555: snapshot too old: rollback segment number with the name "" too small

  ORA-22924: snapshot too old

  I found these two articles in the KB:

  VMware KB: The vCloud Director Web UI reports the error: ORA-01555: snapshot too old: rollback number with n segment...

  VMware KB: Make sure that you have adequate undo tablespace before upgrading a vCloud Director Oracle database

  I added more space for the undo tablespace, new redologs, also change the setting of retention for all LOB in the vCloud regime without a different result.

  Anyone have any idea on this?

  Best regards

  I finally had an answer for the Oracle error.

  I did a full export of the vcloud database and detect an error in this table:

  ORA-31693: Table object "VCLOUD" data "" PROPERTY_MAP "impossible to load/unload and being ignored because of the error:

  ORA-02354: Error exporting/importing data

  ORA-01555: snapshot too old: rollback segment number with the name "" too small

  ORA-22924: snapshot too old

  This OPINION score details this condition:

  Export fails with ORA-2354 ORA ORA-1555-22924 errors and how to confirm the Corruption of the LOB Segment using the export utility? [833635.1 ID]

• Redo log sizing

  Hi all
  
  OEL 5.6
  
  Oracle 9.2.0.6
  
  Are just my recovery for his number and connects the size based on the delay time of switching? Thank you
  

  -rw-r--r-- 1 oraprod dba    10486272 Jan  3 23:24 log01a.dbf
  -rw-r--r-- 1 oraprod dba    10486272 Jan  3 23:24 log01b.dbf
  -rw-r--r-- 1 oraprod dba    10486272 Jan  3 23:09 log02a.dbf
  -rw-r--r-- 1 oraprod dba    10486272 Jan  3 23:09 log02b.dbf

  In the alerts log switching frequency:
  

  Beginning log switch checkpoint up to RBA [0x21186.2.10], SCN: 0x056e.66a6d05f
  Thread 1 advanced to log sequence 135558
    Current log# 1 seq# 135558 mem# 0: /u02/oracle/oaproddata/log01a.dbf
    Current log# 1 seq# 135558 mem# 1: /u02/oracle/oaproddata/log01b.dbf
  Thread 1 cannot allocate new log, sequence 135559
  Checkpoint not complete
    Current log# 1 seq# 135558 mem# 0: /u02/oracle/oaproddata/log01a.dbf
    Current log# 1 seq# 135558 mem# 1: /u02/oracle/oaproddata/log01b.dbf
  Wed Jan  2 20:37:01 2013
  Completed checkpoint up to RBA [0x21186.2.10], SCN: 0x056e.66a6d05f
  Wed Jan  2 20:37:01 2013
  Beginning log switch checkpoint up to RBA [0x21187.2.10], SCN: 0x056e.66a6d5e4
  Thread 1 advanced to log sequence 135559
    Current log# 2 seq# 135559 mem# 0: /u02/oracle/oaproddata/log02a.dbf
    Current log# 2 seq# 135559 mem# 1: /u02/oracle/oaproddata/log02b.dbf
  Thread 1 cannot allocate new log, sequence 135560
  Checkpoint not complete
    Current log# 2 seq# 135559 mem# 0: /u02/oracle/oaproddata/log02a.dbf
    Current log# 2 seq# 135559 mem# 1: /u02/oracle/oaproddata/log02b.dbf
  Wed Jan  2 20:37:07 2013
  Completed checkpoint up to RBA [0x21187.2.10], SCN: 0x056e.66a6d5e4
  Wed Jan  2 20:37:07 2013
  Beginning log switch checkpoint up to RBA [0x21188.2.10], SCN: 0x056e.66a6e3f2
  Thread 1 advanced to log sequence 135560
    Current log# 1 seq# 135560 mem# 0: /u02/oracle/oaproddata/log01a.dbf
    Current log# 1 seq# 135560 mem# 1: /u02/oracle/oaproddata/log01b.dbf
  Wed Jan  2 20:37:18 2013
  Thread 1 cannot allocate new log, sequence 135561
  Checkpoint not complete
    Current log# 1 seq# 135560 mem# 0: /u02/oracle/oaproddata/log01a.dbf
    Current log# 1 seq# 135560 mem# 1: /u02/oracle/oaproddata/log01b.dbf
  Wed Jan  2 20:37:18 2013
  Completed checkpoint up to RBA [0x21188.2.10], SCN: 0x056e.66a6e3f2
  Wed Jan  2 20:37:18 2013
  Beginning log switch checkpoint up to RBA [0x21189.2.10], SCN: 0x056e.66a6f0a4
  Thread 1 advanced to log sequence 135561
    Current log# 2 seq# 135561 mem# 0: /u02/oracle/oaproddata/log02a.dbf
    Current log# 2 seq# 135561 mem# 1: /u02/oracle/oaproddata/log02b.dbf
  Wed Jan  2 20:40:14 2013
  Completed checkpoint up to RBA [0x21189.2.10], SCN: 0x056e.66a6f0a4
  Wed Jan  2 20:40:53 2013
  Beginning log switch checkpoint up to RBA [0x2118a.2.10], SCN: 0x056e.66a70cb2
  Thread 1 advanced to log sequence 135562
    Current log# 1 seq# 135562 mem# 0: /u02/oracle/oaproddata/log01a.dbf
    Current log# 1 seq# 135562 mem# 1: /u02/oracle/oaproddata/log01b.dbf
  Wed Jan  2 20:43:24 2013
  Completed checkpoint up to RBA [0x2118a.2.10], SCN: 0x056e.66a70cb2

  And also I see frequently repeated ORA-1555 on the same statement in the alerts log, how can I avoid this?
  Is this cause also of small redo logs?
  

  Beginning log switch checkpoint up to RBA [0x211b2.2.10], SCN: 0x056e.70580afc
  Thread 1 advanced to log sequence 135602
    Current log# 1 seq# 135602 mem# 0: /u02/oracle/oaproddata/log01a.dbf
    Current log# 1 seq# 135602 mem# 1: /u02/oracle/oaproddata/log01b.dbf
  Wed Jan  2 21:26:14 2013
  Completed checkpoint up to RBA [0x211b2.2.10], SCN: 0x056e.70580afc
  Wed Jan  2 21:26:16 2013
  ORA-01555 caused by SQL statement below (Query Duration=2913 sec, SCN: 0x056e.66a6f853):
  Wed Jan  2 21:26:16 2013
   INSERT INTO RA_INTERFACE_ERRORS
   (INTERFACE_LINE_ID,
    MESSAGE_TEXT,
    INVALID_VALUE)
  SELECT
  INTERFACE_LINE_ID,
  :b_err_msg6,
  'trx_number='||T.TRX_NUMBER||','||'customer_trx_id='||TL.CUSTOMER_TRX_ID
  FROM RA_INTERFACE_LINES_GT IL, RA_CUSTOMER_TRX_LINES TL, RA_CUSTOMER_TRX T
  WHERE  IL.REQUEST_ID = :b1
  AND    IL.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY'
  AND    T.CUSTOMER_TRX_ID =TL.CUSTOMER_TRX_ID
  AND  IL.INTERFACE_LINE_CONTEXT = TL.INTERFACE_LINE_CONTEXT
  AND IL.INTERFACE_LINE_ATTRIBUTE1 = TL.INTERFACE_LINE_ATTRIBUTE1
  AND IL.INTERFACE_LINE_ATTRIBUTE2 = TL.INTERFACE_LINE_ATTRIBUTE2
  AND IL.INTERFACE_LINE_ATTRIBUTE3 = TL.INTERFACE_LINE_ATTRIBUTE3
  AND IL.INTERFACE_LINE_ATTRIBUTE4 = TL.INTERFACE_LINE_ATTRIBUTE4
  AND IL.INTERFACE_LINE_ATTRIBUTE5 = TL.INTERFACE_LINE_ATTRIBUTE5
  AND IL.INTERFACE_LINE_ATTRIBUTE6 = TL.INTERFACE_LINE_ATTRIBUTE6
  AND IL.INTERFACE_LINE_ATTRIBUTE7 = TL.INTERFACE_LINE_ATTRIBUTE7
  AND IL.INTERFACE_LINE_ATTRIBUTE8 = TL.INTERFACE_LINE_ATTRIBUTE8
  AND IL.INTERFACE_LINE_ATTRIBUTE9 = TL.INTERFACE_LINE_ATT
  Wed Jan  2 21:26:22 2013
  Beginning log switch checkpoint up to RBA [0x211b3.2.10], SCN: 0x056e.7062ba10
  Thread 1 advanced to log sequence 135603
    Current log# 2 seq# 135603 mem# 0: /u02/oracle/oaproddata/log02a.dbf
    Current log# 2 seq# 135603 mem# 1: /u02/oracle/oaproddata/log02b.dbf
  Wed Jan  2 21:26:22 2013

  How can I configure management automatic cancellation in 9i?
  
  Thank you

  If UNDO_RETENTION has no impact on the ORA-01555 error, this error message you will get in this scenario?

  UNDO_RETENTION = 1800
  Query running time = 1900

  Works SQL and requires a block of data to read cancellation that has been updated there are 1900. Meanwhile, other users are using the system and the cancellation expired (anything above 1800) was crushed. User request will be error, and I would say that this will be an ORA-01555? Correct me if I'm wrong.

  As pointed out by bby Viswarayar Maran, your UNDO_RETENTION must be on the longer duration of the query. It's what he's there for. Yes, it can happen when you commit inside a loop, but it may happen in this case, too, I think.

  Actions:

  1 increase the size of REDO logs
  2. take another report statspack for the same period of time on a comparable day (in terms of workload, running processes, etc.) and see what it looks like

  Question: Your statspack report is from 22:00 - midnight, what are your pics to load? You have a working window batch during the night which is and then charge during the day? If so, we will need to look at this time for the statspack report, too.

• Undo tablespace full

  Hi all
  
  OS: Solaris
  DB: 10 G
  
  My undotablespace had a lot, I should directly resize it or is there something else I should do first?
  One last thing, if I take the bounce of the database, this will affect cancel it?
  
  Kind regards
  Sphinx

  If you have room for an other undo tablespace, why not make one you have more? Don't forget, one will not be removed until all transactions using this are made.

  There are a few reasons you may need more to cancel the space: you have people leaving the open sessions, you have poor code that uses too or shot himself in the foot, stand too close, autoextend to cancel gourmand or you really need the space.

  Tom Kyte has recommended to keep enough space around it for annual transactions of large batch if you have those. Unfortunately, this means that you do not have the other stuff stupid user. I take an intermediate point of view, keeping a great cancel (it is about half of my db), even though it is barely used most of the time and kill sessions where I can determine that they should not be left open (in other words, people who rarely run stuff from one day to the next day to ask, since most people don't).

  What are the exact errors are you seeing? If this is the code that self-destructs in the foot, no matter how cancel it y a. search for ora-1555 on asktom if that's what you see. What's your retention, what is your guarantee?

• May complete transaction undo tablespace of long duration.

  Hello
  Let's say we're on 9.2.0.8 and long duration of the transaction, I mean, we started some update (1 row only but no commit / rollback) and do nothing for a few days.
  If the amount of the cancellation is minimal, but we wanted to cancel used slot and 1 cancellation transaction table entry.
  Is this some sort of dangerous? AFAIK undo is circular buffer type so set us an upper end and prevent the new transaction to use "low".
  Please provide details. I noticed that a few GUI related situation cancel 100% full, don't know if that's ok.
  Concerning
  GregG

  GregG says:
  And you think more, could you tell how to solve this problem, I mean, how do you know that we are getting near disaster (ora-1555 or cancel saturated), the long-running transaction is taken only 1 unregister
  so doesn't sound dangerous.

  I think that you could read the following blog post: http://jonathanlewis.wordpress.com/2009/10/07/undone/

  Concerning
  Jonathan Lewis

• Error starting OPP

  Hi all
  
  Apps 11i
  ORA 9i
  
  Our OPP have problems at startup. The log manager internal is "error occurred during initialization of VM".
  Could not reserve enough space for lots of things. "
  
  Can you please help...
  
  Thank you

  ORA-01555 caused by the following SQL statement (query length s = 1308626585, SCN: 0x056d.b3a94c87):
  ORA-01555 caused by the following SQL statement (query length s = 1308626786, SCN: 0x056d.b3a96a6a):
  ORA-00600: internal error code, arguments: [504], [0x50042D6C], [160], [7] [pool], [1], [0], [0x50042E34]
  ORA-00600: internal error code, arguments: [504], [0x50042D6C], [640], [7] [pool], [1], [0], [0x50042E34]

  ORA-1652: unable to extend temp by 16 segment in tablespace APPS_TS_TX_DATA
  ORA-1652: unable to extend temp by 16 segment in tablespace TEMP

  How can I add rollback segments in 9i? I am now confused with the addition of the restorations in 9i, 10g, 11g, because I know that the latest is now automated.

  I have to add more to my TEMP datafile?

  You need to add more space to the tablespace APPS_TS_TX_DATA and TEMP.

  OERR: ORA 1652 cannot extend segment temp by %s in %s [19047.1 ID] tablespace

  How to avoid lock?

  How to avoid the ORA-0600

  Fix the error ORA-1652 first, then see if you get the error ORA-01555 and ORA-00600.

  In case you still get that same error (ORA-01555 and ORA-00600) please refer:

  Note to master to find errors ORA-1555 [ID 1307334.1]
  "ORA-01555" snapshot too old: rollback segment %s with name \"%s\ number ' too small ' [ID 1555.1]
  Error ORA-600/ORA-7445 look-up Tool [ID 153788.1]

  Thank you
  Hussein
  Thank you
  Hussein

• Snapshot too old?

  Hello
  
  The user has updated a block but have not committed for a long time. The old value is now available in the segment of cancellation (with small undosegment). After a few hours the cancellation of the user has update block.
  Here if the old value in the undosegment is crushed or restores user successfully? and on what scenario user A gets snapshot too old?
  
  Thank you
  KSG

  Cancellation information written by 'A' are not replaced by anyone (that it either ' A' or 'B' or 'C' or 'Z' or 'SYS') until and unless "A" issued a COMMIT or ROLLBACK.

  A 'snapshot too old' isn't about writing or maintaining information for cancellation as SQL but on the cancellation read that was written by an information
  a. another user/session
  b. another transaction (by the same user/session or another user/session)
  c. a validation has been issued in a cursor and the cursor remains open to maintain a coherent picture of reading.

  (There are a few other cases: crushed Undo segment slot, entrance ITL crushed etc.).

  Do not confuse the written cancellation for a Transaction with cancellations which must be read. The cancellation of 'writing' can generate error "Unable to allocate the measure" If the undo tablespace does not have space for the growing rollback segment. The "read" can generate an ORA-1555, if the information is no longer available for playback.

  Hemant K Collette
  http://hemantoracledba.blogspot.com

• relationship between the size of tablepsace undo_retention and cancel

  Hello, I'm on 10.2.0.3.
  Can someone please delete this things a little more.
  Let's say I have a SQL that inserts or updates and this time of execution of 30 minutes,
  and my undo_retention is set to 20mins, undo_management = auto and undo tablespace of 30 GB which is currently only 1 GB,
  This insert will fail with ora-1555 snapshot too old or not?
  Is undo_retention the only thing that determines how long query can be executed or I can focus on the size of the undo tablespace also if there is enough space inside?

  Exact