Query Rewrite to Utilize Materialized Views on a Remote Database

We have our materilized views stored at a remote database. Is there a way to utilize query rewrite to rewrite the queries issued on the local database such that queries will refer the materialized views at a remote db?
From the documentation, I already know that the base tables for MVs and MVs should eside in the same instance or the query should be submitted on the instance where MVs reside if base tables are residing in a different remote DB to benefit from query rewrite.
My aim is to utilize query rewrite to reduce the workload on a primary database by passing queries that can be rewritten to use MVs on a remote DB.
Thanks for the guidance,

My aim is to utilize query rewrite to reduce the workload on a primary database by passing queries that can be rewritten to use MVs on a remote DB. If you know that MVs are not stale or acceptable of staled data and don't see network bandwidth problems (small set of result), You would try accessing MV tables directly on remote db using dblinks.

Similar Messages

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.

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 to create materialized view log on remote database

How do you create materialized view logs on a remote database.
I tried
create materialized view log on global_express_views.vccs438_project_work_request@h92edwp with sequence, rowid ( columns...)
ERROR at line 1:
ora-00949 illegal reference to remote database

Hi,
I am not getting the error exactly. But have some suggestion:
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.
Hope, this may help you?
Thanx.. Ratan

Query Rewrite (QSM-01263) and Views in Execution Plan

Hello!
I created a query rewrite enabled materialized view from a query, which contains only tables (no views). Query rewrite didn't work, so i checked the query with dbms_mview.explan_rewrite, which told my that my query contains references to views or dictionary tables. I checked my query again, but there are only tables, no views, no dictionary tables.
When I look in the execution plan of my query I see that the query optimizer generates views, I guess from my subquery (?). "A view definition was processed, either from a stored view...or as defined by steps...".
I suppose that's the reason why my query rewrite doesn't work. All my other mat views are working fine, so the usual parameters (query_rewrite_enabled, integrity, etc.) are set correctly.
Do you have any ideas how to get my query rewrite enabled work?
Thanks!

Modifying the query (potentially with hints) so that Oracle doesn't do the view transformation would be one option.

Oracle - Query taking too long (Materialized view)

Hi,
I am extracting billing informaiton and storing in 3 different tables... in order to show total billing (80 to 90 columns, 1 million rows per month), I've used a materialized view... I do not have indexes on 3 billing tables - do have 3 indexes on Materialized view...
at the moment it's taking too long to query the data (running a query via toad fails and shows "Out of Memory" error message; runing a query via APEX though is providing results but taking way too long)...
Please advice how to make the query efficient...

tparvaiz,
Is it possible when building your materialized view to summarize and consolidate the data?
Out of a million rows, what would your typical user do with that amount data if they could retrieve it readily? The answer to this question may indicate if and how to summarize the data within the materialized view.
Jeff
Edited by: jwellsnh on Mar 25, 2010 7:02 AM

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

Create Materialized View based on another database table using db link?

SQL> SELECT sysdate
2 FROM dual@CBRLINK ;
SYSDATE
21-NOV-12
SQL> CREATE MATERIALIZED VIEW USERCBR.V_T24_COUNTRY1
2 REFRESH COMPLETE
3 START WITH SYSDATE NEXT SYSDATE + (5/24)
4 AS
5 SELECT sysdate
6 FROM dual@CBRLINK ;
CREATE MATERIALIZED VIEW USERCBR.V_T24_COUNTRY1
ERROR at line 1:
ORA-04052: error occurred when looking up remote object SYS.DUAL@CBRLINK
ORA-00600: internal error code, arguments: [ORA-00600: internal error code,
arguments: [qksfroFXTStatsLoc() - unknown KQFOPT type!], [0], [], [], [], [],
ORA-02063: preceding line from CBRLINK

It works for me:orcl>
orcl> CREATE MATERIALIZED VIEW scott.V_T24_COUNTRY1
2 REFRESH COMPLETE
3 START WITH SYSDATE NEXT SYSDATE + (5/24)
4 AS
5 SELECT sysdate
6 FROM dual@l1 ;
Materialized view created.
orcl> select * from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
PL/SQL Release 11.2.0.3.0 - Production
CORE 11.2.0.3.0 Production
TNS for 32-bit Windows: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production
orcl>so there is no problem with the code. HTH.

View objects in remote database

Hi all,
Could anyone tell me how to view all tables in a remote database? I've created a db link to that remote database already. I'm trying to find one particular table.
Thanks in advance
stoneiidol

Oh right, thanks.
What do you suggest i should do if i want to find a table in the remote database and i've forgotten that table's name. Can i issue an sql statement to display all the tables in the remote database??
cheers
stoneiidol

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?

Oracle Query Rewrite Alias Problem

Hi,
The problem desribed below is regarding the use of oracle aggregate awareness through the use of query rewrite.
2 materialized views exist (one agg per day, one agg per month) and 1 dimension exists for time (date - month - quarter - year)
Query rewrite seems to be working fine for a query as such (alias sql = alias mv):
select DDFPC.MONTH_NO
from BIDATA_MAIN.DF_REPOSITORY_SUBSET DF2, BIDATA_MAIN.DD_TIME DDFPC
where DF2.FINANCIAL_PROCCESSING_DATE_ID = DDFPC.DATE_ID and DF2.ROUTING_CODE_ISS IN ('FPC','NCC')
group by DDFPC.MONTH_NO
However, considering our reporting tool generates aliases on the fly, we could get the following query (alias sql <> alias mv):
select T2.MONTH_NO
from BIDATA_MAIN.DF_REPOSITORY_SUBSET DF2, BIDATA_MAIN.DD_TIME T2
where DF2.FINANCIAL_PROCCESSING_DATE_ID = T2.DATE_ID and DF2.ROUTING_CODE_ISS IN ('FPC','NCC')
group by T2.MONTH_NO
--> for the second query, query rewrite refuses to correctly use the dimension – it’ll rewrite to the DD (daily) aggregate, but not to the MM (monthly) aggregate
Investigation gives: QSM-01072: materialized view, DA_REPOSITORY_MERCHANT_MM, and query have different joins between tables, DF_REPOSITORY_SUBSET and DD_TIME
So*: How can query rewrite be forced to take place with different aliases between query & materialized view – taken into account a dimension is used for aggregation-awareness?
This seems to indicate it should work...

You are missing a join on the file_id column
i.e.
select sum(f.BLOCKS), sum(d.BLOCKS) from dba_free_space f ,dba_data_files d where f.TABLESPACE_NAME=d.TABLESPACE_NAME and f.TABLESPACE_NAME like SUBSTR('KU_TSD_1',0,10)
and f.file_id = d.file_id
This might have been easier to detect if you had removed the sum aggregation and looked at the data coming back from the raw query.

Oracle Materialized view tables not getting refreshed automatically.

At Destination:--
CREATE MATERIALIZED VIEW PROG_MEDIA
TABLESPACE ONA_TS1
BUILD IMMEDIATE
REFRESH FAST with rowid
START WITH SYSDATE
NEXT SYSDATE+1/96
AS (select /*+ PARALLEL(a,6) */ * from PROG_MEDIA@onair a);
exec dbms_mview.refresh('PROG_MEDIA','C');
At Source:--
CREATE MATERIALIZED VIEW LOG ON ONAIR.PROG_MEDIA
TABLESPACE MVLOG
WITH ROWID;
Fired manually:--
13:00:43 SQL> exec dbms_mview.refresh('PROG_MEDIA','C');
PL/SQL procedure successfully completed.
At source:--
13:18:35 SQL> select PROG_MEDIA_ID,PROG_MEDIA_NAME from PROG_MEDIA where PROG_MEDIA_ID='102226';
PROG_MEDIA_ID
PROG_MEDIA_NAME
102226
test
At Destination:--
14:03:28 SQL> select PROG_MEDIA_ID,PROG_MEDIA_NAME from PROG_MEDIA where PROG_MEDIA_ID='102226';
PROG_MEDIA_ID PROG_MEDIA_NAME
102226 UTSAV-5-162077
JOB LOG_USER THIS_DATE LAST_DATE_TIME NEXT_DATE_TIME INTERVAL FAILURES WHAT
242 ONAIR 17-05-11 14:17:24 SYSDATE+1/96 7 dbms_refresh.refresh('"ONAIR"."PROG_MEDI
A"');
242 ONAIR 17-05-11 14:32:25 SYSDATE+1/96 8 dbms_refresh.refresh('"ONAIR"."PROG_MEDI
A"');
1> I have scheduled this refresh job for every 15mins, but its not getting executed. Also my job_queue_process is '20'. Whenever i execute it manually it get's refresh.
2> I can schedule a cron for the same for every 15mins but i really dont want to do it.
Kindly help me out.

Hi,
I have created MV_CAPABILITIES_TABLE & executed below commands:--
17:56:54 SQL> EXECUTE DBMS_MVIEW.EXPLAIN_MVIEW ('"ONAIR"."PROG_MEDIA"');
PL/SQL procedure successfully completed.
17:57:26 SQL> SELECT capability_name, possible, SUBSTR(related_text,1,8)
17:57:27 2 AS rel_text, SUBSTR(msgtxt,1,60) AS msgtxt
17:57:27 3 FROM MV_CAPABILITIES_TABLE
17:57:27 4 ORDER BY seq;
CAPABILITY_NAME P REL_TEXT MSGTXT
PCT N
PCT N
REFRESH_COMPLETE Y
REFRESH_COMPLETE Y
REFRESH_FAST Y
REFRESH_FAST Y
REWRITE N
REWRITE N
PCT_TABLE N PROG_MED relation is not a partitioned table
PCT_TABLE N PROG_MED relation is not a partitioned table
REFRESH_FAST_AFTER_INSERT Y
REFRESH_FAST_AFTER_INSERT Y
REFRESH_FAST_AFTER_ONETAB_DML Y
REFRESH_FAST_AFTER_ONETAB_DML Y
REFRESH_FAST_AFTER_ANY_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
REFRESH_FAST_PCT N PCT is not possible on any of the detail tables in the mater
REWRITE_FULL_TEXT_MATCH N PROG_MED mv references a remote table or view in the FROM list
REWRITE_FULL_TEXT_MATCH N PROG_MED mv references a remote table or view in the FROM list
REWRITE_FULL_TEXT_MATCH N query rewrite is disabled on the materialized view
REWRITE_FULL_TEXT_MATCH N query rewrite is disabled on the materialized view
REWRITE_PARTIAL_TEXT_MATCH N materialized view cannot support any type of query rewrite
REWRITE_PARTIAL_TEXT_MATCH N materialized view cannot support any type of query rewrite
REWRITE_PARTIAL_TEXT_MATCH N query rewrite is disabled on the materialized view
REWRITE_PARTIAL_TEXT_MATCH N query rewrite is disabled on the materialized view
REWRITE_GENERAL N materialized view cannot support any type of query rewrite
REWRITE_GENERAL N materialized view cannot support any type of query rewrite
REWRITE_GENERAL N query rewrite is disabled on the materialized view
REWRITE_GENERAL N query rewrite is disabled on the materialized view
REWRITE_PCT N general rewrite is not possible or PCT is not possible on an
REWRITE_PCT N general rewrite is not possible or PCT is not possible on an
PCT_TABLE_REWRITE N PROG_MED relation is not a partitioned table
PCT_TABLE_REWRITE N PROG_MED relation is not a partitioned table
34 rows selected.
Elapsed: 00:00:00.09
What to be done next?
Also i fired the job manually by:--
17:38:02 SQL> set serveroutput on
17:39:45 SQL> EXEC DBMS_JOB.RUN(242);
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.48

! Materialized View log VS Trigger to trace table changes !

Hi All
I have to trace changes on couple tables and only those changes then send to other system.
What do you think is better solution to create a Status table and update it via trigger.
I saw that MV log can be used for such purpose, but I am not able to create a MV logging on more than one table.
Or is there any other more effective way to trace changes on table?
Thanks a lot
Martin

It sounds like you should be looking at something like Change Data Capture (CDC). You could also create materialized view logs on each table where you wanted to track changes, create appropriate materialized views on the remote database, and consume the data there. It really depends on what exactly you want to do with the changes you're tracking.
Justin

To increase performance of refresh of Materialized View

Dear Members,
I have a set of 231 Materialized Views on a remote database from which I am refreshing data through materialized views. I.e. I have 231 materialized views which are directly copying data from the source views into our internal databases. (basically select column1, column2.... from viewname@dblinkname) There are no where clauses in any of the tables. The refreshes take around 4 hours to run. They either get fast refreshed or complete refresh. It's an on-demand type of refresh.
Could anyone give me suggestions of improving the performance of these refreshes? I would appreciate some guidance in this case.
Kind Regards,
Suhas

Hi Suhas,
If you are asking about Coherence database integration, you could start here ...
http://coherence.oracle.com/display/COH34UG/Read-Through,+Write-Through,+Write-Behind+and+Refresh-Ahead+Caching
Thanks

Spatial vs. materialized views/query rewrite

Dear all,
we are trying to use Spatial (Locator) functionality together with performance optimization using materialized views and query rewrite, and it does not seem to work. Does anybody has experience with this?
The problem in more detail:
* There is a spatial attribut (vom Typ GEOMETRY) in our table;
* we define a materialized view on that table;
* we run a query that could be better answered using the materialized view with query rewrite;
*the optimizer does not choose the plan using the materialized view, query rewrite does not take place;
This happenes, even if neither the materialized view, nor the query contains the spatial attribut.
The explanation given by the procedure DBMS_MVIEW.Explain_Rewrite is:
"QSM-01064 query has a fixed table or view Cause: Query
rewrite is not allowed if query references any fixed tables or views"
We are using Oracle 9R2, Enterprise Edition, with locator. Nevertheless, it would also be interesting, if there is any improvement in 10g?
A more complicated task, using materialized views to optimize spatial operations (e.g., sdo_relate) would also be very interesting, as spatial joins are very expensive operations.
Thanks in advance for any comments, ideas!
Cheers,
Gergely Lukacs

Hi Dan,
thanks for your rapid response!
A simple example is:
alter session set query_rewrite_integrity=trusted;
alter session set query_rewrite_enabled=true;
set serveroutput on;
/* Creating testtable */
CREATE TABLE TESTTABLE (
KEY1 NUMBER (4) NOT NULL,
KEY2 NUMBER (8) NOT NULL,
KEY3 NUMBER (14) NOT NULL,
NAME VARCHAR2 (255),
X NUMBER (9,2),
Y NUMBER (9,2),
ATTR1 VARCHAR2 (2),
ATTR2 VARCHAR2 (30),
ATTR3 VARCHAR2 (80),
ATTR4 NUMBER (7),
ATTR5 NUMBER (4),
ATTR6 NUMBER (5),
ATTR7 VARCHAR2 (40),
ATTR8 VARCHAR2 (40),
CONSTRAINT TESTTABLE_PK
PRIMARY KEY ( KEY1, KEY2, KEY3 ));
/* Creating materialized view */
CREATE MATERIALIZED VIEW TESTTABLE_MV
REFRESH COMPLETE
ENABLE QUERY REWRITE
AS SELECT DISTINCT ATTR7, ATTR8
FROM TESTTABLE;
/* Creating statistics, just to make sure */
execute dbms_stats.gather_table_stats(ownname=> 'TESTSCHEMA', tabname=> 'TESTTABLE', cascade=>TRUE);
execute dbms_stats.gather_table_stats(ownname=> 'TESTSCHEMA', tabname=> 'TESTTABLE_MV', cascade=>TRUE);
/* Explain rewrite procedure */
DECLARE
Rewrite_Array SYS.RewriteArrayType := SYS.RewriteArrayType();
querytxt VARCHAR2(1500) :=
'SELECT COUNT(*) FROM (
SELECT DISTINCT
ATTR8 FROM
TESTTABLE
i NUMBER;
BEGIN
DBMS_MVIEW.Explain_Rewrite(querytxt, 'TESTTABLE_MV', Rewrite_Array);
FOR i IN 1..Rewrite_Array.count
LOOP
DBMS_OUTPUT.PUT_LINE(Rewrite_Array(i).message);
END LOOP;
END;
The message you get is:
QSM-01009 materialized view, string, matched query text
Cause: The query was rewritten using a materialized view, because query text matched the materialized view text.
Action: No action required.
i.e. query rewrite works!
/* Adding geometry column to the testtable -- not to the materialized view, and not to the query! */
ALTER TABLE TESTTABLE
ADD GEOMETRYATTR mdsys.sdo_geometry;
/* Explain rewrite procedure */
DECLARE
Rewrite_Array SYS.RewriteArrayType := SYS.RewriteArrayType();
querytxt VARCHAR2(1500) :=
'SELECT COUNT(*) FROM (
SELECT DISTINCT
ATTR8 FROM
TESTTABLE
i NUMBER;
BEGIN
DBMS_MVIEW.Explain_Rewrite(querytxt, 'TESTTABLE_MV', Rewrite_Array);
FOR i IN 1..Rewrite_Array.count
LOOP
DBMS_OUTPUT.PUT_LINE(Rewrite_Array(i).message);
END LOOP;
END;
The messages you get are:
QSM-01064 query has a fixed table or view
Cause: Query rewrite is not allowed if query references any fixed tables or views.
Action: No action required.
QSM-01019 no suitable materialized view found to rewrite this query
Cause: There doesn't exist any materialized view that can be used to rewrite this query.
Action: Consider creating a new materialized view.
i.e. query rewrite does not work!
If this works, the next issue is to use materialized views for optimizing spatial operations, e.g., a spatial join. I can supply you with an example, if necessary (only makes sense, I think, after the first problem is solved).
Thanks in advance for any ideas, comments!
Cheers,
Gergely

Query Rewrite to Utilize Materialized Views on a Remote Database

Similar Messages

Maybe you are looking for