FAST enabled MView takes ages to refresh

Question

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

Answer 1

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.