네트워크 대기 시간이 증가하면 MS SQL Server에서 테이블 잠금이 발생합니까?

대기 시간이 긴 네트워크를 통해 SQL Server 데이터베이스를 단일 호출하는 경우 해당 대기 시간으로 인해 테이블 ​​잠금이 발생합니까? 일부 레코드에 대해 테이블 ​​A를 쿼리하고 SQL Server가 느린 네트워크를 통해 해당 데이터를 반환해야한다고 가정합니다. 서버가 네트워크를 통해 응답을 보내는 동안 테이블 A에 읽기 잠금이 있거나 SQL Server가 보내기 전에 잠금을 해제합니까? 응답?

또한 답변의 크기에 따라 답변이 달라 집니까? 몇 KB와 수백 MB를 반환해야한다면 차이가 있습니까?

트랜잭션 기간이 지연 시간과 관련되어 있으므로 명시 적 트랜잭션을 만들고 쿼리를 실행하고 트랜잭션을 닫으면 테이블이 잠길 수 있습니다.

클라이언트가 데이터를 수신하는 데 오랜 시간이 걸리고 SQL Server가 수신 한 데이터를 수신했다는 확인을 SQL Server로 전송하는 경우이 대기로 인해 SQL Server는 클라이언트로부터 승인을받지 않으면 쿼리가 보유한 잠금을 해제하지 않습니다.

이것은 정확하지 않으며 격리 수준에 따라 다릅니다.

기본적으로 READ COMMITTED잠금은 명령문 실행 기간 동안 유지되지 않습니다. READ COMMITTED명령문 레벨의 읽기 일관성을 제공하지 않으면 커미트되지 않은 데이터를 읽을 수 없다는 것이 유일한 보증입니다. 공유 잠금이 확보되어 행을 읽은 후 해제됩니다.

LOB 유형이없는 한.

잠재적으로 매우 큰 LOB 유형은 버퍼링 할 수 없습니다. 공유 잠금은 기본적으로 당신에게주는 문이 완료 될 때까지 획득하고 유지해야 REPEATABLE READ에서 동작을 READ COMMITTED.

대기 시간이 긴 네트워크를 통해 MSSQL 데이터베이스를 단일 호출하는 경우 해당 대기 시간으로 인해 테이블 ​​잠금이 발생합니까?

대기 시간으로 인해 테이블 ​​잠금이 발생하지 않습니다. 그러나 테이블 잠금을 획득 한 경우 대기 시간이 연장됩니다.

나 ( @RemusRusanu ) 보다 이것의 역학을 잘 아는 사람을 인용하려면 :

실행이 진행됨에 따라 결과가 클라이언트 프로그램으로 다시 반환됩니다. 행이 실행 트리를 '거품'으로 만들면 최상위 연산자는 일반적으로 이러한 행을 네트워크 버퍼에 쓰고 클라이언트로 다시 보내는 작업을 수행합니다. 결과는 일부 중간 저장소 (메모리 또는 디스크)에 먼저 생성 된 다음 클라이언트로 다시 전송되지 않고 생성 된대로 (쿼리가 실행될 때) 다시 전송됩니다. 물론 결과를 클라이언트로 다시 보내는 것은 네트워크 흐름 제어 프로토콜의 적용을받습니다. 클라이언트가 적극적으로 결과를 소비하지 않으면 (예 : SqlDataReader.Read () 호출) 흐름 제어는 전송 측 (실행중인 쿼리)을 차단해야하며 결과적으로 실행을 일시 중단합니다 질문.[출처]

클라이언트 나 네트워크로 인해 SQL Server가 결과를 제공 할 수있는만큼 빠르게 결과가 소비되지 않는 경우 ASYNC_NETWORK_IO대기 시간이 누적됩니다. 다시 말하지만, 이것은 획득 한 잠금에 영향을 미치지 않으며 잠금 유지 기간에만 영향을 미칩니다.

Mark의 답변은 많은 혼란을 해결했지만 NetBalancer를 사용하여 대기 시간을 에뮬레이션하여 테스트 한 결과를 게시하고 싶었습니다.

로컬 컴퓨터에서 원격 SQL Server를 호출하고 작은 트랜잭션 내의 테이블에서 SELECT와 INSERT를 모두 실행했습니다. 원격 컴퓨터에서 로컬 SQL 인스턴스에 연결하고 WHILE 루프를 사용하여 sys.dm_tran_locks 테이블을 반복 반복하여 수정하고 읽는 테이블의 잠금을 찾습니다. 서버에 NetBalancer를 설치하고 서버의 네트워크 연결에서 네트워크 대기 시간을 에뮬레이트하는 데 사용했습니다.

내가 찾은 것은 다음과 같습니다.

• 클라이언트에 많은 데이터를 반환하지 않는 명령문의 경우 대기 시간은 잠금에 영향을 미치지 않습니다. 최대 수백 바이트의 데이터 만 반환했습니다. 내 컴퓨터의 트랜잭션에는 잠금을 유지하는 250ms WAITFOR가 있었고 네트워크 대기 시간을 5000ms로 늘리면 잠금 지속 시간은 250ms에 가깝습니다.
• 많은 데이터를 반환하는 명령문의 경우 대기 시간이 잠금에 미치는 영향 확실히 클라이언트에 수만 행을 반환했으며 대기 시간이 없으면 잠금 지속 시간이 짧았습니다. 대기 시간을 늘리면 모든 데이터를 수신 할 때까지 잠금이 계속되었습니다.

이로부터 데이터가 네트워크 버퍼에 들어가는 한 대기 시간은 중요하지 않다는 결론을 내 렸습니다. SQL이 네트워크 버퍼에 많은 양의 데이터를 넣어야하는 경우 대기 시간으로 인해 해당 버퍼가 백업되고 SQL은 모든 쿼리 결과를 버퍼에 넣을 때까지 테이블 잠금을 유지합니다.

대기 시간이 긴 네트워크를 통해 MSSQL 데이터베이스를 단일 호출하는 경우 해당 대기 시간으로 인해 테이블 ​​잠금이 발생합니까?

SQL Server에서 쿼리를 시작하고 완료하면 결과가 생성되고 출력 버퍼에 배치 한 다음 클라이언트로 보낸 다음 출력 버퍼에서 결과를 가져옵니다. 클라이언트로부터 승인을받지 않으면 SQL Server는 쿼리가 보유한 잠금을 해제하지 않습니다. 차단을 유발할 수 있습니다.

편집 : Evan 이 MS 지원 문서를 참조 할 수 있습니다

섹션 3에서

해당 클라이언트 응용 프로그램이 모든 결과 행을 완료하지 못한 SPID로 인한 차단

서버로 조회를 보낸 후 모든 응용 프로그램은 즉시 모든 결과 행을 페치하여 완료해야합니다. 응용 프로그램이 모든 결과 행을 페치하지 않으면 테이블에 잠금이 남아 다른 사용자를 차단할 수 있습니다. SQL 문을 서버에 투명하게 제출하는 응용 프로그램을 사용하는 경우 응용 프로그램은 모든 결과 행을 가져와야합니다. 그렇지 않은 경우 (그리고 구성 할 수없는 경우) 차단 문제를 해결할 수 없습니다. 문제를 피하기 위해 제대로 작동하지 않는 응용 프로그램을보고 또는 의사 결정 지원 데이터베이스로 제한 할 수 있습니다.