이것은 예의 바른 답변을받은 또 다른 포럼에서 묻는 질문입니다.하지만 여기있는 사람이 더 많은 통찰력을 갖고 있는지 확인하고 싶습니다.쿼리가 웹 응용 프로그램에서 시간 초과되었지만 관리 스튜디오에서 정상적으로 실행됩니다.
문제는 웹 응용 프로그램에서 페이지 중 하나가 저장 프로 시저 호출에 도달하면 시간이 초과되어 SQL 프로필러 또는 응용 프로그램 추적 로그를 사용하여 쿼리를 찾아서 붙여 넣는 것입니다 관리 스튜디오에서 우리가 왜 느리게 돌아가고 있는지 파악합니다. 그러나 당신은 거기에서 그것을 실행하고 그것은 단지 매 순간마다 돌아 오지 않고 다시 돌아옵니다.
내 경우에는 ASP.NET 2.0과 Sql Server 2005를 사용하고 있었지만 문제는 모든 RDBMS 시스템에 적용될 수 있다고 생각합니다. SelectCommand에 시간 제한 값을 변경
이것은 내가 지금까지 내 연구에서 학습 한 내용입니다.
.NET은 관리 스튜디오에 로그인 할 때 얻은 것과 다른 연결 설정을 전송합니다.
-- network protocol: TCP/IP
set quoted_identifier off
set arithabort off
set numeric_roundabort off
set ansi_warnings on
set ansi_padding on
set ansi_nulls off
set concat_null_yields_null on
set cursor_close_on_commit off
set implicit_transactions off
set language us_english
set dateformat mdy
set datefirst 7
set transaction isolation level read committed
지금 설정이 동일 있는지 확인하려면 SQL 서버에 로그인 할 때 내가 실행할 때마다 쿼리 위의 설정들을, 붙여 넣기 오전 : 여기 당신이 SQL 프로파일 러와의 연결을 도청하는 경우 당신이 볼 것입니다.
이 경우, 연결을 끊었다가 다시 연결 한 후 각 설정을 개별적으로 시도 했으므로 arithabort를 off에서 on으로 변경하면 문제 쿼리가 90 초에서 1 초로 줄어 듭니다.
가장 가능성있는 설명은 SQL Server가 가장 효과적인 쿼리 계획이라고 생각하는 것을 선택하는 데 사용되는 매개 변수 스니핑과 관련이 있습니다. 연결 설정 중 하나를 변경하면 쿼리 최적화 프로그램에서 다른 계획을 선택할 수 있으며이 경우 잘못된 계획이 선택되었습니다.
그러나 나는 이것에 대해 완전히 확신하지 못했습니다. 이 설정을 변경 한 후 실제 쿼리 계획을 비교해 보았습니다. 아직 diff가 변경 사항을 표시하지 않았습니다.
경우에 따라 쿼리가 느리게 실행될 수있는 arithabort 설정에 대한 다른 내용이 있습니까?
해결책은 간단합니다. set arithabort를 저장 프로 시저의 맨 위에 놓습니다. 그러나 이것은 정반대의 문제로 이어질 수 있습니다. 쿼리 매개 변수를 변경하면 갑자기 'on'보다 'off'가 더 빨리 실행됩니다.
당분간 'with recompile'절차를 실행하여 매번 계획을 다시 생성해야합니다. 이 특정 보고서에서는 다시 컴파일하는 데 약간의 시간이 걸리기 때문에이 보고서는 괜찮습니다. 반환하는 데 1 ~ 10 초가 소요되는 보고서에서는 너무 눈에 띄지 않습니다 (괴물).
그러나 훨씬 자주 실행되며 가능한 한 신속하게 몇 밀리 초 만에 돌아와야하는 다른 쿼리에는 옵션이 아닙니다.준비 상자에
+1 SQL 프로파일 러에서 해당 설정을 가져 와서 Management Studio에 붙여 넣는 것이 유용한 팁이며로드하는 데 도움이되었습니다. –
+1 SET ARITHABORT OFF로 이전의 시간 제한 쿼리가 아름답게 작동하기에 충분했습니다. – Spud
@ eric-z-beard이 값들은 어디에 넣으시겠습니까? SP 내부 또는 EXEC 이전 sp_whatever from .NET – djandreski
시험이를 먼저 SQL 서버에 대한 서버 수준에서 = @@ 옵션
선언 @option의 INT
설정 @option을 변경 | 64
간부 인 sp_configure를 '사용자 옵션',
당신이 ASP.NET 아직 추적을 설정 적이 @option
RECONFIGURE? SQL 저장 프로 시저 자체가 문제가 아니었던 인스턴스를 가졌습니다. 프로 시저가 5000 개의 행을 반환했으며 응용 프로그램에서 문제를 일으키는 5000 개의 항목으로 데이터 바인딩 된 ListItems를 만들려고했습니다.
추적을 통해 웹 앱 기능 사이의 실행 시간을 살펴볼 수도 있습니다.
sp_who2 명령을 사용하여 문제의 프로세스를 확인할 수 있습니다. 이렇게하면 다른 프로세스에 의해 차단되거나 초과 된 CPU 및/또는 IO 시간을 사용하면 표시됩니다.
동일한 문제는 SQL보고 서비스와 관련이 있습니다. 변수의 유형을 확인하려고했습니다. 정수가되어야하는 곳에서 varchar를 보내는 것과 같은 다른 유형의 변수를 SQL에 보냈습니다. 보고 서비스 및 SQL의 저장 프로 시저에서 변수 유형을 동기화 한 후에 문제를 해결했습니다.
비슷한 문제가있었습니다. sproc create에서 "WITH RECOMPILE"옵션을 설정하여 시스템이 호출 될 때마다 실행 계획을 다시 계산하도록하십시오. 때때로 쿼리 프로세서는 많은 브랜칭 또는 case 문을 사용하여 복잡한 저장 프로 시저에서 혼란스러워지고 실제로 최적이 아닌 실행 계획을 가져옵니다. 그것이 문제를 "고칠"것으로 보인다면 통계가 최신인지 확인하고 sproc을 분석해야 할 것입니다.
sproc을 프로파일 링하여이를 확인할 수도 있습니다. SQL Managment Studio에서 실행하면 ASP.NET 응용 프로그램에서 IO를 비교할 때 IO가 어떻게 비교됩니까? 그들이 매우 많은 경우, 나쁜 실행 계획을 세우는 것을 다시 강요합니다.
우리는 같은 문제가 있으며 여기에 우리가 알아 낸 것이 있습니다.
데이터베이스 로그 크기가 기본값 (814MB)으로 유지되고 자동 증가율이 10 %입니다. 서버에서 최대 서버 메모리는 기본 설정 (2147483647 MB)으로 유지되었습니다.
로그가 꽉 차서 커질 필요가있을 때 서버의 모든 메모리를 사용 했으므로 코드를 실행할 수있는 시간이 남아 있으므로 시간이 초과되었습니다. 우리가 한 일은 데이터베이스 로그 파일의 초기 크기를 1MB로, 최대 서버 메모리를 2048MB로 설정 한 것입니다. 이것은 즉시 우리의 문제를 해결했습니다. 물론이 두 속성을 필요에 맞게 변경할 수는 있지만 코드를 통해 저장 프로 시저를 실행할 때 시간 초과 문제가 발생하지만 SSMS에서 매우 빠르게 실행되기 때문에 위의 해결 방법이 도움이되지 않습니다.
나는 동일한 문제가 있었고 http://stackoverflow.com/questions/250713/sqldataadapter-fill-method-slow는 내 문제를 해결했습니다. – David