About materialized refresh view creation and error analysis records encountered in the process

About the creation of materialized refresh views and some error analysis records encountered in the process (focusing on incremental refresh views)

1. Can a view add multiple constraints?
In the process of creating a common view, multiple constraints cannot be set, that is, with read only and with check option can only be selected
.
Yes, but when the view log is created again, it will report that it already exists, so it must be deleted by manual sql, as shown below

drop materialized view log on teacher

3. ORA-12006: a materialized view log for "xxxx"."xxx" does not record the primary key;
this question has been entangled for a long time to find the answer, it's really getting a nosebleed, record it
hereIt is because the materialized view log we created before establishing the materialized incremental refresh view is based on rowid, as shown below

create materialized view log on teacher with rowid;

And we create the materialized view sql as follows [error example]

create materialized view mv_teacher
refresh fast
as
select r.rowid ,r.name name1 from teacher r

The view is based on the primary key by default, so it cannot be created successfully, and the above error is prompted, so how should we write it so as not to report an error? ,As follows

create materialized view mv_teacher5
refresh fast with rowid -- note that this block needs to be added with rowid
as
select r.rowid rr,r.*from teacher r--rowid needs to exist, and there must be an alias

Pay attention to the comments added to the sql above, which is a point to pay attention to. With rowid, the view we build is based on rowid, and we need to alias the rowid, otherwise the creation will still be unsuccessful

. Since there is a view based on rowid, there are also The incremental refresh view based on the primary key is
defined as follows

create materialized view log on teacher with primary key;--create view log

create materialized view mv_teacher8
refresh fast [ with primary key] -- can be omitted here, because the view is based on the primary key by default
as
select * from teacher

The above are some questions about the materialized incremental refresh view, and I will continue to add it later.