Not able to re-create materialized view on prebuilt table - sql

Question

Steps I am trying to execute:
CREATE TABLE sample.MV(application_mode varchar2(25));
CREATE MATERIALIZED VIEW sample.MV
ON PREBUILT TABLE
REFRESH FORCE ON DEMAND
AS
SELECT application_mode
FROM sample.tbl_name
WHERE cnt > 0;
When any other user is trying to drop and re-create the MV
DROP MATERIALIZED VIEW sample.MV;
CREATE MATERIALIZED VIEW sample.MV
ON PREBUILT TABLE
REFRESH FORCE ON DEMAND
AS
SELECT application_mode
FROM sample.tbl_name
WHERE cnt > 0;
He gets below error while re-creation:
ORA-32334: cannot create prebuilt materialized view on a table already
referenced by a MV
why is so?
User got a work around for the same which is to drop the table first
and then recreate the table, recreate the MV.
Really weird behaviour of oracle is that all the subsequent attempts of that user of dropping and re-creating MV work well with no error.

Answer 1

update 2: it really is connected to some other mview which directly or indirectly uses/used this one. (as suggested by #Marmite Bomber, but his all_snapshots based query does not help)
You can find it out with user_dependencies (or maybe all_dependencies) using something like the following query. You may have to follow some dependency graph over synonyms, views, functions etc. to find the connection.
(In my case I knew that there had been a dependency before dropping the matview with preserve table. So this table is still "somehow connected" to some depending "higher" matview and thus the error seems to be issued.)
select * from user_dependencies
where 1=1 -- for easier comment filter usage below
--and referenced_owner=user -- if only current user relevant
--and not type in ('TRIGGER') -- e.g. to skip some auto-gen. triggers
and referenced_name = '<my matview>'
order by name, referenced_name
So a working solution was to also drop the "higher"/depending mview(s) (e.g. with the preserve table option) and recreate them (e.g. with the prebuilt table option so there is no rebuilt necessary).
Previous/old findings/workarounds:
I had the same problem where I automatically "renamed" some materialized views, which is programatically not possible (11.2).
So I created new matviews from old ones
deleting them, but not the table data (preserve table) and
reassociating the existing table with the new ones (prebuilt table).
Everything worked fine but for one matview that caused this ORA-32334 :-(
Debugging with the following SQLs did not give a clue why the system thinks this table is still associated with some matview so I can only assume it is a bug with some kind of random behaviour:
select * from user_mviews
select * from user_objects
where object_name like '%<some meaningful filter criteria>%'
order by object_type, object_name
My workaround: recreating the specific mview from scratch.

Answer 2

The problem with ORA-32334 is that you have nested materialized views.
A possible scenario is as follows - your materialized view MV is referenced by other materialized view MV2
create table mv as
SELECT max(application_mode) application_mode
FROM tbl_name
WHERE cnt > 0
GROUP BY modes;
CREATE MATERIALIZED VIEW MV
ON PREBUILT TABLE
REFRESH FORCE ON DEMAND
AS
SELECT application_mode
FROM tbl_name
WHERE cnt > 0
;
create MATERIALIZED VIEW MV2
REFRESH FORCE ON DEMAND
AS
SELECT *
FROM MV
;
The DROP of MVis not a problem...
DROP MATERIALIZED VIEW MV;
But re-creation gives error:
CREATE MATERIALIZED VIEW MV
ON PREBUILT TABLE
REFRESH FORCE ON DEMAND
AS
SELECT application_mode
FROM tbl_name
WHERE cnt > 0
;
SQL-Fehler: ORA-32334: cannot create prebuilt materialized view on a table already referenced by a MV
The key is in already referenced by a MV
So let find the materialized view that is causing the problem:
select name, owner, master_owner, master
from all_snapshots where
master ='MV';
NAME OWNER MASTER_OWNER MASTER
------------------------------ ------------------------------ ------------------------------ ------------------------------
MV2 SAMPLE SAMPLE MV
The MV2 must be dropped first
DROP MATERIALIZED VIEW MV2;
Than the materializes view MV can be rebuilt.
CREATE MATERIALIZED VIEW MV
ON PREBUILT TABLE
REFRESH FORCE ON DEMAND
AS
SELECT application_mode
FROM tbl_name
WHERE cnt > 0
;
and after that the MV2 must be build again.

Answer 3

This is the expected bahaviour on 11.2
select * from v$version;
Oracle Database 11g Express Edition Release 11.2.0.2.0 - Production
Define a table MV and build a materialized view on it.
create table mv as
SELECT application_mode
FROM tbl_name
WHERE cnt > 0
;
CREATE MATERIALIZED VIEW MV
ON PREBUILT TABLE
REFRESH FORCE ON DEMAND
AS
SELECT application_mode
FROM tbl_name
WHERE cnt > 0
;
Now check that both object exísts
select object_type, object_name from user_objects where object_name = 'MV';
OBJECT_TYPE OBJECT_NAME
------------------- -----------
TABLE MV
MATERIALIZED VIEW MV
Now drop the materialzed view and re-check the objects
DROP MATERIALIZED VIEW MV;
select object_type, object_name from user_objects where object_name = 'MV';
OBJECT_TYPE OBJECT_NAME
------------------- -----------
TABLE MV
OK, materialized view disapeared, but table exists, why?
You may want to check documentation here
If you drop a materialized view that was created on a prebuilt table, then the database drops the materialized view, and the prebuilt table reverts to its identity as a table.
So, the table exists and you may again build a materialized view on it.
CREATE MATERIALIZED VIEW MV
ON PREBUILT TABLE
REFRESH FORCE ON DEMAND
AS
SELECT application_mode
FROM tbl_name
WHERE cnt > 0
;
select object_type, object_name from user_objects where object_name = 'MV';
OBJECT_TYPE OBJECT_NAME
------------------- -----------
TABLE MV
MATERIALIZED VIEW MV
Note in your case when teh materialized view is based on prebuilt table the "PRESERVE TABLE" is default behaviour in DROP, so teh same effect you get with
DROP MATERIALIZED VIEW MV PRESERVE TABLE;
select object_type, object_name from user_objects where object_name = 'MV';
OBJECT_TYPE OBJECT_NAME
------------------- -----------
TABLE MV
The table exist after the DROP materialize view.
Please check this simple scenario to see if it works. Check also your Oracle version - PRESERVE TABLEwas introduced in 10g.