I have 2 or more base tables representing subtype entities. The records in these are mutually exclusive - no intersection. I want to create a materialized view which represents the supertype entity. Can this be done in Netezza using a UNION ALL in the create of the view?
Can this be done in Netezza using a UNION ALL in the create of the view?
Yes (via a "CREATE VIEW")
I want to create a materialized view
In Netezza, a "CREATE MATERIALIZED VIEW" is for a single table.
Related
A is a collapsingMergeTree engine table
CREATE VIEW A AS SELECT * FROM A final;
CREATE MATERIALIZED VIEW a_mview1 TO B
AS select id,
name
from A;
This is not working it seems we can't make mview on view..but why?
Normal View doesn't store any data (see doc) so that it is wrong to use it as a source of data for Materialized View.
It needs to create Materialized View based on the origin table:
CREATE TABLE A (
..
) ENGINE = CollapsingMergeTree
.. ;
CREATE MATERIALIZED VIEW a_mview1 TO B
AS
SELECT ..
FROM A
.. ;
Look at the article ClickHouse Materialized Views Illuminated for details.
CREATE VIEW A AS SELECT * FROM A final;
It's impossible. Because MV never reads a source table. MV gets inserted blocks from INSERT command.
I have created a materialized view with Refresh complete like that and it works well:
CREATE MATERIALIZED VIEW VM4
Build immediate
refresh complete on commit
AS
select C.codecomp,
count(c.numpolice) as NbContrat,
SUM(c.montant) as MontantGlobal
from contrat C
group by c.codecomp;
Now I would like to create a similar view but with Refresh Fast but it dosn't work and it shows me this error:
error
Knowing that I have already created the LOG of the Contrat table ilke that:
CREATE MATERIALIZED VIEW LOG ON contrat with rowid ;
Check documentation:
General Restrictions on Fast Refresh
The defining query of the materialized view is restricted as follows:
The materialized view must not contain references to non-repeating expressions like SYSDATE and ROWNUM.
The materialized view must not contain references to RAW or LONG RAW data types.
It cannot contain a SELECT list subquery.
It cannot contain analytic functions (for example, RANK) in the SELECT clause.
It cannot reference a table on which an XMLIndex index is defined.
It cannot contain a MODEL clause.
It cannot contain a HAVING clause with a subquery.
It cannot contain nested queries that have ANY, ALL, or NOT EXISTS.
It cannot contain a [START WITH …] CONNECT BY clause.
It cannot contain multiple detail tables at different sites.
ON COMMIT materialized views cannot have remote detail tables.
Nested materialized views must have a join or aggregate.
Materialized join views and materialized aggregate views with a GROUP BY clause cannot select from an index-organized table.
Restrictions on Fast Refresh on Materialized Views with Aggregates
Defining queries for materialized views with aggregates or joins have
the following restrictions on fast refresh:
All restrictions from "General Restrictions on Fast Refresh".
Fast refresh is supported for both ON COMMIT and ON DEMAND
materialized views, however the following restrictions apply:
All tables in the materialized view must have materialized view logs, and the materialized view logs must:
Contain all columns from the table referenced in the materialized view.
Specify with ROWID and INCLUDING NEW VALUES.
Specify the SEQUENCE clause if the table is expected to have a mix of inserts/direct-loads, deletes, and updates.
Only SUM, COUNT, AVG, STDDEV, VARIANCE, MIN and MAX are supported for fast refresh.
COUNT(*) must be specified.
Aggregate functions must occur only as the outermost part of the expression. That is, aggregates such as AVG(AVG(x)) or AVG(x)+ AVG(x)
are not allowed.
For each aggregate such as AVG(expr), the corresponding COUNT(expr) must be present. Oracle recommends that SUM(expr) be
specified. See Requirements for Using Materialized Views with
Aggregates for further details.
If VARIANCE(expr) or STDDEV(expr) is specified, COUNT(expr) and SUM(expr) must be specified. Oracle recommends that SUM(expr *expr) be
specified. See Requirements for Using Materialized Views with
Aggregates for further details.
The SELECT column in the defining query cannot be a complex expression with columns from multiple base tables. A possible
workaround to this is to use a nested materialized view.
The SELECT list must contain all GROUP BY columns.
The materialized view is not based on one or more remote tables.
If you use a CHAR data type in the filter columns of a materialized view log, the character sets of the master site and the
materialized view must be the same.
If the materialized view has one of the following, then fast refresh is supported only on conventional DML inserts and direct
loads.
Materialized views with MIN or MAX aggregates
Materialized views which have SUM(expr) but no COUNT(expr)
Materialized views without COUNT(*)
Such a materialized view is called an insert-only materialized view.
A materialized view with MAX or MIN is fast refreshable after delete or mixed DML statements if it does not have a WHERE clause.
The max/min fast refresh after delete or mixed DML does not have the same behavior as the insert-only case. It deletes and recomputes
the max/min values for the affected groups. You need to be aware of
its performance impact.
Materialized views with named views or subqueries in the FROM clause can be fast refreshed provided the views can be completely
merged. For information on which views will merge, see Oracle Database
SQL Tuning Guide.
If there are no outer joins, you may have arbitrary selections and joins in the WHERE clause.
Materialized aggregate views with outer joins are fast refreshable after conventional DML and direct loads, provided only the
outer table has been modified. Also, unique constraints must exist on
the join columns of the inner join table. If there are outer joins,
all the joins must be connected by ANDs and must use the equality (=)
operator.
For materialized views with CUBE, ROLLUP, grouping sets, or concatenation of them, the following restrictions apply:
The SELECT list should contain grouping distinguisher that can either be a GROUPING_ID function on all GROUP BY expressions or
GROUPING functions one for each GROUP BY expression. For example, if
the GROUP BY clause of the materialized view is "GROUP BY CUBE(a, b)",
then the SELECT list should contain either "GROUPING_ID(a, b)" or
"GROUPING(a) AND GROUPING(b)" for the materialized view to be fast
refreshable.
GROUP BY should not result in any duplicate groupings. For example, "GROUP BY a, ROLLUP(a, b)" is not fast refreshable because it
results in duplicate groupings "(a), (a, b), AND (a)".
I think you missed
COUNT(*) must be specified.
For each aggregate such as AVG(expr), the corresponding COUNT(expr) must be present.
Specify with ROWID and INCLUDING NEW VALUES.
Specify the SEQUENCE clause if the table is expected to have a mix of inserts/direct-loads, deletes, and updates.
I have problem with Oracle DB - domain index returns zero rows after search by CONTAINS() on materialized view. I see that materialized view is filled with data and I also used procedure ctx_ddl.sync_index() for domain index synchronization.
What works good:
CREATE TABLE
INSERT DATA
CREATE DOMAIN INDEX
SYNC DOMAIN INDEX
FIND ROWS BY CONTAINS - RETURN ROWS
What is not working:
CREATE TABLE
INSERT DATA
CREATE MATERIALIZED VIEW
REFRESH MATERIALIZED VIEW
CREATE DOMAIN INDEX IN MATERIALIZED VIEW
SYNC DOMAIN INDEX IN MATERIALIZED VIEW
FIND ROWS BY CONTAINS IN MATERIALIZED VIEW - RETURN ZERO ROWS (LIKE %TERM% WORKS)
Why everything works fine without materialized view?
Here is my queries (you can copy-paste and try it in your oracle db):
--create table
CREATE TABLE "PCOUNTERPARTY" ( "ID_COUNTERPARTY" NUMBER(10,0), "TXT_SEARCH_FULL_NAME" NVARCHAR2(260), CONSTRAINT "PCOUNTERPARTY_PK" PRIMARY KEY ("ID_COUNTERPARTY"));
--INSERT DATA.
Insert into PCOUNTERPARTY (ID_COUNTERPARTY,TXT_SEARCH_FULL_NAME) values (1184,'MARTINKO3');
--create materialized view
CREATE MATERIALIZED VIEW m_pcounterparty
AS
SELECT c.ID_COUNTERPARTY, CAST( c.TXT_SEARCH_FULL_NAME AS varchar2(260 CHAR) ) as txt_search_full_name_all
FROM PCOUNTERPARTY c;
--create domain index
create index IDXM_1_pcounterparty on m_pcounterparty(TXT_SEARCH_FULL_NAME_ALL) indextype is ctxsys.context PARAMETERS ('SYNC ( ON COMMIT)');
--refresh of materialized view
EXECUTE DBMS_MVIEW.REFRESH('M_PCOUNTERPARTY');
--refresh of index
exec ctx_ddl.sync_index('IDXM_1_pcounterparty');
--search in materialized view
SELECT
TXT_SEARCH_FULL_NAME_ALL
from
M_PCOUNTERPARTY c
WHERE
CONTAINS(c.TXT_SEARCH_FULL_NAME_ALL, 'martin', 1) > 0; --return ZERO and THIS IS PROBLEM
--c.TXT_SEARCH_FULL_NAME_ALL LIKE '%MARTIN%'; -- return rows but we want search thru CONTAINS
Oracle Text indexes normally search words, not strings.
A wildcard is not necessary to search for "martin" in "Martin Luther King Jr." But a wildcard is necessary to search for "martin" in "MARTINKO3".
Change the CONTAINS predicate to this:
CONTAINS(c.TXT_SEARCH_FULL_NAME_ALL, 'martin%', 1) > 0;
I ran tests on Oracle 12.2 and could not find any differences in behavior between using a table or a materialized view. Perhaps there was a test mistake or a very specific bug that caused the text indexes to act differently on your system.
I have two tables, TABLE_1 and TABLE_2. Then we have a synonym called TABLE that points to either TABLE_1 or TABLE_2. When TABLE_1 is active, an ETL populates TABLE_2 and when the run is complete, it switches the TABLE synonym to TABLE_2 to make it the active table. Then I have a materialized view that does something like this as the SQL: select * from TABLE. What I am seeing happen is that after the materialize view runs the first time, it caches the actual table the synonym is pointing too. So when the ETL runs and flips the synonym to point at TABLE_2, when a complete refresh is done on the materialized view, it still thinks the synonym is pointed at TABLE_1. Why when I do a complete refresh does the materialized view not pick up the new synonym pointer to TABLE_2?
Here is a workaround to Oracle's bug:
alter materialized view MV_NAME nocache;
BEGIN DBMS_SNAPSHOT.REFRESH( MV_NAME,'C'); end;
alter materialized view MV_NAME cache;
I cannot find anything useful in Oracle documentation but just enable the logic:
I firstly create materialized view
In reality to support this materialized view Oracle makes the TABLE with some specific structure (dependent on your query structure) and the rule to refresh the table (as far as I remember it is called SUMMARY, but the name does not play any role here)
I change synonym target to the table which has another structure
The new target table is not "fitting" to the previous structure (e.g. it has totally different amount/data types of columns), the previous structure is invalid then and not working anymore. The underground table must be recreated then.
That's why I would say it is the only way to prevent the errors: reference the real target instead of synonym for creating materialized view.
So, the answer is: because the materialized view is a static table-like object dependent on the data set it is selecting; that's why to prevent the inconsistencies materialized view references the real object.
Sometimes I really wonder how many details Oracle hides inside.
I have a materialized view that I need to redefine the SQL for. We have an external system that hits the view over a db link, and the monster view takes 5 minutes to refresh the data in the view. The only way I know how to redefine the SQL for a view is to drop it and recreate it, but it would be very bad if the external system couldn't find the table, or it didn't have a complete data set. I need to have as little downtime as possible.
Is there any way to do this natively or more elegantly than:
Create public synonym for materialized view and make everything that uses the view use the synonym instead.
Create new materialized view with new SQL
Change the synonym to point to the new view
Drop the old view.
I've got code to do this dynamically but it is getting really ugly. It seems like there should be a better way to handle this.
Oracle has a build in solution for that. Keep in mind that the mview declaration is separate from that of the table.
The original mview
create materialized view mv1 as select dept , count(*) as cnt from scott.emp;
we want to change the declaration so that only dept over 5 will be calculated
drop materialized view mv1 preserve table;
notice the PRESERVE TABLE clause - the table mv1 is not droped - only the mview layer.
desc mv1
now we create the mview with a different query on top of the existing table
create materialized view mv1 on prebuilt table as
select dept , count(*) as cnt from scott.emp where dept > 5;
notice the on prebuilt table clause. the mview is using the existing object.
exec dbms_mview.refresh_mview('mv1');