SQL configuration optimization for ad hoc queries

Foreword:

        When the query or stored procedure is executed for the first time, an execution plan is created and stored in the process cache memory of SQL Server. In many cases, we will execute some simple procedures, only once, and creating stored procedures for these queries is a waste of memory resources. Due to insufficient memory, it may cause your cache to overflow, which will affect performance. Before 2005, this was a big problem, in order to correct this problem. In SQLServer 2008, Microsoft introduced an optimization function for immediate query load. This feature is still available in 2012. It is based on the instance level.

        Many developers run and test queries directly in the production environment . If they do not get the expected results, they will change the query and execute it again, which will cause a lot of pressure on the process cache. So try not to do this.

Before starting, clear the cache on the test server, but remember not to do this in a production environment:

--- 1) Check how much data is stored in the cache
SELECT CP.usecounts AS CountOfQueryExecution,  
        CP.cacheobjtype AS CacheObjectType,  
        CP.objtype AS ObjectType,  
        ST.text AS QueryText  
FROM sys.dm_exec_cached_plans AS CP  
        CROSS APPLY sys.dm_exec_sql_text (plan_handle) AS ST  
WHERE CP.usecounts> 0 

The result is shown in the figure:



--- 2) Clear cache and buffer pool

dbcc freeproccache

If you want to check whether the emptying is successful, you can execute the statement in step 1 again:

--- 3) Execute the select statement, check whether there is a plan cache after running the above statement, and execute the statement that query the plan cache again before:

--4) Set Optimize For Ad Hoc Workioads to 1
ad hoc query needs to be recompiled every time. The principle of optimize for ad hoc workloads is probably like this:
when you execute ad hoc query for the first time, it is The compiled execution plan, sql server saves a part.
Why not store it all, if you store all, adhoc query is very frequent, then it will not put pressure on the memory. 
When you query for the second time, save the execution plan.
When you run it for the third time, you can read the execution plan directly from the cache.

EXEC sp_configure 'show advanced options',1
RECONFIGURE

EXEC sp_configure 'optimize for ad hoc workloads',1
RECONFIGURE 

--5) Clear the cache and buffer pool again

dbcc freeproccache

--6) Execute the select statement, and then query the data in the cache (step 1), the result is as follows:



analysis:

        When a new query is executed, the query_hash value will be generated in memory instead of the entire execution plan. When the same query is executed for the second time, SQLServer will find whether the query_hash already exists. If it does not exist, the execution plan will be saved in the cache in. This will make the query executed only once will not save the execution plan to the cache. So it is strongly recommended to open this configuration. This configuration does not cause any negative effects, but can save space for plan caching.

        In general, when you execute a query, the execution plan will be generated and saved in the process cache, so when you execute the query in step 1, you will see that the server has a lot of plan cache, but when the query after the sixth step is , And found no. For ad hoc queries, why only need to be cached if it is executed only once?

        Some systems have a plan cache of more than GB, which may reduce space by half when turned on. In addition, to check how much space is occupied by ad hoc queries, you can use the following statement:

--- 1) View how much space is occupied by ad hoc queries

SELECT count(*)as 'Number of Plans',
sum(cast(size_in_bytes as bigint))/1024/1024 AS 'Plan Cache(MB)'
FROM    sys.dm_exec_cached_plans  
WHERE   objtype = 'Adhoc'  
        AND usecounts = 1  

---2)按项目查看
select objtype as 'cached object type',
count (*) as 'Number of Plans',
sum(cast(size_in_bytes as bigint))/1024/1024 AS 'Plan Cache(MB)',
avg(usecounts) as 'Avg use Count'
from sys.dm_exec_cached_plans
group by objtype


Original text from: http://blog.csdn.net/dba_huangzj/article/details/8758183



Published 22 original articles · praised 7 · 100,000+ views

Guess you like

Origin blog.csdn.net/qyx0714/article/details/77662837