materialized view, I need a brief explanation

Similar Questions

• Materialized view error - need help

  Hi friends
  
  We have a table named weight_slip in two different places database running independently and that we need to combine these two places in a single central server table records. To this end, we try to use the view with a primary as a materialized bin code key. Below mentioned is Materialized View Query (Park and ang are 2 different oracle db).
  

  select * from weight_slip@park
  union
  select * from weight_slip@ang;

  We get the following error
  
  ORA-12015: cannot create a view fast refresh materialized by a complex query
  
  Please suggest a way to overcome this error or suggest any other way to get this job
  
  Concerning
  Park

  Hello

  You perform a UNION - a set based operations with a unique genre that prevents him from being eligible to fast refresh. You should be able to do a full refresh, however.

  David

• need help on the name of the column in double materialized view ORA-00957

  I have a query, long enough and several (8ways) joins.
  
  When I run it as a SQL query, it is fine.
  
  When I add create materialized, view myViewName it errors with
  ORA-00957: duplicate column name.
  
  How is there is no problem when executing the SQL statement, and how to fix this?
  
  Thank you.

  Hello

  Columns in a query do not need a unique name:

  SELECT     dummy
  ,     dummy
  FROM     dual;
  
  D D
  - -
  X X
  

  At least not in SQL * Plus; other front ends might oppose it.
  In previous versions of Oracle, subqueries (such as online views) does not need to have unique names, but you've got an error if you tried to reference a non-unique column (and it is unnecessary to have the column if never reference you).

  Columns in a table or a view need unique names:

  CREATE OR REPLACE VIEW view_x
  AS
  SELECT     dummy
  ,     dummy
  FROM     dual;
  
  ,     dummy
        *
  ERROR at line 4:
  ORA-00957: duplicate column name
  

• Difference between the table and Materialized View

  Is there an advantage outside automatic synchronization (founded refresh selected type) using Materialized View?

  I came across this question as table and MV both store values, and we can also update table using the code what is the need of MV? Why not create a table instead of MV with the same definition and same charly?

  I need some explanation to force someone to convince himself.

  Thank you

  http://docs.Oracle.com/CD/B19306_01/server.102/b14223/basicmv.htm

  Sections that highlight its strengths:

  1. materialized views for data warehouses

  2. materialized views for distributed computing

  Query, re - write, features as Materialized view log files that can be used for replication between databases, etc...

• A drop materialized view error

  I tried to drop two materialized views (I want to drop one and the other as a test to make sure that the behavior was consistent) with SQL Developer today, using the GUI, not the window of SQL command. When I did this, Developer SQL with these MVs among the tables, he tried to run a 'DROP TABLE' rather than a 'DROP MATERIALIZED VIEW' statement and an ugly error message came up with that and of course she didn't. Is this a bug that needs to be addressed? Or maybe that it is already identified and addressed in a future version?

  Earl

  Looks like you're down the underlying table, not the materialized view.   If you have a my_mv of materialized view, there is also a table called my_mv.

  You must drop the materialized since the Materialized View node in Object Explorer view.

• Trigger on the materialized view

  Hello

  I have the scenario based (Database 11 g):

  There is a view materialized (PERSON), which contains the ID and NAME fields. This MV is update daily with a fast refresh.

  I have a second array (NAMES), with ID and NORM_NAME. This table contains the name of the person, without special characters.

  For example, for recording / * 1 BJORN * / in the PERSON table

  I would check * 1 BJORN * / in table NAMES.

  
  

  Problem is how to fill the NAME table after the filling of the materialized view.

  I used a trigger AFTER INSERT or update, as described below, but even if I update the master table (for this purpose, update the MV), I have only to trigger inserts.

  
  

  Is there a way to implement a trigger "after update" on a materialized view, or do I need another approach?
  

  
  

  /*

  
  

  create or replace TRIGGER TRG_TESTE_MV

  AFTER INSERT OR UPDATE ON THE PERSON

  REFERENCING OLD AS OLD AGAIN AS NEW

  FOR EACH LINE

  BEGIN

  IF THE INSERTION

  INSERT THE NAMES

  VALUES

  (: NEW.id,:NEW.NAME);

  END IF;

  IF THE UPDATE CAN

  UPDATE OF NAMES

  SET NAME =: NEW.NAME WHERE ID =: NEW.id;

  END IF;

  END;

  */

  Thanks for any help

  Your trigger fires, but I doubted that you will be satisfied with the results. You really need to understand how to refresh process works before you begin creating triggers of MV:

  SQL > create table emp1 in select * from EMP
  2.

  Table created.

  SQL > create materialized view emp1 with rowid journal
  2.

  Materialized view log that is created.

  SQL > create materialized view emp1_mv
  2 fast refresh
  3 on request
  4 with rowid
  5 as
  6 select * from emp1
  7.

  Materialized view created.

  SQL > create or replace
  trigger 2 emp1_mv_biudr
  3 before inserting
  4 or update
  5 or delete
  6 on emp1_mv
  7 for each line
  Start 8
  9 insert then dbms_output.put_line ('INSERT' |: new.ename); end if;
  10 if the deletion then dbms_output.put_line ('REMOVE' |: old.ename); end if;
  11 end;
  12.

  Trigger created.

  SQL > insert
  2 in emp1 (empno, ename, sal)
  3 values(1,'X',1000)
  4.

  1 line of creation.

  SQL > validation
  2.

  Validation complete.

  SQL > set serveroutput on
  SQL > exec dbms_mview.refresh ('emp1_mv', 'f');
  INSERTION OF X

  PL/SQL procedure successfully completed.

  SQL > update emp1
  2 set sal = sal + 1
  3 where ename ('King', 'JONES')
  4.

  2 lines to date.

  SQL > validation
  2.

  Validation complete.

  SQL > set serveroutput on
  SQL > exec dbms_mview.refresh ('emp1_mv', 'f');
  INSERTION OF JONES
  INSERTION OF KING

  PL/SQL procedure successfully completed.

  SQL > delete emp1
  2 where in ename ('ALLEN', 'SMITH')
  3.

  2 deleted rows.

  SQL > validation
  2.

  Validation complete.

  SQL > set serveroutput on
  SQL > exec dbms_mview.refresh ('emp1_mv', 'f');

  PL/SQL procedure successfully completed.

  SQL >

  As you can see, refresh MV updates ever. Results update underlying table to remove/insert in MV. That's why your trigger will not give the results that you expected.

  SY.

• tabletop pre-constructed - materialized view Refresh

  Hi all

  Please help me to learn how to work with the materialized on pre-constructed table view.

  I created the table predefined:

  CREATE TABLE 'MISS '. "" TMP003 ".

  (

  "ITEM_ID" NUMBER (10.0)

  ) ;

  I created a materialized on predefined table view:

  CREATE A MATERIALIZED VIEW "MISS." "' TMP003 ' ('ITEM_ID')

  ON PREBUILT TABLE

  AS SOME "COST_DETAIL_ITEMS". "' ITEM_ID ' 'ITEM_ID' TO 'MISS '. "COST_DETAIL_ITEMS"@EFLP2. EFLATBED.COM 'COST_DETAIL_ITEMS ';

  I checked the amount of lines to the original source object:

  SELECT count (1) you cnt OF 'MISS '. "COST_DETAIL_ITEMS"@EFLP2. EFLATBED.COM 'COST_DETAIL_ITEMS ';

  CNT

  -----

  61047571

  I checked the amount of lines to the object of my result:

  Select count (1) cnt of 'MISS '. "" TMP003 ".

  CNT

  ----------

  0

  I tried to update the object with the result:

  DBMS_MVIEW exec. REFRESH('RATER.) TMP003');

  anonymous block filled

  I checked the amount of lines to my profitability after trying to update:

  Select count (1) cnt of 'MISS '. "" TMP003 ".

  CNT

  ----------

  0

  Please help me understand how to refresh my result object properly.

  Thank you.

  You will need to start by filling out the basic pre-built using table create table in select

  concerning

  Pravin

• What is the desertion of orderly materialized view with MLOG$.

  I have 11.2.4.0 Oracle enterprise edition.

  I want to remove completely the MATERIALIZED view and MATERIALIZED view logs.

  
  

  I need to do this on a production of databases.

  
  

  It's the right order?

  Thank you.

  You can drop the materialized view log first, then the materialized views.

  Because when you drop a materialized view log is therefore more available to fast refresh, however, it is available to rewrite, so drop materialized view log first, then materialized views. Additional information provided below may help Doc Oracle.

  If you delete a simple materialized view that is the least recently refreshed materialized view of a main table, then the database automatically purges the materialized master table see only connect the required lines to refresh the materialized view has fallen.

  If you delete a materialized view that was created on a predefined table, then the database removes the materialized view, and table preconstruitse returns to his identity in a table.

  When you delete a master table, the database does not automatically drop the materialized views based on the table. However, the database returns an error when it tries to refresh materialized view based on a main table that has been abandoned.

  If you delete a materialized view, then all the compiled queries that have been rewritten to use the materialized view will be invalidated and recompiled automatically. If the materialized view was preconstruitse on a table, then the table is not deleted, but it can no longer be maintained by the materialized view refresh mechanism.

• Materialized view does not quickly refresh with sysdate in where clause

  Hi all

  I am trying to create a view, materialized with sysdate in where clause. This makes the complex query, and so I can't create a quick refreshment mview.

  I tried to create with rowid too, but it does not create a quick refreshment.

  I was wondering if someone can advise me, how can I accomplish this task, which would be really appreciated.

  The query is:

  create a materialized view PS_MEETING

  build the DEFERRED payment

  Refresh quickly with rowid

  as

  SELECT *.

  MEETING M

  WHERE state_desc = 'VIC '.

  OR Meet_date < TRUNC (SYSDATE);

  the behavior is documented: http://docs.oracle.com/cd/E11882_01/server.112/e25554/basicmv.htm#DWHSG8201

  General restrictions on update quickly

  The definition of the materialized view query is limited as follows:

  • The materialized view must not contain references to non-repetitive phrases such as SYSDATE and ROWNUM .

  So I guess that you would need a more static than sysdate condition - or another strategy update.

• Re: view opaque and the materialized view

  Hi Experts,

  I want some clarification of opaque and view view in the physical layer OBIEE materialized

  -> what is the main difference between the opaque view and materialized in the RPD perspective view, we have to do this at the level of the RPD or DB.

  -> I want the list of opaque opinion and materialized in the RPD view how I should do.

  -> How opaque views will degrade the performance and how a materialized view will improve performance at the level of the report.

  -> In scenarios that we use view opaque and the view materialized (if possible with a scenario for the best permanent basis).

  Thanks in advance.

  I want some clarification of opaque and view view in the physical layer OBIEE materialized

  -> What is the main difference between opaque view and create the materialized view in the RPD point of view, we have to do this at the level of the RPD or DB.

  Opaque views is a SQL statement that is defined in the physical layer, OBIEE will use all in the construction of a SQL query. In a way it's not different from a database view, except it is set in OBIEE only. Alternatively, you can deploy an Opaque view, which pushes its definition in the database. Read more about it here: work with physical tables, Cubes and joins - 11 g Release 1 (11.1.1)

  A materialized view (MV) is a database concept where the results of a SQL statement are physicalised like a table, and therefore as OBIEE is a MV is just another physical array

  -> If I want a list of the opaque views and materialized in the RPD view how I should do.

  To find opaque views, use the function «Repository of applications» administration tool Search physical Tables and set up a filter on the Type = Select

  Screenshot: https://www.evernote.com/shard/s16/sh/5c843e47-bff1-4d4b-b847-be98f3a2ec09/cf060a6cd9805f687fa0b5b46f3f0020

  To find materialized views, you will need to query the catalog in your database (for example select object_name, object_type from user_objects where type_objet = "MATERIALIZED VIEW" ;) and compare it to the list of tables in your SPR)

  -> How opaque views will degrade the performance and how a materialized view will improve performance at the level of the report.

  A materialized view is materialized, in other words, the results are already stored in the database. This means usually there will be more efficient because all the joins and aggregations, etc. will be settled in advance.

• Drop materialized view does not go down?

  SQL > drop materialized view MV_SONG;

  Materialized view is deleted.

  SQL > drop materialized view MV_SONG;

  Materialized view is deleted.

  SQL > drop materialized view MV_SONG;

  Materialized view is deleted.

  Very weird, I need to drop this MV in order to create a new.  I am not in a position from the drop.  Said Materialized view has declined, but he didn't fall.

  SQL > select * from v version $;

  BANNER

  --------------------------------------------------------------------------------

  Oracle Database 11 g Enterprise Edition Release 11.2.0.3.0 - 64 bit Production

  PL/SQL Release 11.2.0.3.0 - Production

  CORE Production 11.2.0.3.0

  AMT for Linux: Version 11.2.0.3.0 - Production

  NLSRTL Version 11.2.0.3.0 - Production

  SQL > select object_name, object_type, created, status from user_objects where object_name = 'MV_SONG ';

  OBJECT_NAM CREATED STATUS OBJECT_TYPE

  ---------- ------------------- --------- -------

  MV_SONG INVALID MATERIALIZED VIEW JULY 29, 11

  Here's more information:

  SQL > drop materialized view mv_song;

  Materialized view is deleted.

  SQL > select * from mv_song;

  Select * from mv_song

  *

  ERROR on line 1:

  ORA-00942: table or view does not exist

  SQL > create a materialized view force discount MV_SONG on request as select sysdate to double;

  create materialized view refresh MV_SONG force on demand as select sysdate double

  *

  ERROR on line 1:

  ORA-00955: name is already used by an existing object

  I asked the support of oracle, can't seem to find an article on the subject.

  Need advice.

  Thank you

  Steeve

  There is a bug, that dropping a materialized view leaves behind a summary that stop the materialized view to be properly cleaned and dropped in the data dictionary.

  Connect as sysdba and check DBA_SUMMARIES to an entry of your materialized view. If he doesn't make one: drop summary OWNER. MV_NAME;

  That should drop your MV successfully.

• Materialized view: when to use a full refresh

  Thank you in advance, I read in the book of the Oracle University - "a complete refresh of a materialized view is to truncate the existing data and reinsert all data based on detail tables, re-running the query definition to CREATE order. Quick updates apply only changes since the last update. My question is what we need to complete refresh because the data in the table created for the two methods are ultimately the same and fast refresh is more "quickly"?

  Well, I don't know about the Oracle University book, but Oracle manual list a long list of restrictions when fast updating is not possible. I hope that answers your question.

  SY.

• extracting data from the CLOB using materialized views

  Hello

  We have xml data from clob which I have a requirement to extract (~ 50 attributes) on a daily basis, so we decided to use materialized views with refreshes full (open good suggestions)

  A small snippet of code

  CREATE THE MWMRPT MATERIALIZED VIEW. TASK_INBOUND

  IMMEDIATE CONSTRUCTION

  FULL REFRESH ON DEMAND

  WITH ROWID

  AS

  SELECT M.TASK_ID, M.BO_STATUS_CD, b.*

  OF CISADM. M1_TASK m,

  XMLTABLE (' / a ' XMLPARSE PASSING ())

  CONTENT '< a > | M.BO_DATA_AREA | "< /a >."

  ) COLUMNS

  serviceDeliverySiteId varchar2 (15) PATH

  "cmPCGeneralInfo/serviceDeliverySiteId"

  serviceSequenceId varchar2 (3) PATH "cmPCGeneralInfo/serviceSequenceId"

  completedByAssignmentId varchar2 (50) PATH "completedByAssignmentId."

  Cust_id varchar2 (10) PATH "cmPCCustomerInformation/customerId,"

  ACCT_SEQ varchar2 (5) PATH "customerInformation/accountId"

  AGRMT_SEQ varchar2 (5) PATH cmPCCustomerAgreement/agreementId"."

  COLL_SEQ varchar2 (5) PATH "cmPCGeneralInfo/accountCollectionSeq"

  REVENUE_CLASS varchar2 (10) PATH "cmPCCustomerAgreement/revenueClassCode"

  REQUESTED_BY varchar2 (50) PATH ' attributes customerInformation/contactName',...~50

  This ddl ran > 20 hours and no materialized view created. There are certain limits that we have

  • Cannot create a materialized view log
  • cannot change the source as its defined provider table
  • cannot do an ETL

  DB is 11g R2

  Any ideas/suggestions are very much appreciated

  I explored a similar approach, using the following test case.

  It creates a table "MASTER_TABLE" containing 20,000 lines and a CLOB containing an XML fragment like this:

  09HOLVUF3T6VX5QUN8UBV9BRW3FHRB9JFO4TSV79R6J87QWVGN

  UUL47WDW6C63YIIBOP1X4FEEJ2Z7NCR9BDFHGSLA5YZ5SAH8Y8

  O1BU1EXLBU945HQLLFB3LUO03XPWMHBN8Y7SO8YRCQXRSWKKL4

  ...

  1HT88050QIGOPGUHGS9RKK54YP7W6OOI6NXVM107GM47R5LUNC

  9FJ1JZ615EOUIX6EKBIVOWFDYCPQZM2HBQQ8HDP3ABVJ5N1OJA

  then an intermediate table "MASTER_TABLE_XML" with the same columns with the exception of the CLOB which turns into XMLType and finally a MVIEW:

  SQL > create table master_table like

  2. Select level as id

  3, cast ('ROW' | to_char (Level) as varchar2 (30)) as the name

  4       , (

  5. Select xmlserialize (content

  XMLAGG 6)

  7 xmlelement (evalname ('ThisIsElement' | to_char (Level)), dbms_random.string ('X', 50))

  8                    )

  9 as clob dash

  10                  )

  11 double

  12 connect by level<=>

  (13) as xmlcontent

  14 double

  15 connect by level<= 20000="">

  Table created.

  SQL > call dbms_stats.gather_table_stats (user, 'MASTER_TABLE');

  Calls made.

  SQL > create table (master_table_xml)

  Identification number 2

  3, name varchar2 (30)

  4, xmlcontent xmltype

  5)

  binary xmltype 6 securefile XML column xmlcontent store

  7;

  Table created.

  SQL > create materialized view master_table_mv

  2 build postponed

  full 3 Refresh on demand

  4, as

  5. Select t.id

  6, t.nom

  7       , x.*

  master_table_xml 8 t

  9, xmltable ('/ r' in passing t.xmlcontent)

  10 columns

  11 path of varchar2 (50) ThisIsElement1 'ThisIsElement1 '.

  12, path of varchar2 (50) ThisIsElement2 'ThisIsElement2 '.

  13, path of varchar2 (50) ThisIsElement3 'ThisIsElement3 '.

  14, path of varchar2 (50) ThisIsElement4 'ThisIsElement4 '.

  15 road of varchar2 (50) ThisIsElement5 'ThisIsElement5 '.

  16, road of varchar2 (50) ThisIsElement6 'ThisIsElement6 '.

  17 road of varchar2 (50) ThisIsElement7 'ThisIsElement7 '.

  18 road of varchar2 (50) ThisIsElement8 'ThisIsElement8 '.

  19 road to varchar2 (50) ThisIsElement9 'ThisIsElement9 '.

  20, path of varchar2 (50) ThisIsElement10 'ThisIsElement10 '.

  21, road to varchar2 (50) ThisIsElement11 'ThisIsElement11 '.

  22 road of varchar2 (50) ThisIsElement12 'ThisIsElement12 '.

  23 road of varchar2 (50) ThisIsElement13 'ThisIsElement13 '.

  24, path of varchar2 (50) ThisIsElement14 'ThisIsElement14 '.

  25 road of varchar2 (50) ThisIsElement15 'ThisIsElement15 '.

  26, path of varchar2 (50) ThisIsElement16 'ThisIsElement16 '.

  27, way to varchar2 (50) ThisIsElement17 'ThisIsElement17 '.

  28 road of varchar2 (50) ThisIsElement18 'ThisIsElement18 '.

  29 road of varchar2 (50) ThisIsElement19 'ThisIsElement19 '.

  30, path of varchar2 (50) ThisIsElement20 'ThisIsElement20 '.

  31, path of varchar2 (50) ThisIsElement21 'ThisIsElement21 '.

  32 road of varchar2 (50) ThisIsElement22 'ThisIsElement22 '.

  33, path of varchar2 (50) ThisIsElement23 'ThisIsElement23 '.

  34 road of varchar2 (50) ThisIsElement24 'ThisIsElement24 '.

  35 road of varchar2 (50) ThisIsElement25 'ThisIsElement25 '.

  36, road to varchar2 (50) ThisIsElement26 'ThisIsElement26 '.

  37, path of varchar2 (50) ThisIsElement27 'ThisIsElement27 '.

  38, path of varchar2 (50) ThisIsElement28 'ThisIsElement28 '.

  39, path of varchar2 (50) ThisIsElement29 'ThisIsElement29 '.

  40, road of varchar2 (50) ThisIsElement30 'ThisIsElement30 '.

  41 road of varchar2 (50) ThisIsElement31 'ThisIsElement31 '.

  42, path of varchar2 (50) ThisIsElement32 'ThisIsElement32 '.

  43, road to varchar2 (50) ThisIsElement33 'ThisIsElement33 '.

  44, path of varchar2 (50) ThisIsElement34 'ThisIsElement34 '.

  45, path of varchar2 (50) ThisIsElement35 'ThisIsElement35 '.

  46, path of varchar2 (50) ThisIsElement36 'ThisIsElement36 '.

  47, path of varchar2 (50) ThisIsElement37 'ThisIsElement37 '.

  48, path of varchar2 (50) ThisIsElement38 'ThisIsElement38 '.

  49, path of varchar2 (50) ThisIsElement39 'ThisIsElement39 '.

  50 road of varchar2 (50) ThisIsElement40 'ThisIsElement40 '.

  51, path of varchar2 (50) ThisIsElement41 'ThisIsElement41 '.

  52, path of varchar2 (50) ThisIsElement42 'ThisIsElement42 '.

  53, path of varchar2 (50) ThisIsElement43 'ThisIsElement43 '.

  54, path of varchar2 (50) ThisIsElement44 'ThisIsElement44 '.

  55 road of varchar2 (50) ThisIsElement45 'ThisIsElement45 '.

  56, path of varchar2 (50) ThisIsElement46 'ThisIsElement46 '.

  57, path of varchar2 (50) ThisIsElement47 'ThisIsElement47 '.

  58 road of varchar2 (50) ThisIsElement48 'ThisIsElement48 '.

  59 road of varchar2 (50) ThisIsElement49 'ThisIsElement49 '.

  60 road of varchar2 (50) ThisIsElement50 'ThisIsElement50 '.

  (61) x;

  Materialized view created.

  The discount is then performed in two steps:

  1. INSERT INTO master_table_xml
  2. Refresh the MVIEW

  (Note: as we insert in an XMLType column, we need an XML (only root) document this time)

  SQL > set timing on

  SQL >

  SQL > truncate table master_table_xml;

  Table truncated.

  Elapsed time: 00:00:00.27

  SQL >

  SQL > insert into master_table_xml

  2. select id

  3, name

  4, xmlparse (document '' |) XmlContent |'')

  5 master_table;

  20000 rows created.

  Elapsed time: 00:04:38.72

  SQL >

  SQL > call dbms_mview.refresh ('MASTER_TABLE_MV');

  Calls made.

  Elapsed time: 00:00:22.42

  SQL >

  SQL > select count (*) in the master_table_mv;

  COUNT (*)

  ----------

  20000

  Elapsed time: 00:00:01.38

  SQL > truncate table master_table_xml;

  Table truncated.

  Elapsed time: 00:00:00.41

• term materialized view for update

  Hello

  Work on 10g

  I created a materialized as fast refresh view on commit.

  I need to know how long took for the update.

  I tried the below but could not get any results.

  SELECT increfreshtim FROM dba_mview_analysis, fullrefreshtim, last_refresh_date, mview_name

  Thanks in advance.

  It works for me. Post your MView definition and the output of queries, similar to what I posted.

  SQL > create table test_table as select level l, col of dbms_random.string ('A', 5) from dual connect by level<=>

  SQL > alter table test_table add constraint pk_test_table_l key (l) primary;

  SQL > create materialized view test_table; journal

  SQL > create a materialized view mv_all_objects cool off quickly in select * from test_table;

  Materialized view created.

  SQL > ed
  A written file afiedt.buf

  1. Select the owner, mview_name, last_refresh_date, refresh_method, fullrefreshtim, increfreshtim, query
  2 of dba_mview_analysis
  3 * where mview_name = 'MV_ALL_OBJECTS. '
  SQL > /.

  OWNER MVIEW_NAME REFRESH_ FULLREFRESHTIM INCREFRESHTIM QUERY LAST_REFR
  ------------------------------ ------------------------------ --------- -------- -------------- ------------- --------------------------------------------------------------------------------
  FDL_BAU MV_ALL_OBJECTS OCTOBER 8, 13 FAST 0 0 SELECT 'TEST_TABLE '. "' L ' 'L', 'TABLE_TEST '. «"COL" 'COL' OF 'TABLE_TEST' TEST_TAB «»

  -Insertion of data more

  SQL > insert test_table select 100000 + level l, col of dbms_random.string ('A', 5) from dual connect by level<=>

  SQL > exec dbms_mview.refresh ('MV_ALL_OBJECTS', 'F');

  PL/SQL procedure successfully completed.

  SQL > ed
  A written file afiedt.buf

  1. Select the owner, mview_name, last_refresh_date, refresh_method, fullrefreshtim, increfreshtim, query
  2 of dba_mview_analysis
  3 * where mview_name = 'MV_ALL_OBJECTS. '
  SQL > /.

  OWNER MVIEW_NAME REFRESH_ FULLREFRESHTIM INCREFRESHTIM QUERY LAST_REFR
  ------------------------------ ------------------------------ --------- -------- -------------- ------------- --------------------------------------------------------------------------------
  FDL_BAU MV_ALL_OBJECTS 8 OCTOBER 13 0 16 QUICK SELECT 'TEST_TABLE '. "' L ' 'L', 'TABLE_TEST '. «"COL" 'COL' OF 'TABLE_TEST' TEST_TAB «»

  SQL > drop materialized view log on test_table;

  Materialized view save ignored.

  SQL > drop mv_all_objects view materialized;

  Materialized view is deleted.

  SQL >

  The INCREFRESHTIM shows that it took 16 seconds to refresh the MView.

• Problems with the materialized view

  Hello

  I need help enforce data integrity using a materialized view. In my example, each system can consist of three types of components, and it is modeled using the supertype/subtype relationships. I'm trying to argue that, for a given system, a component cannot reside in more than one table of components. For example, given the system 1, if A component exists in the mobile_components table, it is impossible to insert into the table desktop_components for system 1. Rather than using triggers, I try to use views materialized with unique constraint to enforce this rule based on the example of "The trouble with triggers" article http://www.oracle.com/technetwork/issue-archive/2008/08-sep/o58asktom-101055.html of Tom Kyte. However, I can't seem to make it work because it gives me ORA-12054: cannot set the ON COMMIT refresh attribute.  I use UNION ALL and I know that can be difficult, but I can not understand what are the rules I'm breaking.  I have the necessary privileges.  Oracle 11g.  Can anyone help?

  Thank you

  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 column marker to distinguish which questions you Union, that the data are:

  for example

  Create materialized view mv_components

  cool off quickly on commit with rowid as

  Select 'a' marker, rowid as row_id, mo_comp_id as identifiant_composant mo_comp_name as comp_name

  of mobile_components

  Union of all the

  Select 'b', rowid, de_comp_id, de_comp_name

  of desktop_components

  Union of all the

  Select 'c', rowid, in_comp_id, in_comp_name

  of internet_components;