I try create project but I have get to proplem
in form builder when I click right and chose data block then chose table and click in add realshenshep I get these error said 'error no master data blocks are available'
Please help me
I am waiting to reply me
Thanx
If you want the Wizard to create relationship between master and detail block, underlying tables have to be related - master table has to have a primary key, and it has to be referenced by detail table's foreign key.
Forms is capable of detecting that and, if it exists, can create the relationship.
Otherwise, if there's no such a relation between those tables, you'll have to create it manually.
[EDIT]
How to create a foreign key?
SQL> create table master
2 (id number,
3 name varchar2(20));
Table created.
SQL> create table detail
2 (id number,
3 idm number,
4 datum date
5 );
Table created.
SQL> -- create a primary key on the master table
SQL> alter table master add constraint pk_mas primary key (id);
Table altered.
SQL> -- create a foreign key on the detail table
SQL> alter table detail add constraint fk_det_mas foreign key (idm)
2 references master (id);
Table altered.
SQL>
As of manually creating a relationship: put the join condition in there, such as
detail.idm = master.id
I would like to have more than one materialized view with refresh fast on commit.
For "refresh fast on commit" you need a materialized view log. Obviously a refresh fast on commit needs the log. The question is can I have more than one materialized view accessing the log.
Obviously I still need the log to satisfy the normal prerequisites (across all views):
http://docs.oracle.com/cd/B19306_01/server.102/b14223/basicmv.htm
Cheers for any help in advance.
Absolutely.
create table data_table as (
select *
from dba_users
);
alter table data_table
add constraint data_table_test_pk PRIMARY KEY (user_id);
select * from data_table;
So now we have a table that looks like dba_users with a PRIMARY KEY constraint.
create materialized view log on data_table;
create materialized view mat_view_one
refresh fast on commit
as
select username, user_id
from data_table
;
create materialized view mat_view_two
refresh fast on commit
as
select user_id, username, account_status
from data_table;
There's our log and the 2 views create successfully.
SYS record in the test table:
select * from mat_view_one
where user_id=0;
USERNAME USER_ID
------------------------------ ----------
SYS 0
select * from mat_view_two
where user_id=0;
USER_ID USERNAME ACCOUNT_STATUS
---------- ------------------------------ --------------------------------
0 SYS OPEN
Now lets update the SYS's name and commit and see what our views show:
update data_table
set username='WALTERWHITE'
WHERE USER_ID=0
;
COMMIT;
USERNAME USER_ID
------------------------------ ----------
WALTERWHITE 0
USER_ID USERNAME ACCOUNT_STATUS
---------- ------------------------------ --------------------------------
0 WALTERWHITE OPEN
So yes, absolutely. 1 materialized view log can serve as many materialized views as you need so long as the proper constraints are held.
Yes. A materialized view log can support as many materialized views as you'd like.
Supporting multiple materialized views may cause the log to be larger than it would be if it was supporting a single materialized view though that probably isn't terribly significant here since your logs probably won't store the data long. If you're replicating data to remote databases (which by definition you can't do with a fast refreshable materialized view), it can be a bit tricky if one of the remote materialized views stops refreshing or goes away without the source being aware since it can cause data to queue up indefinitely in the log. But, again, that doesn't sound like the situation you're facing.
I just created tables DEPT and EMP like follow :
create table DEPT
( dept_no number , dept_name varchar(32) , dept_desc varchar(32),
CONSTRAINT dept_pk Primary Key (dept_no) );
create table EMP
( emp_no number, dept_no number, CONSTRAINT emp_pk Primary Key (emp_no,dept_no));
insert into dept values (10,'it','desc1');
insert into dept values (20,'hr','desc2');
insert into emp values (1,10);
insert into emp values (2,20);
I created materialized view logs on these tables with rowid and materialized views as follows:
create materialized view log on emp with rowid;
create materialized view log on dept with rowid;
create materialized view empdept_mv refresh fast on commit as
select a.rowid dept_rowid, b.rowid emp_rowid, a.dept_no,b.emp_no
from dept a, emp b
where a.dept_no=b.dept_no ;
select * from emp;
EMP_NO DEPT_NO
---------- ----------
1 10
2 20
3 30
select * from dept;
DEPT_NO DEPT_NAME DEPT_DESC
---------- -------------------------------- --------------------------------
10 it desc1
20 hr desc2
30 it desc3
select * from empdept_mv;
DEPT_ROWID EMP_ROWID DEPT_NO EMP_NO
------------------ ------------------ ---------- ----------
AAAli5AABAAAPZ6AAA AAAli7AABAAAQs6AAA 10 1
AAAli5AABAAAPZ6AAB AAAli7AABAAAQs6AAB 20 2
I inserted a new record and did COMMIT; ..but still when i check the materialized view, the new record is not shown in the materialized view.
insert into dept values (30,'it','desc3');
commit;
insert into emp values (3,30);
commit;
select * from empdept_mv;
DEPT_ROWID EMP_ROWID DEPT_NO EMP_NO
------------------ ------------------ ---------- ----------
AAAli5AABAAAPZ6AAA AAAli7AABAAAQs6AAA 10 1
AAAli5AABAAAPZ6AAB AAAli7AABAAAQs6AAB 20 2
Now, when I run the procedure for Fast and complete refresh as per, The Fast refresh does not update the Mview but the complete refresh does. ( Note: But the Mview is still REFRESH ON COMMIT)
execute DBMS_MVIEW.REFRESH('empdept_mv', 'F', '', TRUE, FALSE, 0,0,0,FALSE, FALSE);
PL/SQL procedure successfully completed.
DEPT_ROWID EMP_ROWID DEPT_NO EMP_NO
------------------ ------------------ ---------- ----------
AAAli5AABAAAPZ6AAA AAAli7AABAAAQs6AAA 10 1
AAAli5AABAAAPZ6AAB AAAli7AABAAAQs6AAB 20 2
execute DBMS_MVIEW.REFRESH('test_mview2', 'C', '', TRUE, FALSE, 0,0,0,FALSE, FALSE);
PL/SQL procedure successfully completed.
DEPT_ROWID EMP_ROWID DEPT_NO EMP_NO
------------------ ------------------ ---------- ----------
AAAli5AABAAAPZ6AAA AAAli7AABAAAQs6AAA 10 1
AAAli5AABAAAPZ6AAB AAAli7AABAAAQs6AAB 20 2
AAAli5AABAAAPZ6AAC AAAli7AABAAAQs6AAC 30 3
The DBMS_MVIEW.EXPLAIN_MVIEW output is as shown : (capability_name --Possible-- msgtxt)
PCT --N--
REFRESH_COMPLETE --Y--
REFRESH_FAST --Y--
REWRITE --N--
PCT_TABLE --N-- Oracle error: see RELATED_NUM and RELATED_TEXT for
details
REFRESH_FAST_AFTER_INSERT --Y--
REFRESH_FAST_AFTER_ONETAB_DML --Y--
REFRESH_FAST_AFTER_ANY_DML --Y--
REFRESH_FAST_PCT --N-- PCT is not possible on any of the detail
tables in the mater
REWRITE_FULL_TEXT_MATCH --N-- Oracle error: see RELATED_NUM and
RELATED_TEXT for details
REWRITE_FULL_TEXT_MATCH --N-- query rewrite is disabled on the
materialized view
REWRITE_PARTIAL_TEXT_MATCH --N-- materialized view cannot support
any type of query rewrite
REWRITE_PARTIAL_TEXT_MATCH --N-- query rewrite is disabled on the
materialized view
REWRITE_GENERAL --N-- materialized view cannot support any type of
query rewrite
REWRITE_GENERAL --N-- query rewrite is disabled on the materialized
view
REWRITE_PCT --N-- general rewrite is not possible or PCT is not
possible on an
PCT_TABLE_REWRITE --N-- Oracle error: see RELATED_NUM and
RELATED_TEXT for details
How can I achieve Fast Refresh On Commit ?
The Oracle Version details are as follows:
NLSRTL 10.2.0.4.0 Production
Oracle Database 10g 10.2.0.4.0 64bit Production
PL/SQL 10.2.0.4.0 Production
TNS for Linux: 10.2.0.4.0 Production
I don't know if the problem still persists, but as I took a look at the artice you provided, I noticed something (which might just be the solution here):
ON COMMIT Refresh
A materialized view can be refreshed automatically using the ON COMMIT method. Therefore, whenever a transaction commits which has updated the tables on which a materialized view is defined, those changes are automatically reflected in the materialized view. The advantage of using this approach is you never have to remember to refresh the materialized view. The only disadvantage is the time required to complete the commit will be slightly longer because of the extra processing involved. However, in a data warehouse, this should not be an issue because there is unlikely to be concurrent processes trying to update the same table.
Notice the bold line.
Then we have:
Table 7-1 ON DEMAND Refresh Methods
Refresh Option Parameter Description
COMPLETE C Refreshes by recalculating the defining query of the materialized view.
FAST F Refreshes by incrementally applying changes to the materialized view. For local materialized views, it chooses the refresh method which is estimated by optimizer to be most efficient. The refresh methods considered are log-based FAST and FAST_PCT.
FAST_PCT P Refreshes by recomputing the rows in the materialized view affected by changed partitions in the detail tables.
FORCE ? Attempts a fast refresh. If that is not possible, it does a complete refresh.
For local materialized views, it chooses the refresh method which is estimated by optimizer to be most efficient. The refresh methods considered are log based FAST, FAST_PCT, and COMPLETE.
Notice the bold lines.
I personally prefer the FORCE Option.
Could you please tell, if this occurs again after some time (depending of the parameters of the DB and the machine it runs on, so I can't even hint you how much)?
When Fast Refresh is Possible
Not all materialized views may be fast refreshable. Therefore, use the package DBMS_MVIEW.EXPLAIN_MVIEW to determine what refresh methods are available for a materialized view.
If you are not sure how to make a materialized view fast refreshable, you can use the DBMS_ADVISOR.TUNE_MVIEW procedure, which provides a script containing the statements required to create a fast refreshable materialized view.
Cheers
I see that you created the materialized view logs with ROWID, which is not really required as both tables have a primary key so you could try without the ROWID.
create materialized view log on emp;
create materialized view log on dept;
Additionally, if you create the materialized view log with ROWID you should create the materialized view with rowid.
create materialized view empdept_mv refresh fast on commit WITH ROWID as
select a.rowid dept_rowid, b.rowid emp_rowid, a.dept_no,b.emp_no
from dept a, emp b
where a.dept_no=b.dept_no ;
You could try those changes and see if the materialized views fast refresh on commit.
I'm trying to build a Materialized View on top of a prebuilt table. I can use the below syntax with no modifiers and it works fine.
CREATE MATERIALIZED VIEW TESTRESULT
ON PREBUILT TABLE
SELECT ...
FROM ...
WHERE ...
However, when adding extra clauses to the Materialized View, I get the error "Missing Keyword". I'm not sure what I'm missing and I can't find any documentation online in conjunnction with building on top of a prebuilt table and adding extra clauses.
CREATE MATERIALIZED VIEW TESTRESULT
NOCACHE
LOGGING
NOCOMPRESS
NOPARALLEL
BUILD IMMEDIATE
REFRESH FORCE ON DEMAND
WITH PRIMARY KEY
ON PREBUILT TABLE
AS
SELECT ...
FROM ...
WHERE ...
Oracle Verision : 10g
The ON PREBUILT TABLE option is not compatible with some of your options, as described in the CREATE MATERIALIZED VIEW documentation:
The CACHE, LOGGING, PARALLEL and COMPRESS are table properties inherited from the already built table and are therefore incompatible with PREBUILT.
the BUILD option is there to specify when the table must be populated. However the table is already populated since you've used the PREBUILT option, and the two options are therefore incompatible.
Also make sure you have the arguments is the right order.
The following works:
SQL> CREATE TABLE TEST(ID NUMBER PRIMARY KEY);
Table created
SQL> CREATE TABLE testresult(ID NUMBER);
Table created
SQL> CREATE MATERIALIZED VIEW TESTRESULT
2 ON PREBUILT TABLE
3 REFRESH FORCE ON DEMAND
4 WITH PRIMARY KEY
5 AS
6 SELECT ID
7 FROM TEST;
Materialized view created
I'm confused about Materialized views. Either it is the Toad IDE that I am using that is confusing me, or its that I don't understand MVs enough.
I created a materialized view in Oracle by something like this....
CREATE MATERIALIZED VIEW TESTRESULT
NOCACHE
LOGGING
NOCOMPRESS
NOPARALLEL
BUILD IMMEDIATE
REFRESH FORCE ON DEMAND
WITH PRIMARY KEY
AS
SELECT ...
FROM tables...
I would expect that the materialized view would be created and populated with the data returned from the query. Okay, not a big deal.
What I am confused on is why my Toad IDE shows a table 'TESTRESULT' under the tables section. It even has a 'Create Table Script' that I can look at.
But I also see my materialized view under the 'Materialized View' section.
Behind the scenes is Oracle creating a table when I create a materialized view? It looks as if there are two seperate objects, a materialized view and a table? Could someone please explain what is going on here behind the scenes when creating a materialized view? Is Toad wrong or am I misunderstanding something?
Toad version: 9.6.1.1
Oracle: 10g
Yes, behind the scenes, Oracle creates two objects, a table where the results are actually materialized and a materialized view that has all the metadata (the query, the attributes, etc.). It's very similar to what happens when you create a unique constraint-- Oracle creates a unique index with the same name as the constraint to actually enforce the constraint and then it creates a constraint itself. If you create a materialized view on a pre-built table, you can end up with different names for the table and for the materialized view just as you could create a constraint that uses an existing index that has a different name.
SQL> select object_name, object_type
2 from user_objects
3
SQL> ed
Wrote file afiedt.buf
1 select object_name, object_type
2 from user_objects
3* where object_name = 'MV_EMP'
4 /
no rows selected
SQL> create materialized view mv_emp
2 as
3 select *
4 from emp;
Materialized view created.
SQL> column object_name format a30;
SQL> select object_name, object_type
2 from user_objects
3 where object_name = 'MV_EMP';
OBJECT_NAME OBJECT_TYPE
------------------------------ -------------------
MV_EMP TABLE
MV_EMP MATERIALIZED VIEW