Suggestions for improving this update in batches of 100 records

Question

I'm currently using the following PL/SQL code to update batches of records in groups of 100 records at a time.
- DB Version : Oracle9i Enterprise Edition Release 9.2.0.7.0
- There is an index on columns : AHS_CONTACT_TYPE, SYNCSTATUS
- I have to commit the records in batches of 100
-- Mark all the Agents "In Process" (regardless of Owner)
-- Update last_modified_by_id to 'SALESFORCE_LOADED' if the
-- last_modified_by_id column is 'SALESFORCE_SYNC' and
-- the ID column is NOT NULL
   ln_count := 0;
   FOR C IN (SELECT tmpsf_CONTACT.ROWID
               FROM tmpsf_CONTACT
              WHERE ( AHS_CONTACT_TYPE = c_sfContactType_AGENT ) AND
                     ( SYNCSTATUS <> c_sfsyncstatus_IN_PROCESS )
   LOOP
      UPDATE tmpsf_CONTACT
         SET SYNCSTATUS = c_sfsyncstatus_IN_PROCESS,
             LAST_MODIFIED_BY_ID = decode( LAST_MODIFIED_BY_ID, c_username_SALESFORCE_SYNC,
                                                        decode( ID, NULL, LAST_MODIFIED_BY_ID,
                                                                    c_username_SALESFORCE_LOADED),
                                                        LAST_MODIFIED_BY_ID)
       WHERE ( tmpsf_CONTACT.ROWID = c.ROWID );
      -- Commit every 100 records       
      IF (ln_count >= 100) THEN
         COMMIT;
         ln_count := 1;
      ELSE
         ln_count := ln_count + 1;
      END IF;
   END LOOP;
-- Catch last batch with any records less then 100
COMMIT;Does anyone have any suggestions about further improving this performance?
Thanks,
Jason

Answer 1

Okay, I have to do it batches per our DBA group.
This is not up for debate...unfortunately. Their
r reasons :
- To keep the rollback segment small Very small apparently, in fact in this test, updating 100 rows of 2 varchar2(200) columns uses 56 KB of rollback. Updating the whole 10,000 rows uses 5 MB. Is this database running on a pocket USB flash drive? Currently costing $30 for 512 MB from Amazon
http://www.amazon.com/gp/product/B0000B3AKR/qid=1136558252/sr=8-2/ref=pd_bbs_2/103-9580563-3995040?n=507846&s=electronics&v=glance
SQL> create table t as select rpad('x',200,'x') a, rpad('y',200,'y') b
  2  from dual connect by level <= 10000;
Table created.
SQL> update t set a = replace(a,'x','y'),
  2    b = replace(b,'y','x')
  3  where rownum <= 100;
100 rows updated.
SQL> select
  2      used_ublk undo_used_blk,
  3      used_ublk * blk_size_kb undo_used_kb,
  4      log_io logical_io,
  5      cr_get consistent_gets
  6  from
  7      v$transaction, v$session s,
  8      (select distinct sid from v$mystat) m,
  9      (select to_number(value)/1024 blk_size_kb
10          from v$parameter where name='db_block_size')
11  where
12      m.sid       =   s.sid
13  and ses_addr    =   saddr;
UNDO_USED_BLK UNDO_USED_KB LOGICAL_IO CONSISTENT_GETS
            7           56        337             227
SQL> rollback;
Rollback complete.
SQL> update t set a = replace(a,'x','y'),
  2    b = replace(b,'y','x');
10000 rows updated.
SQL> select
  2      used_ublk undo_used_blk,
  3      used_ublk * blk_size_kb undo_used_kb,
  4      log_io logical_io,
  5      cr_get consistent_gets
  6  from
  7      v$transaction, v$session s,
  8      (select distinct sid from v$mystat) m,
  9      (select to_number(value)/1024 blk_size_kb
10          from v$parameter where name='db_block_size')
11  where
12      m.sid       =   s.sid
13  and ses_addr    =   saddr;
UNDO_USED_BLK UNDO_USED_KB LOGICAL_IO CONSISTENT_GETS
          626         5008      31898             594
SQL>>
- To prevent tying up the entire table
They don't know much about Oracle these DBAs do they, what exactly do they mean by "tying up the table"?
Maybe they didn't get past the 2 Day DBA manual to the Concepts guide yet?
http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14220/consist.htm#i13945
>
- And the most important, replicated transactions
must be reasonably small for throughout across the
WAN
I don't know what replication engine is being used, but the loop approach uses a huge amount more of REDO than a simple set based update. Most replication applies the REDO to the remote database to synch it up. The loop will cause more data to be transferred over the WAN than a single update.
>
Either way, I want to optimize this code as much as
possible. In fact, today I found a need to do a
similar update again...
Just do the update. It uses less resources and is faster becasue of it. The slow approach does not use fewer database resources because you are throttling it. It is slower because it requires more of everything.