parameter-sniffing | 易学教程

How can I cure parameter sniffing on SQL Server 2000?

阅读更多关于 How can I cure parameter sniffing on SQL Server 2000?

问题 I am having an issue where an update query with about 70 parameters times-out on occasion. Based on some research, I believe this is due to packet sniffing. I saw that in newer versions of SQL Server, I can use the Option(recompile) clause, but that does not work in my case, since I am using server 2000. I am using sqlhelper.executeNonQuery and not a stored procedure. 回答1: An easy fix is not to use parameters. Instead of: SELECT * FROM YourTable WHERE UserName = @myUserName; Pass: SELECT *

sql execution latency when assign to a variable

阅读更多关于 sql execution latency when assign to a variable

问题 The following query will be ran in about 22 seconds: DECLARE @i INT, @x INT SET @i = 156567 SELECT TOP 1 @x = AncestorId FROM dbo.tvw_AllProjectStructureParents_ChildView a WHERE ProjectStructureId = @i AND a.NodeTypeCode = 42 AND a.AncestorTypeDiffLevel = 1 OPTION (RECOMPILE) The problem is with variable assignment (indeed this line: @x = AncestorId ). when removing the assignment, it speeds up to about 15 miliseconds! I solved it with inserting the result to a temp table but I think it is a

SP taking 15 minutes, but the same query when executed returns results in 1-2 minutes

阅读更多关于 SP taking 15 minutes, but the same query when executed returns results in 1-2 minutes

问题 So basically I have this relatively long stored procedure. The basic execution flow is that it SELECTS INTO some data into temp tables declared with he # sign and then runs a cursor through these tables a generate a 'running total' into a third temp table which is created using CREATE . Then this resulting temp table is joined with other tables in the DB to generated the result after some grouping etc. The problem is that this SP had been running fine until now returning results in 1-2

Is there any way to overcome parameter sniffing in SQL Server?

阅读更多关于 Is there any way to overcome parameter sniffing in SQL Server?

问题 I came across parameter sniffing when one of my queries took a much longer time to execute than expected. When I delved a little deeper into this problem I came to know that: When first time query gets executed it (SQL Server) creates execution plan for that query and for other n number of times same query executed and if it has large variance in result set with first time execution then parameter sniffing problem occurs". This was in my scenario. Now my question is, is there any way or

strange SQL server report performance problem related with update statistics

阅读更多关于 strange SQL server report performance problem related with update statistics

问题 I got a complex report using reporting service, the report connect to a SQl 2005 database, and calling a number of store procedure and functions. it works ok initially, but after a few months(data grows), it run into timeout error. I created a few indexes to improve the performance, but the strange thing it that it works after the index was created, but throws out the same error the next day. Then I try to update the statistics on the database, it works again (the running time of the query

At some point in your career with SQL Server does parameter sniffing just jump out and attack?

阅读更多关于 At some point in your career with SQL Server does parameter sniffing just jump out and attack?

问题 Today again, I have a MAJOR issue with what appears to be parameter sniffing in SQL Server 2005. I have a query comparing some results with known good results. I added a column to the results and the known good results, so that each month, I can load a new months results in both sides and compare only the current month. The new column is first in the clustered index, so new months will add to the end. I add a criteria to my WHERE clause - this is code-generated, so it's a literal constant:

What are the main differences between OPTION(OPTIMIZE FOR UNKNOWN) and OPTION(RECOMPILE)?

阅读更多关于 What are the main differences between OPTION(OPTIMIZE FOR UNKNOWN) and OPTION(RECOMPILE)?

问题 I run into the classic Parameter Sniffing issues in SQL Server 2012. Based on some research I found multiple options around this problem. The two options that I need to understand the difference between are OPTION(OPTIMIZE FOR UNKNOWN) vs OPTION(RECOMPILE) . I am hesitating to use OPTION(RECOMPILE) at the end of my queries that are having this issue because it will force the server to generate a new execution plan each time. If I call this query often this will spike up the CPU of that

SP taking 15 minutes, but the same query when executed returns results in 1-2 minutes

阅读更多关于 SP taking 15 minutes, but the same query when executed returns results in 1-2 minutes

So basically I have this relatively long stored procedure. The basic execution flow is that it SELECTS INTO some data into temp tables declared with he # sign and then runs a cursor through these tables a generate a 'running total' into a third temp table which is created using CREATE . Then this resulting temp table is joined with other tables in the DB to generated the result after some grouping etc. The problem is that this SP had been running fine until now returning results in 1-2 minutes. And now suddenly its taking 12-15 minutes. If I extract the query from the SP and executed it in the

Is there any way to overcome parameter sniffing in SQL Server?

阅读更多关于 Is there any way to overcome parameter sniffing in SQL Server?

I came across parameter sniffing when one of my queries took a much longer time to execute than expected. When I delved a little deeper into this problem I came to know that: When first time query gets executed it (SQL Server) creates execution plan for that query and for other n number of times same query executed and if it has large variance in result set with first time execution then parameter sniffing problem occurs". This was in my scenario. Now my question is, is there any way or workaround to overcome parameter sniffing in SQL Server in these scenarios? I know by running sp_updatestats

Multi-tenant SQL Server databases and parameter sniffing

阅读更多关于 Multi-tenant SQL Server databases and parameter sniffing

问题 I have a multi-tenant database in SQL Server 2012 where each tenant's rows are identified by a tenant_id column (aka the Shared Database, Shared Schema approach). Some tenants, particularly the newer ones, have very few rows, while others have many. SQL Server's query optimizer normally builds a query plan based on the parameters provided during its first execution, then re-uses this plan for all future queries even if different parameters are provided. This is known as parameter sniffing.