Using time dimension in materialized view

Do anybody has an example of using Time dimension in MVIEW?. The time tablke has no relation with oder object (ex. i will join the time table with sales table, which has no relation with each other.
Thanks in advance
Mehdi

Hi
Check the foreign key on the fact table to see how it is related to the time dimension table.
Cheers
David

Similar Messages

How to use time dimension.

Hi All,
I have to create a report that will show the worth of portfolio based on time frame that is monthly, quarterly, yearly and since inception.
How can i proceed because i have never used time dimension?
Further i have only one column "Date" in the portfolio table that has a corresponding
worth value. SO i need to create the dimension based on this date column.
Pls help me
Thanks

If all you want is to achieve drills from Month, Quarter and Year then treat it as a normal dimension and create the levels. But if you want to do calculations like YTD, QTD and MTD then you need to create a time dimension. Check my blog entry here http://oraclebizint.wordpress.com/2007/11/05/oracle-bi-ee-101332-understanding-todate-and-ago-achieving-ytd-qtd-and-mtd/ for creating a sample time dimension. Also, you need to manually create logical columns corresponding to the levels that you need. So, if you have only a date column then create logical columns Year, Month and Quarter from this column and then create the time dimension.
Thanks,
Venkat
http://oraclebizint.wordpress.com

Alternative for OUTER Join for use in fast refresh materialized view

Hi ,
I have two tables as :
CREATE TABLE TEST_SANDY1
COL1 NUMBER
CREATE TABLE TEST_SANDY2
COL1 NUMBER,
COL2 VARCHAR2(10 BYTE)
Data for the tables are :
INSERT INTO TEST_SANDY1 ( COL1 ) VALUES (
1);
INSERT INTO TEST_SANDY1 ( COL1 ) VALUES (
2);
INSERT INTO TEST_SANDY1 ( COL1 ) VALUES (
3);
COMMIT;
INSERT INTO TEST_SANDY2 ( COL1, COL2 ) VALUES (
1, 'a');
INSERT INTO TEST_SANDY2 ( COL1, COL2 ) VALUES (
2, 'b');
INSERT INTO TEST_SANDY2 ( COL1, COL2 ) VALUES (
4, 'd');
COMMIT;
Now when I run the following select statement :
select
b.col1
from
test_sandy1 a,
test_sandy2 b
where
b.COL1 = a.COL1(+)
I get :
COL1
1
2
4
I want to build a materialized view to generate the same values but it has to be fast refresh. But since I am using outer join I am unable to create a fast refresh one.
Can someone suggest an alternate select to create fast refresh materialized view.
Thanks,
Sandipan

The select statement was not fitting my problem , so I'll change it as :
select
a.col1, nvl(b.col2, 'DEFAULT')
from
test_sandy1 a,
test_sandy2 b
where
b.COL1(+) = a.COL1
I get :
COL1     VAL
1     a
2     b
3     DEFAULT
How do I this ?

Using Oracle Text in Materialized View

Hi all,
I have a situation like that:
I create a MATERIALIZED VIEW select data from 2 normal view
Create Materialized VIEW SEARCH_DNICT
REFRESH COMPLETE NEXT SYSDATE + 1/4069
SELECT * FROM SEARCH_VIEW_CMS
UNION ALL
SELECT * FROM SEARCH_VIEW_TABLEAnd create Indexs on this view
CREATE INDEX SEARCH_DNICT_TIEUDE_IDX ON SEARCH_DNICT(TIEUDE) INDEXTYPE IS CTXSYS.CONTEXT;
CREATE INDEX SEARCH_DNICT_MOTA_IDX ON SEARCH_DNICT(MOTA) INDEXTYPE IS CTXSYS.CONTEXT;
CREATE INDEX SEARCH_DNICT_NOIDUNG_IDX ON SEARCH_DNICT(NOIDUNG) INDEXTYPE IS CTXSYS.CONTEXT;At last I seach on SEARCH_DNICT by command
SELECT * FROM SEARCH_DNICT WHERE CONTAINS(TIEUDE,'xem',1)>0But have no row return although the word 'xem' exist in the SEARCH_DNICT
Anybody can explain for me why?
Thanks a lot!
Edited by: AS84 on Aug 1, 2011 8:13 PM

Hi,
I think your problem is the complete refresh in combination with the creation of the indexes with synhing mode. By complete refresh of the MV, you drop the content of the table (underneath the MV) and rebuild this table. This will also drop the content of the indexes, but the indexes will not be rebuild (or synched) because you didn't mentioned it in the creation of the indexes.
So some options for synching:
1. You need to synchronize the indexes after refreshing the materialized view, manual or by setting some synch option in the index creation
2. Create the indexes on the underlying tables (but this one also needs to be in synch).
Herald ten Dam
http://htendam.wordpress.com

Issue with complete refresh on materialized view when using rownum

Hi all,
I had an issue with rownum when using complete refresh
I am using rownum when creating materialized view and it is generation correctly.But the issue was when i am refreshing the same ,rownum was not getting sorted in ascending order.
anyone had come across this scenario

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

Creating the materialized view using the database link

Hi Guys,
I am using the Oracle 11g release version.
Following is my question,
I had created the Database link to get the data from remote DB table.
Using that DB link, i can access the required table using SELECT statment.
When i tried to create the materialized using that DB link.
I am getting the error SQL Error: ORA-00942: table or view does not exist.
Can anyone please find the root cause and provide the solution for this?
TIA,
Dhivakar.

Hi Dhivakar,
try like this
CREATE DATABASE LINK test
CONNECT TO scott IDENTIFIED BY tiger
USING 'orcl';
Pls make sure the table name.which ur using to create the materialized view.Thanks
Venkadesh

Materialized View cannot use filter columns ORA-12033

Hello Forum members,
I am creating the following MV with Can you please advise me??
Thanks
SQL> create materialized view log on his_swi with rowid including new values;
Materialized view log created.
SQL>
SQL> CREATE MATERIALIZED VIEW His_Swi_mv
2 refresh fast with rowid
3 AS
4 select quarter,sum(sw_po),sum(sw_po_fre),
5 sum(sw_por_sta+sw_porunt_swi+sw_por_hb+sw_po_free) as proj from
6 history_switch group by quarter;
his_swi group by quarter
ERROR at line 6:
ORA-12033: cannot use filter columns from materialized view log on
"EM"."HIS_SWI"

Hello Forum members,
Please ignore the above post.
got solution from : http://www.jusungyang.com/DWfolder/MaterializedViews/MVlogFilterColumns.txt
Thanks

Want to see real time materialized view example

Hi all
i m d beginner with the pl/sql and want to know some real time scenario of materialized view ..i go through some examples on Database journal...but still oif u can help me for that it been great for me
thanks
rommy

and want to know some real time scenario of materialized view What do you mean by "real time scenario"?
What are you looking for that you didn't find in the examples?

Regd FAST refresh option in a Materialized view

Hi All,
I am using a pipeline function in which I am creating a table of records and a few cursors to fetch data from various tables.
Now this PL/SQL table is being used to construct a Materialized view.
Creation of Materialized view is happening fine but not with FAST refresh option. It gives an error " Cannot create a FAST refresh Materialized view from a complex query."
The query which I have used for the view creation is
CREATE MATERIALIZED VIEW CUSTOM.ABC
PCTFREE 0
BUILD IMMEDIATE
REFRESH FAST ON DEMAND
AS
SELECT A.Number,
A.Guarantors_Number,
A.Guarantors_Name,
A.Personal_Garantee_PCNT,
A.Company, LG.Source_System,
A.Type_of_Info,
A.File_Gen_Date,
A.Periodicity
FROM
TABLE(CUSTOM.CDM_LG_PACK_PF.CDM_LG_FUNC) A;
where CDM_LG_PACK_PF is the package and CDM_LG_FUNC is the pipeline function I have written to fetch all the records.
Please help me on how can I do a FAST refresh on this materialized view.
Thanks in advance,
Gaurav

Welcome to the forum!
FAST refresh doesn't mean that the operation is fast (time wise), it means it's an incremental refresh.
If you have a complex query, you can't use a FAST refresh - that's what the exception tells you.

BEST WAY TO REFRESH A MATERIALIZED VIEW

Hi, I have a Materialized View that was created after two Base Tables, Table A is a Dynamic Table, this means that it have Insert's, update's and delete's, and a Table B that is a Fixed Table, this means that this table do not change over time (it's a Date's Table). The size of the Table related to the Materialized View is to big (120 millions rows) so the refresh has to be very efficient in order to not affect the Data Base performance.
I was thinking on a Fast Refresh mode but It would not work because the log created on the B table is not usefull, the thing is that I created the two materialized view log's (Tables A and B) and when I execute the dbms_mview.refresh(list =>'MV', method => 'F')+ sentence I got the error
cannot use rowid column from materialized view log on "Table B" ... remember that this table don't change over time ...
I need to mantain the Materialized view up to date, but do not know how ... Please Help !!!!!

The Materialized View name is test_sitedate2
The Table B name is GCO01.FV_DATES .... is a Fixed Table ... do not change over time ...
The Code of the MV is
CREATE MATERIALIZED VIEW TEST_SITEDATE2
REFRESH FORCE ON DEMAND
AS
SELECT site_id, date_stamp
FROM gco01.fv_site, gco01.fv_dates
where fv_dates.date_stamp >= fv_site.start_date
and fv_dates.date_stamp >= to_date('01/03/2010', 'dd/mm/yyyy')
and fv_dates.date_stamp < to_date('01/04/2010', 'dd/mm/yyyy');
Each table gco01.fv_site and gco01.fv_dates have it's materiallized view log created
The error is ....
SQL> execute dbms_mview.refresh(list =>'test_sitedate2', method => 'F');
begin dbms_mview.refresh(list =>'test_sitedate2', method => 'F'); end;
ORA-12032: cannot use rowid column from materialized view log on "GCO01"."FV_DATES"
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2254
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2460
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2429
ORA-06512: at line 1
Thank's

Material View Refresh Slow under 10.2.0.4?

I have several material views that refreshed in minutes under 9.2.0.6, but are now taking hours under 10.2.0.4. I'm thinking it's in my initialization parameters. I remember the upgrade process making at least one of the HASH parameters obsolete.
Can anyone point me in a direction quickly?
A little more info... If I drop and recreate the materialized view from scratch it take just a few minutes to build.
Thank you.
Edited by: golflover1 on Jan 3, 2009 7:32 AM
Edited by: golflover1 on Jan 3, 2009 7:33 AM

What type of refresh you use to refresh the Materialized Views? (COMPLETE, FAST, FORCE)
Since you migrated to 10g there is a slight difference in how Oracle does the refresh.
Prior to 10g, when a materialized view is completely refreshed the base table was truncated and then populated with a data.
Starting from 10g, the default behavior is changed and truncate is replaced with delete which results in longer refresh times.
This is expected behavior, even though there was a bug associated with it Bug#4132133 which was closed as NOT A BUG.
However, if you still want to do a truncate instead of delete, you should set atomic_refresh=>FALSE in your DBMS_MVIEW.REFRESH command. This will do a truncate and refresh will complete faster.
You should be careful about this since there will be a time when the MV will contain no data.
golflover1 wrote:
A little more info... If I drop and recreate the materialized view from scratch it take just a few minutes to build.
This just confirms what I have written above. When you drop and recreate the MV, it doesn't do the DELETE so it completes faster.
I would say, go ahead and try to refresh the view with atomic_refresh=>FALSE and compare the execution times.
begin
dbms_mview.refresh(list=>'your mv name',method=>'C',atomic_refresh=>FALSE);
end;For more about DBMS_MVIEW.REFRESH check the reference docs on this link</link>.
Cheers,

Query rewrites with Nested materialized views with different aggregations

Platform used : Oracle 11g.
Here is a simple fact table (with measures m1,m2) and dimensions (a) Location (b) Calendar and (c) Product. The business problem is that aggregation operator for measure m1,m2 are different along location dimension and Calendar dimension. The intention is to preaggregate the measures for a product along the calendar dimension and Location dimension and store it as materialized views.
The direct option is to define a materialized view with Inline queries (Because of the different aggrergation operator, it is not possible to write a query without Inline query). http://download-uk.oracle.com/docs/cd/B28359_01/server.111/b28313/qradv.htm#BABEAJBF documents the limitations that it works only for 'Text match' and 'Equivalent queries' and that is too limiting.
So decided to have nested materialized view, with first view having just joins(my_dim_mvw_joins), the second view having aggregations along Calendar dimension (my_dim_mvw_calendar) and third view having aggregations along the Location dimension(my_dim_mvw_location). Obviously I do not want the query I fire to know about materialized views and I fire it against the fact table. I see that for the fired query (Which needs aggregations along both Calendar and Location), is rewritten with just second materialized view but not the third. (Had set QUERY_REWRITE_INTEGRITY as TRUSTED) .
Wanted to know whether there are limitations on Query Writes with nested materialized views? Thanks
(Have given a simple testable example below. Pls ignore the values given in 'CALENDAR_IDs', 'PRODUCT_IDs' etc as they are the same for all the queries)
-- Calendar hierarchy table
CREATE TABLE CALENDAR_HIERARCHY_TREE
(     "CALENDAR_ID" NUMBER(5,0) NOT NULL ENABLE,
"HIERARCHY1_ID" NUMBER(5,0),
"HIERARCHY2_ID" NUMBER(5,0),
"HIERARCHY3_ID" NUMBER(5,0),
"HIERARCHY4_ID" NUMBER(5,0),
CONSTRAINT "CALENDAR_HIERARCHY_TREE_PK" PRIMARY KEY ("CALENDAR_ID")
-- Location hierarchy table
CREATE TABLE LOCATION_HIERARCHY_TREE
(     "LOCATION_ID" NUMBER(3,0) NOT NULL ENABLE,
"HIERARCHY1_ID" NUMBER(3,0),
"HIERARCHY2_ID" NUMBER(3,0),
"HIERARCHY3_ID" NUMBER(3,0),
"HIERARCHY4_ID" NUMBER(3,0),
CONSTRAINT "LOCATION_HIERARCHY_TREE_PK" PRIMARY KEY ("LOCATION_ID")
-- Product hierarchy table
CREATE TABLE PRODUCT_HIERARCHY_TREE
(     "PRODUCT_ID" NUMBER(3,0) NOT NULL ENABLE,
     "HIERARCHY1_ID" NUMBER(3,0),
     "HIERARCHY2_ID" NUMBER(3,0),
     "HIERARCHY3_ID" NUMBER(3,0),
     "HIERARCHY4_ID" NUMBER(3,0),
     "HIERARCHY5_ID" NUMBER(3,0),
     "HIERARCHY6_ID" NUMBER(3,0),
     CONSTRAINT "PRODUCT_HIERARCHY_TREE_PK" PRIMARY KEY ("PRODUCT_ID")
-- Fact table
CREATE TABLE RETAILER_SALES_TBL
(     "PRODUCT_ID" NUMBER,
"PRODUCT_KEY" VARCHAR2(50 BYTE),
"PLAN_ID" NUMBER,
"PLAN_PERIOD_ID" NUMBER,
"PERIOD_ID" NUMBER(5,0),
"M1" NUMBER,
"M2" NUMBER,
"M3" NUMBER,
"M4" NUMBER,
"M5" NUMBER,
"M6" NUMBER,
"M7" NUMBER,
"M8" NUMBER,
"LOCATION_ID" NUMBER(3,0),
"M9" NUMBER,
CONSTRAINT "RETAILER_SALES_TBL_LOCATI_FK1" FOREIGN KEY ("LOCATION_ID")
REFERENCES LOCATION_HIERARCHY_TREE ("LOCATION_ID") ENABLE,
CONSTRAINT "RETAILER_SALES_TBL_PRODUC_FK1" FOREIGN KEY ("PRODUCT_ID")
REFERENCES PRODUCT_HIERARCHY_TREE ("PRODUCT_ID") ENABLE,
CONSTRAINT "RETAILER_SALES_TBL_CALEND_FK1" FOREIGN KEY ("PERIOD_ID")
REFERENCES CALENDAR_HIERARCHY_TREE ("CALENDAR_ID") ENABLE
-- Location dimension definition to promote query rewrite
create DIMENSION LOCATION_DIM
LEVEL CHAIN IS LOCATION_HIERARCHY_TREE.HIERARCHY1_ID
LEVEL CONSUMER_SEGMENT IS LOCATION_HIERARCHY_TREE.HIERARCHY3_ID
LEVEL STORE IS LOCATION_HIERARCHY_TREE.LOCATION_ID
LEVEL TRADING_AREA IS LOCATION_HIERARCHY_TREE.HIERARCHY2_ID
HIERARCHY PROD_ROLLUP (
STORE CHILD OF
CONSUMER_SEGMENT CHILD OF
TRADING_AREA CHILD OF
CHAIN
-- Calendar dimension definition
create DIMENSION CALENDAR_DIM
LEVEL MONTH IS CALENDAR_HIERARCHY_TREE.HIERARCHY3_ID
LEVEL QUARTER IS CALENDAR_HIERARCHY_TREE.HIERARCHY2_ID
LEVEL WEEK IS CALENDAR_HIERARCHY_TREE.CALENDAR_ID
LEVEL YEAR IS CALENDAR_HIERARCHY_TREE.HIERARCHY1_ID
HIERARCHY CALENDAR_ROLLUP (
WEEK CHILD OF
MONTH CHILD OF
QUARTER CHILD OF
YEAR
-- Materialized view with just joins needed for other views
CREATE MATERIALIZED VIEW my_dim_mvw_joins build immediate refresh complete enable query rewrite as
select product_id, lht.HIERARCHY1_ID, lht.HIERARCHY2_ID, lht.HIERARCHY3_ID, lht.location_id, cht.HIERARCHY1_ID year,
cht.HIERARCHY2_ID quarter, cht.HIERARCHY3_ID month, cht.calendar_id week, m1, m3, m7, m9
from retailer_sales_tbl RS, calendar_hierarchy_tree cht, location_hierarchy_tree lht
WHERE RS.period_id = cht.CALENDAR_ID
and RS.location_id = lht.location_id
and cht.CALENDAR_ID in (10,236,237,238,239,608,609,610,611,612,613,614,615,616,617,618,619,1426,1427,1428,1429,1430,1431,1432,1433,1434,1435,1436,1437,1438,1439,1440,1441,1442,1443,1444,1445,1446,1447,1448,1449,1450,1451,1452,1453,1454,1455,1456,1457,1458,1459,1460,1461,1462,1463,1464,1465,1466,1467,1468,1469,1470,1471,1472,1473,1474,1475,1476,1477)
AND product_id IN (5, 6, 7, 8, 11, 12, 13, 14, 17, 18, 19, 20)
AND lht.location_id IN (2, 3, 11, 12, 13, 14, 15, 4, 16, 17, 18, 19, 20)
-- Materialized view which aggregate along calendar dimension
CREATE MATERIALIZED VIEW my_dim_mvw_calendar build immediate refresh complete enable query rewrite as
select product_id, HIERARCHY1_ID , HIERARCHY2_ID , HIERARCHY3_ID ,location_id, year, quarter, month, week,
sum(m1) m1_total, sum(m3) m3_total, sum(m7) m7_total, sum(m9) m9_total,
GROUPING_ID(product_id, location_id, year, quarter, month, week) dim_mvw_gid
from my_dim_mvw_joins
GROUP BY product_id, HIERARCHY1_ID , HIERARCHY2_ID , HIERARCHY3_ID , location_id,
rollup (year, quarter, month, week);
-- Materialized view which aggregate along Location dimension
CREATE MATERIALIZED VIEW my_dim_mvw_location build immediate refresh complete enable query rewrite as
select product_id, year, quarter, month, week, HIERARCHY1_ID, HIERARCHY2_ID, HIERARCHY3_ID, location_id,
sum(m1_total) m1_total_1, sum(m3_total) m3_total_1, sum(m7_total) m7_total_1, sum(m9_total) m9_total_1,
GROUPING_ID(product_id, HIERARCHY1_ID, HIERARCHY2_ID, HIERARCHY3_ID, location_id, year, quarter, month, week) dim_mvw_gid
from my_dim_mvw_calendar
GROUP BY product_id, year, quarter, month, week,
rollup (HIERARCHY1_ID, HIERARCHY2_ID, HIERARCHY3_ID, location_id)
-- SQL Query Fired (for simplicity have used SUM as aggregation operator for both, but they will be different)
select product_id, year, HIERARCHY1_ID, HIERARCHY2_ID,
sum(m1_total) m1_total_1, sum(m3_total) m3_total_1, sum(m7_total) m7_total_1, sum(m9_total) m9_total_1
from
select product_id, HIERARCHY1_ID , HIERARCHY2_ID , year,
sum(m1) m1_total, sum(m3) m3_total, sum(m7) m7_total, sum(m9) m9_total
from
select product_id, lht.HIERARCHY1_ID , lht.HIERARCHY2_ID , lht.HIERARCHY3_ID ,lht.location_id, cht.HIERARCHY1_ID year, cht.HIERARCHY2_ID quarter, cht.HIERARCHY3_ID month, cht.calendar_id week,m1,m3,m7,m9
from
retailer_sales_tbl RS, calendar_hierarchy_tree cht, location_hierarchy_tree lht
WHERE RS.period_id = cht.CALENDAR_ID
and RS.location_id = lht.location_id
and cht.CALENDAR_ID in (10,236,237,238,239,608,609,610,611,612,613,614,615,616,617,618,619,1426,1427,1428,1429,1430,1431,1432,1433,1434,1435,1436,1437,1438,1439,1440,1441,1442,1443,1444,1445,1446,1447,1448,1449,1450,1451,1452,1453,1454,1455,1456,1457,1458,1459,1460,1461,1462,1463,1464,1465,1466,1467,1468,1469,1470,1471,1472,1473,1474,1475,1476,1477)
AND product_id IN (5, 6, 7, 8, 11, 12, 13, 14, 17, 18, 19, 20)
AND lht.location_id IN (2, 3, 11, 12, 13, 14, 15, 4, 16, 17, 18, 19, 20)
GROUP BY product_id, HIERARCHY1_ID , HIERARCHY2_ID , HIERARCHY3_ID , location_id, year
) sales_time
GROUP BY product_id, year,HIERARCHY1_ID, HIERARCHY2_ID
This Query rewrites only with my_dim_mvw_calendar. (as saw in Query Plan and EXPLAIN_MVIEW). But we would like it to use my_dim_mvw_location as that has aggregations for both dimensions.

blackhole001 wrote:
Hi all,
I'm trying to make my programmer's life easier by creating a database view for them to query the data, so they don't have to worry about joining tables. This sounds like a pretty horrible idea. I say this because you will eventually end up with programmers that know nothing about your data model and how to properly interact with it.
Additionally, what you will get is a developer that takes one of your views and see's that of the 20 columns in it, it has 4 that he needs. If all those 4 columns comes from a simple 2 table join, but the view has 8 tables, you're wasting a tonne of resources by using the view (and heaven forbid they have to join that view to another view to get 4 of the 20 columns from that other view as well).
Ideally you'd write stored routines that satisfy exactly what is required (if you are the database resource and these other programmers are java, .net, etc... based) and the front end developers would call those routines customized for an exact purpose.
Creating views is not bad, but it's by no means a proper solution to having developers not learn or understand SQL and/or the data model.

Materialized view logs in cloned database

Hi all!
We have materlialized views and materlialized view logs in two separate databases which are connected with a database link. The MV logs are in DB1_PROD, which is the database being cloned. The database link goes from DB2_PROD (where the MVs are located) to DB1_PROD:
DB2_PROD (materialized views) ----DB link---> DB1_PROD (materialized view logs)
When cloning DB1_PROD to DB3_DEV, the MV logs still have a reference to DB2_PROD. However, there is no connection between DB3_DEV and DB2_PROD.
In my opinion this is not harmful, but I would like to know if any of you can see any problems with this.
In summary;
DB1_PROD: Materialized view logs
DB3_DEV: Materialized view logs. Clone of DB1_PROD
DB2_PROD: Materialized views.
DB1_PROD and DB3_DEV:
select * from v$version;
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
DB2_PROD:
select * from v$version;
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE 11.2.0.3.0 Production
TNS for Linux: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - ProductionPlease let me know if you need further information.

Oracle automatically purges rows in the materialized view log when they are no longer needed. Because Oracle must wait for all dependent materialized views to refresh before purging rows from a materialized view log, unwanted situations can occur that cause a materialized view log to grow indefinitely when multiple materialized views are based on the same master table or master materialized view.
For example, such situations can occur when more than one materialized view is based on a master table or master materialized view and one of the following conditions is true:
Materialized view is not configured for automatic refreshes and has not been manually refreshed for a long time. OR
Materialized view has an infrequent refresh interval, such as every year, etc
You can also refresh the materialized views associated with the log so that Oracle can purge rows from the materialized view log.
If a materialized view log needs to be purged manually for some reason a procedure called DBMS_MVEW.PURGE_LOG can be used.
Edited by: user130038 on Sep 30, 2011 6:49 AM

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.

Materialized view logs issue

We are having issues with the size of materialized view logs in one od the database. The size of the log table is around 32G. Will appreciate if somebody will help in explaining why it is having such a huge size and is not getting purged.
At the same time the master table is having comparatively smaller size of 18G(did not check table fragmentation).
Also, please help me in understanding what is required to be done for fixing this issue.
SQL> select LOG_OWNER,MASTER,LOG_TABLE,LOG_TRIGGER,PRIMARY_KEY from dba_mview_logs where log_owner='MARTDATA' and MASTER='POLICY_CONFIGURATION';
LOG_OWNER MASTER LOG_TABLE LOG_TRIGGER PRI
MARTDATA POLICY_CONFIGURATION MLOG$_POLICY_CONFIGURATION NO
SQL> select owner, segment_name, sum(bytes)/1024/1024 "SIZE in MB" from dba_segments where segment_name='POLICY_CONFIGURATION' and owner ='MARTDATA' group by owner, segment_name;
OWNER SEGMENT_NAME SIZE in MB
MARTDATA POLICY_CONFIGURATION 18458
SQL> select owner, segment_name, sum(bytes)/1024/1024 "SIZE in MB" from dba_segments where segment_name='MLOG$_POLICY_CONFIGURATION' and owner ='MARTDATA' group by owner, segment_name;
OWNER SEGMENT_NAME SIZE in MB
MARTDATA MLOG$_POLICY_CONFIGURATION 32298
Thanks

Oracle automatically purges rows in the materialized view log when they are no longer needed. Because Oracle must wait for all dependent materialized views to refresh before purging rows from a materialized view log, unwanted situations can occur that cause a materialized view log to grow indefinitely when multiple materialized views are based on the same master table or master materialized view.
For example, such situations can occur when more than one materialized view is based on a master table or master materialized view and one of the following conditions is true:
Materialized view is not configured for automatic refreshes and has not been manually refreshed for a long time. OR
Materialized view has an infrequent refresh interval, such as every year, etc
You can also refresh the materialized views associated with the log so that Oracle can purge rows from the materialized view log.
If a materialized view log needs to be purged manually for some reason a procedure called DBMS_MVEW.PURGE_LOG can be used.
Edited by: user130038 on Sep 30, 2011 6:49 AM

Using time dimension in materialized view

Similar Messages

Maybe you are looking for