I created an indexed view that joined a number of tables to get better performance, but when I use the indexed view, the performance is not better than before. When I survey the execution plan, I don't see any change between the view and the indexed view on these joined tables.
If you are not using sql server enterprise edition (see feature Automatic use of indexed views by query optimizer), sql server query optimizer is not taking in account indexed views..
In other versions you can make sql server use it- With (NoExpand):
Select col1, col2, col3
From dbo.vw_MyView With (NoExpand)
Related
I am using Oracle 11g EE and created one Materialized view for a complex query.
But as customer is using Standard edition and it doesn't support Materialized view.
So I need to convert materialized view into a normal view.
Along with this conversion I also need to make sure performance of a query.
When I treid to execute a query for the view independently, it takes around 20 mins which is too much time.
All my tables are indexed.
Any sort of help would be appreciated !!
I don't currently have access to an oracle database to test this, but if you get the DDL of the mview, and remove the word materialized along with the mview related options:
select dbms_metadata.get_ddl('MATERIALIZED_VIEW', 'MVIEW_NAME') from dual;
You should be able to create a normal view from the resulting modified statement.
As for performance, make sure you are indexing the right things, and using the right type of indexes. Make sure statistics are up to date, and finally run explain plan on the view query. The topic of interpreting and optimizing execution plans is deep - start here:
https://docs.oracle.com/cd/B10501_01/server.920/a96533/ex_plan.htm
I have inherited an existing system and am trying to figure out a few things.
The system does a
SELECT * FROM v_myView WHERE mvViewCol = 'someValue'
and v_myView performs summation of Table1 based on myViewCol
Does SQL Server 2005 optimize the query or will summation always occur across the entire Table1?
I understand that I could use a parameterized view but don't want to go changing things unnecessarily.
Cheers
Geoff
Views have no runtime cost at all. They are always inlined into the surrounding query as if you had pasted the view definition as text. They would be impractical to use otherwise.
Does SQL Server (2005) optimize the query or will summation always occur across the entire Table1.
It will be optimized.
This is a complicated question. I think the best explanation is here. I do wish Microsoft documentation were a little clearer on this point.
When a view is created, the query is parsed. This ensures that it is correct.
The execution plan is determined the first time the query is run (to a close approximation). This execution plan then remains in the plan cache for subsequent calls. So, if you have an index on the appropriate columns and the first execution has a where clause that would use the index, then subsequent calls will also use the index.
I say to a close approximation, because it is really the first time that a view is called when the plan is not in the plan cache. Certain changes to the database will flush the plan, as will restarting the server.
So, if you only access the view with the where clause, then subsequent uses of the view will be optimized for that purpose.
SQL Server 2005 will optimize the view each time it is referenced in a query : http://technet.microsoft.com/en-us/library/cc917715.aspx
"After view expansion, the SQL Server query optimizer compiles a single execution plan for the executing query."
I don't have 2005 installed but it will operate similiar to 2008R2 - To view the Query Optimization Plan, right click in the query window and select "Display Estimated Execution Plan" for more info and to spot any bottlenecks.
In the Query menu option, there is "Analyse Query in Database Tuning Advisor" that may also be of benefit to you.
I need to pull a large amount of data from various tables across a line that has very low bandwidth. I need to minimize the amount of data that gets sent too and fro.
On that side is a Sybase database, on this side SQL Server 2008.
What I need is to pull all the tables from the Sybase database that have to do with this office. Lets say I have the following tables as an example:
Farm
Tree
Branch
etc.
(one farm has many trees, one tree has many branches etc.)
Lets say the "Farm" table has a field called "CountryID", and I only want the data for where CountryID=12. The actual table structures I am looking at are very complex (and I am also not very familiar with them) so I want to try to keep the queries simple.
So I am thinking of setting up a series of views:
CREATE VIEW vw_Farm AS
SELECT * from Farm where CountryID=12
CREATE VIEW vw_Tree AS
SELECT * from Tree where FarmID in (SELECT FarmID FROM vw_Farm)
CREATE VIEW vw_Branch AS
SELECT * from Tree where BranchID in (SELECT BranchID FROM vw_Branch)
etc.
To then pull the actual data across I would then do:
SELECT * from vw_Farm into localDb.Farm
SELECT * from vw_Tree into localDb.Tree
SELECT * from vw_Branch into localDb.Branch
etc.
Simple enough to set up. I am wondering how this will perform though? Will it perform all the SELECT statements on the Sybase side and then just send back the result? Also, since this will be an iterative process, is it possible to index the views for subsequent calls?
Any other optimisation suggestions would also be welcome!
Thanks
Karl
EDIT: Just to clarify, the views will be set up in SQL Server. I am using a linked server using Sybase ASE to set up those views. What is worrying me in particular is whether the fact that the view is in SQL Server on this side and not on Sybase on that side will mean that for each iteration the data from the preceeing view will get pulled across to SQL Server first before the calculations get executed. I want Sybase to do all the calcs and just pass the results across.
It's difficult to be certain without testing, but my somewhat-relevant experience (using linked servers to platforms other than Sybase, and on SQL Server 2005) has been that using subqueries (such as your code for vw_Tree and vw_Branch) more or less guarantees that SQL Server will pull all the data for the outer table into a local temp table, then match it to the results of the inner query.
The problem is that SQL Server has no access to the linked server's table statistics, so can make no meaningful decisions about how to optimise the query.
If you want to be sure to have the work done on the Sybase server, your best bet will be to write code (could be views or stored procedures) on the Sybase side and reference them from SQL Server.
Linked server connections are, in my experience, not particularly resilient over flaky networks. If it's available, you could consider using Integration Services rather than linked-server queries - but even that may not be much better. You may need to consider falling back on moving text files with robocopy and bcp.
Does MySQL have an equalavent to SQL Servers "indexed view" functionality?
Is a view faster than a simple query?
What I'm specifically looking for is a way for MySQL to create a "view" that will return results faster than simply performing the underline view's query/sql.
An Indexed View is SQL Server terminology for a materialized view, which MySQL does not support.
You can either:
re-create a temporary table, populated with the desired columns, at a given interval
use an actual table, populated and indexed though again - there'd have to be a process to keep the data and indexes current
Application connected to MS SQL Server will create views where a single row result is an analysis including aggregations of 1-10k records. The applicable criteria across the resulting view will have dozens to tens of thousands of results. The view+criteria will then be ordered by some column (user specified) in the view which are most likely to be the aggregated columns. Response times are expected to degrade quickly when aggregated column is used for ordering.
A while back, this problem was solved pretty easily (in Oracle 9i) with materialized views.
Any ideas on how to get a similar solution in MS SQL Server 2005.
You can use Indexed views for this.
Read here for SQL 2005: http://msdn.microsoft.com/en-us/library/dd171921.aspx
Read here for SQL 2008: http://msdn.microsoft.com/en-us/library/dd171921.aspx
Materialized views are not same as indexed views. MS SQL server indexed views have multiple limitations such as use of outer joins, aggregates and common table expressions.