This document focuses on the solutions to “ORA-01555: snapshot too old”. The main note 185822 – ora-1555 – cause and action described the 3 reasons for this error. I believe it nicely has described the technical background.
However this document summarizes that note and add some more practical steps to analyse and fix the error. The error is shown mostly in the alert.log or system logs.
In all the cases you must identify whether the ORA-1555 has occurred with an UNDO or a LOB segment.
You can find this by looking at the error message. If the “rollback segment number” is not specified exactly (ex. null or “???”) then it is related to LOB segment, check the following document and blog instead for further analysis and solutions.
For undo management WITH LOB please refer to ORA-01555 with a LOB segment
Please refer to Oracle LOBs and undo management – Not as simple as I thought as well.
The following points are relevant for undo management WITHOUT LOB:
1- Check the undo related parameters and make sure you are using Automatic Undo Management (AUM).
AUM is introduced as of 9i and since the latest supported Oracle release is 11g by this time then it is strongly recommended
that this method is adopted.
Open the database parameters from DBACOCKPIT transaction code:
If you are using System Managed Undo (SMU) change it to auto. A restart will be needed after the change. In Oracle Real Application Clusters (RAC) all the instances must have the value ‘auto’.
But be careful the procedure is not so simple if you are migrating from rollback tablespace. Please find more information in note 600141 – Oracle9i: Automatic UNDO Management >> AUM – Migration procedure from MANUAL to AUTO Undo Management
2- The ORA-1555 errors might have happened because a query cannot access enough undo to build the before images. In that case check if the undo tablespace is large enough.
In the image above check undo_retention. That is the time in second for how long the before images should be kept. undo_retention can be set to the maximum run time of the longest query.
But be careful the system ignores the value set in the parameter UNDO_RETENTION for an undo tablespace without AUTOEXTEND. More information in note 1035137 – Oracle Database 10g: Automatic Undo Retention.
Open the space overview from DBACOCKPIT transaction code to find if the undo tablespace is autoextendable or not:
If AUTOEXTEND is set OFF for the undo tablespace then add a datafile to the tablespace. Use BRSPACE option for tablespace extension.
More information in http://scn.sap.com/docs/DOC-29484
3- There are cases when a specific query has been running for 2 or more days in that case the above steps might not be helpful, instead check the execution queries of the tables. Are there places for tuning the SQL statement with a new index or forcing a new execution plan?
4- Are the tables involved in the query very large? If yes, are there possibilities to delete older data? These must be answered from the application point of view.
5-Please note that under some circumstances there are some bugs which cause the ORA-1555.
Make sure you are on the latest patch level of the latest ORACLE release to prevent the already fixed bugs. Perform all the postinstallations of patch installation so that the bug fixes are counted.
6- If the ORA-1555 is occurring with a LOB segment then, the undo tablespace is NOT used for read consistency. Firstly you must check whether the before images is kept in the storage parameter PCTVERSION (used in manual undo management mode) or RETENTION (used in AUM). ONLY one method can be used. More information on 500340 – FAQ: LOBS
This query can be used to find which parameter is in use:
select PCTVERSION, RETENTION from dba_lobs where segment_name = ‘<lobsegment name>’ or TABLE_NAME = ‘<TABLE_NAME>’
** PCTVERSION determines the percentage of the lobsegment assigned to handle the undo management.
** RETENTION determined the period of time lobsegment will keep the before images (not the fixed percentage of space in the logsegment)
Check ORA-01555 with a LOB segment for more information.