A story of Oracle Support frustration
I'm not looking for a technical sol'n to a problem here, just relating a tale of frustration. Here we go ...
I created a materialized view as an aggregation of a dimension and fact table joined together. Pretty standard procedure for data warehouse performance enhacement.
During testing I saw that Query Rewrite (QR) wasn't available, and DBMS_MVIEW.EXPLAIN_MVIEW() told me that general query rewrite wasn't allowed because the MV query had a top-level WITH clause. Which it doesn't -- that would just be silly.
I raised a TAR with Support, gave them the DDL for the objects, and the games began
Me: There is no ORDER BY in the MV definition, so the response makes no sense. What's this got to do with "WITH" clauses?
query rewrite will not be used if any changes after the FROM clause has occurred that no longer matches the Materialized View (MVIEW) definition.
Since ORDER BY clause is added to the query the partial query match rule will
Me: As the DDL shows, I am not trying to create a ROWID MV. If I were then the MV would not have successfully created, which it did.
ROWID materialized views are provided for backwards compatibility only, and cannotbe used with aggregation queries
Me: Well, I just created one without any problem, and the documentation gives examples of doing exactly that.
You can't have an MV that is based on rowid MV log for one table and PK log for another.
Me: The documentation shows this in numerous places -- it makes no logical sense that the base table has to have a PK.
One of the base tables doesn't have a PK -- this isn't a supported configuration
Me: As the DDL shows, I'm not trying to create an updateable MV. If I were then the MV would not have successfully created, which it did.
Documentation says that an MV is not updateable if the base table has no PK
Me: As the DDL shows, I am not trying to create an MV with a subquery. If I were then the MV would not have successfully created, which it did.
A materialized view base table must have a PK in order to use subqueries.
Me: It is not my aim to create a fast refreshable MV -- I am creating a Partition Change Tracking (PCT) fast-refreshable MV. However, as the DDL shows this is a PK-based MV anyway,and fast refresh also works.
An MV that is going to be fast refreshed has to have primary key. Primary is set on MV by default.
Me: The fast refresh process doesn't access the base table -- it only accesses the MV log.
It can't work because the table has to have a PK in order for the MV log to find the relevant data that needs to be propagated to the MV
Me: I upload files that show successful fast refresh for ...
No, it has to access the base table
i) a base table with no PK
ii) a base table with no PK joined to a table with a PK
Furthermore I upload an example of a fast refresh of a MV where the tablespace containing the base table is offline, yet the refresh was successful. Therefore fast refresh does not access the base table.
I also point out that ...
i) DBMS_MVIEW.EXPLAIN_MVIEW() says that fast refresh is available
ii) I don't carewhether it'savailable or not, because i am never going to use it -- i use PCT refresh which doesn't work through MV logs.
Me: OK, at this point i briefly lost my cool. However after recovering, I pointed out that the "Sales History" sample schema in Oracle 9i documentation does not have a PK, is also commented as ...
The fact table in your examples does not have a primary key -- Oracle Support does not condone the use of non-PK'd tables, and we cannot support this scenario
... and is used for all the MV examples, including fast refresh and PCT fast refresh, eg. here
COMMENT ON TABLE sales
IS 'facts table, without a primary key; all rows are uniquely identified by the
combination of all foreign keys';
So, there we are then. I shall provide updates as they become available.
Last edited by slimdave; 01-15-2004 at 01:55 PM.
Click Here to Expand Forum to Full Width