Material view deletion

Hi
i have to delete some material master views for my material.
i have already tried to delete it by using MM06 tcode but its not helping me out. is there any other method by which i can achieve this?
thanks in anticipation

Dear,
First, flag the desired view tab for deletion using MM06, but still the view available during viewing the material. A message will be displayed when viewing or changing the material but the tab will still be visible. To totally remove the tab execute MM74 for archiving the desired tab deletion for this material only. Make sure you do not copy other materials or storage location..
Try this and I hope it will solve the issue.
Regards,
Syed Hussain.

Similar Messages

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.

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 PM

Checked 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.

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 advance

it 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

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

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

The data of my materialized view....in the while

Hello
We have problems with materialized views
We have one wich re-build each a short period of time
¿Can i avoid the data to dissapear in the time process of refresh?
Is so annoing to our clients to see that "from time to time" the data just dissapear for one period of time -the time while the materialized view is refreshing-
Thank you in advance
Bruno. Madrid. Spain

> Is so annoing to our clients to see that "from time to time" the data just dissapear for
one period of time -the time while the materialized view is refreshing-
Have a similar problem. And dealing with large data volumes that makes the DELETE of the MV a very undesirable feature. Not as much a the resource footprint required, but the time it takes to do this - and the very tight processing windows that exist.
The solution is a self-rolled and very likely not ideal for most - but it works well enough for us in production.
No MV. Create a partition table. Create a staging table. Do a manual "full refresh" of the staging table (TRUNCATE and direct path INSERT). Follow this by a partition exchange with the partition table (no validation and including indexes). The result is that the data is replaced in the partitioned table within a second - no long running and expensive DELETE. End-users not effected by having a truncate pulling the data from beneath their reports.

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,
Maciej

It 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

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 AM

Hi
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                          |       |            |          |

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

Fast Refresh on Materialized View With Join

Hi All,
i have created following Materialized View Logs and MV
on EMP and DEPT
CREATE MATERIALIZED VIEW LOG ON DEPT
WITH PRIMARY KEY,SEQUENCE
INCLUDING NEW VALUES;
CREATE MATERIALIZED VIEW LOG ON EMP
WITH PRIMARY KEY,SEQUENCE
INCLUDING NEW VALUES;
CREATE MATERIALIZED VIEW EMP_MVW
TABLESPACE OSMIS_REPORT_DATA
REFRESH FAST ON COMMIT
AS
SELECT A.EMPNO,A.ENAME,A.DEPTNO,A.JOB,A.MGR,A.HIREDATE,A.SAL,A.COMM,B.DNAME,B.LOC
FROM EMP A,DEPT B
WHERE A.DEPTNO=B.DEPTNO
The Create MV Stmnt raised following error.
ERROR at line 6:
ORA-12052: cannot fast refresh materialized view SCOTT.EMP_MVW
I have tried the same with ROWID also,but same error
while creating MV.
Pls anyone give idea to Fast Refersh on MV with Joins
Thnks
Raj.G.
mail : [email protected]

Actually you can get Oracle to tell you why the view does not have the capabilities you want using the DBMS_MVIEW package. For example you could have done something like this...
Personal Oracle Database 10g Release 10.1.0.2.0 - Production
With the Partitioning, OLAP and Data Mining options
SQL> CREATE MATERIALIZED VIEW LOG ON dept
2    WITH PRIMARY KEY, SEQUENCE
3      INCLUDING NEW VALUES;
Materialized view log created.
SQL> CREATE MATERIALIZED VIEW LOG ON emp
2    WITH PRIMARY KEY,SEQUENCE
3      INCLUDING NEW VALUES;
Materialized view log created.
SQL> CREATE MATERIALIZED VIEW emp_mvw
2    REFRESH FAST ON COMMIT
3 AS
4 SELECT a.empno, a.ename, a.deptno,
5         a.job, a.mgr, a.hiredate,
6         a.sal, a.comm, b.dname, b.loc
7 FROM   emp a,dept b
8 WHERE a.deptno = b.deptno;
FROM   emp a,dept b
ERROR at line 7:
ORA-12052: cannot fast refresh materialized view SCOTT.EMP_MVW
SQL> CREATE MATERIALIZED VIEW emp_mvw
2    REFRESH ON COMMIT -- remove the FAST to allow view to compile
3 AS
4 SELECT a.empno, a.ename, a.deptno,
5         a.job, a.mgr, a.hiredate,
6         a.sal, a.comm, b.dname, b.loc
7 FROM   emp a,dept b
8 WHERE a.deptno = b.deptno;
Materialized view created.
SQL> @\oracle\product\10.1.0\Db_1\RDBMS\ADMIN\utlxmv.sql -- create mv_capabilities_table
Table created.
SQL> EXEC DBMS_MVIEW.EXPLAIN_MVIEW ('EMP_MVW');
PL/SQL procedure successfully completed.
SQL> SELECT capability_name, possible, msgtxt
2 FROM   mv_capabilities_table
3 WHERE capability_name LIKE '%REFRESH_FAST_AFTER%';
CAPABILITY_NAME                P MSGTXT
REFRESH_FAST_AFTER_INSERT      N the SELECT list does not have the rowids of all the detail tables
REFRESH_FAST_AFTER_INSERT      N mv log must have ROWID
REFRESH_FAST_AFTER_INSERT      N mv log must have ROWID
REFRESH_FAST_AFTER_ONETAB_DML N see the reason why REFRESH_FAST_AFTER_INSERT is disabled
REFRESH_FAST_AFTER_ANY_DML     N see the reason why REFRESH_FAST_AFTER_ONETAB_DML is disabled
SQL> DROP MATERIALIZED VIEW LOG ON dept;
Materialized view log dropped.
SQL> DROP MATERIALIZED VIEW LOG ON emp;
Materialized view log dropped.
SQL> DROP MATERIALIZED VIEW emp_mvw;
Materialized view dropped.
SQL> CREATE MATERIALIZED VIEW LOG ON dept
2    WITH ROWID, SEQUENCE
3      INCLUDING NEW VALUES;
Materialized view log created.
SQL> CREATE MATERIALIZED VIEW LOG ON emp
2    WITH ROWID,SEQUENCE
3      INCLUDING NEW VALUES;
Materialized view log created.
SQL> CREATE MATERIALIZED VIEW emp_mvw
2    REFRESH FAST ON COMMIT
3 AS
4 SELECT a.ROWID emp_rowid, b.ROWID dept_rowid,
5         a.empno, a.ename, a.deptno,
6         a.job, a.mgr, a.hiredate,
7       a.sal, a.comm, b.dname, b.loc
8 FROM   emp a,dept b
9 WHERE a.deptno = b.deptno;
Materialized view created.
SQL> DELETE mv_capabilities_table;
18 rows deleted.
SQL> EXEC DBMS_MVIEW.EXPLAIN_MVIEW ('EMP_MVW');
PL/SQL procedure successfully completed.
SQL> SELECT capability_name, possible, msgtxt
2 FROM   mv_capabilities_table
3 WHERE capability_name LIKE '%REFRESH_FAST_AFTER%';
CAPABILITY_NAME                P MSGTXT
REFRESH_FAST_AFTER_INSERT      Y
REFRESH_FAST_AFTER_ONETAB_DML Y
REFRESH_FAST_AFTER_ANY_DML     Y
SQL>

Fast refresh of materialized view on remote database

Hi All,
I have the following scenario, two databases called ORCL_1 and ORCL_2
ORCL_1 (11.1.0.7) ORCL_2 (10.2.0.1)
EMPLOYEE (Master table)
DEPARTMENT (Master table)
I have created materialied view logs on both the master tables as follows...
create materialized view log on department
with rowid, sequence(department_id, department_name)
including new values
create materialized view log on employee
with rowid, sequence (employee_no, surname, firstname, title, department_id, dob, dependants)
including new values
On ORCL_1 i have created a materialized view as follows...
create materialized view employee_mview
build immediate
refresh on demand with rowid
as select e.employee_no, e.title, e.firstname, e.surname, d.department_name, d.department_id, e.dob, e.dependants, e.rowid emp_rowid, d.rowid dept_rowid
from employee@ORCL_2 e,
department@ORCL_2 d
where e.department_id = d.department_id
then i have a scheduled task, on ORCL_1, that execute "...dbms_mview.refresh ('mac_dba.employee_mview','?');...." every minute
this works fine, except for the fact that all the records are deleted from the materialized view and then all the records are re-inserted.
How can i get it so that only the records that have been added or amended, as per the materialized view logs, are refreshed to the materialized view.
thanks
Mel

Hi Harry,
Have tried creating materialized view as follows...
create materialized view mac_dba.employee_mview
build immediate
refresh fast on demand with rowid
as select e.employee_no, e.title, e.firstname, e.surname, d.department_name, d.department_id, e.dob, e.dependants, e.rowid emp_rowid, d.rowid dept_rowid
from mac_dba.employee@ORCL_2 e,
mac_dba.department@ORCL_2 d
where e.department_id = d.department_id
I get the following error message
ORA-12028: materialized view type is not supported by master site
thanks
Mel

Materialized View to external dB

I want to create a materialized view in 8.1.6 from an external dB (MS Access)using the Generic data access (Generic OTG), but cannot find documentation that tells me how to use the Generic OTG. The MS Access data can not be permanently brought into Oracle since it is part of another application, but is needed in Oracle for further analysis. Where is the documentation for the Generic OTG?

Hi,
Materialized views are schema objects that can be used to summarize, compute, replicate, and distribute data. They are suitable in various computing environments such as data warehousing, decision support, and distributed or mobile computing:
In distributed environments, materialized views are used to replicate data at distributed sites and synchronize updates done at several sites with conflict resolution methods. The materialized views as replicas provide local access to data that otherwise has to be accessed from remote sites.
Materialized views are similar to indexes in several ways:
They consume storage space.
They must be refreshed when the data in their master tables changes.
They improve the performance of SQL execution when they are used for query rewrites.
Their existence is transparent to SQL applications and users.
Unlike indexes, materialized views can be accessed directly using a SELECT statement. Depending on the types of refresh that are required, they can also be accessed directly in an INSERT, UPDATE, or DELETE statement.
A materialized view can be partitioned. You can define a materialized view on a partitioned table and one or more indexes on the materialized view
A materialized view contains a complete or partial copy of a target master from a single point in time. The target master can be either a master table at a master site or a master materialized view at a materialized view site. A master materialized view is a materialized view that functions as a master for another materialized view. A multitier materialized view is one that is based on another materialized view, instead of on a master table.
It requires lot of experience thats it.
Regards
vinod

Material view deletion

Similar Messages

Maybe you are looking for