RE: Snapshot too old

Patrick,

A code around I've used is to periodically close and reopen the cursor.   

Logic is as follows

define

  v_loop_size  number := 5000;
  v_prev_unique_id number := 0;
  v_hold_unique_id number := 0;

  main_cur (c_start_unique_id in number) is
     select ...
     from ...
     where unique_id  >= c_start_unique_id 
     ...
     order by unique_id;
 

begin
  loop
    for main_rec in main_cur (v_prev_unique_id + 1) loop

         v_prev_unique_id := main_rec.unique_id;

       <some processing>

       if main_cur%rowcount >= v_loop_size then
          exit;
       end if;

    end loop; --end for loop

    --

• hold the last unique id processed so we know when to exit this loop if v_hold_unique_id = v_prev_unique_id then exit; else v_hold_unique_id := v_prev_unique_id; end if; end loop; end;

Todd Arave
Senior Programmer/Analyst

>>> patrick.van.der.sande_at_skynet.be 01/07/03 03:54PM >>>
Dear,

No, the different jobs use different tables.

As I already mentioned I did find in 5 programs something like this :

Cursor c1 is select * from x where id = xx;

For c1rec in c1 loop

    Blabla
    Blabla

    Update table x set id = NULL where id = xx;     Commit;

End loop;

This is for me a clear case of "fetch across commit". The syntax is not completely correct off course, but the programs are already corrected in the mean time and they never crash again.

Still in 2 jobs , I can not put my finger on it.

I do not want to spit in millions of lines of code. If some command,tool,trace,event whatever can make my life easier, let me know.

Rgds,

Patrick

-----Original Message-----
WILLIAMS
Sent: dinsdag 7 januari 2003 22:10
To: Multiple recipients of list ORACLE-L

Patrick - Do any of these jobs update the same tables? Or do any jobs read a
table that other jobs are updating?

Dennis Williams
DBA, 40%OCP
Lifetouch, Inc.
dwilliams_at_lifetouch.com

-----Original Message-----
Sent: Tuesday, January 07, 2003 2:15 PM
To: Multiple recipients of list ORACLE-L

Dear,  

Since a few weeks I am tuning a big conversion batch written in PL/SQL (millions of lines of code split over 7 batches)

When the job is running, certain batches stop with ORA-1555 : Snapshot too
old. Other batches run well till the end.  

Bizarre is that not always the same job stops.  

When I do a trace I see nothing. With a normal trace I am pretty sure that I
will never see it.

Rollback segments are rarely used. So making the rollbacks bigger or smaller
is not the solution.

They also tried to change the commit rate. That was not the solution.  

When I modified the optimal size to NULL value to avoid shrinking and cached
3 heavily used sequences some runs went all the way but

since a week it stops again with the same annoying error.  

After that I put an event in the init.ora file : event = "1555 trace name
processstate forever, level 10"

A trace file was generated but I could not find the error in the trace file.

I am pretty sure that Oracle just dumps all open cursors in a file. Since
there are 100 of cursors opened I do not have a clue which one

is provoking the error.  

I already looked at the batches and I have identified in 5 of them a "fetch
across commit".

Still they have the error. But in the 2 remaining I can not find this.(surely the 2 biggest ones, nice !)  

So my question is :  

How can I know where in the code the error is generated ?

Must I change the definition of the event ? (I know there are other options
but I can not find them right away)

Should I use DBMS_PROFILER ? (it generates massive files !)

Must they write exceptions everywhere in their code ?  

Can somebody help me ?  

Please do not send me an explanation of the "snapshot too old" error. I
wake
up with it and I go asleep with it.    

Patrick             

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net 
-- 
Author: DENNIS WILLIAMS
  INET: DWILLIAMS_at_LIFETOUCH.COM 

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com 
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net 
-- 
Author: Patrick Van der Sande
  INET: patrick.van.der.sande_at_skynet.be 

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com 
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Todd Arave
  INET: COTArave_at_ihc.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).