OLEDB를 사용하여 .NET에서 SQL Server 2005를 쿼리 할 때 CASE 감도

StackOverflow https://stackoverflow.com/questions/150017

문제

.NET 애플리케이션에서 SQL Server 데이터베이스로 실행하는 쿼리가 있으며 (5 분 이상) 완료하는 데 시간이 걸리는 것 같습니다. C#에서 테스트 앱을 만들기 위해 너무 오랫동안 말하는 것을 확인하려고 노력했습니다 (쿼리는 빠르게 돌아와야합니다).

어떤 부분이 너무 오래 걸렸는지 확인하기 위해 요소를 추가하여 쿼리를 재구성 할 때 원래 쿼리의 공간과 대문자 차이가있는 유일한 차이점이있는 쿼리를 실질적으로 구두로 재구성했습니다. 이 차이는 약 100 밀리 초의 결과를 반환했습니다.

전에 본 사람이 있습니까? 우리 서버 (동료가 같은 문제가 있기 때문에) 또는 컴퓨터에 서비스가 꺼져 있는지 궁금합니다.

도움을 주셔서 감사합니다.

아래 코드 샘플 아래 (끝에 쿼리의 첫 번째 줄의 차이) (FK_SOURCE vs. FK _SOURCE) :

//Original
    OleDbCommand comm = new OleDbCommand("select min(ctc.serial_no) as MIN_INTERVAL from countstypecode ctc, source s, countstype ct, counts c where ct.value_id=c.value_id and s.c_id=ct.fk_source and " +
      "ct.timeinterval=ctc.typename and ct.timeinterval in ('15min','1h','1day') and c.time_stamp >=  CONVERT(datetime,'01-01-2008',105)  and c.time_stamp < " +
      "CONVERT(datetime,'01-01-2009',105)  and s.c_id = '27038dbb19ed93db011a315297df3b7a'", dbConn);

//Rebuilt
    OleDbCommand comm = new OleDbCommand("select min(ctc.serial_no) as MIN_INTERVAL from countstypecode ctc, source s, countstype ct, counts c where ct.value_id=c.value_id and s.c_id=ct.fk_Source and " +
      "ct.timeinterval=ctc.typename and ct.timeinterval in ('15min','1h','1day') and c.time_stamp >= CONVERT(datetime,'01-01-2008',105) and c.time_stamp < " +
      "CONVERT(datetime,'01-01-2009',105) and s.c_id='27038dbb19ed93db011a315297df3b7a'", dbConn);
도움이 되었습니까?

해결책

이것이 프로 시저 캐시 문제라고 생각합니다. 저장된 절차의 한 가지 이점은 계획이 귀하를 위해 저장되어 속도를 높이는 것입니다. 불행히도 캐시에서 나쁜 계획을 세우는 것이 가능합니다 (동적 쿼리를 사용하는 경우에도).

재미를 위해 프로 시저 캐시를 확인하고, Adhoc 쿼리를 실행하고, 다시 확인한 다음 다른 Capitlization으로 동일한 쿼리를 실행했으며 절차가 더 높은 것을보고 놀랐습니다.

이 시도....

SQL Server Management Studio에 연결하십시오.

DBCC MemoryStatus

Select Columns... From TABLES.... Where....

dbcc MemoryStatus

Select Columns... From tables.... Where....

dbcc MemoryStatus

문이 변경 될 때 (유일한 변경이 경우에도 민감한 경우에도) TotalProcs가 변경 될 것이라고 생각합니다.

통계를 업데이트하면 도움이 될 수 있습니다. 그것은 다소 느리게 달리는 프로세스이므로 느린 기간 동안이를 실행하고 싶을 수도 있습니다.

다른 팁

SQL Server 2005를 사용하고 있으므로 OLEDBCOMMAND 객체 대신 SQLCOMMAND 객체를 사용해 보셨습니까?

성능에 영향을 줄 쿼리의 차이가 보이지 않습니다. 캐싱 또는 인덱스/통계 변경은 어떻습니까? 통계 또는 색인 변경으로 인해 실행 계획이 변경되었을 수 있습니다.

사례와 관련하여 : 사례는 데이터베이스가 사례에 민감하게 설정되어 있는지 여부에 관계없이, 두 쿼리가 사례에 민감한 데이터베이스에서 실행 되려면 두 형식으로 명명 된 열이 있어야합니다. 성능 차이를 일으키지 않습니다.

첫째, 잘못된 쿼리를 100% 확신합니까? SQL Server의 추적 프로파일을 확인하여 DB에서 얼마나 오래 걸리는지 확인하십시오.

둘째, 동일한 수의 결과를 다시 받고 있습니다. 대문자는 SQL Server에서 기본적으로 중요하지 않지만 다르게 설정할 수 있습니다.

"5 분 이상"이 걸린 쿼리가 있다면, 문자열의 경우와 일치하는 데 필요한 100 밀리 초에 대해 걱정하지 않을 것입니다.

모든 답변에 감사드립니다. 차례로 응답하겠습니다.

1) Russ, 나는 sqlconnection이 더 좋을 것이라는 데 동의하지만 불행히도 연결 유형을 설정하지는 않습니다. 방금이 쿼리를 테스트하기 위해 작은 앱을 만들었지 만 쿼리는 훨씬 더 큰 응용 프로그램에서 동적으로 생성됩니다.

2) GBJBAANB, 제가 생각하는 서버 문제는 아닙니다. 거의 동시에 관리 스튜디오에서 두 쿼리를 실행할 수 있기 때문에 .NET (1.1 및 2.0)에서 OLEDB를 통과 할 때만 문제가되는 것 같습니다. 우리는 프로파일 러를 실행했으며 추적 파일은이 방법으로 호출 될 때 쿼리를 완료하는 데 5 분이 걸렸다는 것을 확인했습니다.

3) Joel Coehoorn은 동의했지만 실제로 여기에 도착하려는 것은 "왜"입니다. 왜냐하면 지금 우리는이 문제가 얼마나 큰지, 어디에 있는지 알지 못하기 때문입니다.

4) Cade Roux, 차이는 매우 재현 가능하므로 동일한 결과로 테스트를 연속적으로 실행하고 SQL Server에서 거의 동시에 시간이 걸리기 때문에 인덱스 변경 또는 캐싱에 문제가되지 않는다고 생각합니다. 운영.

가장 완전한 답변에 대한 G Mastros에게 감사하지만, Cade는 통계의 업데이트를 제안했습니다. 그러나 G Mastos의 솔루션은 내 수준의 SQL Server 경험에 더 적합했습니다.

모두를 도와 주셔서 감사합니다!

나는 왜이 겉보기에 결백 한 차이가 그렇게 큰 결과를 가져 오는지 조사 할 것입니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top