SqlDataAdapter입니다.주입 방법이 느림

SqlDataAdapter입니다.주입 방법이 느림

SQL Server Management Studio에서 실행하는 데 1초 미만이 소요되는데 이 코드를 사용하여 9개의 열, 89개의 행이 있는 테이블을 반환하는 저장 프로시저를 실행하는 데 60초가 걸리는 이유는 무엇입니까?로컬 시스템에서 실행되고 있기 때문에 네트워크 지연 시간이 거의 없고 개발 속도가 빠릅니다.

Dim command As SqlCommand = New SqlCommand(procName, CreateConnection())
command.CommandType = CommandType.StoredProcedure
command.CommandTimeout = _commandTimeOut
Try
   Dim adapter As new SqlDataAdapter(command)
   Dim i as Integer
   For i=0 to parameters.Length-1
      command.Parameters.Add(parameters(i))
   Next
   adapter.Fill(tableToFill)
   adapter.Dispose()
Finally
   command.Dispose()
End Try

매개 변수 배열이 입력되었습니다(이 SQL의 경우 단일 매개 변수만 해당).

parameters(0) = New SqlParameter("@UserID", SqlDbType.BigInt, 0, ParameterDirection.Input, True, 19, 0, "", DataRowVersion.Current, userID)

저장 프로시저는 다음과 같은 선택 문일 뿐입니다.

ALTER PROC [dbo].[web_GetMyStuffFool]
   (@UserID BIGINT)
AS
SELECT Col1, Col2, Col3, Col3, Col3, Col3, Col3, Col3, Col3
FROM [Table]

먼저, 성능을 제대로 프로파일링하고 있는지 확인합니다.예를 들어 ADO.NET에서 쿼리를 두 번 실행하고 두 번째 시간이 첫 번째 시간보다 훨씬 빠른지 확인합니다.이렇게 하면 앱이 컴파일되고 디버깅 인프라가 증가할 때까지 기다리는 오버헤드가 제거됩니다.

ADO합니다.를 들어, 예들어경을 하면 실할행우가 .SET ARITHABORT OFFSSMS는 ADO입니다.NET을 사용할 때만큼 느리게 실행됩니다.

가 한 번 은 한번발것은한견입니다.SET ARITHABORT OFF.SSMS의 경우 proc와 proc는 동일한 통계를 사용합니다.그리고 갑자기 SSMS와 ADO.NET이 거의 동일한 실행 시간을 보고했습니다.:ARITHABORT속도 저하의 원인 자체가 아니라 재컴파일을 유발하고 매개 변수 스니핑으로 인해 두 가지 다른 계획이 발생하는 것입니다.매개 변수 스니핑은 해결해야 할 실제 문제일 가능성이 높습니다.

, 으로 이확인하대실계행, 히특획한을 살펴보세요.sys.dm_exec_cached_plans테이블. 그들은 아마 다를 것입니다.

특정 저장 프로시저에서 'sp_recompile'을 실행하면 캐시에서 관련 실행 계획이 삭제되며, 이를 통해 SQL Server는 다음 프로시저 실행 시 보다 적절한 계획을 만들 수 있습니다.

마지막으로 SSMS를 사용하여 전체 프로시저 캐시와 메모리 버퍼를 정리하는 "궤도에서 핵폭탄 투하" 접근법을 시도할 수 있습니다.

DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE

쿼리를 테스트하기 전에 이렇게 하면 캐시된 실행 계획 및 이전 결과 캐시를 사용할 수 없습니다.

제가 하게 된 일은 다음과 같습니다.

다음 SQL 문을 실행하여 데이터베이스의 모든 테이블에 인덱스를 다시 작성했습니다.

EXEC <databasename>..sp_MSforeachtable @command1='DBCC DBREINDEX (''*'')', @replacechar='*'
-- Replace <databasename> with the name of your database

SSMS에서 동일한 동작을 보려면 다음과 같이 프로세스를 실행했습니다.

SET ARITHABORT OFF
EXEC [dbo].[web_GetMyStuffFool] @UserID=1
SET ARITHABORT ON

이를 무시하는 또 다른 방법은 코드에 이를 추가하는 것입니다.

MyConnection.Execute "SET ARITHABORT ON"

동일한 문제가 발생했지만 SQL 테이블에서 인덱스를 재구성하면 정상적으로 작동하므로 SQL 서버 측에서 인덱스를 재구성하는 것을 고려해야 할 수 있습니다.

DataAdapter 대신 DataReader를 사용하는 것이 어떻겠습니까? 단일 결과 집합이 있는 것처럼 보이고 DB에서 변경사항을 다시 밀어넣지 않을 것이며 .NET 코드에 적용된 제약 조건이 필요하지 않다면 어댑터를 사용하지 마십시오.

편집:

DataTable이 필요한 경우 DataReader를 통해 DB에서 데이터를 가져온 다음 .NET 코드에서 DataReader를 사용하여 DataTable을 채울 수 있습니다.데이터 세트 및 데이터 어댑터에 의존하는 것보다 훨씬 빠를 것입니다.

"왜" 그 자체가 그렇게 느리는지는 모르겠지만, Marcus가 지적했듯이, 관리 스튜디오를 데이터 세트를 채우는 것과 비교하는 것은 사과와 오렌지입니다.데이터셋에는 많은 오버헤드가 포함되어 있습니다.저는 그것들을 싫어하고 제가 도울 수 있다면 절대 사용하지 않습니다.

이전 버전의 SQL 스택이 일치하지 않거나 일부 버전이 일치하지 않는 문제가 있을 수 있습니다(특히 .NET 1.1에서도 문제가 발생했습니다).프레임워크는 스키마 등을 유추하기 위해 "Reflection"에 해당하는 데이터베이스를 시도할 가능성이 높습니다.

유감스럽게도 제약 조건을 사용하여 시도해 볼 수 있는 한 가지 사항은 데이터 리더로 데이터베이스에 액세스하고 코드로 데이터 세트를 구축하는 것입니다.당신은 구글을 통해 샘플을 쉽게 찾을 수 있을 것입니다.

언급URL : https://stackoverflow.com/questions/250713/sqldataadapter-fill-method-slow