In passing – if you’re trying to track down a problem, then it’s best to start tailoring your queries to give yourself the information you need to see. For example, it makes things harder to grasp if you report “AVG_BUFFER_MB” when (a) you’re looking at one query, and (b) you’re interested in the number of buffer visits.

I have tested update on similer test tables in 9i and 10g. Buffer gets was alarmingly high on 11g compared to 10g.

Here is my test.

Oracle 10g. (8K Block size, buffer cached flushed before test executed, no other operation running while this testing).

SQL> update pateld.table_on_network_storage set segmentation='TEST';

1119998 rows updated.

Elapsed: 00:01:58.25

system@WFLDEV> SELECT
  2  executions,
  3 disk_reads*8/1024/executions                avg_disk_read_MB,
  4  buffer_gets*8/1024/executions                   avg_buffer_MB,
  5  direct_writes*8/1024                                      avg_write_MB,
  6  (disk_reads*8/1024 +direct_writes*8/1024)/ (elapsed_time/1000000) /executions AVG_IO_MB_SECOND,
  7  (elapsed_time/1000000)/executions                         avg_elapsed,
  8  cpu_time/1000000/executions                                      avg_cpu
  9  FROM
 10   v$sql a
 11  WHERE
 12              sql_id= '01s561a8yytpu';

EXECUTIONS AVG_DISK_READ_MB AVG_BUFFER_MB AVG_WRITE_MB AVG_IO_MB_SECOND AVG_ELAPSED    AVG_CPU
---------- ---------------- ------------- ------------ ---------------- ----------- ----------
         1       1003.35156    10021.0234            0       8.69134954  115.442551       77.5

Here I can see 10021 MB Buffer gets.

Oracle 11g: (Block size 16K, Buffer cache flushed before running this query, no other job/sql running while this test)

SQL> update pateld.table_on_network_storage set segmentation='TEST';

1119998 rows updated.

Elapsed: 00:05:24.88

system@DWODSU01> SELECT
  2  executions,
  3  disk_reads*16/1024/executions                avg_disk_read_MB,
  4  buffer_gets*16/1024/executions               avg_buffer_MB,
  5  direct_writes*16/1024                             avg_write_MB,
  6  (disk_reads*16/1024 +direct_writes*16/1024)/ (elapsed_time/1000000) /executions AVG_IO_MB_SECOND,
  7  (elapsed_time/1000000)/executions                 avg_elapsed,
  8  cpu_time/1000000/executions                        avg_cpu
  9  FROM
 10   v$sql a
 11  WHERE
 12              sql_id= 'b8qv4rxv2c30d';

EXECUTIONS AVG_DISK_READ_MB AVG_BUFFER_MB AVG_WRITE_MB AVG_IO_MB_SECOND AVG_ELAPSED    AVG_CPU
---------- ---------------- ------------- ------------ ---------------- ----------- ----------
         1          1997.25    39049.8125            0       6.29627302  317.211467     105.21

system@DWODSU01>

I can see very high 39049 MB buffer gets. Execution time also 5 times more compared to 10g database.

Both 10g and 11g servers are similer CPU and memory (also SGA) confuguration.

Thx

Dilip Patel.

I think there are several questions we could ask before coming up with the best solution. For example – since you’re updating every row would you be allowed to do something like:

create new_table nologging as
select newvalue1, newvalue2, {rest of columns} from old table;
create new_indexes
rename old_table ...
rename new_table ...
rename new_indexes
drop old table


If you can’t play games with dropping and recreating, have you tried something like:

update /*+ index(pk index) */ table set ... where pk is not null;


Could you do an update in parallel ?
Can you disable and recreate (nologging) any indexes that would otherwise be affected by the update ?

UPDATE test_table
SET col1 = newvalue1,
col2 = newvalue2;

Any help is appreciated.

Chris

I did a quick test just before supplying the suggestions in this thread of the Oracle Forum:

The results seemed to have been quite beneficial

Update: This thread has since been removed from OTN thanks to the comments made by one of the posters – unfortunately I don’t have a backup, but the point was that the strategy works for deletes, not just updates.

The answer was that in both cases delayed index maintenance took place. The index entries were sorted and updated after the table update was complete – whether the driving access path was a tablescan or index.

Is this true when we do a delete. I have a batch program which does an average of two million rows every day but it does thru index scan, so I am not worried. But I am curious.

Thanks
CT