I run my SQL statement twice, including 'Actual Execution Plan'. However, I got two different execution plans for the same query. The only difference is I change ID.
First, I run sql with ID which is related to only 5 records.
Second, I run sql with ID which is related to 5000+ records.
Does the execution plan change depending on the data?
I'm using SQL Server 2008 R2
Does the execution plan change depending on the data?
Strictly speaking, No. The execution plan will change if the query changes or the statistics (which do depend on the data) change.
If the data changes but the stats do not, then your execution plan will stay the same.
Related
Under SQL Server 2008 R2, working with a database about 1.5 Terabytes in size:
We're testing partitioning the tables in the database. Database A is non-partitioned, B is partitioned.
Query is run via execute SQL, the one where the query is passed in as a string.
Query in A runs in a few seconds.
Query in B runs in over a minute.
Add the RECOMPILE option to the query, query runs in B same time as in A.
Remove the RECOMPILE. Time reverts back to slow time.
Bounce B's instance.
Query without RECOMPILE is slow.
Query with RECOMPILE fast.
Remove RECOMPILE. Query slow again.
We've tried all the usual methods of clearing the execution plan caches that you see online.
It would appear that two separate execution plans are generated. One for the one with recompile, one for the one without. Both seem to persist.
Anyone seen this behavior?
We're trying to get rid of the slow execution plan so that the query will always adopt the fast plan since the SQL is always the same.
Thanks in advance.
Got an issue where i have a complicated sql query that occasionally hangs and doesn't execute on MS SQL. However, when i run update statistics on the tables involved in the query, the query executes normally.
Any idea or pointers on the cause?
Thanks!
SQL Server creates an "execution plan" that uses the statistics info to determine an optimal order to filter the data/reduce access to the database tables.
This execution plan is stored in the database cache and is re-used as long as the database is online; the statistics are not rebuild and the query is not modified.
When you update the indexes, the statistics are updated as well.
As a result, the stored execution plan for your query is no longer optimal and as a result will not be used any more.
I expect SQL Server also closes unused locks and transactions for the table before rebuilding the index. That is an undocumented feature.
In a stored procedure in SQL Server, when is the actual SQL query plans generated? When the SQL is run for the first time or when the stored procedure is compiled? Any idea how expensive the generation of query plans is in comparison to Oracle?
When a query is run, SQL Server will check to see if an execution plan already exists for that query in the execution plan cache. If it finds one, it can reuse that execution plan. If it doesn't find one in the cache, it then generates a plan, puts in the cache ready for subsequent calls to reuse, and then executes the query. So it does this at the time when the query is executed.
How long a plan stays in the cache for is down to a number of factors, including:
- how often that plan is used
- how much "value" that plan offers
- memory pressure on the server
So a given query could have an execution plan generated multiple times over the course of a given period, if it's plan is not managing to stay in the cache. Also, when SQL Server restarts, the cache is cleared.
There's a good MSDN article on Execution Plan Caching and Reuse
When I execute a T-SQL query it executes in 15s on sql 2005.
SSRS was working fine until yesterday. I had to crash it after 30min.
I made no changes to anything in SSRS.
Any ideas? Where do I start looking?
Start your query in SSIS then look into the Activity Monitor of Management Studio. See if the query is currently blocked by any chance, and in that case, what it is blocked on.
Alternatively you can use sys.dm_exec_requests and check the same thing, w/o the user interface getting in the way. Look at the session executing the query from SSIS, check it's blocking_session_id, wait_type, wait_time and wait_resource columns. If you find that the query is blocked, the SSIS has no fault probably and something in your environment is blocking the query execution. If on the other hand the query is making progress (the wait_resource changes) then it just executes slowly and its time to check its execution plan.
Have you tried making the query a stored procedure to see if that helps? This way execution plans are cached.
Updated: You could also make the query a view to achieve the same affect.
Also, SQL Profiler can help you determine what is being executed. This will allow you to see if the SQL is the cause of the issue, or Reporting Services rendering the report (ie: not fetching the data)
There are a number of connection-specific things that can vastly change performance - for example the SET options that are active.
In particular, some of these can play havoc if you have a computed+persisted (and possibly indexed) column. If the settings are a match for how the column was created, it can use the stored value; otherwise, it has to recalculate it per row. This is especially expensive if the column is a promoted column from xml.
Does any of that apply?
Are you sure the problem is your query? There could be SQL Server problems. Don't forget about the ReportServer and ReportServerTempDB databases. Maybe they need some maintenance.
The first port of call for any performance problems like this is to get an execution plan. You can either get this by running an SQL Profiler Trace with the ShowPlan Xml event, or if this isn't possible (you probably shouldn't do this on loaded production servers) you can extract the cached execution plan that's being used from the DMVs.
Getting the plan from a trace is preferable however, as that plan will include statistics about how long the different nodes took to execute. (The trace wont cripple your server or anything, but it will have some performance impact)
I'm wondering if updating statistics has helped you before and how did you know to update them?
exec sp_updatestats
Yes, updating statistics can be very helpful if you find that your queries are not performing as well as they should. This is evidenced by inspecting the query plan and noticing when, for example, table scans or index scans are being performed instead of index seeks. All of this assumes that you have set up your indexes correctly.
There is also the UPDATE STATISTICS command, but I've personally never used that.
It's common to add your statistics update to a maintenance plan (as in an Enterprise Manager-defined Maintenance plan). That way it happens on a schedule - daily, weekly, whatever.
SQL Server 2000 uses statistics to make good decisions about query execution so they definitely help.
It's a good idea to rebuild your indexes at the same time (DBCC DBREINDEX and DBCC INDEXDEFRAG).
If you rebuild indexes, then the statistics for those indexes are automatically rebuilt.
If your timeframes allow, then running UPDATE STATISTICS of part of a maintenance plan is a good idea, as frequently as nightly (if your indexes are being rebuilt less frequently than that).
SQL Server: To determine if out of date statistics are the cause of a query performing poorly, turn on 'Query->Display Estimated Execution plan' (CTRL-L) in Management Studio and run the query. Open another window, paste in the same query and turn on 'Query->Display ActualExecution plan' (CTRL-M) in Management Studio and re-run the query. If the execution plans are different then statistics are most likely out of date.
Updating statistics becomes necessary after the following events:
- Records are inserted into your table
- Records are deleted from your table
- Records are updated in your table
If you have a large database with millions of records that gets lots of writes per day you probably should be determining an off-peak time to schedule index updates.
Also, you need to consider your type of traffic. If you have a lot (millions) of records in tables with many foreign key dependencies and you have a larger proportion of writes to reads you might want to consider turning off automatic statistics recomputation (NOTE: this feature will be removed in a future version of SQL Server, but for SQL Server 2000 you should be OK). This tells the engine to not recompute statistics on every INSERT, DELETE, or UPDATE and makes those actions much more performant.
Indexes are no laughing matter. They are the heart and soul of a performant database.