2013-02-26 3 views
4

SQL Server Management Studio 내에서 실행될 때 (정확한 인덱스를 추가하여 최적화 한 후) 실행하는 데 약 3 초가 걸리는 쿼리 (은 저장 프로 시저로 저장 됨)가 있습니다.쿼리는 SQL Server에서 4 초 만에 직접 실행되지만 ASP.NET에서는 30 초 이상 걸립니까?

이 C#에서 래퍼를 작성하고 URI를 사용하여이 쿼리를 실행할 수있는 기능을 제공했습니다. 그러나이 작업을 수행하는 데 30 초 이상 걸리고이 때문에이 쿼리를 루프의 일부로 실행하면 너무 많은 보류중인 요청으로 인해 브라우저가 멈 춥니 다.

try 
{ 
    string ConString = Constants.connString; 

    using (con = new SqlConnection(ConString)) 
    { 
     cmd = new SqlCommand(sql, con); 
     con.Open(); 
     dr = cmd.ExecuteReader(); 

     while (dr.Read()) 
     { 
     ... 
     } 
    } 
} 

내 연결 문자열은 이것이다 : 나는이 같은 래퍼를 썼다

Data Source={0};Initial Catalog={1};Integrated Security=True;MultipleActiveResultSets=true 

나는 (아래 내가 그것을 SSMS 내부에 여러 번 실행 한하고 잘 작동하기 때문에 쿼리 자체가 잘 알고 평균 5 초). 그리고 무엇을 제공해야할지 모르겠다는 것을 제외하고는 더 많은 디버그 정보를 제공하게되어 기쁩니다.

이러한 문제를 해결하려면 어디서부터 시작해야합니까?

는 편집 :

나는 SQL 프로파일 러를 실행하고 몇 가지 통계를 수집. 이것이 내가 관찰하는 것입니다. 매우 정확한 쿼리가 실행되는 것이 이상합니다. 이 시점에서 내가 할 수있는 일이 있다면 알려주십시오.

enter image description here

+2

어떤 줄과 어떤 줄 사이에 30 초가 걸리나요? –

+0

@MikeChristensen :'cmd.ExecuteReader()'에서 멈 춥니 다. – Legend

+0

SQL 명령 문자열이 1600 라인이거나 1600 개의 행을 반환한다고 말하고 있습니까? – RBarryYoung

답변

8

확인; 마지막으로 대답은 herehere입니다. 여기에 편의를 위해 대답이 복제되었습니다. 감사의 말은 원래의 포스터 인 Jacques Bosch으로, 다시 here에서 가져 왔습니다. 이 문제가 2004 년에 해결되었다고 믿을 수 없습니다!

이 문제는 SQL Server의 Parameter Sniffing이 원인 인 것 같습니다. 이를 방지하려면 들어오는 매개 변수 값을 SP 상단에있는 다른 변수에 할당하십시오.

See this nice Article about it

예 :

CREATE PROCEDURE dbo.MyProcedure 
(
    @Param1 INT 
) 
AS 

declare @MyParam1 INT 
set @MyParam1 = @Param1 

SELECT * FROM dbo.MyTable WHERE ColumnName = @MyParam1 

GO 

나는 eggheadcafe.com에서이 정보를 복사됩니다.

0

왜 U는 결과 세트 대신 XML을 사용하지 않는? XML을 사용하는 것으로 알고있는 한 결과 집합 읽기보다 훨씬 빠릅니다. 그래서이 경우 당신은 다음과 같이 사용한다 :

SELECT * 
FROM [Table Name] 
FOR XML PATH('[Your Path]'), ELEMENTS XSINIL, ROOT('Your Root') 

을하고 그 후 나는 당신이 당신의 프로젝트에 직렬화 수 있다고 생각합니다.

1

쿼리 계획의 캐싱으로 인해 SQL Server 관리 스튜디오에서 쿼리가 더 빠르게 실행되는 경우가 있습니다. 벤치마킹 전에 저장 프로 시저에서 sp_recompile을 실행 해보십시오. 그러면 쿼리 계획이 지워집니다.

0

http://www.sommarskog.se/query-plan-mysteries.html 내가 한 번 같은 문제가 있고, 그 차이는 당신이 SQL 관리 스튜디오를 통해 연결할 경우 다른 인 ARITHABORT 설정에 의해 발생 된 것으로 밝혀졌다 :

자세한 내용은 여기에서 찾을 수 있습니다. .net 연결 OFFARITHABORT 설정, SQL 관리 스튜디오 ON이이 설정을 설정하는 동안 설정합니다.

SQL Management Studio에서 SET ARITHABORT OFF을 실행하여 동일한 문제가 발생하면 시도해보고 쿼리를 실행할 수 있습니다.

Here is a thread이 설정으로 인해 이러한 극적인 성능 차이가 발생할 수있는 이유가 설명됩니다.

관련 문제