Materialized view rows deletion
Hi all,
I have a question!
If the rows in master table are deleted on which a materialized view exist on a remote site, then the corresponding rows from materialized view will also be deleted on refresh?
Appreciate your help
IM
Great, so it means the total number of rows in master table and total number of rows in materialized view will remain same on refresh.
Thanks!
Edited by: user6885664 on Feb 26, 2012 8:29 PM
Similar Messages
-
Need help on tuning materialized view refresh
Hi All,
I am working on materialized view refresh tuning.Initially it was complete refresh and used to take more than 90 mins to complete.
I changed it to fast refresh now it is completing fast. Now i have partitioned the base tables gl_balances and gl_code_combinations of column code_combination_id and created a local index on column code_combination_id then i am trying to partition the materialized on the same column to take advantage of partition change tracking.
Size of gl_balances base tables is 40Gb and all others tables sizes are small. In where clause there all the 4 tables are mapped. If i will create the partition only on code_combination_id will i the materialized will become the candidate for partition change tracking. As i know it will be applicable for PCT. I need expert advice on this.
While doing a fast refresh. the refresh takes less time. when there is a change in gl_balances , gl_code_combinations or gl_periods it completes in 20-30 mins. When there is a change in gl_set_of_books tables. It creates a problem here.DEL query takes more than 48 hours to complete.
CREATE MATERIALIZED VIEW apps.BAL_PART
REFRESH FAST ON DEMAND
ENABLE QUERY REWRITE as
SELECT GL.GL_CODE_COMBINATIONS21.ROWID C1,GL.GL_BALANCES21.ROWID C2, GL.GL_SETS_OF_BOOKS.ROWID C3,
GL.GL_PERIOD.ROWID C4,
"GL"."GL_BALANCES21"."ACTUAL_FLAG" ,
"GL"."GL_BALANCES21"."CURRENCY_CODE" ,
"GL"."GL_BALANCES21"."PERIOD_NUM" ,
"GL"."GL_BALANCES21"."PERIOD_YEAR" ,
"GL"."GL_BALANCES21"."SET_OF_BOOKS_ID" "SOB_ID",
"GL"."GL_CODE_COMBINATIONS21"."CODE_COMBINATION_ID" "CCID",
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT1" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT10" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT11" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT12" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT13" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT14" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT2" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT3" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT4" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT5" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT6" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT7" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT8" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT9" ,
"GL"."GL_PERIODS"."PERIOD_NAME" ,
NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_CR", 0) Open_Bal_Cr,
NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_CR", 0) +
NVL("GL"."GL_BALANCES21"."PERIOD_NET_CR", 0) Close_Bal_Cr,
NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_DR", 0) Open_Bal_Dr,
NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_DR", 0) +
NVL("GL"."GL_BALANCES21"."PERIOD_NET_DR", 0) Close_Bal_Dr,
NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_DR", 0) -
NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_CR", 0) Open_Bal,
NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_DR", 0) -
NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_CR", 0) +
NVL("GL"."GL_BALANCES21"."PERIOD_NET_DR", 0) -
NVL("GL"."GL_BALANCES21"."PERIOD_NET_CR", 0) Close_Bal,
NVL("GL"."GL_BALANCES21"."PERIOD_NET_CR", 0) Period_Cr,
NVL("GL"."GL_BALANCES21"."PERIOD_NET_DR", 0) Period_Dr
FROM GL.GL_CODE_COMBINATIONS21,
GL.GL_BALANCES21,
GL.GL_SETS_OF_BOOKS,
GL.GL_PERIODS
WHERE GL.GL_BALANCES21.CODE_COMBINATION_ID =GL.GL_CODE_COMBINATIONS21.CODE_COMBINATION_ID
AND GL.GL_SETS_OF_BOOKS.SET_OF_BOOKS_ID = GL.GL_BALANCES21.SET_OF_BOOKS_ID
AND GL.GL_PERIODS.PERIOD_NUM = GL.GL_BALANCES21.PERIOD_NUM
AND GL.GL_PERIODS.PERIOD_YEAR = GL.GL_BALANCES21.PERIOD_YEAR
AND GL.GL_PERIODS.PERIOD_TYPE = GL.GL_BALANCES21.PERIOD_TYPE
AND GL.GL_PERIODS.PERIOD_NAME = GL.GL_BALANCES21.PERIOD_NAME
AND GL.GL_PERIODS.PERIOD_SET_NAME = GL.GL_SETS_OF_BOOKS.PERIOD_SET_NAME
and gl.GL_CODE_COMBINATIONS21.summary_flag != 'Y'TRACE 1046 del statement
DELETE FROM "APPS"."apps.BAL_PART" SNA$
WHERE "C3" IN (SELECT /*+ NO_MERGE */ * FROM (SELECT
CHARTOROWID("MAS$"."M_ROW$$") RID$ FROM "GL"."MLOG$_GL_SETS_OF_BOOKS"
"MAS$" WHERE "MAS$".SNAPTIME$$ > :B_ST1 ) AS OF SNAPSHOT(:B_SCN) MAS$)
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 17759.00 171782.99 159422121 1267371 2564144739 0
Fetch 0 0.00 0.00 0 0 0 0
total 2 17759.00 171782.99 159422121 1267371 2564144739 0
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 175 (APPS) (recursive depth: 1)
Rows Row Source Operation
0 DELETE apps.BAL_PART (cr=0 pr=0 pw=0 time=0 us)
193128740 NESTED LOOPS (cr=592437 pr=592422 pw=0 time=945244160 us cost=339302 size=168 card=1)
3 SORT UNIQUE (cr=7 pr=0 pw=0 time=15832 us cost=2 size=138 card=1)
24 TABLE ACCESS FULL MLOG$_GL_SETS_OF_BOOKS (cr=7 pr=0 pw=0 time=19 us cost=2 size=138 card=1)
193128740 INDEX RANGE SCAN C3BOOKS (cr=592430 pr=592422 pw=0 time=789499200 us cost=339299 size=3318314250 card=110610475)(object id 2114736)
error during execute of EXPLAIN PLAN statement
ORA-08187: snapshot expression not allowed here
parse error offset: 314
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 159520897 2.12 144415.96
latch: cache buffers chains 134 0.06 0.68
latch: undo global data 33 0.02 0.15
latch: object queue header operation 521 0.02 0.53
log file switch (private strand flush incomplete)
532 0.31 28.26
resmgr:cpu quantum 155 1.40 13.49
resmgr:internal state change 25 0.11 2.21
latch free 10 0.00 0.00
latch: cache buffers lru chain 4 0.00 0.00
rdbms ipc reply 489 0.02 0.54
reliable message 587 0.00 0.56
latch: row cache objects 3 0.00 0.00
********************************************************************************GL_SETS_OF_BOOKS has only 6 rows. I know there is complete refresh as a option which will again take more than 90 mins.
I want to do the fast refresh. Tables rows details below.
SQL> select count(*) from gl.gl_code_combinations21;
COUNT(*)
3075255
SQL> select count(*) from gl.GL_PERIODS;
COUNT(*)
1160
SQL> select count(*) from gl.gl_balances21;
COUNT(*)
477613527
SQL> select count(*) from gl.gl_sets_of_books;
COUNT(*)
6gl_sets_of_books has less rows. Whenever there is a change then it mapped to huge rows hence during materialized view has delete huge number of rows.
select count(*) from apps.BAL_PART group by C3;
C3 is the rowid which is present in create materialized statement.
COUNT(*)
292927011
210215
69330
184406971
Is there any way to improve the plan. As i created a partition on code_combination_id and local index on code_combination_id which will not help in set_of_books_id case. I dont PCT will help here or not. Is it possible to use PCT refresh by equipartitioning only one column in where clause.
Please assist me in improving refresh of materialized view using fast refresh.
Thanks and Regards,
Edited by: user646034 on Feb 23, 2013 11:13 PM
Edited by: user646034 on Feb 23, 2013 11:19 PM
Edited by: user646034 on Feb 23, 2013 11:46 PM
Edited by: user646034 on Feb 25, 2013 11:46 AMHi
The below explain without index and with index.
/* MV_REFRESH (DEL) */ DELETE FROM "APPS"."BAL_PART
" SNA$ WHERE "C3" IN (SELECT /*+ NO_MERGE */ * FROM (SELECT
CHARTOROWID("MAS$"."M_ROW$$") RID$ FROM
"GL"."MLOG$_GL_SETS_OF_BOOKS" "MAS$" WHERE "MAS$".SNAPTIME$$ > :B_ST1
) AS OF SNAPSHOT(:B_SCN) MAS$)
Plan hash value: 2704021294
| Id | Operation | Name | E-Rows |E-Bytes| Cost (%CPU)| E-Time |
| 0 | DELETE STATEMENT | | | | 339K(100)| |
| 1 | DELETE | BAL_PART | | | | |
| 2 | NESTED LOOPS | | 1 | 168 | 339K (1)|999:59:59 |
| 3 | SORT UNIQUE | | 1 | 138 | 2 (0)| 00:02:31 |
| 4 | TABLE ACCESS FULL| MLOG$_GL_SETS_OF_BOOKS | 1 | 138 | 2 (0)| 00:02:31 |
| 5 | INDEX RANGE SCAN | C3BOOKS | 110M| 3164M| 339K (0)|999:59:59 |
If i will not use the C3 index then the query will use the belolw plan, I guess this will also take same time or more time.
| 0 | DELETE STATEMENT | | | | 9743K(100)| |
| 1 | DELETE | BAL_PART | | | |   -
User_catalog - object listed as both 'TABLE' and 'MATERIALIZED VIEW'
SELECT * FROM USER_CATALOG ORDER BY OBJECT_NAME
returns ...
OBJECT_NAME OBJECT_TYPE
BLOBBY SYNONYM
BONUS TABLE
DEPT TABLE
EMP TABLE
EMPLOYEES SYNONYM
EMPWITHDEPT MATERIALIZED VIEW
EMPWITHDEPT TABLE
^^^^^^^^^^^^Any ideas to show only the 'MATERIALIZED VIEW' row for the above query?
Thanks in advance,
Mike NormanSo, I would need some sort of logic to
check if the OBJECT_NAME from user_objects
is present in user_snapshots print 'MATERIALIZED VIEW'
otherwise take the OBJECT_TYPE from user_objects -
some sort of DECODE? -
Hi,
I have created a materialized view, making a complete refresh ervery day at 1am.
It's possible that a query on this mview at refresh time will be empty will the query execute before and after the refresh wont be empty.
(The refresh will take about 60 Minutes to complete.)
Thanks.
regards,
RainersWhen you do a complete refresh a materialized view, Oracle deletes the old data and inserts the new data in a single transaction. Queries will never see the materialized view as empty-- the will see the old data until the refresh finishes, at which point they will see the new data.
Justin
Distributed Database Consulting, Inc.
http://www.ddbcinc.com/askDDBC -
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. -
Query against materialized view from stored procedure brings back empty row
I have a stored procedure that runs a query against a materialized view. When I run the query outside the SP it works just fine. When I change the MV to a table name, the SP works. When I change it back to the MV i get an empty row. Any ideas? The code is below:
PROCEDURE getAuth (p_naid IN NUMBER,
p_scope IN VARCHAR2,
o_xml_data OUT SYS_REFCURSOR
) IS
BEGIN
IF p_scope = 'Approved' THEN
OPEN o_xml_data FOR
SELECT naid,
p_naid,
auth_type,
xml_data
FROM some_mv
WHERE naid = p_naid;
RETURN;
CLOSE o_xml_data;
... the rest of the procedure ...does procedure contain EXCEPTION handler?
if so, then remove, delete & eliminate EXCEPTION handler (at least during testing & debugging) -
Materialized Views: how can I find the number of updates, inserts, delete
We are using Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Prod.
In a materialized view, with fast incremental refresh, done after every 5 minutes automatically, I want to store in a logging table the number of rows inserted,updated and deleted in the materialized view by that refresh.
One option is to create a job that should read the materialized view log table just before the refresh and store the required information in the logging table. But this information may not be accurate.
Is there any other way to collect this information for each refresh?Use auditing, or an before insert/update/delete trigger, that updates a counter
I hate myself for giving this advice, because it will bring you problems, with the MV update/refresh speed, table lock contention on the log-table....
Be carefull !!
Why not use auditing on the source table and why does anyone wants to know the number of changes??
Regards
FJFranken -
Oracle Materialized View | Deletion of Records, Oracle Materialized View
One question reg Materialized views.
If as part of housekeeping of the Source database we delete some records (older records), will the materialized view also be updated with the deletion?
I believe the answer is yes. In that case can we ensure that this delete does not happen?
Is there anyway we can prevent MView refresh from deleting the records that is once inserted even if we delete the same records in source DB?This is a common scenario, particularly with materialised views that summarise detail data where you want to keep the summary but not the detail, and it is addressed in the documentation.
The technique is to make the MV refresh on demand, delete the data from the detail tables, and use the CONSIDER_FRESH procedure to prevent the changes propagating to the MV. You'll probably find it in the docs by searching on DBMS_MView.Consider_Fresh. There are a few warnings to note I think. -
Multi-row Delete (MRD) on a view?
All,
I created a tabular form on a view, using an instead of trigger to encapsulate the logic for the data manipulations. Works great--until someone checks a row and hits the delete button, at which point APEX throws this error:
ORA-20001: Error in multi row delete operation: row= 107970-18527, ORA-06502: PL/SQL: numeric or value error: character to number conversion error,
Error multi row operation failedAs far as I can tell, it's not even getting to the trigger; I commented out the body of the instead of delete trigger (replacing it with null), and I'm still getting the same error. I have no validations or processes on the page at this point.
The underlying data of the view requires three columns for a unique identifier, so I've concatenated two of them together as an extra column in the view (creating a varchar2 column), and told the MRD to use the calculated column and the third column as the primary key columns. But even using two of the three numeric columns (tweaking the trigger to use a hard-coded value for the third) as an ID fails miserably.
Any idea what's going on?
Thanks,
-David
(In case it makes a difference, we're on APEX 4.0.1.)Hi David,
This might help:
http://oraclequirks.blogspot.com/2011/07/ora-20001-error-in-multi-row-delete.html
Hope it helps!
Regards,
Kiran -
Delete material view transaction MM06
Hi gurus
For error has been opened costing1 and costin2 material view for a material.
Is there any way to delete only two material views?
I have used transaction MM06 but deletes the material at plant level. Using transaction MM74 the modification should
have to be effected but i don't know to use MM74.
Can you help me?
Thanks in advanceit is not possible to delete views, deletion is only possible at organisation level. Costing is just a part of plant organisation, the fields are stored in table MARC.
if the material was not in use, then you can archive the plant level only with SARA (object MM_MATNR) after you have flagged the plant level for deletion in MM06.
then you can recreate the plant level without the unwanted views.
For archiving of individual org levels, you may have to implement an OSS note -
Whats the purpose of materialized view log?whats create view log with rowi
Why we create materialized view log ?????whats the use???
what do you mean by "create view log with rowid"
Regards
GaganA materialized view log stores the change vectors made to a particular table in order to allow materialized views that reference that table to be incrementally refreshed rather than re-materializing the data every time. It's a much more efficient way to refresh a materialized view.
WITH ROWID specifies that the materialized view log should store the ROWID of a row with the change vector, which is one way of identifying which row(s) in the materialized view should be updated by which change vector. You can also use the primary key value for this.
Justin -
Creating a Materialized View Log After the Data has been instered
Hi,
I am trying to create a method of replication from Oracle to MySQL using the Materialized View Log table.
This has been done before and works quite well, the only problem is that I am trying to impliment the log after the table has been created and populated and wish to push all the existing data through the log file...
Does anyone know if it is possible to refresh the Materialized View Log and not a Materialized View.
The way the replication is intended to work is:
Oracle> Data inserted into table
Oracle> writes the vector data to the MVL
Script> Monitors the MVL and can see the changes being made to the Oracle Table
Script> Updates MySQL with the data and removes the rows from the MVL
MySQL is then used with other unix systems
Currently we export the data from the table using Triggers and a cronjob running every x minute to check for changes in the TriggerTables
Many thanks for your time on this, I have been checking for almost a whole working day and not found the answer to this problem.Thats what I thought, the MVL will only read data that has changed since it was created and wont have the option to load in all the data as though it was made before the table was created.
From what I have read, the MVL is quicker than a Trigger and I have some free code that prooved to work from a MVL using it as a reference to know what records to update. There is not that much to a MVL, a record ID and type of update, New, Update or Delete.
I think what I will have to do is work on a the same principle for the MVL but use a Trigger as this way we can do a full reload if required at any point.
Many thanks for your help. -
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 -
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 -
BEST WAY TO REFRESH A MATERIALIZED VIEW
Hi, I have a Materialized View that was created after two Base Tables, Table A is a Dynamic Table, this means that it have Insert's, update's and delete's, and a Table B that is a Fixed Table, this means that this table do not change over time (it's a Date's Table). The size of the Table related to the Materialized View is to big (120 millions rows) so the refresh has to be very efficient in order to not affect the Data Base performance.
I was thinking on a Fast Refresh mode but It would not work because the log created on the B table is not usefull, the thing is that I created the two materialized view log's (Tables A and B) and when I execute the dbms_mview.refresh(list =>'MV', method => 'F')+ sentence I got the error
cannot use rowid column from materialized view log on "Table B" ... remember that this table don't change over time ...
I need to mantain the Materialized view up to date, but do not know how ... Please Help !!!!!The Materialized View name is test_sitedate2
The Table B name is GCO01.FV_DATES .... is a Fixed Table ... do not change over time ...
The Code of the MV is
CREATE MATERIALIZED VIEW TEST_SITEDATE2
REFRESH FORCE ON DEMAND
AS
SELECT site_id, date_stamp
FROM gco01.fv_site, gco01.fv_dates
where fv_dates.date_stamp >= fv_site.start_date
and fv_dates.date_stamp >= to_date('01/03/2010', 'dd/mm/yyyy')
and fv_dates.date_stamp < to_date('01/04/2010', 'dd/mm/yyyy');
Each table gco01.fv_site and gco01.fv_dates have it's materiallized view log created
The error is ....
SQL> execute dbms_mview.refresh(list =>'test_sitedate2', method => 'F');
begin dbms_mview.refresh(list =>'test_sitedate2', method => 'F'); end;
ORA-12032: cannot use rowid column from materialized view log on "GCO01"."FV_DATES"
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2254
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2460
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2429
ORA-06512: at line 1
Thank's
Maybe you are looking for
-
For some unknown reason I have two Apple ITunes/ID Accounts in operation. How do I completely delete one of these Accounts?
-
Ipod cannot connect with itunes
My iPod will not connect with iTunes, it doesn't even show up on iTunes. I know the cord is working because my ipod is charging, but I don't know what to do? Please help!
-
How To Enable a List Box To accept Multiple Selection
Dear all, How can I enable a List box to accept multiple selection.If any body can please help me. Thanks a bunch in advance Regards Rakesh
-
How do I eliminate snap.do from Firefox
Getting rid of this damned snap.do is driving me up a wall. Sure hope someone can help. I've run Regedit and eliminated one instance of snap.do. I've deleted the snap.do or snapdo cookies from Firefox many times but the cookies keep coming back. My p
-
Dump - DBIF_RSQL_NO_MEMORY
Hello , I am getting the dump DBIF_RSQL_NO_MEMORY . Please update me on this . Thanks , Rahul