MAKING MORE ARCHIVE IN MATERIALIZED VIEW

Hi experts,
i created a materialised view and created index on that, but while refreshing the MV it is making more archive log file.
in index i also opted nologging option, still while refreshing it is still creating more archieve files.
what to do so that it should not create more archive while refreshing materlialised view.
thanks

10g to 8i can work, assuming
- 8i = 8.1.7
- You are applying at least the 8.1.7.4 patchset to the master (8i) or you are applying the latest patchset to the slave (10g). Realistically, you probably want to do both.
If you are talking about using the standard edition, I assume that you are only doing basic replication, not multi-master replication. I also assume you are aware of the limitations on hardware that come with Standard Edition 1-- I don't recall if you are limited to machines that have a capacity for 2 or 4 CPU's. Also, be aware that Oracle considers multi-core CPU's as multiple CPU's.
Justin
Distributed Database Consulting, Inc.
http://www.ddbcinc.com/askDDBC

Similar Messages

Making more archieve file while refreshing materialised view

Hi experts,
i have created a materialised view and index on that, while refreshing it is making more archive files,
how to stop making archieve while refreshing the Materialised view.
i also opted nologging option on that,

Hi experts,
i have created a materialised view and index on that, while refreshing it is making more archive files,
how to stop making archieve while refreshing the Materialised view.
i also opted nologging option on that,

Materialized view logs in cloned database

Hi all!
We have materlialized views and materlialized view logs in two separate databases which are connected with a database link. The MV logs are in DB1_PROD, which is the database being cloned. The database link goes from DB2_PROD (where the MVs are located) to DB1_PROD:
DB2_PROD (materialized views) ----DB link---> DB1_PROD (materialized view logs)
When cloning DB1_PROD to DB3_DEV, the MV logs still have a reference to DB2_PROD. However, there is no connection between DB3_DEV and DB2_PROD.
In my opinion this is not harmful, but I would like to know if any of you can see any problems with this.
In summary;
DB1_PROD: Materialized view logs
DB3_DEV: Materialized view logs. Clone of DB1_PROD
DB2_PROD: Materialized views.
DB1_PROD and DB3_DEV:
select * from v$version;
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
DB2_PROD:
select * from v$version;
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE 11.2.0.3.0 Production
TNS for Linux: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - ProductionPlease let me know if you need further information.

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

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

Materialized view and archive

Hi guys,
A materialized view table created with NOLOGGING option generate archivelogs when I execute a refresh command ?
Thanks

That depends at least on Oracle version, refresh method and whether you have put your database and/or tablespace in force logging mode.
I won't cover all combinations but at least you should understand that
1) till 9i (including) the default mechanism for complete refresh is truncate and insert /*+ append */
2) since 10g it is delete and conventional insert
3) complete refresh is done as mentioned above, incremental refresh uses normal DML (without truncate and insert /*+append*/)
4) if you r db and/or tablespace is in force loggng mode then nologging clauses and /*+append*/ hints are ignored
So generally it depends :)
Gints Plivna
http://www.gplivna.eu

Material View Refresh Slow under 10.2.0.4?

I have several material views that refreshed in minutes under 9.2.0.6, but are now taking hours under 10.2.0.4. I'm thinking it's in my initialization parameters. I remember the upgrade process making at least one of the HASH parameters obsolete.
Can anyone point me in a direction quickly?
A little more info... If I drop and recreate the materialized view from scratch it take just a few minutes to build.
Thank you.
Edited by: golflover1 on Jan 3, 2009 7:32 AM
Edited by: golflover1 on Jan 3, 2009 7:33 AM

What type of refresh you use to refresh the Materialized Views? (COMPLETE, FAST, FORCE)
Since you migrated to 10g there is a slight difference in how Oracle does the refresh.
Prior to 10g, when a materialized view is completely refreshed the base table was truncated and then populated with a data.
Starting from 10g, the default behavior is changed and truncate is replaced with delete which results in longer refresh times.
This is expected behavior, even though there was a bug associated with it Bug#4132133 which was closed as NOT A BUG.
However, if you still want to do a truncate instead of delete, you should set atomic_refresh=>FALSE in your DBMS_MVIEW.REFRESH command. This will do a truncate and refresh will complete faster.
You should be careful about this since there will be a time when the MV will contain no data.
golflover1 wrote:
A little more info... If I drop and recreate the materialized view from scratch it take just a few minutes to build.
This just confirms what I have written above. When you drop and recreate the MV, it doesn't do the DELETE so it completes faster.
I would say, go ahead and try to refresh the view with atomic_refresh=>FALSE and compare the execution times.
begin
dbms_mview.refresh(list=>'your mv name',method=>'C',atomic_refresh=>FALSE);
end;For more about DBMS_MVIEW.REFRESH check the reference docs on this link</link>.
Cheers,

Equivalent of Materialized Views in SQL Server

Hi
we are migrating Oracle Database to SQL Server 2012 and is looking for solution, equivalent to Materialized Views in Oracle.
we had tried to implement indexed View, but that was not possible, because the MVs have outer joins, subqueries, aggregate functions and also there is no column in it which can act as a Primary Key.
Please Help to get a solution for this issue.
Regards
Joyasree Mondal

>use tempdb
>drop table t
>go
>create table t(id int, constraint pk_t primary key (id))
>
>go
>insert into t(id)
>select top 1000 cast( cast( newid() as binary(4) ) as int)
>from sys.objects o, sys.columns c
>go 100
>
>
>select id
>from t with (index=pk_t, tablockx)
>
>
>select id
>from t with (index=pk_t, nolock)
Still the same order.
>> No, its always in the key order like I've shown here.
> You are extrapolating from a single example.
Actually, this information doesn't even come from my exampleS (there were quite a few so far). Its written in the article you posted here. My examples are meant to confirm that and explain why the ORDER BY clause is redundant in some cases.
> I have. ORDER BY in a view used to always return ordered results. Then it didn't.
Examples? References?
>GROUP BY without an ORDER BY used to always return ordered results. Then it didn't. Many queries have >change the result ordering when you get a parallel plan.
Now you finally admit ordered results would always be returned, even without an order by clause. We are in the right track it appears. The reason for this change of behavior is a variation in the logical operator used by the query optimizer, and not the
way the engine reads pages from disk.
In the beginning of times there was stream aggregate, an operator that would require its input to be sorted. And this is how a GROUP BY clause would ensure results were always ordered.
But then his ugly cousin came and messed things up. He doesnt need an ordered input so yeah, order would be random. AGAIN, there are still ways of enforcing order here, through query hints, without requiring an order by clause, so this changes nothing.
You have confirmed that for a given operator, results will always be ordered. Your own argument has, once again, proven my point.
> Right. But there are different _kinds_ of scans. An ordered scan, where SQL Server reads rows based on the logical order of the index is just one kind.
It only won't scan in key order (by scheduling reads) if you change the transaction isolation level and hope for the worse. Because the key order scan is the best performing way of reading pages, this behavior (although possible) wasan't even observed in
the example with NOLOCK/TABLOCK (known to cause allocation-order scans in larger tables) you posted above.
> Other kinds include the parallel scan, the reverse scan,
References?
> the merry-go-round scan,
Only applies to table scans, not indexes.
http://technet.microsoft.com/en-us/library/ms191475%28v=SQL.105%29.aspx
> And the allocation-order (or unordered) scan.
Only if you specify TABLOCK or NOLOCK query hints, which I haven't done. This is something that goes without saying, it's irrelevant to an indexed view scenario such as this one.
Some people have also said it will perform an allocation-order scan if the index is too fragmented in SQL Server 2005, but as of 2012 it (probably) won't, as I have shown here. There is also no document anywhere in the internet (you are free to search for
it), that would point us otherwise. If you have access to additional information, I would be more than happy if you could share it with us.
Reference: http://sqlmag.com/database-development/quaere-verum-clustered-index-scans-part-iii
> And don't take my word for it. Take Conor Cunningham's:
>If you need order in your query results, put in an ORDER BY. It's that simple. Anything else is like >riding in a car without a seatbelt.
>No Seatbelt - Expecting Order without ORDER BY
Again, with all due respect, did you read your own article? Did you read what I said earlier about having multiple I/O threads as a whole other situation? If you add new variables, OF COURSE the results will be different. Parallelism was disabled in the
server I performed these tests on, but still you can control this by query hints, and you can enforce execution plans by using plan gudes.
Its like I always say - it's always about the 0.001% of situations, the exceptions, rather than the general rule.
Tell Mr Connor to add MAXDOP 1 to his querys OPTION clause and see if results are still unordered lol
References:
http://msdn.microsoft.com/en-us/library/ms190417.aspx
http://msdn.microsoft.com/en-us/library/ms181714.aspx
http://technet.microsoft.com/en-us/library/ms188611%28v=sql.105%29.aspx
http://blogs.msdn.com/b/conor_cunningham_msft/archive/2008/08/27/no-seatbelt-expecting-order-without-order-by.aspx
Imagining uncontrollable factors that would get an ordered input to be retrieved in an unordered manner is one of SQL Server's myths. There are a whole other people around who think the same way because of some experiences they had when they didn't know
how to control the execution plan, and adding an order by clause is a very popular and easy shortcut to a complex problem. "In the worst cases it will just be redundant", they say. What they like to forget is that sorting has an often high cost,
and it can be avoided by taking advantage of indexes.

Trouble with Materialized View

Hello,
I'm in need of some help enforcing data integrity using a materialized view. In my example, each system may consist of three types of components and this is modeled using supertype/subtype relationships. I'm trying to enforce that, for a given system, a component cannot reside in more than one component table. For example, given System 1, if Component A exists in the mobile_components table, it cannot be inserted into the desktop_components table for System 1. Rather than using triggers, I'm attempting to use a materialized view with unique constraint to enforce this rule based on the example from Tom Kyte's "The Trouble With Triggers" article http://www.oracle.com/technetwork/issue-archive/2008/08-sep/o58asktom-101055.html. However, I can't seem to get it to work as it gives me ORA-12054: Cannot set the ON COMMIT refresh attribute. I'm using UNION ALL, and I know that can be tricky, but I can't figure out what rules I'm breaking. I have the necessary privileges. Oracle 11g. Can anyone help?
Thanks,
Mark
create table systems (
sys_id number,
sys_name varchar2(100),
constraint sys_pk primary key (sys_id),
constraint sys_uk unique (sys_name));
insert into systems values (1,'System 1');
insert into systems values (2,'System 2');
create table mobile_components (
mo_comp_id number,
mo_comp_name varchar2(100),
mo_comp_sys_id number,
constraint mo_pk primary key (mo_comp_id),
constraint mo_uk unique (mo_comp_name, mo_comp_sys_id),
constraint mo_fk foreign key (mo_comp_sys_id) references systems (sys_id));
insert into mobile_components values (1,'Component A',1);
insert into mobile_components values (2,'Component A',2);
create table desktop_components (
de_comp_id number,
de_comp_name varchar2(100),
de_comp_sys_id number,
constraint de_pk primary key (de_comp_id),
constraint de_uk unique (de_comp_name, de_comp_sys_id),
constraint de_fk foreign key (de_comp_sys_id) references systems (sys_id));
insert into desktop_components values (1,'Component B',1);
insert into desktop_components values (2,'Component B',2);
create table internet_components (
in_comp_id number,
in_comp_name varchar2(100),
in_comp_sys_id number,
constraint in_pk primary key (in_comp_id),
constraint in_uk unique (in_comp_name, in_comp_sys_id),
constraint in_fk foreign key (in_comp_sys_id_ references systems (sys_id));
insert into internet_components values (1,'Component C',1);
insert into internet_components values (2,'Component C',2);
create materialized view log on mobile_components with rowid;
create materialized view log on desktop_components with rowid;
create materialized view log on internet_components with rowid;
create materialized view mv_components
refresh fast on commit with rowid as
select rowid as row_id, mo_comp_id as comp_id, mo_comp_name as comp_name
from mobile_components
union all
select rowid, de_comp_id, de_comp_name
from desktop_components
union all
select rowid, in_comp_id, in_comp_name
from internet_components;
alter table mv_components add constraint mv_comp_uk unique (comp_id, comp_name);

You need a marker column to distinguish which of your queries you union, that data came from:
e.g.
create materialized view mv_components
refresh fast on commit with rowid as
select 'a' marker,rowid as row_id, mo_comp_id as comp_id, mo_comp_name as comp_name
from mobile_components
union all
select 'b',rowid, de_comp_id, de_comp_name
from desktop_components
union all
select 'c', rowid, in_comp_id, in_comp_name
from internet_components;

Materialized view excessive logging. SOS

The refresh of our materialized view is causing excessive logging. I altered the materialized view to NOLOGGING but it did not have any effect, not sure why?
We either need to change the refresh time from 3 minutes to every 15 minutes(which is a bummer, data would be more stale) or give up on the materialized view.
The quantity of archive logs has more than doubled since we adding this materialized view and the file system partition filed up last night, halting activity inside the database!
Any suggestions?

The refresh is not set for direct path inserts.Good. Now you have something you can change to help resolve the issue.
The MV does not have any indexes.So the logging issue you describe is purely caused by deletes from, and inserts into the MV during a complete refresh.
You can use the advice given by Alex above, and use atomic_refresh => false. Before you say it cannot be done because the users will not have access to the data during refresh, you might need to get creative. If you use query rewrite, for example, users would have access to data from the base tables while the MV is being refreshed. Their queries may be slower for a while, but they will still get data. If waiting 3 minutes or so is unacceptable for the queries that sneak in during a refresh, you can consider the following. Use query rewrite and have 2 materialized views, one of which can refresh while the other is available. After refreshing one, disable query rewrite on the older one.
We cannot perform a fast refresh due to the query required to build the view.I'll take your word on it, although I have come across this situation many times where MVs that were thought to be impossible to fast refresh actually can be made to do it. Again, you might need to get creative. Sometimes you can do this by having MVs built on other MVs.
Also, consider using MVs on prebuilt tables. You get additional control over how to refresh the MV this way. You can build your own custom refresh process that might help you do your own "fast refresh" by just applying the delta to your data (insert a few rows, update a few aggregates, perhaps). You can even do things like partition swapping so you can build your refreshed data in a separate table and then swap it with the MV partition (even if it is all in one partition).

Materialized view long transaction time

I am using Oracle DB 11g R2 and created a materialized view log WITH SEQUENCE. I need to find out the exact date/time the transaction was made. I see that my MV log has the 'XID$$' column (NUMBER 22), but not sure how to determine the date/time from that. Is there another view/table I can join to get me that info? I see some have 'XID' column but they are RAW(8).
Thanks
Edited by: bobmagan on Feb 27, 2013 11:57 AM

- CDC is at least as performant as materialized view logs. If you do asynchronous CDC, it performs better since you're not burdening the source transactions with the overhead of synchronously maintaining the materialized view logs.
- CDC is at least as effective as materialized view logs. Since CDC is designed to publish changes to custom consumers where materialized view logs are designed to be used by Oracle to refresh a materialized view, it strikes me as a much safer solution. If someone comes along and creates a materialized view that starts using your materialized view log, for example, a solution that involves custom code to manipulate the materialized view is almost certainly going to fail.
- CDC isn't an extra cost option so there shouldn't be a cost difference
That leaves the question of simplicity. I'll certainly grant you that a materialized view log solution may appear simpler. But a lot of that simplicity advantage disappears over time. The fact that we're talking about doing things like querying relatively obscure data dictionary tables like all_summap, for example, is added complexity that a CDC-based solution doesn't need. But over time, I'd much rather maintain a CDC-based solution rather than hooking in to materialized view logs. If someone wants to build a materialized view and Oracle happens to be able to use the materialized view log you've created for your own CDC, the custom solution will stop working. Over time, Oracle introduces more and more functionality that allows the ROWID of a row to change (shrinking a table, flashback, etc.). If you're using CDC, Oracle will take care of making sure that all those things are presented to you correctly. If you're rolling your own solution, you have to test and ensure that your code handles all those cases correctly. When Oracle makes a change in some future release that you hadn't considered, you've got to notice the potential problem, code the fix, and test it. Most places are probably going to miss something and only discover that there is a problem when they do something like shrink a table and then find that their custom solution doesn't handle that gracefully.
Justin

How can I fast refresh the materialized view !!

I created a MV base on some tables in order to improve the querey speed.
but the mv I have created falied to refresh fast.
because there are two same table in the from clause:
jcdm jc1,jcdm jc2
create materialized view temp_mv
nologging
pctfree 0
storage (initial 2048k next 2048k pctincrease 0)
parallel
build immediate
refresh force
on demand
as
select
TAB_GSHX.rowid hx_rid,
TAB_GSHD.rowid hd_rid ,
JC1.rowid jc1_rid ,
JC2.rowid jc2_rid ,
YSHD_ID     HXID,
JC1.JCDM     QFD,
JC2.JCDM     JLD
FROM
TAB_GSHX,
TAB_GSHD,
jCDM JC1,
JCDM JC2
WHERE
YSHD_ID=YSHX_ID
AND YSHD_QFD=JC1.JBJC_ID
AND YSHD_JLD=JC2.JBJC_ID
AND TO_CHAR(YSHX_time,'YYYYMMDD')='20030101'
the column msgtxt of the table MV_CAPABILITIES_TABLE is :
"the multiple instances of the same table or view" and " one or more joins present in mv".
How can I succeed in fast refresh the above temp_mv!!!
thanks.

lianjun,
When you are using Oracle9i there is a procedure which can help you setup the materialized view. If some option isn't working it gives you hint why it doesn't work.
The procedure is dbms_mview.explain_mview.
Take a look at the documentation how to use it. (In the Oracle9i DWH guide the package is explained.)
Hope this helps
With kind regards,
Bas Roelands

Dynamic calculations in a materialized view

Hi,
I have a problem. I created a materialized view which works perfectly. But now I need to perform some calculations with the data in my view . The view contains the working hours of employees who worked in different projects. Every project has a fixed amount of time (time_available) in which the employee has to finish the project. I aggregated the working hours to month for better presentation. What I want to accomplish here is a "simple" subtraction of "fixed amount for a project" minus "working hours" for the employee.
The problem here is that some project have duration of more that just one month. Naturally all my values are in one tuple for every month. So when I have 3 month of working hours for a project my view looks like this:
MV_Working_Hours:
Project --- Time_Available --- DATE --- Employee --- Working Days
Project A --- 50 Days --- 2011-05 --- Mr. A --- 15 Days
Project A --- 50 Days --- 2011-06 --- Mr. A --- 16 Days
Project A --- 50 Days --- 2011-07 --- Mr. A --- 16 Days
What I want to do is to calculate the remaining days like this :
Project --- Time_Available --- DATE --- Employee --- Working d in Month ---reaming days
Project A --- 50 Days --- 2011-05 --- Mr. A --- 15 Days --- 35 Days
Project A --- 50 Days --- 2011-06 --- Mr. A --- 16 Days --- 19 Days <--- I get here 34 which is for my need wrong !!!
Project A --- 50 Days --- 2011-07 --- Mr. A --- 16 Days --- 3 Days
Is there a way to realize this with "just" sql or do I have to use pl/sql in the OWB? I use the OWB version 11gR2
thx

For everybody who is confronted with the same problem I have - here is the solution: (thx to "spencer7593" and "Justin Cave" from StackOverflow)
SUM( "Working Days" )
OVER (PARTITION BY "Product", "Employee"
ORDER BY "DATE"
ROWS UNBOUNDED PRECEDING)
and please check out the link from oracle for _"SQL for Analysis and Reporting"_: http://download.oracle.com/docs/cd/E14072_01/server.112/e10810/analysis.htm

Subquery in a Materialized View

I have a requirement where we have to build a summary view to show a customer's latest transaction. There can be several million customers so I am thinking if a Materialized view that gets refreshed once every day is a good option here. This is a Datawarehouse application where the records get appended once every day. I would like a summarized materialized view that is dropped and refreshed every day morning.
Here is the query that gets the latest order amount for each of the customer:
SELECT cu.cust_name,
od.order_amount
FROM customers cu,
orders od
WHERE cu.cust_id = od.cust_id
and od.order_date =
(select max(order_date) from orders od
where od.cust_id = cu.cust_id)
My questions are:
1) Is the materialized view a snapshot? Or does it go against the underlying table every time the MV is accessed, much like a regular view?
2) I would like a snapshot type of solution here. Since there could be 100 million orders for 1 million customers, a summary snapshot of 1 million records would perform much better IMO. Correct me if I got it wrong.
Thank you in advance for your help.

Users query will be explicitly against the Mview.
After doing some reading on the MView, I am more inclined to think that Mview is not an ideal solution for my requirement here.
SELECT cu.cust_name,
od.order_amount,
MAX(od.order_date) over (PARTITION BY od.cust_id) max_date
FROM customers cu,
orders od
WHERE cu.cust_id = od.cust_id
The orders is a 20+ million records table. I thought by using a Mview that holds the maximum order date will avoid going to the orders table when users want to see that is the latest order date for a customer. However, the report requirements are such that the users will want to see what is the maximum order date within a certain date range. If this being the case, there is no point in using an Mview.
Once again, pl correct me if my understanding is not correct.

How do I figure where is the data in a materialized view coming from

Hi: when I run select NAME, OWNER from dba_mview_refresh_times, I see a number of materialized views. How do I find more details about this view i.e where is the data coming from and which fields. The source table that is in another database changed. But the view on my database where the materialized view exist has not changed. I want to confirm from where is data coming in this view
TIA
Ravi

SQL> select * from dict where table_name like 'ALL%MVIEW%'
TABLE_NAME                     COMMENTS
ALL_BASE_TABLE_MVIEWS          All materialized views with log(s) in the database that the user can s
                               ee
ALL_MVIEWS                     All materialized views in the database
ALL_MVIEW_AGGREGATES           Description of the materialized view aggregates accessible to the user
ALL_MVIEW_ANALYSIS             Description of the materialized views accessible to the user
ALL_MVIEW_COMMENTS             Comments on materialized views accessible to the user
ALL_MVIEW_DETAIL_PARTITION     Freshness information of all PCT materialized views in the database
ALL_MVIEW_DETAIL_RELATIONS     Description of the materialized view detail tables accessible to the u
                               ser
ALL_MVIEW_DETAIL_SUBPARTITION Freshness information of all PCT materialized views in the database
ALL_MVIEW_JOINS                Description of a join between two columns in the
                               WHERE clause of a materialized view accessible to the user
ALL_MVIEW_KEYS                 Description of the columns that appear in the GROUP BY
                               list of a materialized view accessible to the user
ALL_MVIEW_LOGS                 All materialized view logs in the database that the user can see
ALL_MVIEW_REFRESH_TIMES        Materialized views and their last refresh times for each master table
                                that the user can look at
ALL_REGISTERED_MVIEWS          Remote materialized views of local tables that the user can see
13 rows selected.

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

MAKING MORE ARCHIVE IN MATERIALIZED VIEW

Similar Messages

Maybe you are looking for