Fast Refresh mview performance

Hi,
I'm actually facing with Fast Refresh Mview performace problems and i would like to know what is the possible improvments for the fast refresh procedure:
- base table is 1 500 000 000 rows partitions by day , subparttion by has (4)
- mlog partition by hash (4) with indexes on pk and snaptime
- mview partition by day subpartition by hash (4)
10 000 000 insertions / day in base table/mlog
What improvment or indexes can i add to improve fast refresh ?
Thanks for help

Hi,
Which DB version are you using?
Did you have a look at the MV refresh via Partition Change Tracking (PCT)?
http://download.oracle.com/docs/cd/B19306_01/server.102/b14223/advmv.htm#sthref575
If it's possible to use PCT, it would probably improve a lot the performance of the refresh of your MV.
Regards
Maurice

Similar Messages

Fast refreshable mviews vs. cdc

im currently working on a new data warehouse environment. i need to create an ods schema for each of the operational systems in my warehouse.
i've looked at two of 10gR2 prefered technologies for this task:
fast refreshable materialized view and change data capture.
i would to know what is the difference between this two approaches.
in my understanding, there both cause a performance overhead and require some amount of additional work on each dml operations. in addition , there both work on the method of capturing changes from a table and applying them on a target database.
the only difference i could think of is that cdc capture changes from the redo log so that commit time on the operational system wont be affected (as much as it would when logging a dml operation in a mview log).

dba_snapshot_refresh_times or dba_mview_refresh_times would help.
select job, last_date last_refresh, next_date next_refresh, total_time,what from dba_jobs where what like '%dbms_refresh%'
This will work only if the refresh is scheduled to run through job queue.

Fast Refreshable MVIEW

Trying to create a fast refresh materialized view based on a simple join of two tables over a database link oracle gives a 'COMPLEX QUERY' error (ORA-12015).
Logging on the origin tables should be ok as creating the MVIEW based on the same select but in the database where the origin tables are poses no problem. The logging tables are created based on primary key and include rowid.
The select on which the MVIEW should be created is someting like:
select
tab1.rowidn id1,
tab2.rowidn id2,
tab1.key_idn key1,
tab2.key_idn key2
from table1@other_db tabl,table2@other_db tab2
where tab1.key_idn = tab2.key_idn)
Does this mean it is impossible to create a fast refresh materialized view over a database link when a join condition is involved?

Replace the ANSI Joins with Conventional Joins.
Change this :
SELECT * FROM V_FIRST VF
LEFT JOIN R4
ON VF.ID=R4.ID
LEFT JOIN R5
ON VF.ID=R5.IDto this :
SELECT VF.* FROM V_FIRST VF, R4, R5
WHERE VF.ID=R4.ID
AND VF.ID=R5.IDHemant K Chitale

Error when try to Fast Refresh Mview ......

Guys d u have an idea .....
why when I running job that fast refresh an mview.
I alwayas got error :
ORA-12008: error in materialized view refresh path
ORA-01555: snapshot too old: rollback segment number 2268 with name
"_SYSSMU2268$" too small
undo_management set to AUTO.
undo tablespace has enough space.
I have mview log on master database.
regards,
indrajati

damorgan's request for more information is completele relevant.
However, "Snapshot to old" is often due to insufficient rollback/undo space. What happens (grossly simplified) is that when re-reading stored data the database finds it has been overwritten and raises the error. The suggested fix is usually to increase rollback/undo space.

How much time My FAST refreshable MVIEWS taken to refresh in last refresh?

How to find the DURATION of last FAST refresh of MVIEWS?
Refresh duration will vary depends on data change on base table. I would like to find the duration of last refresh

dba_snapshot_refresh_times or dba_mview_refresh_times would help.
select job, last_date last_refresh, next_date next_refresh, total_time,what from dba_jobs where what like '%dbms_refresh%'
This will work only if the refresh is scheduled to run through job queue.

Fast refresh Mview

hi
plz tell me why am not able to create a Fast refresh materialized View
SQL> CONNECT SCHEMA1/SCHEMA@HOST;
Connected.
SQL> CREATE MATERIALIZED VIEW LOG ON COMPANY WITH PRIMARY KEY;
Materialized view log created.
SQL> CREATE MATERIALIZED VIEW LOG ON EMPLOYEE WITH PRIMARY KEY;
Materialized view log created.
SQL> GRANT SELECT ON MLOG$_COMPANY TO SCHEMAREP;
Grant succeeded.
SQL> GRANT SELECT ON MLOG$_EMPLOYEE TO SCHEMAREP;
Grant succeeded.
SQL> CONNECT SCHEMAREP/REPORTS@HOST;
Connected.
SQL>
SQL> CREATE MATERIALIZED VIEW mview_1
2 REFRESH fast on DEMAND
3 AS
4 SELECT EMPLOYEE.EMPLOYEE_num
5 FROM schema1.COMPANY company,schema1.EMPLOYEE EMPLOYEE
6 WHERE COMPANY.COMPANY_ID=EMPLOYEE.COMPANY_ID;
FROM schema1.COMPANY company,schema1.EMPLOYEE EMPLOYEE
ERROR at line 5:
ORA-12052: cannot fast refresh materialized view SCHEMAREP.MVIEW_1
SQL>

You would be able to answer yourself your question, if you
a) read the restrictions for fast refresheable materialized view at
http://download.oracle.com/docs/cd/B19306_01/server.102/b14223/basicmv.htm#sthref537
b) make you familiar with the packaged procedure dbms_mview.explain_mview
Best regards
Maxim

Fast refreshable Mview question.

Hi All,
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
PL/SQL Release 11.1.0.7.0 - Production
"CORE 11.1.0.7.0 Production"
TNS for Linux: Version 11.1.0.7.0 - Production
NLSRTL Version 11.1.0.7.0 - Production
Can't we make a Fast refresh materialized view which has UNIONALL operator on REMOTE DATA BASE..?
REMOTEDB: R
TARGETDB:T
Note: all these tables are in Remote DB(R) and I want to create a Mat view on Target DB (T).
create or replace view V_FIRST
As
select * from R1
UNION ALL
select * from R2
UNION ALL
select * from R3Now i am creating a Fast refresh Mat view
CREATE MATERIALIZED VIEW REMOTE_MV
REFRESH FAST ON DEMAND AS
SELECT * FROM V_FIRST VF
LEFT JOIN R4
ON VF.ID=R4.ID
LEFT JOIN R5
ON VF.ID=R5.IDHere i am getting error can not create a fast refreshable mat view on a complex query.
I think we can create a fast refreshable Mat view which has UNION ALL operator... I don't know about remote tables.
How to achieve this... with out splitting the Mat view ?. Is there any way..?
Appreciate your help.
Thanks,
Mike

Replace the ANSI Joins with Conventional Joins.
Change this :
SELECT * FROM V_FIRST VF
LEFT JOIN R4
ON VF.ID=R4.ID
LEFT JOIN R5
ON VF.ID=R5.IDto this :
SELECT VF.* FROM V_FIRST VF, R4, R5
WHERE VF.ID=R4.ID
AND VF.ID=R5.IDHemant K Chitale

Regarding error in fast refresh for Materialized

ORA-12015: cannot create a fast refresh materialized view from a complex query
CREATE MATERIALIZED VIEW CRESTELVIEWSDEV510.MVCONTENTHISTORY
TABLESPACE CRESTELVIEWSDEV510
NOCACHE
LOGGING
NOCOMPRESS
NOPARALLEL
BUILD IMMEDIATE
REFRESH FAST
ENABLE QUERY REWRITE
AS
SELECT a.DAY, a.contentname,
SUM
(CASE
WHEN (b.subscriptionstartdate) <= (a.DAY)
AND ((CASE
WHEN b.subscriptionenddate IS NOT NULL
THEN (a.DAY)
ELSE TO_DATE ('01/20/1990', 'MM/DD/YYYY')
END
) <=
(CASE
WHEN b.subscriptionenddate IS NOT NULL
THEN (b.subscriptionenddate)
ELSE TO_DATE ('01/20/1990', 'MM/DD/YYYY')
END
THEN 1
ELSE 0
END
) COUNT,
COUNT
(CASE
WHEN (b.subscriptionstartdate) <= (a.DAY)
AND ((CASE
WHEN b.subscriptionenddate IS NOT NULL
THEN (a.DAY)
ELSE TO_DATE ('01/20/1990', 'MM/DD/YYYY')
END
) <=
(CASE
WHEN b.subscriptionenddate IS NOT NULL
THEN (b.subscriptionenddate)
ELSE TO_DATE ('01/20/1990', 'MM/DD/YYYY')
END
THEN 1
ELSE 0
END
) cnt
FROM TBLTDATEWISECONTENT a,
(SELECT TRUNC (a.subscriptionstartdate) subscriptionstartdate,
TRUNC (a.subscriptionenddate) subscriptionenddate, b.NAME,
b.contentid
FROM syntbltcontentsubscrhistory a, syntblmcontent b
WHERE b.contentid = a.contentid(+)) b
WHERE a.contentid = b.contentid(+)
AND a.DAY = b.subscriptionstartdate(+)
GROUP BY a.contentname, a.DAY;
while creation time of this Materialized I have receive above error ORA-12015
I have also crated log with Primary on all base tables and index on column that is in where clause.
Kindly provide solution .
I want to create this MV with FAST Refresh.
Regards,
nayana chavda.

What's your Oracle version?
The error is pretty self explanatory. You can not build fast refresh MView with complex query.
check Oracle document,
http://download.oracle.com/docs/cd/B19306_01/server.102/b14226/repmview.htm#BABEEHGJ
To be fast refreshed, the defining query for a materialized view must observe certain restrictions. If you require a materialized view whose defining query is more general and cannot observe the restrictions, then the materialized view is complex and cannot be fast refreshed.
...

FAST enabled MView takes ages to refresh

Hi All,
I have a materlialized view which is based on a single fact table ( OAS_BALANCE_UNIONED 11,445,156 rows) and a bunch of dimension tables each containing limited number of rows (a typical start schema).
The conditioins to make the mview fast refreshable have been met so the mview created successfully with the FAST option.
The mview then worked just fine after than and had been refreshing FAST (6 minutes) for the whole day till other mviews started to refresh in the same time. Some of those mviews read from some of the base tables of the mview in question. Since then, the mivew has started to take ages (3 hours) to refresh. There is surely something wrong because the COMPLETE refresh was faster than that.
Later, I stopped all the refresh jobs of the other mviews. Yet, the FAST mview still has the same problem of taking ages to refresh.
When I monitored the session that refreshes the mview, I noticed in the "Long Ops" that
most of the time is spent on a step named as "Hash Join" (it appears in the Message column). Hash join occurrs because of the outer join.
Why my FAST mview suddenly started to take so long time to refresh?
How can I make my FAST mivew really refresh fast?
Technical Details are below:
OS: Windows 2003 32-bit
DB version: Oracle 10g R1 ( 10.1.0.2.0 )
CREATE MATERIALIZED VIEW FACT_BAL_MV
BUILD DEFERRED
REFRESH FAST ON DEMAND
WITH PRIMARY KEY
AS
SELECT B.cmpcode BAL_KEY,
       B.CMPCODE,
       B.YR,
       B.PERIOD,
       B.BALCODE,
       B.CURCODE,
       B.REPBASIS,
       TO_NUMBER (B.YR || LPAD (B.PERIOD, 2, 0)) DIM_PERIOD_MV,
       D_CMP.DIM_KEY DIM_COMPANY,
       D_CUR.DIM_KEY DIM_CURRENCY,
       D_EL_1.DIM_KEY DIM_EL_1,
       D_EL_2.DIM_KEY DIM_EL_2,
       D_EL_3.DIM_KEY DIM_EL_3,
       D_EL_4.DIM_KEY DIM_EL_4,
       GRP_1_P_EL.DIM_KEY DIM_GRP_1_P_EL,
       D_GRP_1_B_EL.DIM_KEY DIM_GRP_1_B_EL,
       D_GRP_1_K_EL.DIM_KEY DIM_GRP_1_K_EL,
       D_GRP_2_D_EL.DIM_KEY DIM_GRP_2_D_EL,
       D_GRP_3_E_EL.DIM_KEY D_GRP_3_E_EL,
       B.ROWID X_OB_ROWID,
       D_CMP.ROWID X_CMP_ROWID,
       D_CUR.ROWID X_CUR_ROWID,
       D_EL_1.ROWID X_EL_1_ROWID,
       D_EL_2.ROWID X_EL_2_ROWID,
       D_EL_3.ROWID X_EL_3_ROWID,
       D_EL_4.ROWID X_EL_4_ROWID,
       GRP_1_P_EL.ROWID X_GRP_1_P_EL_ROWID,
       GRP_1_P.ROWID X_GRP_1_P_ROWID,
       D_GRP_1_B_EL.ROWID X_GRP_1_B_EL_ROWID,
       D_GRP_1_B.ROWID X_GRP_1_B_ROWID,
       D_GRP_1_K_EL.ROWID X_GRP_1_K_EL_ROWID,
       D_GRP_1_K.ROWID X_GRP_1_K_ROWID,
       D_GRP_2_D_EL.ROWID X_GRP_2_D_EL_ROWID,
       D_GRP_2_D.ROWID X_GRP_2_D_ROWID,
       D_GRP_3_E_EL.ROWID X_GRP_3_E_EL_ROWID,
       D_GRP_3_E.ROWID X_GRP_3_E_ROWID
FROM CLVE_STAGING.OAS_BALANCE_UNIONED B,
       FINANCE.DW_DIM_COMPANY D_CMP,
       FINANCE.DW_DIM_CURRENCY D_CUR,
       FINANCE.DW_DIM_EL_1 D_EL_1,
       FINANCE.DW_DIM_EL_2 D_EL_2,
       FINANCE.DW_DIM_EL_3 D_EL_3,
       FINANCE.DW_DIM_EL_4 D_EL_4,
       FINANCE.DW_DIM_GRP_1_P_EL GRP_1_P_EL,
       FINANCE.DW_DIM_GRP_1_P GRP_1_P,
       FINANCE.DW_DIM_GRP_1_B_EL D_GRP_1_B_EL,
       FINANCE.DW_DIM_GRP_1_B D_GRP_1_B,
       FINANCE.DW_DIM_GRP_1_K_EL D_GRP_1_K_EL,
       FINANCE.DW_DIM_GRP_1_K D_GRP_1_K,
       FINANCE.DW_DIM_GRP_2_D_EL D_GRP_2_D_EL,
       FINANCE.DW_DIM_GRP_2_D D_GRP_2_D,
       FINANCE.DW_DIM_GRP_3_E_EL D_GRP_3_E_EL,
       FINANCE.DW_DIM_GRP_3_E D_GRP_3_E
WHERE     B.CMPCODE = D_CMP.CODE
       AND (B.CMPCODE = D_CUR.CMPCODE(+) AND B.CURCODE = D_CUR.CODE(+))
       AND (B.CMPCODE = D_EL_1.CMPCODE(+) AND B.EL1 = D_EL_1.EL_CODE(+))
       AND (B.CMPCODE = D_EL_2.CMPCODE(+) AND B.EL2 = D_EL_2.EL_CODE(+))
       AND (B.CMPCODE = D_EL_3.CMPCODE(+) AND B.EL3 = D_EL_3.EL_CODE(+))
       AND (B.CMPCODE = D_EL_4.CMPCODE(+) AND B.EL3 = D_EL_4.EL_CODE(+))
       AND (GRP_1_P_EL.CMPCODE = GRP_1_P.CMPCODE(+)
            AND GRP_1_P_EL.GRP_CODE = GRP_1_P.GRP_CODE(+))
       AND (B.CMPCODE = GRP_1_P_EL.CMPCODE(+)
            AND B.EL1 = GRP_1_P_EL.EL_CODE(+))
       AND (D_GRP_1_B_EL.CMPCODE = D_GRP_1_B.CMPCODE(+)
            AND D_GRP_1_B_EL.GRP_CODE = D_GRP_1_B.GRP_CODE(+))
       AND (B.CMPCODE = D_GRP_1_B_EL.CMPCODE(+)
            AND B.EL1 = D_GRP_1_B_EL.EL_CODE(+))
       AND (D_GRP_1_K_EL.CMPCODE = D_GRP_1_K.CMPCODE(+)
            AND D_GRP_1_K_EL.GRP_CODE = D_GRP_1_K.GRP_CODE(+))
       AND (B.CMPCODE = D_GRP_1_K_EL.CMPCODE(+)
            AND B.EL1 = D_GRP_1_K_EL.EL_CODE(+))
       AND (D_GRP_2_D_EL.CMPCODE = D_GRP_2_D.CMPCODE(+)
            AND D_GRP_2_D_EL.GRP_CODE = D_GRP_2_D.GRP_CODE(+))
       AND (B.CMPCODE = D_GRP_2_D_EL.CMPCODE(+)
            AND B.EL2 = D_GRP_2_D_EL.EL_CODE(+))
       AND (D_GRP_3_E_EL.CMPCODE = D_GRP_3_E.CMPCODE(+)
            AND D_GRP_3_E_EL.GRP_CODE = D_GRP_3_E.GRP_CODE(+))
       AND (B.CMPCODE = D_GRP_3_E_EL.CMPCODE(+)
            AND B.EL3 = D_GRP_3_E_EL.EL_CODE(+));
CREATE INDEX FINANCE.DW_FACT_BAL_MV_INX
ON FACT_BAL_MV (X_OB_ROWID);
SQL> select count(X_OB_ROWID) from FACT_BAL_MV ;
COUNT(X_OB_ROWID)
         11444816
Elapsed: 00:00:27.85
SQL> select bytes/1024/1024/1024 GB from
user_segments where segment_name='FACT_BAL_MV';
        GB
4.4296875search id: redcorolla

Hard to say why the refresh is now slow. Possibilties include
* system resources implemented by the fast refresh
* something changed on the query making the background query run slowly
Look at the query first. 18 tables, with almost every join an outer join. Some of the tables appear more than once in the query.
Get an executioion plan to see how the query is being executed.

Mview Fast Refresh Problem

Hello,
We run a fast refresh for a particular mview. I have the mview log created on the primary db (base table) and the mview created on another reporting database.
The fast refresh seems to be fine throughout the day but at the end of a day it fails to do the fast refresh and i'm forced to do a complete refresh everyday which fixes it but this cycle continues until the end of day when it breaks again.
If you notice in the next date column the refresh date turns to 01-JAN-00, not sure why this happens and this is causing the problem.
JOB REFRESH_JOB LAST_DATE NEXT_DATE NEXT_SEC BROKEN
70 CON_SYS"."MV_BRICKNW" 04-AUG-10 01-JAN-00 00:00:00 Y
75 CON_SYS"."MV_BRICKNWCAN" 04-AUG-10 01-JAN-00 00:00:00 Y
Could someone please tell me what the problem is.

The Refresh Date gets reset when the job is Broken (which you see as BROKEN='Y'). The job is Broken when 16 consecutive attempts have failed (which you would see in FAILURE_COUNT).
You have to find out why it fails -- fails 16 times. There seems to be an issue with the date/time logic OR one of the source objects probably gets dropped or becomes unavailable close to the end of the day.
Hemant K Chitale

Mview fast refresh taking longer than complete refresh

Hi there,
We have a mview which takes about an hour to refresh in complete mode. Created all the mview logs and refreshing via fast method but this takes longer.
When all the mview logs empty works fine as fast refresh and far far quicker as would expect. Tried upadting one of records on base table called todays_date which simply stores todays date to get around fast refresh restriction with sysdate.
Anybody any idea why so slow?
Also wondering if better approach. Thought about just having an aggregate table and processing the inserts in MLOG$_TRANS_TABLE via a merge statement. Also heard about change data capture.
Any thoughts/suggestions welcome.
Many Thanks

Well, search with your post subject on this forum. There are a lot of threads discussing the same.

Commit performance on table with Fast Refresh MV

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.

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)
********************************************************************************

Snapshot fast refresh performance

I have a master table with a snapshot log
on the primary database (8.1.6 Oracle and
AiX). There are 20,000 rows in the snapshot
log which take about 6 hrs to perform a fast
refresh to a snapshot database on the same
set up.
i am looking for some ways to tune the snapshot to decrease the time of the refresh.

The refresh time is primarily dependent upon the speed of the remote connection. Also it is not so much the number of rows as it is the size of the rows. As far as tuning the refresh you can check to see if the master snapshot log HWM has grown very large. The refresh will perform a full table scan when it determines which rows it needs to refresh.

How to speed up fast refresh of materialized view without primary key

Thought I'd share this info, as I couldn't find anything on here to help me diagnose the issue:
I had a materialized view that was taking longer to perform a fast refresh than it took to perform a complete refresh. My mview had no primary key, as the base table had no primary key.
I created a trace file for the session and saw references to a column M_ROW$$ in my mview. Nowhere in the data dictionary could I find a reference to the m_row$$ column in my mview, but apparently it exists and is created automatically. After creating the index below, the fast refresh took 6 minutes to add 500k rows to the materialized view. (versus 4+ hours without the index) When I looked in the trace file, I noticed that for each row in the mview log, it first tries to update the mview with an UPDATE statement, then it performs an insert of the new data. Seems like it should be able to determine whether to perform an update or insert based on the DMLTYPE$$ column of the mview log. What was killing my performance was the UPDATE phase. Since I had no primary key on the mview, and no index on the m_row$$ column, the UPDATE phase was performing a full table scan of my mview for every row in the mview log. I was expecting it to be smart enough to only perform inserts, as the only transactions against the base table were inserts.
In summary: If you have a materialized view without a primary key, create an index on the m_row$$ column of the mview, even though no such column displays in the data dictionary.
ex:
CREATE MATERIALIZED VIEW mv_minidrr ...
CREATE INDEX pk_mv_minidrr ON mv_minidrr(m_row$$) ...

Well, there indeed is a column called M_ROW$$
Your MLOG$_EMP is nothing but the materialized view log on the base table.
SQL> create materialized view log on emp with rowid ;
Materialized view log created.
SQL> create materialized view emp_mview refresh fast on demand with rowid as select * from emp ;
Materialized view created.
SQL> desc mlog$_emp
Name                                                  Null?    Type
M_ROW$$                                                        VARCHAR2(255)
SNAPTIME$$                                                     DATE
DMLTYPE$$                                                      VARCHAR2(1)
OLD_NEW$$                                                      VARCHAR2(1)
CHANGE_VECTOR$$                                                RAW(255)
SQL> select table_name, column_name from user_tab_columns where column_name = 'M_ROW$$' ;
TABLE_NAME                     COLUMN_NAME
MLOG$_EMP                      M_ROW$$
1 row selected.
SQL>

Materialized View with Join for FAST Refresh

Hi Gurus,
Facing issues in MV with a simple join for FAST Refresh.
2 sample Tables:
1. employee
empid integer PK
empname varchar(50)
deptid integer FK
2. delta_employee
empid integer PK
empname varchar(50)
deptid integer FK
dmlflag varchar(2)
watermark integer
Code is as given below -
CREATE MATERIALIZED VIEW LOG ON work.employee
WITH SEQUENCE,rowid(empid)
INCLUDING NEW VALUES;
CREATE MATERIALIZED VIEW LOG ON work.delta_employee
WITH SEQUENCE,rowid(empid)
INCLUDING NEW VALUES;
CREATE MATERIALIZED VIEW work.MVEmployee REFRESH force on
demand with rowid AS
select e.empid,e.empname,e.deptid,d.empid t1
from work.employee e, work.delta_employee d
where e.empid = d.empid;
Able to perform Complete Refresh. Not able to use Fast Refresh for
incremental refresh.
Please help.
Thanks,
J Kumar

Found a solution,
As per oracle documentation rowid fileds should be included in the Select statement. Even though I included the rowid fields, empid in this case it still didnt work.
The implementation of the rowid column should be included with tablename.rowid instead of the tablename.columnname !
Modified script is as given below.
CREATE MATERIALIZED VIEW WORK.MVEMPLOYEE
REFRESH FORCE ON DEMAND
WITH PRIMARY KEY
AS
select e.rowid "empid",d.rowid "t1" ,e.empname,e.deptid
from work.employee e, work.delta_employee d
where e.empid = d.empid;
And It really WORKS

Fast Refresh mview performance

Similar Messages

Maybe you are looking for