On commit restriction on materialized view.
Hello friends,
I am creating one materialized view which needs to be refreshed on commit, While creating that MV, i am getting error stating "On commit is not allowed for that.."
I have studied oracle documentations for the same.
The only restriction the document is saying is that, the Query for MV should not contain object type.
The query for which i am creating MV doesn't contain any object type.
Please friends,if you know, suggest me the document link stating the restrictions on use of "on commit" clause with create materialize view statement.
Regards,
Dipali.
There are many restrictions on MV especially with refresh fast on commit clause, refer the below link,(for oracle 10g R2)
http://download.oracle.com/docs/cd/B19306_01/server.102/b14223/basicmv.htm#i1007007
sbs
Similar Messages
-
On commit fast refreshable materialized view does not update
... but instead it deletes and inserts. And I would like it to perform an update, so we can add a database trigger to call a webservice. But it's crucial that we call the "update webservice" when it updates.
This is an Oracle 10.2.0.4 database.
Output of my problem-reproducing-case:
First creation of a small instrumentation setup:
SQL> create table logtable
2 ( id number
3 , time timestamp
4 , text varchar2(100)
5 )
6 /
Tabel is aangemaakt.
SQL> create sequence log_seq cache 100
2 /
Reeks is aangemaakt.
SQL> create procedure add_log_message (p_text in varchar2)
2 is
3 pragma autonomous_transaction;
4 begin
5 insert into logtable
6 values (log_seq.nextval,systimestamp,p_text);
7 commit;
8 end;
9 /
Procedure is aangemaakt.Two tables with full blown materialized view logs defined on them:
SQL> create table t1 (id,ean)
2 as
3 select level
4 , to_char(trunc(dbms_random.value(0,999999999999999999)))
5 from dual
6 connect by level <= 10
7 /
Tabel is aangemaakt.
SQL> alter table t1 add primary key (id)
2 /
Tabel is gewijzigd.
SQL> create materialized view log on t1 with sequence, rowid (id,ean) including new values
2 /
Gematerialiseerde viewlog is aangemaakt.
SQL> create table t2 (id,t1_id,value)
2 as
3 select level
4 , level * 2
5 , trunc(dbms_random.value(1,100))
6 from dual
7 connect by level <= 5
8 /
Tabel is aangemaakt.
SQL> alter table t2 add primary key (id)
2 /
Tabel is gewijzigd.
SQL> alter table t2 add foreign key (t1_id) references t1(id)
2 /
Tabel is gewijzigd.
SQL> create materialized view log on t2 with sequence, rowid (id,t1_id,value) including new values
2 /
Gematerialiseerde viewlog is aangemaakt.And the materialized view itself, containing an outer join. And on that materialized view there is a trigger that logs the action performed (I, U or D):
SQL> create materialized view mv refresh fast on commit
2 as
3 select t1.rowid t1_rowid
4 , t2.rowid t2_rowid
5 , t1.id t1_id
6 , t1.ean ean
7 , t2.id t2_id
8 , t2.value value
9 from t1
10 , t2
11 where t1.id = t2.t1_id (+)
12 and t1.ean is not null
13 /
Gematerialiseerde view is aangemaakt.
SQL> create trigger mv_trg_ariud
2 after insert or update or delete on mv
3 for each row
4 begin
5 add_log_message
6 ( case
7 when inserting then 'I'
8 when updating then 'U'
9 when deleting then 'D'
10 end
11 );
12 end;
13 /
Trigger is aangemaakt.
SQL> select * from mv
2 /
T1_ROWID T2_ROWID T1_ID EAN T2_ID VALUE
AAFwMeAChAABamIAAA 1 360432237186591962
AAFwMeAChAABamIAAB AAFwMhAChAABamaAAA 2 706465424496730795 1 77
AAFwMeAChAABamIAAC 3 678961199378791568
AAFwMeAChAABamIAAD AAFwMhAChAABamaAAB 4 351418443524585979 2 35
AAFwMeAChAABamIAAE 5 610374519804201714
AAFwMeAChAABamIAAF AAFwMhAChAABamaAAC 6 798782716740397566 3 33
AAFwMeAChAABamIAAG 7 909989471290455410
AAFwMeAChAABamIAAH AAFwMhAChAABamaAAD 8 670698835550268126 4 69
AAFwMeAChAABamIAAI 9 746290195605805530
AAFwMeAChAABamIAAJ AAFwMhAChAABamaAAE 10 157491298211132413 5 82
10 rijen zijn geselecteerd.Now we add a new t1 row, which leads to an extra row in the mv on commit time:
SQL> insert into t1 values (11, '999999999999999999')
2 /
1 rij is aangemaakt.
SQL> commit
2 /
Commit is voltooid.
SQL> select rpad(text,10) || to_char(time,'hh24:mi:ss.ff6') log
2 from logtable
3 order by id
4 /
LOG
I 11:39:47.817225
1 rij is geselecteerd.
SQL> select * from mv where ean = '999999999999999999'
2 /
T1_ROWID T2_ROWID T1_ID EAN T2_ID VALUE
AAFwMeAChAABamJAAA 11 999999999999999999
1 rij is geselecteerd.As expected. Now insert a record in t2, which should lead to an update of the materialized view:
SQL> insert into t2 values (11,11,1)
2 /
1 rij is aangemaakt.
SQL> commit
2 /
Commit is voltooid.
SQL> select * from mv where ean = '999999999999999999'
2 /
T1_ROWID T2_ROWID T1_ID EAN T2_ID VALUE
AAFwMeAChAABamJAAA AAFwMhAChAABambAAA 11 999999999999999999 11 1
1 rij is geselecteerd.
SQL> select rpad(text,10) || to_char(time,'hh24:mi:ss.ff6') log
2 from logtable
3 order by id
4 /
LOG
I 11:39:47.817225
D 11:39:47.992824
I 11:39:48.015072
3 rijen zijn geselecteerd.But it doesn't: apparently it has inserted a row and deleted a row. Let's do a normal update:
SQL> update t2 set value = 2 where id = 11
2 /
1 rij is bijgewerkt.
SQL> commit
2 /
Commit is voltooid.
SQL> select * from mv where ean = '999999999999999999'
2 /
T1_ROWID T2_ROWID T1_ID EAN T2_ID VALUE
AAFwMeAChAABamJAAA AAFwMhAChAABambAAA 11 999999999999999999 11 2
1 rij is geselecteerd.
SQL> select rpad(text,10) || to_char(time,'hh24:mi:ss.ff6') log
2 from logtable
3 order by id
4 /
LOG
I 11:39:47.817225
D 11:39:47.992824
I 11:39:48.015072
D 11:39:48.142621
I 11:39:48.168553
5 rijen zijn geselecteerd.And again: a delete and an insert.
Does anybody know if I can change this behaviour and let the mv perform an update?
In another materialized view (not shown here) containing aggregates, I've seen that it performs an update. But using this "join" mv, it does not.
Here is the script, if you want to try it on your own database:
create table logtable
( id number
, time timestamp
, text varchar2(100)
create sequence log_seq cache 100
create procedure add_log_message (p_text in varchar2)
is
pragma autonomous_transaction;
begin
insert into logtable
values (log_seq.nextval,systimestamp,p_text);
commit;
end;
create table t1 (id,ean)
as
select level
, to_char(trunc(dbms_random.value(0,999999999999999999)))
from dual
connect by level <= 10
alter table t1 add primary key (id)
create materialized view log on t1 with sequence, rowid (id,ean) including new values
create table t2 (id,t1_id,value)
as
select level
, level * 2
, trunc(dbms_random.value(1,100))
from dual
connect by level <= 5
alter table t2 add primary key (id)
alter table t2 add foreign key (t1_id) references t1(id)
create materialized view log on t2 with sequence, rowid (id,t1_id,value) including new values
create materialized view mv refresh fast on commit
as
select t1.rowid t1_rowid
, t2.rowid t2_rowid
, t1.id t1_id
, t1.ean ean
, t2.id t2_id
, t2.value value
from t1
, t2
where t1.id = t2.t1_id (+)
and t1.ean is not null
create trigger mv_trg_ariud
after insert or update or delete on mv
for each row
begin
add_log_message
( case
when inserting then 'I'
when updating then 'U'
when deleting then 'D'
end
end;
select * from mv
insert into t1 values (11, '999999999999999999')
commit
select rpad(text,10) || to_char(time,'hh24:mi:ss.ff6') log
from logtable
order by id
select * from mv where ean = '999999999999999999'
insert into t2 values (11,11,1)
commit
select * from mv where ean = '999999999999999999'
select rpad(text,10) || to_char(time,'hh24:mi:ss.ff6') log
from logtable
order by id
update t2 set value = 2 where id = 11
commit
select * from mv where ean = '999999999999999999'
select rpad(text,10) || to_char(time,'hh24:mi:ss.ff6') log
from logtable
order by id
set echo off
drop materialized view mv
drop table t2 purge
drop table t1 purge
drop procedure add_log_message
drop sequence log_seq
drop table logtable purge
/Regards,
Rob.
Edited by: Rob van Wijk on 7-mrt-2009 9:49
bumpRob,
here's what Tom says about this:
seems dangerous as there is nothing stopping Oracle from performing an "update" of a materialized
view as a DELETE+INSERT. For you see, the internals of how materialized views are maintained are
"internal" and subject to change (so even if documented - so what, you cannot control the "how" of
materialized view refreshes)
...It is from 2006 though ...things might have changed ;) -
Materialized view with tables in different schemas
Hello,
I want to create a materialized view with a table from a different schema in the SELECT statement. For materialized view I would like to apply the "REFRESH COMPLETE ON COMMIT" option.
Here the code:
CREATE MATERIALIZED VIEW S1.MV_EXAMPLE
TABLESPACE TS1
PCTFREE 0
BUILD IMMEDIATE
REFRESH COMPLETE ON COMMIT
AS
SELECT T.COLUMN1 COLUMN
FROM S2.TABLE1 T
I can't execute this SQL because I get an "insufficient privileges" error to this table:
FROM S2.TABLE1 T
FEHLER in Zeile 9:
ORA-01031: Insufficient privileges
User S1 has the following privileges:
CREATE SESSION
CREATE SNAPSHOT
CREATE TABLE
CREATE QUERY REWRITE
SELECT ANY TABLE
User S2 has the following privileges:
CREATE SESSION
CREATE SNAPSHOT
CREATE TABLE
CREATE QUERY REWRITE
ALTER ANY SNAPSHOT
Which privileges are missing?
Thanks, MathiasThanks Kamal for your answer!
S1 has the grant select directly. But I solveld the problem. The system privilege "ON COMMIT REFRESH" was missing for S1. This has to be set if any of the tables are outside the owner's schema of the materialized view (ORACLE documentation - Data Warehouse Guide).
But one thing is not clear to me yet and the ORACLE documentation doesn't give me an answer. I can set the refresh-attribute ON COMMIT on a materialized view containing only joins when a group by clause is set. If the group by clause is missing I can't! Why?
Regards, Mathias -
Regarding Error in Materialized view Fast Refresh
ORA-12015: cannot create a fast refresh materialized view from a complex query
CREATE MATERIALIZED VIEW MVCONTENTHISTORY_01
BUILD IMMEDIATE
REFRESH FAST
WITH PRIMARY KEY
ENABLE QUERY REWRITE
AS
SELECT a.DAY, a.contentname,
SUM
(CASE
WHEN (b.subscriptionstartdate) <= (a.DAY)
AND ((CASE
WHEN b.subscriptionenddate IS NOT NULL
THEN (a.DAY)
ELSE TO_DATE ('01/20/1990', 'MM/DD/YYYY')
END
) <=
(CASE
WHEN b.subscriptionenddate IS NOT NULL
THEN (b.subscriptionenddate)
ELSE TO_DATE ('01/20/1990', 'MM/DD/YYYY')
END
THEN 1
ELSE 0
END
) COUNT,
COUNT
(CASE
WHEN (b.subscriptionstartdate) <= (a.DAY)
AND ((CASE
WHEN b.subscriptionenddate IS NOT NULL
THEN (a.DAY)
ELSE TO_DATE ('01/20/1990', 'MM/DD/YYYY')
END
) <=
(CASE
WHEN b.subscriptionenddate IS NOT NULL
THEN (b.subscriptionenddate)
ELSE TO_DATE ('01/20/1990', 'MM/DD/YYYY')
END
THEN 1
ELSE 0
END
) cnt
FROM TBLTDATEWISECONTENT a,
(SELECT TRUNC (a.subscriptionstartdate) subscriptionstartdate,
TRUNC (a.subscriptionenddate) subscriptionenddate, b.NAME,
b.contentid
FROM syntbltcontentsubscrhistory a, syntblmcontent b
WHERE b.contentid = a.contentid(+)) b
WHERE a.contentid = b.contentid(+) AND a.DAY = b.subscriptionstartdate(+)
GROUP BY a.contentname, a.DAY;
I can't create Materialized view with fast Refresh .
Kindly provide solution .
Regards,
nayana chavda.Kindly provide full Oracle version since option vary by release.
There error message says it is impossible to fast refresh based on a complex query.
On 10g Oracle provides a package procedure that will tell you why the view cannot be fast refreshed: dbms_mview.explain_mview.
Otherwise see the Advanced Replication Manual for a list of restrictions.
10gR2 >>Restrictions for Materialized Views with Subqueries
The defining query of a materialized view with a subquery is subject to several restrictions to preserve the materialized view's fast refresh capability.
The following are restrictions for fast refresh materialized views with subqueries:
Materialized views must be primary key materialized views.
The master's materialized view log must include certain columns referenced in the subquery. For information about which columns must be included, see "Logging Columns in the Materialized View Log".
If the subquery is many to many or one to many, join columns that are not part of a primary key must be included in the materialized view log of the master. This restriction does not apply to many to one subqueries.
The subquery must be a positive subquery. For example, you can use the EXISTS condition, but not the NOT EXISTS condition.
The subquery must use EXISTS to connect each nested level (IN is not allowed).
Each table can be in only one EXISTS expression.
The join expression must use exact match or equality comparisons (that is, equi-joins).
Each table can be joined only once within the subquery.
A primary key must exist for each table at each nested level.
Each nested level can only reference the table in the level above it.
Subqueries can include AND conditions, but each OR condition can only reference columns contained within one row. Multiple OR conditions within a subquery can be connected with an AND condition.
All tables referenced in a subquery must reside in the same master site or master materialized view site.
<<
HTH -- Mark D Powell --
Message was edited by: added list of restrictions left off initial post
mpowel01 -
Constraint in Materialized View misbehave
Enviroment
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
s.o : windows 7. on laptop Intel core i7.
create table product_type
( product_type_id varchar2(3) constraint product_type_pk primary key,
product_type_name varchar2(100) constraint product_type_name_nn not null,
move_inv varchar2(1) default 'Y' constraint product_type_move_inv_nn not null,
generate_abc varchar2(1) default 'N' constraint product_type_generate_abc_nn not null,
constraint product_type_move_inv_check check (move_inv in ('Y','N')),
constraint product_type_gen_abc_check check (generate_abc in ('Y','N'))
create table product_class
( product_type_id varchar2(3) constraint product_class_type_id_nn not null,
product_class_id varchar2(3) constraint product_class_id_nn not null,
product_class_name varchar2(50) constraint product_class_name_nn not null,
inv_negative varchar2(1) default 'N' constraint product_class_inv_negative_nn not null,
constraint product_class_pk primary key (product_type_id,product_class_id),
constraint product_class_by_product_type foreign key (product_type_id) references product_type(product_type_id),
constraint product_class_inv_negative_chk check (inv_negative in ('Y','N'))
create materialized view log on product_type with rowid, primary key , sequence (move_inv) including new values;
create materialized view log on product_class with rowid, primary key , sequence (inv_negative) including new values;
create materialized view prd_type_val_prd_class
refresh fast on commit as
select count(*) tot_rows
from product_type pt
join product_class pc
on ( pt.product_type_id = pc.product_type_id )
where pt.move_inv = 'N' and pc.inv_negative = 'Y';
alter table prd_type_val_prd_class add constraint rows_in_prd_type_val_prd_class check( tot_rows < 1 );
-- sentence 1, expected to works
insert into product_type values('SAR','FARMA','N','N');
commit; --- WORKS fine.
-- sentence 2, expected to works
insert into product_class values('SAR','LIQ','LIQUID' ,'N');
commit; --- WORKS fine
-- sentence 3, expected to fail due materialized view constraint
insert into product_class values('SAR','CAP','CAPSULES','Y');
commit; ---> SHOW the materialized view constraint Error FINE!!!!!!
update product_type set move_inv = 'Y'; -- Update product type to allow sentence 3 to be ok
commit; ---> works fine
--- Re execute sentence 3 ----> success FINE!
---sentence 4, WORKS unexpected. --- it suppose to show the error, due materialized view constraint as did in sentence 3 (first try)
update product_type set move_inv = 'N';
commit; --- WORKS :( since this point ON the materialized view constraint error is show no More.... :(
insert into product_class values('SAR','TAB','TABLETS','Y');
commit;
insert into product_class values('SAR','ABC','ABCZXY','Y');
commit;
select count(*) tot_rows
from product_type pt
join product_class pc
on ( pt.product_type_id = pc.product_type_id )
where pt.move_inv = 'N' and pc.inv_negative = 'Y';
tot_rows
3
Any Idea why is this not working as expected??? maybe I'm missing something or is this a glitch???? hope is not.
thank youluis,
I don't understand why your mv failed, but I tried it in a way I would do it, using an empty MV rather than one with a single rwos with 0 in it. i.e.:
create materialized view prd_type_val_prd_class
refresh fast on commit
as
select pt.product_type_id
,pc.product_type_id pc_bc_product_type_id
,pc.product_class_id
,pc.rowid pc_row_id
,pt.rowid pt_row_id
from product_type pt
, product_class pc
where pt.bc_product_type_id = pc.bc_product_type_id
AND pt.move_inv = 'N' and pc.inv_negative = 'Y';and changed the constraint to keep it empty:
alter table prd_type_val_prd_class add constraint rows_in_prd_type_val_prd_class check(1=0);Is it seemed to pass all your tests -
Adding a field to materialized view
I have a materialized view called DEVICE which gets it's data from a table called device in another database (asset3). A new field was added to the device table in the asset3 database. In order to add that field to the materialized view, will I need to drop the materialized view and recreate it or can I run an alter command to add the field?
SQL> select MVIEW_NAME,QUERY from DBA_MVIEWS where OWNER='DWH' and MVIEW_NAME='DEVICE';
MVIEW_NAME
QUERY
DEVICE
select * from device@asset3Thanks
RaviYou have to recreate materialized Views
Example(REFRESH FAST ON COMMIT):
SQL> CREATE MATERIALIZED VIEW LOG ON B with rowid;
SQL> CREATE MATERIALIZED VIEW MV_B REFRESH FAST ON COMMIT with rowid AS select * from B;
SQL> alter table B add k number;
SQL> ALTER MATERIALIZED VIEW LOG ON B add (k);
SQL> drop MATERIALIZED VIEW MV_B;
SQ> CREATE MATERIALIZED VIEW MV_B REFRESH FAST ON COMMIT with rowid AS select * from B;Edited by: Surachart (HunterX) on Jun 17, 2009 11:11 PM -
Materialized view - REFRESH FAST ON COMMIT - UNION ALL
In a materialized view which uses REFRESH FAST ON COMMIT to update the data, how many UNION ALL can be used.
I am asking this question because my materialized view works fine when there are only 2 SELECT statement (1 UNION ALL).
Thank you.In a materialized view which uses REFRESH FAST ON COMMIT to update the data, how many UNION ALL can be used.As far as I remember you can have 64K UNIONized selects.
I am asking this question because my materialized view works fine when there are only 2 SELECT statement (1 UNION ALL).Post SQL that does not work. -
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 advanceStraight 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 on two tables with Fast Refresh
i Wanted to create MV on two tables with Fast refresh on commit.
I followed below steps
create materialized view log on t1 WITH PRIMARY KEY, rowid;
create materialized view log on t2 WITH PRIMARY KEY, rowid;
CREATE MATERIALIZED VIEW ETL_ENTITY_DIVISION_ASSO_MV
REFRESH fast ON commit
ENABLE QUERY REWRITE
AS
select A.ROWID B.ROWID,a.c1, DECODE(a.c1,'aaa','xxx','aaa') c2
from t1 A
join t2 b
on AB.c1= CD.c2;
i am getting below error.
Error report:
SQL Error: ORA-12054: cannot set the ON COMMIT refresh attribute for the materialized view
12054. 00000 - "cannot set the ON COMMIT refresh attribute for the materialized view"
*Cause: The materialized view did not satisfy conditions for refresh at
commit time.
*Action: Specify only valid options.
Basically i want to take record in MV by joinig two tables and if both of the base tables will updated then record should reflect in materialised view.
Please do the needfull.does the table support PCT? the other restrictions on joins look to be ok in your statement.
maybe try creating first with on demand instead of commit to see does it create.
http://docs.oracle.com/cd/B19306_01/server.102/b14223/basicmv.htm
>
Materialized Views Containing Only Joins
Some materialized views contain only joins and no aggregates, such as in Example 8-4, where a materialized view is created that joins the sales table to the times and customers tables. The advantage of creating this type of materialized view is that expensive joins will be precalculated.
Fast refresh for a materialized view containing only joins is possible after any type of DML to the base tables (direct-path or conventional INSERT, UPDATE, or DELETE).
A materialized view containing only joins can be defined to be refreshed ON COMMIT or ON DEMAND. If it is ON COMMIT, the refresh is performed at commit time of the transaction that does DML on the materialized view's detail table.
If you specify REFRESH FAST, Oracle performs further verification of the query definition to ensure that fast refresh can be performed if any of the detail tables change. These additional checks are:
A materialized view log must be present for each detail table unless the table supports PCT. Also, when a materialized view log is required, the ROWID column must be present in each materialized view log.
The rowids of all the detail tables must appear in the SELECT list of the materialized view query definition.
If some of these restrictions are not met, you can create the materialized view as REFRESH FORCE to take advantage of fast refresh when it is possible. If one of the tables did not meet all of the criteria, but the other tables did, the materialized view would still be fast refreshable with respect to the other tables for which all the criteria are met. -
Materialized View creation with REFRESH FAST
Hello ,
Please see below case,
TABLE A1(partitioned range+list)
COLUMN C1 -- Primary key
COLUMN C2 -- NUMBER
TABLE D1
COLUMN C1 -- PRIMARY KEY
created MV log as below
CREATE MATERIALIzED VIEW LOG ON A1 WITH ROWID,PRIMARY KEY INCLUDING NEW VALUES;
CREATE MATERIALIzED VIEW LOG ON D1 WITH ROWID,PRIMARY KEY INCLUDING NEW VALUES;
Trying to create MV like below:
CREATE MATERILIZED VIEW mv1test
REFRESH FAST ON COMMIT
AS
Select
FROM A1,
D1
WHERE A1.C1 = D1.CI
AND A1.C2 IS NOT NULL;
It gives below error message:
ORA-12052: cannot fast refresh materialized view schema.mv1test
12052. 00000 - "cannot fast refresh materialized view %s.%s"
*Cause: Either ROWIDs of certain tables were missing in the definition or
the inner table of an outer join did not have UNIQUE constraints on
join columns.
*Action: Specify the FORCE or COMPLETE option. If this error is got
during creation, the materialized view definition may have be
changed. Refer to the documentation on materialized views.
However ,as discussed in earlier thread i checked all general restrictions of the 'Refresh fast' approach for join.
Restrictions on Fast Refresh on Materialized Views with Joins Only
Defining queries for materialized views with joins only and no aggregates have the following restrictions on fast refresh:
1) They cannot have GROUPBY clauses or aggregates.
2) Rowids of all the tables in the FROM list must appear in the SELECT list of the query.
3)Materialized view logs must exist with rowids for all the base tables in the FROM list of the query.
4)You cannot create a fast refreshable materialized view from multiple tables with simple joins that include an object type column in the SELECTstatement.
As per above restrictions ,
1) Group by clause is not present
2)i do not understand 2nd point , i have added a1.rowid and d1.rowid in select statement of MV, but got same error.
3) observed same as 2nd point.
4)we have CLOB column in select list. Tried removing this column but got same error.
Please do let me know any workaround on this.
Thanks in advanced ..
PMBasic Materialized Views show how to analyse MVs using dbms_mview. I'm not sure about creating MVs on partitioned tables, that partition maintenance might cause problems
-
Problem creating materialized view
OK, I'm totally new in using materialized views.
I'm trying to create one and to make it refreshed on commit
CREATE MATERIALIZED VIEW VK_CLIENT build immediate refresh fast on commit AS
select c1.code,
c1.fiche fiche_1,
decode( c1.sfam, '04',
decode( c7.sfam, '04', 'M. et Mme', c1.lnte ), c1.lnte ) lnte_1,
decode( c1.sfam, '04',
decode( c7.sfam, '04',
decode( c1.lnte, 'M.', c1.libe, c7.libe ), c1.libe ), c1.libe ) libe_1,
decode( c1.sfam, '04',
decode( c7.sfam, '04',
decode( c1.lnte, 'M.', substr( c1.libe, 1, c1.lgnom ), substr( c7.libe, 1, c7.lgnom ) ), substr( c1.libe, 1, c1.lgnom ) ), substr( c1.libe, 1, c1.lgnom ) ) nom_1,
decode( c1.sfam, '04',
decode( c7.sfam, '04',
decode( c1.lnte, 'M.', initcap( substr( c1.libe, c1.lgnom + 2 ) ), initcap( substr( c7.libe, c7.lgnom + 2 ) ) ), initcap( substr( c1.libe, c1.lgnom + 2 ) ) ), initcap( substr( c1.libe, c1.lgnom + 2 ) ) ) prenom_1,
decode( c1.sfam, '04', decode( c7.sfam, '04', decode( c1.lnte, 'Mlle', 'Mme', c1.lnte ), c1.lnte ), c1.lnte ) lnte_1_bis,
c1.libe libe_1_bis,
substr( c1.libe, 1, c1.lgnom ) nom_1_bis,
initcap( substr( c1.libe, c1.lgnom + 2 ) ) prenom_1_bis,
c1.sfam sfam_1,
c1.dnai dnai_1,
decode( to_char( c1.dnai, 'dd' ), '01', '1er',
decode( substr( to_char( c1.dnai, 'dd' ), 1, 1 ), 0, substr( to_char( c1.dnai, 'dd' ), 2 ), to_char( c1.dnai, 'dd' ) ) ) || ' ' ||
rtrim( to_char( c1.dnai, 'month', 'nls_date_language = french' ) ) || to_char( c1.dnai, ' yyyy' ) dnai_fr_1,
c1.horsfoyer horsfoyer_1,
decode( c1.lnte, 'Mlle', 'f', 'Mme', 'f', 'M.', 'm' ) accord_1,
c7.fiche fiche_7,
decode( c1.sfam, '04',
decode( c7.sfam, '04', null, c7.lnte ), c7.lnte ) lnte_7,
decode( c1.sfam, '04',
decode( c7.sfam, '04', null, c7.libe ), c7.libe ) libe_7,
decode( c1.sfam, '04',
decode( c7.sfam, '04', null, substr( c7.libe, 1, c7.lgnom ) ), substr( c7.libe, 1, c7.lgnom ) ) nom_7,
decode( c1.sfam, '04',
decode( c7.sfam, '04', null, initcap( substr( c7.libe, c7.lgnom + 2 ) ) ), initcap( substr( c7.libe, c7.lgnom + 2 ) ) ) prenom_7,
decode( c7.sfam, '04', decode( c1.sfam, '04', decode( c7.lnte, 'Mlle', 'Mme', c7.lnte ), c7.lnte ), c7.lnte ) lnte_7_bis,
c7.libe libe_7_bis,
substr( c7.libe, 1, c7.lgnom ) nom_7_bis,
initcap( substr( c7.libe, c7.lgnom + 2 ) ) prenom_7_bis,
c7.sfam sfam_7,
c7.dnai dnai_7,
decode( to_char( c7.dnai, 'dd' ), '01', '1er',
decode( substr( to_char( c7.dnai, 'dd' ), 1, 1 ), 0, substr( to_char( c7.dnai, 'dd' ), 2 ), to_char( c7.dnai, 'dd' ) ) ) || ' ' ||
rtrim( to_char( c7.dnai, 'month', 'nls_date_language = french' ) ) || to_char( c7.dnai, ' yyyy' ) dnai_fr_7,
decode( c7.lnte, 'Mlle', 'f', 'Mme', 'f', 'M.', 'm' ) accord_7,
initcap( decode( instr( lower( c1.adr1 ), 'log' ), '1', c1.adr2, decode( instr( lower( c1.adr1 ), 'bât' ), '1', c1.adr2, c1.adr1 ) ) ) adr1,
initcap( decode( decode( instr( lower( c1.adr1 ), 'log' ), '1', c1.adr2, decode( instr( lower( c1.adr1 ), 'bât' ), '1', c1.adr2, c1.adr1 ) ), c1.adr2, null,
decode( instr( lower( c1.adr2 ), 'log' ), '1', c1.adr3, decode( instr( lower( c1.adr2 ), 'bât' ), '1', c1.adr3, c1.adr2 ) ) ) ) adr2,
initcap( decode( instr( lower( c1.adr3 ), 'log' ), '1', null, decode( instr( lower( c1.adr3 ), 'bât' ), '1', null, c1.adr3 ) ) ) adr3,
c1.ptt,
c1.lcom,
decode( c7.fiche, null, decode( c1.lnte, 'Mme', 'Madame', 'Mlle', 'Mademoiselle', 'M.', 'Monsieur', 'Monsieur' ),
decode( nvl( c1.sfam, '07' ), '04',
decode( nvl( c7.sfam, '07' ), '04', 'Madame, Monsieur',
decode( c1.lnte,
'Mme', decode( c7.lnte, 'Mme', 'Mesdames', 'Mlle', 'Madame, Mademoiselle', 'M.', 'Madame, Monsieur', 'Madame, Monsieur' ),
'Mlle', decode( c7.lnte, 'Mme', 'Madame, Mademoiselle', 'Mlle', 'Mesdemoiselles', 'M.', 'Mademoiselle, Monsieur', 'Mademoiselle, Monsieur' ),
'M.', decode( c7.lnte, 'Mme', 'Madame, Monsieur', 'Mlle', 'Mademoiselle, Monsieur', 'M.', 'Mesieurs', 'Mesieurs' ),
'. ', decode( c7.lnte, 'Mme', 'Madame, Monsieur', 'Mlle', 'Mademoiselle, Monsieur', 'M.', 'Mesieurs', 'Mesieurs' ),
decode( c1.lnte,
'Mme', decode( c7.lnte, 'Mme', 'Mesdames', 'Mlle', 'Madame, Mademoiselle', 'M.', 'Madame, Monsieur', 'Madame, Monsieur' ),
'Mlle', decode( c7.lnte, 'Mme', 'Madame, Mademoiselle', 'Mlle', 'Mesdemoiselles', 'M.', 'Mademoiselle, Monsieur', 'Mademoiselle, Monsieur' ),
'M.', decode( c7.lnte, 'Mme', 'Madame, Monsieur', 'Mlle', 'Mademoiselle, Monsieur', 'M.', 'Mesieurs', 'Mesieurs' ),
'. ', decode( c7.lnte, 'Mme', 'Madame, Monsieur', 'Mlle', 'Mademoiselle, Monsieur', 'M.', 'Mesieurs', 'Mesieurs' ),
'-' ) ) ) lnte_long,
decode( c1.cfam, null, c7.cfam, c1.cfam ) cfam,
decode( c1.cfam, null, c7.allo, c1.allo ) allo,
decode( c1.sexe, 'm', decode( c7.sexe, null, 'ms', 'm', 'mp', 'f', 'mp' ), 'f', decode( c7.sexe, null, 'fs', 'm', 'mp', 'f', 'fp' ), '-' ) accord,
c9.fiche fiche_9,
c9.lnte lnte_9,
c9.libe libe_9,
substr( c9.libe, 1, c9.lgnom ) nom_9,
initcap( substr( c9.libe, c9.lgnom + 2 ) ) prenom_9,
initcap( decode( instr( lower( c9.adr1 ), 'log' ), '1', c9.adr2, decode( instr( lower( c9.adr1 ), 'bât' ), '1', c9.adr2, c9.adr1 ) ) ) adr1_9,
initcap( decode( decode( instr( lower( c9.adr1 ), 'log' ), '1', c9.adr2, decode( instr( lower( c9.adr1 ), 'bât' ), '1', c9.adr2, c9.adr1 ) ), c9.adr2, null,
decode( instr( lower( c9.adr2 ), 'log' ), '1', c9.adr3, decode( instr( lower( c9.adr2 ), 'bât' ), '1', c9.adr3, c9.adr2 ) ) ) ) adr2_9,
initcap( decode( instr( lower( c9.adr3 ), 'log' ), '1', null, decode( instr( lower( c9.adr3 ), 'bât' ), '1', null, c9.adr3 ) ) ) adr3_9,
c9.ptt ptt_9,
c9.lcom lcom_9,
decode( c9.lnte, 'Mlle' , 'Mademoiselle', 'Mme', 'Madame', 'M.', 'Monsieur', 'M. et Mme', 'Madame, Monsieur', null ) lnte_long_9,
decode( c9.sexe, 'm', 'ms', 'f', 'fs', null, null, '-' ) accord_9,
no.nbocc
from client c1,
client c7,
client c9,
select z.code code,
count(*) nbocc
from client z
where to_char( sysdate, 'yyyymmdd' ) between to_char( z.cdeb, 'yyyymmdd' ) and to_char( nvl( z.cfin, sysdate ), 'yyyymmdd' )
group by z.code
) no
where c1.code = c7.code (+)
and c1.role = '1'
and c7.role (+) ='7'
and nvl( c7.horsfoyer (+), 0 ) = '0'
and to_char( nvl( c7.cfin (+), sysdate ), 'yyyymmdd' ) >= to_char( sysdate, 'yyyymmdd' )
and c1.code = c9.code (+)
and c9.role (+) = '9'
and to_char( nvl( c9.cfin (+), sysdate ), 'yyyymmdd' ) >= to_char( sysdate, 'yyyymmdd' )
and c9.lnte (+) not in ( '. ', 'Assoc.', 'Ste' )
and c9.lcom (+) is not null
and c1.code = no.code (+);when doing so, I'm getting a ORA-12054:
ORA-12054: cannot set the ON COMMIT refresh attribute for the materialized view
12054. 00000 - "cannot set the ON COMMIT refresh attribute for the materialized view"
*Cause: The materialized view did not satisfy conditions for refresh at
commit time.
*Action: Specify only valid options.
When I create the materialized view with just CREATE MATERIALIZED VIEW "H6801_GL_00"."VK_CLIENT" AS
it works but the refresh is only "ON DEMAND"...
Can't find how and why it won't work...
Edited by: MacFizz on Dec 17, 2009 3:22 PMYou could try the DBMS_MVIEW.TUNE_MVIEW and check if you can modify you materialized view or "refactor" it in a smaller, fast refreshable part that you could combine later to the sysdate/rownum part of it.
http://download.oracle.com/docs/cd/E11882_01/server.112/e10821/advisor.htm
Explanation on restrictions of fast refresh:
http://download.oracle.com/docs/cd/E11882_01/server.112/e10706/repmview.htm
Below there's an example of a fast refreshable mview, on creating the materialized view log and so on:
http://download.oracle.com/docs/cd/E11882_01/server.112/e10592/statements_6002.htm#i2080820 -
Leave a distinct value in a materialized view on two tables
Hi and thank you for reading,
I have the following problem. I am creating a materialized view out of two tables, with "where a.id = b.id".
The resulting materialized view list several values twice. For example, one customer name has several contact details and thus the customer name is listed several times. Now I would like to join each customer name with just ONE contact detail, how can I do that? (Even if I would loose some information while doing this).
Thanks
EvgenyHi,
You can do this
SELECT deptno, empno, ename, job, mgr, hiredate, sal, comm
FROM emp_test
ORDER BY deptno;
DEPTNO EMPNO ENAME JOB MGR HIREDATE SAL COMM
10 7782 CLARK MANAGER 7839 1981-06-09 2450
10 7839 KING PRESIDENT 1981-11-17 5000 0
10 7934 MILLER CLERK 7782 1982-01-23 1300
20 7566 JONES MANAGER 7839 1981-04-02 2975
20 7902 FORD ANALYST 7566 1981-12-03 3000
20 7876 ADAMS CLERK 7788 1987-05-23 1100
20 7369 SMITH CLERK 7902 1980-12-17 800
20 7788 SCOTT ANALYST 7566 1987-04-19 3000
30 7521 WARD SALESMAN 7698 1981-02-22 1250 500
30 7844 TURNER SALESMAN 7698 1981-09-08 1500
30 7499 ALLEN SALESMAN 7698 1981-02-20 1600 300
30 7900 JAMES CLERK 7698 1981-12-03 950
30 7698 BLAKE MANAGER 7839 1981-05-01 2850
30 7654 MARTIN SALESMAN 7698 1981-09-28 1250 1400
14 rows selected.
SELECT CASE
WHEN ROW_NUMBER () OVER (PARTITION BY deptno ORDER BY empno) =
1
THEN deptno
END deptno,
empno, ename, job, mgr, hiredate, sal, comm
FROM emp_test;
DEPTNO EMPNO ENAME JOB MGR HIREDATE SAL COMM
10 7782 CLARK MANAGER 7839 1981-06-09 2450
7839 KING PRESIDENT 1981-11-17 5000 0
7934 MILLER CLERK 7782 1982-01-23 1300
20 7369 SMITH CLERK 7902 1980-12-17 800
7566 JONES MANAGER 7839 1981-04-02 2975
7788 SCOTT ANALYST 7566 1987-04-19 3000
7876 ADAMS CLERK 7788 1987-05-23 1100
7902 FORD ANALYST 7566 1981-12-03 3000
30 7499 ALLEN SALESMAN 7698 1981-02-20 1600 300
7521 WARD SALESMAN 7698 1981-02-22 1250 500
7654 MARTIN SALESMAN 7698 1981-09-28 1250 1400
7698 BLAKE MANAGER 7839 1981-05-01 2850
7844 TURNER SALESMAN 7698 1981-09-08 1500
7900 JAMES CLERK 7698 1981-12-03 950
14 rows selected.Edited by: Salim Chelabi on 2009-09-14 08:13 -
A bug when refreshing a materialized view?
I am getting "ORA-00603: ORACLE server session terminated by fatal error" upon refresh of a materialized view. I've put together a test case to demonstrate the problem. Is it a bug?
SQL*Plus: Release 10.1.0.3.0 - Production on Fri Jul 29 13:43:45 2005
Copyright (c) 1982, 2004, Oracle. All rights reserved.
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.6.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.6.0 - Production
[email protected]> create table t (
2 id int primary key,
3 t_name varchar2(10),
4 t_date date
5 );
Table created.
[email protected]> create materialized view log on t
2 with rowid (t_name, id, t_date) including new values;
Materialized view log created.
[email protected]> create materialized view t_mv
2 build immediate
3 refresh fast
4 on commit
5 as
6 select t_name, max(id) id, max(t_date) t_date, count(*)
7 from t
8 GROUP BY t_name;
Materialized view created.
[email protected]> create materialized view log on t_mv
2 with rowid (id) including new values;
Materialized view log created.
[email protected]> create table v (
2 id int primary key,
3 t_id int references t(id) on delete cascade,
4 v_name varchar2(10)
5 );
Table created.
[email protected]> create materialized view log on v
2 with rowid (v_name, t_id) including new values;
Materialized view log created.
[email protected]> create materialized view v_mv
2 build immediate
3 refresh fast
4 on commit
5 as
6 select v.rowid rowid1, t_mv.rowid rowid2, v.v_name, v.t_id
7 from v, t_mv
8 where v.t_id = t_mv.id;
Materialized view created.
[email protected]> alter table v_mv
2 add constraint v_mv_uk1 unique
3 (
4 v_name
5 )
6 enable
7 ;
Table altered.
[email protected]> insert into t (id, t_name, t_date) values (1, 'A', sysdate);
1 row created.
[email protected]> insert into t (id, t_name, t_date) values (2, 'B', sysdate);
1 row created.
[email protected]> insert into t (id, t_name, t_date) values (3, 'A', sysdate);
1 row created.
[email protected]> insert into t (id, t_name, t_date) values (4, 'A', sysdate);
1 row created.
[email protected]> insert into t (id, t_name, t_date) values (5, 'B', sysdate);
1 row created.
[email protected]> insert into v (id, t_id, v_name) values (1, 1, 'V_A_1');
1 row created.
[email protected]> insert into v (id, t_id, v_name) values (2, 2, 'V_B_1');
1 row created.
[email protected]> insert into v (id, t_id, v_name) values (3, 3, 'V_A_2');
1 row created.
[email protected]> insert into v (id, t_id, v_name) values (4, 4, 'V_A_3');
1 row created.
[email protected]> insert into v (id, t_id, v_name) values (5, 5, 'V_B_2');
1 row created.
[email protected]> commit;
Commit complete.
[email protected]> insert into t (id, t_name, t_date) values (6, 'A', sysdate);
1 row created.
[email protected]> insert into v (id, t_id, v_name) values (6, 6, 'V_B_2');
1 row created.
[email protected]> commit;
commit
ERROR at line 1:
ORA-12008: error in materialized view refresh path
ORA-00001: unique constraint (FESA.V_MV_UK1) violated
[email protected]> -- ORA-12008 is fine here: that's what was expected
[email protected]> delete from t where id = 5;
1 row deleted.
[email protected]> commit;
ERROR:
ORA-03114: not connected to ORACLE
commit
ERROR at line 1:
ORA-00603: ORACLE server session terminated by fatal errorWhy ORA-00603?
Best regards,
MaciejIt may be a bug, or it may be a result of the dependencies between the materialized views. I don't have a 9.2.0.6 instance that I'm willing to trash to test this, but this is what I get on 9.2.0.1.
If it is a bug they at least changed the behaviour of the bug in 9.2.0.6.
I ran your script up to the first commit then did:
SQL> SELECT * FROM t;
ID T_NAME T_DATE
1 A 29-JUL-05
2 B 29-JUL-05
3 A 29-JUL-05
4 A 29-JUL-05
5 B 29-JUL-05
SQL> SELECT * FROM t_mv;
T_NAME ID T_DATE COUNT(*)
A 4 29-JUL-05 3
B 5 29-JUL-05 2
SQL> SELECT * FROM v;
ID T_ID V_NAME
1 1 V_A_1
2 2 V_B_1
3 3 V_A_2
4 4 V_A_3
5 5 V_B_2
SQL> SELECT * FROM v_mv;
no rows selectedHUH?? But:
SQL> SELECT v.rowid rowid1, t_mv.rowid rowid2, v.v_name, v.t_id
2 FROM v, t_mv
3 WHERE v.t_id = t_mv.id;
ROWID1 ROWID2 V_NAME T_ID
AAAH4QAAIAAAAl1AAD AAAH4MAAIAAAAlFAAA V_A_3 4
AAAH4QAAIAAAAl1AAE AAAH4MAAIAAAAlFAAB V_B_2 5So, I tried:
SQL> EXEC DBMS_MVIEW.REFRESH('V_MV');
PL/SQL procedure successfully completed.
SQL> SELECT * FROM v_mv;
no rows selectedNow, this is confusing, so:
SQL> EXEC DBMS_MVIEW.REFRESH('V_MV', 'COMPLETE');
PL/SQL procedure successfully completed.
SQL> SELECT * FROM v_mv;
ROWID1 ROWID2 V_NAME T_ID
AAAH4dAAIAAAAl1AAD AAAH4ZAAIAAAAlFAAA V_A_3 4
AAAH4dAAIAAAAl1AAE AAAH4ZAAIAAAAlFAAB V_B_2 5So at least I've got something in the MV. Now, to continue your test:
SQL> insert into t (id, t_name, t_date) values (6, 'A', sysdate);
1 row created.
SQL> insert into v (id, t_id, v_name) values (6, 6, 'V_B_2');
1 row created.
SQL> COMMIT;
Commit complete.I also expected the error but no joy, and look at this:
SQL> SELECT * FROM v_mv;
ROWID1 ROWID2 V_NAME T_ID
AAAH4dAAIAAAAl1AAE AAAH4ZAAIAAAAlFAAB V_B_2 5Forcing the refresh on v_mv gets:
SQL> EXEC DBMS_MVIEW.REFRESH('V_MV', 'COMPLETE');
BEGIN DBMS_MVIEW.REFRESH('V_MV', 'COMPLETE'); END;
ERROR at line 1:
ORA-12008: error in materialized view refresh path
ORA-00001: unique constraint (OPS$ORACLE.V_MV_UK1) violatedVery strange! It gets better:
SQL> DELETE FROM t WHERE id = 5;
1 row deleted.
SQL> commit;
Commit complete.
SQL> EXEC DBMS_MVIEW.REFRESH('V_MV', 'COMPLETE');
PL/SQL procedure successfully completed.
SQL> select * from v_mv;
ROWID1 ROWID2 V_NAME T_ID
AAAH4dAAIAAAAl1AAF AAAH4ZAAIAAAAlFAAA V_B_2 6 But:
SQL> SELECT * FROM t_mv;
T_NAME ID T_DATE COUNT(*)
A 6 29-JUL-05 4
B 5 29-JUL-05 2
SQL> SELECT * FROM t;
ID T_NAME T_DATE
1 A 29-JUL-05
2 B 29-JUL-05
3 A 29-JUL-05
4 A 29-JUL-05
6 A 29-JUL-05Obvioulsy, something is not fast refreshing. So lets force it:
SQL> EXEC DBMS_MVIEW.Refresh('T_MV', 'COMPLETE');
PL/SQL procedure successfully completed.
SQL> SELECT * FROM t_mv;
T_NAME ID T_DATE COUNT(*)
A 6 29-JUL-05 4
B 2 29-JUL-05 1
SQL> SELECT * FROM v_mv;
ROWID1 ROWID2 V_NAME T_ID
AAAH4dAAIAAAAl1AAB AAAH4qAAIAAAAlEAAB V_B_1 2
AAAH4dAAIAAAAl1AAF AAAH4qAAIAAAAlEAAA V_B_2 6Which looks right to me.
Then, I blew everything away and did it allagain up to an including the inserts into t, then I inserted into v and commited. Now, both MV's were correct, so I did:
SQL> insert into t (id, t_name, t_date) values (6, 'A', sysdate);
1 row created.
SQL> insert into v (id, t_id, v_name) values (6, 6, 'V_B_2');
1 row created.
SQL> commit;
Commit complete.
SQL> SELECT * FROM t_mv;
T_NAME ID T_DATE COUNT(*)
A 6 29-JUL-05 4
B 5 29-JUL-05 2Still strange, so blow it all away again insert into t commit, insert into v commit, then:
SQL> insert into t (id, t_name, t_date) values (6, 'A', sysdate);
1 row created.
SQL> commit;
Commit complete.
SQL> insert into v (id, t_id, v_name) values (6, 6, 'V_B_2');
1 row created.
SQL> commit;
commit
ERROR at line 1:
ORA-12008: error in materialized view refresh path
ORA-00001: unique constraint (OPS$ORACLE.V_MV_UK1) violatedAt least now it sees the error at commit time for v so lets try the delete:
SQL> delete from t where id = 5;
1 row deleted.
SQL> commit;
Commit complete.
SQL> SELECT * FROM t_mv;
T_NAME ID T_DATE COUNT(*)
A 6 29-JUL-05 4
B 5 29-JUL-05 2
SQL> SELECT * FROM t;
ID T_NAME T_DATE
1 A 29-JUL-05
2 B 29-JUL-05
3 A 29-JUL-05
4 A 29-JUL-05
6 A 29-JUL-05Still not actually refreshing somehow.
I may play with this some more, it seems truly strange to me.
John -
ORA-00600: internal error when delete master rows in a materialized view
I have a materialized view in 11g2 on Redhat 5, defined asCREATE MATERIALIZED VIEW mv_idty
PARALLEL BUILD IMMEDIATE REFRESH FAST ON COMMIT ENABLE QUERY REWRITE AS
select IDTY_NAME_FIRST,IDTY_NAME_MIDDLE,IDTY_NAME_LAST,IDTY_NAME_SUFFIX,IDTY_SSN,
IDTY_DR_LIC_NUM,IDTY_DR_LIC_STA,x.person_id,i.rowid i_rowid,x.rowid x_rowid
from idty i,person_x_idty x where x.idty_id=i.idty_id; I deleted a few rows from the master tables and get error13:58:48 SQL> delete idty where idty_id like 'test_row%' ;
7 rows deleted.
13:58:52 SQL> commit;
commit
ERROR at line 1:
ORA-12008: error in materialized view refresh path
ORA-00600: internal error code, arguments: [kkzfrfajv_markdml-1], [], [], [], [], [], [], [], [], [], [], [] I have other materialized views and they all delete master OK. This is the simplest one but causes problem. HELP!
Edited by: user13148231 on Aug 11, 2010 5:45 PMChecked note 743766.1. It is not 100% relevant as it is about import, but the query is usefulselect sowner, vname, mowner, master from sys.snap_reftime$It reveals the materialized view some how based on other schema.
Recreate the materialized view. problem solved. -
Issue with fast refresh on a materialized view
Hi,
Oracle DB version is 10.2.0.3
We have a matierialized view created using this script. We have materialized view logs on these six tables.
By default, it is set to ON COMMIT .
When a batch job is run every morning (usually 100-200 records) we set it to ON DEMAND and then bring it back to ON COMMIT. It takes around 1-2 minutes.
If the batch is unusually big, like say 100,000 it takes more than 5 hours to put it back on ON COMMIT. (We analyze the schema (GATHER STALE) before refreshing the MV.) Trace shows deletes taking a long time.
When I see a big batch, I usually drop the view and recreate it with indexes (there is also a context index). Takes 30 mins to do the whole thing.
I tried refreshing it COMPLETE when the num of rows is high but it still takes more than 2 hours..(I killed it)
Is there any way to speed things up without dropping and recreating the MV ?
thanks
Mat view creation script:
CREATE MATERIALIZED VIEW WCC_INTERNAL_SEARCH_M
TABLESPACE ICV_TS_WCC_DATA
NOCACHE
LOGGING
NOCOMPRESS
NOPARALLEL
BUILD IMMEDIATE
REFRESH FAST ON COMMIT
WITH ROWID
AS
SELECT orgname.ROWID orgname_rowid,
cnt.ROWID cnt_rowid,
locgrp.ROWID locgrp_rowid,
cntry.ROWID cdcntry_rowid,
addrgrp.ROWID addrgrp_rowid,
addr.ROWID addr_rowid,
cnt.cont_id cont_id,
decode(cntry.name,'US',substr(addr.postal_code,1,5),addr.postal_code) postal_code,
cntry.name country,
UPPER(addr.addr_line_one) addr_line_one,
UPPER(addr.addr_line_two) addr_line_two,
UPPER(addr.addr_line_three) addr_line_three,
UPPER(addr.CITY_NAME) city_name,
UPPER(cnt.CONTACT_NAME) display_name,
UPPER(orgname.ORG_NAME) org_name,
addr.prov_state_tp_cd
FROM orgname,
contact cnt,
locationgroup locgrp,
cdcountrytp cntry,
addressgroup addrgrp,
address addr
WHERE locgrp.cont_id = orgname.cont_id
AND locgrp.cont_id = cnt.cont_id
AND addrgrp.location_group_id = locgrp.location_group_id
AND addr.country_tp_cd = cntry.country_tp_cd
AND addr.address_id = addrgrp.address_id
AND cnt.INACTIVATED_DT is null
AND locgrp.END_DT is null
AND orgname.END_DT is null
AND cnt.person_org_code = 'O'
AND cntry.lang_tp_cd = 100
AND locgrp.member_ind = 'Y'
AND locgrp.loc_group_tp_code = 'A'
ORDER by org_name,city_name,postal_code,country;This is the script that creates the preferences and then the context index.
exec ctx_ddl.create_preference('STEM_FUZZY_PREF', 'BASIC_WORDLIST');
exec ctx_ddl.set_attribute('STEM_FUZZY_PREF','FUZZY_MATCH','AUTO');
exec ctx_ddl.set_attribute('STEM_FUZZY_PREF','FUZZY_SCORE','60');
exec ctx_ddl.set_attribute('STEM_FUZZY_PREF','FUZZY_NUMRESULTS','100');
exec ctx_ddl.set_attribute('STEM_FUZZY_PREF','STEMMER','AUTO');
exec ctx_ddl.set_attribute('STEM_FUZZY_PREF', 'wildcard_maxterms',15000) ;
exec ctx_ddl.create_preference('LEXTER_PREF', 'BASIC_LEXER');
exec ctx_ddl.set_attribute('LEXTER_PREF','index_stems', 'ENGLISH');
exec ctx_ddl.set_attribute('LEXTER_PREF','skipjoins',',''."+/-&');
exec ctx_ddl.create_preference('ICV_WCC_INT_SEARCH_CTX_PREF', 'BASIC_STORAGE');
exec ctx_ddl.set_attribute('ICV_WCC_INT_SEARCH_CTX_PREF', 'I_TABLE_CLAUSE','tablespace ICV_TS_CTX_IDX');
exec ctx_ddl.set_attribute('ICV_WCC_INT_SEARCH_CTX_PREF', 'K_TABLE_CLAUSE','tablespace ICV_TS_CTX_IDX');
exec ctx_ddl.set_attribute('ICV_WCC_INT_SEARCH_CTX_PREF', 'N_TABLE_CLAUSE','tablespace ICV_TS_CTX_IDX');
exec ctx_ddl.set_attribute('ICV_WCC_INT_SEARCH_CTX_PREF', 'I_INDEX_CLAUSE','tablespace ICV_TS_CTX_IDX compress 2');
exec ctx_ddl.set_attribute('ICV_WCC_INT_SEARCH_CTX_PREF', 'P_TABLE_CLAUSE','tablespace ICV_TS_CTX_IDX');
exec ctx_ddl.set_attribute('ICV_WCC_INT_SEARCH_CTX_PREF', 'R_TABLE_CLAUSE','tablespace ICV_TS_CTX_IDX');
CREATE INDEX WCC_INT_SEARCH_CTX_I1 ON WCC_INTERNAL_SEARCH_M
(ORG_NAME)
INDEXTYPE IS CTXSYS.CTXCAT
PARAMETERS('Wordlist STEM_FUZZY_PREF
LEXER LEXTER_PREF
STORAGE ICV_WCC_INT_SEARCH_CTX_PREF');
DB is 10.2.0.3
Maybe you are looking for
-
Inspection lot creation for Movement type 531
Dear experts, following is the procedure 1) Material enter against purchase order SFG 2) Quality checks that and send to unrestricted (its an sampling inspection) 3) Issue this material against production order 4) order is confirmed and GR is done fo
-
Best practice for application module for scalability
if i compare application module with forms 6i runtime session.(correct me if i wrong) In forms 6i, we create for single form for purchase entry. in which we select table like po , po_item, item_master, customer master also single form for sales entry
-
Curve 9300 synching personal contacts has blocked work email address
Hi, I administer the cell phones for a small company. One of my new users sucessfully set-up his new BB Curve 9360's email with his work address last week. Over the weekend he synched his new phone with the contacts on his outlook at home which is at
-
Insufficient Shared Objects Memory Available
Hi Friends , You must be knowing sample application <b>wdr_test_chat</b> .I have used , executed application many time ....now when I run it and click in Log on ...log on pop up come and I am able to enter name ...but on click ok following dump comin
-
i never connent the ipod to the computer. my son change the passcode and forgot it .