FTS on small Materialized View, should I cache it in the KEEP Pool ?

Hi all,
I have a small MV (1773 rows) that is used in a Query JOIN (the query & the explain plan is attached below). Although I already create index for the MV, it is always FTS in the query.
I read a Tuning tips, that FTS on small table should be cached in the KEEP POOL, with this command :
ALTER TABLE ITT.MV_CONVERT_UOM STORAGE (BUFFER_POOL KEEP);
Should I do this ?
Thank you for your help,
xtanto.
Query & explain PLAN :
SELECT so_id_hdr, product_ord, qty_ord, UOM, MV.UOM_B, MV.UOM_K
FROM SALESORDER_D SOD
JOIN MV_CONVERT_UOM MV ON MV.PRODUCT = SOD.PRODUCT_ORD
WHERE SO_id_hdr = 31944
Plan hash value: 1323612888
| Id | Operation                         | Name             | Rows | Bytes | Cost (%CPU)| Time     |    TQ |IN-OUT| PQ Distrib |
|   0 | SELECT STATEMENT                  |                  |     5 |   225 |     5 (20)| 00:00:01 |        |      |            |
|   1 | PX COORDINATOR                   |                  |       |       |            |          |        |      |            |
|   2 |   PX SEND QC (RANDOM)             | :TQ10001         |     5 |   225 |     5 (20)| 00:00:01 | Q1,01 | P->S | QC (RAND) |
|* 3 |    HASH JOIN                      |                  |     5 |   225 |     5 (20)| 00:00:01 | Q1,01 | PCWP |            |
|   4 |     BUFFER SORT                   |                  |       |       |            |          | Q1,01 | PCWC |            |
|   5 |      PX RECEIVE                   |                  |     5 |   135 |     2   (0)| 00:00:01 | Q1,01 | PCWP |            |
|   6 |       PX SEND BROADCAST           | :TQ10000         |     5 |   135 |     2   (0)| 00:00:01 |        | S->P | BROADCAST |
|   7 |        TABLE ACCESS BY INDEX ROWID| SALESORDER_D     |     5 |   135 |     2   (0)| 00:00:01 |        |      |            |
|* 8 |         INDEX RANGE SCAN          | SALESORDER_D_FKH |     5 |       |     1   (0)| 00:00:01 |        |      |            |
|   9 |     PX BLOCK ITERATOR             |                  | 1773 | 31914 |     2   (0)| 00:00:01 | Q1,01 | PCWC |            |
| 10 |      MAT_VIEW ACCESS FULL         | MV_CONVERT_UOM   | 1773 | 31914 |     2   (0)| 00:00:01 | Q1,01 | PCWP |            |
Predicate Information (identified by operation id):
   3 - access("MV"."PRODUCT"="SOD"."PRODUCT_ORD")
   8 - access("SOD"."SO_ID_HDR"=31944)

Hi Leo, below is execution plan for the query you gave :
Plan hash value: 1323612888
| Id | Operation                         | Name             | Rows | Bytes | Cost (%CPU)| Time     |    TQ |IN-OUT| PQ Distrib |
|   0 | SELECT STATEMENT                  |                  |     5 |   200 |     5 (20)| 00:00:01 |        |      |            |
|   1 | PX COORDINATOR                   |                  |       |       |            |          |        |      |            |
|   2 |   PX SEND QC (RANDOM)             | :TQ10001         |     5 |   200 |     5 (20)| 00:00:01 | Q1,01 | P->S | QC (RAND) |
|* 3 |    HASH JOIN                      |                  |     5 |   200 |     5 (20)| 00:00:01 | Q1,01 | PCWP |            |
|   4 |     BUFFER SORT                   |                  |       |       |            |          | Q1,01 | PCWC |            |
|   5 |      PX RECEIVE                   |                  |     5 |   110 |     2   (0)| 00:00:01 | Q1,01 | PCWP |            |
|   6 |       PX SEND BROADCAST           | :TQ10000         |     5 |   110 |     2   (0)| 00:00:01 |        | S->P | BROADCAST |
|   7 |        TABLE ACCESS BY INDEX ROWID| SALESORDER_D     |     5 |   110 |     2   (0)| 00:00:01 |        |      |            |
|* 8 |         INDEX RANGE SCAN          | SALESORDER_D_FKH |     5 |       |     1   (0)| 00:00:01 |        |      |            |
|   9 |     PX BLOCK ITERATOR             |                  | 1773 | 31914 |     2   (0)| 00:00:01 | Q1,01 | PCWC |            |
| 10 |      MAT_VIEW ACCESS FULL         | MV_CONVERT_UOM   | 1773 | 31914 |     2   (0)| 00:00:01 | Q1,01 | PCWP |            |
------------I have tried using index hints like below, but it stil FTS.
EXPLAIN PLAN FOR
SELECT /*+ INDEX(MV_CONVERT_UOM MV_CONVERT_UOM_IDX1) */sod.so_id_hdr ,sod.product_ord ,
     sod.qty_ord ,sod.uom ,mv.uom_b ,
     mv.uom_k FROM SALESORDER_D sod ,
     MV_CONVERT_UOM mv WHERE mv.product = sod.product_ord AND
     sod.so_id_hdr = 31944
what to do now ?
Thank you,
xtanto

Similar Messages

How to get a materialized view get to refresh itself after the job is "broken"

we created a materialized view sometime ago with the following statement:
create materialized view SXV_PUB_EMPLOYEE_CERT_ALL_M
refresh complete on demand
start with to_date('30-08-2009 04:00:00', 'dd-mm-yyyy hh24:mi:ss') next trunc(sysdate) + (28/24)
as
select sxv_emp_cert_all.*
from sxv_employee_certification_all sxv_emp_cert_all;
this week we found out it had not been refresh for about a month
In dba_jobs the column broken was 'Y', next_date time something like 01-01-4000 and failures 16
when I ran it manually by executing
BEGIN DBMS_MVIEW.REFRESH('SXV_PUB_EMPLOYEE_CERT_ALL_M', 'C'); END;
I found that one of the columns was too small (probably a columns of one of the underlying tables had been extended since the creation of the materialized view)
After fixing this I ussied yesterday (on 29-8-2013) the statement :
alter materialized view SXV_PUB_EMPLOYEE_CERT_ALL_M
refresh complete on demand
start with to_date('30-08-2009 04:00:00', 'dd-mm-yyyy hh24:mi:ss') next trunc(sysdate) + (28/24)
after this the table dba_jobs showed me 30-08-2013 04:00:00 as next date
I was expecting it to run this night at 04:00, but it didn't
the last_date column value was still from about a month ago, the column broken still shows 'Y'
and the next date 30-08-2013 04:00:00 (while it should been set to 31-08-2013 01:00:00
Rrunning
BEGIN DBMS_MVIEW.REFRESH('SXV_PUB_EMPLOYEE_CERT_ALL_M', 'C'); END;
gave no errors this time
and in User_Mview_Analysis the last_refresh_date column showed the date/time I had executed it
Any idea how to get the job "unbroken" again so that the view refreshes itself every night?
the database is Oracle Database 10g Release 10.2.0.4.0
regards,
Remco

thanx for all your helpful and correct answers . but eventually I found it myself
exec dbms_job.broken(<jobnumber>, false);

Creating Materialized View in Toad

As with every new endeavor - come new questions.
I am trying to create a materialized view via toad (first time doing this). Now - toad is great, since it provides a kind-of wizard interface. Hence, one doesn't have to completely code in the create statement, with all of the options, etc.
Instead, in toad, one can (via the schema browser), go into the Materialized Views tab and click on create new. This opens a window with 6 tabs: Basic Info, Refresh Info, Physical Attributes, Query, Partitions & Subpartition Template.
In the Basic Info, one can put a check mark next to some of the following options:
-Build Deffered
-Parallel
-Cache
-Logging
-Using index
-Allow updates
etc.
I have read that build deferred refers to whether or not you would like the view to be created automatically or to be deferred.
Anyways, I tried to find Toad documentation to explain each of the options in-detail. No success. Hence, am researching each part piece by piece.
But - here is my question:
In the Query tab, we are asked to specify a query. I am assuming that the query does not have to be a full query, beginning with CREATE MATERIALIZED VIEW mv_table1 REFRESH FAST etc...
Since in this 'wizard', we are providing the MV name at the top of the dialog box, we are checking the 'options' in the other tabs, etc.
And so, I assumed that the query should merely be a select query in the window mentioned above.
So I entered the following:
select * from table1@remote_db;
When I go to verify the syntax, I get the error message: ORA_00911: invalid character. It seems to be pointing to my db_link (remote_db). I have been using this link throughout many places, w/o any problems.
Has anyone created a MV in toad before? Any links to good toad documentation would be helpful as well.
Thanks.

(This is fun... ;))
For anyone endeavoring this in the future, below I have attached the prerequisites required in order to create a materialized view (can also be found @ http://download-uk.oracle.com/docs/cd/B14117_01/server.101/b10759/statements_6002.htm):
Prerequisites
The privileges required to create a materialized view should be granted directly rather than through a role.
To create a materialized view in your own schema:
You must have been granted the CREATE MATERIALIZED VIEW system privilege and either the CREATE TABLE or CREATE ANY TABLE system privilege.
You must also have access to any master tables of the materialized view that you do not own, either through a SELECT object privilege on each of the tables or through the SELECT ANY TABLE system privilege.
To create a materialized view in another user's schema:
You must have the CREATE ANY MATERIALIZED VIEW system privilege.
The owner of the materialized view must have the CREATE TABLE system privilege. The owner must also have access to any master tables of the materialized view that the schema owner does not own (for example, if the master tables are on a remote database) and to any materialized view logs defined on those master tables, either through a SELECT object privilege on each of the tables or through the SELECT ANY TABLE system privilege.
To create a refresh-on-commit materialized view (ON COMMIT REFRESH clause), in addition to the preceding privileges, you must have the ON COMMIT REFRESH object privilege on any master tables that you do not own or you must have the ON COMMIT REFRESH system privilege.
To create the materialized view with query rewrite enabled, in addition to the preceding privileges:
If the schema owner does not own the master tables, then the schema owner must have the GLOBAL QUERY REWRITE privilege or the QUERY REWRITE object privilege on each table outside the schema.
If you are defining the materialized view on a prebuilt container (ON PREBUILT TABLE clause), then you must have the SELECT privilege WITH GRANT OPTION on the container table.
The user whose schema contains the materialized view must have sufficient quota in the target tablespace to store the master table and index of the materialized view or must have the UNLIMITED TABLESPACE system privilege.
When you create a materialized view, Oracle Database creates one internal table and at least one index, and may create one view, all in the schema of the materialized view. Oracle Database uses these objects to maintain the materialized view data. You must have the privileges necessary to create these objects.

Materialized View to run only once in a year...

Hi everybody...
I want to create a materialized view which will run only once in a year and specifically some minutes after 00:00 a.m. on new year's day,
so i created the following:
CREATE MATERIALIZED VIEW <mv_name>
BUILD IMMEDIATE
REFRESH START WITH TO_DATE('01/01/2007 00:15:00','DD/MM/RRRR HH24:MI:SS')
NEXT SYSDATE+366
I have two notes:
1) how to declare the refresh to be done the first new year's day after the day it'll be created , i mean not static date (01/01/2007)
2)some years are leap and some are not , so in order to run every new year's day how should i transform the above..????
3)is there any view which displays the next run of a materialized view..???
the view DBA_MV_REFRESH_TIMES displays the last refresh of mv's...
I use Oracle 10.2.0.1 on XP ...
Thanks , a lot
Simon

1).
use the expression that evaluates to next january first.
SQL> select sysdate, add_months(trunc(sysdate, 'yyyy'), 12) from dual ;
SYSDATE ADD_MONTHS(
19-JUN-2006 01-JAN-2007
1 row selected.
SQL>2). for this also use the same expression that will evaluate to the january first of the year after that.

What's the impact of rowid materialized view in oracle 10g

Hello to all ;
Oracle official docs saying
ROWID materialized views should be used only for materialized views based on master tables from an Oracle7 database, and should not be used from Oracle8 or higher.
For 10g or higher versions can we consider rowid materizlized view ?
product 10.2.0.4 and 11g r2 on Redhat 5.1

No
should not be used from Oracle8 or higher10g is higher

Creation of materialized view

Hi All,
We had created some other materialized view with for small set of data. The materialized view name is ‘XXCA_PAGL_RECON_GL1_TRANS_MV’ and it has created a table with the same name.
What I am unable to understand is that the new table which was created by the system during the creation of materialized view is in VALID state but the materialized view is in INVALID state.
Please help me to understand this process.
Thanks in advance
Venkatesh

The column dba_objects.status for mviews is set to INVALID when the base tables are updated. See Metalink note 454552.1. It is normal.
Edited by: YasinBaskan on Feb 17, 2009 2:07 PM

MATERIALIZED view on two tables with Fast Refresh

i Wanted to create MV on two tables with Fast refresh on commit.
I followed below steps
create materialized view log on t1 WITH PRIMARY KEY, rowid;
create materialized view log on t2 WITH PRIMARY KEY, rowid;
CREATE MATERIALIZED VIEW ETL_ENTITY_DIVISION_ASSO_MV
REFRESH fast ON commit
ENABLE QUERY REWRITE
AS
select A.ROWID B.ROWID,a.c1, DECODE(a.c1,'aaa','xxx','aaa') c2
from t1 A
join t2 b
on AB.c1= CD.c2;
i am getting below error.
Error report:
SQL Error: ORA-12054: cannot set the ON COMMIT refresh attribute for the materialized view
12054. 00000 - "cannot set the ON COMMIT refresh attribute for the materialized view"
*Cause: The materialized view did not satisfy conditions for refresh at
commit time.
*Action: Specify only valid options.
Basically i want to take record in MV by joinig two tables and if both of the base tables will updated then record should reflect in materialised view.
Please do the needfull.

does the table support PCT? the other restrictions on joins look to be ok in your statement.
maybe try creating first with on demand instead of commit to see does it create.
http://docs.oracle.com/cd/B19306_01/server.102/b14223/basicmv.htm
>
Materialized Views Containing Only Joins
Some materialized views contain only joins and no aggregates, such as in Example 8-4, where a materialized view is created that joins the sales table to the times and customers tables. The advantage of creating this type of materialized view is that expensive joins will be precalculated.
Fast refresh for a materialized view containing only joins is possible after any type of DML to the base tables (direct-path or conventional INSERT, UPDATE, or DELETE).
A materialized view containing only joins can be defined to be refreshed ON COMMIT or ON DEMAND. If it is ON COMMIT, the refresh is performed at commit time of the transaction that does DML on the materialized view's detail table.
If you specify REFRESH FAST, Oracle performs further verification of the query definition to ensure that fast refresh can be performed if any of the detail tables change. These additional checks are:
A materialized view log must be present for each detail table unless the table supports PCT. Also, when a materialized view log is required, the ROWID column must be present in each materialized view log.
The rowids of all the detail tables must appear in the SELECT list of the materialized view query definition.
If some of these restrictions are not met, you can create the materialized view as REFRESH FORCE to take advantage of fast refresh when it is possible. If one of the tables did not meet all of the criteria, but the other tables did, the materialized view would still be fast refreshable with respect to the other tables for which all the criteria are met.

Problem refreshing Materialized View in SQL Developer

I have a database schema with a Materialized View (MV) that updates a products table shown on a website. This schema was recently imported to an 11g database from 8i, but since this import I have been unable to refresh my schema’s Materialized View.
The MV_PRODUCT_MASTER Materialized View attaches price data to product data that is stored in a normal WEB_PRODUCT table, and create an MV table as a result. The output MV table is what the website pulls data from to display to the site users. Since it is an MV table, this table cannot be edited directly. In order to change, say, a product description, I need to alter the description field in WEB_PRODUCT and manually refresh the MV_PRODUCT_MASTER table. Only through the refresh will the upstream edits appear in the MV_PRODUCT_MASTER table and be visible on the website.
In my old 7.6.0.11 copy of TOAD, I could manually refresh these MVs easily, by opening the “Snapshots” tab, right clicking on the MV I wanted to refresh and selecting the “Refresh” option. Since the schema was imported to 11g, I have been using the Oracle SQLDeveloper tool to manage the schema. SQLDeveloper doesn’t have a clear method for manually refreshing an MV, or else the method I am using isn’t working.
If I right click on the MV_PRODUCT_MASTER Materialized View object, and choose “Other Actions”, I see the following choices:
Shrink Materialized View
Compile Materialized View
Force Materialized View Refresh
Rebuild Materialized View
…I assumed that “Force Materialized View Refresh” was the right choice, and chose that. This option displays the SQL:
alter materialized view "WEBADMIN"."MV_PRODUCT_MASTER" consider fresh
When I apply this, I get the message: “Materialized view “MV_PRODUCT_MASTER” has been set torefreshed”. However, no changes appear in the MV output table. i.e. if I make a specific change to a row in the WEB_PRODUCT table, the change is not being carried into the MV_PRODUCT_MASTER table, so that indicated that the refresh is not actually happening. The MV table appears to believe it is being refreshed:
REWRITE_CAPABILITY     GENERAL
REFRESH_MODE     DEMAND
REFRESH_METHOD     COMPLETE
BUILD_MODE     IMMEDIATE
FAST_REFRESHABLE     NO
LAST_REFRESH_TYPE     COMPLETE
LAST_REFRESH_DATE     06-APR-10
STALENESS     UNKNOWN
…but it isn’t showing any changes.
What am I doing wrong? Is there a plain SQL statement I can run in order to run these refreshes, instead of using the SQLDeveloper GUI? Thanks for any advice on this.

Hi Blama,
DDL for Index-organized Materialized Views is generated in the Early Adopter release 4.1.0.866, which is now available for download.
The Organization on the Table that is implemented as the Materialized View should be set to INDEX, and the Table's IOT properties will be used during DDL generation.
David

Error in materialized view refresh path

I have a procedure that manuall refreshes a materialized view. It almost always gets the following errors:
ERROR at line 1:
ORA-12008: error in materialized view refresh path
ORA-08103: object no longer exists
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2255
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2461
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2430
ORA-06512: at "MGT2.ITV_026_SP", line 35
ORA-06512: at line 1
When I run the same refresh of the materialized view directly from SQL*Plus, it never gets the error. It takes only about 5 minutes. OEM says the undo tablespace can support retention of 753 minutes if I'm understanding the graph.
Thanks for your help..

I will take a wild guess:
MGT2.VW_PRINT_026
Is a materialized view too.
This error means that while doing a refresh to VW_MAT_026 it
source mv, the VW_PRINT_026 wasn't exists, i.e. has been in the refresh process.
You didn't get it in Sql*Plus because you are doing it step by step.
The solution - make sure that VW_PRINT_026 completed it refresh before doing
The VW_MAT_026 refresh, e.g.
not tested-
begin
dbms_snapshot.refresh('VW_PRINT_026');
dbms_snapshot.refresh('VW_MAT_026');
end;Another option - the VW_PRINT_026 is a table created "on the fly"
And in some scenario - the table isn't exists yet...
If this is the case you should check if the object exist before doing the
VW_MAT_026 refresh, e.g.
not tested-
declare
ll_exists number;
begin
select 1 into ll_exists from all_objects where owner ='MGT2' and
object_name ='VW_PRINT_026';
dbms_snapshot.refresh('VW_MAT_026');
when others then raise;
end;Amiel

Materialized views on prebuilt tables - query rewrite

Hi Everyone,
I am currently counting on implementing the query rewrite functionality via materialized views to leverage existing aggregated tables.
Goal*: to use aggregate-awareness for our queries
How*: by creating views on existing aggregates loaded via ETL (+CREATE MATERIALIZED VIEW xxx on ON PREBUILT TABLE ENABLE QUERY REWRITE+)
Advantage*: leverage oracle functionalities + render logical model simpler (no aggregates)
Disadvantage*: existing ETL's need to be written as SQL in view creation statement --> aggregation rule exists twice (once on db, once in ETL)
Issue*: Certain ETL's are quite complex via lookups, functions, ... --> might create overy complex SQLs in view creation statements
My question: is there a way around the issue described? (I'm assuming the SQL in the view creation is necessary for oracle to know when an aggregate can be used)
Best practices & shared experiences are welcome as well of course
Kind regards,
Peter

streefpo wrote:
I'm still in the process of testing, but the drops should not be necessary.
Remember: The materialized view is nothing but a definition - the table itself continues to exist as before.
So as long as the definition doesn't change (added column, changed calculation, ...), the materialized view doesn't need to be re-created. (as the data is not maintained by Oracle)Thanks for reminding me but if you find a documented approach I will be waiting because this was the basis of my argument from the beginning.
SQL> select * from v$version ;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE     11.2.0.1.0     Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production
SQL> desc employees
Name                                                                                            Null?    Type
EMPLOYEE_ID                                                                                     NOT NULL NUMBER(6)
FIRST_NAME                                                                                               VARCHAR2(20)
LAST_NAME                                                                                       NOT NULL VARCHAR2(25)
EMAIL                                                                                           NOT NULL VARCHAR2(25)
PHONE_NUMBER                                                                                             VARCHAR2(20)
HIRE_DATE                                                                                       NOT NULL DATE
JOB_ID                                                                                          NOT NULL VARCHAR2(10)
SALARY                                                                                                   NUMBER(8,2)
COMMISSION_PCT                                                                                           NUMBER(2,2)
MANAGER_ID                                                                                               NUMBER(6)
DEPARTMENT_ID                                                                                            NUMBER(4)
SQL> select count(*) from employees ;
COUNT(*)
       107
SQL> create table mv_table nologging as select department_id, sum(salary) as totalsal from employees group by department_id ;
Table created.
SQL> desc mv_table
Name                                                                                            Null?    Type
DEPARTMENT_ID                                                                                            NUMBER(4)
TOTALSAL                                                                                                 NUMBER
SQL> select count(*) from mv_table ;
COUNT(*)
        12
SQL> create materialized view mv_table on prebuilt table with reduced precision enable query rewrite as select department_id, sum(salary) as totalsal from employees group by department_id ;
Materialized view created.
SQL> select count(*) from mv_table ;
COUNT(*)
        12
SQL> select object_name, object_type from user_objects where object_name = 'MV_TABLE' ;
OBJECT_NAME                                                                                                                      OBJECT_TYPE
MV_TABLE                                                                                                                         TABLE
MV_TABLE                                                                                                                         MATERIALIZED VIEW
SQL> insert into mv_table values (999, 100) ;
insert into mv_table values (999, 100)
ERROR at line 1:
ORA-01732: data manipulation operation not legal on this view
SQL> update mv_table set totalsal = totalsal * 1.1 where department_id = 10 ;
update mv_table set totalsal = totalsal * 1.1 where department_id = 10
ERROR at line 1:
ORA-01732: data manipulation operation not legal on this view
SQL> delete from mv_table where totalsal <= 10000 ;
delete from mv_table where totalsal <= 10000
ERROR at line 1:
ORA-01732: data manipulation operation not legal on this view While investigating for this thread I actually made my own question redundant as the answer became gradually clear:
When using complex ETL's, I just need to make sure the complexity is located in the ETL loading the detailed table, not the aggregate
I'll try to clarify through an example:
- A detailed Table DET_SALES exists with Sales per Day, Store & Product
- An aggregated table AGG_SALES_MM exists with Sales, SalesStore per Month, Store & Product
- An ETL exists to load AGG_SALES_MM where Sales = SUM(Sales) & SalesStore = (SUM(Sales) Across Store)
--> i.e. the SalesStore measure will be derived out of a lookup
- A (Prebuilt) Materialized View will exist with the same column definitions as the ETL
--> to allow query-rewrite to know when to access the table
My concern was how to include the SalesStore in the materialized view definition (--> complex SQL!)
--> I should actually include SalesStore in the DET_SALES table, thus:
- including the 'Across Store' function in the detailed ETL
- rendering my Aggregation ETL into a simple GROUP BY
- rendering my materialized view definition into a simple GROUP BY as wellNot sure how close your example is to your actual problem. Also don't know if you are doing an incremental/complete data load and the data volume.
But the "SalesStore = (SUM(Sales) Across Store)" can be derived from the aggregated MV using analytical function. One can just create a normal view on top of MV for querying. It is hard to believe that aggregating in detail table during ETL load is the best approach but what do I know?

Materialized view showing red cross in front of it in SQL developer

we created a materialized view in oracle database,it works fine, and other views that select on it return results and work fine too. But it has a red cross in front of it in oracle developer.
I then refresh the view, or recreate the view, it shows green, but after a while when I come back, the red cross show up again.
What does it mean, any error message we can find?
Thanks

878566 wrote:
we created a materialized view in oracle database,it works fine, and other views that select on it return results and work fine too. But it has a red cross in front of it in oracle developer.
I then refresh the view, or recreate the view, it shows green, but after a while when I come back, the red cross show up again.
What does it mean, any error message we can find?
It means your system is working NORMALLY! There is no 'error message' to find because there is no error. What you describe is EXACTLY how MVs are designed to work.
It is NORMAL for MVs to be, and to become, invalid, especially if there refresh setting is ON DEMAND. Don't confuse 'validity' with 'staleness'; they are very different things.
See the section 'Invalidating Materialized Views' in the Data Warehousing Guide'
http://docs.oracle.com/cd/B28359_01/server.111/b28313/advmv.htm#i1007082
Invalidating Materialized Views
Dependencies related to materialized views are automatically maintained to ensure correct operation. When a materialized view is created, the materialized view depends on the detail tables referenced in its definition. Any DML operation, such as an INSERT, or DELETE, UPDATE, or DDL operation on any dependency in the materialized view will cause it to become invalid. To revalidate a materialized view, use the ALTER MATERIALIZED VIEW COMPILE statement.
A materialized view is automatically revalidated when it is referenced. In many cases, the materialized view will be successfully and transparently revalidated. However, if a column has been dropped in a table referenced by a materialized view or the owner of the materialized view did not have one of the query rewrite privileges and that privilege has now been granted to the owner, you should use the following statement to revalidate the materialized view:
ALTER MATERIALIZED VIEW mview_name COMPILE;
The state of a materialized view can be checked by querying the data dictionary views USER_MVIEWS or ALL_MVIEWS. The column STALENESS will show one of the values FRESH, STALE, UNUSABLE, UNKNOWN, UNDEFINED, or NEEDS_COMPILE to indicate whether the materialized view can be used. The state is maintained automatically. However, if the staleness of a materialized view is marked as NEEDS_COMPILE, you could issue an ALTER MATERIALIZED VIEW ... COMPILE statement to validate the materialized view and get the correct staleness state. If the state of a materialized view is UNUSABLE, you must perform a complete refresh to bring the materialized view back to the FRESH state. If the materialized view is based on a prebuilt table that you never refresh, you will need to drop and re-create the materialized view.
As the doc states Oracle will normally 'revalidate' an MV when it is referenced. You can do this manually by using 'ALTER . . . COMPILE'. For an ON DEMAND MV compiling it will NOT alter the contents of the MV - it may stil be STALE.
You don't need to REFRESH or recreate the MV to make it valid; just recompile it. If it doesn't become VALID after you compile it then there is usually an issue with one of the dependent objects that you need to resolve.

Materialized View creation advice and SQL advice

I want to create a materialized view for the table below. The materialized view should query data from only this table and i want to join 2 rows to one.
The key for the joins are the column internal_correlation_id which is unique for request/response pair.
The table is updated every day with 2 million rows.
What type of materialized view should i use and how can i query to get one row?
CREATE TABLE EVENT (
       caller_id                              VARCHAR2(255)          NOT NULL
     , service_id                         VARCHAR2(255)          NOT NULL
     , country_code                         VARCHAR2(2)
     , internal_correlation_id                  VARCHAR2(255)          NOT NULL -- Unique for request response pair
     , received_date                         DATE                    NOT NULL
     , status                              VARCHAR2(20)
     , queue_name                         VARCHAR2(255)          NOT NULL
     , USER_ID                              VARCHAR2(50)
     , engine_id                         VARCHAR2(50)
     , tracking_correlation_id                  VARCHAR2(2000)
     , mnc                              VARCHAR2(20)
     , mcc                              VARCHAR2(20)
     , request_type                         VARCHAR2(50) -- REQUEST or RESPONSE
     , app_id                              VARCHAR2(50)
     , failure_code                         VARCHAR2(50)
     , failure_string                            VARCHAR2(255)
     , created_date                          DATE DEFAULT SYSDATE
    , updated_date                             DATE DEFAULT SYSDATE
    DB release 11G release 1
Edited by: Alekons01 on Mar 24, 2012 2:43 PM

Anyway, I don't believe you will be able to create MV with fast refresh. MV with complete refresh:
CREATE MATERIALIZED VIEW event_mv
BUILD IMMEDIATE
REFRESH COMPLETE ON DEMAND
AS
    SELECT e1.caller_id req_caller_id,
            e1.service_id req_service_id,
            e1.country_code req_country_code,
            e1.internal_correlation_id req_internal_correlation_id,
            e1.received_date req_received_date,
            e1.status req_status,
            e1.queue_name req_queue_name,
            e1.user_id req_user_id,
            e1.engine_id req_engine_id,
            e1.tracking_correlation_id req_tracking_correlation_id,
            e1.mnc req_mnc,
            e1.mcc req_mcc,
            e1.request_type req_request_type,
            e1.app_id req_app_id,
            e1.failure_code req_failure_code,
            e1.failure_string req_failure_string,
            e1.created_date req_created_date,
            e1.updated_date req_updated_date,
            e2.caller_id rsp_caller_id,
            e2.service_id rsp_service_id,
            e2.country_code rsp_country_code,
            e2.internal_correlation_id rsp_internal_correlation_id,
            e2.received_date rsp_received_date,
            e2.status rsp_status,
            e2.queue_name rsp_queue_name,
            e2.user_id rsp_user_id,
            e2.engine_id rsp_engine_id,
            e2.tracking_correlation_id rsp_tracking_correlation_id,
            e2.mnc rsp_mnc,
            e2.mcc rsp_mcc,
            e2.request_type rsp_request_type,
            e2.app_id rsp_app_id,
            e2.failure_code rsp_failure_code,
            e2.failure_string rsp_failure_string,
            e2.created_date rsp_created_date,
            e2.updated_date rsp_updated_date
      FROM event e1,
            event e2
      WHERE e2.internal_correlation_id = e1.internal_correlation_id
        AND e1.request_type = 'REQUEST'
        AND e2.request_type = 'RESPONSE'
/SY.

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

SELECT PRIVILEGES required on Materialized View Logs

Hi,
I have a scenario where in Base table exists in one database and Materialized View on other.
The Materialized View is created with FAST REFRESH option.
I have created Materialized View Log in database where master table exists.
Also I have given Select priv on master table to the user(where MV is created).
I want to know how will i Grant SELECT PRIV on Materialized View Log so that FAST refresh happens.
Both databases are Oracle 10g R2.
I have read following on oracle site:
The owner of the materialized view must have the CREATE TABLE system privilege. The owner must also have access to any master tables of the materialized view that the schema owner does not own (for example, if the master tables are on a remote database) and to any materialized view logs defined on those master tables, either through a SELECT object privilege on each of the tables or through the SELECT ANY TABLE system privilege.
Please tell me the command to GRANT SELECT to the user who has created MV.
Thank You,
Niranjan.

Hi,
The privileges required to create a materialized view should be granted directly rather than through a role
To create a materialized view in your own schema:
1- Grant CREATE MATERIALIZED VIEW system privilege and either the CREATE TABLE or CREATE ANY TABLE system privilege.
2-You must also have access to any master tables of the materialized view that you do not own, either through a SELECT object privilege on each of the tables or through the SELECT ANY
TABLE system privilege.
To create a materialized view in another user's schema:
1-You must have the CREATE ANY MATERIALIZED VIEW system privilege.
2-The owner of the materialized view must have the CREATE TABLE system privilege. The owner must also have access to any master tables of the materialized view that the schema owner does not own (for example, if the master tables are on a remote database) and to any materialized view logs defined on those master tables, either through a SELECT object privilege on each of the tables or through the SELECT ANY TABLE system privilege.
To create a refresh-on-commit materialized view (ON COMMIT REFRESH clause), in addition to the preceding privileges, you must have the ON COMMIT REFRESH object privilege on any master tables that you do not own or you must have the ON COMMIT REFRESH system privilege.
see this link
http://download.oracle.com/docs/cd/B12037_01/server.101/b10759/statements_6002.htm

Materialized view and view logs on EBS 11.5.10

Hi,
Trying to create a materialized view log on table MTL_SYSTEM_ITEMS_B connected as APPS... the system complaints about : ORA-00942: table or view does not exist
So, do i have to create the mv log to the INV schema or do i need to grant a priv to user APPS???
I have read in the EBS- Concepts edoc that the materialized view should be created in the APPS schema...
What about the materialized view logs..???
Thank you,
Sim

Sim,
Please review the following documents, and see if it helps.
Note: 273924.1 - ORA-12096: ERROR IN MATERIALIZED VIEW LOG ON ''INV''.''MTL_MATERIAL_TRANSACTIONS
https://metalink2.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=273924.1
Note: 215463.1 - ORA-01031 Insufficient Privileges When Create A Materialized View Log In Different Schema
https://metalink2.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=215463.1
Regards,
Hussein

FTS on small Materialized View, should I cache it in the KEEP Pool ?

Similar Messages

Maybe you are looking for