집 >데이터 베이스 >MySQL 튜토리얼 >SQL Server 디스크 요청 시간 초과 833 오류 원인 및 해결 방법_MsSql
이 글에서는 주로 SQL Server 디스크 요청 시간 초과 833 오류에 대한 원인과 해결 방법을 소개합니다. 필요하신 분들은 참고하시면 됩니다.
최근 SQL Server 서버의 응답 속도가 매우 느리고, 클라이언트 요청에서 오류가 발생하는 것을 목격했습니다. 데이터베이스에서 디스크 요청을 완료하는 데 15초 이상 걸렸다는 오류 메시지가 오류 로그에 나타납니다.
이런 종류의 문제는 스토리지 시스템이나 디스크의 장애인가요, SQL Server 자체의 문제인가요, 아니면 애플리케이션으로 인해 발생하나요? 어떻게 해결하나요?
이 글에서는 이 문제를 일으키는 특정 요인에 대한 간단한 분석을 수행하지만 모든 잠재적인 가능성을 다룰 수는 없으므로 유사한 문제가 발생할 경우 구체적인 분석을 수행해야 합니다.
SQL Server의 디스크 요청 시간 초과
오류 오류 메시지의 영어 버전은 다음과 같습니다.
SQL Server에서 %d보다 오래 걸리는 I/O 요청이 %d번 발생했습니다. 데이터베이스 ID %d의 파일 [%ls]에서 완료하는 데 초가 소요됩니다. OS 파일 핸들은 0x%p입니다. 0
최근 긴 I/O의 오프셋은 다음과 같습니다. %#016I64x
중국어 버전의 오류 메시지는 다음과 같습니다. 다음과 같습니다
SQL Server에서 데이터베이스 ID %4의 파일 [%3!]에 대한 I/O 요청이 발생했으며 완료하는 데 %2!이 걸렸습니다. 운영 체제 파일 핸들은 0x%5!입니다. 최근 장기 I/O의 오프셋은 %6입니다!
메시지 정보의 833번 오류 메시지를 참고하세요
특정 833 오류 응용 디스크 요청 타임아웃 현상
특정 오류 상황
SQL Server에서 완료하는 데 15초 넘게 걸린 데이터베이스 n의 *** 파일에 대한 m개의 I/O 요청이 발생했습니다. 운영 체제 파일 핸들은 ***입니다. 최신 장기 I/O 오프셋은 다음과 같습니다. ***
즉, 데이터베이스 파일이 자동으로 증가하는 동안 오류가 발생했습니다.
.
더욱 흥미로운 점은 DBA가 이 오류 메시지를 스토리지(부착된 디스크가 아닌 SAN 스토리지) 담당 엔지니어에게 보고하면서 스토리지 시스템의 결함이나 불안정성 때문일 수 있다고 생각하고,
스토리지 엔지니어는 서버를 확인한 결과, 서버에 이상이 있고 메모리가 "거의 꽉 찼다"고 하더군요. 스토리지를 담당하는 엔지니어가 전문 DBA가 아니라는 점을 고려하면, SQL Server 데이터베이스 서버의 메모리 사용량에 대해 잘 모르실 수도 있으니 이런 질문을 하시는 것은 충분히 이해가 됩니다.
데이터베이스 서버에서 사용하는 스토리지는 고성능 SAN 스토리지이기 때문에 해당 스토리지는 여러 서버에서 사용되는 것으로 의심됩니다. 스토리지 오류"는 단순히 스토리지 오류로 간주됩니다.
그럼 이유가 뭔가요?
데이터베이스 엔진 오류 833의 의미
먼저 이 833 오류의 구체적인 의미를 살펴보겠습니다. 고전 책에는 아주 명확하게 설명되어 있습니다.
간단히 말하면 SQL Server가 디스크 읽기 및 쓰기를 요청할 때 사용 중인 디스크 또는 기타 요인이 발생하여 15초 이상 완료하지 못했다는 의미입니다.
예를 들어 데이터를 읽고 쓸 때 작업량이 많거나 다른 문제로 인해 너무 늦거나 응답이 적시에 충분하지 않으면 의심할 여지 없이 SQL Server 외부 서버의 응답 시간에 심각한 영향을 미칩니다.
위 내용은 단순 분석으로 이 문제는 흔하지 않고, 스토리지 시스템에 문제가 있을 가능성도 낮으므로 현재 서버 자체의 요인을 찾을 가능성이 높습니다.
원인 분석
SQL Server 전용 서버이기 때문에 다른 애플리케이션의 요청은 없으며, sqlserver 데이터베이스에 대한 요청과 관련이 있을 가능성이 높습니다.
사실 이 문제가 발생하기 전에는 경고 신호가 있었습니다. 서버는 일반적으로 상당히 안정적입니다(CPU가 60%를 초과하는 경우가 거의 없으며 메모리의 PLE가 20분 이상 안정적일 수 있고 디스크 IO 지연이 낮음 등). .), 하지만 간헐적으로 경련이 발생합니다
경련이 발생하면 CPU가 80% 정도까지 급등하고, 메모리의 PLE가 심각하게 줄어들며, IO 지연이 심각하게 증가합니다.
이제 SQL Server의 Session으로만 시작할 수 있습니다. SQL Server의 활성 세션을 관찰해 보면 특정 유형의 SQL 문에 대한 query시간이 매우 길다는 것을 알 수 있습니다.
보통 이런 유형입니다. 특정 기간의 SQL 쿼리 내부 실행 빈도가 상대적으로 높습니다.
그런데 정상적인 상황에서는 이러한 유형의 SQL의 실행 효율성이 여전히 상대적으로 높습니다. 왜 갑자기 매우 낮아지나요?
활성 세션의 해당 실행 계획을 확인한 결과 이러한 유형의 활성 세션의 대기 상태는 IO 대기(PAGEIOLATCH_SH)이며 SQL 실행은 전혀 예상치 못한 것으로 나타났습니다.
비슷한 쿼리가 상대적으로 자주 실행되기 때문에 이러한 세션은 서로 다른 클라이언트에서 시작됩니다. SQL의 실행 효율성이 떨어지면 서버에 많은 수의 활성 세션이 누적됩니다
SQL 문이 일반적으로 잘 실행되는 이유는 무엇입니까? 갑자기 엄청 느려지더라구요,
그 이유는 어느 시점에서 SQL Server가 자동으로 통계정보의 update를 실행했는데, 상대적으로 큰 테이블인데 통계정보 업데이트를 위한 기본 샘플링 비율이 부족하기 때문입니다. , 샘플링 비율이 충분하지 않으면 이 통계 정보를 전혀 사용할 수 없습니다.
자동 통계 정보 수집이 완료되면 현재 수집된 통계 정보를 바탕으로 이전 SQL 문에 효율적이라고 생각되는 방법(인덱스 탐색 대신 테이블 스캔)을 발행합니다. 실제로 이 방법은 합리적이지 않습니다.
이로 인해 해당 SQL이 무리한 실행 계획을 사용하여 쿼리를 구현하게 되고, 이로 인해 클라이언트가 많은 수의 Sessions를 전송하고 비효율적으로 느리게 실행됩니다.
그래서 CPU가 급증하고, IO 지연 시간이 늘어나고, 메모리의 PLE가 심각하게 떨어지게 됩니다.
수십 개의 쿼리 세션이 불합리한 방식으로 디스크에 요청을 보내고 있으며 디스크가 활성 세션의 데이터 요청으로 인해 데이터 또는 index파일로 인해 응답할 수 없습니다. 자동 성장 요청으로 인해 처음에 언급한 문제가 발생했습니다.
마지막으로 지수 재구성을 통해 해결했습니다(통계정보 업데이트 촉진은 물론 순수 통계정보 업데이트도 가능합니다). 장기적인 예방을 위해서는 임계값과 샘플링 비율을 인위적으로 정의하는 작업이 필요합니다. 통계정보 업데이트 안내입니다.
요약:
데이터베이스 서버의 많은 문제는 연쇄 반응 과정에서 관찰된 현상 중 일부에 해당하며, 반응이 표면에 나타나는 것과 다를 가능성이 매우 높습니다(디스크 요청 시간 초과, 문제는 스토리지 때문인가요? )
전문직은 전문적인 자질이 있어야 합니다. 예를 들어 처음에는 DBA가 스토리지 문제라고 잘못 생각했고, 스토리지 엔지니어는 서버 메모리가 꽉 차서 이상하다고 생각했습니다. , 이것이 문제의 근본 원인은 아닙니다.
문제에 직면했을 때 우리는 근원으로 돌아가 가장 근본적인 원인을 찾아야 하며, 이것이 문제 해결의 열쇠입니다.
위 내용은 SQL Server 디스크 요청 시간 초과 833 오류 원인 및 해결 방법_MsSql의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!