How does the view actually keep its data up to date? I mean does it execute the query each time that the view is queried or used for something? Also how does this affect performance, if the view queries a SQL Server - Oracle linked server.
A simple view is nothing but a stored query that is executed each time you call it. There is no performance benefit here.
You might want to have a look at stored procedures and materialized views if you need to optimize.
Related
Let's say I have main database called db1. There is also another database called db2. Sometimes I need to get data from db2. Is it better to directly get data from db2 or to make view in db1?
If you're getting data from db2 you should create views in db2 for each query. Why? To create interfaces.
If someone will make changes in db2 he don't know your queries which are executed from db1. Your queries can stop working. If you create views for your queries in db2 and from db1 query view#db2 anyone who change structure in db2 will see invalid view in case his changes damaged your queries.
Of course I mean situation when your queries are embedded in packages or views. If you just query for analytic purpose it make no difference if you do it directly, with view on db1 or view on db2 just do as it is suitable for you. But good practice is setting interfaces so I would recommend to create view on db2 for datasets your later querying from db1. It can also make sense to create additional view or synonym on db1 side to have both side interface.
You will first need to set up a driver for connectng to DB2, a TNS connection entry for Oracle to connect with and a database link in Oracle to point to the connection.
The important thing is that you try, as far as possible, to insulate changes in one DB from the other.
I've this done different ways but this has worked for me;
For each table you are querying in DB2 create a DB2 view of JUST the columns you want from that table.
Create a view in Oracle that queries DB2_VIEW#DB2_database. Although not strictly necessary just query the columns you want - its good practice.
Create a synonym for the view and query through that. If the source of the data changes and the view is replaced by a different one you can switch the synonym to point at the new view instead of changing your code.
Summary:
Unless I've misunderstood you seem to be asking should I query the table directly in DB2 or should I go through views? I suggest that going through views insulates you from changes at either end to some extent so use the views.
We have a .NET Application using LINQ to SQL (ORM) to call a view which contains joins from multiple objects in different databases. The .NET Application times out calling this view, however our DBA runs the following statement:
sp_refreshview on the view and the subsequennt sql views
the application starts running again.
This application starts timing out again on the same view after close to 20 minutes. So our DBA has scheduled a job to run the above statement every 30 minutes. There has been no structural changes to the view and we are trying to figure why sp_refreshview fixes this problem and what could be the underlying issue that we could fix?
The reason that sp_refreshview is fixing the issue is that the view is not schema-bound. SQLServer keeps metadata about the view to aid in execution, and since the view is not schema-bound the metadata becomes outdated as the base objects are updated (think DML statements). What sp_refreshview does is update that metadata for non-schema-bound views so they can run optimally. Take a look at the documentation for sp_refreshview.
For some clarification on why this works, think about what a view is? A view is just a query. The metadata that is stored relates to that query.
Whenever you run a query, the server will figure out the most optimal way to run that query (called a plan), and that depends on the statistics of the tables used in the query. As the data in the tables change, the statistics for the tables will change, and so the plan can change. When you create a view (non-schema-bound), metadata around the optimal execution is stored (most likely the plan). Since a view is just a query, the plan can become outdated and sp_refreshview updates that metadata.
Most likely sp_refreshview causes the server to remove the cached execution plan of your query from the cache. When you run the query after a call to sp_refreshview the new (better) execution plan is generated. This is why calling sp_refreshview helps. Apparently, updating statistics doesn't remove cached execution plans, that's why it doesn't help in your case.
There are some types of queries that can't have a good plan for all possible values of parameters, or your data may be significantly skewed.
If you add OPTION(RECOMPILE) to your query most likely you will not need to call sp_refreshview to make it work fast.
I don't know how to add this query hint when the query is generated by your ORM.
I recommend you to read an excellent article Slow in the Application, Fast in SSMS by Erland Sommarskog.
Metadata is information about the tables used by the view. Statistics updates the information about the data. It might help to see your View definition. For example, having a select * in the view could really cause you problems. As a refresher, a view is just a statement until it is executed. If you are using tables that are always changing their structure or are dropped and re-added, you will need to be running sp_refreshview every time. If you want additional help, you will need to provide the query and any information on the underlying tables, like processes the refresh them. All of the above comments were within reason correct.
If all SQL is doing is SELECT, is there an advantage to using a view vs a SPROC.
From my point of view, it's purely organizational, but I am wondering if there is a good reason for using views when all a SPROC is doing is SELECTs and has no writes to the DB.
I'm on Sql Server 2008 but this can probably apply to other SQL server products
Views are meant to abstract out the details of the underlying table and provide a window to the data, the way you want it to appear.
Stored procedures achieve a specific task and optionally take parameters that would be used during the task execution.
If you would like to run a specific task by taking arguments from the users, then you can create a stored procedure.
If you just want to expose data in a given way and leave further filtering, if required, to the users, you can create a view.
Other than the security advantage of encapsulating specific data for specific roles, there's also the advantage of being able to create an index on the view.
Here are some specific performance advantages, from the MSDN link:
Aggregations can be precomputed and stored in the index to minimize expensive computations during query execution.
Tables can be prejoined and the resulting data set stored.
Combinations of joins or aggregations can be stored.
Am querying a remote database using DBLink. Now am wondering to speed up the query, how can i add indexes to few columns in the remote table.
Would appreciate if anyone can provide any recommendations around the same.
You could use DBMS_JOB or DBMS_SCHEDULER packages on the remote database to schedule a job, executing DDL.
But consider this, if Oracle throws an exception for DDL over databse links, there must be a good reason for it, right? You don't want anyone messing with your schema remotely over a database link. So instead, talk to the remote DBA and try to figure out solutions with him/her.
it can't be done over the dblink (even if your dblink is using the owning schema) you will see
ORA-02021: DDL operations are not allowed on a remote database
You could create a Materialized View in the remote database based in your query, add your prefered indexes to it, and then, if you need it, create a synonym for that materialized view.
John,
A good place to start would be the following Oracle documentation on "Tuning Distributed Queries".
http://download.oracle.com/docs/cd/B28359_01/server.111/b28310/ds_appdev004.htm
you could create the indexes in the remote database and build up your query in a view form (in the remote database of course).
that way the remote database will complete the query using all the methods he got (like indexes) and bring you back only the wanted resultes.
I have a table in a SQL Server database that needs to be visible to an oracle database. We have tried using a normal view over sqllink, but we are not able to create an onUpdate triggers on that view.
I have read that we can create the trigger if it is a materialised view, but is unable to find any information on whether it can be done across different databases. (all the example are for oracle to oracle tables)
Can someone tell me if it is possible? and what issues I might need to look out for if I used materialised views?
Thanks
I do something similar and ended up using Oracle's HS gateway to handle it. Created an MV based of tables or queries to establish a staging area in Oracle. Followed up with logic to meet requests.