다른 클라이언트가 SQL 서버와 통신하는 다른 결과를 기반으로합니다.

Question

오늘 우리 프로덕션 시스템에서 매우 이상한 시나리오가 발생합니다. 누군가가 이와 같은 것을 보았고 나에게 좋은 설명을 주 었는지 궁금합니다.

우리는 Sql Server 2014에 저장 프로 시저를 가지고 있으며 .NET 시스템에서 호출 할 때 데이터를 반환하지 않았습니다.

Sql 프로필러를 사용하여 호출을 캡처하고 동일한 Sql 인증 자격 증명을 사용하여 Sql Management Studio에서 재생했으며 예상대로 결과를 반환했습니다.

우리가 각 시도를 몇 번이나 시도해도 클라이언트가 .NET 클라이언트 일 때 아무런 결과도 얻지 못했고 SSMS 일 때 제대로 작동했음을 일관되게 나타 냈습니다.

SP 재 컴파일을 수행하여 문제를 해결할 수 있었지만 임시 해결책처럼 느껴졌으며 원래 원인이 경고없이 반복 될 수 있다는 것을 알지 못합니다. . 또한 sp 재 컴파일은 결과가 다르지 않은 성능 문제에만 영향을 미친다는 인상하에있었습니다.

이전에 본 사람이 있습니까? sp 재 컴파일이 왜 그것을 고쳤는지 설명 할 수 있습니까?

많은 감사!

Answer 1

일반적으로 쿼리는 SSMS에서 제대로 실행되지만 .Net 클라이언트에서는 시간이 초과됩니다. 그게 당신이 여기서 묘사 한 것일 수도 있습니다.

이 문제의 정확한 원인에 대한 몇 가지 논쟁이 있습니다.

한 쪽에서는 SSMS와 .Net 클라이언트의 기본값이 다릅니다. 가장 일반적인 범죄자가 ON으로 설정 SSMS ARITHABORT,하지만 대부분의 SQL 서버 제공 업체들은 서버 기본값으로 (OFF) 떠나 :이

SQL Server 관리 Studio의 기본 ARITHABORT 설정은 ON입니다

경고 . 클라이언트 응용 프로그램에서 ARITHABORT를 OFF로 설정하면 다른 쿼리 계획이 수신되어 쿼리 성능이 좋지 않은 쿼리의 문제를 해결하기가 어려워집니다. 즉, 동일한 쿼리는 관리 스튜디오 에서 빠르게 실행될 수 있지만 응용 프로그램에서는 느려질 수 있습니다. Management Studio를 사용하여 쿼리의 문제를 해결할 때 항상 클라이언트 ARITHABORT 설정과 일치해야합니다.

이렇게하면 a cached query plan (상당히 복잡한 주제)이 SSMS에서는 잘 작동하지만 닷넷 클라이언트에서는 잘 작동하지 않습니다.

다른 쪽의 문제는 단지 parameter sniffing이므로 저장 프로 시저에 캐시 된 나쁜 계획이 있음을 의미합니다. 이 측면에서는 ARITHABORT 설정으로 인해 서버가 다른 계획을 선택하여 잘못된 계획을 건너 뛰게된다고 주장합니다. 하지만 핵심 문제는 매개 변수 스니핑이며 ARITHABORT 설정은 실제로 해결 방법입니다.

This SO question은 (ARITHABORT ON, OPTION RECOMPILE 사용, OPTIMIZE FOR UNKNOWN 사용 등) 가능한 많은 솔루션을 포함합니다. 그 질문은 또한 Erland Sommarskog의 정액 작업 인 Slow in the Application, Fast in SSMS?: Understanding Performance Mysteries과 관련이 있습니다. 이것은 아마 당신이 알고 싶어하는 것 이상입니다.