Cursors, rollback and Long Updates

From: Simon Thompson <scthomp_at_ibm.net>
Date: 1995/07/31
Message-ID: <3vi8c6$1cov_at_news-s01.ca.us.ibm.net>#1/1


I have several PL/SQL programs that have a long-running update where one of the tables being updated is the table in the CURSOR select statement for the driving table. (Some skelton code below demonstrated the process.)

Some background: The database is a DSS (OLAP) database. The data comes from an old Mainframe system. When I update the database from flat files, I want to mark the records as I load them in so I don't have to restart the process from the beginning if something goes wrong. (In one case, I can't start from the beginning as loading the records more than once would make the database inaccurate). I do a commit every 200 records or so. There are other times when I am creating summary data, etc., that I also mark the records summarised.

The basic problem is that I sometimes run out of rollback segments. An ancillary problem is that I am sure keeping the rollback data slows the process down. Once the records are committed, I no longer require the rollback data on the driving table.

Is there any way I can stop it keeping the rollback data for the cursor table? Or a PL/SQL coding trick? I've checked my manuals and my text books, but none of them cover this. Would putting an exclusive lock on the driving table work?

Skeleton code:

declare

cursor INPUT is
  select ROWID, ...
    from INPUT_TABLE;

count NUMBER(3, 0);

begin
count := 0;
for aRec in INPUT loop;

  • Processing goes here.

  update INPUT
    set PROCESSED = 'Y'
    where ROWID = aRec.ROWID;

  count := count + 1;
  if count >= 200 then
    commit;
    count := 0;
  end if;
end loop;
commit;
end;

TIA.

+---------------------------

| Simon Thompson
| Christchurch
| New Zealand
Received on Mon Jul 31 1995 - 00:00:00 CEST

Original text of this message