IIS 및 SQL Server 2005 (동시 사용자 500 명, 데이터 1TB, IIS 서버 8 개)에서 실행되는 타사 응용 프로그램 (원본에 대한 액세스 권한 없음)에 대한 책임은 사용자에게 있습니다. 우리는 최근 문제가없는 프로덕션 환경에서이 애플리케이션을 몇 달 동안 실행 한 후에 데이터베이스에 대한 막대한 차단을 시작했습니다. 이는 하루 중 임의의 간격으로 약 30 분마다 발생하며 매회 20 ~ 100 회의 세션에 영향을줍니다. 모든 세션이 결국 응용 프로그램 시간 제한에 도달하고 세션이 중단됩니다.SQL Server 2005 차단 문제 (ASYNC_NETWORK_IO)
문제가 사라지고 점진적으로 다시 나타납니다. 차단에 대한 책임 SPID는 항상 다음과 같은 기능을 가지고 다음 SQL 실행되고이 "SELECT claimid, enrollid, 상태, orgclaimid ( VARCHAR (15) @claimid)한다 = ASYNC_NETWORK_IO
- 대기 유형, resubclaimid, primaryclaimid FROM claim where primaryclaimid = @claimid AND primaryclaimid <> claimid "). 이것은 은 하나 또는 두 개의 레코드 만 반환하고 큰 데이터 집합은 반환하지 않는 상대적으로 무해한 SQL입니다.
- NO 기타 SQL 문은 블로킹에 관련되어 있으며이 경우에만 SQL 문입니다.
- 실행 계획이 sys.dm_exec_cached_plans에 캐시 된 매개 변수화 된 SQL입니다.
- 이 SPID는 클레임 테이블에 개체 수준 S 잠금을 가지고 있으므로 클레임 테이블에 대한 모든 UPDATE/INSERT도 차단됩니다.
- 호스트 ID는 다양합니다. 다른 웹 서버가 블로킹 세션을 담당합니다. 항상 어떤있다
- : 예를 들면, 때때로 우리는 웹 서버 1, 우리는 차단에 연루 웹 서버에 다시 추적 2.
, 우리는 다음을 참조 때로는 웹 서버에 다시 추적 일종의 웹 서버의 이벤트 로그에 응용 프로그램 관련 오류 을 호스트 ID에 연결하고 호스트 프로세스 ID 을 SQL 세션에서 연결했습니다.
- 오류 메시지는 다양합니다. 보통 일종의 SystemOutofMemory입니다. (이 오류 메시지는 우리가 전에 을 무슨 일이 일어 생각합니다. 우리는 극적인 결과없이 과거에 본 오류 메시지와 유사한 것으로 보이지만, 차단으로 이어질하지 않았다. 왜 지금?)
- 웹 서버의 어댑터 또는 웹 서버의 어댑터와 관련된 알려진 문제점이 없습니다.
상황이 배제 :
- 인덱스는 정기적으로 조각 모음을하고 있습니다.
- 통계가 정기적으로 업데이트됩니다.
- claim.primaryclaimid에서 통계 의 표본 크기가 증가했습니다.
- 캐시 된 실행 계획을 강제로 다시 컴파일합니다.
- primaryclaimid, claimid로 복합 색인을 만들었습니다.
- 네트워킹 문제가 없습니다.
- 웹 서버에 알려진 문제점이 없습니다.
- 웹 서버의 응용 프로그램 소프트웨어는 변경되지 않습니다.
우리는 일련의 사건이 이런 식 가설 :
- 웹 서버 프로세스가 위의 SQL 을 제출합니다.
- 중에 SQL 서버가 SQL을 실행하여 클레임 테이블에 대한 잠금을 획득합니다.
- 웹 서버 프로세스에 오류가 발생하여 이 종료됩니다.
- 웹 서버 프로세스가 데이터 세트를 읽으려면 을 기다리는 중 SQL 서버 세션이 중단되었습니다. 주장 테이블의 일부에 (누구 처리 주장을) X 잠금을 얻을 필요가
- SQL 서버 세션 주장 테이블에 잠금에 의해 차단 을하고 그들은 모든 응용 프로그램 시간을 명중 할 때까지 차단 된 상태로 유지됩니다.
공급 업체의 지원을 기다리는 동안 문제를 해결하기위한 제안은 언제든지 환영합니다.
이 특정 SQL 문의 행/페이지 수준에서만 SQL Server를 강제로 잠글 수있는 방법이 있습니까? 대기중인 ASYNC_NETWORK_IO에 임계 값을 설정하는 방법이 있습니까?
신속하고 유익한 답변을 보내 주셔서 감사합니다. 우리는 모든 웹 서버의 어댑터/물리적 네트워크 연결을 재확인했으며이를 배제 할 수 있다고 생각합니다. 블로킹에 연루된 SQL 문은 보통 네트워크 버퍼를 오버 플로우하고 장기간 ASYNC_NETWORK_IO 대기를 생성하기에 충분하지 않은 매우 작은 데이터 세트 (최대 3 개 레코드)를 리턴합니다. 그러나 수백만 개의 레코드를 반환하는 경계 조건 (@claimid = '')이 있습니다. 이렇게하면 제대로 구성된 웹 서버에서도 ASYNC_NETWORK_IO가 잘 유도 될 수 있습니다. 이것이 우리가 다음에 추구 할 것입니다. – ivankolo