Mapping materialized views

Is there some sort of setting I need to adjust to pull off creating Java objects from a materialized view? When I launch the Java Objects from Tables wizard in jDeveloper 11g I can't see any of the materialized views. The views are in a different schema but I have the grants to select from them.
I can see synonyms to them in a different schema but importing synonyms seems to result in some odd mapping behavior.
Any ideas?

I done some more testing by creating a new schema and creating a materialized view inside of it. When I create a new Toplink project using that schemas login information I still cant see the materialized views in the "Create Java objects from Tables" wizard. This seems to happen in jDeveloper 10 and 11g, Windows and Mac.
Has anyone here managed to successfully map a materialized view? Its looking impossible within jDeveloper at this point.

Similar Messages

  • Map Viewer Query Rewriting for Dynamic themes and  Materialized Views.

    Hi,
    I am usng a WMS request to render FOI points in my map.
    Internally query rewrite is happening in Mapviewer for this dynamic theme and my data points query is getting converted as
    select FROM
    ( select status, shape from MatView.MyTab where id = '3' )
    WHERE MDSYS.SDO_FILTER(shape, MDSYS.SDO_GEOMETRY(2003, 4283, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1, 1003, 3), MDSYS.SDO_ORDINATE_ARRAY(144.948120117188,-37.8162934802451,144.950866699219,-37.8141237016045)), 'querytype=WINDOW') = 'TRUE'
    here the rewritten query is not correct and is throwing exceptions in mapviewer log
    How can I make this query to be written correctly.
    (My orginal query before rewrite is: select status,shape from MatView.MyTab where id='3' )
    I am using a materialised view : MatView is a materialized view.
    When I used normal tables, the query is re written correctly.But for this materialized view this is happening.
    How can I correct the error?
    Is this has something to do with some Spatial Indexing in Materialised view or Query Rewriting for materialized view?
    Edited by: 841309 on Mar 10, 2011 11:04 PM

    Oops!
    The Materialized view was not accessible from the schema I tried :)
    And so when I gave permissions,it formed the correct query.
    So if permission is not there,map viewer will rewrite the query in a wrong way! New information.

  • Refresh/Update data in a materialized view

    Hi,
    I have question about the data in a materialized view and how it is refreshed. My mat view has all my dimension-ids and my (for my specialize needs) aggregated measures from my fact table. I used the mat view wizard to create my view - which works perfectly. But now I wonder if I have to create some sort of mapping(?) or some sort of trigger to refresh the data in the mat view. Or is the data automatically refreshed when I start my fact table mappings. I use OWB 11gR2
    thx

    MVs have properties for refresh - you an refresh based on schedules or when dependent data is committed or manually.
    Cheers
    David

  • Need help on tuning materialized view refresh

    Hi All,
    I am working on materialized view refresh tuning.Initially it was complete refresh and used to take more than 90 mins to complete.
    I changed it to fast refresh now it is completing fast. Now i have partitioned the base tables gl_balances and gl_code_combinations of column code_combination_id and created a local index on column code_combination_id then i am trying to partition the materialized on the same column to take advantage of partition change tracking.
    Size of gl_balances base tables is 40Gb and all others tables sizes are small. In where clause there all the 4 tables are mapped. If i will create the partition only on code_combination_id will i the materialized will become the candidate for partition change tracking. As i know it will be applicable for PCT. I need expert advice on this.
    While doing a fast refresh. the refresh takes less time. when there is a change in gl_balances , gl_code_combinations or gl_periods it completes in 20-30 mins. When there is a change in gl_set_of_books tables. It creates a problem here.DEL query takes more than 48 hours to complete.
    CREATE MATERIALIZED VIEW apps.BAL_PART
    REFRESH FAST ON DEMAND
    ENABLE QUERY REWRITE as
    SELECT GL.GL_CODE_COMBINATIONS21.ROWID C1,GL.GL_BALANCES21.ROWID C2, GL.GL_SETS_OF_BOOKS.ROWID C3,
    GL.GL_PERIOD.ROWID C4,
    "GL"."GL_BALANCES21"."ACTUAL_FLAG" ,
    "GL"."GL_BALANCES21"."CURRENCY_CODE" ,
    "GL"."GL_BALANCES21"."PERIOD_NUM" ,
    "GL"."GL_BALANCES21"."PERIOD_YEAR" ,
    "GL"."GL_BALANCES21"."SET_OF_BOOKS_ID" "SOB_ID",
    "GL"."GL_CODE_COMBINATIONS21"."CODE_COMBINATION_ID" "CCID",
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT1" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT10" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT11" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT12" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT13" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT14" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT2" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT3" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT4" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT5" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT6" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT7" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT8" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT9" ,
    "GL"."GL_PERIODS"."PERIOD_NAME" ,
    NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_CR", 0) Open_Bal_Cr,
    NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_CR", 0) +
    NVL("GL"."GL_BALANCES21"."PERIOD_NET_CR", 0) Close_Bal_Cr,
    NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_DR", 0) Open_Bal_Dr,
    NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_DR", 0) +
    NVL("GL"."GL_BALANCES21"."PERIOD_NET_DR", 0) Close_Bal_Dr,
    NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_DR", 0) -
    NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_CR", 0) Open_Bal,
    NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_DR", 0) -
    NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_CR", 0) +
    NVL("GL"."GL_BALANCES21"."PERIOD_NET_DR", 0) -
    NVL("GL"."GL_BALANCES21"."PERIOD_NET_CR", 0) Close_Bal,
    NVL("GL"."GL_BALANCES21"."PERIOD_NET_CR", 0) Period_Cr,
    NVL("GL"."GL_BALANCES21"."PERIOD_NET_DR", 0) Period_Dr
    FROM GL.GL_CODE_COMBINATIONS21,
    GL.GL_BALANCES21,
    GL.GL_SETS_OF_BOOKS,
    GL.GL_PERIODS
    WHERE GL.GL_BALANCES21.CODE_COMBINATION_ID =GL.GL_CODE_COMBINATIONS21.CODE_COMBINATION_ID
    AND GL.GL_SETS_OF_BOOKS.SET_OF_BOOKS_ID = GL.GL_BALANCES21.SET_OF_BOOKS_ID
    AND GL.GL_PERIODS.PERIOD_NUM = GL.GL_BALANCES21.PERIOD_NUM
    AND GL.GL_PERIODS.PERIOD_YEAR = GL.GL_BALANCES21.PERIOD_YEAR
    AND GL.GL_PERIODS.PERIOD_TYPE = GL.GL_BALANCES21.PERIOD_TYPE
    AND GL.GL_PERIODS.PERIOD_NAME = GL.GL_BALANCES21.PERIOD_NAME
    AND GL.GL_PERIODS.PERIOD_SET_NAME = GL.GL_SETS_OF_BOOKS.PERIOD_SET_NAME
    and gl.GL_CODE_COMBINATIONS21.summary_flag != 'Y'TRACE 1046 del statement
    DELETE FROM "APPS"."apps.BAL_PART" SNA$
    WHERE "C3" IN (SELECT /*+ NO_MERGE  */ * FROM (SELECT 
      CHARTOROWID("MAS$"."M_ROW$$") RID$     FROM "GL"."MLOG$_GL_SETS_OF_BOOKS"
      "MAS$"   WHERE "MAS$".SNAPTIME$$ > :B_ST1 ) AS OF SNAPSHOT(:B_SCN) MAS$)
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute      1  17759.00  171782.99  159422121    1267371 2564144739           0
    Fetch        0      0.00       0.00          0          0          0           0
    total        2  17759.00  171782.99  159422121    1267371 2564144739           0
    Misses in library cache during parse: 1
    Misses in library cache during execute: 1
    Optimizer mode: ALL_ROWS
    Parsing user id: 175  (APPS)   (recursive depth: 1)
    Rows     Row Source Operation
          0  DELETE  apps.BAL_PART (cr=0 pr=0 pw=0 time=0 us)
    193128740   NESTED LOOPS  (cr=592437 pr=592422 pw=0 time=945244160 us cost=339302 size=168 card=1)
          3    SORT UNIQUE (cr=7 pr=0 pw=0 time=15832 us cost=2 size=138 card=1)
         24     TABLE ACCESS FULL MLOG$_GL_SETS_OF_BOOKS (cr=7 pr=0 pw=0 time=19 us cost=2 size=138 card=1)
    193128740    INDEX RANGE SCAN C3BOOKS (cr=592430 pr=592422 pw=0 time=789499200 us cost=339299 size=3318314250 card=110610475)(object id 2114736)
    error during execute of EXPLAIN PLAN statement
    ORA-08187: snapshot expression not allowed here
    parse error offset: 314
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      db file sequential read                   159520897        2.12     144415.96
      latch: cache buffers chains                   134        0.06          0.68
      latch: undo global data                        33        0.02          0.15
      latch: object queue header operation          521        0.02          0.53
      log file switch (private strand flush incomplete)
                                                    532        0.31         28.26
      resmgr:cpu quantum                            155        1.40         13.49
      resmgr:internal state change                   25        0.11          2.21
      latch free                                     10        0.00          0.00
      latch: cache buffers lru chain                  4        0.00          0.00
      rdbms ipc reply                               489        0.02          0.54
      reliable message                              587        0.00          0.56
      latch: row cache objects                        3        0.00          0.00
    ********************************************************************************GL_SETS_OF_BOOKS has only 6 rows. I know there is complete refresh as a option which will again take more than 90 mins.
    I want to do the fast refresh. Tables rows details below.
    SQL> select count(*) from gl.gl_code_combinations21;
    COUNT(*)
    3075255
    SQL> select count(*) from gl.GL_PERIODS;
    COUNT(*)
    1160
    SQL> select count(*) from gl.gl_balances21;
    COUNT(*)
    477613527
    SQL> select count(*) from gl.gl_sets_of_books;
    COUNT(*)
    6gl_sets_of_books has less rows. Whenever there is a change then it mapped to huge rows hence during materialized view has delete huge number of rows.
    select count(*) from apps.BAL_PART group by C3;
    C3 is the rowid which is present in create materialized statement.
    COUNT(*)
    292927011
    210215
    69330
    184406971
    Is there any way to improve the plan. As i created a partition on code_combination_id and local index on code_combination_id which will not help in set_of_books_id case. I dont PCT will help here or not. Is it possible to use PCT refresh by equipartitioning only one column in where clause.
    Please assist me in improving refresh of materialized view using fast refresh.
    Thanks and Regards,
    Edited by: user646034 on Feb 23, 2013 11:13 PM
    Edited by: user646034 on Feb 23, 2013 11:19 PM
    Edited by: user646034 on Feb 23, 2013 11:46 PM
    Edited by: user646034 on Feb 25, 2013 11:46 AM

    Hi
    The below explain without index and with index.
    /* MV_REFRESH (DEL) */ DELETE FROM "APPS"."BAL_PART                                                                                                                                                                                                                                                                                                                                                                                                                
    " SNA$ WHERE "C3" IN (SELECT /*+ NO_MERGE  */ * FROM (SELECT                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           
    CHARTOROWID("MAS$"."M_ROW$$") RID$     FROM                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            
    "GL"."MLOG$_GL_SETS_OF_BOOKS" "MAS$"   WHERE "MAS$".SNAPTIME$$ > :B_ST1                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
    ) AS OF SNAPSHOT(:B_SCN) MAS$)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         
    Plan hash value: 2704021294                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           | Id  | Operation            | Name                          | E-Rows |E-Bytes| Cost (%CPU)| E-Time   |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
    |   0 | DELETE STATEMENT     |                               |        |       |   339K(100)|          |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
    |   1 |  DELETE              | BAL_PART                          |        |       |            |          |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
    |   2 |   NESTED LOOPS       |                               |      1 |   168 |   339K  (1)|999:59:59 |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
    |   3 |    SORT UNIQUE       |                               |      1 |   138 |     2   (0)| 00:02:31 |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
    |   4 |     TABLE ACCESS FULL| MLOG$_GL_SETS_OF_BOOKS        |      1 |   138 |     2   (0)| 00:02:31 |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
    |   5 |    INDEX RANGE SCAN  | C3BOOKS                       |    110M|  3164M|   339K  (0)|999:59:59 |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
    If i will not use the C3 index then the query will use the belolw plan, I guess this will also take same time or more time.
    |   0 | DELETE STATEMENT       |                               |        |       |  9743K(100)|          |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              
    |   1 |  DELETE                | BAL_PART                          |       |            |          |                                                                                                                                                                                                                                                                                                                                                                                                     

  • How to Refresh materialized view

    Hi,
    I am using 11G owb. I would like to know if any one can help me know if there is any easy to Refresh materialized view . I will be using this materialized view to source data from my maps. this map will be part of a process flow. i would like to refresh the materialized view before every run of the map in process flow.
    Thanks,
    Ash.
    Edited by: user591315 on Aug 6, 2009 1:26 PM

    A couple of approaches;
    * refresh the MV from a procedure in a pre map process operator (its an operator in a mapping), or
    * call the procedure from a process flow activity before the map
    Cheers
    David

  • CGroup from Oracle Materialized view

    Hi
    I'm trying to create a User Manage Cgroup in timesten from a oracle mview....
    When execute "create .. cache group command" this error message appears
    Command> CREATE USERMANAGED CACHE GROUP "cg_ser_lin"
    > AUTOREFRESH MODE INCREMENTAL INTERVAL 10 MINUTES
    > STATE PAUSED
    > FROM
    "MARTINEL"."v_SER_LIN" (
    > "MARTINEL"."v_SER_LIN" (
    "NUM_LINE" CHAR(12 BYTE) NOT NULL,
    "COD_serv" CHAR(10 BYTE) NOT NULL,
    > "NUM_LINE" CHAR(12 BYTE) NOT NULL,
    > "COD_serv" CHAR(10 BYTE) NOT NULL,
    > "fec_term" date not null,
    > PRIMARY KEY("NUM_LINE","COD_serv"), READONLY
    >
    > );
    5120: No matching unique index with not null columns, unique key constraint with not null columns, or primary key constraint on table MARTINEL.V_SER_LIN, cache operations are restricted
    5168: Restricted cache groups are deprecated
    5126: A system managed cache group cannot contain non-standard column type mapping
    The command failed.
    The mview definition is :
    create materialized view v_ser_lin
    parallel 3
    nologging
    refresh complete
    start with sysdate next SYSDATE + 30/1440
    as
    select /*+ index (s ser_pk)*/sl.num_line, s.cod_serv,SL.FEC_INIC,SL.FEC_TERM
    from servicios s, ser_lin sl
    where
    s.cod_serv = sl.cod_prod
    and
    s.flg_cons='S'
    and
    s.flg_switch='S';

    TimesTen does not currently support caching of Oracle materializesed views. The only objects that a cache group can be defined on are actual tables.
    Also, any Oracle table that will be cached must have a primary key defined in Oracle.
    Chris

  • AWM does not provide Materialized Views as potential data sources.

    Hi
    I would like to map OLAP dimensions and cubes directly to materialized views. The Oracle AWM tool, however, only displays Tables, Views and Synonyms as mapping objects and I have to indirectly map to normal views created over the materialized views.
    Why does Oracle enforce this limitation?
    Thanks
    Kind Regards
    Greg

    Greg,
    Not sure why AWM enforces this limitation, certainly Warehouse Builder does not enforce this rule (at least not to my knowledge). You could raise a bug/enhancement request with Support. However, my recommendation is to never to map directly to a source object, such as a fact table or materialized view, in AWM. This can create all sorts of problems as you move your AWM model across environments. I always suggest to my customers and consultants they create a view over their source objects and use the view within the mapping editor. It will give you more control over the flow of data into your cube/dimension since it allows you to define filters on the view.
    Hope this helps
    Keith Laker
    Oracle EMEA Consulting
    BI Blog: http://oraclebi.blogspot.com/
    DM Blog: http://oracledmt.blogspot.com/
    BI on Oracle: http://www.oracle.com/bi/
    BI on OTN: http://www.oracle.com/technology/products/bi/
    BI Samples: http://www.oracle.com/technology/products/bi/samples/

  • Materialized View Refresh; Process Flow

    I was wondering if anyone has used process flow to refresh materialized view;
    I am trying to use a process flow for this i.e. run something similiar to below
    EXECUTE dbms_refresh.refresh('"ODW_SRC"."MV_SERVICE_DAILY_AUDIT"');
    I am trying to avoid using DB scheduler because I want to make sure process flow doesn't clash with update of materialized view causing possible conflict of longer than expected job run time goes into refresh window.
    I am assuming I could use a transformation and build it out; but I was wondering if there is an easier way in just executing this one line ... any idea's
    Thank you in advance for your help

    Sorry, I think the OWB term is post mapping process, its actually an operator in an OWB mapping where you can add a procedure call for example. The procedure can do pretty much what it wants.
    Cheers
    David

  • Error on OWB-Materialized view

    hi,
    i got this error when i try to generate a mapping that fill up a materialized view
    ORA-01732:
    this mapping or this mv is filled from various dimensions table and one fact table, in this mapping the data or some data pass for a sum operation from the fact table, then is used a join to join the dimensions and the fact table, and later we use an "agregator"(or group by expression) and then the data goes to the mv.
    i don't know what could be the problem.
    any help? thanks.
    miguel.

    The MV is refreshed NOT through OWB but through SQL*Plus. The provided package DBMS_MVIEW has a procedure 'REFRESH' that is called to refresh the data. It's usage is 'exec dbms_mview.refresh('<mview name in caps>')'.
    Check the SQL documentation for other parameters that can be used with the refresh sub-program.
    OWB is used only to create the MV, define the data columns and set the refresh paramters, the actual data refresh is done via SQL.
    It is as Mahesh has stated. He is the guru.
    -gary

  • Materialized Views or DBMS_JOBS?

    Hellow
    I have a situation where there are 2 database servers "db1" and
    "db2". Both the servers have a common schema containing common tables.
    Some tables in db1 is getting updated repeatedly in every 3sec. I need
    to synchronise this tables with the corresponding replica tables in
    db2 after every 4sec.
    I cannot opt for trigger because in every 3 sec entire data in the
    able is flushed out and new data is populated....so i need to wait for 3
    sec and then do the same thing for the replica table in db2 by copying data
    from db1 to db2...
    what option will be better Materialized View or DBMS_JOB...I mean i
    thought of writing a plsql script which will update the table in db2
    after every 5sec..by associating this script with DBMS_JOB
    performance wise which will be more better?
    Regards
    sam

    Actually it is getting populated by new coordinates which depict the latest location of a moving object. this data is constantly getting updated (deleted and re-populated)
    this is being done in db1 and we are asked to replicate the tables and populate the latest data from the tables in db1 to corresponding tables in db2.
    we need to perform the same operation in db2 in every 5sec...thats the main issue
    we will be accessing these coordinates and display them on a map, later...
    performance wise which option will be good
    1. Materialized Views
    2. DBMS_JOBS (relating to a pl/sql code)
    also is there any much difference in performance from a normal view when compared to materialized views?
    please suggest
    Regards
    Sam

  • Materialized View Operator

    Hi All,
    In which scenario's we can use Materialized View Operator as a Target.
    What are advantages/features by using Materialized View Operator as a Target.
    Regards,
    Subbu

    Hi
    You can design views and materialized views in OWB using the mapping editor, and have the view/mv as a target operator, you then create the actual view/mv from the target operator by doing a 'create and bind', the SQL in the map will be the view/view definition. So you could design the summary as a mapping in OWB.
    See here for some details:
    http://blogs.oracle.com/warehousebuilder/2007/07/what_is_new_in_11g_and_10203_f.html
    Cheers
    David

  • Very high parse times for query rewrite using cube materialized views

    We recently upgraded to version 11.2.0.2 (both AWM and Oracle database server). We are using cube materialized views with query rewrite enabled. Some observations of changes that took place when we rebuilt all the dimensions and cubes in this version:
    1. Queries against the base tables take about 35 seconds to parse. Then they execute in a tenth of a second. Even simple queries that just get a sum of the amount from the fact table (which is joined to all the dimensions) takes that long to parse. Once parsed, the queries fly.
    2. I noticed that the materialized views used to use grouping sets in the group by clause in version 11.2.0.1, but now they use group by rollup, rollup, rollup...
    If we disable query rewrite on the MV or for my session, parse times drop to less than a second. Ideas?

    There does appear to be a slow down in parse times between 11.1.0.7 and 11.2. We are still investigating this, but in the meantime here is a way to force the code in 11.2 to generate a GROUPING SETS clause instead of the new ROLLUP syntax.
    The trick is to create a dummy hierarchy containing only the leaf level. This is necessary for all dimensions that currently have a single hierarchy. As a simple example I created a dimension, PROD, with three levels, A, B, and C, in a single hierarchy. I then created a one dimensional cube, PC. Here is the SELECT statement for the MV in 11.2. Note the ROLLUP clause in the GROUP BY.
    SELECT
      GROUPING_ID(T3."CLASS_ID", T3."FAMILY_ID", T3."ITEM_ID")  SYS_GID,
      (CASE GROUPING_ID(T3."CLASS_ID", T3."FAMILY_ID", T3."ITEM_ID")
       WHEN 3
       THEN TO_CHAR(('A_' || T3."CLASS_ID") )
       WHEN 1
       THEN TO_CHAR(('B_' || T3."FAMILY_ID") )
       ELSE TO_CHAR(('C_' || T3."ITEM_ID") )  END)     "PROD",
      T3."CLASS_ID" "D1_PROD_A_ID",
      T3."FAMILY_ID" "D1_PROD_B_ID",
      T3."ITEM_ID" "D1_PROD_C_ID",
      SUM(T2."UNIT_PRICE")     "PRICE",
      COUNT(T2."UNIT_PRICE")  "COUNT_PRICE",
      COUNT(*)  "SYS_COUNT"
    FROM
      GLOBAL."PRICE_AND_COST_FACT" T2,
      GLOBAL."PRODUCT_DIM" T3
    WHERE
      (T3."ITEM_ID" = T2."ITEM_ID")
    GROUP BY
      (T3."CLASS_ID") ,
      ROLLUP ((T3."FAMILY_ID") , (T3."ITEM_ID") )Next I modified the dimension to add a new hierarchy, DUMMY, containing just the leaf level, C. Once I have mapped the new level and re-enabled MVs, I get the following formulation.
    SELECT
      GROUPING_ID(T3."CLASS_ID", T3."FAMILY_ID", T3."ITEM_ID")  SYS_GID,
      (CASE GROUPING_ID(T3."CLASS_ID", T3."FAMILY_ID", T3."ITEM_ID")
       WHEN 3
       THEN ('A_' || T3."CLASS_ID")
       WHEN 1
       THEN ('B_' || T3."FAMILY_ID")
       WHEN 0
       THEN ('C_' || T3."ITEM_ID")
       ELSE NULL END)  "PROD",
      T3."CLASS_ID" "D1_PROD_A_ID",
      T3."FAMILY_ID" "D1_PROD_B_ID",
      T3."ITEM_ID" "D1_PROD_C_ID",
      SUM(T2."UNIT_PRICE")     "PRICE",
      COUNT(T2."UNIT_PRICE")  "COUNT_PRICE",
      COUNT(*)  "SYS_COUNT"
    FROM
      GLOBAL."PRICE_AND_COST_FACT" T2,
      GLOBAL."PRODUCT_DIM" T3
    WHERE
      (T3."ITEM_ID" = T2."ITEM_ID")
    GROUP BY
      GROUPING SETS ((T3."CLASS_ID") , (T3."FAMILY_ID", T3."CLASS_ID") , (T3."ITEM_ID", T3."FAMILY_ID", T3."CLASS_ID") )This puts things back the way they were in 11.1.0.7 when the GROUPING SETS clause was used in all cases. Note that the two queries are logically equivalent.

  • How can I fast refresh the  materialized view !!

    I created a MV base on some tables in order to improve the querey speed.
    but the mv I have created falied to refresh fast.
    because there are two same table in the from clause:
    jcdm jc1,jcdm jc2
    create materialized view temp_mv
    nologging
    pctfree 0
    storage (initial 2048k next 2048k pctincrease 0)
    parallel
    build immediate
    refresh force
    on demand
    as
    select
    TAB_GSHX.rowid hx_rid,
    TAB_GSHD.rowid hd_rid ,
    JC1.rowid jc1_rid ,
    JC2.rowid jc2_rid ,
    YSHD_ID     HXID,          
    JC1.JCDM     QFD,     
    JC2.JCDM     JLD     
    FROM
    TAB_GSHX,
    TAB_GSHD,
    jCDM JC1,
    JCDM JC2
    WHERE
    YSHD_ID=YSHX_ID
    AND YSHD_QFD=JC1.JBJC_ID
    AND YSHD_JLD=JC2.JBJC_ID
    AND TO_CHAR(YSHX_time,'YYYYMMDD')='20030101'
    the column msgtxt of the table MV_CAPABILITIES_TABLE is :
    "the multiple instances of the same table or view" and " one or more joins present in mv".
    How can I succeed in fast refresh the above temp_mv!!!
    thanks.

    lianjun,
    When you are using Oracle9i there is a procedure which can help you setup the materialized view. If some option isn't working it gives you hint why it doesn't work.
    The procedure is dbms_mview.explain_mview.
    Take a look at the documentation how to use it. (In the Oracle9i DWH guide the package is explained.)
    Hope this helps
    With kind regards,
    Bas Roelands

  • How to get Materialized View to ignore unused columns in source table

    When updating a column in a source table, records are generated in the corresponding materialized view log table. This happens even if the column being updated is not used in any MV that references the source table. That could be OK, so long as those updates are ignored. However they are not ignored, so when the MV is fast refreshed, I find it can take over a minute, even though no changes are required or made. Is there some way of configuring the materialized view log such that the materialized view refresh ignores these updates ?
    So for examle if I have table TEST:
    CREATE table test (
    d_id NUMBER(10) PRIMARY KEY,
    d_name VARCHAR2(100),
    d_desc VARCHAR2(256)
    This has an MV log MLOG$_TEST:
    CREATE MATERIALIZED VIEW LOG ON TEST with rowid, sequence, primary key;
    CREATE MATERIALIZED VIEW test_mv
    refresh fast on demand
    as
    select d_id, d_name
    from test;
    INSERT 200,000 records
    exec dbms_mview.refresh('TEST_MV','f');
    update test set d_desc = upper(d_desc) ;
    exec dbms_mview.refresh('TEST_MV','f'); -- This takes 37 seconds, yet no changes are required.
    Oracle 10g/11g

    I would love to hear a positive answer to this question - I have the exact same issue :-)
    In the "old" days (version 8 I think it was) populating the materialized view logs was done by Oracle auto-creating triggers on the base table. A "trick" could then make that trigger become "FOR UPDATE OF <used_column_list>". Now-a-days it has been internalized so such "triggers" are not visible and modifiable by us mere mortals.
    I have not found a way to explicitly tell Oracle "only populate MV log for updates of these columns." I think the underlying reason is that the MV log potentially could be used for several different materialized views at possibly several different target databases. So to be safe that the MV log can be used for any MV created in the future - Oracle always populates MV log at any update (I think.)
    One way around the problem is to migrate to STREAMS replication rather than materialized views - but it seems to me like swatting a fly with a bowling ball...
    One thing to be aware of: Once the MV log has been "bloated" with a lot of unneccessary logging, you may perhaps see that all your FAST REFRESHes afterwards becomes slow - even after the one that checked all the 200000 unneccessary updates. We have seen that it can happen that Oracle decides on full table scanning the MV log when it does a fast refresh - which usually makes sense. But after a "bloat" has happened, the high water mark of the MV log is now unnaturally high, which can make the full table scan slow by scanning a lot of empty blocks.
    We have a nightly job that checks each MV log if it is empty. If it is empty, it locks the MV log and locks the base table, checks for emptiness again, and truncates the MV log if it is still empty, before finally unlocking the tables. That way if an update during the day has happened to bloat the MV log, all the empty space in the MV log will be reclaimed at night.
    But I hope someone can answer both you and me with a better solution ;-)

  • Materialized View to run only once in a year...

    Hi everybody...
    I want to create a materialized view which will run only once in a year and specifically some minutes after 00:00 a.m. on new year's day,
    so i created the following:
    CREATE MATERIALIZED VIEW <mv_name>
    BUILD IMMEDIATE
    REFRESH START WITH TO_DATE('01/01/2007 00:15:00','DD/MM/RRRR HH24:MI:SS')
    NEXT SYSDATE+366
    I have two notes:
    1) how to declare the refresh to be done the first new year's day after the day it'll be created , i mean not static date (01/01/2007)
    2)some years are leap and some are not , so in order to run every new year's day how should i transform the above..????
    3)is there any view which displays the next run of a materialized view..???
    the view DBA_MV_REFRESH_TIMES displays the last refresh of mv's...
    I use Oracle 10.2.0.1 on XP ...
    Thanks , a lot
    Simon

    1).
    use the expression that evaluates to next january first.
    SQL> select sysdate, add_months(trunc(sysdate, 'yyyy'), 12) from dual ;
    SYSDATE     ADD_MONTHS(
    19-JUN-2006 01-JAN-2007
    1 row selected.
    SQL>2). for this also use the same expression that will evaluate to the january first of the year after that.

Maybe you are looking for