Cursors, rollback and Long Updates
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