이해 및 분석-1018,-1019 및-1022 Exchange 데이터베이스 오류

기술 자료 번역 기술 자료 번역
기술 자료: 314917 - 이 문서가 적용되는 제품 보기.
이 문서는 이전에 다음 ID로 출판되었음: KR314917
모두 확대 | 모두 축소

이 페이지에서

요약

이 문서에서는-1018,-1019 및-1022 Exchange 데이터베이스 오류를 분석 하 고 이해 하는 데 도움이 되는 정보를 제공 합니다. 보고 해야 할 세 가지 오류의 원인이 간의 차이점 문제 유형과 이러한 세 가지 오류는 데이터베이스에 설명 합니다.

추가 정보

Exchange 데이터베이스에서 페이지에 대 한 파일 수준 손상을 검색 하는 기능이 포함 되어 있습니다. Exchange 데이터베이스 파일 수준 손상과 관련 된 가장 일반적인 세 가지 오류는 다음과 같습니다.
  • -1018 JET_errReadVerifyFailure
  • -1019 JET_errPageNotInitialized
  • -1022 JET_errDiskIO
다음 세 가지 수준의 손상이 Exchange 데이터베이스에 발생할 수 있습니다.
  • 페이지 (파일 시스템) 수준
  • 데이터베이스 (JET 데이터베이스 엔진) 수준
  • 응용 프로그램 (Exchange 정보 저장소) 수준
Esefile.exe 유틸리티는 페이지 수준에서 데이터베이스에서 오류를 검색할 수 있습니다. Eseutil.exe 유틸리티는 검색 하 고 페이지 수준과 데이터베이스 수준 모두에서 문제를 복구할 수 있습니다. 검색 하 고 응용 프로그램 수준에서 문제를 복구 합니다.

피해 낮은 수준 (페이지 수준) 거의 항상에서 더 높은 수준 (데이터베이스 또는 응용 프로그램 수준)에서 문제를 일으킵니다. 따라서 Eseutil 사용 하 여 데이터베이스를 복구한 후 Isinteg 나중에 사용 하도록 필요한 거의 항상.

데이터베이스 및 응용 프로그램 수준의 손상은 Exchange 코드에서 또는 Exchange에 통합 된 타사 프로그램에 문제가 관련 되어 있습니다. 페이지 수준 손상은 또한 Exchange 문제가 될 수 있습니다 있지만 페이지 수준의 손상은 일반적으로 드라이버, 펌웨어 또는 하드웨어 문제에서 발생 합니다.

거의 항상 Exchange가 의존 하는 기본 시스템 중에-1018 오류에 대 한 근본 원인의 찾을 하 고 Exchange 자체 코드지 않습니다. 이 규칙에는 거의 예외입니다. Exchange 자체에-1018 오류가 발생 하지 않으므로 날짜에 대 한 예외를 관련 하 여 Exchange는-1018 조건을 보고 되었습니다. 에 대 한 자세한 내용은 Microsoft 기술 자료의 다음 문서 번호를 클릭 합니다.
237953온라인 백업 동안 반환 하는 잘못 된-1018 오류
230215 단일 프로세서 컴퓨터에서 수행할 없습니다 백업 checksuming
기본 시스템의 결함으로 대부분의-1019 및-1022 오류가 발생 하지만 오류-1019 및-1022 오류 때문에 Exchange 코드 오류로 발생할 수 있다는 가능성을 제외 없습니다.

-1018 오류는 Exchange 데이터베이스 파일 시스템 수준에서 손상 되었다는 것을 나타내는 가장 일반적으로 나타나는 오류가입니다. 따라서이 문서의 대부분-1018 오류를 설명 합니다.

디스크의 데이터가 손상 될 수 있다는 세 가지 기본 방법에는
  • 잘못 된 데이터 저장소 미디어에 기록 됩니다.
  • 저장소 미디어의 잘못 된 위치에 데이터가 쓰여진 경우
  • 데이터가 손상 되었거나 변경 후 저장 합니다.
방지 하거나 모든 손상을 100%를 해결 하기 위해 매우 어려운 일 이지만 발생 한 문제를 검색은 비교적 쉽습니다. Exchange 부정확 하 고 위치가 잘못 된 데이터를 데이터베이스 파일에서 검색 및-1018 오류 또는-1019 오류를 보고 합니다. 파일이 심각 하 게 손상 된 부품을 아예 없거나 Exchange 파일을 읽으려고 시도할 때 액세스할 수 없는 경우-1022 오류가 보고 됩니다.

Exchange에서 체크섬과 숫자 데이터베이스 페이지를 계산 하는 방법을

-1018 및-1019 오류를 트리거하는 메커니즘의 작동 방식을 이해 하려면 Exchange 데이터베이스가 데이터 페이지를 저장 하는 방법을 이해 해야 합니다.

낮은 논리 수준에서 Exchange 데이터베이스 파일을 일련의 순차적으로 번호가 매겨진 4kb 페이지를 볼 수 있습니다. 데이터를 읽고는 Exchange 데이터베이스 한 페이지에 작성 합니다.

모든 데이터 페이지에서 계산 된 체크섬과 함께 자체 페이지 번호 데이터를 포함 하는 각 페이지를 저장 합니다. 검사 값이이 계산에 포함 되지 않은 페이지의 유일한 부분입니다.

Exchange에서 사용 하는 체크섬 알고리즘을 포함 하 여 체크섬 알고리즘은 이해 하기 쉽고 상대적으로 간단한입니다. 페이지 사이의 차이 하나만 있는 경우에 동일한 검사는 두 개의 다른 페이지에 대 한 발생 가능성이 낮은, 수 있도록 설계 된 비트.

체크섬 테스트 페이지가 쓰여진 후로 페이지의 변경 여부를 확인 하는 데 충분 하지만 체크섬 테스트 페이지가 올바른 위치에 있는지 확인 하려면 충분 하지 않습니다. 이 인해 Exchange 각 페이지 체크섬 뿐만 아니라 자체 페이지 번호에 적용합니다.

데이터베이스에서 처음 두 개의 4KB 페이지는 데이터베이스 "헤더"에 예약 되어 있습니다. 데이터베이스가 중지 되 면 Eseutil 유틸리티를 사용할 수 있습니다. /MH 이 헤더를 보려면 스위치입니다. 머리글 전체 데이터베이스에 대 한 식별 정보를 포함합니다.

이 첫 두 헤더 페이지를 다른 페이지에는 데이터베이스의 모든 데이터 후. 데이터 페이지는 모두 공통 구조를 공유 합니다. 각 페이지에는 실제 데이터가 따라 나오는 특정 페이지에 대 한 id 정보를 포함 하는 전용 페이지 헤더가 있습니다.

Exchange 데이터베이스에서 첫 번째 데이터 페이지의 처음 두 헤더 페이지 이후에 위치한 때문에 데이터베이스에서 실제 페이지 3 1 논리 페이지가입니다. 2는 실제 페이지 4의 논리 페이지 번호입니다.

데이터베이스의 논리 페이지 번호를 실제 페이지 번호로 직접 다음 수식을 통해 매핑됩니다.
논리 페이지 번호 = 실제 페이지 번호-2
데이터베이스 파일의 논리와 실제 페이지 구조는 밀접 하 게 관련이 있으므로 Exchange 각 논리 페이지가 파일에서의 올바른 실제 위치에서 지 쉽게 확인할 수 있습니다.

데이터베이스 체크섬 계산 되지 않은 유일한 페이지는 "초기화 되지 않은 페이지"입니다. 이러한 확보를 위해 더 많은 데이터를 데이터베이스 크기를 확장할 때 만들어지는 페이지 블록입니다. 초기화 되지 않은 페이지는 체크섬과 페이지 번호가 0이 됩니다. 일반적으로 초기화 되지 않은 페이지의 모든 바이트 문자로 채웁니다. 0x00.

초기화 되지 않은 페이지를 처음 사용 하면 비어 있더라도 초기화 되지 않은 상태로 반환 하지 않습니다. 대신 플래그 비어 있는 페이지에 사용할 수 있다고 표시 설정 됩니다. 여전히 페이지 비어 있을 때 페이지 번호와 체크섬이 들어 있습니다.

체크섬 알고리즘과 페이지 서식을 사용 하는 Exchange Server 2003 서비스 팩 1 (SP1)을 변경 합니다. 또한 Exchange Server 2003 SP1 오류를 수정 코드 (ECC) 알고리즘을 검색 하 고 단일 비트 오류를 자동으로 수정 하려면 도입 되었습니다.이 새 기능에 대 한 자세한 내용은 Microsoft 기술 자료의 다음 문서 번호를 클릭 합니다.
867626새 오류 코드를 수정 합니다. Exchange Server 2003 서비스 팩 1에 포함 된

-1018 오류 원인은 무엇입니까

Exchange는-1018 오류는 초기화 페이지 경우 데이터베이스 파일에는 다음 중 하나를 찾을 수를 보고 합니다.
  • 페이지에 저장 된 체크섬은 페이지를 읽을 때에 수행 된 체크섬 재계산 결과 일치 하지 않습니다.
  • 페이지에 저장 된 페이지 번호가 페이지에서 데이터베이스 파일에 페이지의 실제 위치를 지정 해야 하는 페이지 번호를 일치 하지 않습니다.
Exchange는 Exchange에서 다음 중 하나를 수행 하는 경우-1018 오류를 자동 생성할 수 있습니다.
  • 잘못 된 체크섬을 가진 페이지를 작성 합니다.
  • 페이지를 올바로 작성 하지만 잘못 된 위치에 페이지를 쓰도록 운영 체제에 알려 줍니다.
시스템 관리자 관리자는 서버에 [NULL]에 대해 진단 하드웨어 테스트를 실행 하 고이 결과 문제가 없다고 보고할 경우-1018 오류를 발견 한 후 관리자는 하드웨어가 초기 분석을 통과 하기 때문에 Exchange에서 문제를 해결 해야 한다고 생각할 수도 있습니다.

그러나 사례에서 Microsoft 또는 하드웨어 공급 업체 미묘한 문제가 발견 되었습니다 데이터베이스 파일의 손상을 유발 실제로 담당 하는 하드웨어, 펌웨어 또는 장치 드라이버에서 추가 조사 결과.

일반적인 진단 테스트에 여러 가지 이유로 일시적 오류를 모두 발견할 수 없습니다. 펌웨어나 드라이버 소프트웨어의 문제가 진단 프로그램의 능력 밖을 벗어날 수 있습니다. 진단 테스트는 시간이 오래 걸리거나 복잡 한 로드를 적절히 시뮬레이션 하지 못할. 또한 진단 모니터링 이나 디버그 로깅을 추가 문제가 다시 발생 하지 않도록 시스템을 변경할 수 있습니다.

단순성 및 체크섬을 생성 하 고 페이지를 데이터베이스 파일에 기록 하는 Exchange 메커니즘의 안정성에-1018 오류의 원인이 Exchange 문제 가능성이 낮은 또 다른 이유입니다. 체크섬 및 잘못 된 페이지 검색 메커니즘은 간단 하 고 신뢰할 수 있는 및 첫 번째 Exchange 릴리스 이후로 데이터베이스 버전 간에 데이터베이스 페이지 형식 변경을 적용 하기 위한 사소한 변경을 제외 하 고 기본적으로 동일한 남아 있습니다.

또한 약 페이지에 모든 다른 데이터가 기록 된 후 디스크에 쓰여질 페이지에 [NULL]에 대해 체크섬이 생성 됩니다 설명 하기 포함 하 여 페이지 번호입니다. Exchange는 체크섬은 페이지에 추가 되 면 Exchange는 표준의 게시 된 Windows 응용 프로그램 프로그래밍 인터페이스 (Api)를 사용 하 여 페이지를 디스크에 쓰도록 Microsoft Windows 운영 체제에 지시 합니다.

페이지에 대 한 체크섬이 올바르게 생성 될 수 있지만 다음 페이지가 잘못 된 위치에 하드 디스크에 쓸 수 있습니다. "비트 뒤집기" 같은 일시적인 메모리 오류에 의해 발생할 수 있습니다. 예를 들어, Exchange 70 페이지의 새 버전을 생성 하는 것으로 가정 합니다. 페이지 자체에 오류가 발생 하지 않습니다 있지만 디스크 컨트롤러 또는 운영 체제에서 사용 되는 페이지 번호의 복사본이 임의로 변경 됩니다. 이 문제는 불안정 한 메모리 셀에 의해 70 (이진수 100110) 6 (이진수 000110)으로 변경 된 경우에 발생할 수 있습니다. 페이지의 체크섬 여전히 정확 하지만 데이터베이스에서 페이지 위치는 이제 올바르지 않습니다. Exchange 논리 페이지 번호가 페이지의 물리적 위치와 일치 하지 감지 하면 페이지에 [NULL]에 대해-1018 오류를 보고 합니다. Exchange 페이지에서 잘못 된 페이지 번호를 쓰면 다른 유형의 페이지 번호 매기기 (Exchange에서 발생할) 오류가 발생할 수 있습니다. 하지만이-1018 오류가 아닌 다른 오류가 발생 합니다. Exchange 페이지 70에 71을 쓴 다음 페이지에서 체크섬을 올바르게 생성할 경우 페이지는 위치 71에 쓰여지며 페이지 번호와 체크섬 테스트를 모두 통과 합니다.

자주 Exchange 데이터베이스에 보고 되는 단일-1018 오류 데이터베이스를 중지 하거나-1018 오류 이외의 현상은 발생 하지 않습니다. 페이지는 자주 액세스 하지 않는 폴더에 수 있습니다 (예: 보낸 편지함 또는 지운 편지함 폴더), 또는 거의 열지 않거나 비어 있는 첨부 파일에 있습니다.

단일-1018 오류로 데이터가 많이 손실 될 가능성은 됩니다 경우에-1018 오류-1018 오류는 저장 시스템이 안정적으로 저장 하거나 데이터를 적어도 한 번 검색 하지 못한다는 증거가 있기 때문에 여전히 문제의 원인이 됩니다. -1018 오류가 다시 발생 하지 않는 일시적인 문제일 수 있지만이 오류는 점차 악화 될 문제를 조기 경고 인지 더 높습니다. 첫 번째-1018 오류가 데이터베이스의 빈 페이지에서 경우에 페이지 다음 손상를 알 수 없습니다. 중요 한 글로벌 테이블이 손상 된 경우 데이터베이스 시작할 수 없으며 데이터베이스 복구가 실패 하거나 일부만 성공할 수 있습니다.

-1018 오류가 기록 된 후 고려해 야 하 고 근본 원인을 제거 하 고 찾을 때까지 즉시 오류가 발생 하거나 이후에 임의의 손상이 데이터베이스를 계획 해야 합니다.

-1018 오류 복구

Exchange 데이터베이스에서 또 다른 문제를 일으키는에서 임의의 데이터에서 작업 하지 않도록 완전히 읽을 수로-1018 오류가 발생 하는 페이지를 처리 합니다.

-1018 오류와 함께 실패 하는 페이지 복구 하거나 구제할 수 없습니다. 이 데이터베이스에서 expunged 수 있어야 합니다. 데이터베이스에서 페이지를 삭제 하 고 수 세 가지가 있습니다.
  • 온라인 백업에서 데이터베이스를 복원 합니다.
  • Eseutil.exe를 사용 합니다. /D 스위치를 사용 하는 데이터베이스의 오프 라인 조각 모음을 수행 합니다.
  • Eseutil.exe를 사용 합니다. /P 스위치를 사용 하는 데이터베이스를 복구 합니다.

온라인 백업에서 데이터베이스를 복원 합니다.

온라인 백업 도중-1018 오류 발견 되 면 백업이 중지 됩니다. 이렇게 하면 마지막 성공적인 백업에 손상 된 페이지가 없습니다. 순환 로깅이 비활성화 되어 있는 경우 가장 최근의 사용 가능한 전체 백업을 복원 하 고 오는 트랜잭션 로그에서 데이터베이스를 롤 수 있습니다.

Eseutil.exe를 사용 하는 데이터베이스의 오프 라인 조각 모음을 수행 하는 "/d" 스위치

이 메서드는-1018 오류가 빈 페이지에 보고 된 경우 유효 합니다. 온라인 백업이 나 야간 온라인 유지 관리 동안에-1018 오류가 발생 하는 경우 페이지에 거의 액세스 하지 또는 비어 있음을 나타냅니다. 모든 빈 페이지와 보조 인덱스는 데이터베이스에서 오프 라인 조각 모음을 삭제합니다.

Eseutil.exe 사용 "/ P" 스위치 데이터베이스를 복구 하려면

이 메서드를 사용 하면 잘못 된 페이지를 삭제 하면 잘못 된 페이지를 복구입니다. 관련 된 페이지가 "리프 페이지" 인 경우 일부 데이터 손실이 발생 합니다. 리프 페이지는 데이터베이스에서 실제 데이터를 전달 하는 페이지가입니다. 내부 페이지는 구조 정보와 논리 정보를 전달 합니다. 대부분의 경우은 내부 페이지가 손실 된 경우 Eseutil 테이블 완전히 재구성할 수 있습니다. 그러나 데이터베이스에 있는 페이지 대부분은 리프 페이지.

Eseutil의 복구 기능은 작동, 및 대부분의 데이터베이스 작업을 최소한의 데이터 손실에 복원할 수 있습니다. 그러나 많은 페이지가 손상 되었거나 중요 한 시스템 테이블이 손실 된 경우 데이터 손실이 치명적 이거나 데이터베이스를 복구할 수 없는 수 있습니다.

데이터베이스를 복구 합니다. 일반적으로 백업에서 복원 하 고 복구가 복원 보다 시간이 오래 걸리고 더 위험 하기 때문에 데이터베이스를 롤에 비해 품질이 떨어집니다. 경우에 복구를 선택 합니다.
  • 백업이 없습니다.
  • 완전히 백업에서 롤 포워드할 수 없습니다.
복구 또는 데이터베이스를 복원 하기 전에 항상 현재 데이터베이스 파일의 백업 복사본을 확인 합니다. 복원이 작동 하지 않는 경우 기존 데이터베이스를 복구할 수 있습니다. 복구는 작동 하지 않습니다, 하지만 여전히 지라도 데이터베이스의 이전 복사본 경우 손실 될 수 있는 데이터를 수 있습니다.

중요 한 데이터베이스를 복구한 후 데이터베이스 헤더에 있는 복구 카운트를 확인 해야 합니다. 카운트가 0 보다 큰 경우 Eseutil을 사용 하 여는 오프 라인 조각 모음을 수행 해야 하 고 정보 저장소 수준에서 Isinteg 유틸리티는 데이터베이스를 복구 해야 합니다. 그렇게 하지 않으면 사용자가 자신의 사서함에 더 이상 존재 하는 항목의 메시지 또는 첨부 파일 또는 참조를 열 수 없는 등의 문제가 발생할 수 없습니다.

복구 카운트를 확인 하려면 다음 명령을 실행할 때 생성 되는 화면 출력을 검토 하십시오.
ESEUTIL /MH [database_file_name]
복구 된 데이터베이스는 오프 라인 조각 모음을 수행 하려면 다음 명령을 실행 합니다.
ESEUTIL /D [database_file_name]
포괄적인 Isinteg 수정을 복구한 후 Exchange 2000를 위해 정보 저장소 서비스를 실행 해야, 하지만 복구할 데이터베이스는 분리 해야 합니다. 데이터베이스 수정을 위해 다음 명령을 실행 합니다.
ISINTEG-S [서버 이름]-수정-테스트까지
할 포괄적인 Isinteg fix 복구한 후 Exchange Server 5.5에서 정보 저장소 서비스를 중지 해야 합니다. 적절 한 스위치 (사용 하 여 다음 명령을 실행 합니다.우선 순위 또는 -유), 개인 또는 공용 데이터베이스에 [NULL]에 대해 복구를 실행 중인 여부에 따라:
ISINTEG-PRI|PUB-FIX-테스트까지
참고 Eseutil과 Esefile 원시 데이터베이스 파일에 관계 없이 해당 파일에 [NULL]에 대해 시스템 위치 실행 하 여 수 있습니다. 심지어 데이터베이스 파일이 Exchange 서버에 있이 필요가 없습니다. 그러나 Isinteg 정보 저장소 수준에서 작동 하 고 정보 저장소 서비스를 사용 하 여 데이터베이스에 액세스할 수 있으므로 데이터베이스가 완전 하 게 구성 된 Exchange 서버에 있는 동안 Isinteg를 실행 해야 합니다.

에 대 한 자세한 내용은 Microsoft 기술 자료의 다음 문서 번호를 클릭 합니다.
244525없는 Exchange Server 컴퓨터에서 Eseutil을 실행 하는 방법

-1019 오류에서 복구

-1019 오류 (JET_errPageNotInitialized)는 사용 중인 것으로 예상 되는 페이지가 초기화 되지 않았거나 비어 있을 때 보고 됩니다. 사용 중인 페이지의 페이지 번호 필드가 0x00000000 이면 페이지 체크섬 테스트가 실패할 수 있더라도-1019 오류-1018 오류 대신 보고 됩니다.

-1019 오류를 해결 하는 방법-1018 오류를 해결 하려면과 동일 합니다. 메모를 감지-1019 문제 온라인 백업에 의해 검색 되지 않으므로-1019 문제-1018 문제 보다 더 이상 되지 않을 것입니다.

-1018 오류의 원인이 Exchange 외부에 있을 가능성이 있지만 논리 포인터나 페이지 사이의 링크가 잘못 된 경우 Exchange에 의해-1019 오류 발생할 수 있습니다.

그러나 일반적인 파일 시스템이 손상 되었거나 파일에 속하지 않은 데이터베이스 파일에 페이지가 매핑된 때문에-1019 오류가 발생 됩니다.

-1022 오류에서 복구

-1022 오류 (JET_errDiskIO) Exchange 데이터베이스에서 페이지 운영 체제를 요청 하 고 반환 되는 페이지 데이터 대신 오류가 발생 하는 경우에 발생 합니다. -1022 오류는 디스크 입/출력 (I/O) 문제가 발생 하 여 Exchange에서 데이터베이스의 요청한 페이지에 대 한 액세스에 없게 될 때마다 나타나는 일반 오류가입니다.

-1022 오류의 가장 일반적인 이유는 심각 하 게 손상 되었거나 잘린 데이터베이스 파일입니다. 이 문제가 발생 하면 Exchange는 페이지 번호 요청 데이터베이스 파일의 페이지 수보다 큰 하 고-1022 오류가 발생 합니다. 파일 시스템에서 문제 때문에 또는 부적절 한 트랜잭션 로그 재생에 인해 발생할 수 있습니다.

Exchange 2000 데이터베이스를 손상 시킬 수 있는 트랜잭션 로그 재생을 방지 하기 위해 광범위 한 보호 장치가 포함 되어 있지만 Exchange Server 5.5가 불완전 한 로그 파일 집합이 재생 하 고 데이터베이스를 손상 시킬 수 있었습니다. 예를 들어,이 문제는 재생이 로그 9에서 시작 되어야 하지만 대신 재생 로그 10에서 강제로 시작 되는 경우 발생할 수 있습니다. 관리자가 검사점 파일과 로그 9 삭제 한 경우 재생이 강제로 발생할 수 있습니다. 트랜잭션 로그 9에서에서 데이터베이스의 크기를 확장 하지만 로그 9 데이터베이스로 재생 되지 않을 경우 10 로그를 데이터베이스에 추가 된 새 페이지에 대 한 참조가-1022 오류가 발생 합니다. 갑작스런 충돌, 중지, 및 액세스 위반도 데이터베이스에는 불완전 한 트랜잭션 로그 집합을 재생 하는 일반적인 현상 이기도 합니다.

이해 하 고-1022 오류의 원인을 해결-1018 또는-1019 오류를 해결 하는 보다 복잡 한 것입니다. 파일 시스템의 데이터베이스 손상으로 오류가 발생 하는 경우에 확인 또는 파일 시스템을 복구 하 고 다음 백업 으로부터 Exchange를 복원 해야 합니다. 복구는 데이터베이스 복구 여전히 옵션 이지만-1022 오류는 종종 광범위 한 손상을 나타내기 때문에 다른 오류 보다 성공 하려면 가능성이 적습니다.

지금까지 손상 되지 않은 데이터베이스에서-1022 오류의 가장 일반적인 이유는 파일 열기 보유 하 고 정보 저장소를 방지 하 여 다른 응용 프로그램 서비스에서 액세스 합니다. 이러한 경우에는 또한 1032 오류 (JET_errFileAccessDenied)를 볼 수 있습니다. 모든 Exchange 서비스를 다시 시작 하거나 서버를 다시 시작 하면 잠금을 제거할 수 있습니다.

바이러스 검색 프로그램 같은 타사 프로그램, Exchange 데이터를 Exchange 액세스를 차단할 수 있습니다. 항상 파일 검색 작업에서 Exchange 데이터 파일을 제외 하도록 파일 수준 바이러스 검색 프로그램을 구성 합니다. 여러 가지 바이러스 검색 프로그램을 사용할 수 있는 Exchange 바이러스 응용 프로그래밍 인터페이스 (API) 메시지를 검색 하 고 정보 저장소의 첨부 파일을 받아.

-1018 및-1019 오류 분석

이 섹션의 내용은 기술 지원 서비스에 주로 사용 되며 원인 분석에 관련 된 공급 업체 직원.

관리자는-1018 또는-1019 오류를 찾은 후에 관리자는 적어도 세 가지를 알고 있어야 합니다.
  • 무엇에 손상 된 페이지가 되었습니다.
  • 성공적인 복구 가능성 이란
  • 피해를 일으킨
-1018 및-1019 오류는 응용 프로그램 이벤트 로그에서 또는 Eseutil 같은 Exchange 유틸리티 출력에서 서비스를 시작할 때 명령줄에서를 발생할 수 있습니다. 데이터베이스 무결성 검사를 실행 하면 응용 프로그램 이벤트 로그에서-1018 오류가 보고 될 수 있습니다 있는 Eseutil /G 명령입니다. 이 상황에서는 잘못 된 페이지가 빌 가능성이 있습니다.

대부분의 경우 오류는 문제를 보고 하는 페이지를 확인할 수 있는 형태로 보고 됩니다. 또한 Esefile 잘못 된 페이지를 식별 하는 전체 데이터베이스를 검색할 수 있습니다. Esefile에 대 한 자세한 내용은 Microsoft 기술 자료의 다음 문서 번호를 클릭 합니다.
248406Exchange Server 5.5와 Exchange 2000의 Esefile 지원 유틸리티
다음 예제는 각 오류의 세부적인 분석과 함께 Exchange의 다양 한 버전에 대 한 응용 프로그램 이벤트 로그의 일반적인-1018 오류 설명입니다.
MSExchangeIS (248) Synchronous read page checksum error -1018
((1:3106 1:3106)(0-310013)(0-312215)) occurred.
Please restore the databases from a previous backup.
					
앞의 예제에서 괄호 안의 숫자를 다음과 같이 해석할 수 있습니다.
  • (1057816)에서 요청한 (페이지 3106) 및 페이지 (페이지 3106)에 실제로 발견 된 페이지 번호 기록 된 데이터베이스 페이지를 나타내며. 1:이 Exchange Server 5.5의 Priv.edb 데이터베이스 1입니다. 데이터베이스 2는 Pub.edb입니다.
  • (0-310013) 나타내는 dbtime 현재 페이지에 기록 되는 값입니다. 는 dbtime 값은 페이지가 변경 된 이후로 경과 된 시간 관련 각 페이지에 기록 하는 64 비트 값이입니다.
  • (0-312215)는 전류를 나타냅니다. dbtime 전체 데이터베이스에 대 한 값: 가능성이 있는 dbtime 페이지가 지금 변경 된 경우이 페이지에 기록 될 값입니다. 는 dbtime 값에는 항상 현재 보다 작은 이어야 합니다. dbtime 값입니다.
페이지 번호를 페이지에서 올바르게 읽지는, dbtime (첫번째로 적당 dbtime 값 초 보다 낮은), 데이터베이스 외부에서 페이지 또는 다른 페이지에이 페이지를 완전히 교체 되지 않습니다.

Esefile을 사용 하 여 다음과 비슷한 명령으로 페이지 자체를 출력할 수 있습니다.
Esefile /d database.edb 3106 > 3106.txt
이 페이지 구조와 관련 하 여 크게 손상 되지 않은 것으로 나타나기 때문에 Eseutil을 사용 하 여 논리적인 페이지 정보를 볼 수도 있습니다. Exchange 2000과 Exchange Server 5.5 데이터베이스 구조 정보 페이지를 보려면 Eseutil의 Exchange 2000 버전을 사용할 수 있습니다.

경고 데이터베이스에 기록 되는 모드에는 Exchange Server 5.5 데이터베이스에 [NULL]에 대해 Eseutil의 Exchange 2000 버전을 사용 하지 않습니다. 안전을 위해서는 전용의 /M 스위치 및 사용 안 함은 /P, /G또는 /R. 또한 eseutil.exe와 ese.dll의 Exchange 2000 버전은 Exchange Server 5.5 컴퓨터로 복사 하지 마십시오. 대신 원격 서버에이 파일을 복사 하 고 검사 하 고 데이터베이스에는 명시적 명령줄 UNC (범용 명명 규칙) 경로 제공 합니다.

다음 명령과 비슷한 명령은 텍스트 파일에는 페이지의 논리 정보를 출력합니다.
Eseutil /M \\exchange1\d$\exchsrvr\mdbdata\priv.edb /p3106 > 3106.txt

Initiating FILE DUMP mode...
      Database: priv.edb
          Page: 3106

                        pgnoThis <0x02360004,  4>:  3106 (0x00000c22)
                        objidFDP <0x02360018,  4>:  19 (0x00000013)
                ulChecksumParity <0x02360000,  4>:  4269350574 (0xfe791eae)
        ** computed checksum: 157180847 (0x095e63af)
                   dbtimeDirtied <0x02360008,  8>:  310013 (0x000000000004bafd)
                          cbFree <0x0236001c,  2>:  436 (0x01b4)
                       ibMicFree <0x02360020,  2>:  3608 (0x0e18)
                     itagMicFree <0x02360022,  2>:  3 (0x0003)
               cbUncommittedFree <0x0236001e,  2>:  0 (0x0000)
                        pgnoNext <0x02360014,  4>:  3108 (0x00000c24)
                        pgnoPrev <0x02360010,  4>:  3088 (0x00000c10)
                          fFlags <0x02360024,  4>:  2050 (0x00000802)
                Leaf page
                Primary page
이 출력에서 페이지가 실제 데이터가 있는 것을 의미 하는 리프 페이지 인지 확인할 수 있습니다. 이 데이터베이스를 복구 하면 복구는 최소한이 데이터 손실 됩니다. 하나 이상의 페이지에 속하는 사서함을 찾는 방법에 대 한 자세한 내용은 Microsoft 기술 자료의 다음 문서 번호를 클릭 합니다.
262196사서함 데이터베이스의 특정 페이지를 소유 하 고 확인 하는 방법
Eseutil 출력이 페이지, 복구 가능성에 대 한 리프 페이지 나열 되지 않는 경우 작업 완전히 높습니다. 대부분의 내부 또는 구조 페이지는 복구 프로세스에 의해 완전히 다시 수 있습니다.

출력도이 "빈 페이지"로 표시할 수 있습니다. 이 경우에 오프 라인 조각 모음 데이터베이스에서 잘못 된 페이지를 삭제 합니다.

페이지가 데이터베이스 파일에 속하지 않는 데이터의 블록에 의해 완전히 교체 된 경우 Eseutil 출력이 의미가 없을 수 있다는 점을 기억 하십시오.

다음 오류는 다른 예입니다.
MSExchangeIS ((247) ) Synchronous read page checksum error -1018
((1:1057816 1:3688618971) (3688618971-3688618971) (0-16815256)) occurred.
Please restore the databases from a previous backup.
이 예제에서는 페이지 번호가 저장 되는 위치를 페이지 머리글 영역 손상 되었음을 의미 합니다. 요청 된 페이지 (3688618971) 페이지에서 실제로 읽은 페이지 번호를 일치 하지 않습니다. 페이지 번호가 데이터베이스에도 존재 하지 않습니다 예상 됩니다. 이러한 경우 인지 확인 하려면 페이지 번호에 4096을 곱한 다음 데이터베이스 파일의 바이트 크기 수를 비교 하며 이 경우 페이지 번호는 데이터베이스 크기 (3688618971 x 4096 = 15108583305216)가 아닌 경우 Exchange가 원래 기록한 하나 될 것입니다.

또한 다음에 유의 첫 번째 dbtime 값이 페이지 번호 패턴을 정확 하 게 반복 합니다. 3688618971을 16 진수 (해당 공학용 모드에서 Calc.exe 사용) 변환 하는 경우 0xdbdbdbdb가 됩니다. Exchange 2000 및 Exchange Server 5.5에서 8 바이트 dbtime 값은 4 바이트 페이지 번호 값 후 즉시 저장 됩니다. 이 인해 두 개의 다른 필드에 [NULL]에 대해 최소 12 개의 연속적인 바이트가 특정 패턴으로 덮어쓴 것 알고 있습니다. Esefile을 사용 하 여이 페이지에서 직접 볼 수 있으면 아마도 전체 페이지가 패턴 0xDB 덮어써진 것 알 수 있습니다. 다른 자주 잘못 된 바이트 패턴은 0xFF입니다. 이 경우 위의 오류가 발생 하는 경우는 dbtime 값이 4294967295가 됩니다.

다음 오류는 바이트 오프셋 파일에, 페이지 번호가 아닌 파일로 페이지 정보를 제공합니다.
Information Store (2160) The database page read from the file
"d:\exchsrvr\MDBDATA\PRIV.EDB" at offset 897024 (0x00000000000db000)
for 4096 (0x00001000) bytes failed verification due to a page checksum
mismatch. The expected checksum was 2651583211 (0x9e0bf2eb) and the
actual checksum was 2651582996 (0x9e0bf214). The read operation will
fail with error -1018 (0xfffffc06). If this condition persists then
please restore the database from a previous backup.
					
세 개의 후행 0을 제거 1을 빼고 결과 10 진수로 변환 하 여 첫 번째 오프셋을 페이지 번호로 변환할 수 있습니다. 이 예제에서 0x00000000000db-1 = 0xda = 십진수 218입니다. Esefile 또는 Eseutil이 십진수 페이지 번호를 사용할 수 있습니다.

참고 하면 오프셋 0x1 대신 0x0에서 카운트를 시작 하기 때문에 데이터베이스에서 두 헤더 페이지를 고려 하도록 2 대신 1을 뺍니다. Esefile 또는 Eseutil 헤더 페이지를 확인 하려는 경우 페이지-1 및 0 페이지를 참조 합니다.

Exchange 데이터베이스 헤더에는 실제로 단일 페이지만이 필요합니다. 두 번째 페이지는 헤더의 "섀도" 복사본입니다. 사용 하는 경우에 보고 되는 체크섬은 Esefile /D 데이터베이스를 완전히 종료 한 후 페이지 덤프 기능 항상 페이지-1 및 0에 [NULL]에 대해 동일 해야 합니다. Exchange 헤더 중 충돌이 다시 작성 하는 경우 Exchange 다시 시작 될 때 머리글 복사 완전 체크섬을 사용 합니다.

앞의 예에서 체크섬 실제로 매우 서로 가까이 두 문자만 다르고. 체크섬이 유사 하면이 페이지는 변경 내용을 최소 라는 것을 나타냅니다: 아마도 단일 비트 오류. 이 페이지도의 논리적 구조를 분석할 수 만큼 포함 될 수 있기 Eseutil /M /P.

오류 메시지에서 예상 되는 체크섬은 지금 데이터베이스에 있는 페이지에서 실제로 읽은 체크섬이입니다. 오류 메시지의 실제 체크섬은 페이지를 읽을 때 Exchange가 동적으로 다시 계산 하는 체크섬이입니다.

페이지의 실제 체크섬이 0x89abcdef 인 경우 페이지에는 모두 0x00 문자가 포함 되어 있습니다. 실제 체크섬이 0x76543210 인 경우 페이지는 모두 0xFF 문자가 포함 되어 있습니다.

다음 예제에서는-1019 오류는 다음과 같습니다.
Information Store (3928) The database page read from the file
"d:\exchsrvr\MDBDATA\PRIV.EDB" at offset 1675264 (0x0000000000199000)
for 4096 (0x00001000) bytes failed verification because it contains
no page data.  The read operation will fail with error -1019 (0xfffffc05).
If this condition persists then please restore the database from a
previous backup.
					
정상 작업 동안 페이지가-1019 오류나-1018 오류를 보고할 경우-1019 오류 우선 하 고 보고 됩니다. 페이지에 작성 된 페이지 번호가 0x00000000, 때마다-1019 오류가 발생 하지만 Exchange 페이지에서 사용 중인 것으로 예상 됩니다. -1019 오류는 파일 시스템 블록 0 데이터베이스 파일의 매핑된 때문에 발생 하는지 여부 또는 Exchange 실수는 사용 하지 않는 페이지를 "사용 중"으로 참조 하기 때문에 입증 하기 어려울 수 있습니다.

페이지가 초기화 되지 여부 또는 일부 다른 상태에서 이전 오류와 구분할 수 없습니다. Esefile과 Eseutil을 사용 하 더 이상 페이지를 확인 해야 합니다. 이 예제에서는 페이지 번호는 십진수 408 (0x199에서 파생)입니다.

Eseutil을 사용 페이지를 자세히 검토할 수 있습니다. 는 pgnoThis 값 쿼리 되는 페이지 번호와 일치 해야 하는 ulChecksumParity 값 추가 보고 ** 계산 된 체크섬 페이지의 체크섬이 잘못 된 경우 값입니다. Esefile을 사용 /D 전환 (모두 0x00 문자) 초기화 되지 여부를 확인 하 여 원시 페이지를 찾습니다.

거짓-1018 오류

"False"-1018 오류는 디스크에 있는 페이지가 올바르지만 I/O 시스템이 데이터를 잘못 검색할 때 발생 합니다. 이러한 오류는 대개 일시적 이며 찾기 어렵습니다입니다. 하지만 "false"-1018 오류는 심각한 신호가. 저장소 시스템의 안정성을 손상 될 수 있으며 시스템에 추가 문제나 오류가 발생할 위험이에서 수 있습니다.

시스템에서 일시적인 읽기 오류가 의심 되는 경우 Esefile을 사용 합니다. /D 전환 또는 Eseutil /M /P 관련 된 개별 페이지를 확인. 두 유틸리티를 사용 하 여 전체 데이터베이스를 검색 하는 경우 더욱 나쁜 결과가 발생할 수 있습니다 I/O 시스템에 부담을 넣습니다.

Exchange Server 5.5 서비스 팩 2 (SP2) 일시적인 읽기 오류를 식별 하는 데 도움이 되는 기능을 추가 합니다. Exchange는 읽기 확인 오류가 발생 한 후 16 회 페이지를 다시 읽도록 합니다. 페이지 읽기를 여러 번 시도한 후에 성공 하면 디스크에서 안전 하 게 읽기에는 시스템 문제 임을 나타냅니다. 모든 16 읽기 실패 하는 경우에이 않는다면 페이지 잘못 되었다는 것을 증명 하지 못합니다. Esefile 또는 Eseutil로 보조 테스트를 수행 합니다.

데이터베이스 제로화

데이터베이스 제로화가 없습니다 복구 하거나 데이터베이스 파일을 직접 검사 하 여 읽을 수 있도록 Exchange 데이터베이스에서 삭제 된 정보를 모호 하 게 위한 것입니다. 데이터베이스 제로화에 대 한 자세한 내용은 Microsoft 기술 자료의 다음 문서 번호를 클릭 합니다.
223161ESE 제로화에 대 한 정보
데이터베이스 제로화가 사용 되는 경우 비어 있거나 부분적으로 비어 있는 페이지의 섹션은 특정 문자 패턴으로 덮어쓸 수 있지만 페이지는 여전히 초기화 되지 않은 상태로 돌아가지 않습니다.

속성

기술 자료: 314917 - 마지막 검토: 2011년 5월 24일 화요일 - 수정: 0.1
본 문서의 정보는 다음의 제품에 적용됩니다.
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange 2000 Server Standard Edition
  • Microsoft Exchange Server 5.5 Standard Edition
키워드:?
kbinfo kbmt KB314917 KbMtko
기계 번역된 문서
중요: 본 문서는 전문 번역가가 번역한 것이 아니라 Microsoft 기계 번역 소프트웨어로 번역한 것입니다. Microsoft는 번역가가 번역한 문서 및 기계 번역된 문서를 모두 제공하므로 Microsoft 기술 자료에 있는 모든 문서를 한글로 접할 수 있습니다. 그러나 기계 번역 문서가 항상 완벽한 것은 아닙니다. 따라서 기계 번역 문서에는 마치 외국인이 한국어로 말할 때 실수를 하는 것처럼 어휘, 구문 또는 문법에 오류가 있을 수 있습니다. Microsoft는 내용상의 오역 또는 Microsoft 고객이 이러한 오역을 사용함으로써 발생하는 부 정확성, 오류 또는 손해에 대해 책임을 지지 않습니다. Microsoft는 이러한 문제를 해결하기 위해 기계 번역 소프트웨어를 자주 업데이트하고 있습니다.
이 문서의 영문 버전 보기:314917

피드백 보내기

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com