I have a query and run it using SQL management studio. Usually, there is created one execution plan for a query in the studio. But sometimes I can catch up the duplicated execution plans for a single Query on the Azure SQL like below.
When I open the query from this plan I see the duplicated query. As if the copied query is pasted into the same query. The same in Query 1 and Query 2. See below.
Maybe someone knows why does this happen and how to avoid this behavior? How is that even possible?
P.S. Time of execution query was increased from 2 sec to 20 sec and more.
P.P.S. The warning in the Query 2
It could be that the queries were ran with different settings. I can notice that one has a warning and the other doesn't.
Reference:
https://blogs.msdn.microsoft.com/psssql/2014/04/03/i-think-i-am-getting-duplicate-query-plan-entries-in-sql-servers-procedure-cache/
Related
Some programm generate and send queries to sql server(on high load production). I want take plan of concrete query of concrete table. I start profiler with "Showplan XML" and set filter on TextData(like %MyTable%) and DatabaseName. It show rows with xml in TextData that describe execution plans(for all queries of my table). But I know that exist 5 different sql queries for this table.
How I can match some concrete query with correspond plan without use statistic?
Is there a reason this has to be done on the production environment? Most really bad execution plans (missing indexes causing table scans etc.) will be obvious enough on a dev environment where you can use all the diagnostics you want.
Otherwise running the SQL on the query cache (as in the linked question someone else mentioned) will probably have the lowest impact as it just queries a system table rather than adding diagnostics to every query.
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 have a table in my SQL Server 2008 database called dbo.app_additional_info which contains approximately 130,000 records. Below shows the structure of the table.
When I run a query like the one below in SQL Server Management Studio 2008
select app_additional_text
from app_additional_info
where application_id = 2665 --Could be any ID here
My query takes a long time to execute (up to 5minutes) and sometimes it times out. This database is also connected to a Web Application and when it runs the above query, I always get a timeout error.
Is there anything I can do to speed up the performance of my query?
Your help with this would be greatly appreciated as this is grinding my web application to a halt.
Thanks.
Update
Below shows my execution plan from SSMS (I apologise for poor quality)
based on the limited info in the question, it looks like you are doing a table scan because there is no index on application_id. So, try this:
CREATE INDEX IX_app_additional_info_application_id on
app_additional_info (application_id)
your query should run much faster now.
I have two servers I'm doing development on and I'm not a DBA, but we don't have one so I'm trying to figure out some performance issues I'm having. Locally I have SQL Server 2008 R2 installed and when an ORM that I'm using runs a query it returns the results in less than a second. When I run that exact same query on our development server with is SQL Server 2005, it takes over a minute. I've looked at the execution plan on both of them the main thing that sticks out is the last two lines of the query has a order by statement. On the 2005 server this is 100% of the cost. on the 2008 server its 0% of the cost. Is there some sort of setting I'm overlooking? Both servers have approximately the same data in them and the same indexes/keys/etc.....since the local copy is just a restore from a backup.
My best guess is the 2005 server is sorting all the tables and then giving me the results (200 lines). Where the 2008 server is getting all the results and then sorting them. (200 results also.)
Link to slow execution plan: http://pastebin.com/sUCiVk8j
Link to fast execution plan: http://pastebin.com/EdR7zFAn
I would post the query but it is obnoxiously long because I have a bunch of includes and its Entity Framework that is generating the query.
Thank you in advance.
Edit: I opened Task manager on the SQL server this is running on and the CPU goes to 100% during the execution of this query.
Edit: Added XML version to jsfiddle.net. pastebin wouldn't allow me to because of the size. Just used the CSS window for the XML.
Actual 2008R2: http://jsfiddle.net/wgsv6/2/
Actual 2005: http://jsfiddle.net/wgsv6/3/
Hard to tell without seeing the query, but is it possible you are missing an INDEX on the slow server?
THe statistics could be out of date on the dev server.
I have been working on migrating some of our data from Microsoft SQL Server 2000 to 2008. Among the usual hiccups and whatnot, I’ve run across something strange. Linked below is a SQL query that returns very quickly under 2000, but takes 20 minutes under 2008. I have read quite a bit on upgrading SQL server and went down the usual paths of checking indexes, statistics, etc. before coming to the conclusion that the following statement, found in the WHERE clause, causes the execution plan for the steps that follow this statement to change dramatically:
And (
#bOnlyUnmatched = 0 -- offending line
Or Not Exists(
The SQL statements and execution plans are linked below.
A coworker was able to rewrite a portion of the WHERE clause using a CASE statement, which seems to “trick” the optimizer into using a better execution plan. The version with the CASE statement is also contained in the linked archive.
I’d like to see if someone has an explanation as to why this is happening and if there may be a more elegant solution than using a CASE statement. While we can work around this specific issue, I’d like to have a broader understanding of what is happening to ensure the rest of the migration is as painless as possible.
Zip file with SQL statements and XML execution plans
Thanks in advance!
We experienced similar problems a few years back in our migration from 2000 to 2005. The error we were seeing was actually an invalid cast error. I think I found the thread here
The query optimiser has much more freedom in SQL Server >=2005. The CASE solution is probably the best route.