Can we do Dml statements on materialize views

I want to know can we do Dml statements on materialize views .If yes, how

Can you? Maybe. Depends on how you created the materialized view. Should you? Maybe. Are you running a multi-master environment? Or are you using materialized views for one-way replication? If you are doing one-way replication, do you want your DML changes to be retained beyond the next refresh of the materialized view?
Justin

Similar Messages

DML operations on multiple views

Hi all.
I can't understand updateing the data on views which created by multiple table joining. Which columns I can update and why I'm getting
ORA-01779: cannot modify a column which maps to a non key-preserved table error??
Can anybody show me explanation with examples??
Thanks...

Modifying a Join View
A modifiable join view is a view that contains more than one table in the top
level FROM clause of the SELECT statement, and that does not contain any of
the following:
- DISTINCT operator
- aggregate functions: AVG, COUNT, GLB, MAX, MIN, STDDEV, SUM, or VARIANCE
- set operations: UNION, UNION ALL, INTERSECT, MINUS
- GROUP BY or HAVING clauses
- START WITH or CONNECT BY clauses
- ROWNUM pseudocolumn
With some restrictions, you can modify views that involve joins. If a view is
a join on other nested views, then the other nested views must be mergeable
into the top level view.
The examples in following sections use the EMP and DEPT tables. These examples
work only if you explicitly define the primary and foreign keys in these
tables, or define unique indexes. Following are the appropriately constrained
table definitions for EMP and DEPT:
CREATE TABLE dept
    deptno NUMBER(4) PRIMARY KEY,
    dname VARCHAR2(14),
    loc VARCHAR2(13)
CREATE TABLE emp
    empno NUMBER(4) PRIMARY KEY,
    ename VARCHAR2(10),
    job varchar2(9),
    mgr NUMBER(4),
    hiredate DATE,
    sal NUMBER(7,2),
    comm NUMBER(7,2),
    deptno NUMBER(2),
    FOREIGN KEY (DEPTNO) REFERENCES DEPT(DEPTNO)
You could also omit the primary and foreign key constraints listed above, and
create a UNIQUE INDEX on DEPT (DEPTNO) to make the following examples work.
CREATE OR REPLACE VIEW emp_dept AS
    SELECT empno, ename, sal, e.deptno, dname, loc
    FROM EMP e, DEPT d
    WHERE e.deptno = d.deptno;
Key-Preserved Tables
The concept of a key-preserved table is fundamental to understanding the
restrictions on modifying join views. A table is key preserved if every key of
the table can also be a key of the result of the join. So, a key-preserved
table has its keys preserved through a join.
Note: It is not necessary that the key or keys of a table be selected for it
to be key preserved. It is sufficient that if the key or keys were selected,
then they would also be key(s) of the result of the join.
Attention: The key-preserving property of a table does not depend on the
actual data in the table. It is, rather, a property of its schema and not of
the data in the table. For example, if in the EMP table there was at most one
employee in each department, then DEPT.DEPTNO would be unique in the result of
a join of EMP and DEPT, but DEPT would still not be a key-preserved table.
If you SELECT all rows from EMP_DEPT view, the results are:
SELECT * FROM EMP_DEPT;
EMPNO ENAME SAL DEPTNO DNAME      LOC
   7369 SMITH   800     20 RESEARCH   DALLAS
   7499 ALLEN 1600     30 SALES      CHICAGO
   7521 WARD   1250     30 SALES      CHICAGO
   7566 JONES 2975     20 RESEARCH   DALLAS
   7654 MARTIN 1250     30 SALES      CHICAGO
   7698 BLAKE 2850     30 SALES      CHICAGO
   7782 CLARK 2695     10 ACCOUNTING NEW YORK
   7788 SCOTT 3000     20 RESEARCH   DALLAS
   7839 KING   5500     10 ACCOUNTING NEW YORK
   7844 TURNER 1500     30 SALES      CHICAGO
   7876 ADAMS 1100     20 RESEARCH   DALLAS
   7900 JAMES   950     30 SALES      CHICAGO
   7902 FORD   3000     20 RESEARCH   DALLAS
   7934 MILLER 1430     10 ACCOUNTING NEW YORK
14 rows selected.
In this view, EMP is a key-preserved table, because EMPNO is a key of the EMP
table, and also a key of the result of the join. DEPT is not a key-preserved
table, because although DEPTNO is a key of the DEPT table, it is not a key of
the join.
DML Statements and Join Views
=============================
!!!!!! IMPORTANT !!!!!! IMPORTANT !!!!!! IMPORTANT !!!!!! IMPORTANT !!!!!!
Any UPDATE, INSERT, or DELETE statement performed on a join view can modify
only *** one *** underlying base table.
!!!!!! IMPORTANT !!!!!! IMPORTANT !!!!!! IMPORTANT !!!!!! IMPORTANT !!!!!!
UPDATE Statements:
The following example shows an UPDATE statement that successfully modifies the
EMP_DEPT view:
UPDATE emp_dept
SET sal = sal * 1.10
WHERE deptno = 10;
The following UPDATE statement would be disallowed on the EMP_DEPT view:
UPDATE emp_dept
SET loc = 'BOSTON'
WHERE ename = 'SMITH';
This statement fails with an ORA-01779 error (cannot modify a column which
maps to a non key-preserved table), because it attempts to modify the
underlying DEPT table, and the DEPT table is not key preserved in the EMP_DEPT
view.
In general, all modifiable columns of a join view must map to columns of a
key-preserved table. If the view is defined using the WITH CHECK OPTION
clause, then all join columns and all columns of repeated tables are not
modifiable.
So, for example, if the EMP_DEPT view were defined using WITH CHECK OPTION,
the following UPDATE statement would fail:
UPDATE emp_dept
SET deptno = 10
WHERE ename = 'SMITH';
The statement fails because it is trying to update a join column.
DELETE Statements:
You can delete from a join view provided there is one and only one
key-preserved table in the join.
The following DELETE statement works on the EMP_DEPT view:
DELETE FROM emp_dept
WHERE ename = 'SMITH';
This DELETE statement on the EMP_DEPT view is legal because it can be
translated to a DELETE operation on the base EMP table, and because the EMP
table is the only key-preserved table in the join.
In the following view, a DELETE operation cannot be performed on the view
because both E1 and E2 are key-preserved tables:
CREATE VIEW emp_emp AS
    SELECT e1.ename, e2.empno, deptno
    FROM emp e1, emp e2
    WHERE e1.empno = e2.empno;
If a view is defined using the WITH CHECK OPTION clause and the keypreserved
table is repeated, then rows cannot be deleted from such a view:
CREATE VIEW emp_mgr AS
    SELECT e1.ename, e2.ename mname
    FROM emp e1, emp e2
    WHERE e1.mgr = e2.empno
    WITH CHECK OPTION;
No deletion can be performed on this view because the view involves a
self-join of the table that is key preserved.
INSERT Statements:
The following INSERT statement on the EMP_DEPT view succeeds:
INSERT INTO emp_dept (ename, empno, deptno)
VALUES ('KURODA', 9010, 40);
This statement works because only one key-preserved base table is being
modified (EMP), and 40 is a valid DEPTNO in the DEPT table (thus satisfying
the FOREIGN KEY integrity constraint on the EMP table).
An INSERT statement like the following would fail for the same reason that
such an UPDATE on the base EMP table would fail: the FOREIGN KEY integrity
constraint on the EMP table is violated.
INSERT INTO emp_dept (ename, empno, deptno)
VALUES ('KURODA', 9010, 77);
The following INSERT statement would fail with an ORA-1776 error (cannot
modify more than one base table through a view).
INSERT INTO emp_dept (empno, ename, loc)
VALUES (9010, 'KURODA', 'BOSTON');
An INSERT cannot, implicitly or explicitly, refer to columns of a
non-key-preserved table. If the join view is defined using the WITH CHECK
OPTION clause, then you cannot perform an INSERT to it.
Using the UPDATABLE_ COLUMNS Views
The following views can assist you when modifying join views:
View Name               Description
USER_UPDATABLE_COLUMNS Shows all columns in all tables and views in the
                        users schema that are modifiable.
DBA_UPDATABLE_COLUMNS   Shows all columns in all tables and views in the
                        DBA schema that are modifiable.
ALL_UPDATABLE_COLUMNS   Shows all columns in all tables and views that are
                        modifiable.

Capturing DML statements fired on a databse

Is there anyway through which I can capture the DML statements that have been fired on a database when a patch is applied .
Like we can capture ddl statements using before or after ddl on database trigger ..
Is there any similar way through which we can capture DML statements?

check out this link.
Re: Track the delete operation.
Regards,
Bhagat

Rowid, DML statements

Hi,
I have two questions..
1)I have a table called accounts with a column accountid. I have an index with accountid which is also the primary key.
Is accessing a record faster with rowid or accountid?
2)How can I trap DML statements in a PL/SQL block? Even if the particular record is not found, it does not return any error?
Any help greatly appreciated?
Thanks,
Jyoti

Access through ROWID is the fastest way because the ROWID contains the physical address of the row. The disadvantage is that the ROWID can change without you knowing it. You must not use this method unless you are a 100% sure that the table is really static (even then, an export and import can change the ROWID).
To trap DML statements in PL/SQL you can use the packages dbms_output or utl_file. Those packages allow you to write to screen or file. For error handling you must use the EXCEPTION clause.
null

Will Materialized view log reduces the performance of DML statements on the master table

Hi all,
I need to refresh a on demand fast refresh Materialized view in Oracle 11GR2. For this purpose I created a Materialized view log on the table (Non partitioned) in which records will be inserted @ rate of 5000/day as follows.
CREATE MATERIALIZED VIEW LOG ON NOTES NOLOGGING WITH PRIMARY KEY INCLUDING NEW VALUES;
This table already has 20L records and adding this Mview log will reduce the DML performance on the table ?
Please guide me on this.

Having the base table maintain a materialised view log will have an impact on the speed of DML statements - they are doing extra work, which will take extra time. A more sensible question would be to ask whether it will have a significant impact, to which the answer is almost certainly "no".
5000 records inserted a day is nothing. Adding a view log to the heap really shouldn't cause any trouble at all - but ultimately only your own testing can establish that.

If we use DML statement in function then that function can be used inside s

if we use DML statement in function then that function can be used inside select query or any DML query?

select f from t2;I think you meant to query t1.
It works if the function is an autonomous transaction:
create or replace function f return number
is
PRAGMA AUTONOMOUS_TRANSACTION;
begin
    update t1 set c=2;
    commit;
    return 1;
end;
select f from t1But as Billy said why would you want to do DML this way. And this is not the way autonomous procedures should be used either.
An an answer to an interview question though nothing wrong with it.

Can we write the select statement on maintence view for data retreval

Can we use the select statement on maintence view
Regrads
Diva

No. U cannot write a select on maintenance view.

How to monitor DML statements

Hi pals,
I want to know how i can monitor DML statements, i can able to monitor select statments but don't DML statements, is there any way or script in following format:
Executer,Statement,%Completed,%left,Exec_Time,Time_left
Where
Executer is a user who runs the statement
Statement which statement runs
%completed how much DML operation completed
%left how much DML operation left
Exec_Time elapsed time
time_left how much time remaining in complete operation
I really apperciate you pals if you can give me some idea how this can be possible??
Thanks in advance
Hassan Khan

Hi,
These info can be found in V$SESSION_LOGOPS. But the view isn't populated for every query and sometimes it's a bit weird (I actually had queries that ouput 290% of "work" - parallel query side effect). Also notice that this is for long ops, and not everything will be reported there.
HTH,
Yoann.

How to find total refresh time of Materialize view?

Hello All,
I want to know the total refresh time of Materialize view. i m refreshing MV by below statement
i hv not logging the start and end time of this in process.
exec dbms_mview.refresh('EMP_MV','C','',FALSE,FALSE,0,0,0,TRUE);
So, anybody can you please know the using which database table it cab be possible?
Thanks in advance

The only way you can log the refresh time for each execution is to wrap the call inside a procedure that also logs the start and end times to a logging table.
(if you manually run the exec dbms_mview.refresh from an SQLPlus command line, you could also SET TIMING ON in SQLPlus)
Hemant K Chitale

ORA-02243:invalid ALTER INDEX or ALTER MATERIALIZES VIEW option

Hi, Friend,
I am changing all the index to another tablespace of one of my schema.When I run the DDL script,got the error:
ORA-02243:invalid ALTER INDEX or ALTER MATERIALIZES VIEW option
I checked the metalink, got nothing.Anyone can help? Thanks!

I also googled some info,like:
Oracle Error :: ORA-02243
invalid ALTER INDEX or ALTER MATERIALIZED VIEW option
Cause
An option other than INITRANS, MAXTRANS,or STORAGE is specified in an ALTER INDEX statement or in the USING INDEX clause of an ALTER MATERIALIZED VIEW statement.
Action
Specify only legal options.
But I still can't find the clue.

If statement within a view is not working correctly ?

Hi all,
maybe i am wrong but i think the if statement within a view is not working correctly. See code down below.
I would like to use the Hallo World depending on the page attribute isFrame with or without all the neccessary html tags. Therefore i have embedded the htmlb tags in an if statement. But for any reason if isframe is initial it isn't working. It would be great if anybody could help me.
<%@page language="abap"%>
<%@extension name="htmlb" prefix="htmlb"%>
<% if not isframe is initial. %>
<htmlb:content design="design2003">
     <htmlb:page title = "Top Level Navigation view">
<% endif. %>
hallo world
<% if not isframe is initial. %>
     </htmlb:page>
</htmlb:content>
<% endif. %>
thanks in advance and best regards
Matthias Hlubek

Matthias,
The short answer: your example is <b>NOT</b> going to work. The long answer will probably 5 pages to describe. So first let me rewrite the example so that it could work, and then give a short version of the long answer. Do not be disappointed if it is not totally clear. It is rather complicated. (See the nice form of IF statements that are possible since 620.)
<%@page language="abap"%>
<%@extension name="htmlb" prefix="htmlb"%>
<% if isframe is <b>NOT</b> initial. %>
<htmlb:content design="design2003">
<htmlb:page title = "Top Level Navigation view">
    hallo world
</htmlb:page>
</htmlb:content>
<% else. %>
hallo world
<% endif. %>
So why does your example not work? Let us start with a simple tag:
<htmlb:page title = "Top Level Navigation view">
</htmlb:page>
Now, for each tag, we have effectively the opening part (<htmlb:page>), an optional body, and then the closing part (</htmlb:page>). We are now at the level of the BSP runtime processing one tag. What the runtime does not know, is whether the tag wants to process its body or not. Each tag can decide dynamically at runtime whether the body should be processed. So the BSP compiler generates the following code:
DATA: tag TYPE REF TO cl_htmlb_page.
CREATE OBJECT tag.
tag->title = 'Top Level Navigation view'.
IF tag->DO_AT_BEGINNING( ) = CONTINUE.
ENDIF.
tag->DO_AT_END( ).
You should actually just debug your BSP code at ABAP level, and then you will immediately see all of this. Now, let us mix in your example with our code generation. First you simplified example:
<% if isframe is NOT initial. %>
<htmlb:page title = "Top Level Navigation view">
<% endif. %>
<% if isframe is NOT initial. %>
</htmlb:page>
<% endif. %>
And then with our generated code. Look specifically at how the IF/ENDIF blocks suddenly match!
if isframe is NOT initial.
DATA: tag TYPE REF TO cl_htmlb_page.
CREATE OBJECT tag.
tag->title = 'Top Level Navigation view'.
IF tag->DO_AT_BEGINNING( ) = CONTINUE.
endif.
if isframe is NOT initial.
ENDIF.
tag->DO_AT_END( ).
endif.
You can see that your ENDIF statements are closing IF blocks generated by the BSP compiler. Such a nesting will not work. This is a very short form of the problem, there are a number of variations, and different types of the same problem.
The only way to solve this problem, is probably to put the body into a page fragment and include it like I did above with the duplicate HelloWorld strings. But this duplicates source code. Better is to put body onto a view, that can be processed as required.
brian

Refresh Fast option in Materialize view

Dear All,
We have oracle 10g On windows.
We have database A having SCOTT schema and tables Emp and Dept.
I have another database B having TEST schema and this schema does not have any objects (Moto is to create mview on this database).
We have created DB LINK between TEST schema to SCOTT schema and planning to create materialize view in TEST schema.
Now I am confuse....
1) I am creating mview in TEST schema and i want to refresh mview increamentally. I search on internet and found only if you want to use FAST REFRESH then you must have to create log table for the base table.
--Query is
1) I am creating mview in TEST schema and my base tables are in SCOTT schema on different database. Where should i create log table(on SCOTT SCHEMA or TEST schema).
2) Does this log tables will occupy more space or log table will truncate after refresh of mview.
3) For using incremental refresh i need to use +REFRESH FORCE+ option or anything else.
4) If log table will not truncate then it will occupy more space so is there anything that we can come up out of this situation.Thanks..

1) You should create log in Scott Schema
2)
Managing Materialized View Log Space
Oracle automatically tracks which rows in a materialized view log have been used during the refreshes of materialized views, and purges these rows from the log so that the log does not grow endlessly. Because multiple simple materialized views can use the same materialized view log, rows already used to refresh one materialized view might still be needed to refresh another materialized view. Oracle does not delete rows from the log until all materialized views have used them.
For example, suppose two materialized views were created against the customers table in a master site. Oracle refreshes the customers materialized view at the spdb1 database. However, the server that manages the master table and associated materialized view log does not purge the materialized view log rows used during the refresh of this materialized view until the customers materialized view at the spdb2 database also refreshes using these rows.
Because Oracle must wait for all dependent materialized views to refresh before purging rows from a materialized view log, unwanted situations can occur that cause a materialized view log to grow indefinitely when multiple materialized views are based on the same master table or master materialized view.
For example, such situations can occur when more than one materialized view is based on a master table or master materialized view and one of the following conditions is true:
One materialized view is not configured for automatic refreshes and has not been manually refreshed for a long time.
One materialized view has an infrequent refresh interval, such as every year (365 days).
A network failure has prevented an automatic refresh of one or more of the materialized views based on the master table or master materialized view.
A network or site failure has prevented a master table or master materialized view from becoming aware that a materialized view has been dropped.
Note:
If you purge or TRUNCATE a materialized view log before a materialized view has refreshed the changes that were deleted, then the materialized view must perform a complete refresh.
Purging Rows from a Materialized View Log
Always try to keep a materialized view log as small as possible to minimize the database space that it uses. To remove rows from a materialized view log and make space for newer log records, you can perform one of the following actions:
Refresh the materialized views associated with the log so that Oracle can purge rows from the materialized view log.
Manually purge records in the log by deleting rows required only by the nth least recently refreshed materialized views.
To manually purge rows from a materialized view log, execute the PURGE_LOG procedure of the DBMS_MVIEW package at the database that contains the log. For example, to purge entries from the materialized view log of the customers table that are necessary only for the least recently refreshed materialized view, execute the following procedure:
3) REFRESH FAST
4) See step 2

Select statement on maintenance view.

Hello Friends,
I have a quick question. I have a maintenance view, and I want to do a select statement on this view in an ABAP program, but seems like the view is not filled with data when running the program.
How do I get the view to be populated at runtime in the ABAP program? the work area and the internal table is TYPE of the view..
Here's the code:
select * into wa
from view
where bukrs = P_BUKRS
vtweg in S_CHNL.
append wa to it.
endselect.
best regards B

Hello B,
Just to inform you: "You can select data only from Database Views".
You can design a work-around for this, by taking look @ the Join tables. May i know form which View you want to get the data?
BR,
Suhas

Why we cannot perform DML operations against complex views directly.

hi
can any tell me why we cannot perform DML operations against complex views directly.

Hi,
It is not easy to perform DML operations on complex views which involve more than one table as said by vissu. The reason being you may not know which columns to be updated/inserted/deleted on the base tables of the views. If it is a simple view containing a single table it is as simple as performing actions on the table.
For further details visit this
http://www.orafaq.com/wiki/View
cheers
VT

DML operations on Materialized view

Hi,
I want to know can we perform DML operations like insert/update on a materialized view?
Thanks
Deepak

Thanks Michaels. I'm able to update/insert into materialized view.
But I'm having another problem.
My materialized view is selecting rows on group by condition, but to create a MV as updatable, it should be simple.
SQL> create materialized view mv_utr_Link
2 build immediate
3 refresh force on demand
4 for update
5 enable query rewrite
6 as
7 select link_id,booking_date
8 from t_utr
9 where link_id=246229
10 group by link_id,booking_date
11 /
from t_utr
ERROR at line 8:
ORA-12013: updatable materialized views must be simple enough to do fast
refresh
If I remove the group by clause, its allowing me to create MV, but that won't solve my problem.
any workaround on that?
Thanks
Deepak

Can we do Dml statements on materialize views

Similar Messages

Maybe you are looking for