I'd like to know if there is some performance advantage of using DBA_ catalog views over ALL_ views for querying database metadata and in which situations (if any) this advantage would manifest.
Oracle dictionary is slow so the general rule of thumb is not to use dictionary in performance critical code. If you terribly need metadata in your application, you can create materialized view based on dictionary tables and refresh it manually after executing DDL. Of course, not every change in dictionary is made by user DDL, but I don't know what kind of meatadata exactly you need.
As for difference in ALL_ and DBA_ views I believe it is marginal. For obvious reasons, DBA_ views have more data than ALL_ views. In each case you can try to obtain DDL for them using DBMS_METADATA package.
select dbms_metadata.get_ddl('VIEW', 'ALL_TABLES', 'SYS')
from dual
I will not attach the output since it's pretty verbose and useless. In case of ALL_TABLES list of tables used in FROM is the same. Since you access much the same data, perform same joins and just filter rows a bit differently, performance-wise the result should be about the same.
Related
The DBA_OBJECTS object is a view. I was trying to look and see what the underlying tables of that view is. Can those base tables be updated manually, and it be reflected in the view?
Can obj$ be updated manually?
No. obj$ cannot be updated manually. Only indirectly through execution of DDL statements that create, alter, or drop database objects.
You can see the underlying objects by querying dba_views:
SELECT text
FROM dba_views
WHERE view_name = 'DBA_OBJECTS'
You will find that it is quite complex, undocumented and absolutely off limits for direct modification. Messing with dictionary objects can easily corrupt your dictionary and will earn you a dead-end in any SR you open with Oracle. But there's no harm in exploring the view definitions to understand the dictionary better, and in some cases, such as with advanced monitoring tools such as I write, there is benefit to querying base dictionary and fixed x$ objects directly, but never modifying anything.
The only exception to the above rule I have found is that there is a legitimate need for a DBA at times to modify the ptime column in sys.user$ in order to spread out password expirations caused by creating too many users all at the same time (at database creation time, for example). But this is a rare situation and is only justified by the lack of any other means provided by Oracle to do this.
I am migrating Oracle objects to Snowflake. I have materialized view in Oracle that fetches data from multiple tables but in Snowflake a materialized view can be created on single table only. Can I use Oracle materialized view script and use it as a simple view to load into a temporary table and then use this temporary table to create a materialized view on top of it?
Can I use Oracle materialized view script and use it as a simple view to load into a temporary table and then use this temporary table to create a materialized view on top of it?
No, this won't work. A materialized view in Snowflake cannot be based on another view. But don't despair, just because you needed a materialised view in Oracle does not mean that you will need one in Snowflake ! On the contrary, it is typical in scenarios where a materialized view was needed in traditional RDBMS, that no special handling is required in Snowflake due to it's superior performance. Snowflake recommends the following considerations when deciding to use a materialized or regular view:
Create a materialized view when all of the following are true:
The query results from the view don’t change often. This almost always means that the underlying/base table for the view doesn’t change often, or at least that the subset of base table rows used in the materialized view don’t change often.
The results of the view are used often (typically significantly more often than the query results change).
The query consumes a lot of resources. Typically, this means that the query consumes a lot of processing time or credits, but it could also mean that the query consumes a lot of storage space for intermediate results.
Create a regular view when any of the following are true:
The results of the view change often.
The results are not used often (relative to the rate at which the results change).
The query is not resource intensive so it is not costly to re-run it.
When materialized views are created in Oracle, do they store indices or do they store actual table values?
I am asking this as creating index on table and using views on that table and using materialized views (created with refresh complete start with (sysdate) next (sysdate+1) with rowid as) on unindexed table gives similar performance.
Where as I would expect materialized views to be far more faster.
Update
I slightly modified the content/title. My current concern after discussion is if materialized views are actual real tables or virtual tables with some optimization.
Materialized views create a copy of the data. To all intents and purposes they are actual tables. In fact we can create a materialized view from an existing table using the PREBUILT clause. The only difference is how the data is mastered - a materialized view doesn't own its data, a table does.
As to your performance conundrum:
When you say "on unindexed table" do you literally mean one table? If so, we wouldn't expect any difference in the time to query a view, a materialized view or the actual data: they all execute a full table scan on the same volume of data.
Consider the case where views have expecting select * from <table> where <condition>.
We would a SELECT against a materialised view built on that query to execute quicker than the same SELECT against the actual table, provided the WHERE clause restricts the data to a significantly smaller subset of the original data. Simply because a full table scan over a small table (materialised view) takes less time than a full table scan over a big table. Same applies if the materialised view's projection has fewer columns than the base table.
Indexing is a different matter. Unless the query selects a very small subset of the data it's not going to be more efficient than a full table scan and a filter.
To sum up: the only universal tuning heuristic is: it takes less time to do less work. Beyond that it is impossible to generalise. We can't discuss some vague "consider the case where views have select * from <table> where <condition>." It's all about the specifics.
Fundamentally, a materialized view is just a table with an associated query to populate it.
Given static data, one would generally expect the performance of a SELECT * from the materialized view (with no WHERE clause) to be at least as fast as running the query that underlies the materialized view, regardless of indexing.
If we add a WHERE clause to a SELECT * against the mview, however, that query could perform significantly slower than running the query that underlies the mview with the same WHERE clause. That's because the tables referenced in the query underlying the mview could have indexes to support the conditions in the WHERE clause, where as the mview might not have such indexes.
I am reviewing my team's database setup, particularly focusing on Materialized Views. In most cases, we are currently doing 'Complete' refreshes, and I want to move to doing fast refreshes.
In some cases, this is straight forward -- the MV is based directly on a table on our source database, and I can enable MVIEW LOGS on the table and recreate the MV.
But in a number of cases, the MVs are based on a combination of other MVs, and Views, etc, that go several levels deep before I get to the tables on our source database.
In these cases, if I track down the ultimate source tables, will enabling MVIEW LOGS on them allow the top MV and any intermediate MVs, to use fast refresh?
The Oracle documentation contains an example for a FAST REFRESH of a materialized view based on an UNION ALL view:
CREATE VIEW view_with_unionall AS
(SELECT c.rowid crid, c.cust_id, 2 umarker
FROM customers c WHERE c.cust_last_name = 'Smith'
UNION ALL
SELECT c.rowid crid, c.cust_id, 3 umarker
FROM customers c WHERE c.cust_last_name = 'Jones');
CREATE MATERIALIZED VIEW unionall_inside_view_mv
REFRESH FAST ON DEMAND AS
SELECT * FROM view_with_unionall;
So in principle, you can indeed fast refresh materialized views based on views.
Some things to note:
there are a couple of restrictions for fast refreshable materialized views. E.g. you cannot use ROWNUM, SYSDATE or HAVING. See the docs for details
somewhat counterintuitively, a FAST REFRESH is not always faster than a COMPLETE REFRESH. This depends on the amount of data that has changed since the last refresh; IMHO, Oracle should have used the term INCREMENTAL REFRESH instead
Oracle provides a procedure for that: DBMS_MVIEW.EXPLAIN_MVIEW
You can use this procedure to check whether your Materialized Views is capable for FAST REFRESH, it also tells you the reason why it is not.
For me the most strange restriction for FAST REFRESH is: When you join several tables you have to use the (old) Oracle Join syntax, ANSI join syntax does not work. Some time ago a created a case at Oracle support for this issue, however the answer from Oracle was: "This is not a bug, it is just a lack of documentation."(!)
I don't know if it still applies for Oracle 12c version.
Will moving views from one schema to another have any adverse effect on performance?
I have about 40 views in one schema. I want to create a new schema which will have all the correct permissions. Suppose TableA resides in schema A. So my view will be in schema A. So I would do simply select * from TableA. Now I move this view to schema B. Since the table is in schema A, I would need to do select * from A.TableA. Will this cross-schema query cause any performance issues?
this is not where you might start in a performance review.
the sql of the actual view is probably far more important than which schema you place it in.
edit:
where the view resides should not affect performance. (aside from how the schema is laid out across blocks and datafiles)
If it's not a materialized view, it should have very little effect on performance.