Performance degradation in Update statement

Question

Hi
I have a table t1 with 3 of the columns as :- c1 ,c2,c3.
there is a non unique index on c2 ,c3.
I am using an update statement as : update t1 set c1="value" where c2="some_value" and c3="some_value2" ;
this works fine in case the number of rows for the same c2 and c3 are less (~100) but takes a large time when ~30,000.
And it has to be run many times in my application (time out is occuring now)
Can anybody suggest a solution ?
Thanks
Message was edited by:
user580975

Answer 1

First off, setting a table to NOLOGGING does not affect the rate of redo generation unless you are also doing direct-path inserts (which is obviously not the case here and which come with their own set of issues). Note that the amount of redo being generated in these two examples is quite similar.
SCOTT @ jcave102 Local> create table all_obj_cpy as select * from all_objects;
Table created.
Elapsed: 00:00:10.78
SCOTT @ jcave102 Local> set autotrace traceonly;
SCOTT @ jcave102 Local> alter table all_obj_cpy logging;
Table altered.
Elapsed: 00:00:00.01
SCOTT @ jcave102 Local> update all_obj_cpy
  2  set last_ddl_time = sysdate - 1;
42511 rows updated.
Elapsed: 00:00:01.45
Execution Plan
Plan hash value: 1645016300
| Id  | Operation          | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | UPDATE STATEMENT   |             | 43776 |   384K|   137   (3)| 00:00:02 |
|   1 |  UPDATE            | ALL_OBJ_CPY |       |       |            |          |
|   2 |   TABLE ACCESS FULL| ALL_OBJ_CPY | 43776 |   384K|   137   (3)| 00:00:02 |
Note
   - dynamic sampling used for this statement
Statistics
        556  recursive calls
      46075  db block gets
       1558  consistent gets
          0  physical reads
   13575764  redo size
        924  bytes sent via SQL*Net to client
        965  bytes received via SQL*Net from client
          6  SQL*Net roundtrips to/from client
          6  sorts (memory)
          0  sorts (disk)
      42511  rows processed
SCOTT @ jcave102 Local> alter table all_obj_cpy nologging;
Table altered.
Elapsed: 00:00:00.01
SCOTT @ jcave102 Local> update all_obj_cpy
  2  set last_ddl_time = sysdate - 2;
42511 rows updated.
Elapsed: 00:00:01.32
Execution Plan
Plan hash value: 1645016300
| Id  | Operation          | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | UPDATE STATEMENT   |             | 43776 |   384K|   137   (3)| 00:00:02 |
|   1 |  UPDATE            | ALL_OBJ_CPY |       |       |            |          |
|   2 |   TABLE ACCESS FULL| ALL_OBJ_CPY | 43776 |   384K|   137   (3)| 00:00:02 |
Note
   - dynamic sampling used for this statement
Statistics
        561  recursive calls
      44949  db block gets
       1496  consistent gets
          0  physical reads
   12799600  redo size
        924  bytes sent via SQL*Net to client
        965  bytes received via SQL*Net from client
          6  SQL*Net roundtrips to/from client
          6  sorts (memory)
          0  sorts (disk)
      42511  rows processedSecond, if you did manage to do an unlogged operation, make absolutely certain you understand the recovery implications. You must do a complete backup of the database after an unlogged operation or the table will not be recovered in the event of a database failure. If you have a standby database for disaster recovery, unlogged operations would cause the standby to be useless (hence the option to force logging at the tablespace and/or database level).
While it's certainly possible that this is an Oracle server configuration problem, it would be relatively tough to configure a system so that a 30,000 row update would force excessive log switches. If it were a configuration problem, you'd expect that any update of 30,000 rows would be slow and that multiple sessions running smaller updates would also be slow, but I don't believe that describes the symptoms the original poster is concerned about.
Justin