I notice that many views, esp. the data dictionary views, start with v$ in oracle, is there some differences than other views in oracle?
These are called dynamic performance views which are maintained by oracle server.
These views provide data on internal disk structures and memory structures. These views can be selected from, but never updated or altered by the user.
You can check more details at this link: http://docs.oracle.com/cd/E11882_01/server.112/e40402/dynviews_1001.htm#i1398692
Related
Trying to understand if there is any such concept like this in Oracle Database.
Let's say I have two Databases, Database_A & Database_B
Database_A has schema_A, is there a way I can attach this schema to Database_B?
What I mean by this is if there is a job populating a TABLE_A in schema_A, I can see that read-only view in Database_B. We are trying to split a big Oracle database into two smaller databases and have a vast PL/SQL code, and trying to minimize the refactoring here.
Sharding might be what you're looking for. The schemas and tables will still logically exist on all databases, but you can arrange the data to be physically stored in specific databases. There might be a way to setup shardspaces, tablespaces, and user default tablespaces in a way where each schema's data is automatically stored in a specific database.
But I haven't actually used sharding. From what I've read, it seems to be designed for massive distributed OLTP systems, and it is likely complicated to administer. I'd guess this feature isn't worth the hassle unless you have petabytes of data.
I'm learning about Oracle Views and I got the concept of views but little confused about performance.
I was watching video and there I listen that oracle view can increase the performance. Suppose I have created view like below.
CREATE VIEW SALES_MAN
AS
SELECT * FROM EMP WHERE JOB='SALESMAN';
Ok now I have executed query to get SALES_MAN detail.
SELECT * FROM SALES_MAN
Ok now confusion start.
I listened in video that once the above query SELECT * FROM SALES_MAN will be executed the DATA/RECORD will be placed into cache memory after hitting the oracle DB. and if I will execute same query( IN Current Session/Login ) Oracle Engine will not hit to Database and will give you record from CACHED-MEMORY is it right?
But I have read on many websites that View add nothing to SQL performance more
Another Reference that says view not help in performance. Here
So Views increase performance too or not?
A view is just a kind of virtual table defined by a query. It has no proper data and performance will depend on the underlying table(s) and the query definition.
But you also have Materialized View wich stores the results from the view query definition. Data is synchronized automatically, and you can add indexes to the view. In this case, you can achieve better performances. The cost to pay is
more space (the view contains data dupplicated),
no access to the up to date data from the underlying tables
You (and perhaps the creator of the un-cited video) are confusing two different concepts. The reason the data that was in the cache was used on the second execution was NOT because it was the second execution of the view. As long as data remains in the cache, it is available for ANY query that needs it. The very fact that the first execution of the view had to get the data from disk should be a strong clue. And what if your second use of the view wasn't until hours or days later when the data was no longer in the cache? The answer remains. A view does NOT improve performance.
I'm assuming that it CAN be done, I just don't know how or haven't been able to find a way to do it.
In Oracle, can access to the ALL_* tables and USER_* tables be revoked, including select grants.
For example, the all_objects, all_procedures views. Can access to these be restricted?
The same goes for user_tables and user_procedures and any other user_* views. Can access to them be restricted?
No, you can't (reasonably) prevent users from being able to query the ALL_* or USER_* views. You could go through and individually revoke access to each and every one of these views from PUBLIC but that would be a rather painful effort to go through, it would cause all sorts of applications to break not to mention breaking scripts from Oracle. You would end up, at a minimum, re-granting access to those views to any account that connected to the database because every database API interrogates the data dictionary views. Whether you have an ODBC application, a JDBC application, a PL/SQL IDE like TOAD or SQL Developer, or just about anything else, those applications will need to query the data dictionary.
The data that they will see in either view, however, will be limited to the objects that they have access to (for the ALL_* views) or the objects that they own (for the USER_* views). What purpose would be served by restricting a user's ability to query the data dictionary to determine what objects the user owns or what objects the user has access to? It would seem extremely odd to want a user to own a table but then to not allow the user to know that he owned that table.
Now, if you are really determined, you can create objects in the user's schema (tables or views) named, say, ALL_TABLES or USER_TABLES. Assuming that the user just queries ALL_TABLES rather than specifying a fully qualified SYS.ALL_TABLES, they will be querying the local object not the data dictionary view. That is generally a very inadvisable thing to do-- lots of products work by querying the data dictionary so causing the data dictionary queries to return the wrong set of data can lead to all sorts of bugs that are terribly hard to track down. But it is an option if you really, really want to restrict what data is returned from the data dictionary.
I am converting sybase stored procedures into oracle views. This is what they want and this is not my first choice. My question is:
Are there any limitations in oracle views? Total number of columns? Can you create indexes for views? Since I will be creating subviews and joining views within views, are there any limitations on how many layers of views you can do?
Thanks
Are there any limitations in oracle views?
Total number of columns?
are there any limitations on how many layers of views you can do
All covered here: http://docs.oracle.com/database/121/REFRN/GUID-685230CF-63F5-4C5A-B8B0-037C566BDA76.htm#REFRN0043
The number of columns in a view has the same limits as the number of columns in a table.
Can you create indexes for views?
No you cannot. However you cate create a materialized view, that can be indexed
You're limited to 1000 columns in a table. It wouldn't shock me if there was a similar limit for views. But if you're creating a view with 1000 columns, you're probably doing something very wrong.
You cannot create indexes on views but you can create indexes on the underlying tables that queries against views can use. You can index materialized views since, as the name implies, they materialize the data into a separate structure. But then you have to deal with refreshing the materialized view on commit, which adds overhead to transactions, or tolerate stale data and refresh the materialized view on some schedule.
There is no limit to the number of layers of views you can have. Depending on the Oracle version, the complexity of the views, and things like the presence of constraints, you can end up with queries that either force Oracle to do extra work (i.e. joining in additional tables in view layers that your end query doesn't actually need) or that are too complex for the optimizer to find a decent plan.
There aren't any significant limitations on the complexity of views.
The Oracle cost-based optimizer does a decent (if inscrutable) job of figuring out how to carry out queries to views using the indexes of the underlying tables.
If that performance isn't enough, you might consider looking into materialized views.
The usual way of doing the kind of project you're doing is to get the views working, then use EXPLAIN PLAN to do the optimization.
Can Oracle Materialized views be used to join multiple related tables having foreign keys to create a larger denormalized big table which is refreshed instantaneously?
On some investigations, it says that joins are not allowed while using fast refresh.
Is it my assumption which is wrong that i can do this sort of thing with Oracle Materalized views?
Assuming all the tables are local (i.e. you are not trying to replicate the data from a remote database and do the joins all in one step), the restrictions you need to be aware of are listed in the Data Warehousing Guide, not the replication manual. The specific set of restrictions depends on the Oracle version but you should be able to create a fast-refreshable denormalized view of your data.