Skip to Main Content
  • Questions
  • How to find out which session/process caused ORA-01555

Breadcrumb

Question and Answer

Tom Kyte

Thanks for the question.

Asked: May 03, 2005 - 3:51 pm UTC

Last updated: February 04, 2011 - 2:28 pm UTC

Version: 9.2.0.5

Viewed 10K+ times! This question is

You Asked

We have a database running on 9.2.0.5 and we do have intermittent
ORA-01555 errors in our alert log. There is no trace file to get
the process information. We have a piece of the SQL statement
that caused the ORA-01555 in the alert log with which we could get
the complete SQL from the hash_value in the V$SQLTEXT. We would
like to see if it is possible to trace it further to find out which
session or process caused this.

Would you please suggest a way to do that?

Thanks.

and Tom said...

Ok, in order to demonstrate this, I have to break every rule in the book :) (except bind variables of course...)

You can use this trigger -- just grab whatever info you want and record it:

ops$tkyte@ORA9IR2> create table t ( msg varchar2(4000) );

Table created.

ops$tkyte@ORA9IR2>
ops$tkyte@ORA9IR2> create or replace trigger snapshot_too_old
2 after servererror on database
3 declare
4 l_sql_text ora_name_list_t;
5 l_n number;
6 begin
7 if ( is_servererror(1555) )
8 then
9 insert into t values ( 'ora_sysevent = ' || ora_sysevent );
10 insert into t values ( 'ora_login_user = ' || ora_login_user );
11 insert into t values ( 'ora_server_error = ' || ora_server_error(1) );
12
13 l_n := ora_sql_txt( l_sql_text );
14 for i in 1 .. l_n
15 loop
16 insert into t values ( 'l_sql_text(' || i || ') = ' || l_sql_text(i) );
17 end loop;
18 end if;
19 end;
20 /

Trigger created.

ops$tkyte@ORA9IR2>

no we must get a 1555 - so go small:

ops$tkyte@ORA9IR2> create undo tablespace small datafile size 2m autoextend OFF;

Tablespace created.

ops$tkyte@ORA9IR2>
ops$tkyte@ORA9IR2> drop table ora_1555;

Table dropped.

ops$tkyte@ORA9IR2> create table ora_1555 as select * from all_objects;

Table created.

ops$tkyte@ORA9IR2>
ops$tkyte@ORA9IR2>
ops$tkyte@ORA9IR2> alter system set undo_tablespace = small;

System altered.


Now open a cursor -- it is read consistent as of NOW

ops$tkyte@ORA9IR2> variable x refcursor
ops$tkyte@ORA9IR2>
ops$tkyte@ORA9IR2> exec open :x for select * from ora_1555;

PL/SQL procedure successfully completed.

generate lots of undo and commit and do it over again and again, ugly... don't do this at home kids...

ops$tkyte@ORA9IR2> begin
2 for i in 1 .. 10
3 loop
4 loop
5 delete from ora_1555 where rownum <= 1000;
6 exit when sql%rowcount = 0;
7 commit;
8 end loop;
9 commit;
10 insert into ora_1555 select * from all_objects;
11 commit;
12 end loop;
13 end;
14 /

PL/SQL procedure successfully completed.

ops$tkyte@ORA9IR2> print x
ERROR:
ORA-01555: snapshot too old: rollback segment number 13 with name "_SYSSMU13$" too small



no rows selected

got the error, and....

ops$tkyte@ORA9IR2>
ops$tkyte@ORA9IR2> alter system set undo_tablespace = undo;

System altered.

ops$tkyte@ORA9IR2> drop tablespace small;

Tablespace dropped.

ops$tkyte@ORA9IR2> drop trigger snapshot_too_old;

Trigger dropped.

ops$tkyte@ORA9IR2> spool off
ops$tkyte@ORA9IR2> select * from t;

MSG
-------------------------------------------------------------------------------------------------------------------------
ora_sysevent = SERVERERROR
ora_login_user = OPS$TKYTE
ora_server_error = 1555
l_sql_text(1) = SELECT * FROM ORA_1555

we have the record of it


Rating

  (39 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

A reader, May 04, 2005 - 12:36 pm UTC


Followup question

Bob Rich, May 04, 2005 - 1:29 pm UTC

Tom,
I've used the after servererror on database trigger just as written from a previous post with much success. However, I was unable to write code to handle the error caused by someone trying to login with an invalid password. Do you have any suggestions?

Thank you.

Error example:

ORA-7445 occurs when this trigger is enabled.

*** SESSION ID:(264.5592) 2004-05-12 13:44:06.923
Exception signal: 11 (SIGSEGV), code: 1 (Address not mapped to object),
addr: 0x0, PC: [0x100a01228, 0000000100A01228]
*** 2004-05-12 13:44:06.931
ksedmp: internal or fatal error
ORA-07445: exception encountered: core dump [0000000100A01228] [SIGSEGV]
[Address not mapped to object] [0x000000000] [] []
ORA-01017: invalid username/password; logon denied



Tom Kyte
May 04, 2005 - 1:51 pm UTC

use auditing for that....



A reader, May 04, 2005 - 1:38 pm UTC


Follow up question

Bob Rich, May 04, 2005 - 2:12 pm UTC

Sorry Tom, I did not make myself clear. I do use auditing to monitor invalid logon attempts. I was trying to keep the trigger from erroring when an invalid logon occured. I was told it errored out because the error occured outside the database.

Thanks

Tom Kyte
May 04, 2005 - 2:18 pm UTC

version? doesn't happen in 9ir2/10g

A reader, May 04, 2005 - 3:53 pm UTC

What if the error is caused by some recursive SQL executed/generated on behalf of some USER sql ? Can we get the USER SQL in this case as well ?

thanks
Regi

Tom Kyte
May 04, 2005 - 6:02 pm UTC

you can grab the state of the session (like v$cursor contents)

from the metalink

A reader, May 04, 2005 - 4:53 pm UTC

Also from the oracle metalink

Caution when using ora_sql_txt function within a server error event trigger. 

 
SCOPE & APPLICATION
-------------------

Anyone who is going to write a server error trigger. 


Problem 
--------
A describe of a non-existent table may get ORA-3113 or ORA-7445 (qdesqltxt)  
in the server side alert.log. 

The reason that ora_sql_txt failed is because, in cases such as:
 
SQL> desc <some non-existent table> 

which should give ORA-4030, no triggering sql is involved so ora_sql_txt 
didn't return a number.
 
WORKAROUND:
-----------

Avoid calling ora_sql_txt within a systemwide servererror trigger. 


RELATED DOCUMENTS
-----------------

Bug 3124081 fixed in 10.1, with backports to 9.2.0.5 on some platforms.
.
thanks
Regi 

Tom Kyte
May 04, 2005 - 6:13 pm UTC

not sure i like that note, what is the number.

it should say "use ora_sql_text" on the errors you want to use it on...

I still don't get it.

not saying, May 04, 2005 - 7:31 pm UTC

You've shown the statement that is failing with the 1555, which is what the OP asked for.

But don't we really want to know the statement that is making oracle think the select * from transaction is looking at the data that needs to be consistent?

Maybe an example that isn't recursive would be more clear on this point, like what the ora-1555 error message says.

Tom Kyte
May 04, 2005 - 8:00 pm UTC

and that is exactly what I logged - the statement that needs the undo

there could be (and generally are) thousands of statements that make it so it cannot get it's consistent read.

The 1555 is fired when a READ to the database cannot find the undo needed to put a block it wants back the way it was when that statement began. EVERY modification that happened from the time the statement was opened contributes to that -- EVERY one.

Metalink doc

A reader, May 06, 2005 - 3:08 pm UTC

Describe of a Non-existent Object Results in ORA-3113 or ORA-7445 - Doc Id 258495.1

Regi

Very Helpful

A reader, May 12, 2005 - 7:41 pm UTC

Tom,
This is very helpful. Since over a period many 1555 may get accumalated, is it possible to capture the time stamp also? Can you please show it? I tried sysdate imporperply and had issues.
Thanks.

Tom Kyte
May 13, 2005 - 9:06 am UTC

describe issues, better yet, give example and say what didn't work.

Words again

Niall Litchfield, June 03, 2005 - 5:17 am UTC

I suspect some of the confusion comes from the wording of the original question. The question asked for the statement that #bcaused#b the 1555, the trigger gets the statement that #bencountered#b the 1555. This, most often, is what we want - because it'll be in bad code, but it isn't the cause - the cause is the size of the available undo and the volume of transactions

Tom Kyte
June 03, 2005 - 7:34 am UTC

But there isn't "a statement" that causes a 1555.

It is every statement since the query began that "causes" it.

Correct me if I am wrong....

Paul Guerin, June 05, 2005 - 4:05 am UTC

used = active or within undo_retention period.
active = utilised by a transaction.
expired = outside undo_retention period.

In Summary:
a) Intention is for unused (ie non-active and outside undo_retention period) rollback segments to be reused to satisfy demand.
b) When unused rollback segments are not available, then the Undo tablespace will endeavour to increase in size to meet the undo generated.
c) If the undo tablespace can not grow in size, then:
- inactive unexpired rollback segments will be reused - initially not a problem - but once all these rollback segments are used then 'unable to extend segment' error results. Reduce the rollback segment turn around time by reducing the undo_retention period.
- active expired rollback segments of long running transactions can be used by other transactions - 'snapshot too old' error. Increase the rollback segment turn around time by increasing the undo_retention period.

Rollback segment Comment
inactive,expired: Rollback segment is free for reuse.
inactive,unexpired:Rollback segment is used.
(Can not be reused except if the Undo tablespace is full and can not extend, then reusable immediately.)

active,expired: Rollback segment is used.
(Can not be reused except if the Undo tablespace is full and can not extend, then is reusable by other transactions resulting in 'snapshot too old' error.)

active,unexpired: Rollback segment is used, and can not be reused.


Tom Kyte
June 05, 2005 - 9:23 am UTC

the goal simply stated is to keep undo EXTENTS available for the period of time specified by undo-retention. If undo-retention says to keep it for 30 minutes, we'll try to not reuse it for 30 minutes after it was last used.

In order to do that, we'll attempt to grow the undo tablespace in order to add new undo extents, rather than overwrite data less than 30 minutes old.

We can also 'steal' extents -- normally an extent belongs to a segment, but with AUM, we can steal an extent from undo segment "1" and give it to undo segment "2". We'll do that as well -- steal old, no longer needed extents from other segments rather than reuse something less than 30 minutes old.

If we cannot grow AND we cannot steal a no-longer needed extent, then we'll start using extents that fall within the 30 minute window.

lost sys password 9i

Adel, June 06, 2005 - 7:15 am UTC

Dear Tom
I 've lost my sys password. Do you know any way to recreate a new pass.

Regards Adel

DBA 8i 9i


Tom Kyte
June 06, 2005 - 7:41 am UTC

find the user who is allowed at the OS level to "connect / as sysdba" and ask them to fix it.

Move a database to the new version 9i to 10g

Don carlos, June 07, 2005 - 4:16 am UTC

Hi Tom
I have installed Oracle 9i on the database server, some of the databases have been moved to 10g by another Oracle dba, I am new to the database migration. What steps to move a database to the new Oracle instance?



Tom Kyte
June 07, 2005 - 8:17 am UTC

</code> http://otn.oracle.com/pls/db10g/portal.portal_demo3?selected=3#index-UPG <code>

you want to read the upgrade guide to learn the ways to go from 9i to 10g.

ora_sql_text function returns null in trigger in 10g

Sasa, June 21, 2005 - 11:28 am UTC

Hi Tom,
Ora_sql_text function returns null in trigger in 10g while this has worked fine in a 9i.

Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - Prod
PL/SQL Release 10.1.0.2.0 - Production
CORE 10.1.0.2.0 Production
TNS for 32-bit Windows: Version 10.1.0.2.0 - Production
NLSRTL Version 10.1.0.2.0 - Production

Do you happen to know any problem related to this issue?
Regards,
Sasa


Tom Kyte
June 21, 2005 - 5:12 pm UTC

the problem -- you don't get the text?

Good work

sikkandar, June 27, 2005 - 9:37 pm UTC

By god support you are the invicible person in ORACLE stream.

SQL Statement (DBA from Bahrain)

DBA 8i 9i, July 20, 2005 - 3:07 am UTC

Hi tom

Which SQL statement displays the date March 19,2001 in a format that appears as "Nineteenth of March 2001 12:00:00 AM"?


A.select to_char(to_Date("19-Mar-2001','DD-Mon-yyyy'),'fmDsdpth "of" Moth yyyy FmHH:MI:SS AM') NEW_Date from dual;

B.select to_char(To_Date('19-Mar-2001','DD-Mon-yyyy'),'Ddspth "of" Month yyyy fmHH:MI:SS AM') NEW_DATE from dual;

C. select to_char(TO_DATE('19-Mar-2001','DD-Mon-yyyy),'fmDdspth "of" Month yyyy HH:MI:SS AM')NEW_DATE

D.select to_char(TO_DATE('19-Mar-2001','DD-Mon-yyyy),'fmDdspth "of" Month yyyy

so which is the answer.




Tom Kyte
July 20, 2005 - 6:25 am UTC

run them and see???



Capturing sql-code from ORA-1555 errors

Jeff Breckenridge, February 11, 2006 - 9:14 am UTC

The write-up is great. This has solved my problem and will save me a lot of time tracking down the sql-code for ORA-1555 errors. The alert log chopped of the sql after 1000 characters. This method will allow me to identify the entire sql code. Thank you.

Hash value of sql text

Fayyaz ZAHEER, July 27, 2006 - 6:52 am UTC

Is it possible to get hash_value and module name of SQL text also in your procedure snapshot_too_old ?

Becuase, once we got the sql causing the ORA-1555 error, then we have to find, from which module it is coming? Also, if it is not coming from any module, then we have to find hash_value of that SQL ?

Thanks for your answer

Tom Kyte
July 27, 2006 - 11:58 am UTC

you have the sql text available, you can query the v$ tables from that.

susan, August 08, 2006 - 11:01 am UTC

In order to identify offending statements in "ORA-1555: snapshot too old" errors, can you please let me know how to set events? I have seen in Oracle forums to set "alter session set events = '1555 trace name errorstack level 1'." But this was for Oracle 8.1.7. Our database is version 9.2.0.6.0. Is this event valid for version 9.2.0.6.0. as well?
Also, can you tell me some good documents for more details on valid events for each release and the trace levels? Thank you in advance.


Tom Kyte
August 09, 2006 - 9:51 am UTC

please utilize support for information regarding events.



ORA-01555 caused by SQL statement below with Query Duration=0 sec

Tomas Lopez, August 11, 2006 - 1:41 pm UTC

Hi Tom,

I read a lot about the ORA-1555 error with Query Duration of thousands of seconds but any one with 0 sec. I had this error marked 18 times in alert.log.

ORA-01555 caused by SQL statement below (SQL ID: 33mfg4w6sq53d, Query Duration=0 sec, SCN: 0x0000.0972cfbf):

Is possible that undo is full when the system tried to execute these queries? Or, what could be the reason of this Query Duration=0 error?

We have a 5GB undo and undo_retention=1800.

Thank you very much for your time.

Tom Kyte
August 11, 2006 - 2:48 pm UTC

Ok, it took me a minute to figure out :)

probably a flashback query that flashed back over a period of time longer than you had undo for.

Here is my "demo", the drop and create are commented out because you have to have the table around for a couple of minutes to flashback (so I ran it, it failed, waited a bit, and then it worked... after commenting out)

ops$tkyte%ORA10GR2> create undo tablespace undo_small
  2  datafile size 3m
  3  autoextend off;

Tablespace created.

ops$tkyte%ORA10GR2>
ops$tkyte%ORA10GR2> alter system set undo_tablespace = undo_small;

System altered.

ops$tkyte%ORA10GR2> alter system set undo_retention = 0 scope = memory;

System altered.

ops$tkyte%ORA10GR2>
ops$tkyte%ORA10GR2> connect /
Connected.
ops$tkyte%ORA10GR2> set echo on
ops$tkyte%ORA10GR2> /*
ops$tkyte%ORA10GR2> drop table t;
ops$tkyte%ORA10GR2> create table t ( x int, y char(2000) );
ops$tkyte%ORA10GR2> insert into t select user_id, 'x' from all_users;
ops$tkyte%ORA10GR2> commit;
ops$tkyte%ORA10GR2> */
ops$tkyte%ORA10GR2> column scn new_val S
ops$tkyte%ORA10GR2> select dbms_flashback.get_system_change_number scn from dual;

       SCN
----------
  13232468

ops$tkyte%ORA10GR2>
ops$tkyte%ORA10GR2> begin
  2          for i in 1 .. 10000
  3          loop
  4                  update t set y = rpad( i, 2000, substr(i,1,1) );
  5                  commit;
  6          end loop;
  7  end;
  8  /

PL/SQL procedure successfully completed.

ops$tkyte%ORA10GR2> select x from t as of scn &s;
old   1: select x from t as of scn &s
new   1: select x from t as of scn   13232468
select x from t as of scn   13232468
              *
ERROR at line 1:
ORA-01555: snapshot too old: rollback segment number 34 with name "_SYSSMU34$"
too small


ops$tkyte%ORA10GR2>
ops$tkyte%ORA10GR2> alter system set undo_tablespace = UNDOTBS1;

System altered.

ops$tkyte%ORA10GR2> connect /
Connected.
ops$tkyte%ORA10GR2> set echo on
ops$tkyte%ORA10GR2> drop tablespace undo_small;

Tablespace dropped.



....
ORA-01555 caused by SQL statement below (SQL ID: bcggg6dddmzqy, Query Duration=0 sec, SCN: 0x0000.00c9e954):
Fri Aug 11 14:37:57 2006
select x from t as of scn   13232468
 

Flashback,Trigger many points

ambsa, September 04, 2006 - 11:06 pm UTC

I cleared lot's of doubt but i thing is i also wanted to ask

some questions how shall I?
my mail id:ambasa.ladwa@qsoftindia.com
ambasa.ladwa@gmail.com

Sean, October 18, 2006 - 11:36 pm UTC

Tom,

I do not understand in your demo

"alter system set undo_retention = 0"

seemed to it for sure hitting 1555, correct?

Tom Kyte
October 19, 2006 - 8:11 am UTC

that was the goal, yes. but undo_retention enables "self tuning" undo management in 10g actually.

But in my case, I was trying to show how to get a query fail with a 1555 with 0.00 seconds of runtime - by flashing back far enough into the past.

my case

Sean, October 20, 2006 - 12:18 pm UTC

ORA-01555 caused by SQL statement below (SQL ID: ... Query Duration=8 sec, SCN: ...):

SELECT "TASK_ID","PROJ_ID","TASK_TYPE","ACT_END_DATE" FROM "TASK" "T" WHERE
("TASK_TYPE"=:"SYS_B_0" OR "TASK_TYPE"=:"SYS_B_1") AND "ACT_END_DATE" IS NOT NULL


we are on 9.2.0.7 and undo_retention set to 15 hours.

the applications hit 1555 undeterministically. does your demo apply?


Tom Kyte
October 20, 2006 - 12:24 pm UTC

nope, not unless they used the stored procedure method of flashing back or were serializable or where read only.

A reader, October 20, 2006 - 12:49 pm UTC

is the method of flashing back a 10g thing, not in 9iR2?




Tom Kyte
October 20, 2006 - 1:21 pm UTC

no, works fine in 9ir2 (and the same)

Does Undo Tablespace Size Matter

Jay, May 18, 2007 - 3:56 pm UTC

Tom,

In 10g and 9ir2 with automatic undo management, does the undo tablespace size matter at all in terms of DML performance? Say if we don't encounter ora-1555 but we constantly see that the freespace in the undo tablespace is about to run out, is DB performance in this situation adversely affected by the constant reuse of existing undo segments?

Thanks!
Tom Kyte
May 18, 2007 - 4:30 pm UTC

freespace is about to run out....


that means "nothing" - because if it doesn't run out, - well we cannot say much?

Although...it does on a disk.

S Patel, May 21, 2007 - 1:08 am UTC

Well,

If the same situation is encountered with regards to a Disk-spindle you might have issues with your UNDO operations being slowed down (not an Oracle issue, more like external).

If you create a new UNDO file on a disk which is about to run out, you might be storing those bits on the inner sectors which experiences high seek time oppose to outer sectors of the disk.

Also depends on vendor to vendor.

Have seen people doing that mistake over and over to use 100% disk quota to store datafiles combined with Oracle Managed Files (OMF).

Generally I store OMF on fast almost/half empty disks as they incur heavy read/write. And those writes are seeked-writes, for e.g., UNDO where you might need to seek first in order to replace/write.

My two cents worth. Not saying do it, just think that this should be the practice. Check with Tom though. ;)

Re: Does Undo Tablespace Size Matter

Jay, May 21, 2007 - 1:26 pm UTC

Well actually sometimes it did run out of space as I got alerts that free extents is 0 in undo tablespace. However that doesn't always cause ora-1555 and moments later the free space might increase to acceptable level by itself. What I'm worried is Oracle's re-use of existing extents after freespace is out slows the process down even though no error was thrown. On the other hand I don't want to just increase the undo size if Oracle can finish the job without 1555 or dramatic performance penalty.
Tom Kyte
May 21, 2007 - 1:54 pm UTC

free extent of zero is not out of space.

If you see lots of prematurely expired extents (v$undostat), then you have allocated insufficient undo space for your undo retention and that would/could lead to 1555's.

Oracle reuse of existing extents will not "slow down processes" since by design we always reuse existing extents - it is the way it works. However, if we reuse an extent prematurely, that'll increase your odds of a 1555 and you'd probably want to avoid that (by adding space - statspack or AWR can help you determine how much permanently allocated space you need for a given undo retention).

Re: Does Undo Tablespace Size Matter

Jay, May 21, 2007 - 3:10 pm UTC

Thanks, that's very helpful!

Undo Advisor

Reader, May 21, 2007 - 3:34 pm UTC

Undo Advisor GUI is very helpful in situations like this.

Snapshot too old

Bob, August 13, 2008 - 6:19 am UTC

Hi Tom,

I have been reading with interested your initial post on recording the offending SQL in an audit table using a system level trigger. I have noticed a problem though whilst testing this. For example, after creating the trigger and setting the undo tablespace to "small", if our PL/SQL code does the following:

drop table x
/
create table x as select * from all_objects
/
drop table temp
/
create table temp
(y number)
/
insert into temp values (1)
/
commit
/
PROMPT QUERYING TEMP BEFORE
PROMPT

select * from temp
/
var r refcursor
--
exec open :r for select * from x;
--
begin

loop
delete from x where rownum <= 1000;
exit when sql%rowcount = 0;
commit;
end loop;
commit;

insert into x select * from all_objects;
commit;

delete from temp;
end;
/
print :r
--
PROMPT QUERYING TEMP AFTER
select * from temp
/

We will find after trying to print the contents of the REF cursor, getting the ORA-1555, it automatically commits the delete from temp table! Probably not what we want in a production system.

Is it possible to make the system level trigger process as an autonomous transaction?

Cheers,
Bob

Snapshot too old

Bob, August 13, 2008 - 10:56 am UTC

Sorry Tom, I've made a mistake here. I have realized it's an autonomous transaction!

Can we use this to check TEMP tablespaces being blown? And more importantly, who the culprit is!!!

Cheers,
Bob
Tom Kyte
August 18, 2008 - 9:34 am UTC

grab the error for a temp tablespace in addition/instead of 1555, use a servererror for that.


and then EVERYONE that is trying to use temp is the culprit, query the v$ views to see who it using it and save that information if you want to

'1555 trace name errorstack level 3';

Tariq, February 20, 2009 - 1:24 pm UTC

Dear Tom,

I have set the following thing with system user

alter system set events '1555 trace name errorstack level 3';
alter system set events '10442 trace name context forever, level 10';

because of undo error:

Now I want to set both the above as normal as previous.

Need you help in this regard


Tom Kyte
February 21, 2009 - 9:10 pm UTC

no you don't. I don't know why you think you "do"

utilize support for this

A reader, February 11, 2010 - 9:53 am UTC

For some reason, the trigger does not capture every occurence of 1555 appeared in the alert log. My database is 9.2.0.8. In a test envrionment, I tried your example with SYS user, it does not capture, with other users OK. But I am sure we don't use SYS in our production database. Any other cases that the trigger may not work?

- Yu (Denis) Sun
Tom Kyte
February 16, 2010 - 9:53 am UTC

SYS is special and magic, do NOT DO ANYTHING as sys, just stop using sys, that is our account - you need to use it for almost NOTHING.

You don't need it to start/stop the database (as sysoper is more than sufficient) and beyond that - you need it for almost nothing else.

What are you doing as SYS ????????? Things work differently for SYS.

1555 by a remote SQL not capture

Yu Denis Sun, February 25, 2010 - 9:45 am UTC

Thanks for the comments on SYS.

I did following test in sequence after creating the small undo tablespace and table:

-- At remote

denis@REMOTEDB>variable x refcursor
denis@REMOTEDB>exec open :x for select * from ora_1555@dbwrkev1;

PL/SQL procedure successfully completed.


-- At local

denis@DBWRKEV1> begin
2 for i in 1 .. 10
3 loop
4 loop
5 delete from ora_1555 where rownum <= 1000;
6 exit when sql%rowcount = 0;
7 commit;
8 end loop;
9 commit;
10 insert into ora_1555 select * from all_objects;
11 commit;
12 end loop;
13 end;
14 /


-- At remote

denis@REMOTEDB>print x
ERROR:
ORA-01555: snapshot too old: rollback segment number 16 with name "_SYSSMU16$" too small
ORA-02063: preceding line from DBWRKEV1


no rows selected



-- Local alert log (PST)

Thu Feb 25 07:14:45 2010
ORA-01555 caused by SQL statement below (SQL ID: 7xnnz01z88xhp, Query Duration=130 sec, SCN: 0x09e4.4295f28d):
Thu Feb 25 07:14:45 2010
SELECT "A1"."OWNER","A1"."OBJECT_NAME","A1"."SUBOBJECT_NAME","A1"."OBJECT_ID","A1"."DATA_OBJECT_ID","A1"."OBJECT_TYPE","A1".
"CREATED","A1"."LAST_DDL_TIME","A1"."TIMESTAMP","A1"."STATUS","A1"."TEMPORARY","A1"."GENERATED","A1"."SECONDARY" FROM "ORA_1
555" "A1"
~

-- Remote alert log
(not see any 1555, I am a little suppurized)

-- at local -- note the ORA-01555 in alert log at time 7:14 not captured by the trigger.

denis@DBWRKEV1> ;
1* select * from db_admin.servererror_log
v983294@DBWRKEV1> /

ID ERROR TIMESTAMP USERNAME OSUSER MACHINE PROCESS PROGRAM
---------- ---------- ----------------- ---------- ---------- --------------- -------- ------------------------------
1 942 25-02-10 07:01:07 SYS oracle sjscqdd1 23074 sqlplus@sjscqdd1 (TNS V1-V3)
2 1555 25-02-10 07:03:18 SYS oracle sjscqdd1 23074 sqlplus@sjscqdd1 (TNS V1-V3)




Query Duration in ORA-01555

A reader, August 03, 2010 - 10:36 am UTC

Hi,

I am trying to understand how to interpret the value of Query Duration in ORA-01555 error. Some of the values show tremendously high value (like the one below).

ORA-01555 caused by SQL statement below (Query Duration=1281961223 sec, SCN: 0x0000.2773d7b6):
Thu Jul 22 21:19:26 2010
SELECT OWNER, DEFINITION, WHENCLAUSE, ACTION, ENABLED, OWNERID, NAME,
BASENAME, BASETYPE, BASEOBJECT, PROPERTY, BTOWNER, TPROPERTY,
TRIG_OBJNO
FROM SYS.EXU92TGR
WHERE OWNERID != 0
ORDER BY OWNERID

I appreciate your explanation on this subject.

Thanks,

Tom Kyte
August 03, 2010 - 11:53 am UTC

see support Note 750195.1

capture additional details on 1555

kg, January 26, 2011 - 3:55 pm UTC

Hi Tom

In below plsql portion where you capture session information

if ( is_servererror(1555) )
8 then
9 insert into t values ( 'ora_sysevent = ' || ora_sysevent );
10 insert into t values ( 'ora_login_user = ' || ora_login_user );
11 insert into t values ( 'ora_server_error = ' || ora_server_error(1) );

Would like to capture more session details such as sid,module,action

We want to capture information in 11i EBS environment


Tom Kyte
February 01, 2011 - 2:57 pm UTC

insert into t
select whatever columns you want
from v$session where sid = (select sid from v$mystat where rownum=1);


it is all there.

Not very Clear

KG, February 04, 2011 - 2:04 pm UTC

Hi Tom
Thanks for response
---
insert into t
select whatever columns you want
from v$session where sid = (select sid from v$mystat where rownum=1);
---

I am looking this information not for my session but any session in database which causes 1555 .
In that case, How do i identify SID ?




Tom Kyte
February 04, 2011 - 2:28 pm UTC

the trigger is fired in a session. That session has a sid. That sid is most easily retrieved via "select sid from v$mystat where rownum=1"

Thank you for explaining

A reader, February 08, 2011 - 10:25 am UTC


Thank you Again

KG, February 12, 2011 - 1:36 pm UTC

Tom
I would test it and would come back if face any issue.
You help so far much appreciated

More to Explore

PL/SQL demos

Check out more PL/SQL tutorials on our LiveSQL tool.

PL/SQL docs

PL/SQL reference manual from the Oracle documentation library