SQL Server에 연결하는 동안 간헐적 또는 주기적인 문제 해결
네트워크 안정성은 다양한 서비스 및 애플리케이션의 원활한 운영에 필수적입니다. 그러나 네트워크 문제로 인해 이러한 안정성이 중단되는 경우가 있습니다. 이 문서는 간헐적 또는 주기적인 네트워크 문제 및 일반적인 오류 메시지를 이해하고 해결하는 데 도움이 됩니다. 이러한 문제는 실망스러울 수 있지만 더 나은 이해와 적절한 문제 해결 기술로 보다 효과적으로 해결할 수 있습니다.
가장 일반적인 오류 메시지
일시적인 문제는 불규칙하게 발생하지만 주기적인 문제는 예측 가능한 간격으로 발생하는 경향이 있습니다. 문제 유형을 식별하는 것은 문제 해결의 첫 번째 단계입니다. 간헐적 또는 주기적인 네트워크 문제가 발생하면 다음과 같은 오류 메시지가 발생할 수 있습니다.
- 통신 링크 실패: 이 오류는 네트워크 구성 요소 간의 통신 중단을 나타냅니다.
- 연결 시간 제한 만료: 서버에 대한 연결 시간이 초과되어 서버가 지연되거나 사용할 수 없음을 시사합니다.
- 일반 네트워크 오류: 일반적인 네트워크 오류 메시지는 종종 네트워크에 대해 지정되지 않은 문제를 나타냅니다.
- 전송 수준 오류: 이 오류는 전송 계층에서 발생하며 데이터 전송에 문제가 있음을 시사합니다.
- 지정된 네트워크 이름을 더 이상 사용할 수 없습니다. 이 메시지는 지정된 네트워크 리소스에 연결할 수 없음을 의미합니다.
- 세마포 시간 제한: 이 오류는 네트워크에서 세마포 사용과 관련된 시간 제한 조건을 가리킵니다.
- 대기 작업 시간 초과: 대기 작업이 일반적으로 네트워크 지연으로 인해 허용되는 시간을 초과했습니다.
- 네트워크에서 입력 스트림을 읽는 동안 심각한 오류가 발생했습니다. 이 메시지는 네트워크에서 데이터를 읽을 때 심각한 오류를 나타냅니다.
- TDS 스트림의 프로토콜 오류: TDS(테이블 형식 데이터 스트림)는 SQL Server에서 사용하는 프로토콜입니다. 이 오류는 프로토콜에 문제가 있음을 나타냅니다.
- 서버를 찾을 수 없거나 액세스할 수 없습니다. 이 오류 메시지는 액세스하려는 서버를 사용할 수 없거나 찾을 수 없음을 나타냅니다.
- SQL Server가 없거나 액세스가 거부되었습니다. 이 오류는 SQL Server에 액세스하려고 할 때 SQL Server가 없거나 인증 오류가 있음을 나타낼 수 있습니다.
원인
가장 일반적인 문제는 바이러스 백신, 네트워크 최적화, 이전 네트워크 드라이버, 잘못된 라우터 또는 스위치 및 애플리케이션의 풀되지 않은 연결로 인한 패킷 삭제와 관련이 있습니다.
바이러스 백신과 같은 일부 원인은 증명하기 어려울 수 있지만 여전히 일반적입니다. 명확한 증거 없이 컴퓨터를 제거하고 다시 부팅하여 증명해야 할 수 있습니다. SQL Server에 대한 예외 만들기도 작동할 수 있습니다. 그러나 네트워크 필터 드라이버가 모니터링되지 않더라도 여전히 로드되므로 바이러스 백신을 해제해도 일반적으로 작동하지 않습니다.
문제 해결 프로세스
참고 항목
이 프로세스는 SQL Server 클라이언트 및 서버 연결을 위해 설계되었습니다. 포트 5022를 통한 SQL Server 미러링, Always-On 및 Service Broker 동기화 트래픽과 같은 다른 통신은 처리되지 않습니다.
일반적으로 문제 해결은 데이터 기반이어야 하며, 이는 보다 집중된 컨텍스트에서 경험적 테스트에 영향을 줄 수 있습니다. 문제가 매우 간헐적이며 네트워크 추적을 캡처하기 어려운 경우 경험적 메서드가 먼저 적용될 수 있습니다.
각 컴퓨터에서 SQLCHECK를 사용하여 보고서 수집
각 컴퓨터에서 SQLCHECK를 실행하여 보고서를 생성합니다. 연결이 실패할 수 있는 이유를 확인하는 것이 유용합니다.
클라이언트 및 서버에서 네트워크 추적 수집
Windows 머신에서 SQLTRACE를 사용하여 네트워크 추적을 수집합니다.
다음 단계에 따라 추적을 준비하고 수행합니다. 2단계와 3단계는 한 번만 수행해야 합니다.
최신 버전의 SQLTRACE를 다운로드하고 C:\MSDATA와 같은 폴더에 압축을 풉니다.
SQLTrace.ini 파일을 열고 다음 설정을 해제합니다.
BIDTrace=no,AuthTrace=no및EventViewer=no파일을 저장합니다.
관리자 권한으로 PowerShell을 열고 디렉터리를 SQLTrace.ps1이 포함된 폴더로 변경합니다.
CD C:\MSDATA추적 컬렉션을 시작합니다.
.\SQLTrace.ps1 -start문제를 재현하거나 오류가 발생할 때까지 기다립니다.
추적을 중지합니다.
.\SQLTrace.ps1 -stop
출력 폴더는 현재 디렉터리에 생성되며 추가 분석에 사용할 수 있습니다.
비 Windows 컴퓨터에서 TCPDUMP 또는 WireShark를 사용하여 패킷 캡처를 수집합니다.
SQL Server Network Analyzer 실행
SQLNAUI(SQL Network Analyzer UI) 는 구문 분석 및 설정 옵션을 위해 추적 파일을 선택하는 그래픽 인터페이스를 제공합니다. SQLNA(SQL Network Analyzer)에서 다운로드합니다.
클라이언트 및 서버 추적을 별도로 처리합니다. 추적을 연결한 경우 동시에 처리합니다. 이러한 파일의 총 크기는 컴퓨터 메모리의 80%를 초과하면 안 됩니다. 관련된 모든 추적 파일을 처리할 수 있는 충분한 메모리가 있는지 확인합니다.
이 도구는 의심되는 문제에 대한 보고서와 대체 연구를 위해 Excel에서 탐색할 수 있는 CSV 파일을 생성합니다.
클라이언트 추적 및 서버 추적에서 일치하는 대화를 찾습니다. 일반적으로 IP 주소와 포트 번호가 일치합니다. 그러나 연결이 모든 종류의 네트워크 주소 변환 또는 포트 매핑을 통과하는 경우 더 어려울 수 있으며 IPV4 패킷 ID를 사용하여 줄을 서서 페이로드를 비교해야 할 수 있습니다.
네트워크 추적 분석에서 찾을 패턴
NETMON 또는 WireShark에서 대화가 어떻게 끝나는지 검사합니다. 클라이언트와 서버가 동일한 것에 동의하는지 또는 다른 스토리를 전달하는지 확인합니다.
SSL 핸드셰이크 중에 연결이 닫혔습니다.
ServerHello 패킷에서 사용되는 암호화 제품군이 Diffie-Hellman 제품군이고 트래픽이 Windows 2012 또는 이전 버전과 Windows 2016 이상 사이인 경우 이 알고리즘은 Windows 2016 보안 패치부터 변경됩니다. 이 암호 그룹 그룹을 사용하지 않도록 설정해야 합니다. 자세한 내용은 Windows에서 SQL Server를 연결할 때 애플리케이션에서 강제로 닫힌 TLS 연결 오류 발생을 참조하세요.
ClientHello 이후 연결이 닫힌 경우 클라이언트와 서버 간에 TLS 1.0 또는 TLS 1.2가 일치하지 않는지 확인합니다. 동일한 경우 두 컴퓨터에서 활성화된 암호 그룹 및 활성화된 해시를 확인합니다.
자세한 내용은 Advanced Secure Sockets Layer 데이터 캡처를 참조하세요.
삭제된 패킷 수
일치하는 대화의 끝을 봅니다. 재전송된 패킷이 많거나(또는 10개의 Keep-Alive 패킷, 1초 간격으로) ACK+RESET가 뒤따르는 경우, 다른 하나는 적시에 응답을 보고하고 다른 하나는 지연된 것으로 보고 대화를 닫거나 재설정하는 경우 네트워크 디바이스와 패킷이 삭제되거나 지연되는 문제를 나타냅니다.
서버가 대화를 다시 설정했음을 나타내는 클라이언트 보고서와 클라이언트가 대화를 다시 설정했음을 나타내는 서버 보고서가 표시될 수도 있습니다. 이는 중간에서 연결을 닫는 잘못된 스위치 또는 라우터로 인해 발생하며, 연결이 잠시 동안 유휴 상태임을 감지하는 경우 이를 수행하도록 구성할 수 있으며, 종종 Keep-Alive 패킷을 무시합니다.
연결 삭제에 대한 자세한 내용은 다음을 참조하세요.
서버 추적과 클라이언트 추적 모두 문제가 클라이언트에 있다는 데 동의합니다.
두 추적 모두 클라이언트에 지연 또는 응답이 표시되지 않거나 클라이언트가 서버 응답을 승인한 후 ACK+RESET을 발급하거나 로그인 시퀀스 중에 연결을 일찍 닫는 경우 TCP/IP 스택 내부와 드라이버의 생각을 살펴보려면 클라이언트에서 BID 추적 및 NETSH 추적을 수행해야 합니다. 이는 바이러스 백신 또는 기타 네트워크 필터 드라이버가 패킷 수신 또는 회신 전송을 지연하는 경우에 일반적입니다. 연결 시간 제한은 초기 SYN 패킷이 유선으로 전송되기 전에 호출된 느린 DNS 응답 또는 느린 보안 API 때문일 수도 있습니다.
SQL Network Analyzer의 임시 포트 보고서를 확인하고 클라이언트가 아웃바운드 포트가 부족하지 않은지 확인합니다.
클라이언트가 SYN 패킷을 보내기 전에 긴 지연이 있는 경우 클라이언트에서 시작된 ACK+FIN에 의해 TCP 3방향 여는 핸드셰이크만 표시되고, 즉시 또는 PreLogin 패킷을 보낸 후 때때로 표시되는 패턴이 표시될 수 있습니다.
네트워크 추적 및 BID 추적을 수집하여 Windows에서 클라이언트 문제 격리
SQLTrace.ini 파일을 열고 다음 설정을 다시 설정합니다.
BIDTrace=Yes,AuthTrace=Yes및EventViewer=Yes애플리케이션에서
BIDProviderList사용 중인 드라이버와 일치하도록 in SQLTrace.ini 구성합니다..NET System.Data.SqlClient는 기본적으로 사용하도록 설정됩니다. 사용 중인 드라이버가 아닌 경우 줄 앞에 추가하여#사용하지 않도록 설정하고BIDProviderListODBC 또는 OLEDB 목록의 시작 부분에서 제거합니다. 이렇게 하면 해당 유형의 지원되는 모든 드라이버가 캡처됩니다. 자세한 내용은 INI 구성을 참조 하세요.파일을 저장합니다.
관리자 권한으로 PowerShell을 열고 디렉터리를 SQLTrace.ps1이 포함된 폴더로 변경합니다.
CD C:\MSDATABID 추적을 수집하는 경우 BID 추적 레지스트리를 초기화합니다.
참고 항목
BID 추적은 기본적으로 사용하도록 설정됩니다.
.\SQLTrace.ps1 -setup추적 중인 서비스 또는 애플리케이션을 다시 시작합니다.
SSIS(SQL Server Integration Services) 패키지와 같은 일부 애플리케이션의 경우 패키지가 실행되면 DTEXEC 또는 ISServerExec의 새 인스턴스가 시작되므로 다시 시작이 의미가 없습니다.
추적 컬렉션을 시작합니다.
.\SQLTrace.ps1 -start문제를 재현하거나 오류가 발생할 때까지 기다립니다.
추적을 중지합니다.
.\SQLTrace.ps1 -stop
출력 폴더는 현재 디렉터리에 생성되며 추가 분석에 사용할 수 있습니다.
다른 Microsoft SQL Server 드라이버를 추적하려면 다음 문서를 참조하세요. 네트워크 추적을 사용하여 수행합니다.
- Linux 및 Mac ODBC 드라이버 BID 추적
- .NET Core SQL 드라이버 추적 수집
- PerfView 다운로드
- PerfView를 사용하여 추적 로그 수집
- Microsoft JDBC 드라이버
타사 드라이버를 추적하려면 공급업체 설명서를 참조하세요.
서버 추적과 클라이언트 추적 모두 문제가 서버에 있다는 데 동의합니다.
두 추적 모두 서버에 지연 또는 응답이 표시되지 않거나 서버가 로그인 시퀀스의 예기치 않은 지점에서 연결을 닫거나 서버가 동시에 많은 연결을 닫는 경우 서버에 몇 가지 문제가 있음을 나타냅니다.
가장 가능성이 높은 원인은 서버 성능 저하, 높은 MAXDOP 및 대규모 병렬 쿼리 및 차단입니다. 이로 인해 스레드가 부족하여 로그인 요청이 즉시 처리되지 않도록 할 수 있습니다. 특히 많은 연결 시간 제한이 동시에 종료되고 LoginAck 열에 "지연"이 표시되는 경우 특히 그렇습니다. SQL Server ERRORLOG 파일은 성능 문제의 또 다른 지표인 15초보다 오래 걸리는 IO 작업을 표시할 수 있습니다. 네트워크 추적에서 다시 설정 보고서에 6개 이하의 프레임이 있는 많은 대화가 표시될 수 있습니다. 이는 TCP 3방향 핸드셰이크가 완료되지 않았음을 나타냅니다. 자세한 내용은 연결 링 버퍼 수집을 참조하세요.
쿼리를 RingBufferConnectivity 실행하고 결과를 Excel에 붙여넣습니다. 이 목록은 기록 목록이므로 문제가 발생한 후에 실행할 수 있습니다. 그러나 사용량이 많은 서버의 경우 빠르게 종료될 수 있습니다. 느린 서버의 경우 며칠 동안 데이터가 있을 수 있습니다.
애플리케이션이 MARS(다중 활성 결과 집합)를 사용하는 경우 종료 시퀀스의 일부로 RESET로 끝납니다. SMP:FIN 및 ACK+FIN 패킷이 클라이언트에서 이미 전송된 경우 무해합니다. 서버의 SMP:FIN 패킷은 클라이언트에서 ACK+FIN 후에 도착하며, Windows는 연결 닫기 시퀀스의 일부로 다른 서버 응답에 대해 ACK+RESET 및 RESET을 실행합니다.
연결 풀링
자세한 내용은 연결 풀링을 참조 하세요.
연결 풀링을 사용하는 경우 네트워크 추적의 대화는 일반적으로 상당히 길어집니다. SQL Server Network Analyzer에서 생성된 CSV 파일을 사용하여 프로토콜 및 프레임을 기준으로 정렬 및 필터링할 수 있습니다. 네트워크 캡처가 반 시간 미만인 경우 시작 또는 끝 프레임이 표시되지 않을 수 있습니다. 많은 대화가 SYN 패킷에서 ACK+FIN 패킷까지 30프레임보다 짧은 경우 풀되지 않은 연결을 나타냅니다. 이러한 대화가 몇 가지 긴 대화와 혼합된 경우 결과 집합을 읽는 동안 MARS가 아닌 연결에서 명령을 실행하여 백그라운드 비 풀링 연결이 발생하는 것으로 의심됩니다.
임시 포트 보고서에는 추적 수명 동안의 새 연결 수가 표시됩니다. 초당 연결 수로 연결 속도를 판단할 수 있습니다.
RESET 및 ACK+RESET 비교
ACK+RESET은 일반적으로 애플리케이션 또는 Windows에서 연결을 중단할 때 표시됩니다. 이는 일반적으로 낮은 수준의 TCP 오류 때문입니다. 패킷은 다른 컴퓨터에 즉시 전송을 중지하도록 알릴 수 있습니다. 그러나 서버가 전송 중이면 ACK+RESET가 전송된 후 하나 또는 두 개의 패킷이 클라이언트에 도착할 수 있습니다. 포트가 닫혀 있으므로 운영 체제에서 RESET 패킷을 보냅니다. 일반 닫는 핸드셰이크의 일부가 아닌 ACK+FIN 패킷 이후에 패킷이 도착하는 경우에도 발생합니다.
또한 일부 타사 드라이버는 ACK+FIN 대신 연결을 닫기 위해 ACK+RESET 패킷을 보냅니다. 일부 프로브 연결에서도 이 작업을 수행할 수 있습니다. ACK+RESET 패킷 앞에 Keep-Alive 패킷, 재전송된 패킷 또는 제로 Windows 패킷이 선행되지 않고 ACK+FIN의 정상적인 닫기를 예상할 때 클라이언트에서 가져온 경우 양호할 수 있습니다.
NETSTAT를 사용하여 네트워크 문제 분석
NETSTAT는 데이터 수집을 위해 SQLTrace.ps1을 실행할 때 자동으로 수집됩니다.
또는 관리자 권한으로 명령 프롬프트에서 실행 NETSTAT -abon > c:\ports.txt 하여 네트워크 문제와 관련된 정보를 수집할 수 있습니다.
ports.txt 파일에는 모든 인바운드 및 아웃바운드 포트, 포트 번호, 프로세스 ID 및 포트를 소유하는 애플리케이션의 이름 목록이 포함됩니다. 이를 사용하여 최악의 범죄자와 포트 제한에 도달했는지 여부를 확인할 수 있습니다. 메모장에서 상태 표시줄을 켜고 Word 줄 바꿈을 끕니다. 상태 표시줄은 줄 수를 제공합니다. 대략적인 포트 사용량을 얻기 위해 2로 나눌 수 있습니다.
TcpTimedWaitDelay 및 MaxUserPort 조정
애플리케이션이 호스트 컴퓨터에서 아웃바운드 포트를 소진하고 애플리케이션을 즉시 변경할 수 없는 경우 240초에서 30초로 줄 TcpTimedWaitDelay 여 아웃바운드 포트를 더 빠르게 재활용할 수 있습니다.
Windows 2003 이상의 MaxUserPort경우 . Windows Vista 이상에서는 이 명령을 통해 NETSH 설정합니다. 이 작업 과정에서는 풀링되지 않은 연결 또는 풀링되지 않은 백그라운드 연결의 비효율성을 제거하지 않으며, 개발자는 연결 풀링을 사용하도록 애플리케이션을 변경하는 것이 좋습니다.
Windows 2008 이상에서는 기본적으로 약 4,000개의 임시 포트에서 16,000개의 포트로 범위가 증가했습니다.
자세한 내용은 MaxUserPort 및 TcpTimedWaitDelay 설정 조정을 참조하세요.
바이러스 백신 또는 네트워크 필터 드라이버와 관련된 문제
클라이언트에서 서버 또는 서버로 클라이언트로 전송되는 거의 모든 패킷은 반대 방향으로 진행되는 ACK 패킷으로 응답됩니다. TCP.SYS 계층은 ACK를 생성합니다. 클라이언트에서 패킷이 수신되고 클라이언트 추적에서 들어오는 것을 보여 주지만 ACK가 서버에 반환되지 않는 경우 이는 바이러스 백신 또는 일부 다른 네트워크 필터 드라이버가 패킷을 분실하거나 삭제했거나 오랜 시간 동안(네트워크 추적 컬렉션의 끝을 지나서) 유지되었음을 나타내는 좋은 표시입니다. 마찬가지로 서버 추적에 클라이언트에서 들어오는 패킷이 표시되지만 ACK가 클라이언트로 다시 전송되지 않는 경우 서버의 서버 바이러스 백신에 문제가 있을 수 있음을 나타냅니다.
그러나 대량의 데이터를 업로드하거나 다운로드할 때 ACK 패킷은 흐름 제어에 도움이 되는 일련의 데이터 패킷 뒤에 올 수 있습니다.
바이러스 백신 및 필터 드라이버는 범인으로 증명하기가 매우 어렵습니다. 경험적 테스트는 거의 항상 필요합니다. 바이러스 백신에서 애플리케이션 또는 SQL Server에 대한 예외를 만든 다음 48시간 동안 모니터링하여 동작이 개선되었는지 확인합니다. 예외를 설정할 수 없는 경우 바이러스 백신 프로그램을 제거하고 다시 부팅합니다. 일반적으로 사용하지 않도록 설정해도 바이러스 백신 필터 드라이버가 계속 로드되므로 도움이 되지 않습니다. 에지 보호가 있는 경우에만 최후의 수단으로 이 작업을 수행합니다.
네트워크 보안 관리자에게 문의하세요. 상황이 개선되면 바이러스 백신 공급업체와 협력하여 문제를 완화해야 할 수 있습니다. 그렇지 않으면 다른 네트워크 필터 드라이버가 원인일 수 있습니다.
Windows 방화벽 감사 사용
방화벽이 패킷 을 삭제했는지 여부를 확인하려면 Windows에서 방화벽 감사를 사용하도록 설정합니다.
SQL Server의 경우 이 문제는 클라이언트 또는 서버 컴퓨터와 관련이 있을 수 있습니다. 네트워크 추적은 컴퓨터가 패킷을 받았지만 응답하지 않았음을 보여 줍니다. 그런 다음 패킷을 다시 전송하고 응답을 받지 않으며 결국 연결이 다시 설정됩니다.
경험적 및 기타 작업
임시 포트
일시적 포트가 부족한 것은 간헐적인 연결 시간 제한의 비교적 일반적인 원인이며, 특히 와이어에 SYN 패킷이 표시되지 않는 경우 더욱 그렇습니다.
서버에서 들어오는 요청의 경우 80 또는 1433과 같은 포트는 클라이언트 IP 주소당 최대 64,000개의 들어오는 연결을 사용할 수 있으며 일반적으로 모든 실용적인 용도로 "무제한"입니다.
반면 아웃바운드 연결의 경우 포트 수가 제한되고 모든 서버 연결 간에 공유됩니다. Windows Vista, Windows 2008 이상의 경우 기본 범위는 포트 49152에서 65535(2^16 = 16,384 포트)입니다.
일반적으로 포트는 운영 체제에서 4분(240초) 동안 유지된 후 재활용되고 애플리케이션에서 다시 사용할 수 있습니다. 이는 악성 소프트웨어에 의한 포트 스푸핑 또는 해당 포트의 이전 소유자에 대한 새 연결의 우발적인 리디렉션을 방지하기 위한 것입니다. 이 지연으로 인해 Windows 2003에서 클라이언트 애플리케이션은 SQL Server에 초당 17개만 연결할 수 있으며 아웃바운드 포트 범위는 4분 이내에 소진됩니다. Windows Vista의 경우 이 숫자는 초당 68개의 연결로 증가합니다.
IIS와 같은 애플리케이션의 경우 각 HTTP 클라이언트에는 SQL Server로 나가는 포트가 하나 있을 수 있습니다. 사용량이 많은 웹 서버의 경우 부하가 높을 때 아웃바운드 포트가 부족할 수 있습니다. 웹 팜은 이 상황을 완화할 수 있습니다.
최대 서버 메모리 조정(MB)
낮은 커널 메모리와 관련된 문제를 해결하려면 최대 서버 메모리 (MB)를 조정합니다.
오프로드 사용 안 함
테스트를 위해 관리 명령 프롬프트를 통해 일부 오프로드를 사용하지 않도록 설정할 수 있습니다.
netsh int tcp set global chimney=disabled
netsh int tcp set global rss=disabled
netsh int tcp set global NetDMS=disabled
netsh int tcp set global autotuninglevel=disabled
문제를 완화하지 않는 한 이러한 설정을 오랫동안 사용하지 않도록 설정하지 마세요. Windows 2008 이상에서는 기본적으로 사용하도록 설정해야 합니다.
다른 오프로드의 경우 네트워크 어댑터 속성을 보고 사용하지 않도록 설정하려면 네트워크 어댑터 속성으로 이동해야 합니다.
VMware 네트워크 버퍼 문제
VM(가상 머신)을 포함하는 ESX 호스트에는 트래픽이 급증할 경우 안정성 문제를 일으킬 수 있는 작은 네트워크 버퍼가 있습니다. 다음 VMware 문서에서는 버퍼 크기를 늘리는 방법을 설명합니다. 다시 부팅할 필요가 없습니다. 이 작업은 VM이 아닌 ESX 호스트 컴퓨터에서 수행해야 합니다.
ESXi에서 VMXNET3 사용하여 게스트 OS에서 큰 패킷 손실
또한 VM을 다른 ESX 호스트 서버로 이동하거나 클라이언트와 서버를 동일한 ESX 호스트 서버로 이동하고 문제가 사라졌는지 확인합니다. 이 경우 기본 네트워크 문제입니다.
VMware 스냅샷
오류 중에 발생하는 VMware 스냅샷을 확인하고 사용하지 않도록 설정합니다.
호스트 컴퓨터에서 RSS(수신측 크기 조정)를 사용하지 않도록 설정
RSS를 사용하지 않도록 설정하면 SQL Server 호스트는 단일 CPU만 사용하여 모든 네트워크 요청을 처리합니다. 이로 인해 CPU가 100%로 급증하고 다른 CPU(및 전체 CPU) 수준이 낮더라도 문제가 발생할 수 있습니다.
자세한 내용은 수신측 크기 조정 및 수신측 크기 조정 버전 2(RSSv2) 소개를 참조하세요.
자세한 정보
타사 정보 고지 사항
이 문서에 나와 있는 다른 공급업체 제품은 Microsoft와 무관한 회사에서 제조한 것입니다. Microsoft는 이들 제품의 성능이나 안정성에 관하여 명시적이든 묵시적이든 어떠한 보증도 하지 않습니다.