Materialized view - parameter and refresh

Hi,
We are creating a Materialized view that has 2 rows for a CCID, one for this year and one for previous year with balances in 12 buckets.
We have 2 questions:
1. Can a materialized view be created with a parameter? or it can only take hard coded values?
2. Can we refresh a part of materialized view, lets say we want to refresh the balances only for this year?
Thanks

user12182208 wrote:
Hi,
We are creating a Materialized view that has 2 rows for a CCID, one for this year and one for previous year with balances in 12 buckets.
We have 2 questions:
1. Can a materialized view be created with a parameter? or it can only take hard coded values? Typically, you want a materialized view to contain a complete set of aggregate data ... so, no, parameters don't really make sense (also, the results are pre-computed unlike a regular VIEW which is just a stored query. With a MV the data is actually computed on creation unless you defer it, and takes up physical storage).
>
2. Can we refresh a part of materialized view, lets say we want to refresh the balances only for this year?
You can (depending on your Oracle Version and complexity of your materialized view) create a materialized view that does fast refreshes. If for some reason it was pertinent for you to achieve what you've asked, you could make 2 MV's and then a view that does a UNION ALL of them (the MV's would not contain overlaps), then you would just refresh the 1 MV, seems odd to me to want to do this though.
Thanks

Similar Messages

  • Materialized view (creating and complete refresh)

    Good day.
    I have a huge query that is used to create a materialized view. The query consist of 9 joins, a lot of aggregations, some subqueries, so we can say it is rather huge. The query itself executes for about 30 seconds and returns about 200 rows. The materialized view creates and refreshes for more than 30 minutes. Can someone please explain me the mechanism of materialized view creation which causes such bad performance.
    We use Oracle Database 9.2.0.4.
    Thank you in advance.

    I've fount the solution. May be it will be useful for someone not regarding that 9.2 database is less used today than 10.2.
    I studied carefully the plan of the query and the plan of insert statement that is used when creating materialized view and found the cause of trouble. Insert statements generates VIEW PUSHED PREDICATE and BITMAP CONVERSION FROM ROWIDS when parsing. Bitmap conversion can be removed by setting environment parameter btree_bitmap_plans to false (a well-known issue), but I decided not ot change the production environment. The pushed predicate can be removed by using hint NO_PUSH_PRED to each subquery used in a materialized view. This step reduced the time of materialized view creation and execution to about a minute.
    Thank everyone who tried to help.

  • Query against materialized view awful after refresh of Mview

    We have a materialized view defined to refresh complete daily at 5am. YOu can run queries against the MV alone or joining it to other tables. Results come back in 2 or 3 seconds. Once the MView refreshes at 5am - those same queries now take 15 minutes or even more sometimes to complete. WHY IS THIS HAPPENING?? Help anyone?

    okay this is better... sorry...
    this is the GOOD EXPLAIN PLAN:
    PLAN_TABLE_OUTPUT                                                                                                                                                                                                                                                                      
    | Id  | Operation                         |  Name             | Rows  | Bytes | Cost  |                                                                                                                                                                                                
    |   0 | SELECT STATEMENT                  |                   |     1 |   127 |  1665 |                                                                                                                                                                                                
    |   1 |  SORT AGGREGATE                   |                   |     1 |   127 |       |                                                                                                                                                                                                
    |   2 |   NESTED LOOPS                    |                   |     1 |   127 |  1665 |                                                                                                                                                                                                
    |   3 |    NESTED LOOPS                   |                   |     1 |   113 |  1664 |                                                                                                                                                                                                
    |   4 |     NESTED LOOPS                  |                   |     1 |    99 |  1663 |                                                                                                                                                                                                
    |   5 |      NESTED LOOPS                 |                   |     1 |    88 |  1662 |                                                                                                                                                                                                
    |*  6 |       HASH JOIN ANTI              |                   |     1 |    70 |  1661 |                                                                                                                                                                                                
    |*  7 |        TABLE ACCESS BY INDEX ROWID| CONTACT           |  3815 |   201K|  1534 |                                                                                                                                                                                                
    |   8 |         AND-EQUAL                 |                   |       |       |       |                                                                                                                                                                                                
    |*  9 |          INDEX RANGE SCAN         | IDX_CNT__C_STATE  |       |       |       |                                                                                                                                                                                                
    |* 10 |          INDEX RANGE SCAN         | IDX_CNT__STATUS   |       |       |       |                                                                                                                                                                                                
    |  11 |        INDEX FAST FULL SCAN       | PK_RPP            | 69277 |  1082K|   120 |                                                                                                                                                                                                
    |* 12 |       TABLE ACCESS BY INDEX ROWID | REP_PROFILE       |     1 |    18 |     1 |                                                                                                                                                                                                
    |* 13 |        INDEX UNIQUE SCAN          | PK_C19            |     1 |       |       |                                                                                                                                                                                                
    |* 14 |      INDEX UNIQUE SCAN            | PK_B01            |     1 |    11 |       |                                                                                                                                                                                                
    |* 15 |     INDEX UNIQUE SCAN             | PK_B02            |     1 |    14 |       |                                                                                                                                                                                                
    |* 16 |    INDEX UNIQUE SCAN              | PK_RCN            |     1 |    14 |       |                                                                                                                                                                                                
    Predicate Information (identified by operation id):                                                                                                                                                                                                                                    
       6 - access("B"."CONTACT_ID"="RPP"."PARTNERSHIP_ID")                                                                                                                                                                                                                                 
       7 - filter("B"."C_STATE"='GA' AND "B"."C_LAST"<>'Name Unknown' AND                                                                                                                                                                                                                  
                  "B"."STATUS"='Confirmed')                                                                                                                                                                                                                                                
       9 - access("B"."C_STATE"='GA')                                                                                                                                                                                                                                                      
      10 - access("B"."STATUS"='Confirmed')                                                                                                                                                                                                                                                
      12 - filter("C19"."TERR1"='46')                                                                                                                                                                                                                                                      
      13 - access("B"."CONTACT_ID"="C19"."CONTACT_ID")                                                                                                                                                                                                                                     
      14 - access("B"."FIRM_ID"="B01"."FIRM_ID")                                                                                                                                                                                                                                           
      15 - access("B"."OFFICE_ID"="B02"."OFFICE_ID")                                                                                                                                                                                                                                       
      16 - access("B"."CONTACT_ID"="RCN"."CONTACT_ID")                                                                                                                                                                                                                                     
    Note: cpu costing is off                                                                                                                                                                                                                                                               
    38 rows selected.

  • Enabling materialized view for fast refresh method

    In AWM when i select refresh method as FAST and enable the materialized view, am getting the below error:
    "Refresh method fast requires materialized view logs and a previously run complete refresh of the cube mv". i need this Fast refresh of a cube materialized view, so that it performs an incremental refresh and re-aggregation of only changed rows in the source table.
    can anyone help me on this??

    If you want the cube to hold data even after it has been deleted from the relational table, then you should disable the MV on the cube.
    Synchronization with the source table is determined by the default "cube script".
    <li>CLEAR, LOAD, SOLVE : This will synchronize your cube with the source table. It is a requirement for MVs.
    <li>LOAD, SOLVE: This will allow your cube to contain data even after it has been removed from the source table. It sounds like you want this.
    Cube builds can be "incremental" in one of two ways.
    (1) You can have an "incremental LOAD" if the source table contains only the changed rows or if you use MV "FAST" or "PCT" refresh. Since you can't use MVs, you would need a source table with only the changed rows.
    (2) You will have an "incremental SOLVE" (a.k.a. "incremental aggregation") if there is no "CLEAR VALUES" or "CLEAR AGGREGATES" step and various other conditions hold.
    To force a "complete LOAD" with an "incremental SOLVE" you should have all rows in your source table and run the following build script.
    LOAD, SOLVE You could also run "CLEAR LEAVES, LOAD, SOLVE" to synchronize the cube with the table.
    To force an "incremental LOAD" with a "complete SOLVE" you make the source table contains only the changed rows and the run the following:
    CLEAR AGGREGATES, LOAD, SOLVEor
    LOAD, CLEAR AGGREGATES, SOLVEFinally, if you want both LOAD and SOLVE to be incremental you make the source table contains only the changed rows and the run the following:
    LOAD, SOLVE

  • Materialized view not properly refreshing

    Hi,
    As materialized view is not refreshing properly. we compare the sum of hashcode materialized view with the sum of hash code of the base view or table the materialized view is defined. If it's found equal then materialized view got refreshed succesfully else not.
    But in below example the column value is interchanged in between the row eventhough hashcode is same.
    Is there any other way to find the materialized view got refreshed successfully or not.
    SQL> create table temp as select object_name, subobject_name from user_objects where rownum<3;
    Table created
    SQL> select * from temp;
    OBJECT_NAME SUBOBJECT_NAME
    ATP_BN_I_1
    ATP_START_END_DATE_I_2
    SQL> create materialized view mv1 as select * from temp;
    Materialized view created
    SQL> select * from mv1;
    OBJECT_NAME SUBOBJECT_NAME
    ATP_BN_I_1
    ATP_START_END_DATE_I_2
    SQL> select sum(nvl(ora_hash("OBJECT_NAME"||"SUBOBJECT_NAME"),0)) from temp;
    SUM(NVL(ORA_HASH("OBJECT_NAME"
    4852176374
    SQL> select sum(nvl(ora_hash("OBJECT_NAME"||"SUBOBJECT_NAME"),0)) from MV1;
    SUM(NVL(ORA_HASH("OBJECT_NAME"
    4852176374
    SQL> UPDATE TEMP SET OBJECT_NAME=SUBOBJECT_NAME,SUBOBJECT_NAME=OBJECT_NAME;
    2 rows updated
    SQL> COMMIT;
    Commit complete
    SQL> select * from mv1;
    OBJECT_NAME SUBOBJECT_NAME
    ATP_BN_I_1
    ATP_START_END_DATE_I_2
    SQL> select * from temp;
    OBJECT_NAME SUBOBJECT_NAME
    ATP_BN_I_1
    ATP_START_END_DATE_I_2
    SQL> select sum(nvl(ora_hash("OBJECT_NAME"||"SUBOBJECT_NAME"),0)) from MV1;
    SUM(NVL(ORA_HASH("OBJECT_NAME"
    4852176374
    SQL> select sum(nvl(ora_hash("object_name"||"subobject_name"),0)) from temp;
    select sum(nvl(ora_hash("object_name"||"subobject_name"),0)) from temp
    ORA-00904: "subobject_name": invalid identifier
    SQL> select sum(nvl(ora_hash("OBJECT_NAME"||"SUBOBJECT_NAME"),0)) from temp;
    SUM(NVL(ORA_HASH("OBJECT_NAME"
    4852176374
    Any help really appreciated.
    Thanks in advance.

    unique wrote:
    Is there any other way to find the materialized view got refreshed successfully or not.You can look at the last_refresh_date and staleness columns of all_mviews: http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/statviews_1105.htm#REFRN20139
    Or maybe use the all_mview_refresh_times view: http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/statviews_1104.htm#sthref1068
    Regards,
    Rob.

  • How manage materialized view, materialized view logs and db links in Server explorer and Oracle Database Proyect

    Hi,
    We have installed Oracle 12c Oracle Developer Tools for Visual Studio (Visual Studio is 2010 edition). With this tool we can manage tables, views, etc... but we also need to manage more database objects such as materialized views, materialized view logs and db links.
    Is there any option to manage this object from Server Explorer and to add the script in the Database Project? At the same time, the schema compare tools does not include this object types. Is there any option to compare them?
    Thanks.

    As you noticed, not all database objects are available in Server Explorer, and because of this they can't have scripts generated for them, nor can they be compared with Schema Compare.
    In a pinch, you should be able to use SQL Developer to do this.

  • How do I use Primary Key and RowID in Materialized View Logs and MVs

    How do I use Primary Key and RowID in Materialized View Logs and Materialized Views????
    I don’t understand in the Materalized View Logs the diference between Primary Key and RowID. Besides, I could choose both Primary Key and RowID.
    When I have to use RowID?? Why?? And Primary Key??? And both, Primary Key and RowID????
    Thank you very much!

    Yes, I have already read it...
    But for example I don’t Understand:
    This is the example 8-1
    CREATE MATERIALIZED VIEW LOG ON products
    WITH SEQUENCE, ROWID
    (prod_id, prod_name, prod_desc, prod_subcategory, prod_subcat_desc, prod_
    category, prod_cat_desc, prod_weight_class, prod_unit_of_measure, prod_pack_
    size, supplier_id, prod_status, prod_list_price, prod_min_price)
    INCLUDING NEW VALUES;
    But if I create a Materialized View with TOAD if I choose a KEY field I receive the error:
    ORA-12026: invalid filter column detected
    Then I have to take out the Key (in the above example prod_id)
    And then the script is
    CREATE MATERIALIZED VIEW LOG ON products
    WITH ROWID, SEQUENCE, PRIMARY KEY!!!!!!!!!!!!!!!!!!!!
    (prod_id, prod_name, prod_desc, prod_subcategory, prod_subcat_desc, prod_
    category, prod_cat_desc, prod_weight_class, prod_unit_of_measure, prod_pack_
    size, supplier_id, prod_status, prod_list_price, prod_min_price)
    INCLUDING NEW VALUES;
    I have PRIMARY KEY in the definition (I don’t choose it) and I don’t have the prod_id field
    Why is it????
    Note: If I execute the script to create the MV Log manually the PRIMARY KEY option NO IS in the script and the prod_id field either is in the script.
    And on the other hand,
    What is this:
    CREATE MATERIALIZED VIEW LOG ON sales
    WITH ROWID;
    CREATE MATERIALIZED VIEW LOG ON times
    WITH ROWID;
    CREATE MATERIALIZED VIEW LOG ON customers
    WITH ROWID;
    These MATERIALIZED VIEW LOG contain any fields????
    Or it contain the primary key fields of this tables (sales, times and customers)??? Then, Why is it ROWID instead of PRIMARY KEY????
    Thanks!

  • Materialized View big and empty after full refresh

    Background:
    Database 10.2.0.4 running on Windows 2003 Server R2 SP2.
    Materialized view MV_A, selects from 3 base tables, 2 of which are partitioned, fast refresh on demand, approx 33 million rows. Initially populated with a complete refresh of 31 million rows about 2 months ago, and fast refreshed every 10 seconds since then.
    Problem: Performed a partition split on one of the base tables and received this error on the next fast refresh:
    ORA-32313: REFRESH FAST of "CUR"."MV_A" unsupported after PMOPs
    Docs say a complete refresh is required.
    So, created a new copy of the materialized view "MV_B", same storage params, same mview SELECT, same schema.
    Did a complete refresh, the extents grew to the expected 10GB combined size. The DBMS_MVIEW.REFRESH reported 'PL/SQL procedure successfully completed' but the MVIEW is empty.
    23:01:26 SQL> exec DBMS_MVIEW.REFRESH('MV_B','C','',FALSE,FALSE,0,0,0,TRUE) /* Complete */;
    PL/SQL procedure successfully completed.
    07:56:46 SQL> commit;
    Commit complete.
    08:17:51 SQL> select count(*) from mv_b;
    COUNT(*)
    0
    08:19:39 SQL>
    Since the MVIEW table MV_B added 10 GB worth of extents during the refresh, it appears that the rows were inserted but then for some reason were rolled back. Nothing unusual in the alert.log. If I execute the MVIEW select statement by itself in SQLPlus, yes, I do get rows back.
    The tablespaces housing the MVIEW table as well as the temporary and undo tablespaces are set to autoextend/unlimited to make sure they are not an issue.
    Next I dropped and recreated the materialized view MV_B, identical except an added condition to the WHERE clause so that the number of rows returned is only 7 million instead of 33 million and that works fine - a complete refresh populates it and subsequent fast refreshes work correctly.
    I'm stumped. Any ideas? Could we be running out of some memory resource that when exhausted, is not trapped properly by Oracle as an error?
    - Tom

    Is the MV and the source tables on the same database? If this is a remote MV, then check the source site if there are any issues (TEMP, UNDO space issues).

  • Materialized View - creation and schedule (To automate Refresh)

    Hi All,
    I have one table based on SQL Query (multiple tables) and loading data every day through procedure.
    When I execute the procedure is taking lot of time to load data. That’s why I am planning to create Materialized view to refresh the data in a table every day at some point of time (ex:-9.00 am).
    Exclude procedure and materialized view are there any ways to refresh the data?
    Can you and all please help me to create materialized view and schedule (Automate refresh).
    begin
    insert into CLAIMS_PRODUCT_TAB
    select
    substr(at.ATN_VOUCHER_NUMBER,1,6) as BRANCH,
    t.MONTH_NAME as MONTH,t.FISCAL_YEAR as YEAR,
    bb.ACC_ACCOUNT_TYPE as TYPE,
    aa.ACC_DEPARTMENT_CODE as DEPT,
    pr.PRODUCT_NAME as PRODUCT,
    case bb.ACC_ACCOUNT_TYPE when '1301' then 'Claims Paid' when '5383' then 'Claims OS' end as HEAD,
    case aa.ACC_DEPARTMENT_CODE when '31' then 'OD' when '32' then 'TP' when '39' then 'TP Pool' end as DEPT_NAME,
    count(distinct at.CLAIM_ID) as CLAIMS,
    --count( distinct at.POLICY_ID) as POLICIES,  
    sum(atd.ATD_CREDIT_AMOUNT - atd.ATD_DEBIT_AMOUNT) as totals
    from
    ACCOUNTING_TRN_DETAIL atd,time t,
    ACCOUNT bb,
    ACCOUNT aa,claim c, policy p,product pr,
    accounting_transaction at
    where bb.ACC_ACCOUNT_ID = aa.ACC_ACC_ACCOUNT_ID
    and at.CLAIM_ID = c.CLAIM_ID
    and c.POLICY_ID = p.POLICY_ID
    and p.PRODUCT_ID = pr.PRODUCT_ID
    and aa.ACC_ACCOUNT_ID = atd.ACC_ACCOUNT_ID
    and atd.ATN_ACCOUNTING_TRANSACTION_ID = at.ATN_ACCOUNTING_TRANSACTION_ID
    and trunc(at.ATN_TRANSACTION_DATE) = t.CAL_DATE
    and (bb.ACC_ACCOUNT_TYPE in ('1301','5383'))
    group by substr(at.ATN_VOUCHER_NUMBER,1,6)
    ,t.MONTH_NAME
    ,t.FISCAL_YEAR,bb.ACC_ACCOUNT_TYPE
    ,aa.ACC_DEPARTMENT_CODE
    ,pr.PRODUCT_NAME
    , case bb.ACC_ACCOUNT_TYPE when '1301' then 'Claims Paid' when '5383' then 'Claims OS' end
    ,case aa.ACC_DEPARTMENT_CODE when '31' then 'OD' when '32' then 'TP' when '39' then 'TP Pool' end );
    end;
    Thanks and Regards
    Venkat

    Is the MV and the source tables on the same database? If this is a remote MV, then check the source site if there are any issues (TEMP, UNDO space issues).

  • How does materialized view work when refresh the view vs create the view?

    I am using a materialized view, and I cant set it to fast refresh because some of the tables are from remote database which does not have materialized view log.
    When I create the materialized view, it took like 20 30 seconds. however when I was trying to refresh it. It took more than 2 3 hours. and total number of records are only around 460,000.
    I understand that when the view refreshes, it would take extra step like purge the table however I am not sure why it made so much difference in execution time perspective...
    Does the dbms_mview.refresh('MY_MATVIEW', 'C', atomic_refresh=>false) do the same exact insert as when I created the view?
    Could anyone please let me know how would this happen? Thanks,
    Code looks like as following
    create materialized view MY_MV1
    refresh force on demand
    start with to_date('20-02-2013 22:00:00', 'dd-mm-yyyy hh24:mi:ss') next trunc(sysdate)+1+22/24
    as
    ( SELECT Nvl(Cr.Sol_Chng_Num, ' ') AS Change_Request_Nbr,
           Nvl(Sr.Sr_Num, ' ') AS Service_Request_Nbr,
           Nvl(Sr.w_Org_Id, 0) AS Org_Id,
           Fcr.rowid,
           Cr.rowid,
           Bsr.rowid,
           Sr.rowid,
           SYSDATE
      FROM [email protected] Fcr
    INNER JOIN [email protected] Cr
        ON Fcr.w_Sol_Chng_Id = Cr.w_Sol_Chng_Id
    INNER JOIN [email protected] Bsr
        ON Fcr.w_Sol_Chng_Id = Bsr.w_Sol_Chng_Id
    INNER JOIN [email protected] Sr
        ON Sr.w_Srv_Rec_Id = Bsr.w_Srv_Rec_Id
    WHERE Sr.Sr_Num !='NS'
    );I have tried to use dbms_mview.refresh('MY_MATVIEW', 'C', atomic_refresh=>false) but it still took 141 mins to run... vs 159 mins without atomic_refresh=>false
    Edited by: 986006 on Feb 20, 2013 2:15 PM

    Welcome to the forum!
    Whenever you post provide your 4 digit Oracle version (result of SELECT * FROM V$VERSION)
    >
    I am using a materialized view, and I cant set it to fast refresh because some of the tables are from remote database which does not have materialized view log.
    When I create the materialized view, it took like 20 30 seconds. however when I was trying to refresh it. It took more than 2 3 hours. and total number of records are only around 460,000.
    I understand that when the view refreshes, it would take extra step like purge the table however I am not sure why it made so much difference in execution time perspective...
    Does the dbms_mview.refresh('MY_MATVIEW', 'C', atomic_refresh=>false) do the same exact insert as when I created the view?
    >
    What Oracle version are you using? The 'atomic_refresh' parameter default was changed to TRUE starting with 10g.
    See the PL/SQL Packages and Types doc
    >
    atomic_refresh
    If this parameter is set to true, then the list of materialized views is refreshed in a single transaction. All of the refreshed materialized views are updated to a single point in time. If the refresh fails for any of the materialized views, none of the materialized views are updated.
    If this parameter is set to false, then each of the materialized views is refreshed in a separate transaction.
    >
    What that means is that if the value is TRUE Oracle uses a DELETE to remove the existing rows. If the value is FALSE then Oracle uses TRUNCATE.
    If you really are using the FALSE setting you should not be seeing that much of a time difference between creating the MV and a complete refresh so something else must be going on.

  • How to get a materialized view get to refresh itself after the job is "broken"

    we created a materialized view sometime ago with the following statement:
    create materialized view SXV_PUB_EMPLOYEE_CERT_ALL_M
    refresh complete on demand
    start with to_date('30-08-2009 04:00:00', 'dd-mm-yyyy hh24:mi:ss') next trunc(sysdate) + (28/24)
    as
    select  sxv_emp_cert_all.*
    from    sxv_employee_certification_all sxv_emp_cert_all;
    this week we found out it had not been refresh for about a month
    In dba_jobs the column broken was 'Y', next_date time something like 01-01-4000 and failures 16
    when I ran it manually by executing
    BEGIN DBMS_MVIEW.REFRESH('SXV_PUB_EMPLOYEE_CERT_ALL_M', 'C'); END;
    I found that one of the columns was too small (probably a columns of one of the underlying tables had been extended since the creation of the materialized view)
    After fixing this I ussied yesterday (on 29-8-2013) the statement :
    alter materialized view SXV_PUB_EMPLOYEE_CERT_ALL_M
    refresh complete on demand
    start with to_date('30-08-2009 04:00:00', 'dd-mm-yyyy hh24:mi:ss') next trunc(sysdate) + (28/24)
    after this the table dba_jobs showed me 30-08-2013 04:00:00 as next date
    I was expecting it to run this night at 04:00, but it didn't
    the last_date column value was still from about a month ago, the column broken still shows 'Y'
    and the next date 30-08-2013 04:00:00 (while it should been set to 31-08-2013 01:00:00
    Rrunning
    BEGIN DBMS_MVIEW.REFRESH('SXV_PUB_EMPLOYEE_CERT_ALL_M', 'C'); END;
    gave no errors this time
    and in User_Mview_Analysis the last_refresh_date column showed the date/time I had executed it
    Any idea how to get the job "unbroken" again so that the view refreshes itself every night?
    the database is Oracle Database 10g Release 10.2.0.4.0
    regards,
    Remco

    thanx for all your helpful and correct answers . but eventually I found it myself
    exec dbms_job.broken(<jobnumber>, false);

  • Update sequence wrong in Materialized view when using refresh group

    Hi,
    I made a trigger (for each row) on a materialized view(replication data from a master table in in a different database), which is refreshed by a refresh group (exec dbms_refresh.refresh('"...). However, the update order/sequence is important and must be handled (by the trigger) in the same order how the updates where done in the master table. Unfortunately the updates in the materialized view are NOT in the same order. The trigger is fired in a wrong order.
    I am using database version 10.2.0
    Does anybody reconize this problem, Is there a solution for this problem ( with keeping the refresh group mechanisme)?
    Thanks
    Regards
    Jurn

    rownum is determined as the row is output, so "order by rownum" does literally nothing.
    http://docs.oracle.com/cd/B19306_01/server.102/b14200/pseudocolumns009.htm

  • Materialized View creation with REFRESH FAST

    Hello ,
    Please see below case,
    TABLE A1(partitioned range+list)
    COLUMN C1  -- Primary key
    COLUMN C2  -- NUMBER
    TABLE D1
    COLUMN C1 -- PRIMARY KEY
    created MV log as below
    CREATE MATERIALIzED VIEW LOG ON A1 WITH ROWID,PRIMARY KEY INCLUDING NEW VALUES;
    CREATE MATERIALIzED VIEW LOG ON D1 WITH ROWID,PRIMARY KEY INCLUDING NEW VALUES;
    Trying to create MV like below:
    CREATE MATERILIZED VIEW mv1test
                                    REFRESH FAST ON COMMIT
    AS
    Select
    FROM A1,
                            D1
                    WHERE A1.C1 = D1.CI
    AND A1.C2 IS NOT NULL;
    It gives below error message:
    ORA-12052: cannot fast refresh materialized view schema.mv1test
    12052. 00000 -  "cannot fast refresh materialized view %s.%s"
    *Cause:    Either ROWIDs of certain tables were missing in the definition or
               the inner table of an outer join did not have UNIQUE constraints on
               join columns.
    *Action:   Specify the FORCE or COMPLETE option. If this error is got
               during creation, the materialized view definition may have be
               changed. Refer to the documentation on materialized views.
    However ,as discussed in earlier thread i checked all general restrictions of the 'Refresh fast' approach for join.
    Restrictions on Fast Refresh on Materialized Views with Joins Only
    Defining queries for materialized views with joins only and no aggregates have the following restrictions on fast refresh:
    1) They cannot have GROUPBY clauses or aggregates.
    2) Rowids of all the tables in the FROM list must appear in the SELECT list of the query.
    3)Materialized view logs must exist with rowids for all the base tables in the FROM list of the query.
    4)You cannot create a fast refreshable materialized view from multiple tables with simple joins that include an object type column in the SELECTstatement.
    As per above restrictions ,
    1) Group by clause is not present
    2)i do not understand 2nd point , i have added a1.rowid  and d1.rowid in  select statement of MV, but got same error.
    3) observed same as 2nd point.
    4)we have CLOB column in select list. Tried removing this column but got same error.
    Please do let me know any workaround on this.
    Thanks in advanced ..
    PM

    Basic Materialized Views show how to analyse MVs using dbms_mview. I'm not sure about creating MVs on partitioned tables, that partition maintenance might cause problems

  • Materialized view not fast refreshable

    I need to calculate a moving total in a materialized view - that is, calculate subtotal for rows starting at current row up to the first row.
    I am using a window function, as shown below.
    The problem is, MVs using window functions are not fast refreshable, and I need this MV to be fast refreshable.
    Is there any other way of getting the moving total without using a window function?
    CREATE MATERIALIZED VIEW BIL_BI_OPDTL_MV_11_TST
    --REFRESH FAST ON DEMAND
    AS
    SELECT
    fact.txn_time_id txn_time_id
    , fact.effective_time_id close_time_id
    , prntmv.parent_group_id
    , jgd.parent_group_id sales_group_id
    , fact.lead_id
    , fact.opp_open_status_flag
    , fact.win_loss_indicator
    , fact.forecast_rollup_flag
    ,fact.rev_flag1
    , SUM(fact.rev_flag1) OVER (PARTITION BY
    fact.effective_time_id , prntmv.parent_group_id
    , fact.lead_id, fact.opp_open_status_flag, fact.win_loss_indicator, fact.forecast_rollup_flag
    , to_number(to_char(opty_creation_date,'J'))
    , to_number(to_char(opty_conversion_date,'J'))
    ORDER BY fact.lead_id
    ROWS UNBOUNDED PRECEDING) moving_total
    , to_number(to_char(opty_creation_date,'J')) opty_creation_time_id
    , to_number(to_char(opty_conversion_date,'J')) opty_conversion_time_id
    ,count(*) cnt
    FROM bil.bil_bi_opty_ld_f_tst fact, bil_bi_rs_grp_mv rgmv, bil_bi_rs_grp_mv prntmv,
    jtf.jtf_rs_groups_denorm jgd
    WHERE rgmv.sales_group_id = fact.sales_group_id
    and rgmv.salesrep_id = fact.salesrep_id
    AND fact.sales_group_id = jgd.group_id
    AND prntmv.sales_group_id = jgd.parent_group_id
    AND prntmv.umarker in ('top_groups', 'groups')
    AND jgd.active_flag='Y'
    group by
    fact.txn_time_id,
    fact.effective_time_id
    , prntmv.parent_group_id
    , jgd.parent_group_id
    , fact.lead_id
    , fact.opp_open_status_flag
    , fact.win_loss_indicator
    , fact.forecast_rollup_flag
    , fact.rev_flag1
    , to_number(to_char(opty_creation_date,'J'))
    , to_number(to_char(opty_conversion_date,'J'))

    Please post your question at
    General Database Discussions
    for faster response

  • Materialized views with Complete refresh taking infinite time while refresh

    Hi,
    We have some materialized view which are configured for Complete refresh and are being refreshed manually everyday in the morning. Some times we face this issue of the MV taking longer time than usual for refresh. We tried running the below query to see if any object/MVs are locked and did not obtain any entries using the query:
    SELECT username U_NAME, owner OBJ_OWNER,
    object_name, object_type, s.osuser,
    DECODE(l.block,
    0, 'Not Blocking',
    1, 'Blocking',
    2, 'Global') STATUS,
    DECODE(v.locked_mode,
    0, 'None',
    1, 'Null',
    2, 'Row-S (SS)',
    3, 'Row-X (SX)',
    4, 'Share',
    5, 'S/Row-X (SSX)',
    6, 'Exclusive', TO_CHAR(lmode)
    ) MODE_HELD
    FROM gv$locked_object v, dba_objects d,
    gv$lock l, gv$session s
    WHERE v.object_id = d.object_id
    AND (v.object_id = l.id1)
    AND v.session_id = s.sid
    ORDER BY username, session_id;
    Hence please help us in troubleshooting this issue in Refreshing. and also let us know of any possible cause of Refresh taking longer time than usual.
    Thanking you in advance.
    Bharath

    >
    We have some materialized view which are configured for Complete refresh and are being refreshed manually everyday in the morning. Some times we face this issue of the MV taking longer time than usual for refresh
    >
    Which is it? 'some' MVs or 'the' MV that is taking longer than usual.
    1. How many MVs are being refreshed?
    2. What process are you using to refresh them
    3. Are you refreshing them one at a time serially or just starting the refresh of all of them at the same time?
    4. Do any of these MVs use the same base tables as the other MVs
    5. Are any of the MVs based on remote tables?
    6. Are any of the MVs based on other MVs?
    7. What does an AWR report show for the time period when things are taking longer than usual?
    All of the same issues that can cause a query to run slow can cause an MV refresh to go slow because an MV refresh is a query.
    But you need to provide a lot more information and metrics about your system if you want to get any advice that might be specific to your particular case.

Maybe you are looking for