The implicit assumption is that parameterized statements are most commonly executed with the most common parameter values. When parameter sniffing is enabled (the default), SQL Server chooses an execution plan based on the particular parameter values that exist at compilation time. An execution plan that is efficient for one parameter value may not be a good choice for other possible parameter values. These are all good things, provided the query being parameterized really ought to use the same cached execution plan for different parameter values. Now that you know how to deal with the problem, perhaps there are aįew situations in your own database that you might want to revisit.Query parameterization promotes the reuse of cached execution plans, thereby avoiding unnecessary compilations, and reducing the number of ad-hoc queries in the plan cache. Procedure is great but, if you aren’t careful, it can bite you when you leastĮxpect it. SQL Server’s ability to optimize and compile a stored Searched exactly one column, there is no need to recompile. ![]() That way, the query planĪssociated with the sub-sprocs remains in the cache, Separate sproc for each search method, and thenĭecide which one to execute within the CASE block. Query plan on every execution of the sproc. You can also add the WITH RECOMPILE directly to the stored This tells SQL Server to throw away the existing query planĪnd build another one–but only this once. Supplying the WITH RECOMPILE option: EXEC MySproc_Select '' WITH RECOMPILE No wonder performance would plummet so dramatically. Plan, searching for the target company name using the OrderDate If I switched the search to the CompanyName column, SQL would blindly use the cached query For instance, say I was searching on the column OrderDate. The first search I performed created a query plan and stored The moment I switched columns, however, performance plummeted. Long as I searched on that particular column, everything would work asĮxpected. Multiple searches, regardless of the order, the first would be fast, andįinally, I realized that the first time the procedure was called, a query plan was devised and stored in the cache. Least be approximately the same, but that isn’t what happened. In theory, the performance of each search should at I knew something was wrong when I began to test my allegedlyĬlever stored procedure. Several queries, depending upon the column to search. I examined the parameter using a CASE block, and then executed one of Then the page called a sproc, passing a parameter to indicate which column to Its users to search by any of several columns. My experience with the WITH RECOMPILE optionĪ while back, I was supporting a search page that allowed ![]() Then SQL Server compiles it and places it in the cache. In the cache first, finds the sproc there, andĭoesn’t compile it. ![]() Plan and stores it in its procedure cache. By default, it doesn’t compile the sproc at creation time. The system tables: sysobjects, sysdepends,Īnd syscomments (the latter stores the body of the sproc). If itĭoesn’t find any errors, then it adds the sproc to They run more quickly than the equivalent SQL statements executed from QueryĪnalyzer (or perhaps passed in from some front-end app such as a Web page or VBįirst, you need to know what SQL Server does with a new sproc. ![]() The generally accepted wisdom about stored procedures (or sprocs) is that because SQL can optimize and compile them, TechRepublic’s free SQL Server newsletter, delivered each Tuesday, contains hands-on tips that will help you become more adept with this powerful relational database management system. See how Arthur Fuller executes a stored procedure using the WITH RECOMPILE option, and then consider whether you need to revisit any stored procedures in your database. SQL Server's ability to optimize and compile a stored procedure is great but, if you aren't careful, it can bite you when you least expect it. Understanding SQL Server’s WITH RECOMPILE option
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |