MSSQLSERVER_833

적용 대상: SQL Server Azure SQL Managed Instance

세부 정보

attribute	값
제품 이름	SQL Server
이벤트 ID	8:33
이벤트 원본	MSSQLSERVER
구성 요소	SQLEngine
심볼 이름	BUF_LONG_IO
메시지 텍스트	SQL Server에서 데이터베이스 [%ls] (%d)의 파일 [%ls]에서 완료하는 데 %d초보다 오래 걸리는 I/O 요청이 %d개 발생했습니다. OS 파일 핸들은 0x%p입니다. 가장 최근의 시간 초과 I/O의 오프셋은 %#016I64x입니다.

설명

이 메시지는 SQL Server가 디스크에서 읽기 또는 쓰기 요청을 실행했으며 요청이 반환되는 데 15초 이상 걸렸다는 것을 나타냅니다. SQL Server는 이 오류를 보고하고 I/O 하위 시스템에 문제가 있음을 나타냅니다. SQL Server와 같은 DBMS(데이터베이스 관리 시스템)는 파일 입력 및 출력(I/O) 작업의 타임라인에 의존합니다. 다음 항목 중 하나가 중단되거나 중단된 I/O 작업이 발생할 수 있으며 SQL Server 응답성 및 성능에 부정적인 영향을 줄 수 있습니다.

• 결함이 있는 하드웨어
• 잘못 구성된 하드웨어
• 펌웨어 설정
• 필터 드라이버
• 압축
• 버그
• I/O 경로의 기타 조건

이러한 I/O 문제로 인해 다음 동작이 발생할 수 있습니다.

• 블로킹.
• 래치 경합 및 시간 제한
• 느린 응답 시간.
• 리소스 경계 확장.
• 다음과 같이 이 메시지와 관련된 다른 증상도 확인할 수 있습니다.
  • PAGEIOLATCH 대기 시간이 깁니다.
  • 시스템 이벤트 로그의 경고 또는 오류입니다.
  • 시스템 모니터 카운터의 디스크 대기 시간 문제를 나타냅니다.

I/O 작업이 15초 이상 보류된 경우 SQL Server는 다음 단계를 수행합니다.

1. 작업이 보류 중임을 검색합니다.

2. 세부 정보 섹션에 설명된 대로 SQL Server 오류 로그에 정보 메시지를 씁니다.

   이 정보 메시지의 여러 섹션에 대한 설명은 다음 표에 설명되어 있습니다.

메시지 텍스트	설명
<숫자> 발생	15초 이내에 읽기 또는 쓰기 작업을 완료하지 않은 I/O 요청 수입니다.
파일 정보	전체 파일 이름, 데이터베이스 이름 및 DBID(데이터베이스 ID) 번호입니다.
Handle	파일의 운영 체제 핸들입니다. 디버거 또는 기타 유틸리티와 함께 운영 체제 핸들을 사용하여 IRP(I/O 요청 패킷) 요청을 추적할 수 있습니다.
Offset	마지막으로 중단된 I/O 작업 또는 마지막으로 중단된 I/O 작업의 오프셋입니다. 디버거 또는 기타 유틸리티와 함께 오프셋을 사용하여 IRP 요청을 추적할 수 있습니다. 참고: 정보 메시지가 SQL Server 오류 로그에 기록되면 I/O 작업이 더 이상 중단되거나 중단되지 않을 수 있습니다.

가능한 원인

정보 메시지는 현재 로드에 다음 조건 중 하나가 발생할 수 있음을 나타냅니다.

• I/O 하위 시스템(SAN, NAS 및 직접 연결됨)이 잘못 구성되었거나 하드웨어 용량에 도달했기 때문에 워크로드가 I/O 경로 기능을 초과합니다.
• 워크로드가 I/O, CPU 및 HBA와 같은 현재 시스템 기능을 초과합니다.
• I/O 경로에 오작동 소프트웨어가 있습니다. 펌웨어 또는 드라이버 문제일 수 있습니다.
• I/O 경로에 오작동하는 하드웨어 구성 요소가 있습니다.
• 운영 체제 수준의 성능 문제입니다.
• 데이터베이스 파일의 I/O 프로세스 또는 스토리지 경로에서 드라이버 개입을 필터링합니다. 예를 들어 바이러스 백신 프로그램입니다.

SQL Server는 I/O 요청을 시작한 시간을 기록하고 I/O가 완료된 시간을 기록합니다. 해당 차이가 15초 이상인 경우 이 조건이 검색됩니다. 또한 SQL Server는 이 메시지가 설명하고 보고하는 지연된 I/O 조건의 원인이 아님을 의미합니다. 이 조건을 중단된 I/O라고 합니다. 대부분의 디스크 요청은 디스크의 일반적인 속도 내에서 발생합니다. 이 일반적인 디스크 속도는 디스크 검색 시간이라고도 합니다. 대부분의 표준 디스크에 대한 디스크 검색 시간은 10밀리초 이내에 발생합니다. 따라서 시스템 I/O 경로가 SQL Server로 반환되는 데는 15초가 긴 시간입니다. 자세한 내용은 추가 정보 섹션을 참조하세요.

사용자 작업

다음 단계를 수행하여 이 오류를 해결합니다.

1. 시스템 이벤트 로그에서 하드웨어 관련 오류 메시지를 검사합니다.
2. 사용 가능한 경우 하드웨어별 로그를 검사합니다. 필요한 방법과 기술을 사용하여 운영 체제, 드라이버 또는 I/O 하드웨어의 지연 원인을 확인합니다.
3. 모든 디바이스 드라이버 및 펌웨어를 업데이트하거나 I/O 하위 시스템에 연결된 다른 진단을 수행합니다.
4. 필터 드라이버(예: 바이러스 백신 프로그램)에 의해 디스크 액세스 속도가 느려질 수 있습니다. 액세스 속도를 높이려면 활성 바이러스 검사에서 오류 메시지에 지정된 SQL Server 데이터 파일을 제외합니다. 자세한 내용은 SQL Server(microsoft.com)를 실행하는 컴퓨터에서 실행할 바이러스 백신 소프트웨어를 선택하는 방법을 참조하세요.
   • fltmc.exe 명령줄 유틸리티를 사용하여 시스템에 설치된 모든 필터 드라이버를 쿼리하고 데이터베이스 파일의 스토리지 경로에서 수행하는 기능을 이해합니다.
5. 성능 모니터 사용하여 다음 카운터를 검사합니다.
   • Average Disk Sec/Transfer
   • 평균 디스크 큐 길이
   • 현재 디스크 큐 길이
6. Storport ETW 로깅과 같은 기능을 사용하여 디스크 단위에 대해 수행된 요청의 대기 시간을 측정할 수도 있습니다. 또 다른 유사한 디스크 I/O 문제 해결 키트는 Windows 성능 레코더의 기본 제공 프로필로 사용할 수 있습니다.
7. sys.dm_io_virtual_file_stats 모니터링하고 스토리지 처리량에 적합한 스토리지 계층 및 IOPS를 선택합니다.

I/O 문제로 인해 발생하는 SQL Server 성능 문제를 진단하고 해결하기 위한 안내된 연습은 I/O 문제로 인한 느린 SQL Server 성능 문제 해결을 참조하세요.

자세한 정보

I/O가 중단되고 I/O가 중단됨

I/O가 중단됨

중단된 I/O는 완료되지 않는 I/O 요청으로 정의됩니다. 자주 중단된 I/O는 IRP가 중단되었음을 나타냅니다. 중단된 I/O 조건을 해결하려면 일반적으로 컴퓨터를 다시 시작하거나 비슷한 작업을 수행해야 합니다. 고정된 I/O 조건은 일반적으로 다음 문제 중 하나를 나타냅니다.

• 하드웨어에 오류가 있습니다.
• I/O 경로 구성 요소의 버그입니다.

지연된 I/O

중단된 I/O는 완료되거나 완료하는 데 과도한 시간이 걸리는 I/O 요청으로 정의됩니다. 중단된 I/O 동작은 일반적으로 다음 이유 중 하나로 인해 발생합니다.

• 하드웨어 구성.
• 펌웨어 설정.
• 추적 및 해결을 위해 하드웨어 또는 소프트웨어 공급업체의 지원이 필요한 필터 드라이버 문제입니다.

SQL Server에서 I/O가 중단되고 I/O 기록 및 보고가 중단됨

SQL Server 지원은 매년 중단되거나 중단된 I/O 문제와 관련된 많은 사례를 처리합니다. 이러한 I/O 문제는 다양한 방식으로 표시됩니다. I/O 문제는 진단 및 디버그하기 가장 어려운 문제 중 일부이며 Microsoft 및 고객의 디버깅에 상당한 시간과 리소스가 필요합니다. I/O 요청의 보고 및 기록은 파일별로 설계되었습니다. 중단된 I/O 요청과 중단된 I/O 요청의 검색 및 보고는 별도의 두 가지 작업입니다.

기록

SQL Server에서 레코드 작업이 발생하는 두 가지 순간이 있습니다. 첫 번째는 I/O 작업이 완료되는 경우입니다. 두 번째 순간은 지연 작성기가 실행되는 경우입니다. 지연 기록기가 실행되면 보류 중인 모든 데이터와 보류 중인 로그 파일 I/O 요청을 확인합니다. I/O 요청이 15초 임계값을 초과하면 레코드 작업이 발생합니다.

보고

보고는 5분 이상 간격으로 발생합니다. 보고는 파일에 대한 다음 I/O 요청이 수행되면 발생합니다. 레코드 작업이 발생하고 마지막 보고서가 발생한 후 5분 이상 경과한 경우 세부 정보 섹션에 언급된 정보 메시지는 SQL Server 오류 로그에 기록됩니다.

15초 임계값은 조정할 수 없습니다. 그러나 추적 플래그 830을 사용하여 중단되거나 중단된 I/O 검색을 사용하지 않도록 설정할 수 있지만 이 작업은 사용하지 않는 것이 좋습니다.

추적 플래그 830을 사용하여 중단 및 중단된 I/O에 대한 검색을 사용하지 않도록 설정할 수 있습니다. SQL Server가 시작될 때마다 이 플래그를 사용하도록 설정하려면 -T830 시작 매개 변수를 사용합니다. 현재 실행 중인 SQL Server 인스턴스에 대한 검색을 사용하지 않도록 설정하려면 다음 문을 사용합니다.

    dbcc traceon(830, -1)

이 설정은 SQL Server 프로세스의 수명 동안에만 적용됩니다.

참고 항목

중단되거나 중단되는 I/O 요청은 한 번만 보고됩니다. 예를 들어 메시지가 10개의 I/O 요청이 중단되었다고 보고하는 경우 이러한 10개 보고서는 다시 발생하지 않습니다. 다음 메시지가 15개의 I/O 요청이 중단되었다고 보고하는 경우 15개의 새 I/O 요청이 중단되었음을 의미합니다.

IRP(I/O 요청 패킷) 추적

SQL Server는 표준 Microsoft Windows API 호출을 사용하여 데이터를 읽고 씁니다. 예를 들어 SQL Server는 다음 함수를 사용합니다.

• WriteFile
• ReadFile
• WriteFileScatter
• ReadFileGather

읽기 또는 쓰기 요청은 Windows에서 IRP(I/O 요청 패킷)로 처리됩니다. IRP의 상태를 확인하려면 다음 기능을 모두 사용합니다.

• Windows 지원
• Storport ETW 로깅

다음 항목에 대해 사용 가능한 업데이트를 확인하는 것이 좋습니다.

• The BIOS
• 펌웨어
• 다른 I/O 경로 구성 요소

추가 디버깅 작업을 수행하기 전에 하드웨어 공급업체에 문의하세요. 디버그 세션에는 타사 드라이버, 펌웨어 또는 필터 드라이버 구성 요소가 포함될 수 있습니다.

시스템 성능 및 쿼리 계획 작업

전반적으로 시스템 성능은 I/O 처리에서 중요한 역할을 할 수 있습니다. 중단되거나 중단된 I/O 작업에 대한 보고서를 조사하는 동안 시스템의 일반적인 상태를 고려해야 합니다. 과도한 로드로 인해 I/O 처리를 포함하여 전체 시스템이 느려질 수 있습니다. 문제가 발생할 때 시스템의 동작은 문제의 근본 원인을 결정하는 핵심 요소가 될 수 있습니다. 예를 들어 문제가 발생하는 동안 CPU 사용량이 증가하거나 높게 유지되는 경우 시스템 프로세스가 너무 많은 CPU를 사용하고 있어 다른 프로세스가 부정적인 영향을 받고 있음을 나타낼 수 있습니다.

성능 카운터

I/O 성능을 모니터링하려면 다음 성능 카운터에서 특정 I/O 경로 정보를 검사합니다.

• Average Disk Sec/Transfer
• 평균 디스크 큐 길이
• 현재 디스크 큐 길이

예를 들어 SQL Server를 실행하는 컴퓨터의 평균 디스크 초/전송 시간은 일반적으로 15밀리초 미만입니다. 평균 디스크 초/전송 값이 상승하면 I/O 하위 시스템이 I/O 수요를 최적으로 따라잡지 못했음을 나타냅니다.

SQL Server는 디스크 큐 길이를 크게 푸시하는 비동기 I/O 기능을 최대한 활용하므로 성능 카운터를 사용하는 동안 주의해야 합니다. 따라서 디스크 큐 길이만 길어도 문제가 되지 않습니다.

Windows 시스템 모니터에서 영향을 받는 각 디스크에 대한 카운터 "실제 디스크: 디스크 바이트/초"를 검토하고 각 프로세스에 대한 "프로세스: IO 데이터 바이트/초" 및 "프로세스: IO 기타 바이트/초" 카운터와 작업 속도를 비교할 수 있습니다. 이렇게 하면 특정 프로세스 집합이 과도한 I/O 요청을 생성하는지 여부를 식별할 수 있습니다. Process 개체의 다양한 기타 I/O 관련 카운터는 보다 세부적인 정보를 표시합니다. SQL Server 인스턴스가 서버의 과도한 I/O 로드를 담당하는 것으로 확인되면 인덱스 및 병렬 처리에 대한 다음 섹션을 참조하세요. I/O 병목 상태를 감지하고 해결하는 방법에 대한 자세한 내용은 I/O 문제로 인한 느린 SQL Server 성능 문제 해결을 참조하세요.

인덱스 및 병렬 처리

인덱스가 누락되어 I/O 버스트가 발생하는 경우가 많습니다. 이 동작은 I/O 경로를 심각하게 푸시할 수 있습니다. ITW(인덱스 전환 마법사)를 사용하는 패스는 시스템의 I/O 압력을 해결하는 데 도움이 될 수 있습니다. 쿼리가 테이블 검색 대신 인덱스의 이점을 얻거나 정렬 또는 해시를 사용하는 경우 시스템은 다음과 같은 이점을 얻을 수 있습니다.

• 쿼리에 대한 성능 이점을 직접 만드는 작업을 완료하는 데 필요한 물리적 I/O가 감소합니다.
• 데이터 캐시의 페이지 수를 줄여야 합니다. 따라서 데이터 캐시에 있는 해당 페이지는 활성 쿼리와 계속 관련이 있습니다.
• 인덱스가 없거나 통계가 만료되어 정렬 및 해시가 사용됩니다. 하나 이상의 인덱스를 추가하여 tempdb 사용 및 경합을 줄일 수 있습니다.
• 리소스, 병렬 작업 또는 둘 다에서 감소합니다. SQL Server는 병렬 쿼리 실행을 보장하지 않으며 시스템의 부하를 고려하므로 모든 쿼리를 직렬 실행에 최적화하는 것이 가장 좋습니다. 쿼리를 최적화하려면 Query Analyzer를 열고 최대 병렬 처리 수준 옵션의 sp_configure 값을 1로 설정합니다. 모든 쿼리가 직렬 작업으로 즉시 실행되도록 조정된 경우 병렬 실행이 더 나은 결과인 경우가 많습니다. 그러나 데이터의 양이 크기 때문에 병렬 실행이 선택되는 경우가 많습니다. 누락된 인덱스인 경우 큰 정렬이 발생해야 할 수 있습니다. 정렬 작업을 수행하는 여러 작업자가 더 빠른 응답을 만듭니다. 그러나 이 동작은 시스템에 대한 압력을 크게 증가시킬 수 있습니다. 많은 작업자의 큰 읽기 요청으로 인해 CPU 사용량이 증가하면서 I/O 버스트가 발생할 수 있습니다. 인덱스가 추가되거나 다른 튜닝 작업이 발생하는 경우 쿼리를 더 빠르게 실행하고 더 적은 리소스를 사용하도록 튜닝할 수 있습니다.

SQL Server 지원의 실제 예제

다음 예제는 SQL Server 지원 및 Windows 에스컬레이션 지원에서 처리되었습니다. 이러한 예제는 참조 프레임을 제공하고 중단된 I/O 상황에 대한 기대치를 설정하는 데 도움이 됩니다. 또한 시스템이 영향을 받거나 응답할 수 있는 방법을 이해하기 위한 프레임워크를 제공합니다. 특정 하드웨어 또는 드라이버 집합이 특정 위험을 초래하거나 다른 드라이버에 대한 위험이 증가하지 않습니다. 이러한 측면에서 모든 시스템은 동일합니다.

예제 1: 45초 동안 중단된 로그 쓰기

SQL Server 로그 파일을 정기적으로 쓰려는 시도가 약 45초 동안 중단됩니다. 로그 쓰기가 적시에 완료되지 않습니다. 이 동작은 30초 클라이언트 제한 시간을 발생시키는 차단 조건을 만듭니다.

애플리케이션이 SQL Server에 커밋을 제출하고 커밋이 로그 쓰기 보류 중으로 중단됩니다. 이 동작으로 인해 쿼리는 잠금을 계속 유지하고 다른 클라이언트에서 들어오는 요청을 차단합니다. 그런 다음 다른 클라이언트가 시간 초과를 시작합니다. 쿼리 제한 시간이 발생할 때 애플리케이션이 열려 있는 트랜잭션을 롤백하지 않기 때문에 이 문제가 복잡합니다. 이렇게 하면 잠금을 보유하는 수백 개의 열린 트랜잭션이 생성됩니다. 따라서 심각한 차단 상황이 발생합니다.

트랜잭션 처리 및 차단에 대한 자세한 내용은 다음 Microsoft 기술 자료 문서를 참조하세요. 224453 SQL Server 차단 문제 이해 및 해결

애플리케이션은 연결 풀링을 사용하여 웹 사이트를 서비스합니다. 더 많은 연결이 차단되면 웹 사이트에서 더 많은 연결을 만듭니다. 이러한 연결은 차단되고 주기는 계속됩니다.

로그 쓰기를 완료하는 데 약 45초가 걸립니다. 그러나 이번에는 수백 개의 연결이 백업됩니다. 차단 문제로 인해 SQL Server 및 애플리케이션의 복구 시간이 몇 분 정도 발생합니다. 애플리케이션 문제와 함께 중단된 I/O 조건은 시스템에 매우 부정적인 영향을 줍니다.

해결 방법

HBA(Host Bus 어댑터) 드라이버에서 문제가 중단된 I/O 요청으로 추적됩니다. 컴퓨터에 장애 조치(failover) 지원이 포함된 여러 HBA 카드가 있습니다. 한 HBA가 뒤처지거나 SAN(스토리지 영역 네트워크)과 통신하지 않는 경우 "장애 조치(failover) 전 다시 시도" 제한 시간 값은 45초로 구성됩니다. 제한 시간이 초과되면 I/O 요청이 두 번째 HBA로 라우팅됩니다. 두 번째 HBA는 요청을 처리하고 신속하게 완료됩니다. 이러한 중단 조건을 방지하기 위해 하드웨어 제조업체는 5초의 "장애 조치(failover) 전에 다시 시도" 설정을 권장합니다.

예제 2: 드라이버 개입 필터링

많은 바이러스 백신 소프트웨어 프로그램 및 백업 제품은 I/O 필터 드라이버를 사용합니다. 이러한 I/O 필터 드라이버는 I/O 요청 스택의 일부가 되며 IRP 요청에 액세스할 수 있습니다. Microsoft 제품 지원 서비스는 필터 드라이버 구현에서 중단된 I/O 조건 또는 중단된 I/O 조건을 만드는 버그의 다양한 문제를 확인했습니다.

이러한 조건 중 하나는 백업이 발생할 때 열려 있는 파일의 백업을 허용하는 백업 처리를 위한 필터 드라이버입니다. 시스템 관리자가 파일 백업 선택에 SQL Server 데이터 파일 디렉터리를 포함했습니다. 백업이 발생하면 백업이 시작될 때 파일의 올바른 이미지를 수집하려고 시도합니다. 이렇게 하면 I/O 요청이 지연됩니다. I/O 요청은 소프트웨어에서 처리할 때 한 번에 하나만 완료할 수 있습니다.

백업이 시작되면 SQL Server의 I/O가 한 번에 하나씩 완료해야 하므로 SQL Server 성능이 크게 저하됩니다. 한 번에 하나씩 논리는 I/O 작업을 비동기적으로 수행할 수 없으므로 문제가 복잡해집니다. 따라서 SQL Server에서 I/O 요청을 게시하고 계속해야 하는 경우 I/O 요청이 완료될 때까지 작업자가 읽기 또는 쓰기 호출에서 중단됩니다. 필터 드라이버의 작업은 SQL Server 미리 읽기와 같은 처리 작업을 효과적으로 사용하지 않도록 설정합니다. 또한 필터 드라이버의 또 다른 버그는 백업이 완료된 경우에도 프로세스에서 한 번에 작업을 남깁니다. SQL Server 성능을 복원하는 유일한 방법은 필터 드라이버 상호 작용 없이 파일 핸들이 해제되고 다시 액세스되도록 SQL Server를 다시 시작하는 것입니다.

해결 방법

이 문제를 해결하기 위해 SQL Server 데이터 파일은 파일 백업 프로세스에서 제거됩니다. 소프트웨어 제조업체가 파일을 "한 번에 하나씩" 모드로 전환한 문제를 해결했습니다.

예제 3: 숨겨진 오류

많은 고급 시스템에는 부하 분산 또는 유사한 작업을 처리하는 다중 채널 I/O 경로가 있습니다. Microsoft 제품 지원에서 I/O 요청이 실패하지만 소프트웨어가 오류 조건을 올바르게 처리하지 못하는 부하 분산 소프트웨어에 문제가 있습니다. 소프트웨어는 무한 재시도를 시도할 수 있습니다. I/O 작업이 중단되고 SQL Server에서 지정된 작업을 완료할 수 없습니다. 앞에서 설명한 로그 쓰기 조건과 마찬가지로 이러한 조건이 시스템을 쐐기화한 후 많은 잘못된 시스템 동작이 발생할 수 있습니다.

해결 방법

이 문제를 해결하려면 SQL Server를 다시 시작합니다. 그러나 경우에 따라 처리를 복원하기 위해 운영 체제를 다시 시작해야 합니다. I/O 공급업체에서 소프트웨어 업데이트를 받는 것이 좋습니다.

예제 4: 원격 스토리지, 미러링 및 Raid 드라이브

많은 시스템에서 미러링을 사용하거나 유사한 단계를 채택하여 데이터 손실을 방지합니다. 미러링을 사용하는 일부 시스템은 소프트웨어 기반이며 일부는 하드웨어 기반입니다. 이러한 시스템에 대한 Microsoft 지원 일반적으로 검색되는 상황은 대기 시간이 증가합니다.

I/O가 완료된 것으로 간주되기 전에 완료해야 하는 경우 전체 I/O 시간이 증가합니다. 원격 미러 설치의 경우 네트워크 재시도에 참여할 수 있습니다. 드라이브 오류가 발생하고 Raid 시스템을 다시 빌드하는 경우 I/O 패턴도 중단될 수 있습니다.

해결 방법

미러링 대기 시간을 줄이거나 다시 빌드 작업을 습격하려면 엄격한 구성 설정이 필요합니다.

예제 5: 압축

Microsoft는 압축된 드라이브에서 SQL Server 데이터 파일 및 로그 파일을 지원하지 않습니다. NTFS 압축이 WAL(Write Ahead Logging) 프로토콜을 중단하기 때문에 NTFS 압축은 SQL Server에 안전하지 않습니다. 또한 NTFS 압축에는 각 I/O 작업에 대한 처리가 증가해야 합니다. 압축은 심각한 성능 문제가 발생하는 동작과 같이 "한 번에 하나씩"을 만듭니다.

해결 방법

이 문제를 해결하려면 데이터 및 로그 파일의 압축을 해제합니다.

자세한 내용은 압축된 볼륨에 대한 데이터베이스 지원을 참조 하세요.

추가 데이터 요소

PAGEIOLATCH_* 및 sys.dm_os_wait_stats DMV(동적 관리 뷰)의 쓰기 로그 대기는 I/O 경로 성능을 조사하는 주요 지표입니다. 표시되는 PAGEIOLATCH 대기가 상당히 높으면 SQL Server가 I/O 하위 시스템에서 대기하고 있음을 의미합니다. 특정 양의 PAGEIOLATCH 대기는 일반적인 예상 동작입니다. 그러나 평균 PAGEIOLATCH 대기 시간이 지속적으로 10밀리초보다 큰 경우 I/O 하위 시스템이 압력을 받는 이유를 조사해야 합니다. 자세한 내용은 다음 문서를 참조하십시오.

• I/O 문제로 인한 느린 SQL 서버 성능 문제 해결
• sys.dm_os_waiting_tasks(Transact-SQL)
• sys.dm_exec_requests
• SQL Server 대기 유형 리포지토리

참조

• DIKSPD를 사용하여 워크로드 스토리지 성능 테스트
• 부실 읽기 또는 쓰기 손실로 인해 보고되지 않은 I/O 문제를 감지하기 위해 추가된 SQL Server 진단 826433
• 로깅 및 데이터 스토리지 알고리즘

SQL Server를 사용하려면 시스템이 SQL Server I/O 안정성 프로그램 요구 사항에 설명된 대로 "안정적인 미디어에 배달 보장"을 지원해야 합니다. SQL Server 데이터베이스 엔진의 입력 및 출력 요구 사항에 대한 자세한 내용은 데이터베이스 엔진 입력/출력 요구 사항을 참조하세요.

I/O 오류에 대한 자세한 내용은 Microsoft SQL Server I/O 기본 사항, 2장을 참조하세요.