Empty materialized view

Hi,
i have a REFRESH FAST ON DEMAND materialized view (10g XE) which access data throught dblink(10.2g).
This Materialized view had been functioning for months well, when one day i've found it empty.
When i executed the creation query, it got the data.
When i refreshed either fast or complete, it still remained empty.
At the end i had to drop and re-create it and now it has the data.
My question: how is it possible this behaviour? Whan can cause such problems?
Thanks in advance.
Bianca

It's certainly allowed ...
ME_XE?create table for_my_mv as select * from all_objects;
Table created.
ME_XE?alter table for_my_mv add constraint for_my_mv_pk primary key (object_id);
Table altered.
ME_XE?create materialized view test_mv as select * from for_my_mv@loopback where 1=0;
Materialized view created.
ME_XE?select * from test_mv;
no rows selected
ME_XE?select * from v$version;
BANNER
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Product
PL/SQL Release 10.2.0.1.0 - Production
CORE 10.2.0.1.0 Production
TNS for Linux: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production
5 rows selected.
ME_XE?Are you attempting to use some GUI tool to do this in, or SQLPLUS (on a client machine, or the server hosting the database)? What version of Oracle?

Similar Messages

MS - contention with empty materialized view on demand - 10.2.0.4

Could somebody explain what is MS - contention? I've searched everywhere and got just that it is used to setup materialized view log. I need more deeper explanation. Why is it needed? And the main thing - I have this materialized view:
CREATE MATERIALIZED VIEW "CLIENT_MV"
ORGANIZATION HEAP PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 1048576 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
BUILD IMMEDIATE
USING INDEX
REFRESH FAST ON DEMAND
WITH PRIMARY KEY USING DEFAULT LOCAL ROLLBACK SEGMENT
DISABLE QUERY REWRITE
AS SELECT CLIENT_ID FROM CLIENT WHERE 1=0
And mlog on it. What activity can cause MS-contention on it? I tried concurrent updates on a master table, refreshed it at the same time, but can't get contention. May be it is important that I saw this contention in v$active_history view
Edited by: user6895786 on 26.02.2010 6:11

user626582 wrote:
Hi all
I have trouble on a 10.2.0.4. All Users have lost their Passwords, that means that the column password in the view dba_users is empty an Users can't login anymore.
I didn't found a logfile or something else. Have you got an idea ? Profiles eg ?
Thanks for your help.What is the error that the users are getting, invalid user name and password, is it? Did you do any recent patching of your system/db? I would suggest that you raise an SR with oracle as it would highly descreuctive to play with base tables on your own.
HTH
Aman....

Materialized Views - DIRLOAD_LIMITEDDML

Hello, I'm currently using Oracle 11g.
Creating a fast refreshable MVIEW with max function on select causes the fast refreshable limitation to DIRLOAD_LIMITEDDML. However, even with an empty materialized view log on the source table, the materialized view keeps COMPLETE refreshing.
Here is my DDL:
CREATE materialized VIEW Log ON DW.FACT_BU_INV_DET_DET
WITH ROWID,
SEQUENCE(
INV_ID,
DETAIL_ID,
ITEM,
ITEM_STEP,
AMMOUNT_BILL,
QUANTITY_RD,
QUANTITY_ST,
QUANTITY_LP,
START_STEP,
END_STEP,
LINE_TYPE,
AMMOUNT_CR,
ORG,
UNIT,
BI_FLAG,
ORG_ID,
UNIT_ID
) INCLUDING NEW VALUES;
CREATE materialized VIEW dw.fact_bu_inv_step_mstep_mv
build IMMEDIATE
REFRESH FAST ON demand
ENABLE query rewrite
as
SELECT s.inv_id,s.item,Max(s.item_step) m_step
FROM
dw.fact_bu_inv_det_det s
GROUP BY s.inv_id,s.item
Any ideas?
Thanks in advance,
Pedro Almeida

What do you mean by "complex query"? Oracle defines a complex query as one that cannot be fast refreshable, so that you could not get a delta. Many queries that people would describe as complex, however, are not technically complex in an Oracle replication context or can be made non-complex.
Justin

Query against materialized view from stored procedure brings back empty row

I have a stored procedure that runs a query against a materialized view. When I run the query outside the SP it works just fine. When I change the MV to a table name, the SP works. When I change it back to the MV i get an empty row. Any ideas? The code is below:
PROCEDURE getAuth     (p_naid        IN NUMBER,
                         p_scope       IN VARCHAR2,
                         o_xml_data    OUT SYS_REFCURSOR
                         ) IS
BEGIN
    IF p_scope = 'Approved' THEN
      OPEN o_xml_data FOR
        SELECT naid,
               p_naid,
               auth_type,
               xml_data
        FROM some_mv
        WHERE naid = p_naid;
      RETURN;
      CLOSE o_xml_data;
... the rest of the procedure ...

does procedure contain EXCEPTION handler?
if so, then remove, delete & eliminate EXCEPTION handler (at least during testing & debugging)

Materialized View big and empty after full refresh

Background:
Database 10.2.0.4 running on Windows 2003 Server R2 SP2.
Materialized view MV_A, selects from 3 base tables, 2 of which are partitioned, fast refresh on demand, approx 33 million rows. Initially populated with a complete refresh of 31 million rows about 2 months ago, and fast refreshed every 10 seconds since then.
Problem: Performed a partition split on one of the base tables and received this error on the next fast refresh:
ORA-32313: REFRESH FAST of "CUR"."MV_A" unsupported after PMOPs
Docs say a complete refresh is required.
So, created a new copy of the materialized view "MV_B", same storage params, same mview SELECT, same schema.
Did a complete refresh, the extents grew to the expected 10GB combined size. The DBMS_MVIEW.REFRESH reported 'PL/SQL procedure successfully completed' but the MVIEW is empty.
23:01:26 SQL> exec DBMS_MVIEW.REFRESH('MV_B','C','',FALSE,FALSE,0,0,0,TRUE) /* Complete */;
PL/SQL procedure successfully completed.
07:56:46 SQL> commit;
Commit complete.
08:17:51 SQL> select count(*) from mv_b;
COUNT(*)
0
08:19:39 SQL>
Since the MVIEW table MV_B added 10 GB worth of extents during the refresh, it appears that the rows were inserted but then for some reason were rolled back. Nothing unusual in the alert.log. If I execute the MVIEW select statement by itself in SQLPlus, yes, I do get rows back.
The tablespaces housing the MVIEW table as well as the temporary and undo tablespaces are set to autoextend/unlimited to make sure they are not an issue.
Next I dropped and recreated the materialized view MV_B, identical except an added condition to the WHERE clause so that the number of rows returned is only 7 million instead of 33 million and that works fine - a complete refresh populates it and subsequent fast refreshes work correctly.
I'm stumped. Any ideas? Could we be running out of some memory resource that when exhausted, is not trapped properly by Oracle as an error?
- Tom

Is the MV and the source tables on the same database? If this is a remote MV, then check the source site if there are any issues (TEMP, UNDO space issues).

Materialized View Log not empty

Hello all
I have an oracle database (11g version), connecting via dbLink to another DB (10g version), and using it's tables as masters for fast refresh materialized views.
To make it simple: I have master DB, with master table X, and Materialized View Log MLOG$_X.
Then, I have replicate DB, with dblink pointing to Master, and Materialized View MV_X, using X.
The materialized view is refreshed fast, on demand.
The problem is, the MV log is never getting empty... how can I solve this issue?
/* code for creating MView */
CREATE MATERIALIZED VIEW "MY_USER"."SI_BANK" ("ID", "NAME", "ACRONYM")
ORGANIZATION HEAP PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 163840 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
TABLESPACE "USERS"
BUILD IMMEDIATE
USING INDEX
REFRESH FAST ON DEMAND START WITH sysdate+0 NEXT SYSDATE + 1
WITH PRIMARY KEY USING DEFAULT LOCAL ROLLBACK SEGMENT
USING ENFORCED CONSTRAINTS DISABLE QUERY REWRITE
AS SELECT ibanco id, nbanco name, nsigla acronym FROM USER.tgtbanc0@DB_LINK;
/* code for refresh group*/
BEGIN
DBMS_REFRESH.MAKE ( name => 'si2p_grp',
list => '', next_date => 'SYSDATE +1' , interval => 'SYSDATE + 1', implicit_destroy => FALSE, rollback_seg => '', push_deferred_rpc => TRUE, refresh_after_errors => FALSE);
END;
/* ADD MATERIALIZED VIEWS TO GROUP */
BEGIN
DBMS_REFRESH.ADD ( name => 'si2p_grp', list => 'SI_BANK', lax => TRUE);
END;
Thank you for any help

One MV log serve to many materialized views. Check dba_registered_mviews on master DB to see how many MViews you have build on you master table X.
After MV (materialized view) is refreshed than all data logged in MVlog for this MV are deleted. But new are recorded when DML are performed against table X.
If you can stop DML on table X for some period of time then do MV refresh and then you can see that MVlog is empty.

How to get Materialized View to ignore unused columns in source table

When updating a column in a source table, records are generated in the corresponding materialized view log table. This happens even if the column being updated is not used in any MV that references the source table. That could be OK, so long as those updates are ignored. However they are not ignored, so when the MV is fast refreshed, I find it can take over a minute, even though no changes are required or made. Is there some way of configuring the materialized view log such that the materialized view refresh ignores these updates ?
So for examle if I have table TEST:
CREATE table test (
d_id NUMBER(10) PRIMARY KEY,
d_name VARCHAR2(100),
d_desc VARCHAR2(256)
This has an MV log MLOG$_TEST:
CREATE MATERIALIZED VIEW LOG ON TEST with rowid, sequence, primary key;
CREATE MATERIALIZED VIEW test_mv
refresh fast on demand
as
select d_id, d_name
from test;
INSERT 200,000 records
exec dbms_mview.refresh('TEST_MV','f');
update test set d_desc = upper(d_desc) ;
exec dbms_mview.refresh('TEST_MV','f'); -- This takes 37 seconds, yet no changes are required.
Oracle 10g/11g

I would love to hear a positive answer to this question - I have the exact same issue :-)
In the "old" days (version 8 I think it was) populating the materialized view logs was done by Oracle auto-creating triggers on the base table. A "trick" could then make that trigger become "FOR UPDATE OF <used_column_list>". Now-a-days it has been internalized so such "triggers" are not visible and modifiable by us mere mortals.
I have not found a way to explicitly tell Oracle "only populate MV log for updates of these columns." I think the underlying reason is that the MV log potentially could be used for several different materialized views at possibly several different target databases. So to be safe that the MV log can be used for any MV created in the future - Oracle always populates MV log at any update (I think.)
One way around the problem is to migrate to STREAMS replication rather than materialized views - but it seems to me like swatting a fly with a bowling ball...
One thing to be aware of: Once the MV log has been "bloated" with a lot of unneccessary logging, you may perhaps see that all your FAST REFRESHes afterwards becomes slow - even after the one that checked all the 200000 unneccessary updates. We have seen that it can happen that Oracle decides on full table scanning the MV log when it does a fast refresh - which usually makes sense. But after a "bloat" has happened, the high water mark of the MV log is now unnaturally high, which can make the full table scan slow by scanning a lot of empty blocks.
We have a nightly job that checks each MV log if it is empty. If it is empty, it locks the MV log and locks the base table, checks for emptiness again, and truncates the MV log if it is still empty, before finally unlocking the tables. That way if an update during the day has happened to bloat the MV log, all the empty space in the MV log will be reclaimed at night.
But I hope someone can answer both you and me with a better solution ;-)

Fast refresh of a materialized view works incorrect

Hi All,
I have created a MV using the sql below:
create materialized view WLS
refresh fast
enable query rewrite
as
SELECT Employees.USER_NAME,
       Permissions.ROLE_NAME,
       Vouchers.VOUCHER_ID,
       EmployeeRoles.FROM_DATE,
       EmployeeRoles.TO_DATE,
       VoucherPatterns.rowid   ACC_VOUCHER_PATTERNS_ROW_ID,
       Vouchers.rowid          ACC_VOUCHERS_ROW_ID,
       Ledgers.rowid           ACC_LEDGERS_ROW_ID,
       Employees.rowid         BANK_EMPLOYEES_ROW_ID,
       IncExcUnits.rowid       INC_EXC_UNITS_ROW_ID,
       EmployeeRoles.rowid     BANK_EMPLOYEE_ROLES_ROW_ID,
       ParentRoles.rowid       PARENT_ROLES_ROW_ID,
       Roles.rowid             ROLES_ROW_ID,
       Permissions.rowid       PERMISSIONS_ROLES_ROW_ID,
       RolesMemberships.rowid ROLES_MEMBERSHIPS_ROW_ID
FROM ACC_VOUCHER_PATTERNS        VoucherPatterns,
       ACC_VOUCHERS                Vouchers,
       ACC_LEDGERS                 Ledgers,
       BANK_EMPLOYEES              Employees,
       BANK_EMPLOYEE_INC_EXC_UNITS IncExcUnits,
       BANK_EMPLOYEE_ROLES         EmployeeRoles,
       ROLES                       ParentRoles,
       ROLES                       Roles,
       ROLES                       Permissions,
       ROLES_MEMBERSHIPS           RolesMemberships
WHERE Vouchers.TYPE_VOUCHER_PATTERN_FK =
       VoucherPatterns.VOUCHER_PATTERN_ID
   AND VoucherPatterns.CONFIRM_COUNT = 2
   AND Vouchers.STATE = 'ISU'
   AND Vouchers.LEDGER_FK = Ledgers.LEDGER_ID
   AND Employees.ID = IncExcUnits.BKEM_ID(+)
   AND (((IncExcUnits.INC_EXCLUD_TYPE IS NULL OR
       IncExcUnits.INC_EXCLUD_TYPE != 'EXC') AND
       Ledgers.ORGANIZATION_UNIT_FK = Employees.ORGU_ID) OR
       (Ledgers.ORGANIZATION_UNIT_FK = IncExcUnits.ORGU_ID AND
       IncExcUnits.INC_EXCLUD_TYPE = 'INC'))
   AND EmployeeRoles.BKEM_ID = Employees.ID
   AND ParentRoles.ID = EmployeeRoles.ROLS_ID
   AND ParentRoles.IS_PERMISSION = 'N'
   AND ParentRoles.ROLE_TYPE = 'ORG'
   AND ParentRoles.ID = Roles.ROLS_ID
   AND Roles.IS_PERMISSION = 'N'
   AND Roles.ROLE_TYPE = 'SYS'
   AND Permissions.IS_PERMISSION = 'Y'
   AND Permissions.ROLE_NAME = 'ACC_AccVoucherConfirm'
   AND Roles.ID = RolesMemberships.ROLS_ID
   AND Permissions.ID = RolesMemberships.ROLS_ID_MEMBER_OF;
Then I have issued a SELECT * though it and that works fine.
And then I've manipulated the data in some tables such that according to MV's WHERE clause it must return no rows.
Intuitively before refreshing the MV it will return the data last placed on it,
But it return the same data after issuing the following command in PL/SQL Developer:
call dbms_mview.refresh(list => 'WLS', method => 'F');
And unfortunately the following will correct it:
call dbms_mview.refresh(list => 'WLS', method => 'C');
Why the fast refresh of a fast refreshable MV does not work fine while its complete refresh works good?
How ever after undoing made changes to those tables and issuing the fast refresh using the following command the MV will contain correct updated data:
call dbms_mview.refresh(list => 'WLS', method => 'F');
It seems that it has bug in deleting rows from Fast Refreshable MV but upserts work fine.
I've tried to simulate the problem for a simpler query with simple tables containing some sample data but those don't have any problem.
Please help me,
Thanks

Thanks Martin,
Finally I've discovered one of possible several situations in which a MV fast refreshed incorrectly.
This is happened when an OR condition exists among several AND conditions and at least one outer join symbol there exists!
this is the scenario:
-- create two sample tables
create table t as select 1 a, 2 b from dual;
create table j as select 1 a, 2 b from dual;
-- defining primary keys
alter table t add constraint tp primary key (a);
alter table j add constraint jp primary key (a);
-- creating MV Logs
create materialized view log on t with primary key, rowid;
create materialized view log on j with primary key, rowid;
-- creating Fast Refresh MV with a sample query
create materialized view mvt refresh fast enable query rewrite as
select t.a, j.b, t.rowid tr, j.rowid jr from t,j where t.a = j.a(+)
and (t.b = j.b or t.a = t.b);
-- select through MV, the MV returns correct data
select * from mvt;
     A    B    TR                    JR
    1    2    AAAYwQAAEAAFhwzAAA    AAAYwRAAEAAFhw7AAA
-- intentionally manipulate the data to the query returns no rows
update j set a = 2;
commit;
-- query the select of MV
select t.a, j.b, t.rowid tr, j.rowid jr from t,j where t.a = j.a(+)
and (t.b = j.b or t.a = t.b);
-- returns now rows, The query rewrite does not work here!
-- select through MV, the MV returns correct data because it has not refreshed yet!
select * from mvt;
     A    B    TR                    JR
    1    2    AAAYwQAAEAAFhwzAAA    AAAYwRAAEAAFhw7AAA
-- fast refreshing the mv and issuing select again
call dbms_mview.refresh(list => 'MVT', method => 'F');
select * from mvt;
     A    B        TR                    JR
    1    null    AAAYwuAAEAAFh2jAAA    null
-- A change is occured but it is not correct, it must returns no rows!
-- query the select of MV
select t.a, j.b, t.rowid tr, j.rowid jr from t,j where t.a = j.a(+)
and (t.b = j.b or t.a = t.b);
     A    B        TR                    JR
    1    null    AAAYwuAAEAAFh2jAAA    null
-- Query rewrite does work here! because appending a neutral "and 1=1" conditions will show the correct empty result:
select t.a, j.b, t.rowid tr, j.rowid jr from t,j where t.a = j.a(+)
and (t.b = j.b or t.a = t.b) and 1=1;
-- returns no rows
-- now complete refreshing the MV and achieving the correct result:
call dbms_mview.refresh(list => 'MVT', method => 'C');
select * from mvt;
-- returns no rows
Is this a BUG?
Any suggestions?

Constraint in Materialized View misbehave

Enviroment
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
s.o : windows 7. on laptop Intel core i7.
create table product_type
( product_type_id varchar2(3) constraint product_type_pk primary key,
product_type_name varchar2(100) constraint product_type_name_nn not null,
move_inv varchar2(1) default 'Y' constraint product_type_move_inv_nn not null,
generate_abc varchar2(1) default 'N' constraint product_type_generate_abc_nn not null,
constraint product_type_move_inv_check check (move_inv in ('Y','N')),
constraint product_type_gen_abc_check check (generate_abc in ('Y','N'))
create table product_class
( product_type_id varchar2(3) constraint product_class_type_id_nn not null,
product_class_id varchar2(3) constraint product_class_id_nn not null,
product_class_name varchar2(50) constraint product_class_name_nn not null,
inv_negative varchar2(1) default 'N' constraint product_class_inv_negative_nn not null,
constraint product_class_pk primary key (product_type_id,product_class_id),
constraint product_class_by_product_type foreign key (product_type_id) references product_type(product_type_id),
constraint product_class_inv_negative_chk check (inv_negative in ('Y','N'))
create materialized view log on product_type with rowid, primary key , sequence (move_inv) including new values;
create materialized view log on product_class with rowid, primary key , sequence (inv_negative) including new values;
create materialized view prd_type_val_prd_class
refresh fast on commit as
select count(*) tot_rows
from product_type pt
join product_class pc
on ( pt.product_type_id = pc.product_type_id )
where pt.move_inv = 'N' and pc.inv_negative = 'Y';
alter table prd_type_val_prd_class add constraint rows_in_prd_type_val_prd_class check( tot_rows < 1 );
-- sentence 1, expected to works
insert into product_type values('SAR','FARMA','N','N');
commit; --- WORKS fine.
-- sentence 2, expected to works
insert into product_class values('SAR','LIQ','LIQUID' ,'N');
commit; --- WORKS fine
-- sentence 3, expected to fail due materialized view constraint
insert into product_class values('SAR','CAP','CAPSULES','Y');
commit; ---> SHOW the materialized view constraint Error FINE!!!!!!
update product_type set move_inv = 'Y'; -- Update product type to allow sentence 3 to be ok
commit; ---> works fine
--- Re execute sentence 3 ----> success FINE!
---sentence 4, WORKS unexpected. --- it suppose to show the error, due materialized view constraint as did in sentence 3 (first try)
update product_type set move_inv = 'N';
commit; --- WORKS :( since this point ON the materialized view constraint error is show no More.... :(
insert into product_class values('SAR','TAB','TABLETS','Y');
commit;
insert into product_class values('SAR','ABC','ABCZXY','Y');
commit;
select count(*) tot_rows
from product_type pt
join product_class pc
on ( pt.product_type_id = pc.product_type_id )
where pt.move_inv = 'N' and pc.inv_negative = 'Y';
tot_rows
3
Any Idea why is this not working as expected??? maybe I'm missing something or is this a glitch???? hope is not.
thank you

luis,
I don't understand why your mv failed, but I tried it in a way I would do it, using an empty MV rather than one with a single rwos with 0 in it. i.e.:
create materialized view prd_type_val_prd_class
refresh fast on commit
as
select pt.product_type_id
      ,pc.product_type_id pc_bc_product_type_id
      ,pc.product_class_id
      ,pc.rowid pc_row_id
      ,pt.rowid pt_row_id
from product_type pt
   , product_class pc
where pt.bc_product_type_id = pc.bc_product_type_id
AND pt.move_inv = 'N' and pc.inv_negative = 'Y';and changed the constraint to keep it empty:
alter table prd_type_val_prd_class add constraint rows_in_prd_type_val_prd_class check(1=0);Is it seemed to pass all your tests

About Refresh Error In Materialized view

hi
i have
Oracle 9.2.0.1 at the windows server 2003
i have created some materialized view to use in my one web application running on tomcat
i have scheduling for refresh it using refresh utility available in oracle materialized view snapshot refresh
but when its try to run state of refresh become unusable and table according to it
remains empty
when i try to do it manually it gives error log
Ora-12008 error in materialized view refresh path
ora-01114 io error writing block to file 201(block #2621321)
ora-27069 skgfdisp:attmempt to do i/o beyond the range of file
osd-04026 invalid parameter passed(OS 2621327)
ora-01114 io error writing block to file 201(block#2621321)
ora-27069 skgfdisp:attempt do i/o beyond the range of the file
osd-04026 invalid parameter passed (OS 2621327)
ora 06512 at "SYS.DBMS_SNAPSHOt",line 794
ora 06512 at "SYS.DBMS_SNAPSHOt", line 851
ora 06512 at "SYS.DBMS_SNAPSHOt", line 832
ora 06512 at line 2
even i could not understand this error
one strange thing in this when i restart my server and try to refresh
it is going to be refresh
please help me

I suspect one of your datafiles has exceeded the 4Gb windows limit. Your tablespace has probably been set to autoextend and this has created the problem. I am not sure what you can do at this point apart from recover from backup. I would open a TAR with Oracle Support as soon as possible to try and resolve this issue.
Please note: This forum is for OLAP issues only. If you need more information I would try posting on the database forum.
Keith Laker
Oracle EMEA Consulting
OLAP Blog: http://oracleOLAP.blogspot.com/
OLAP Wiki: http://wiki.oracle.com/page/Oracle+OLAP+Option
DM Blog: http://oracledmt.blogspot.com/
OWB Blog : http://blogs.oracle.com/warehousebuilder/
OWB Wiki : http://wiki.oracle.com/page/Oracle+Warehouse+Builder
DW on OTN : http://www.oracle.com/technology/products/bi/db/11g/index.html

MLOGS not purge after a fast refresh (Materialized view) ...

Hi,
I have a database on my own site (Quebec) that has 36 materialized views refresh by a master table site that is physically at Montreal. The MVIEWs are refreshed every day of the week (monday to friday) at 7h00 until 19h00. We use the "fast refresh" technic to refresh the materialized views.
Last weekend, I transfered this database on a new server. So, I created a new SID (I rename the old SID "ORCL" by "ATQP") and I created this instance with a DB_BLOCK_SIZE of 16k rather than 8k. It's the only difference between the two instances (the old one and the new one). I also created the owner schema "ATQP" and I made an Export on the old server followed by an Import of the schema that owned the Materialized views (not a Full import) on the new server. The export was made many hours (saturday morning) after the last refresh of the week (friday, at 19h00) on the old server.
After the successul import on my new server, I'm looking for the information about the creation of the MVIEW. Everything seems OK. I can see that the last refresh date indicated "2008-02-22 19:00" (date / time of the last refresh of the week). I made a quick test on a small MVIEW (a fast refresh) and it worked, no error.
Yesterday morning, the DBA of the master table site mentionned us that the DELETE on the MLOGS didn't work on the master site. The refresh was made successfully but the MLOGS continue to grow up, again and again ... On my database, I'm looking in the SYS.SNAP$ table and I saw that the SNAPTIME date is '1950-01-01 12:00' rather than '2008-02-25 19:00'. In the SYS.SNAP_REFTIME, the SNAPTIME is OK but the LOADERTIME column contains the same strange date '1950-01-01 12:00'.
I made a quick check on my old server and the SYS.SNAP$ table is empty !!! I think it's normal because the last refresh on this node was made last friday night and I made the transfert last saturday (I shutdown the old database after).
I know how to solve the problem, by recreate the MVIEW, but it causes a big problem for us. We are in PRODUCTION and we don't want to refresh many millions of records. I think it will take a couple of days to refresh all the materialized views of my schema. And it doesn't sound good by the master table site management team ...
The master table site "rush" us to solve the problem before the weekend. They don't want that we overcharge the network link between them and us by refreshing those MVIEWS.
So, is it possible to make something simple to resynchronized the SNAPTIME date without refreshing completely all the materialized views ?
If the master site table recreate the MLOG (purge manually), is it possible that it will solve our problem ?
Is it also possible to recreate the MVIEW without refreshing the data (specify to Oracle to recreate the MVIEW but indicate that the table associated already exist) ?
All of my materialized view are up to date concerning the data. I don't want to refresh all of it.
Thank's in advance ...

Hi Justin,
The DBA of the master table site sent me a email about the fact he unregistered the MVIEW. He told me that the script for the unregistered worked well. He tried to purge the MLOG and he got the error ORA-23424 but I think it's normal (It's what you said yesterday about the fact that the UNREGISTER command also purge the MLOGS).
So, it seems that the MLOGS are still not purged (that's what the DBA of the master table site said). I ran the following query:
SQL> select * from [email protected];
LOG_OWNER MASTER LOG_TABLE LOG_TRIGGER ROW PRI OBJ FIL SEQ INC
ATQ ALIAS_ANILOTS MLOG$_ALIAS_ANILOTS NO YES NO YES NO YES
ATQ ALIAS_INTERVENANTS MLOG$_ALIAS_INTERVENANTS NO YES NO YES NO YES
ATQ ANILOTS MLOG$_ANILOTS NO YES NO YES NO YES
ATQ CATEGORIES MLOG$_CATEGORIES NO YES NO YES NO YES
ATQ CODES_POSTAUX MLOG$_CODES_POSTAUX NO YES NO YES NO YES
ATQ COMMANDES MLOG$_COMMANDES NO YES NO YES NO YES
ATQ COMMUNICATIONS MLOG$_COMMUNICATIONS NO YES NO YES NO YES
ATQ DEPLACEMENTS MLOG$_DEPLACEMENTS NO YES NO YES NO YES
ATQ DETAILS_STATUTS_COMMANDES MLOG$_DETAILS_STATUTS_COMM NO YES NO YES NO YES
ATQ DOMAINES MLOG$_DOMAINES NO YES NO YES NO YES
ATQ ENREGISTREMENT_LOGS MLOG$_ENREGISTREMENT_LOGS NO YES NO YES NO YES
ATQ ENREGISTREMENT_NOTES MLOG$_ENREGISTREMENT_NOTES NO YES NO YES NO YES
ATQ ESPECES MLOG$_ESPECES NO YES NO YES NO YES
ATQ EVENEMENTS MLOG$_EVENEMENTS NO YES NO YES NO YES
ATQ EVENE_DIFFERES MLOG$_EVENE_DIFFERES NO YES NO YES NO YES
ATQ IDENTIFIANTS MLOG$_IDENTIFIANTS NO YES NO YES NO YES
ATQ INTERVENANTS MLOG$_INTERVENANTS NO YES NO YES NO YES
ATQ INTERVENANTS_CLIENTS MLOG$_INTERVENANTS_CLIENTS NO YES NO YES NO YES
ATQ INTERVENANTS_SITES MLOG$_INTERVENANTS_SITES NO YES NO YES NO YES
ATQ MAX_EVENE_DIFFERES MLOG$_MAX_EVENE_DIFFERES NO YES NO YES NO YES
ATQ MESSAGES MLOG$_MESSAGES NO YES NO YES NO YES
ATQ MUNICIPALITES MLOG$_MUNICIPALITES NO YES NO YES NO YES
ATQ NEW_ANILOTS MLOG$_NEW_ANILOTS NO YES NO YES NO YES
ATQ NEW_EVENEMENTS MLOG$_NEW_EVENEMENTS NO YES NO YES NO YES
ATQ NEW_IDENTIFIANTS MLOG$_NEW_IDENTIFIANTS NO YES NO YES NO YES
ATQ NEW_SITES MLOG$_NEW_SITES NO YES NO YES NO YES
ATQ PAYS MLOG$_PAYS NO YES NO YES NO YES
ATQ PRODUCTIONS MLOG$_PRODUCTIONS NO YES NO YES NO YES
ATQ PROPRIETES_ANILOTS MLOG$_PROPRIETES_ANILOTS NO YES NO YES NO YES
ATQ PROVINCES MLOG$_PROVINCES NO YES NO YES NO YES
ATQ SITES_EXPLOITATIONS MLOG$_SITES_EXPLOITATIONS NO YES NO YES NO YES
ATQ TYPES_IDENTIFIANTS MLOG$_TYPES_IDENTIFIANTS NO YES NO YES NO YES
ATQ UTILISATEURS MLOG$_UTILISATEURS NO YES NO YES NO YES
ATQ VALEURS MLOG$_VALEURS NO YES NO YES NO YES
ATQ VALEURS_DETAILS MLOG$_VALEURS_DETAILS NO YES NO YES NO YES
ATQ VEHICULES MLOG$_VEHICULES NO YES NO YES NO YES
36 ligne(s) sélectionnée(s).
SQL>
I supposed that is the result of the MLOG of the MVIEW associated with my new server. How can I be sure that the MLOG associated with the old one are really deleted ?
Thank you

Materialized view refresh and rollback segment

Hi all,
maybe this is a dumb question but:
We use a few materialized views (partitioned, on prebult tables) in our DB.
The refresh method used is complete.
Every refresh clears old data et the very beginning and leaves the table empty until new data is commited (can take up to 2 hrs). But what is use of specifying the rollback segment than?
I would like to change this behaviour to keep the old data to the very moment of replacing with new one.
Is there a way?
Thanks a lot
Petr

Hi all,
maybe this is a dumb question but:
We use a few materialized views (partitioned, on prebult tables) in our DB.
The refresh method used is complete.
Every refresh clears old data et the very beginning and leaves the table empty until new data is commited (can take up to 2 hrs). But what is use of specifying the rollback segment than?
I would like to change this behaviour to keep the old data to the very moment of replacing with new one.
Is there a way?
Thanks a lot
Petr Oracle will truncate the MV and then effectively insert as select to populate your MV. In doing so
Oracle needs to keep a read consistent view of the select it is executing. Here clearly you might consider specifying a specific rbs.
Have you considered fast refresh or is this not a candidate? At least with fast refresh you won't have to compeletly rebuild the mv each time and it will be considerably faster.
steve

Refreshing materialized view fails

Hi,
I'm trying to refresh a materialized view. I've set up everything according to the documentation but when I try to do a refresh of the MV I get an end-of-file on communication channel. I know there is not a single cause of this error but maybe someone has an idea. The statement is:
CALL DBMS_MVIEW.REFRESH ('ismart_user.psis_images', '?');
The output of sql*plus:
list => 'ismart_user.psis_images',
ERROR at line 3:
ORA-03113: end-of-file on communication channel
The mv table is defined as:
PSIS_IMAGE_ID NOT NULL NUMBER
PSIS_IMAGE ORDSYS.ORDIMAGE
PSIS_THUMBNAIL ORDSYS.ORDIMAGE
PSIS_IMAGE_NAME VARCHAR2(50)
PSIS_IMAGE_WIDTH NUMBER
PSIS_IMAGE_HEIGHTN NUMBER
There are about 50 other table (also with ORDSYS.ORDIMAGE columns) which don't give any problem, only this single table. (FYI: the table is empty).
What can be the cause of the end-of-file on comm channel error?

There are many reasons for this error. I suggest you check for related docs on Metalink.

Materialized View - Refresh in 10g FAST .. refresh in 11g SLOW

Sorry I'm not able to paste anything.
The customer moved their database from 10g to a 11gR2 database.
They created the MV in the new system and now it takes 26 hours to refresh
as opposed to 15 min in the old 10g database.
Just looking for a game plan for troubleshooting.
I know I'm not providing much of anything so please forgive me.
Where would you look first ? Explain plan .. system settings .. ? Let me know.
If you have a good reference then that would work. The docs are not working.
Thanks in advance.
BB

Do you mean they upgraded their existing database from 10g to 11gr2?
Or do you mean they loaded the data into a new 11gr2 database?Yeah I confirmed this morning that they data-pumped the entire database to the 11g host.
Unless you provide more information there is no way to provide any specific suggestions.
What kind of MV? Are the source and MV on the same server?They do a manual refresh :
create materialized view (mview_name as select ...)
dbms_snapshot.refresh(mview_name, 'C')
The source is the same for both however it is from a place that uses a connection.
If it is a new DB then there may be missing indexes or constraints.
The MV may initially be empty and the first refresh will be a COMPLETE
one that will take a lot longer than an incremental.
Some of the objects or constraints could be invalid. The indexes appear to be the same and the constraints enabled/disabled in the same manner.
They confirmed that the refresh after the initial is taking way too long compared to before (10g).
Oddly some of the mviews see no performance degradation in the new environment.
They have many.
Thanks for taking the time to think about it. It was much appreciated.
If I get to the bottom of it I'll let everybody know.
BB

Fast Refresh in Materialized Views Partitioned

Hi all.. I've a little problem... let's go into it:
I have two tables:
A dimension table , named D1
A partitioned fact table, named F1
I create two materialized views log in each of 2 tables.
Ok.. Now, I created a Materialized View Partitioned, name MV_F1D1, with incremental refresh for it...
I can create the Materialized View Partitioned with fast refresh, no problem here...
First time Oracle make a Complete refresh, everything ok.. Then I make a
     BEGIN
          DBMS_SNAPSHOT.REFRESH('MV_F1D1','F');
     END;
And everything goes well...
But.. In my fact tables, I load the data with a temporary table, named F1_NP (Fact table no partitionated)
with the data of the current month. Every week I do this:
1) Load the data in F1_NP
2) If the LAST_PARTITION_MM_YYYY not exists in F1, I add the partition to F1...
3) ALTER TABLE F1 EXCHANGE PARTITION LAST_PARTITION_MM_YYYY WITH TABLE F1_NP
And, this is the problem....
After that process, the Log table of F1 is empty..
When i'm trying to fast refresh the mv_F1D1, I got an error
     ORA-12097 changes in the master tables during refresh, try refresh:
THis occurs when only I truncate a partition
in the fact table too.
Ok.. My only solution here is to make a complete refresh.. But I have only a new partition. I expected that with the PCT, Oracle let me
do it a fast refresh.
I'm looking for a solution in the web, and I installed the utlxmnv.sql:
1) Before add a partition in F1
truncate table mv_capabilities_table;
exec DBMS_MVIEW.EXPLAIN_MVIEW ( 'MV_F1D1' );
select * from mv_capabilities_table;
PCT Y
REFRESH_COMPLETE Y
REFRESH_FAST Y
REWRITE Y
PCT_TABLE Y F1
PCT_TABLE N D1 2068 Relation is not partitioned.
REFRESH_FAST_AFTER_INSERT Y
REFRESH_FAST_AFTER_ONETAB_DML Y
REFRESH_FAST_AFTER_ANY_DML Y
REFRESH_FAST_PCT Y
REWRITE_FULL_TEXT_MATCH Y
REWRITE_PARTIAL_TEXT_MATCH Y
REWRITE_GENERAL Y
REWRITE_PCT Y
PCT_TABLE_REWRITE Y F1
PCT_TABLE_REWRITE N D1 2068 Relation is not partitioned.
2) After truncate a partition in F1
truncate table mv_capabilities_table;
exec DBMS_MVIEW.EXPLAIN_MVIEW ( 'MV_F1D1');
select * from mv_capabilities_table;
PCT Y
REFRESH_COMPLETE Y
REFRESH_FAST Y
REWRITE Y
PCT_TABLE Y F1
PCT_TABLE N D1 2068 Relation is not partitioned.
REFRESH_FAST_AFTER_INSERT N F1 2077 Mv log is newer than last full refresh
REFRESH_FAST_AFTER_INSERT N F1 2077 Mv log is newer than last full refresh
REFRESH_FAST_AFTER_ONETAB_DML N 2146
REFRESH_FAST_AFTER_ANY_DML N F1 2076
REFRESH_FAST_AFTER_ANY_DML N 2161
REFRESH_FAST_PCT Y
REWRITE_FULL_TEXT_MATCH Y
REWRITE_PARTIAL_TEXT_MATCH Y
REWRITE_GENERAL Y
REWRITE_PCT Y
PCT_TABLE_REWRITE Y F1
PCT_TABLE_REWRITE N D1 2068 Relation is not partitioned.
BEGIN
          DBMS_SNAPSHOT.REFRESH('MV_F1D1','F');
END;
ORA-32313: REFRESH FAST of "MV_F1D1" unsupported after PMOPs
any ideas? Can I fast refresh a MV partitioned (composed with a Table Dimension and Fact table)
with PCT when I add data in the Dimension Table/add a partition in a Fact Table Partitioned?

Look at ATOMIC_REFRESH option, if you set this to FALSE you may see performance gain as it'll use DIRECT PATH and TRUNCATE. Data will be unavailable while being refreshed though.
Cheers
Si

Empty materialized view

Similar Messages

Maybe you are looking for