SQL Server 디스크 요청 시간 초과 833 오류 원인 및 해결 방법

최근 에 SQL Server 서버 의 응답 이 매우 느 리 고 클 라 이언 트 요청 이 잘못 되 었 습 니 다.데이터베이스 에 있 는 errorlog 에서 디스크 요청 이 15s 가 넘 어서 야 완 료 된 error 메시지 가 나 타 났 습 니 다.
이러한 문제 에 대해 도대체 저장 시스템 이나 디스크 의 고장 입 니까?아니면 SQL Server 자체 의 문제 입 니까?아니면 응용 프로그램 이 일 으 킨 것 입 니까?또 어떻게 해결 해 야 합 니까?
본 고 는 이 문 제 를 일 으 키 는 특정한 요 소 를 간단하게 분석 할 것 이지 만 모든 잠재 적 인 가능성 을 포함 할 수 없 기 때문에 비슷 한 문제 에 부 딪 히 면 구체 적 인 분석 을 해 야 한다.
SQL Server 의 디스크 요청 시간 초과
이 잘못된 영문 판 의 오류 정 보 는 다음 과 같다.
　　SQL Server has encountered %d occurrence(s) of I/O requests taking longer than %d seconds to complete on file [%ls] in database id %d. The OS file handle is 0x%p. 0
　　The offset of the latest long I/O is: %#016I64x
중국어 버 전의 오류 정 보 는 다음 과 같다.
SQL Server%1 을(를)만 났 습 니 다!2 대 데이터베이스 ID%4!파일[%3!]진행 중인 I/O 요청 이%2 를 초과 하 였 습 니 다!초 만 에 완성 하 다.운영 체제 파일 핸들 이 0x%5 입 니 다!최신 장시간 I/O 의 오프셋 은:%6!
message 정보 중 833 번 오류 메시지 참조

구체 적 인 833 error 신청 디스크 요청 시간 초과 현상
구체 적 으로 잘못 보고 한 상황 은 다음 과 같다.
SQL Server 는 데이터베이스 n 의 파일***에 대한 I/O 요청 이 15 초 를 넘 어서 야 완료 되 었 습 니 다.운영 체제 파일 핸들 은**입 니 다.최신 장시간 I/O 의 오프셋 은:**입 니 다.
데이터베이스 파일 이 자동 으로 늘 어 나 는 과정 에서 오류 가 발생 한 셈 이다.
。
　　
　　
재 미 있 는 것 은 한 DBA 가 이 오류 정 보 를 저장(SAN 저장,걸 린 디스크 가 아 닌)을 담당 하 는 엔지니어 에 게 보고 해 저장 시스템 에 고장 이 있 거나 불안정 으로 인 한 것 이 라 고 생각 하 는 것 이다.
메모리 엔 지 니 어 는 저장 에 문제 가 없다 고 생각 했다.서버 를 검사 한 후에 서버 가 정상 적 이지 않 고 메모리 가 거의 꽉 찼 다 고 말 했다.데이터베이스 서버 에 대해 메모리 가 거의 꽉 찼 다 고 말 하 는 상황 은 완전히 정상 적 이 라 고 할 수 있다.저장 을 담당 하 는 엔지니어 가 전문 DBA 가 아니 기 때문에 SQL Server 데이터베이스 서버 의 메모리 사용 에 대해 잘 알 지 못 할 수도 있다.이 의문 을 제기 하 는 것 도 이해 할 수 있다.
데이터베이스 서버 가 사용 하 는 저장 소 는 고성능 의 SAN 저장 소 이기 때문에 저장 소 는 하나의 서비스 로 존재 하 며 N 다 중 서버 가 공동으로 사용 하 는 것 으로 다른 서버 에 서 는 디스크 요청 이 일어나 지 않 아 한 서버 에'저장 고장'으로 의심 된다 고 해서 저장 고장 으로 간단하게 인정 할 수 는 없다.
그렇다면 그 이 유 는 무엇 일 까?
데이터베이스 엔진 오류 833 의 의미
우선 이 833 오류 의 구체 적 인 의미 가 무엇 인지 살 펴 보고 13 을 담아 서 설명 하지 않 겠 습 니 다.그 전형 적 인 책 에는 명확 하 게 쓰 여 있 습 니 다.
한 마디 로 하면 SQL Server 가 디스크 읽 기와 쓰 기 를 요청 할 때 디스크 가 바 쁘 거나 다른 요 소 를 만 나 15 초 가 넘 도록 완성 되 지 않 았 다 는 뜻 이다.
예 를 들 어 데이터 의 읽 기와 쓰 기 를 할 때 디스크 에 요청 을 해 야 하 는데 디스크 가 바 쁘 거나 다른 문제 가 있어 서 늦 거나 해당 되 는 시간 이 적절 하지 않 으 면 SQL Server 가 대외 적 으로 서버 를 제공 하 는 응답 시간 에 심각 한 영향 을 줄 수 있 습 니 다.
위 에서 간단하게 분석 한 바 와 같이 이 문 제 는 일반 영화 에서 발생 한 것 이 아니 기 때문에 저장 시스템 에 문제 가 발생 할 수 없 기 때문에 현재 서버 자체 의 요 소 를 찾 을 수 있다.

원인 분석
전문 적 인 SQL Server 서버 이기 때문에 다른 프로그램의 요청 이 없 으 며,sqlserver 데이터베이스 에 요청 한 요청 과 관련 이 있 을 수 있 습 니 다.
사실 이 문제 가 발생 하기 전에 이미 조짐 이 있 었 다.평소에 도 안정 적 인 서버(CPU 가 60%를 넘 지 않 고 메모리 의 PLE 도 20 분 이상 안정 적 이 며 디스크 IO 지연 이 낮 다 는 등).다만 가끔 씩 바람 이 부 는 경우 가 있 었 다.
경 기 를 할 때 는 CPU 가 80%대 까지 치 솟 는 것 으로 나타 나 메모리 의 PLE 가 심각하게 떨 어 지고 IO 지연 이 심각하게 높아진다.
현 재 는 SQL Server 의 Session 에 착안 하여 SQL Server 의 활동 Session 을 관찰 할 때 특정한 SQL 문 구 를 조회 하 는 시간 이 매우 길다.
평소에 이런 SQL 은 어느 시간 대 에 실행 되 는 빈도 가 비교적 높 은 편 이다.
그러나 정상 적 인 상황 에서 이런 SQL 의 집행 효율 은 비교적 높 은 데 왜 갑자기 매우 낮 아 졌 습 니까?
이벤트 세 션 의 대응 하 는 실행 계획 을 검사 할 때 이러한 이벤트 세 션 의 대기 상 태 는 모두 IO 대기(PAGEIOLATCHSH),동시에 SQL 의 실행 은 완전히 예상 치 못 한 실행 방식 입 니 다.
유사 한 조회 가 빈번 하기 때문에 이러한 Session 은 서로 다른 클 라 이언 트 에서 시 작 됩 니 다.SQL 의 실행 효율 이 떨 어 지면 서버 에 대량의 활동 Session 이 쌓 입 니 다.
왜 평소에 잘 하 던 SQL 문 구 는 갑자기 느 리 고 느 려 지 는 지,
그 이 유 는 특정한 점 에서 SQL Server 가 통계 정보의 업 데 이 트 를 자동 으로 촉발 시 켰 기 때문이다.그러나 이것 은 비교적 큰 표 이지 만 기본 통계 정보 업데이트 의 샘플링 비율 이 부족 하 다.만약 에 샘플링 비율 이 부족 하면 이 통계 정 보 는 전혀 사용 할 수 없다.
통계 정 보 를 자동 으로 수집 한 후에 현재 수 집 된 통계 정보 에 따라 이전의 SQL 문장 에 효율 적 인 방식(table scan 이지 index seek)을 보 냅 니 다.사실은 이런 방식 은 합 리 적 인 것 이 아 닙 니 다.
이 로 인해 대응 하 는 SQL 은 합 리 적 이지 않 은 실행 계획 을 이용 하여 조 회 를 실현 하 는 동시에 Session 의 정 체 를 초래 할 수 있다.클 라 이언 트 가 대량의 Session 을 보 내 는 동시에 비효 율 적 인 방식 으로 천천히 집행 한다.
그래서 CPU 가 치 솟 고 IO 지연 이 증가 하 며 메모리 의 PLE 가 심각하게 떨어진다.
이 를 통 해 수 십 개의 조회 세 션 이 불합리한 방식 으로 디스크 요청 을 미 친 듯 이 생각 하고 있 음 을 이해 하기 어렵 지 않다.디스크 는 세 션 의 데이터 요청 을 활동 하 느 라 바 쁘 고 데이터 나 색인 파일 의 자동 증가 요청 에 응답 하지 못 해 처음에 말 한 문제 가 발생 하고 있다.
마지막 으로 색인 재 구축(통계 정 보 를 업데이트 시 키 고 순수한 통계 정보 업데이트 도 가능)을 통 해 해결 할 수 있 습 니 다.장기 적 으로 예방 하려 면 job 를 배정 하여 통계 정보 업데이트 의 한도 값 과 샘플링 백분율 을 인위적으로 정의 해 야 합 니 다.
요약:
데이터베이스 서버 의 문제,많은 문 제 는 연쇄 반응 의 과정 입 니 다.관찰 한 일부 현상 에 대응 하여 표면적 인 반응 이 아 닐 가능성 이 높 습 니 다.(디스크 요청 시간 초과,문 제 는 저장 소 에 있 습 니까?)
전문 적 인 위치 에 전문 적 인 소양 이 있어 야 한다.예 를 들 어 처음에 DBA 는 저장 문제 로 착각 하고 저장 엔지니어 가 서버 메모리 가 가득 쓰 인 것 이 정상 적 이지 않다 고 생각 하 는 등 문제 의 근본 적 인 원인 이 아니다.
문제 에 직면 하여 근본 적 인 원인 을 찾 는 것 이 야 말로 문 제 를 해결 하 는 관건 이다.