I created some materialized views and Oracle SQL Developer puts a little red 'x' next to each of them. At the moment they are returning the correct information when I query them and running the following query in SQL Plus suggests that there are no errors:
SELECT * FROM USER_SNAPSHOTS
The ERROR column in this returns 0 for the materialized views in question.
Does anyone know why SQL Developer thinks there is an error? Is there anywhere else I can check?
UPDATE
Taking Patrick's advice I ran the following query:
SELECT * FROM ALL_MVIEWS
The COMPILE_STATE is 'NEEDS_COMPILE' for each view in question. What does this mean? Why would it need to be recompiled? None of the underlying tables have been changed.
To fix 'red' cross icon on views (actually it is a white cross over red background) due to NEEDS_COMPILE run the ALTER VIEW COMMAND.
ALTER VIEW MY_VIEW COMPILE;
Check ORACLE SQL Reference about ALTER VIEW.
http://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_4004.htm
For some reason, simply refreshing the materialized views made the 'error' go away. So not a true error, more of a reminder that the data isn't up to date. I guess you can ignore it if the table structure hasn't actually changed then...
This can be caused by modifications to an underlying table that the materialized view is based on. For example: increasing the max size of a column in the table which is included in the materialized view.
To refresh the materialized view you can do the following:
BEGIN
DBMS_SNAPSHOT.REFRESH('Name of materialized view');
END;
Related
In my Oracle instance I have a table. It existed just fine for many years without problems, I run thousands of queries per day on it (through my software), mostly selects and inserts, with rare (once-a-week) updates.
Today, a week after the last update, I ran an update against it and it failed with an ORA-00942: table or view does not exist.
I am the owner of that table. I'm pretty sure that database didn't change much during the week, certainly not this table.
I can select from it just fine: select * from table_x, but updates and inserts fail: insert into table_x select * from table_x where 1 = 0 with the weird ORA-00942.
Since I'm the owner, the usual visibility and privilege problems don't seem to apply, and googling, sadly, doesn't help. I'm sure I'm missing something really simple, so any suggestions are very welcome.
How did I make an Oracle table read-only (or invisible) for myself (the owner)?
It's partitioned (not sure if that helps). It's about 50GB in size, half of that indexes (not sure if that helps either).
EDIT: Here's a screenshot of the sample statement from PL/SQL Developer:
Once I ran the same situation, according to the trace file and little googling which referenced to Materialized View Log which is associated with master table.
Use the following command to drop the materialized view log
DROP MATERIALIZED VIEW LOG ON <table_x>
I have two tables, TABLE_1 and TABLE_2. Then we have a synonym called TABLE that points to either TABLE_1 or TABLE_2. When TABLE_1 is active, an ETL populates TABLE_2 and when the run is complete, it switches the TABLE synonym to TABLE_2 to make it the active table. Then I have a materialized view that does something like this as the SQL: select * from TABLE. What I am seeing happen is that after the materialize view runs the first time, it caches the actual table the synonym is pointing too. So when the ETL runs and flips the synonym to point at TABLE_2, when a complete refresh is done on the materialized view, it still thinks the synonym is pointed at TABLE_1. Why when I do a complete refresh does the materialized view not pick up the new synonym pointer to TABLE_2?
Here is a workaround to Oracle's bug:
alter materialized view MV_NAME nocache;
BEGIN DBMS_SNAPSHOT.REFRESH( MV_NAME,'C'); end;
alter materialized view MV_NAME cache;
I cannot find anything useful in Oracle documentation but just enable the logic:
I firstly create materialized view
In reality to support this materialized view Oracle makes the TABLE with some specific structure (dependent on your query structure) and the rule to refresh the table (as far as I remember it is called SUMMARY, but the name does not play any role here)
I change synonym target to the table which has another structure
The new target table is not "fitting" to the previous structure (e.g. it has totally different amount/data types of columns), the previous structure is invalid then and not working anymore. The underground table must be recreated then.
That's why I would say it is the only way to prevent the errors: reference the real target instead of synonym for creating materialized view.
So, the answer is: because the materialized view is a static table-like object dependent on the data set it is selecting; that's why to prevent the inconsistencies materialized view references the real object.
Sometimes I really wonder how many details Oracle hides inside.
I have a materialized view that I need to redefine the SQL for. We have an external system that hits the view over a db link, and the monster view takes 5 minutes to refresh the data in the view. The only way I know how to redefine the SQL for a view is to drop it and recreate it, but it would be very bad if the external system couldn't find the table, or it didn't have a complete data set. I need to have as little downtime as possible.
Is there any way to do this natively or more elegantly than:
Create public synonym for materialized view and make everything that uses the view use the synonym instead.
Create new materialized view with new SQL
Change the synonym to point to the new view
Drop the old view.
I've got code to do this dynamically but it is getting really ugly. It seems like there should be a better way to handle this.
Oracle has a build in solution for that. Keep in mind that the mview declaration is separate from that of the table.
The original mview
create materialized view mv1 as select dept , count(*) as cnt from scott.emp;
we want to change the declaration so that only dept over 5 will be calculated
drop materialized view mv1 preserve table;
notice the PRESERVE TABLE clause - the table mv1 is not droped - only the mview layer.
desc mv1
now we create the mview with a different query on top of the existing table
create materialized view mv1 on prebuilt table as
select dept , count(*) as cnt from scott.emp where dept > 5;
notice the on prebuilt table clause. the mview is using the existing object.
exec dbms_mview.refresh_mview('mv1');
I have materialized views that ran in production but hare having problems refreshing. The error message is
ORA-32411: materialized view definition query exceeds the maximum length
The ones that are having the problems are 76kb,70kb,75kb, and 67kb. Is there anything that can be done, besides splitting up the query? The scripts are one long query each so it will be hard to split up.
Recreate your materialized views as just views, and then recompile your materialized view select statement as
select * from your_new_view
I don't believe there is a limit to how long a view can be. I've also found this makes updating the MV query quite simple as you only have to recompile the view instead of dropping and recreating the MV.
I have one Materialized view on one server which is created by DB link.
There is one job running on that Mview. (created with dbms_refresh.make earlier).
Now I have created 3 new fields in original table.
My queries are.
1) Do I need to drop and create Mview again, if yes, do i need to create Mview log on main server again
2) What happens to job running on Mview , do i need to create it agin?
Also there are views created on Mview ,so
--If i run create or replace view query , will it create any problem?
Please guide.
Thanks!
If you need to include the new columns in your materialized view then yes you need to re-create the materialized view. You must explicitly drop the view as there is no "create or replace materialized view" statement.
DROP MATERIALIZED VIEW blah;
CREATE MATERIALIZED VIEW blah...
Dropping/recreating the materialized view should re-create the refresh job. Not 100% certain, but you should probably recreate the log as well.
And, if you don't need to include the new columns in your view, you really don't need to do anything...
After dropping/creating the materialized view, you should recompile the other views afterwards, because they may have become invalid.
You can check if that happened with
select *
from user_objects
where status = 'INVALID';
Recompile a view can be done with
alter view the_view compile;
or
exec dbms_utility.compile_schema(user);
This simply recompiles everything in your schema. Be sure to have no running jobs while doing this!