Commit performance on table with Fast Refresh MV

Question

Hi Everyone,
Trying to wrap my head around fast refresh performance and why I'm seeing (what I would consider) high disk/query numbers associated with updating the MV_LOG in a TKPROF.
The setup.
(Oracle 10.2.0.4.0)
Base table:
SQL> desc action;
Name                                      Null?    Type
PK_ACTION_ID                              NOT NULL NUMBER(10)
CATEGORY                                           VARCHAR2(20)
INT_DESCRIPTION                                    VARCHAR2(4000)
EXT_DESCRIPTION                                    VARCHAR2(4000)
ACTION_TITLE                              NOT NULL VARCHAR2(400)
CALL_DURATION                                      VARCHAR2(6)
DATE_OPENED                               NOT NULL DATE
CONTRACT                                           VARCHAR2(100)
SOFTWARE_SUMMARY                                   VARCHAR2(2000)
MACHINE_NAME                                       VARCHAR2(25)
BILLING_STATUS                                     VARCHAR2(15)
ACTION_NUMBER                                      NUMBER(3)
THIRD_PARTY_NAME                                   VARCHAR2(25)
MAILED_TO                                          VARCHAR2(400)
FK_CONTACT_ID                                      NUMBER(10)
FK_EMPLOYEE_ID                            NOT NULL NUMBER(10)
FK_ISSUE_ID                               NOT NULL NUMBER(10)
STATUS                                             VARCHAR2(80)
PRIORITY                                           NUMBER(1)
EMAILED_CUSTOMER                                   TIMESTAMP(6) WITH LOCAL TIME
                                                     ZONE
SQL> select count(*) from action;
  COUNT(*)
   1388780MV was created
create materialized view log on action with sequence, rowid
(pk_action_id, fk_issue_id, date_opened)
including new values;
-- Create materialized view
create materialized view issue_open_mv
build immediate
refresh fast on commit
enable query rewrite as
select  fk_issue_id issue_id,
     count(*) cnt,
     min(date_opened) issue_open,
     max(date_opened) last_action_date,
     min(pk_action_id) first_action_id,
     max(pk_action_id) last_action_id,
     count(pk_action_id) num_actions
from    action
group by fk_issue_id;
exec dbms_stats.gather_table_stats('tg','issue_open_mv')
SQL> select table_name, last_analyzed from dba_tables where table_name = 'ISSUE_OPEN_MV';
TABLE_NAME                     LAST_ANAL
ISSUE_OPEN_MV                  15-NOV-10
*note: table was created a couple of days ago *
SQL> exec dbms_mview.explain_mview('TG.ISSUE_OPEN_MV');
CAPABILITY_NAME                P REL_TEXT MSGTXT
PCT                            N
REFRESH_COMPLETE               Y
REFRESH_FAST                   Y
REWRITE                        Y
PCT_TABLE                      N ACTION   relation is not a partitioned table
REFRESH_FAST_AFTER_INSERT      Y
REFRESH_FAST_AFTER_ANY_DML     Y
REFRESH_FAST_PCT               N          PCT is not possible on any of the detail tables in the mater
REWRITE_FULL_TEXT_MATCH        Y
REWRITE_PARTIAL_TEXT_MATCH     Y
REWRITE_GENERAL                Y
REWRITE_PCT                    N          general rewrite is not possible or PCT is not possible on an
PCT_TABLE_REWRITE              N ACTION   relation is not a partitioned table
13 rows selected.Fast refresh works fine. And the log is kept quite small.
SQL> select count(*) from mlog$_action;
  COUNT(*)
         0When I update one row in the base table:
var in_action_id number;
exec :in_action_id := 398385;
UPDATE action
SET emailed_customer = SYSTIMESTAMP
WHERE pk_action_id = :in_action_id
AND DECODE(emailed_customer, NULL, 0, 1) = 0
commit;I see the following happen via tkprof...
INSERT /*+ IDX(0) */ INTO "TG"."MLOG$_ACTION" (dmltype$$,old_new$$,snaptime$$,
  change_vector$$,sequence$$,m_row$$,"PK_ACTION_ID","DATE_OPENED",
  "FK_ISSUE_ID")
VALUES
(:d,:o,to_date('4000-01-01:00:00:00','YYYY-MM-DD:HH24:MI:SS'),:c,
  sys.cdc_rsid_seq$.nextval,:m,:1,:2,:3)
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.01          0          0          0           0
Execute      2      0.00       0.03          4          4          4           2
Fetch        0      0.00       0.00          0          0          0           0
total        3      0.00       0.04          4          4          4           2
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      2  SEQUENCE  CDC_RSID_SEQ$ (cr=0 pr=0 pw=0 time=28 us)
Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  db file sequential read                         4        0.01          0.01
update "TG"."MLOG$_ACTION" set snaptime$$ = :1
where
snaptime$$ > to_date('2100-01-01:00:00:00','YYYY-MM-DD:HH24:MI:SS')
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.01          0          0          0           0
Execute      1      0.94       5.36      55996      56012          1           2
Fetch        0      0.00       0.00          0          0          0           0
total        2      0.94       5.38      55996      56012          1           2
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      0  UPDATE  MLOG$_ACTION (cr=56012 pr=55996 pw=0 time=5364554 us)
      2   TABLE ACCESS FULL MLOG$_ACTION (cr=56012 pr=55996 pw=0 time=46756 us)
Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  db file scattered read                       3529        0.02          4.91
select dmltype$$, max(snaptime$$)
from
"TG"."MLOG$_ACTION"  where snaptime$$ <= :1  group by dmltype$$
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        2      0.70       0.68      55996      56012          0           1
total        4      0.70       0.68      55996      56012          0           1
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      1  SORT GROUP BY (cr=56012 pr=55996 pw=0 time=685671 us)
      2   TABLE ACCESS FULL MLOG$_ACTION (cr=56012 pr=55996 pw=0 time=1851 us)
Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  db file scattered read                       3529        0.00          0.38
delete from "TG"."MLOG$_ACTION"
where
snaptime$$ <= :1
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.71       0.70      55946      56012          3           2
Fetch        0      0.00       0.00          0          0          0           0
total        2      0.71       0.70      55946      56012          3           2
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      0  DELETE  MLOG$_ACTION (cr=56012 pr=55946 pw=0 time=702813 us)
      2   TABLE ACCESS FULL MLOG$_ACTION (cr=56012 pr=55946 pw=0 time=1814 us)
Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  db file scattered read                       3530        0.00          0.39
  db file sequential read                        33        0.00          0.00
********************************************************************************Could someone explain why are the SELECT/UPDATE/DELETE on MLOG$_ACTION so "expensive" when there should only be 2 rows (old value and new value) in that log after an update? Is there anything I could do to improve the performance of the update?
Let me know if you require more info...would be glad to provide it.

Answer 1

Brilliant. Thanks.
I owe you a beverage.
SQL> set autotrace on
SQL> select count(*) from MLOG$_ACTION;
  COUNT(*)
         0
Execution Plan
Plan hash value: 2727134882
| Id  | Operation          | Name         | Rows  | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |              |     1 | 12309   (1)| 00:02:28 |
|   1 |  SORT AGGREGATE    |              |     1 |            |          |
|   2 |   TABLE ACCESS FULL| MLOG$_ACTION |     1 | 12309   (1)| 00:02:28 |
Note
   - dynamic sampling used for this statement
Statistics
          4  recursive calls
          0  db block gets
      56092  consistent gets
      56022  physical reads
          0  redo size
        410  bytes sent via SQL*Net to client
        400  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed
SQL> truncate table MLOG$_ACTION;
Table truncated.
SQL> select count(*) from MLOG$_ACTION;
  COUNT(*)
         0
Execution Plan
Plan hash value: 2727134882
| Id  | Operation          | Name         | Rows  | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |              |     1 |     2   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE    |              |     1 |            |          |
|   2 |   TABLE ACCESS FULL| MLOG$_ACTION |     1 |     2   (0)| 00:00:01 |
Note
   - dynamic sampling used for this statement
Statistics
          1  recursive calls
          1  db block gets
          6  consistent gets
          0  physical reads
         96  redo size
        410  bytes sent via SQL*Net to client
        400  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processedJust for fun...comparison of the TKPROF.
Before:
update "TG"."MLOG$_ACTION" set snaptime$$ = :1
where
snaptime$$ > to_date('2100-01-01:00:00:00','YYYY-MM-DD:HH24:MI:SS')
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.01          0          0          0           0
Execute      1      0.94       5.36      55996      56012          1           2
Fetch        0      0.00       0.00          0          0          0           0
total        2      0.94       5.38      55996      56012          1           2
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      0  UPDATE  MLOG$_ACTION (cr=56012 pr=55996 pw=0 time=5364554 us)
      2   TABLE ACCESS FULL MLOG$_ACTION (cr=56012 pr=55996 pw=0 time=46756 us)
Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  db file scattered read                       3529        0.02          4.91
********************************************************************************After:
update "TG"."MLOG$_ACTION" set snaptime$$ = :1
where
snaptime$$ > to_date('2100-01-01:00:00:00','YYYY-MM-DD:HH24:MI:SS')
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          7          1           2
Fetch        0      0.00       0.00          0          0          0           0
total        2      0.00       0.00          0          7          1           2
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      0  UPDATE  MLOG$_ACTION (cr=7 pr=0 pw=0 time=79 us)
      2   TABLE ACCESS FULL MLOG$_ACTION (cr=7 pr=0 pw=0 time=28 us)
********************************************************************************