Top-N in Materialized View

Hello,
I have to create a materialized view for a top 10 query. "rownum" and "Rank()" doesn't work in a mv.
That's my query:
bq. SELECT * \\ FROM ( \\ SELECT RANK() OVER(order by sum(f.f_gebuehren) DESC) as Rang, sum(f.f_gebuehren), d.d_monat, d.d_jahr, a.a_name \\ FROM fakt f, datum d, anbieter a \\ WHERE f.d_datum=d.d_datum \\ AND f.a_id = a.a_id \\ GROUP BY d.d_monat, d.d_jahr, a.a_name) \\ WHERE Rang <= 10;
Are there any ideas of solving this problem?
Thanks

It should be a data warehouse with one fact table and two dimension tables.
select * from fakt where f_id < 10;
F_ID F_GEBUEHREN F_DAUER F_TARIFSTUFE F_PLZ F_TARIFZIEL F_TYP A_ID D_DATUM
1 3413,37577 975,25022 1 2 F P 2 27.09.05
2 4258,778808 1216,793945 1 7 F F 2 13.10.05
3 966,23501 439,197732 1 9 F F 3 26.02.05
4 2801,772922 800,506549 1 5 F F 2 17.04.05
5 2043,212511 583,775003 1 1 F P 2 17.09.05
6 1100,792739 314,512211 1 1 F P 2 26.01.04
7 436,147302 145,382434 3 3 F P 1 16.02.04
8 1997,94342 570,840977 1 4 F F 2 11.01.04
9 5587,168297 1596,333799 1 8 F P 2 25.06.04
select * from anbieter;
A_ID A_NAME
1 BTK AG
2 08-15 Telekom
3 Freie Wahl Telekom
select * from datum where rownum < 10;
D_DATUM D_JAHR D_HALBJAHR D_QUARTAL D_MONAT D_KW D_WT
09.11.05 2005 2 4 11 45 3
10.11.05 2005 2 4 11 45 4
11.11.05 2005 2 4 11 45 5
12.11.05 2005 2 4 11 45 6
13.11.05 2005 2 4 11 45 7
14.11.05 2005 2 4 11 46 1
15.11.05 2005 2 4 11 46 2
16.11.05 2005 2 4 11 46 3
17.11.05 2005 2 4 11 46 4
I hope this is the data you need...
Edited by: Patrick G. on Dec 19, 2008 7:31 PM

Similar Messages

Can we create materialized view on the top of another materialized view.

Hi ,
can we create materialized view on the top of another materialized view.
Thanks
Naveen

Welcome , Just remember is not good apporch to do that since performance when MV refresh
Please mark this thread as answered .

Materialized View On top of View Refesh Question

I have senario...where we have a MVW on top of view....How can I refesh the MVW everytime the view refreshes...?
THe MVW is very small (less than 150 rows)..and its straight data from view
any suggestions?

Hi dude,
Please refere below code
Materialized View Built on View Rewritten for FAST REFRESH
SQL> DROP MATERIALIZED VIEW scott.emp_v_MV;
SQL> CREATE MATERIALIZED VIEW scott.emp_v_MV
NOLOGGING
PARALLEL
BUILD IMMEDIATE
REFRESH FORCE ON DEMAND
ENABLE QUERY REWRITE
AS
select * from emp_v
SQL> truncate table mv_capabilities_table;
SQL> exec dbms_mview.explain_mview('scott.emp_v_mv');
SQL> set linesize 100
SQL> SELECT capability_name, possible, SUBSTR(msgtxt,1,60) AS msgtxt
           FROM mv_capabilities_table
           WHERE capability_name like '%FAST%';
CAPABILITY_NAME                P MSGTXT
REFRESH_FAST                   N
REFRESH_FAST_AFTER_INSERT      N named view in FROM list not supported   for this type MV
REFRESH_FAST_AFTER_INSERT      N named view in FROM list not supported for this type MV
REFRESH_FAST_AFTER_INSERT      N view or subquery in from list
REFRESH_FAST_AFTER_INSERT      N the detail table does not have a materialized view log
REFRESH_FAST_AFTER_ONETAB_DML N see the reason why REFRESH_FAST_AFTER_INSERT is disabled
REFRESH_FAST_AFTER_ANY_DML     N see the reason why REFRESH_FAST_AFTER_ONETAB_DML is disabled
REFRESH_FAST_PCT               N PCT is not possible on any of the detail tables in the mater
SQL> DROP MATERIALIZED VIEW scott.emp_v_MV;
SQL> CREATE MATERIALIZED VIEW scott.emp_v_MV
NOLOGGING
PARALLEL
BUILD IMMEDIATE
REFRESH FORCE ON DEMAND
ENABLE QUERY REWRITE
AS
select * from emp;
SQL> TRUNCATE TABLE mv_capabilities_table;
SQL> EXEC dbms_mview.explain_mview('scott.emp_v_mv');
SQL> SELECT capability_name, possible, SUBSTR(msgtxt,1,60) AS msgtxt
           FROM mv_capabilities_table
           WHERE capability_name like '%FAST%';
CAPABILITY_NAME                P MSGTXT
REFRESH_FAST                   Y
REFRESH_FAST_AFTER_INSERT      Y
REFRESH_FAST_AFTER_ONETAB_DML Y
REFRESH_FAST_AFTER_ANY_DML     Y
REFRESH_FAST_PCT               N PCT is not possible on any of the detail tables in the mater
Materialized View Aggregation with Required Materialized View Logs:
SQL> CREATE MATERIALIZED VIEW LOG ON scott.emp
WITH SEQUENCE, ROWID (JOB, DEPTNO, SAL)
INCLUDING NEW VALUES;
SQL> CREATE MATERIALIZED VIEW LOG ON scott.dept
WITH SEQUENCE, ROWID (DEPTNO)
INCLUDING NEW VALUES;
SQL> DROP MATERIALIZED VIEW scott.sal_dept_mv;
SQL> CREATE MATERIALIZED VIEW scott.sal_dept_mv
           NOLOGGING
           PARALLEL
           BUILD IMMEDIATE
           REFRESH FORCE ON DEMAND
           ENABLE QUERY REWRITE
           AS
          SELECT e.job, e.deptno, sum(e.sal)
          FROM emp e,
               dept d
          WHERE e.deptno=d.deptno
          GROUP BY e.job, e.deptno;

Creating Materialized View in Toad

As with every new endeavor - come new questions.
I am trying to create a materialized view via toad (first time doing this). Now - toad is great, since it provides a kind-of wizard interface. Hence, one doesn't have to completely code in the create statement, with all of the options, etc.
Instead, in toad, one can (via the schema browser), go into the Materialized Views tab and click on create new. This opens a window with 6 tabs: Basic Info, Refresh Info, Physical Attributes, Query, Partitions & Subpartition Template.
In the Basic Info, one can put a check mark next to some of the following options:
-Build Deffered
-Parallel
-Cache
-Logging
-Using index
-Allow updates
etc.
I have read that build deferred refers to whether or not you would like the view to be created automatically or to be deferred.
Anyways, I tried to find Toad documentation to explain each of the options in-detail. No success. Hence, am researching each part piece by piece.
But - here is my question:
In the Query tab, we are asked to specify a query. I am assuming that the query does not have to be a full query, beginning with CREATE MATERIALIZED VIEW mv_table1 REFRESH FAST etc...
Since in this 'wizard', we are providing the MV name at the top of the dialog box, we are checking the 'options' in the other tabs, etc.
And so, I assumed that the query should merely be a select query in the window mentioned above.
So I entered the following:
select * from table1@remote_db;
When I go to verify the syntax, I get the error message: ORA_00911: invalid character. It seems to be pointing to my db_link (remote_db). I have been using this link throughout many places, w/o any problems.
Has anyone created a MV in toad before? Any links to good toad documentation would be helpful as well.
Thanks.

(This is fun... ;))
For anyone endeavoring this in the future, below I have attached the prerequisites required in order to create a materialized view (can also be found @ http://download-uk.oracle.com/docs/cd/B14117_01/server.101/b10759/statements_6002.htm):
Prerequisites
The privileges required to create a materialized view should be granted directly rather than through a role.
To create a materialized view in your own schema:
You must have been granted the CREATE MATERIALIZED VIEW system privilege and either the CREATE TABLE or CREATE ANY TABLE system privilege.
You must also have access to any master tables of the materialized view that you do not own, either through a SELECT object privilege on each of the tables or through the SELECT ANY TABLE system privilege.
To create a materialized view in another user's schema:
You must have the CREATE ANY MATERIALIZED VIEW system privilege.
The owner of the materialized view must have the CREATE TABLE system privilege. The owner must also have access to any master tables of the materialized view that the schema owner does not own (for example, if the master tables are on a remote database) and to any materialized view logs defined on those master tables, either through a SELECT object privilege on each of the tables or through the SELECT ANY TABLE system privilege.
To create a refresh-on-commit materialized view (ON COMMIT REFRESH clause), in addition to the preceding privileges, you must have the ON COMMIT REFRESH object privilege on any master tables that you do not own or you must have the ON COMMIT REFRESH system privilege.
To create the materialized view with query rewrite enabled, in addition to the preceding privileges:
If the schema owner does not own the master tables, then the schema owner must have the GLOBAL QUERY REWRITE privilege or the QUERY REWRITE object privilege on each table outside the schema.
If you are defining the materialized view on a prebuilt container (ON PREBUILT TABLE clause), then you must have the SELECT privilege WITH GRANT OPTION on the container table.
The user whose schema contains the materialized view must have sufficient quota in the target tablespace to store the master table and index of the materialized view or must have the UNLIMITED TABLESPACE system privilege.
When you create a materialized view, Oracle Database creates one internal table and at least one index, and may create one view, all in the schema of the materialized view. Oracle Database uses these objects to maintain the materialized view data. You must have the privileges necessary to create these objects.

Need advise : Risks of using materialized views

Hi -
I need some advise on whether using a materilzied view can help in teh folloiwng scenario.
Scenario : You have a large tables which has sy 60 million rows, This is a demand management application which accesses this data at various aggregate levels (It is not using any OLAP functionality). The worksheets that is used to display the data takes up hours to execute on.
To solve teh above scenario I created partitions on the base table say by time and the on top I created some materialized views. This gave me tremendoud gain in performance for the worksheets.
Question is : Will Materialzied views help in situations say where the user changes the data in the worksheet and another user tries to query the changes will the materialized view be able to show the changes or do I need enforce a fast refresh. all the standard option of enabling query rewrite and fast refresh are enabled. The parameter for query_rewrite_integrity is set to Trusted.
Please advise what could be teh pitfalls in managing such huge data where some of it changes infrequently.

Hi Arch,
Will Materialzied views help in situations say where the user changes the data in the worksheet and another user tries to query the changes will the materialized view be able to show the changes or do I need enforce a fast refresh.That depends on your "stale tolerance":
http://www.dba-oracle.com/t_materialized_view_fast_refresh_performance.htm
pitfalls in managing such huge data where some of it changes infrequently. If it does not change frequently, then it's just a matter of extra disk space for the materializations. I have more notes here:
http://www.dba-oracle.com/t_finding_materialized_view_contents.htm
Hope this helps. . .
Don Burleson
Oracle Press author
Author of “Oracle Tuning: The Definitive Reference”
http://www.dba-oracle.com/bp/s_oracle_tuning_book.htm

Materialized view takes long to refresh

On Oracle 11g2, I created a materialized view fast refresh on commit CREATE MATERIALIZED VIEW mv_case
PARALLEL BUILD IMMEDIATE REFRESH FAST ON COMMIT ENABLE QUERY REWRITE AS
SELECT p.jperson_id,offense_id,CASE_SENTENCE_DATE,court_ref,CASE_COURT_ORI,
c.CASE_VERDICT_DATE,CASE_DOCKET,c.CASE_EXPUNGED,c.jcase_id,cc.CYCLEID_ID,
p.rowid p_rowid,xc.rowid xc_rowid,c.rowid c_rowid,cxo.rowid cxo_rowid,cc.rowid cc_row_id
FROM jperson p,jperson_x_jcase xc,jcase c,jcase_x_offense cxo,jcase_x_cycleid cc
where p.jperson_id = xc.jperson_id(+) and xc.jcase_id = c.jcase_id(+)
and c.jcase_id = cxo.jcase_id(+) and c.jcase_id=cc.jcase_id;
create index idx_mv_case_pid on mv_case(jperson_id);
ALTER TABLE mv_case ADD (CONSTRAINT PK_MV_CASE PRIMARY KEY(jcase_id,offense_id)) ;
create index idx_mv_case_p_rowid on mv_case(p_rowid);
create index idx_mv_case_xc_rowid on mv_case(xc_rowid);
create index idx_mv_case_c_rowid on mv_case(c_rowid);
create index idx_mv_case_cxo_rowid on mv_case(cxo_rowid);
create index idx_mv_case_cc_rowid on mv_case(cc_row_id); I inserted one single row into one of the master table
insert into jcase_x_offense (offense_id,jcase_id) values ('test_row3','test_row3');
commit; The commit tooks a quite long. I looked into the trace file and the actual insert took 0.01 seconds but one of the internel DML took most of time. I copy the relevant TKPROF output for the internal DML belowINSERT INTO QAPF.MV_CASE SELECT /*+ NO_MERGE(JV$) */
MAS$4.JPERSON_ID,JV$.OFFENSE_ID,MAS$2.CASE_SENTENCE_DATE,
MAS$2.COURT_REF,MAS$2.CASE_COURT_ORI,MAS$2.CASE_VERDICT_DATE,
MAS$2.CASE_DOCKET,MAS$2.CASE_EXPUNGED,MAS$2.JCASE_ID,
MAS$0.CYCLEID_ID,MAS$4.ROWID,MAS$3.ROWID,MAS$2.ROWID,JV$.RID$,
MAS$0.ROWID
FROM ( SELECT MAS$.ROWID RID$ , MAS$.* FROM QAPF.JCASE_X_OFFENSE MAS$ WHERE ROWID IN
          (SELECT /*+ HASH_SJ */ CHARTOROWID(MAS$.M_ROW$$) RID$
           FROM QAPF.MLOG$_JCASE_X_OFFENSE MAS$ WHERE MAS$.XID$$ = :1 )) JV$,
JCASE_X_CYCLEID AS OF SNAPSHOT(:B_SCN) MAS$0, JCASE AS OF SNAPSHOT(:B_SCN) MAS$2,
JPERSON_X_JCASE AS OF SNAPSHOT(:B_SCN) MAS$3, JPERSON AS OF SNAPSHOT(:B_SCN) MAS$4
WHERE (MAS$4.JPERSON_ID=MAS$3.JPERSON_ID(+)
AND MAS$3.JCASE_ID=MAS$2.JCASE_ID(+)
AND MAS$2.JCASE_ID=JV$.JCASE_ID(+)
AND MAS$2.JCASE_ID=MAS$0.JCASE_ID)
AND NOT EXISTS (
    SELECT 1 FROM QAPF.MV_CASE SNA2$
    WHERE (SNA2$.P_ROWID = MAS$4.ROWID)
    AND (SNA2$.XC_ROWID = MAS$3.ROWID OR MAS$3.ROWID IS NULL )
    AND (SNA2$.C_ROWID = MAS$2.ROWID OR MAS$2.ROWID IS NULL )
    AND (SNA2$.CC_ROW_ID = MAS$0.ROWID OR MAS$0.ROWID IS NULL )
    AND JV$.RID$ IS NULL)
AND NOT EXISTS (
    SELECT 1 FROM JCASE_X_OFFENSE MAS_INNER$, JCASE AS OF SNAPSHOT(:B_SCN) MAS_OUTER$
    WHERE MAS$2.ROWID = MAS_OUTER$.ROWID AND JV$.RID$ IS NULL
    AND MAS_OUTER$.JCASE_ID=MAS_INNER$.JCASE_ID)
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1     99.51     364.87     377012   17412972          1           0
Fetch        0      0.00       0.00          0          0          0           0
total        2     99.51     364.87     377012   17412972          1           0
Rows     Row Source Operation
      0 LOAD TABLE CONVENTIONAL (cr=17412968 pr=377012 pw=120527 time=0 us)
      0   FILTER (cr=17412968 pr=377012 pw=120527 time=0 us)
3363837    HASH JOIN RIGHT OUTER (cr=264914 pr=280254 pw=120527 time=35845080 us cost=299444 size=1029332286 card=3363831)
      1     VIEW (cr=112490 pr=180864 pw=119722 time=0 us cost=30743 size=78 card=1)
      1      HASH JOIN SEMI (cr=112490 pr=180864 pw=119722 time=0 us cost=72627 size=208 card=1)
11354346       TABLE ACCESS FULL JCASE_X_OFFENSE (cr=112488 pr=112447 pw=0 time=4814838 us cost=30703 size=749386770 card=11354345)
      1       TABLE ACCESS BY INDEX ROWID MLOG$_JCASE_X_OFFENSE (cr=2 pr=0 pw=0 time=0 us cost=1 size=142 card=1)
      1        INDEX RANGE SCAN IDX_MLOG$_XID_JCASE_X_OFFENSE (cr=1 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 98375)
3363837     HASH JOIN (cr=152424 pr=99390 pw=805 time=29973970 us cost=268690 size=766953468 card=3363831)
2994042      INDEX FAST FULL SCAN JPERSON_I0 (cr=18134 pr=0 pw=0 time=772990 us cost=17450 size=134731845 card=2994041)(object id 83738)
3363837      HASH JOIN (cr=134290 pr=99390 pw=805 time=25292580 us cost=212128 size=615581073 card=3363831)
3363837       HASH JOIN (cr=69008 pr=34127 pw=805 time=4750330 us cost=101637 size=393568929 card=3363837)
3363837        TABLE ACCESS FULL JCASE_X_CYCLEID (cr=33337 pr=33322 pw=0 time=2942460 us cost=33569 size=222013242 card=3363837)
6586646        TABLE ACCESS FULL JCASE (cr=35671 pr=0 pw=0 time=1584102 us cost=35988 size=335918895 card=6586645)
6586635       TABLE ACCESS FULL JPERSON_X_JCASE (cr=65282 pr=65263 pw=0 time=5446686 us cost=65632 size=434717844 card=6586634)
3363837    FILTER (cr=17148054 pr=96758 pw=0 time=0 us)
3363837     MAT_VIEW ACCESS BY INDEX ROWID MV_CASE (cr=17148054 pr=96758 pw=0 time=0 us cost=7 size=40 card=1)
32464070      INDEX RANGE SCAN IDX_MV_CASE_P_ROWID (cr=4489770 pr=15250 pw=0 time=19576798 us cost=3 size=0 card=7)(object id 98467)
      0    FILTER (cr=0 pr=0 pw=0 time=0 us)
      0     NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=4 size=78 card=1)
      0      TABLE ACCESS BY USER ROWID JCASE (cr=0 pr=0 pw=0 time=0 us cost=1 size=45 card=1)
      0      INDEX RANGE SCAN JCASE_X_OFFENSE_I0 (cr=0 pr=0 pw=0 time=0 us cost=3 size=33 card=1)(object id 83623)Questions:
1) what are the objects like JCASE AS OF SNAPSHOT(:B_SCN) ? Can I index them? I tried access it but got error
select * from JCASE AS OF SNAPSHOT(:B_SCN) ;
ORA-08187: snapshot expression not allowed here
08187. 00000 - "snapshot expression not allowed here"
*Cause:    A snapshot expression using AS OF was specified when not allowed.
*Action:   Do not use the AS OF clause
2) In the inline view following the firs FROM, it used ROWID in where clause. I tried create an index on ROWID, and error
create index idx_jcase_offense_rid on JCASE_X_OFFENSE(rowid)
ERROR at line 1:
ORA-00904: : invalid identifier
Note: I checked that I have indexes all fields in all where clauses in the DML except rowid.
Thanks for help.

sybrand_b wrote:
1 Apparently Oracle is using Flashback technology when no materialized view logs have been set up
As your MV is a complex MV it is not a candidate for FAST REFRESH ON COMMIT.
I haven't looked closely at how 11.2 has changed the "fast refresh on commit" - but I would have expected it to raise an Oracle error when the OP tried to create the materialized view with that option if it were not possible.
I think your first comment is probably the more important one - if the user sets up suitable materialized view logs on all the tables in the outer join then it's possible that the fast refresh could work properly.
This is pure speculation, of course, based on the absence of an error message.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
There is a +"Preview"+ tab at the top of the text entry panel. Use this to check what your message will look like before you post the message. If it looks a complete mess you're unlikely to get a response. (Click on the +"Plain text"+ tab if you want to edit the text to tidy it up.)
+"Science is more than a body of knowledge; it is a way of thinking"+
+Carl Sagan+

Materialized View with Joins

Dear Dev/DBAs,
I have the following scenario:
SQL> CREATE TABLE T1 (ID NUMBER(3),NAME VARCHAR2(10));
SQL> CREATE TABLE T2 (ID NUMBER(3),NAME VARCHAR2(10));
The T1 contains records having the ID num from 10 to 80 and the T2 having the ID from 90 to 170
SQL> SELECT * FROM T1 JOIN ALL SELECT * FROM T2
It give all records in the 2 tables.
I'm planning to create a materialized view (like CREATE MATERIALIZED VIEW V_TAB REFRESH ON COMMIT AS SELECT * FROM T1 JOIN ALL SELECT * FROM T2) and it seems i can't do with the error ORA-12054, further the oracle documentation says that materialized view can only be used with a simple join.
Do you have another solution??
Note that the materialized views can be used to improve queries.
Thank you in advance

Straight from the link I posted:
*Restrictions on Fast Refresh on Materialized Views with UNION ALL*Materialized views with the UNION ALL set operator support the REFRESH FAST option if the following conditions are satisfied:
* The defining query must have the UNION ALL operator at the top level.
The UNION ALL operator cannot be embedded inside a subquery, with one exception: The UNION ALL can be in a subquery in the FROM clause provided the defining query is of the form SELECT * FROM (view or subquery with UNION ALL) as in the following example:
CREATE VIEW view_with_unionall AS
(SELECT c.rowid crid, c.cust_id, 2 umarker
FROM customers c WHERE c.cust_last_name = 'Smith'
UNION ALL
SELECT c.rowid crid, c.cust_id, 3 umarker
FROM customers c WHERE c.cust_last_name = 'Jones');
CREATE MATERIALIZED VIEW unionall_inside_view_mv
REFRESH FAST ON DEMAND AS
SELECT * FROM view_with_unionall;
Note that the view view_with_unionall satisfies the requirements for fast refresh.
* Each query block in the UNION ALL query must satisfy the requirements of a fast refreshable materialized view with aggregates or a fast refreshable materialized view with joins.
The appropriate materialized view logs must be created on the tables as required for the corresponding type of fast refreshable materialized view.
Note that the Oracle Database also allows the special case of a single table materialized view with joins only provided the ROWID column has been included in the SELECT list and in the materialized view log. This is shown in the defining query of the view view_with_unionall.
* The SELECT list of each query must include a maintenance column, called a UNION ALL marker. The UNION ALL column must have a distinct constant numeric or string value in each UNION ALL branch. Further, the marker column must appear in the same ordinal position in the SELECT list of each query block.
* Some features such as outer joins, insert-only aggregate materialized view queries and remote tables are not supported for materialized views with UNION ALL.
* Partiton Change Tracking (PCT)-based refresh is not supported for UNION ALL materialized views.
* The compatibility initialization parameter must be set to 9.2.0 or higher to create a fast refreshable materialized view with UNION ALL.

Materialized view with join

In 10g release 2,I tried to create following materialized view with join:
test_link is a normal table
test_geom is a table contains a column in SDO_GEOMETRY
CREATE MATERIALIZED VIEW LOG ON test_link with rowid
CREATE MATERIALIZED VIEW LOG ON test_geom with rowid,primary key
CREATE MATERIALIZED VIEW MV_LINK USING INDEX REFRESH FAST ON DEMAND AS
SELECT li.rowid link_rowid,geom.rowid geom_rowid,li.link_id,geom.link
FROM test_link li, test_geom geom
WHERE li.link_id=geom.link_id
But I always got an error like:
ORA-12015: cannot create a fast refresh materialized view from a complex query
If I change the geometry table to another table, everything works fine.
Anyone have ideas?

Unfortunately, creating a fast refreshable materialized view on a join with one of the select columns being a user defined type (sdo_geometry is a user defined type) is not allowed. See 5303489 in the metalink bug database.
You could do like the workaround in the article suggests and create two materialized views and then create a regular view on top.
In our scenario, our materialized view also contains unions, so we would really like to have one physical object at the end of the day. One approach that we are currently investigating is to create the materialized view (MV1) without the geometry column, which makes it fast refreshable, and also create a materialized view (MV2) on the table containing the geometry column. MV2 is also fast refreshable. We then create a table (T3) that contains all of the columns from MV1, plus a geometry column. An insert, update, delete trigger on MV1 is created. The trigger is used to push all of the columns from MV1 to T3 and the geometry column from MV2 to T3. I have created the above in one of our test environments and haven't encountered any issues yet.
Let me know if you come up with a better approach.

Problem with Materialized Views in 10g

Hi All,
I am creating a Materialized View like
CREATE MATERIALIZED VIEW mvname TABLESPACE SYSTEM BUILD IMMEDIATE REFRESH WITH ROWID FOR UPDATE AS ( SELECT a,b,c FROM table_a,table_b,table_c WHERE cond );
I am getting an error
SQL Error: ORA-12013: updatable materialized views must be simple enough to do fast refresh.
Can anyone tell what is the problem?
I have included rowid of all three tables in select clause.

Hi,
From Oracle Docs:
ORA-12013: updatable materialized views must be simple enough to do fast refresh
Cause: The updatable materialized view query contained a join, subquery, union, connect by, order by, or group by caluse.
Action: Make the materialized view simpler. If a join is really needed, make multiple simple materialized views then put a view on top of them.
Regards
K.Rajkumar

Materialized views on prebuilt tables - query rewrite

Hi Everyone,
I am currently counting on implementing the query rewrite functionality via materialized views to leverage existing aggregated tables.
Goal*: to use aggregate-awareness for our queries
How*: by creating views on existing aggregates loaded via ETL (+CREATE MATERIALIZED VIEW xxx on ON PREBUILT TABLE ENABLE QUERY REWRITE+)
Advantage*: leverage oracle functionalities + render logical model simpler (no aggregates)
Disadvantage*: existing ETL's need to be written as SQL in view creation statement --> aggregation rule exists twice (once on db, once in ETL)
Issue*: Certain ETL's are quite complex via lookups, functions, ... --> might create overy complex SQLs in view creation statements
My question: is there a way around the issue described? (I'm assuming the SQL in the view creation is necessary for oracle to know when an aggregate can be used)
Best practices & shared experiences are welcome as well of course
Kind regards,
Peter

streefpo wrote:
I'm still in the process of testing, but the drops should not be necessary.
Remember: The materialized view is nothing but a definition - the table itself continues to exist as before.
So as long as the definition doesn't change (added column, changed calculation, ...), the materialized view doesn't need to be re-created. (as the data is not maintained by Oracle)Thanks for reminding me but if you find a documented approach I will be waiting because this was the basis of my argument from the beginning.
SQL> select * from v$version ;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE     11.2.0.1.0     Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production
SQL> desc employees
Name                                                                                            Null?    Type
EMPLOYEE_ID                                                                                     NOT NULL NUMBER(6)
FIRST_NAME                                                                                               VARCHAR2(20)
LAST_NAME                                                                                       NOT NULL VARCHAR2(25)
EMAIL                                                                                           NOT NULL VARCHAR2(25)
PHONE_NUMBER                                                                                             VARCHAR2(20)
HIRE_DATE                                                                                       NOT NULL DATE
JOB_ID                                                                                          NOT NULL VARCHAR2(10)
SALARY                                                                                                   NUMBER(8,2)
COMMISSION_PCT                                                                                           NUMBER(2,2)
MANAGER_ID                                                                                               NUMBER(6)
DEPARTMENT_ID                                                                                            NUMBER(4)
SQL> select count(*) from employees ;
COUNT(*)
       107
SQL> create table mv_table nologging as select department_id, sum(salary) as totalsal from employees group by department_id ;
Table created.
SQL> desc mv_table
Name                                                                                            Null?    Type
DEPARTMENT_ID                                                                                            NUMBER(4)
TOTALSAL                                                                                                 NUMBER
SQL> select count(*) from mv_table ;
COUNT(*)
        12
SQL> create materialized view mv_table on prebuilt table with reduced precision enable query rewrite as select department_id, sum(salary) as totalsal from employees group by department_id ;
Materialized view created.
SQL> select count(*) from mv_table ;
COUNT(*)
        12
SQL> select object_name, object_type from user_objects where object_name = 'MV_TABLE' ;
OBJECT_NAME                                                                                                                      OBJECT_TYPE
MV_TABLE                                                                                                                         TABLE
MV_TABLE                                                                                                                         MATERIALIZED VIEW
SQL> insert into mv_table values (999, 100) ;
insert into mv_table values (999, 100)
ERROR at line 1:
ORA-01732: data manipulation operation not legal on this view
SQL> update mv_table set totalsal = totalsal * 1.1 where department_id = 10 ;
update mv_table set totalsal = totalsal * 1.1 where department_id = 10
ERROR at line 1:
ORA-01732: data manipulation operation not legal on this view
SQL> delete from mv_table where totalsal <= 10000 ;
delete from mv_table where totalsal <= 10000
ERROR at line 1:
ORA-01732: data manipulation operation not legal on this view While investigating for this thread I actually made my own question redundant as the answer became gradually clear:
When using complex ETL's, I just need to make sure the complexity is located in the ETL loading the detailed table, not the aggregate
I'll try to clarify through an example:
- A detailed Table DET_SALES exists with Sales per Day, Store & Product
- An aggregated table AGG_SALES_MM exists with Sales, SalesStore per Month, Store & Product
- An ETL exists to load AGG_SALES_MM where Sales = SUM(Sales) & SalesStore = (SUM(Sales) Across Store)
--> i.e. the SalesStore measure will be derived out of a lookup
- A (Prebuilt) Materialized View will exist with the same column definitions as the ETL
--> to allow query-rewrite to know when to access the table
My concern was how to include the SalesStore in the materialized view definition (--> complex SQL!)
--> I should actually include SalesStore in the DET_SALES table, thus:
- including the 'Across Store' function in the detailed ETL
- rendering my Aggregation ETL into a simple GROUP BY
- rendering my materialized view definition into a simple GROUP BY as wellNot sure how close your example is to your actual problem. Also don't know if you are doing an incremental/complete data load and the data volume.
But the "SalesStore = (SUM(Sales) Across Store)" can be derived from the aggregated MV using analytical function. One can just create a normal view on top of MV for querying. It is hard to believe that aggregating in detail table during ETL load is the best approach but what do I know?

Equivalent of Materialized Views in SQL Server

Hi
we are migrating Oracle Database to SQL Server 2012 and is looking for solution, equivalent to Materialized Views in Oracle.
we had tried to implement indexed View, but that was not possible, because the MVs have outer joins, subqueries, aggregate functions and also there is no column in it which can act as a Primary Key.
Please Help to get a solution for this issue.
Regards
Joyasree Mondal

>use tempdb
>drop table t
>go
>create table t(id int, constraint pk_t primary key (id))
>
>go
>insert into t(id)
>select top 1000 cast( cast( newid() as binary(4) ) as int)
>from sys.objects o, sys.columns c
>go 100
>
>
>select id
>from t with (index=pk_t, tablockx)
>
>
>select id
>from t with (index=pk_t, nolock)
Still the same order.
>> No, its always in the key order like I've shown here.
> You are extrapolating from a single example.
Actually, this information doesn't even come from my exampleS (there were quite a few so far). Its written in the article you posted here. My examples are meant to confirm that and explain why the ORDER BY clause is redundant in some cases.
> I have. ORDER BY in a view used to always return ordered results. Then it didn't.
Examples? References?
>GROUP BY without an ORDER BY used to always return ordered results. Then it didn't. Many queries have >change the result ordering when you get a parallel plan.
Now you finally admit ordered results would always be returned, even without an order by clause. We are in the right track it appears. The reason for this change of behavior is a variation in the logical operator used by the query optimizer, and not the
way the engine reads pages from disk.
In the beginning of times there was stream aggregate, an operator that would require its input to be sorted. And this is how a GROUP BY clause would ensure results were always ordered.
But then his ugly cousin came and messed things up. He doesnt need an ordered input so yeah, order would be random. AGAIN, there are still ways of enforcing order here, through query hints, without requiring an order by clause, so this changes nothing.
You have confirmed that for a given operator, results will always be ordered. Your own argument has, once again, proven my point.
> Right. But there are different _kinds_ of scans. An ordered scan, where SQL Server reads rows based on the logical order of the index is just one kind.
It only won't scan in key order (by scheduling reads) if you change the transaction isolation level and hope for the worse. Because the key order scan is the best performing way of reading pages, this behavior (although possible) wasan't even observed in
the example with NOLOCK/TABLOCK (known to cause allocation-order scans in larger tables) you posted above.
> Other kinds include the parallel scan, the reverse scan,
References?
> the merry-go-round scan,
Only applies to table scans, not indexes.
http://technet.microsoft.com/en-us/library/ms191475%28v=SQL.105%29.aspx
> And the allocation-order (or unordered) scan.
Only if you specify TABLOCK or NOLOCK query hints, which I haven't done. This is something that goes without saying, it's irrelevant to an indexed view scenario such as this one.
Some people have also said it will perform an allocation-order scan if the index is too fragmented in SQL Server 2005, but as of 2012 it (probably) won't, as I have shown here. There is also no document anywhere in the internet (you are free to search for
it), that would point us otherwise. If you have access to additional information, I would be more than happy if you could share it with us.
Reference: http://sqlmag.com/database-development/quaere-verum-clustered-index-scans-part-iii
> And don't take my word for it. Take Conor Cunningham's:
>If you need order in your query results, put in an ORDER BY. It's that simple. Anything else is like >riding in a car without a seatbelt.
>No Seatbelt - Expecting Order without ORDER BY
Again, with all due respect, did you read your own article? Did you read what I said earlier about having multiple I/O threads as a whole other situation? If you add new variables, OF COURSE the results will be different. Parallelism was disabled in the
server I performed these tests on, but still you can control this by query hints, and you can enforce execution plans by using plan gudes.
Its like I always say - it's always about the 0.001% of situations, the exceptions, rather than the general rule.
Tell Mr Connor to add MAXDOP 1 to his querys OPTION clause and see if results are still unordered lol
References:
http://msdn.microsoft.com/en-us/library/ms190417.aspx
http://msdn.microsoft.com/en-us/library/ms181714.aspx
http://technet.microsoft.com/en-us/library/ms188611%28v=sql.105%29.aspx
http://blogs.msdn.com/b/conor_cunningham_msft/archive/2008/08/27/no-seatbelt-expecting-order-without-order-by.aspx
Imagining uncontrollable factors that would get an ordered input to be retrieved in an unordered manner is one of SQL Server's myths. There are a whole other people around who think the same way because of some experiences they had when they didn't know
how to control the execution plan, and adding an order by clause is a very popular and easy shortcut to a complex problem. "In the worst cases it will just be redundant", they say. What they like to forget is that sorting has an often high cost,
and it can be avoided by taking advantage of indexes.

Materialized view with dynamic column names !

hello,
i need some help , i'm trying ( i got no where so far :) ) to create a materialized
view that has dynamic field name values , so every time the view is refreshed
the fields are renamed.
i have been asked to create a decade summary view and to assign year values to field names,the years should be table columns ( not rows !? ) and thus i should reflect this fact to the column names.
i know its a wierd request but is there anway to do it ?
i dunno about it at least,
Thanks !

...or you could define the materialised view neutrally e.g. with columns like YEAR1, YEAR2 etc.
Then create a dynamically-defined view on top of this view, after it's refreshed, using the relevant years as column names. SELECT year1 AS "1991", year2 AS "1992" etc.
I still don't see how anybody is going to use these views as they won't know what the "year" columns are called.
And if the same materialised view is going to have different sets of data each time it's refreshed i.e. different sets of years, are you re-defining the selection criteria each time? If so, why not just define separate views?
It's a weird world out there...

Materialized view log update question

Hi, I am running into a question regarding mview - not sure if it should behave that way or I didn't use it right.
I have two base tables, sales and customers (drived from nested materialized view example in oracle doc):
CREATE TABLE sales
cust_ID VARCHAR2(32 BYTE) NOT NULL,
amount_sold NUMBER,
TEMP VARCHAR2(100 BYTE),
CONSTRAINT sales_pk PRIMARY KEY (cust_id)
CREATE TABLE customers
cust_ID VARCHAR2(32 BYTE) NOT NULL,
CUST_LAST_NAME VARCHAR2(100 BYTE),
TEMP VARCHAR2(100 BYTE),
CONSTRAINT cust_pk PRIMARY KEY (cust_id)
CREATE MATERIALIZED VIEW LOG ON sales
WITH ROWID (cust_id, amount_sold);
CREATE MATERIALIZED VIEW LOG ON customers
WITH ROWID (cust_id, cust_last_name);
Then I create a fast refresh materialized view based on them:
CREATE MATERIALIZED VIEW join_sales_cust
REFRESH FAST ON DEMAND AS
SELECT c.cust_id, c.cust_last_name, s.amount_sold, s.rowid srid, c.rowid crid
FROM sales s, customers c
WHERE s.cust_id = c.cust_id;
Since this materialized view only invole cust_id and amount_sold from sales and cust_id and last_name from customers table, I do not want to trigger materialized view log entry if the TEMP column value gets updated. So follow update shouldn't trigger mlog:
update sales set TEMP='TEMP2' where cust_id=1
but this update should:
update sales set amount_sold=3 where cust_id=1
What I am seeing happenning is any update on the base table will triger mlog entried regardless whether the column is involed in the materialized view or not.
Can someone please confirm if this is the correct behavior and whether there is a way to accomplish what I wanted to do?
Thank you!
Edited by: user3933488 on Jan 8, 2010 12:53 PM

You created the materialized view logs with some columns, which is not necessary when creating a join MV on top of them. You can happily skip those in your MV log definition. And then it becomes clear that those columns are not involved in the decision whether a MV log needs to be updated or not. Everything that happens to the base table gets recorded. The "WITH ROWID" and "INCLUDING NEW VALUES" and the column list only specify WHAT should be recorded when something changed.
Regards,
Rob.

Oracle Text Index on Materialized View

Hello,
I have designed a search engine for an internet application.
We have different tables for our main business objects, the search is based on the content of all these dependent entities (Product, Company etc...)
So I have created a materialized view to embody this aggregation.
Then I have created a Multi column datastore index on top of the snapshot.
The search engine has to be refreshed automatically 3 times a day, and manually anytime.
This is achieved by executing a complete refresh on the view and rebuild the index, programmatically via Toplink (SqlCall).
The MV refresh looks like this :
alter index usr_batiprod.fullTextMulticolIdx rebuild
and the index rebuild:
begin
DBMS_MVIEW.REFRESH('FT_TEST','C');
end;
Everything was fine until now, we have had lots of tuning on the index side, the refresh process was working fine...
We have let the users access the engine since Thursday (the index had been created on the production environment a fews weeks ago) and since yesterday (or maybe before) we have been experiencing data incoherency on the index...
I've tracked down the pb to the Fulltext Search's refresh process (manual and automatic share the same code) that was crashing on the Materialized view refresh :
java.sql.SQLException: ORA-20000: Oracle Text error:
DRG-50610: internal error: drexdsync
DRG-50857: oracle error in drekrtd (lob erase)
ORA-00060: deadlock detected while waiting for resource
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 794
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 851
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 832
ORA-06512: at line 2
Again, we had tested the functionality thoroughly and never experienced such behaviour before... even while refreshing the materialized view and the index 3 times (or more) a day..
Once I dropped the Oracle Text Index, I was able to refresh the MV again..
so it looks like the index was in some incoherent state and was holding a lock on the materialized view...
Maybe my Index refresh call is wrong, and a stronger load on the functionality leads quickly to this pb, I dont know..
I had always been a bit doubtful towards my index rebuild call, so Im thinking about using a more complete call :
alter index usr_batiprod.fullTextMulticolIdx rebuild parameters ('sync')
is it enough, or do I have to switch to a 'Oracle Text' specific call ?
Is there another possible reason for the MV lock ?
Thank you for your support
Best Regards
Olivier Cuzacq

MVs are constructed in different ways and have lots of different uses.
Why not just use MV as temp table for OT (Oracle Text) index?
Refresh MV OT_TEMP.
Delete all not matching rows from OT.
Insert all missing missing rows from OT_TEMP to OT.
sync OT index (online).
Query table OT.

How to prevent materialized views from refreshing if source table is zero

any ideas?

Probably not what you were hoping for but here are a couple of ideas.
Your account shows - 113 (85 unresolved)
1. How about helping to keep the forum clean by reviewing your 85 unresolved previous questions and giving HELPFUL or ANSWERED credit to those that helped you in the past.
2. Read the FAQ at the top right of the page and post the information about your system and software so that we know what you are working with.
3. Ask your question in the body of the thread. Don't just say 'Any ideas'.
What exactly is your question? Is this an academic question or do you have an actual problem that needs to be addressed?
If you have an actual problem produce the DDL for the materialized view and information about the type of refresh that has been set up for it. Is there a materialized view log on the base table(s)?
The simple answer to your quest is to use REFRESH ON DEMAND and check the base table(s) before you do a manual
refresh. The best answer depends on what version of Oracle you are using and what your actual setup is. Are your
MVs in REFRESH GROUPS?. That can make a difference in the answer.
How can anyone help with this question if you won't provide the information needed(FAQ)? Why SHOULD anyone help if you show you don't appreciate the help by marking questions answered once you have been helped.

Top-N in Materialized View

Similar Messages

Maybe you are looking for