Commiting every 50 records

Question

Dear all,
Am using the below query to insert records into a table.. this query is often resulting in ora-01555. snapshot too old error.
insert /*+ APPEND NOLOGGING PARALLEL */ into medt.pedfg SELECT MIN(TRUNC(I.TRANSDATE)) "TRANSDATE", c.tno , c.contrno, c.prepost_paid,
c.tariff_profile,
DECODE(num_type, 'P','Platinium','G','Golden','S','Silver', 'B','Bronze','V','Regular',num_type) NUMBER_TYPE, TRUNC(C.CREATION_DATE) "Activation Date"
FROM medcinf c, medt i WHERE c.tno = i.tno AND C.PREPOST_PAID ='PREP' AND c.tno LIKE '5%'
AND c.tno NOT IN (SELECT tno FROM medt.pedfg )
GROUP BY c.tno , c.contrno, c.prepost_paid,c.tariff_profile , NUM_TYPE,TRUNC(C.CREATION_DATE);
How can I put this in a loop and commit every 50 rows or 100 rows ?
Please guide
Kai

Answer 1

How can I put this in a loop and commit every 50 rows or 100 rows ?While you could do this, I would expect that doing so would radically slow down the process and increase the frequency of the ORA-01555 error. I would expect (unless you have some evidence to the contrary) that the problem here is that it takes some time for Oracle to execute your query, that the tables you are referencing are undergoing DML while the query is running, and that at some point during the query execution, Oracle needs to reconstruct a block as it existed at the time the query started but the block had been modified by one of those processes doing DML and the UNDO for that change had been discarded. Slowing down the process will only make it more likely that you'll need such a block.
Assuming this diagnosis is correct, you have a couple of options
1) Increase the time that blocks remain in UNDO. This may involve increasing your UNDO_RETENTION period to exceed the length of time Oracle requires to execute this statement or ensuring that your UNDO tablespace is large enough to hold all the UNDO generated over that time.
2) Decrease the time that this query takes to run.
Etbin has suggested trying NOT EXISTS in order to go down path #2. That may well be a reasonable approach depending on the data volumes involved. But if we're treating this as a tuning exercise, I'd rather start with getting a query plan to see how best to attack the performance problem.
On the other hand, increasing UNDO_RETENTION or throwing some disk at the UNDO tablespace may be an easier option.
If you do want to go down path #2 and try Etbin's suggestion,
c.tno NOT IN (SELECT tno FROM medt.pedfg )would be logically equivalent to
NOT EXISTS( SELECT 1 FROM medt.pedfg p WHERE c.tno = p.tno)Justin