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

Similar Messages

When will ora-01555 error not be recorded in alert file?

Application side repeatably gets ora-01555 error, but from alert log, there is no such error recorded. I recalled normally this error will be recorded, so under which condition we can't find this error in alert file?

You would get ORA-0155 on a LOB if
a) the LOB storage has been defined with PCTVERSION which is low (Oracle doesn't use Undo Segments but uses space in the LOB Segment itself and if this is inadequate for multiple updates, an ORA-0155 is raised, which is not really related to Undo Segments but the space in the LOB segment)
b) the LOB storage has been defined with RETENTION which is low
(Even if you increase undo_retention, you'd have to modify the LOB segment to PCTVERSION and then back to RETENTION for it to use the new undo_retention value).
See MetaLink Notes 162345.1, 66431.1 and 563470.1
Since the ORA-01555 error doesn't really relate to Undo segments, I believe that it would not be reported in the alert.log file -- but I haven't verified this.
Hemant K Chitale
http://hemantoracledba.blogspot.com

Does RULE hint cause ORA-01555 errors ?

DB Version:9.2.0.5.0
OS:SunOS 5.9
Our DBA is saying that the RULE hint in the below SQL might be causing ORA-01555 error. Is it true? Does RULE hint cause ORA-01555 errors
SELECT /*+ RULE */ COUNT(*)
FROM ( SELECT /*+ RULE */ DISTINCT CAR_HDR.CAR_NBR AS A1, CAR_HDR.PLT_ID AS A29,
CAR_HDR.PKT_CTRL_NBR AS A2, CAR_HDR.TOTAL_QTY AS A21, CAR_HDR.STAT_CODE AS A6,
CAR_HDR.CURR_LOCN_ID AS A12,
CAR_HDR.CAR_NBR AS A145,
CAR_HDR.WN_NBR AS A4, CAR_HDR.PCALL_NBR AS A7, CAR_HDR.CHAIN_CNT AS A119,
CAR_HDR.SHPMT_NBR AS A35, LPN_HDR.WHSE AS A105, CAR_HDR.MISC_CAR AS A146, '' AS A138,
CAR_HDR.CHUTE_ID AS A132, CAR_HDR.MOD_DATE_TIME AS A82, LPN_HDR.LOCN_CLASS AS A106,
LPN_HDR.AREA AS A107, LPN_HDR.ZONE AS A108, LPN_HDR.AISLE AS A109, LPN_HDR.BAY AS A110,
LPN_HDR.LVL AS A111, LPN_HDR.POSN AS A112
      FROM INV_MASTER , CAR_DTL , LPN_HDR , CAR_HDR
       WHERE CAR_HDR.CAR_NBR=CAR_DTL.CAR_NBR(+)
       AND CAR_HDR.CURR_LOCN_ID=LPN_HDR.LOCN_ID(+)
       AND CAR_HDR.WHSE=LPN_HDR.WHSE(+)
       AND CAR_DTL.SKU_ID=INV_MASTER.SKU_ID(+)
       AND CAR_HDR.CT_SEQ = 'ALB10'
       AND INV_MASTER.INV_CODE = 98
       AND INV_MASTER.TRACK_CODE = 'P10' )


user636669 wrote:
DB Version:9.2.0.5.0
OS:SunOS 5.9
Our DBA is saying that the RULE hint in the below SQL might be causing ORA-01555 error. Is it true? Does RULE hint cause ORA-01555 errorsThe full statement is causing the ORA-01555 error. Each line of the statement is important therefore each line is reponsible for the error. I personally think the DISTINCT keyword has a bigger influence than the RULE hint.
I suggest to check what you want to do with that count result. maybe there are better ways to get the same result. Maybe you can even ignore the distinct keyword or remove some outer joins. Using the CBO might result in the same plan as using the RBO, so you you will never know if that removing the hint will help or if if you'll get the same problem later again.

ORA-01555 error when assigning values based on geometry

Hello,
I have a table with 220,000+ records with street information, and I am trying to assign a municipal area (stored in another table) based on the geometry of the road line and the geometry of the municipal boundary.
CREATE TABLE TEMP AS SELECT A.ID, B.AREA FROM ROADS A, PLACES B WHERE B.TYPE IN (33,35,36,37) AND mdsys.sdo_relate (a.geometry,b.geometry,'
mask=inside querytype = window')='TRUE';
This took a long time to run and it came back with a series of errors, one of which was ORA--01555 'snapshot too old'. I was running other queries on the table (in a separate SQL window) because I'm under a deadline, so i figured that doing multiple things at one time while the spatial query was running was causing the problem. I didn't have time to run it again (it was the end of the day when the error came up, conveniently) so I am trying to work out a solution to this issue.
Would it be better if I: a) ran the statement again on the whole dataset and did nothing else while it is running, even though it will still take a while, or
b) broke it up into groups of 50,000 records and run the statement on one group at a time and hope for the best.
Thanks in advance!

Assuming you have less municipal areas than roads, the query should perform better by specifying the join order:
CREATE TABLE TEMP AS (
     SELECT /*+ ORDERED */ A.ID, B.AREA
     FROM PLACES B, ROADS A
     WHERE B.TYPE IN (33,35,36,37)
     AND mdsys.sdo_relate (a.geometry, b.geometry,'mask=inside querytype = window') = 'TRUE');Also, are you sure 'inside' is the right mask to use here? What if a road intersects the edge of the municipality? In that case it wouldn't be returned by this query.

Help to produce an ora-01555 error.

Hello all,
I've been gotten wind of about UNDO management, but I'm not able to reproduce an ora-01555. I tried one way that I found in some metalink notes but I didn't succeed. I know that using some PL/SQL statements I get there, but how can I achieve it?
I appreciate your help.
Thanks in advance,
Regards,
Emerson

Easy to reproduce. Just use flashback query to an SCN that has aged out of undo.
E.g
SQL> select object_id from test as of scn 5936742 where object_id = 20;
select object_id from test as of scn 5936742 where object_id = 20
ERROR at line 1:
ORA-01555: snapshot too old: rollback segment number 6 with name
"_SYSSMU6_2443381498$" too smallAnother option is to reduce undo retention, shrink the undo tablespace and turn off autoextend. Then in one session run a long select, and in another session run a loop with an update and a commit.
E.g
begin
for i in 1..10000 loop
update test set object_id = object_id where object_id = 20;
commit;
end loop;
end;
/

ORA-01555 error, snapshot too old

I am getting this error message trying to run a report:
ORA-01555 snapshot too old: rollback segment number 4 with name "R03" too small.
No report generated.
Any help to correct the problem would be much appreciated.
null

You need to contact your DBA and ask him to tune the rollback segments or tune up your query. You need a larger rollback segment to run your report query.
null

How do you avoid the ORA-01555 error in oracle 8i?

please give me examples.

i have to disagree with gopalora
Increasing rollback segments will make large updates/inserts not to fail.
Do frequent Logical Commits will make large updates/inserts not to fail (besides the performance issues).
What you have is a long query failing from frequent updated table,
In any point while the query is running, some rows get updated, making the resultset inconsistent.
Action
Old Snapshot >>>>>>>>>>>>>>>>>>>>>>>>>> |
Query. ----------------------------------------------------------------x--------------------------------------------->
Update >>>>>>>>>>>>>>>> U
Commit >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ^
If that's the case then this should help.
Workaround:
Try splitting the data you are retrieving. ( by Date for instance).
If you are retrieving a whole year get it month by month instead.
I hope this helps.

UNdo error (ora-01555) - Snapshot too old error

Hi,
If undo get filled and if we get a snapshot too old error then what is the solution for this error, plz give step by step solution for this.

You prevent ORA-01555 errors by
1) Setting UNDO_RETENTION equal to or greater than the length of the longest running query/ serializable transaction in the system
2) Ensuring the UNDO tablespace is large enough to accomodate the amount of UNDO generated over that period of time.
You would need to determine things like the length of your longest running query, the amount of UNDO getting generated, etc. and adjust your UNDO_RETENTION and UNDO tablespace accordingly.
Justin

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

Hi,
I'm working on Oracle Database 11g Release 11.1.0.6.0 - 64bit Production With the Real Application Clusters option.
I'm exepriencing the error in the subject executing a procedure.
This procedure run at 2am, reading from a table all records written the day before:
... WHERE date_write between d1 and d1+1 ....
d1 = trunc(sysdate-1)So I suppose that the recordset cannot be changed during the execution of the procedure.
The recordset extracs more or less 10milions of records.
The procedure than read few records from another table and then insert a new record into a table (trying to delete it if already existing).
I commit every 10k records.
What I noticed is that the procedure always fails after 1 hour, that's the undo_retention value.
I tried to change the param to 2 hours, and last run failed after 2 hours...
I think I understood the ORA-01555 causes, but I thought the commit would have avoid it.
So, any suggestion?
Thanks in advance!
Samuel

What's then the logic why the commit is causing it?When you commit a transaction, involved undo blocks are "released", and they might be overwritten : if those blocks are needed for consistency, then you get ORA-01555 error.

Ora-01555 even after proper undo settings

Hi All,
OS : Linux
Oracle : 10.2.0.3.0
Last few weeks i am keep on facing 01555 error for some queries.
Please see my undo settings below
SQL> show parameter undo
NAME                                 TYPE                              VALUE
undo_management                      string                            AUTO
undo_retention                       integer                           1200
undo_tablespace                      string                            UNDOTBS1###############################################
SQL> declare
retention number ;
undo_ts_size number ;
   begin
   retention := DBMS_UNDO_ADV.REQUIRED_RETENTION ;
   undo_ts_size := DBMS_UNDO_ADV.REQUIRED_UNDO_SIZE(retention) ;
   dbms_output.put_line('Current retention ' || retention );
   dbms_output.put_line('Required tablespace size is ' || undo_ts_size);
end ;
Current retention 1100903
Required tablespace size is 198527
PL/SQL procedure successfully completed.####################################################
Tablespace Name                     Ext. Mgt. Seg. Mgt. Tablespace Size (in MB)       Used (in MB)       Free (in MB) Pct. Used
UNDOTBS1                            LOCAL      MANUAL                     16,500              *1,708*             14,792        10###############################################################################
As its an oracle 10.2.0 version, i read that oracle will adjust retention period based on the long running quries & undo advisor is giving recommondation to set tablespace size to 198 G but i cannot understand why my undo tablespace is only 10% used when i am getting ora 01555 error ? mence there is no problem with retention as well as space then where is the problem ?
Also i checked if there is any stealing/reuse is happening but this below query returns 0
select UNXPSTEALCNT,UNXPBLKREUCNT from V$UNDOSTAT;
           0             0
           0             0
576 rows selected.
SQL>#########################################################
Could you please help me to identify the problem which i am facing ?
Thanks
Nisanth Santhan

but as per the below document, in 10.2 onwards even if we set undo retention, oracle will automatically adjust the retention based on the long running query . It seems we can even set 0 for undo retention. I have checked, my current auto undo retention setting is (1100822 sec).
http://www.oracle.com/technology/products/manageability/database/pdf/ow04/1241_minhas_pres.pdf

Flashback Query ORA-01555

Gurus,
I'm receiving an ora-01555 error when attempting to run a flashback query. How can I get this resolve as I need to recover records that were deleted!
SQL> show parameter undo
NAME TYPE
VALUE
undo_management string
AUTO
undo_retention integer
604800
undo_tablespace string
UNDOTBS1
Undo Tablespace is 6GB!
select count(*) from bld as of timestamp (sysdate-5);
ORA-01555: snapshot too old: rollback segment number 19 with name "_SYSSMU19_1281712960$" too small
01555. 00000 - "snapshot too old: rollback segment number %s with name \"%s\" too small"
*Cause:    rollback records needed by a reader for consistent read are
overwritten by other writers
*Action:   If in Automatic Undo Management mode, increase undo_retention
setting. Otherwise, use larger rollback segments
All help is greatly appreciated.

Based on what you have posted you are toast. The data you are trying to read is no longer in the undo tablespace and therefore is unavailable to you.
Why you might ask? I suspect you would find great value in reading the most current issue of Oracle magazine: Especially Tom Kyte's article where he specifically addresses this issue.
SQL> select 604800/86400 from dual;
604800/86400
           7Your undo retention exceeds 5 days ... thus all you have accomplished is to waste disk space.

Catching ORA-01555 in a procedure

Hi,
I have procedure to analyze all the tables in schema based on frequency column value.
while executing this procedure I am getting few errors apart from ORA-01555.
Now I want to catch only ORA-01555 error and insert that record into a log table.
My aim is when I get ORA-01555 error, skip that particular record and continue for next record.
I have added exception part for this, but somehow it is not working.
Please note my requirement is not to aviod the ORA-01555, I want to catch that record into a log table and proceed furthur.
Please help me to resolve this.
below is my procedure code.
CREATE OR REPLACE PROCEDURE analyze_script AS
current_analyze_date DATE;
ana_tbl_list_rec ana_tbl_list%ROWTYPE;
CURSOR cur_analize_list(p_ana_date DATE) IS
SELECT *
FROM ana_tbl_list
WHERE next_current_analyze_date <= p_ana_date;
snapshot_too_old EXCEPTION;
PRAGMA EXCEPTION_INIT (snapshot_too_old, -1555);
BEGIN
current_analyze_date := trunc(sysdate);
--Write start statement to status tab
FOR ana_tbl_list_rec IN cur_analize_list(current_analyze_date) LOOP
     BEGIN
     IF ana_tbl_list_rec.partitioned = 'Y' THEN
          DBMS_STATS.gather_table_stats(ownname => ana_tbl_list_rec.owner,
                         tabname => ana_tbl_list_rec.table_name,
                         CASCADE => TRUE,
                         granularity => 'PARTITION',
                         DEGREE => ana_tbl_list_rec.DEGREE,
                         estimate_percent => ana_tbl_list_rec.estimate_size);
     ELSIF ana_tbl_list_rec.partition_name IS NULL THEN
          DBMS_STATS.gather_table_stats(ownname => ana_tbl_list_rec.owner,
                         tabname => ana_tbl_list_rec.table_name,
                         CASCADE => TRUE,
                         estimate_percent => ana_tbl_list_rec.estimate_size,
                         DEGREE => ana_tbl_list_rec.DEGREE);
     ELSE
          DBMS_STATS.gather_table_stats(ownname => ana_tbl_list_rec.owner,
                         tabname => ana_tbl_list_rec.table_name,
                         partname => ana_tbl_list_rec.partition_name,
                         estimate_percent => ana_tbl_list_rec.estimate_size,
                         DEGREE => ana_tbl_list_rec.DEGREE);
     END IF;
     UPDATE ana_tbl_list
     SET last_analyzed = current_analyze_date,
     next_anal_date = trunc(sysdate + ana_tbl_list_rec.ana_frequence)
     WHERE anatable_id = ana_tbl_list_rec.anatable_id;
     EXCEPTION
          WHEN SNAPSHOT_TOO_OLD
          THEN
          INSERT INTO analyze_table_log(table_name,sql_errorcode,sql_errormsg)
          VALUES (ana_tbl_list_rec.table_name,'1555','SNAPSHOT_TOO_OLD');
     END;
END LOOP;
COMMIT;
END analyze_script;
Thanks

From 10gR2 you have error logging feature. but it will log all the error that occurs during DML operation.
If you use exception handling, the error will be caught and handled but your DML operation will not continue further.
Just to show how DBMS_ERRLOG works...
PRAZY@11gR1> create table source (code number primary key,code_name varchar2(100));
Table created.
Elapsed: 00:00:00.15
PRAZY@11gR1> exec dbms_errlog.create_error_log('SOURCE','ERROR_SOURCE');
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.14
PRAZY@11gR1> desc error_source;
Name
ORA_ERR_NUMBER$
ORA_ERR_MESG$
ORA_ERR_ROWID$
ORA_ERR_OPTYP$
ORA_ERR_TAG$
CODE
CODE_NAME
declare
type src_type is table of source%rowtype;
src_var src_type := src_type();
begin
for i in 1..10000 loop
src_var.extend;
src_var(i).code:=i;
src_var(i).code_name:='NAME '||i;
end loop;
src_var(100).code:=null;
src_var(1000).code:=null;
forall i in 1..src_var.count
insert into source values (src_var(i).code,src_var(i).code_name) log errors into error_source ('INSERT') reject limit unlimited;
end;
PL/SQL procedure successfully completed.
PRAZY@11gR1> select ora_err_number$,ora_Err_mesg$,code,code_name from error_source;
ORA_ERR_NUMBER$ ORA_ERR_MESG$                                                                    CODE       CODE_NAME
           1400 ORA-01400: cannot insert NULL into ("PRAZY"."SOURCE"."CODE")                                NAME 100
           1400 ORA-01400: cannot insert NULL into ("PRAZY"."SOURCE"."CODE")                                NAME 1000
Elapsed: 00:00:00.01Regards,
Prazy
Edited by: Prazy on Mar 25, 2010 2:46 PM

ORA-01555 when performing refresh of materialized views via DBMS_JOB

All,
With this project needing to be finished soon and an issue occuring on the local database, I am hopefuly one of you will have the answer or resolution so that I may complete this project soon....
Here is the setup..
10g database (remote)
9i database (local
DB Link from local to remote database
103 materialized views in local database that are refreshed by pulling data from dblink to remote database.
A PL/SQL procedure has been created which sets the v_failures variable = 0 and then performs a check to see if the current job has a failure and if so, inserts that value into the v_failures variable. When that reaches "1", then the procedure does nothing and closes out. If the failures are equal to "0" then it performs a DBMS_MVIEW.REFRESH procedure for each materialized view.
This worked the first time but its continually failing now with the ORA-01555 error (snapshot too old). From what I can tell, the dbms_job duration is 4 seconds and the Last_Exec is 2m 7s after it starts (8:30 PM). With that said, our DBAs working o nthe project have increased the Undo_Retention settings and assure us that shouldn't be the problem. Odd thing is, this never happened in the dev environment when we were developing/testing - only in the production environment once it got migrated.
I am looking for possible causes and possible solutions to the ORA-01555 error. A sample of the code in my procedure is below:
CREATE OR REPLACE PROCEDURE Ar_Mviews IS
V_FAILURES NUMBER := 0;
BEGIN
BEGIN
          SELECT FAILURES INTO V_FAILURES FROM USER_JOBS WHERE SCHEMA_USER = 'CATEBS' AND WHAT LIKE '%DISCO_MVIEWS%';
          IF V_FAILURES = 1 THEN NULL;
          ELSE
DBMS_MVIEW.REFRESH ('AR_BATCH_RECEIPTS_V', 'C');
          DBMS_OUTPUT.PUT_LINE(V_FAILURES); END IF;
END;
BEGIN
     SELECT FAILURES INTO V_FAILURES FROM USER_JOBS WHERE SCHEMA_USER = 'CATEBS' AND WHAT LIKE '%DISCO_MVIEWS%';
          IF V_FAILURES = 1 THEN NULL;
          ELSE
DBMS_MVIEW.REFRESH ('AR_BATCHES_ALL_V', 'C');
          DBMS_OUTPUT.PUT_LINE(V_FAILURES); END IF;
END;
END Ar_Mviews;
---------------------------------------------------------------------------------------------------------------

We are doing complete refreshes and doing it that way for consistency in the data presented. Because some materialized views are dependent upon data in other materialized views, we have them ordered in a procedure so that when one finishes, the next starts and they are also in a specific order as to ensure accurate data.
The condition for v_failures is done so that the job doesn't get, lets say, 90% finished and hit an error and start over again. We do the IF statement which results in NULL (do nothing) so that the job doesn't repeat itself over and over again. If one MV fails, we have to consider the job a failure and do nothing else because the one MV that failed may have been a dependency of another MV down the line. (i.e. MV7 calls MV3 and MV3 fails, so the whole job fails because MV7 can't be accurate without the most current data from MV3).
As well, this is being performed in off-business hours after backup to tape, etc. and prior to start of business so that no one is using the system when we run this job. That won't always be the case when we move to high availability with this system for varying time-zone end-users.
I hope I have answered your question and look forward to continued feedback.
Thanks!

How to solve ORA-01555 for SELECT ? Thanks.

I am running Oracle 9i on Solaris 9. I have a query that's supposed to processes massive records by joining several very big tables but dies with ORA-01555 error after hitting UNDO_RETENTION of 144000 (40 hours). The query plan looks pretty nice and robust.
Instead of running the SELECT statement, what can be other approaches that can solve this problem?
Thanks.

The query plan can have flowers all over it, but saying it looks pretty nice doesn't really give us any information. We can't see your query, your table structures, your data or your execution plans or trace files, so we can't provide much help really.
>
ORA-01555: snapshot too old: rollback segment number string with name "string" too small
Cause: rollback records needed by a reader for consistent read are overwritten by other writers
Action: If in Automatic Undo Management mode, increase undo_retention setting. Otherwise, use larger rollback segments

ORA-01555 during SELECT ??

I am running Oracle 9i on Solaris 9. I have a Stored Procedue that's essentially a huge SELECT (no insert, update, delete at all) statement joining many big tables. The query plan looks pretty good -- all index hits, no table scan. Now -- when I run it I get the infamous ORA-01555 error on UNDO segment -- saying its too small! What may be the reason (note that there are not many users on this system) and how to avoid it?
Thanks.

Since you didn't provide any details we can redirect you in those following links ->
1. Error Reason ->
http://ora-01555.ora-code.com/
2. Popular Oracle Thread By Tom Kytes in this topic ->
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1441804355350
Regards.
Satyaki De.

ORA-01555 error ?

Similar Messages

Maybe you are looking for