Issue in Materialized view

Hi,
Am facing the below issue while creating MV,
create materialized view log on a;
cretae materialized view log ob b;
create materialized view
refresh fast on commit
as
select a.x,a.y,b.z
from a,b
where
a.i=b.i and
a.bill_dt > trunc(add_months(sysdate,-12),'month');
And am getting ORA-12054 Kindly suggest me how can achive this?
Thanks,
Siva

I don't really have a good idea, sorry.
If an MV can be partitioned, then maybe monthly partitioning on the MV could be an option. But I guess (I do not know for certain) that an MV would not support dropping old partions.
An alternative solution (but it is somewhat a kludge) would be an MV that refreshes complete every night (no refresh fast on commit, no MV logs.) Then you create a view that selects from the MV all data before today and uses union all to a select that queries the base tables for todays data. It will not be as fast to query as an MV refresh on commit, but it might be fast enough?
I do not see another way - but maybe some other forum user has a good idea? ;-)

Similar Messages

Performace issue on MATERIALIZED view

Hi Gurus,
Need help to understand perfoamance issue on MATERIALIZED view. I have created mat view on some big table of 76GB. Mat view is of 25 GB.
I have refreshed mat view before running report. In OEM it ish showng going for full table scan and estimated time is of 2 hrs where full tablescan on base table on which mat view is created is of 20 Mins . I am using fast refresh on demand .
We are using Oracle 10.2.0.4 on Sun Sprac 64bit 10 platform and version.
Could you please let me know what could be the reason why mat views are performing poor ?
Thanks & Regards

You have MLOG created on your master table, right?
OK, then check DBA_MVIEWS. Look for LAST_REFRESH_TYPE, If everything is OK, i should be FAST.
If everything is OK by now, the problem can be the nature of master table. If there is great amount of changes in master table, set periodic job which will do refresh often (since 'often' is fuzzy word, it can be every 5, 10, 30 minutes...). Incremental refresh will perform beter if there is small amount of changes in MLOG table!
You can check your MLOG table. If it is huge (size in MB) and there is only few records in it, try to realocate the space issuing "ALTER TABLE MLOG$_table_name;"
Hope something will be helpfull...
Best regards

Issue with Materialized View ORA-08103: object no longer exists

I have a materialized view which gets refreshed(COMPLETE Refresh) every 2 minutes. However there are few scheduled programs which queries this materialized view, some of the queries in the scheduled program take longer to run. When the materialized view refresh time overlaps with this query executing from the program i get this error: ORA-08103: object no longer exists.
I know that COMPLETE refresh doing TRUNCATE + INSERT is causing the issue, could someone suggest a workaround for this. But i need to do a COMPLETE refresh.

Why would a TRUNCATE cause an "object no longer exists" ?
Which job encounters this error ? The MV Refresh job or the programs that are querying the MV ? How does it resolve ? Automatically -- meaning that the next refresh/query does not raise the error ?

Performance issue accessing Materialized Views

Hi All
I am extracting source data from Materialized View through DBLink which is having record count of 1500000 rows.
But its taking lot of time(Approx. 30-45 min) during loading.
Is there any other way to load the data in a faster way??
regards
Gourisankar

Hi,
I take it the simple 'Select from "materialized view' doesn't take this long. This could be down to the issue when issuing an 'INSERT' statement using a database link, even if you use the Optimizer hint 'DRIVING_SITE' does not help. The problem is that when issuing an INSERT statement using a DB LINK the filtering of records does not happen on the far side of the link. All the data is moved across the link to the target db, and then filtered etc.
One way to get round this is to use a pipelined function to run your select to get your values, then call the pipeline function via ODI.
Still use the DIRVING_SITE optimizer hint in the pipelined function when selecting your data.
Cheers
Bos

Issue with materialized view and fast refresh between Oracle 10g and 11g

Hi all,
I've hit a problem when trying to create a fast-refreshable materialized view.
I've got two databases, one 10.2.0.10, another 11.2.0.1.0, running on 32-bit Windows. Both are enterprise edition, and I'm trying to pull data from the 10g one into the 11g one. I can happily query across the database link from 11g to 10g, and can use complete refresh with no problem except the time it takes.
On the 10g side, I've got tables with primary keys and m.v. logs created, the logs being of this form ...
CREATE MATERIALIZED VIEW LOG ON table WITH PRIMARY KEY INCLUDING NEW VALUES
On the 11g side, when I try to create an m.v. against that ...
CREATE MATERIALIZED VIEW mv_table REFRESH FAST WITH PRIMARY KEY AS SELECT col1, col2 FROM table@dblink;
... I get an ORA-12028 error (materialized view type is not supported by master site).
After running the EXPLAIN_MVIEW procedure it shows this;
REFRESH_FAST_AFTER_INSERT not supported for this type mv by Oracle version at master site
A colleague has managed to build a fast-refresh m.v. from the same source database, but pulling to a different one than I'm using; his target is also 10g, like the (common) source, so I've no idea why I'm getting the 'not supported' message whilst he isn't.
I've been able, on previous projects, to do exactly what I'm trying to achieve but on those someone with more knowledge than me has configured the database!
I'm now stumped. I'm also no DBA but despite that it's been left to me to install the new 11g database on the 32-bit Windows server from scratch, so there are probably a couple of things I'm missing. It's probably something really obvious but I don't really know where to look now.
If anyone can give me any pointers at all, I'd be really grateful. This question is also duplicated in the Replication forum but hasn't had any replies as yet, so I'm reproducing it here in hope!
Thanks in advance,
Steve

Hi Steve,
You should have a look at metalink, Doc ID 1059547.1
If that does not help, there may be something else in Mater note ID 1353040.1
Best regards
Peter

Fast Refresh Materialized View - failure

Okay, this issue currently has me stumped. I searched the world wide web and still cannot seem to identify the cause of this issue.
Here is the scenario:
I created a materialized view log for the source table (let's say table1) found at DB1.
I then create a materialized view (fast refresh, with logging) at a remote database (let's say DB2). The query for the MV is basic: select * from schema1.table1@db1_link;
I set the materialized view to refresh every 30 seconds (for testing purposes).
This creates a dbms job that executes every 30 seconds. The materialized view gets created successfully. I purposely enter new data into table1. The materialized view log for table1 successfully captures these changes. However, the materialized view found at DB2 does not get refreshed (updated) successfully.
In fact, the dbms job errors-out. It keeps failing and failing. After 16 times, it gets marked as 'broken.'
The error message is as such:
RDBA WARNING: ORA-12012: error on auto execute of job 1472
RDBA WARNING: ORA-00604: error occurred at recursive SQL level 3
RDBA WARNING: ORA-01017: invalid username/password; logon denied
RDBA WARNING: ORA-02063: preceding line from db1
RDBA WARNING: ORA-06512: at "SYS.DBMS_SNAPSHOT", line 820
RDBA WARNING: ORA-06512: at "SYS.DBMS_SNAPSHOT", line 877
RDBA WARNING: ORA-06512: at "SYS.DBMS_IREFRESH", line 683
RDBA WARNING: ORA-06512: at "SYS.DBMS_REFRESH", line 195
RDBA WARNING: ORA-06512: at line 1
The strange thing is, that the error supposedly claims invalid username/password. But I've used the db links successfully before & the username/password is not invalid. Has anyone encountered this issue before?

Justin,
From reading earlier posts about issues with materialized views, I remember reading something about materialized views (fast refreshable) not working with sysdate. What did you mean by such a statement? (I would copy & paste it here, but I am unable to find it at the moment).
The reason I am curious, is the fact that I am setting my MV to refresh every 30 seconds let's say (for testing). At this moment - it starts failing & failing & failing.

Materialized view failure

Hello,
I am facing issue with Materialized views having Complete refresh option. When I run the below Query during the duration when Materialized view refresh is happening:
Select * from USER_JOBS;
I am seeing some numeric value in the failures column. How can I get more info on the failure?
Thanks.

Please check the alert.log file.

Issue with creation of a materialized view

Hi,
I have a SQL query that works fine.
But when I create a materialized view using the query, a few columns in the MV do not get populated at all.
What could be the issue here?
regards
Prem

Hi,
Thanks for the reply. Here is the code.
CREATE MATERIALIZED VIEW EDW.MV_OPPTY_ACTIVITY_AGG
TABLESPACE EDW_DIM_DAT
NOCACHE
LOGGING
NOCOMPRESS
NOPARALLEL
BUILD IMMEDIATE
REFRESH COMPLETE ON DEMAND
WITH PRIMARY KEY
AS
select
OPPTY_ID OPPTY_ID,
OPPORTUNITY_KEY OPPORTUNITY_KEY,
oppty_number oppty_number ,
SALES_CONSULTANT_HIST_KEY SALES_CONSULTANT_HIST_KEY ,
company_add_source_key company_add_source_key,
SALES_CONSULTANT_ID SALES_CONSULTANT_ID,
ACTIVITY_TYPE ACTIVITY_TYPE ,
activity_DATE activity_DATE ,
LAST_MODIFIED_DATE LAST_MODIFIED_DATE ,
CUSTOMER_FLAG CUSTOMER_FLAG,
SALES_EMPLOYEE_HIST_KEY,
milestone_KEY,
oppty_milestone_name_hist stage_name,
oppty_milestone_id_hist stage_id,
milestone_prob prob_to_close,
start_date oppty_start_date,
oppty_close_date oppty_close_date,
end_date oppty_end_date,
sum(DURATION) TOTAL_DURATION,
sum (CASE WHEN ACTIVITY_type IN ('CU14', 'CU15', 'CU16', 'CU17',
'CU18', 'CU19', 'CU20', 'CU21') THEN DURATION ELSE 0 END ) CQM_DURATION,
sum (CASE WHEN ACTIVITY_type = 'CU01' THEN DURATION ELSE 0 END ) TRADE_SEM_DURATION,
sum( CASE WHEN ACTIVITY_type = 'CU02' THEN DURATION ELSE 0 END ) RFP_RFI_DURATION,
sum( CASE WHEN ACTIVITY_type = 'CU03' THEN DURATION ELSE 0 END ) INFO_GATH_DURATION,
sum( CASE WHEN ACTIVITY_type = 'CU04' THEN DURATION ELSE 0 END ) PREP_DURATION,
sum( CASE WHEN ACTIVITY_type = 'CU05' THEN DURATION ELSE 0 END ) PRES_DEMO_DURATION,
sum( CASE WHEN ACTIVITY_type = 'CU06' THEN DURATION ELSE 0 END ) POC_DURATION,
sum ( CASE WHEN ACTIVITY_type = 'CU07' THEN DURATION ELSE 0 END ) PRE_CUST_SUPP_DURATION,
sum( CASE WHEN ACTIVITY_type = 'CU08' THEN DURATION ELSE 0 END ) POST_CUST_SUPP_DURATION,
sum( CASE WHEN ACTIVITY_type = 'CU09' THEN DURATION ELSE 0 END ) PARTNER_SUPP_DURATION,
sum( CASE WHEN ACTIVITY_type = 'CU10' THEN DURATION ELSE 0 END ) TRAVEL_DURATION,
sum( CASE WHEN ACTIVITY_type = 'CU11' THEN DURATION ELSE 0 END ) KEYCODES_DURATION,
sum( CASE WHEN ACTIVITY_type = 'CU12' THEN DURATION ELSE 0 END ) SI_SUPP_DURATION,
sum ( CASE WHEN ACTIVITY_type = 'CU13' THEN DURATION ELSE 0 END ) CHANNEL_SUPP_DURATION,
sum( CASE WHEN ACTIVITY_type = 'CU23' THEN DURATION ELSE 0 END ) MIGRATION_DURATION ,
max(LICENSE_USD) LICENSE_USD ,
MAX(LICENSE_LOCAL) LICENSE_LOCAL,
MAX(maintAINANCE_usd) maintAINANCE_usd,
MAX(maintAINANCE_LOCAL) maintAINANCE_LOCAL,
MAX(TRAINING_USD) training_usd,
MAX(TRAINING_LOCAL) training_LOCAL,
MAX(CONSULTING_USD) consulting_usd,
MAX(CONSULTING_LOCAL) consulting_LOCAL,
MAX(RENEWALS_USD) renewals_usd ,
MAX(RENEWAL_local) RENEWAL_local,
max(LOBANALYTICS2_LOCAL) epm_local,
max(LOBDATAINTEGRATION2_LOCAL) eim_local,
max(IDD_AMOUNT_LOCAL) idd_local,
max(ONDEMAND_AMOUNT_LOCAL) ondemand_local,
max(LOBANALYTICS2_usd) epm_usd,
max(LOBDATAINTEGRATION2_usd) eim_usd,
max(IDD_AMOUNT_usd) idd_usd,
max(ONDEMAND_AMOUNT_usd) ondemand_usd
FROM edw.sales_consulting_activity_fct t1 ,
select
o.oppty_id_number,
o.oppty_id,
O.OPPORTUNITY_KEY,
LICENSE_USD LICENSE_USD ,
LICENSE_LOCAL LICENSE_LOCAL,
o.FYM_USD maintAINANCE_usd,
o.FYM_LOCAL maintAINANCE_LOCAL,
o.TRAINING_USD training_usd,
o.TRAINING_LOCAL training_LOCAL,
o.CONSULTING_USD consulting_usd,
o.CONSULTING_LOCAL consulting_LOCAL,
o.RENEWAL_USD renewals_usd ,
o.RENEWAL_local RENEWAL_local ,
o.LOBANALYTICS2_LOCAL,
o.LOBANALYTICS2_usd,
o.LOBDATAINTEGRATION2_LOCAL,
o.IDD_AMOUNT_LOCAL,
o.ONDEMAND_AMOUNT_LOCAL,
o.LOBDATAINTEGRATION2_usd,
o.IDD_AMOUNT_usd,
o.ONDEMAND_AMOUNT_usd
from edw.opportunity_hist_fact o
where o.SOURCE_SYSTEM='SFDC'
and upper(status)='ACTIVE'
and o.last_modified_date = (select max(last_modified_date )from edw.opportunity_hist_fact o2 where o.opportunity_key = o2.opportunity_key))T2,
( Select activity_key,OPPTY_ID_NUMBER, MIL.milestone_KEY,MIL.milestone_name oppty_milestone_name_hist,milestone_id
oppty_milestone_id_hist, milestone_prob,start_date,oppty_close_date,end_date FROM
EDW.opportunity_hist_fact OPP,
edw.milestone MIL,
edw.sales_consulting_activity_fct act WHERE
ACTIVITY_DATE >=start_date (+) and activity_date <=opp.last_modified_date(+)
and OPP.OPPTY_ID_NUMBER (+) =act.OPPTY_NUMBER
and OPP.milestone_key =MIL.milestone_key(+) ) T3
where t1.oppty_NUMBER (+) =T2.OPPTY_ID_NUMBER
and t1.activity_key=t3.activity_key
--and oppty_number ='279749'
GROUP BY OPPTY_ID,
oppty_number,
OPPORTUNITY_KEY,
SALES_CONSULTANT_HIST_KEY ,
company_add_source_key,
SALES_CONSULTANT_ID,
SALES_EMPLOYEE_HIST_KEY,
ACTIVITY_TYPE ,
ACTIVITY_DATE ,
LAST_MODIFIED_DATE,
CUSTOMER_FLAG,
milestone_KEY,
oppty_milestone_name_hist,
oppty_milestone_id_hist,
milestone_prob,
start_date,
oppty_close_date,
end_date;
Regards,
Prem

Issue with complete refresh on materialized view when using rownum

Hi all,
I had an issue with rownum when using complete refresh
I am using rownum when creating materialized view and it is generation correctly.But the issue was when i am refreshing the same ,rownum was not getting sorted in ascending order.
anyone had come across this scenario

rownum is determined as the row is output, so "order by rownum" does literally nothing.
http://docs.oracle.com/cd/B19306_01/server.102/b14200/pseudocolumns009.htm

Materialized view logs issue

We are having issues with the size of materialized view logs in one od the database. The size of the log table is around 32G. Will appreciate if somebody will help in explaining why it is having such a huge size and is not getting purged.
At the same time the master table is having comparatively smaller size of 18G(did not check table fragmentation).
Also, please help me in understanding what is required to be done for fixing this issue.
SQL> select LOG_OWNER,MASTER,LOG_TABLE,LOG_TRIGGER,PRIMARY_KEY from dba_mview_logs where log_owner='MARTDATA' and MASTER='POLICY_CONFIGURATION';
LOG_OWNER MASTER LOG_TABLE LOG_TRIGGER PRI
MARTDATA POLICY_CONFIGURATION MLOG$_POLICY_CONFIGURATION NO
SQL> select owner, segment_name, sum(bytes)/1024/1024 "SIZE in MB" from dba_segments where segment_name='POLICY_CONFIGURATION' and owner ='MARTDATA' group by owner, segment_name;
OWNER SEGMENT_NAME SIZE in MB
MARTDATA POLICY_CONFIGURATION 18458
SQL> select owner, segment_name, sum(bytes)/1024/1024 "SIZE in MB" from dba_segments where segment_name='MLOG$_POLICY_CONFIGURATION' and owner ='MARTDATA' group by owner, segment_name;
OWNER SEGMENT_NAME SIZE in MB
MARTDATA MLOG$_POLICY_CONFIGURATION 32298
Thanks

Oracle automatically purges rows in the materialized view log when they are no longer needed. Because Oracle must wait for all dependent materialized views to refresh before purging rows from a materialized view log, unwanted situations can occur that cause a materialized view log to grow indefinitely when multiple materialized views are based on the same master table or master materialized view.
For example, such situations can occur when more than one materialized view is based on a master table or master materialized view and one of the following conditions is true:
Materialized view is not configured for automatic refreshes and has not been manually refreshed for a long time. OR
Materialized view has an infrequent refresh interval, such as every year, etc
You can also refresh the materialized views associated with the log so that Oracle can purge rows from the materialized view log.
If a materialized view log needs to be purged manually for some reason a procedure called DBMS_MVEW.PURGE_LOG can be used.
Edited by: user130038 on Sep 30, 2011 6:49 AM

Issue with creating materialized view

Hi,
We have a select query (containing joins, aggregates and UNION ALL’s) using which we are creating materialized views. We were able to create these mat views in development environment, however when tried to run the same scripts in a higher environment the creation never completes. The higher environment has three times more data than in Dev currently.
The below operations complete well in time , but when we add “CREATE MATERIALIZED VIEW MAT_VIEW_NAME” to the select query it takes forever (we have cancelled the operation after waiting for more 1 hour)
Select count(1) from the complete Mat. View query -     takes 3.2 min to complete - the query resullts in      3,010,068 rows
Create Normal VIEW using complete Mat. View select query -     takes      3.06 sec     to complete
Create table using complete Mat. View select query     takes 5.75 min to complete - the query resullts in           3,010,068
Does anyone have an idea why this could be happening ? if you have ever faced this kind of issue, can you please provide pointers on how you were able to solve the problem. We are using Oracle 11g.
Let me know if I have to provide any other information for you to understand the issue better.
Thanks

SELECT vis.uid, findet.yr, findet.ect, vis.ind,
tm_view.col1_id, tm_view.col1_name,
tm_view.col2_id, tm_view.col2_name,
tm_view.col3_id, tm_view.col3_name,
clnt.cl_id, clnt.cl_nm,
prodparent_view.parent_cd,
prodparent_view.parent_desc,
prod_view.parent_cd,
prod_view.parent_desc,
prod_view.child_cd,
prod_view.child_desc,
SUM (value1), SUM (value2),
SUM (value3), SUM (value4),
SUM (value5), SUM (value6),
SUM (value7), SUM (value8),
SUM (value9), SUM (value10),
SUM (value11), SUM (value12)
FROM vis,
(SELECT *
FROM analytic_e,
(SELECT table_val
FROM TAB_CHECK s
WHERE s.tgt_table_nm = 'ANALYTIC'
AND s.table_val = 'ANALYTIC_E')
WHERE table_val = 'ANALYTIC_E'
UNION ALL
SELECT *
FROM analytic_o,
(SELECT switch_val
FROM tab_check s
WHERE s.tgt_table_nm = 'ANALYTIC'
AND s.switch_val = 'ANALYTIC_O')
WHERE switch_val = 'ANALYTIC_O') findet,
prod_view,
prodparent_view,
tm_view,
clnt,
(select to_number(to_char(ref_dt,'yyyy'))-1 year_agg from DATE_TABLE) tbabt
WHERE tbabt.yr = findet.yr
AND vis.cl_key = findet.cl_key
AND tm_view.hi_key = findet.hi_key
AND prod_view.child_cd = findet.prod_cd
AND clnt.cl_key = findet.cl_key
AND prodparent_view.child_cd = prod_view.parent_cd
GROUP BY vis.uid, findet.yr, findet.ect, vis.ind,
tm_view.col1_id, tm_view.col1_name,
tm_view.col2_id, tm_view.col2_name,
tm_view.col3_id, tm_view.col3_name,
clnt.cl_id, clnt.cl_nm,
prodparent_view.parent_cd
prodparent_view.parent_desc
prod_view.parent_cd
prod_view.parent_desc
prod_view.child_cd
prod_view.child_desc
Higher Environment
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 57M| 65G| | 20M (1)| 66:48:28 | | |
| 1 | HASH GROUP BY | | 57M| 65G| 73G| 20M (1)| 66:48:28 | | |
|* 2 | HASH JOIN | | 57M| 65G| | 109K (2)| 00:21:58 | | |
| 3 | TABLE ACCESS BY INDEX ROWID | HIER | 2100 | 244K| | 172 (0)| 00:00:03 | | |
|* 4 | INDEX RANGE SCAN | UK_HIER | 2100 | | | 16 (0)| 00:00:01 | | |
|* 5 | HASH JOIN | | 57M| 59G| | 109K (1)| 00:21:52 | | |
| 6 | VIEW | VW_GBF_25 | 1908 | 868K| | 2612 (1)| 00:00:32 | | |
| 7 | HASH GROUP BY | | 1908 | 141K| | 2612 (1)| 00:00:32 | | |
| 8 | VIEW | | 45107 | 3347K| | 2609 (1)| 00:00:32 | | |
| 9 | UNION-ALL | | | | | | | | |
| 10 | HASH UNIQUE | | 22518 | 1473K| 1872K| 1010 (1)| 00:00:13 | | |
|* 11 | TABLE ACCESS FULL | HIER | 22518 | 1473K| | 650 (1)| 00:00:08 | | |
| 12 | HASH UNIQUE | | 22518 | 1165K| 1512K| 947 (1)| 00:00:12 | | |
|* 13 | TABLE ACCESS FULL | HIER | 22518 | 1165K| | 650 (1)| 00:00:08 | | |
| 14 | HASH UNIQUE | | 71 | 1917 | | 652 (1)| 00:00:08 | | |
|* 15 | TABLE ACCESS FULL | HIER | 22518 | 593K| | 650 (1)| 00:00:08 | | |
|* 16 | HASH JOIN | | 64M| 38G| 4936K| 106K (1)| 00:21:16 | | |
| 17 | VIEW | | 45107 | 4404K| | 2609 (1)| 00:00:32 | | |
| 18 | UNION-ALL | | | | | | | | |
| 19 | HASH UNIQUE | | 22518 | 1473K| 1872K| 1010 (1)| 00:00:13 | | |
|* 20 | TABLE ACCESS FULL | HIER | 22518 | 1473K| | 650 (1)| 00:00:08 | | |
| 21 | HASH UNIQUE | | 22518 | 1165K| 1512K| 947 (1)| 00:00:12 | | |
|* 22 | TABLE ACCESS FULL | HIER | 22518 | 1165K| | 650 (1)| 00:00:08 | | |
| 23 | HASH UNIQUE | | 71 | 1917 | | 652 (1)| 00:00:08 | | |
|* 24 | TABLE ACCESS FULL | HIER | 22518 | 593K| | 650 (1)| 00:00:08 | | |
|* 25 | HASH JOIN | | 3021K| 1550M| 15M| 24492 (1)| 00:04:54 | | |
| 26 | PARTITION HASH ALL | | 491K| 10M| | 1059 (1)| 00:00:13 | 1 | 16 |
| 27 | MAT_VIEW ACCESS FULL | VIS | 491K| 10M| | 1059 (1)| 00:00:13 | 1 | 16 |
|* 28 | HASH JOIN | | 388K| 190M| 6056K| 12929 (1)| 00:02:36 | | |
| 29 | TABLE ACCESS FULL | CLNT | 64540 | 5294K| | 411 (1)| 00:00:05 | | |
|* 30 | HASH JOIN | | 388K| 159M| | 4072 (1)| 00:00:49 | | |
| 31 | TABLE ACCESS FULL | DATE_TABLE | 2 | 16 | | 3 (0)| 00:00:01 | | |
| 32 | VIEW | | 582K| 235M| | 4065 (1)| 00:00:49 | | |
| 33 | UNION-ALL | | | | | | | | |
| 34 | NESTED LOOPS | | 272K| 52M| | 1860 (1)| 00:00:23 | | |
|* 35 | TABLE ACCESS BY INDEX ROWID| TAB_CHECK | 1 | 46 | | 1 (0)| 00:00:01 | | |
|* 36 | INDEX UNIQUE SCAN | SYS_C0041157 | 1 | | | 0 (0)| 00:00:01 | | |
| 37 | PARTITION RANGE ALL | | 272K| 40M| | 1859 (1)| 00:00:23 | 1 |1048575|
| 38 | TABLE ACCESS FULL | ANALYTIC_E | 272K| 40M| | 1859 (1)| 00:00:23 | 1 |1048575|
| 39 | NESTED LOOPS | | 309K| 58M| | 2205 (1)| 00:00:27 | | |
|* 40 | TABLE ACCESS BY INDEX ROWID| TAB_CHECK | 1 | 46 | | 1 (0)| 00:00:01 | | |
|* 41 | INDEX UNIQUE SCAN | SYS_C0041157 | 1 | | | 0 (0)| 00:00:01 | | |
| 42 | PARTITION RANGE ALL | | 309K| 44M| | 2204 (1)| 00:00:27 | 1 |1048575|
| 43 | TABLE ACCESS FULL | ANALYTIC_O | 309K| 44M| | 2204 (1)| 00:00:27 | 1 |1048575|
Development
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1696K| 1276M| | 291K (1)| 00:58:20 | | |
| 1 | HASH GROUP BY | | 1696K| 1276M| 1325M| 291K (1)| 00:58:20 | | |
|* 2 | HASH JOIN | | 1696K| 1276M| | 9721 (2)| 00:01:57 | | |
| 3 | VIEW | | 15464 | 1132K| | 1855 (1)| 00:00:23 | | |
| 4 | UNION-ALL | | | | | | | | |
| 5 | HASH UNIQUE | | 7681 | 502K| | 618 (1)| 00:00:08 | | |
|* 6 | TABLE ACCESS FULL | HIER | 7681 | 502K| | 617 (1)| 00:00:08 | | |
| 7 | HASH UNIQUE | | 7681 | 375K| | 618 (1)| 00:00:08 | | |
|* 8 | TABLE ACCESS FULL | HIER | 7681 | 375K| | 617 (1)| 00:00:08 | | |
| 9 | HASH UNIQUE | | 102 | 2448 | | 618 (1)| 00:00:08 | | |
|* 10 | TABLE ACCESS FULL | HIER | 7681 | 180K| | 617 (1)| 00:00:08 | | |
|* 11 | HASH JOIN | | 371K| 252M| | 7847 (2)| 00:01:35 | | |
| 12 | VIEW | | 15464 | 1510K| | 1855 (1)| 00:00:23 | | |
| 13 | UNION-ALL | | | | | | | | |
| 14 | HASH UNIQUE | | 7681 | 502K| | 618 (1)| 00:00:08 | | |
|* 15 | TABLE ACCESS FULL | HIER | 7681 | 502K| | 617 (1)| 00:00:08 | | |
| 16 | HASH UNIQUE | | 7681 | 375K| | 618 (1)| 00:00:08 | | |
|* 17 | TABLE ACCESS FULL | HIER | 7681 | 375K| | 617 (1)| 00:00:08 | | |
| 18 | HASH UNIQUE | | 102 | 2448 | | 618 (1)| 00:00:08 | | |
|* 19 | TABLE ACCESS FULL | HIER | 7681 | 180K| | 617 (1)| 00:00:08 | | |
|* 20 | HASH JOIN | | 122K| 71M| | 5987 (2)| 00:01:12 | | |
|* 21 | TABLE ACCESS FULL | HIER | 7681 | 915K| | 617 (1)| 00:00:08 | | |
|* 22 | HASH JOIN | | 122K| 57M| 4512K| 5368 (2)| 00:01:05 | | |
|* 23 | HASH JOIN | | 9556 | 4395K| 3856K| 2409 (2)| 00:00:29 | | |
| 24 | TABLE ACCESS FULL | CLNT | 74426 | 2979K| | 310 (1)| 00:00:04 | | |
|* 25 | HASH JOIN | | 9556 | 4012K| | 1710 (2)| 00:00:21 | | |
| 26 | TABLE ACCESS FULL | DATE_TABLE | 1 | 7 | | 3 (0)| 00:00:01 | | |
| 27 | VIEW | | 19112 | 7894K| | 1706 (2)| 00:00:21 | | |
| 28 | UNION-ALL | | | | | | | | |
| 29 | MERGE JOIN CARTESIAN | | 19111 | 4068K| | 1701 (2)| 00:00:21 | | |
|* 30 | TABLE ACCESS FULL | TAB_CHECK | 1 | 49 | | 3 (0)| 00:00:01 | | |
| 31 | BUFFER SORT | | 248K| 40M| | 1698 (2)| 00:00:21 | | |
| 32 | PARTITION RANGE ALL| | 248K| 40M| | 1698 (2)| 00:00:21 | 1 |1048575|
| 33 | TABLE ACCESS FULL | ANALYTIC_E | 248K| 40M| | 1698 (2)| 00:00:21 | 1 |1048575|
| 34 | MERGE JOIN CARTESIAN | | 1 | 537 | | 5 (0)| 00:00:01 | | |
| 35 | PARTITION RANGE ALL | | 1 | 488 | | 2 (0)| 00:00:01 | 1 |1048575|
| 36 | TABLE ACCESS FULL | ANALYTIC_O | 1 | 488 | | 2 (0)| 00:00:01 | 1 |1048575|
| 37 | BUFFER SORT | | 1 | 49 | | 3 (0)| 00:00:01 | | |
|* 38 | TABLE ACCESS FULL | TAB_CHECK | 1 | 49 | | 3 (0)| 00:00:01 | | |
| 39 | PARTITION HASH ALL | | 810K| 16M| | 1456 (2)| 00:00:18 | 1 | 16 |
| 40 | MAT_VIEW ACCESS FULL | VIS | 810K| 16M| | 1456 (2)| 00:00:18 | 1 | 16 |
-----------------------------------------------------------------------------------------------------------------------------------------

Materialized view creation issue

I am running into an issue and trying to ascertain issue.
Scenario:
I have 2 MV creation scripts. The MV is supposed to get populated by connection from schema to another schema USING DB Links.
Basically, SAME HOST, SAME RAC DATABASE, just separate schemas.
The MV creations are just hanging. I see NO alert log mentions. I ran a SQL trace and yes, I see:
call count       cpu elapsed       disk query    current        rows
Parse 0      0.00 0.00 0          0 0           0
Execute   1011 1.40 73.80 0 0 0           0
Fetch 1010      1.08 317.57 0 0 0        1010
total 2021      2.49 391.38 0 0 0        1010
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 109     (recursive depth: 2)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to dblink 2022 0.00          0.00
SQL*Net message from dblink 2021 0.46        242.58
Understandable, but when I do a selective query, the results come back pretty much within 5 seconds.
DB version is 11.2.0.3.   Is there a BUG that I should know about?
Here is a snippet:
CREATE MATERIALIZED VIEW "SCHEMA"."MV_NAME_MV" USING INDEX REFRESH COMPLETE ON DEMAND AS (SELECT distinct mapguide_persons(pl.location_code) "FULL_NAME_COSTCENTER",
mapguide_jobemp(pl.location_code) "TRUNCNAME_JOB",
mapguide_empnum(pl.location_code) "FULLNAME_EMPNUMBER_PHONE",
mapguide_english(pl.location_code) "ENGLISH_NAME_COSTCENTER",
pl.function_type_lookup_code "FUNCTION_TYPE_LOOKUP_CODE",
pl.location_code "LOCATION_CODE",
pl.org_id "ORG_ID"
FROM [email protected] pl
WHERE pl.function_type_lookup_code not in ('VALUE','CONSULT')
and sysdate between pl.active_start_date and active_end_date);
*Network netstat –in output **
netstat -in
Kernel Interface table
Iface       MTU Met    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0       1500   0 58751025      0 0      0 27335255 0      0      0 BMRU
eth0:1     1500 0      - no statistics available - BMRU
eth0:2     1500 0      - no statistics available - BMRU
eth1       1500   0 5569305513      0 0      0 4365204661 0      0      0 BMRU
eth2       1500   0 146061981      0 0      0 270589939 0      0      0 BMRU
eth2:1     1500 0      - no statistics available - BMRU
lo 16436   0 31731571 0      0      0 31731571      0 0      0 LRU
The above just hangs and spins its wheels…
Any ideas are appreciated…
thanks

JCGO wrote:
The above just hangs and spins its wheels…
And what happens when you issue just the underlying select:
SELECT distinct mapguide_persons(pl.location_code) "FULL_NAME_COSTCENTER",
mapguide_jobemp(pl.location_code) "TRUNCNAME_JOB",
mapguide_empnum(pl.location_code) "FULLNAME_EMPNUMBER_PHONE",
mapguide_english(pl.location_code) "ENGLISH_NAME_COSTCENTER",
pl.function_type_lookup_code "FUNCTION_TYPE_LOOKUP_CODE",
pl.location_code "LOCATION_CODE",
pl.org_id "ORG_ID"
FROM [email protected] pl
WHERE pl.function_type_lookup_code not in ('VALUE','CONSULT')
and sysdate between pl.active_start_date and active_end_date
SY.

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

Issue in Complete Refresh of a Materialized View

Hello,
We have an MV in the Datawarehouse that does a FAST REFRESH daily. Every Saturday, a COMPLETE REFRESH is done as part of the normal Database Activities. The Database is Oracle 9i. The MV contains a Join between a Dimension and Fact Table of a Datawarehouse and does a FAST REFRESH using the MV logs.
However, last Sat, the COMPLETE REFRESH has failed. The DBA tried to run the script twice again but it failed on both occasions with an UNDO TABLESPACE error (ORA-30036). The DBA tried to extend the Tablespace; it did not help either.
- Could this be linked to Tablespace allocations for the MV? Are there any specific steps that can be followed to resolve this?
- Can the MV be dropped and re-created?
Would appreciate a response on the same.
Many Thanks,
Ketan

Hi Ketan,
I guess this is probably because MV complete refresh performs "delete" from the MV and then insert. If the MV is large, it may fail on undo allocation.
Please take a look at Re: materialized view refresh time! Plz Help me! you can see the explanation, metalink note and the solution (how to perform truncate instead of delete).
HTH
Liron Amitzi
Senior DBA consultant
[www.dbsnaps.com]
[www.orbiumsoftware.com]

Materialized View Refresh and I_SNAP$ Indexes issue

At the time of doing REFRESH of the Materialized View, we are getting error like -
SQL> EXECUTE DBMS_MVIEW.REFRESH('MV_TEST.MY_VIEW,'CF');
BEGIN DBMS_MVIEW.REFRESH('MV_TEST.MY_VIEW,'CF'); END;
ERROR at line 1:
ORA-12008: error in materialized view refresh path
ORA-00001: unique constraint (MV_TEST.I_SNAP$_FIN_RESULT_EXPENSE1) violated
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2545
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2751
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2720
ORA-06512: at line 1
I tried to drop and recreate the index I_SNAP$_FIN_RESULT_EXPENSE1 but it didn’t helped.
Later I dropped the index I_SNAP$_FIN_RESULT_EXPENSE1 and refreshed the materialized view and it was successful (obvious). But when I tried to recreate the index, I got the following error –
SYS_OP_MAP_NONNULL("FIN_MULT"), SYS_OP_MAP_NONNULL("FIN_CD"))
ERROR at line 8:
ORA-01452: cannot CREATE UNIQUE INDEX; duplicate keys found
When I look at the value of SYS_OP_MAP_NONNULL('FIN_CD'), it seems to be unique.
SQL> select SYS_OP_MAP_NONNULL('FIN_CD') from dual;
SYS_OP_MAP_NONNULL('FIN_CD’)
46494E5F5650545F4C564C5F335F434400
My questions are:
1.     Why are the indexes (I_SNAP$_*) automatically created for?
2.     What is the purpose of these (I_SNAP$_*) indexes?
3.     What harm can be there if we drop these (I_SNAP$_*) indexes?
4.     Why it is complaining about the Duplicate records / Uniqueness?
5.     How to know where exactly the problem is in this case?
6.     What is the solution for this problem? How to recreate these indexes successfully?
Thanks!

This forum is for the OLAP Option (which supports a cool featured called cube-organized materialized views). If this question if about table-based materialized views you should post it the General Oracle Database forum. Good luck.

Issue in Materialized view

Similar Messages

Maybe you are looking for