Exchange에는 데이터베이스에 있는 페이지에 대한 파일 수준 손상을 검색하는 기능이 포함되어 있습니다. Exchange 데이터베이스에 대한 파일 수준 손상과 관련된 가장 일반적인 세 가지 오류는 다음과 같습니다.
| • |
-1018 JET_errReadVerifyFailure |
| • |
-1019 JET_errPageNotInitialized |
| • |
-1022 JET_errDiskIO |
Exchange 데이터베이스에서는 다음과 같은 세 가지 수준의 손상이 발생할 수 있습니다.
| • |
페이지(파일 시스템) 수준 |
| • |
데이터베이스(JET 데이터베이스 엔진) 수준 |
| • |
응용 프로그램(Exchange 정보 저장소) 수준 |
Esefile.exe 유틸리티는 페이지 수준에서 데이터베이스 오류를 검색할 수 있습니다. Eseutil.exe 유틸리티는 페이지 수준과 데이터베이스 수준 모두에서 문제를 검색하고 복구할 수 있습니다. Isinteg.exe 유틸리티는 응용 프로그램 수준에서 문제를 검색하고 복구합니다.
낮은 수준(페이지 수준)의 손상은 거의 항상 높은 수준(데이터베이스 또는 응용 프로그램 수준)에서 문제를 일으킵니다. 따라서 Eseutil을 사용하여 데이터베이스를 복구한 이후에는 거의 항상 Isinteg를 사용해야 합니다.
데이터베이스와 응용 프로그램 수준의 손상은 Exchange 코드 또는 Exchange에 통합된 타사 프로그램의 문제와 관련이 있습니다. 페이지 수준 손상은 일반적으로 드라이버, 펌웨어 또는 하드웨어 문제가 원인이지만 Exchange의 문제가 원인일 수도 있습니다.
-1018 오류의 원인은 거의 항상 Exchange 코드 자체가 아닌 Exchange가 의존하는 기본 시스템 중 하나에서 발견됩니다. 이 규칙에는 거의 예외가 없습니다. 현재까지의 예외는 Exchange 자체가 -1018 오류의 원인이 아니라 -1018 조건을 보고하는 Exchange에 관한 것이었습니다. 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
237953 (http://support.microsoft.com/kb/237953/) XADM: 온라인 백업 동안 -1018 오류가 잘못 반환된다
230215 (http://support.microsoft.com/kb/230215/) XADM: 단일 프로세스 컴퓨터에서 백업 체크섬이 수행되지 않는다
대부분 기본 시스템의 오류로 -1019 및 -1022 오류가 발생하지만 Exchange 코드 오류로 인해 -1019와 -1022 오류가 발생할 수 있다는 가능성을 배제할 수 없습니다.
오류 -1018은 가장 일반적으로 나타나는 오류이며 Exchange 데이터베이스가 파일 시스템 수준에서 손상되었다는 것을 나타냅니다. 따라서 이 문서에서는 주로 오류 -1018에 대해 설명합니다.
기본적으로 디스크의 데이터는 다음과 같은 세 가지 경우에 손상됩니다.
| • |
저장소 미디어에 잘못된 데이터가 쓰여진 경우 |
| • |
저장소 미디어의 잘못된 위치에 데이터가 쓰여진 경우 |
| • |
저장한 후에 데이터가 손상되었거나 변경된 경우 |
모든 손상을 100% 예방하거나 해결하는 것은 매우 어려운 일이지만 발생한 문제를 검색하는 것은 상대적으로 쉽습니다. Exchange는 잘못된 데이터나 잘못 배치된 데이터를 데이터베이스 파일에서 검색하고 -1018 오류 또는 -1019 오류를 보고합니다. 파일이 심각하게 손상되었고 그 일부가 아예 없거나 Exchange가 파일을 읽으려고 시도할 때 액세스할 수 없는 경우에는 -1022 오류가 보고됩니다.
위로 가기
Exchange가 체크섬과 숫자 데이터베이스 페이지를 계산하는 방법
-1018 및 -1019 오류를 트리거하는 메커니즘의 작동 방식을 이해하려면 Exchange 데이터베이스가 데이터 페이지를 저장하는 방법을 이해해야 합니다.
논리적으로 가장 낮은 수준에서는 Exchange 데이터베이스 파일을 순차적으로 번호가 매겨진 4KB 페이지의 집합으로 볼 수 있습니다. 한 번에 한 페이지의 Exchange 데이터베이스 데이터를 읽고 씁니다.
데이터가 들어 있는 각 페이지는 페이지의 모든 데이터에서 계산된 체크섬과 함께 자체 페이지 번호를 저장합니다. 체크섬 값 자체는 페이지에서 이 계산에 포함되지 않은 유일한 부분입니다.
Exchange가 사용하는 체크섬 알고리즘을 포함하여 체크섬 알고리즘은 이해하기 쉽고 상대적으로 간단합니다. 이 알고리즘은 페이지 사이의 차이점이 단일 비트일지라도 두 개의 다른 페이지에 대해 동일한 체크섬이 계산될 가능성이 낮도록 설계됩니다.
페이지가 쓰여진 후로 페이지의 변경 여부를 확인하는 데는 체크섬 테스트로도 충분하지만 페이지가 올바른 위치에 있는지 확인하기에는 체크섬 테스트가 충분하지 않습니다. 따라서 Exchange는 자체 페이지 번호는 물론 체크섬으로 각 페이지에 스탬프를 찍습니다.
데이터베이스에서 4KB의 처음 두 페이지는 데이터베이스 "헤더"에 예약되어 있습니다. 데이터베이스가 중지되면 Eseutil 유틸리티의
/MH 스위치를 사용하여 이 헤더를 볼 수 있습니다. 헤더에는 데이터베이스에 대한 전체적인 확인 정보가 들어 있습니다.
이 첫 두 헤더 페이지 이후에 나오는 페이지에는 데이터가 들어 있습니다. 데이터 페이지는 모두 공통 구조를 공유합니다. 각 페이지에는 전용 페이지 헤더가 있는데, 여기에는 실제 데이터가 따라 나오는 특정 페이지에 대한 확인 정보가 들어 있습니다.
Exchange 데이터베이스의 첫 번째 데이터 페이지는 처음 두 헤더 페이지 다음에 있기 때문에 데이터베이스에서 실제 페이지 3은 논리 페이지 1이 되고 2는 실제 페이지 4의 논리 페이지 번호가 됩니다.
데이터베이스의 논리 페이지 번호는 다음 공식에 따라 실제 페이지 번호로 직접 매핑됩니다.
논리 페이지 번호 = 실제 페이지 번호 - 2
데이터베이스 파일의 논리 페이지와 실제 페이지 구조는 밀접하게 관련되어 있으므로 Exchange는 각 논리 페이지가 파일의 올바른 실제 위치에 있는지 여부를 쉽게 확인할 수 있습니다.
데이터베이스에서 체크섬이 계산되지 않은 유일한 페이지는 "초기화되지 않은 페이지"입니다. 이 페이지는 더 많은 데이터를 저장할 수 있도록 공간을 만들기 위해 데이터베이스 크기를 확장할 때 만들어지는 페이지 블록입니다. 초기화되지 않은 페이지는 체크섬과 페이지 번호가 0인 페이지입니다. 일반적으로 초기화되지 않은 페이지의 모든 바이트는
0x00 문자로 채워지지만 Exchange Server 4.0 또는 Exchange Server 5.0에서 업그레이드된 데이터베이스에는 이러한 규칙이 적용되지 않을 수 있습니다.
초기화되지 않은 페이지를 처음 사용하면 비어 있더라도 초기화되지 않은 상태를 반환하지 않습니다. 대신 비어 있는 페이지에 다시 사용할 수 있다고 표시하는 플래그가 설정됩니다. 페이지에는 비어 있을 때도 페이지 번호와 체크섬이 들어 있습니다.
Exchange Server 2003 서비스 팩 1(SP1)에서는 사용되는 체크섬 알고리즘과 페이지 서식을 변경했을 뿐 아니라 단일 비트 오류를 검색하고 자동으로 수정하는 ECC(오류 수정 코드) 알고리즘을 도입했습니다. 이 새로운 기능에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
867626 (http://support.microsoft.com/kb/867626/) Exchange Server 2003 SP 1에 새 오류 수정 코드가 포함되어 있다
위로 가기
-1018 오류의 원인
Exchange는 데이터베이스 파일에서 다음 조건에서 초기화된 페이지가 발견되면 -1018 오류를 보고합니다.
| • |
페이지를 읽을 때 수행된 체크섬 재계산 결과와 페이지에 저장된 체크섬이 일치하지 않습니다. |
| • |
데이터베이스 파일에 페이지의 실제 위치가 있을 경우 페이지에 저장된 페이지 번호가 페이지에 있는 페이지 번호와 일치하지 않습니다. |
Exchange에서 다음과 같은 작업을 수행할 경우 -1018 오류가 자동으로 생성될 수 있습니다.
| • |
잘못된 체크섬을 가진 페이지를 작성합니다. |
| • |
페이지를 올바르게 작성하지만 운영 체제가 잘못된 위치에 페이지를 쓰도록 합니다. |
-1018 오류가 발생한 후에 시스템 관리자가 서버에 대한 진단 하드웨어 테스트를 실행하고 이 테스트의 결과가 문제 없음으로 보고되는 경우 관리자는 하드웨어가 초기 분석을 통과했기 때문에 Exchange가 문제의 원인이라고 결론지을 수 있습니다.
그러나 사례별로 Microsoft 또는 하드웨어 공급업체별로 계속 조사하면 데이터베이스 파일을 실제로 손상시킨 하드웨어, 펌웨어 또는 장치 드라이버에서 미묘한 문제가 드러납니다.
일반적인 진단 테스트는 여러 가지 원인으로 발생하는 모든 일시적 오류를 검색하지 못할 수 있습니다. 펌웨어나 드라이버 소프트웨어의 문제는 진단 프로그램의 능력을 벗어날 수 있습니다. 진단 테스트는 시간이 오래 걸리거나 복잡한 로드를 적절히 시뮬레이션하지 못할 수 있습니다. 또한 진단 모니터링이나 디버그 로깅을 추가하면 문제가 다시 나타나는 것을 충분히 예방하도록 시스템을 변경할 수 있습니다.
체크섬을 생성하고 페이지를 데이터베이스 파일에 기록하는 Exchange 메커니즘의 단순성과 안정성은 -1018 오류에 대한 원인이 Exchange 문제일 가능성이 낮은 또 다른 이유입니다. 체크섬과 잘못된 페이지 검색 메커니즘은 간단하고 신뢰성이 있으며 데이터베이스 버전 간에 데이터베이스 페이지 형식 변경을 적용하기 위한 사소한 변경을 제외하고는 첫 번째 Exchange 릴리스 이후로 기본적으로 동일합니다.
추가 설명을 위해 페이지 번호를 포함하여 다른 모든 데이터가 페이지에 기록된 후에 디스크에 기록될 페이지에 대해 체크섬이 생성됩니다. Exchange가 체크섬을 페이지에 추가한 후에 Exchange는 표준의 게시된 Windows API(응용 프로그래밍 인터페이스)를 사용하여 페이지를 디스크에 쓰도록 Microsoft Windows 운영 체제에 지시합니다.
페이지에 대해서는 체크섬이 올바로 생성될 수 있지만 하드 디스크의 잘못된 위치에 페이지가 기록될 수 있으며 이로 인해 "비트 플립"과 같은 일시적 메모리 오류가 발생할 수 있습니다. 예를 들어, Exchange가 새 버전의 페이지 70을 만드는 경우 페이지 자체에서 오류가 발생하지는 않지만 디스크 컨트롤러나 운영 체제에서 사용하는 페이지 번호의 복사본이 임의로 변경됩니다. 이 문제는 70(이진수 100110)이 불안정한 메모리 셀에 의해 6(이진수 000110)으로 변경된 경우에 발생할 수 있습니다. 페이지의 체크섬은 아직 올바르지만 데이터베이스에서의 페이지 위치는 이제 올바르지 않습니다. Exchange는 논리 페이지 번호가 페이지의 실제 위치와 일치하지 않는 것을 발견하면 -1018 오류를 보고합니다. Exchange가 페이지 자체에 잘못된 페이지 번호를 쓰면 Exchange에 의해 또 다른 종류의 페이지 번호 매기기 오류가 발생할 수 있습니다. 그러나 이것은 -1018 오류가 아닌 다른 오류의 원인이 됩니다. Exchange가 페이지 70에 71을 쓰고 페이지에 대한 체크섬이 올바로 수행된 경우 페이지가 위치 71에 쓰여지고 페이지 번호 테스트와 체크섬 테스트를 둘 다 통과합니다.
대개 Exchange 데이터베이스에 보고되는 단일 -1018 오류는 데이터베이스를 중지시키거나 -1018 오류 이외의 현상을 발생시키지 않습니다. 페이지는 자주 액세스하지 않는 폴더(예: 보낸 편지함이나 지운 편지함 폴더)에 있거나 좀처럼 열지 않거나 비어 있는 첨부 파일에 있을 수 있습니다.
단일 -1018 오류로 데이터가 많이 손실될 가능성은 없지만 -1018 오류는 저장 시스템이 한 번 이상 데이터를 신뢰성 있게 저장하거나 검색하지 못한다는 증거가 되기 때문에 -1018 오류는 여전히 고려의 대상입니다. -1018 오류가 다시 발생하지 않을 일시적 문제일 수도 있지만 점차 악화될 문제를 조기 경고하는 것일 가능성이 높습니다. 첫 번째 -1018 오류는 데이터베이스에서 비어 있는 페이지에 있지만 다음에 어느 페이지가 손상될지는 알 수 없습니다. 중요한 전역 테이블이 손상된 경우 데이터베이스를 시작할 수 없으며 데이터베이스 복구가 실패하거나 일부만 성공할 수 있습니다.
-1018 오류가 기록된 후에 오류의 원인을 찾아 제거할 때까지 데이터베이스에 즉시 오류가 발생하거나 이후에 임의의 손상이 발생할 가능성을 염두에 두고 대비해야 합니다.
위로 가기
-1018 오류 복구
Exchange는 -1018 오류가 발생하는 페이지는 완전히 읽을 수 없는 것으로 취급하여 임의의 데이터에 대한 작업이 데이터베이스에서 또 다른 문제를 일으키는 것을 예방합니다.
-1018 오류가 발생하는 페이지는 복구하거나 복원할 수 없습니다. 이 페이지는 데이터베이스에서 삭제해야 합니다. 데이터베이스에서 페이지를 삭제하는 방법은 다음 세 가지가 있습니다.
| • |
온라인 백업에서 데이터베이스를 복원합니다. |
| • |
/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]
Exchange 2000에서 복구 후에 포괄적인 Isinteg 수정을 수행하려면 정보 저장소 서비스를 실행해야 하지만 복구할 데이터베이스는 분리해야 합니다. 데이터베이스 수정을 위해 다음 명령을 실행하십시오.
ISINTEG -S [server_name] -FIX -TEST ALLTESTS
Exchange Server 5.5에서 복구 후에 포괄적인 Isinteg 수정을 수행하려면 정보 저장소 서비스를 중지해야 합니다. 개인 또는 공용 데이터베이스에 대해 복구를 실행하고 있는지 여부에 따라 적절한 스위치(
-PRI 또는
-PUB)를 사용하여 다음 명령을 실행하십시오.
ISINTEG -PRI|PUB -FIX -TEST ALLTESTS
참고 파일 시스템 위치에 관계없이 원시 데이터베이스 파일에 대해 Eseutil과 Esefile을 실행할 수 있습니다. 데이터베이스 파일은 Exchange 서버에 있을 필요가 없습니다. 그러나 Isinteg가 정보 저장소 수준에서 작동하고 정보 저장소 서비스를 사용하여 데이터베이스에 액세스하므로 데이터베이스가 완벽하게 구성된 Exchange 서버에 있는 동안 Isinteg를 실행해야 합니다.
자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
244525 (http://support.microsoft.com/kb/244525/) XADM: Exchange Server가 설치되어 있지 않은 컴퓨터에서 Eseutil을 실행하는 방법
위로 가기
-1019 오류 복구
-1019 오류(JET_errPageNotInitialized)는 사용 중일 것으로 예상되는 페이지가 초기화되지 않았거나 비어 있을 때 보고됩니다. 사용 중인 페이지의 페이지 번호 필드가 0x00000000인 경우 페이지가 체크섬 테스트에 실패할 수는 있지만 -1018 오류 대신 -1019 오류가 보고됩니다.
-1019 오류를 해결하는 방법은 -1018 오류를 해결하는 방법과 동일합니다. 온라인 백업으로는 -1019 문제가 검색되지 않으므로 -1019 문제는 -1018 문제보다 더 오랫동안 감지되지 않을 수 있습니다.
-1018 오류의 원인이 Exchange 외부에 있을 가능성이 크지만 논리 포인터나 페이지 사이의 링크가 잘못되었을 경우 Exchange에 의해 -1019 오류가 발생할 수 있습니다.
그러나 대부분의 경우 -1019 오류는 파일 시스템이 손상되었거나 파일을 포함하고 있지 않은 데이터베이스 파일에 페이지가 매핑된 경우에 발생합니다.
위로 가기
-1022 오류 복구
Exchange가 운영 체제에 데이터베이스에 있는 페이지를 요청하고 페이지 데이터가 반환되는 대신 오류가 발생하는 경우 -1022 오류(JET_errDiskIO)가 발생합니다. -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 유틸리티 출력에서 서비스를 시작할 때 명령줄에서 발생할 수 있습니다.
Eseutil /G 명령을 사용하여 데이터베이스 무결성 확인을 실행할 때 응용 프로그램 이벤트 로그에서 -1018 오류가 보고되지 않을 수 있습니다. 이 상황에서는 잘못된 페이지가 비어 있을 가능성이 있습니다.
대부분의 경우 문제를 보고하는 페이지를 확인할 수 있는 형태로 오류가 보고됩니다. 또한 Esefile을 사용하여 전체 데이터베이스를 검색하여 잘못된 페이지를 확인할 수도 있습니다. Esefile에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
248406 (http://support.microsoft.com/kb/248406/) Exchange Server 5.5 및 Exchange 2000 서버에 대한 Esefile 지원 유틸리티
다음 예제는 각 오류의 세부적인 분석과 함께 Exchange의 다양한 버전에 대한 응용 프로그램 이벤트 로그의 일반적인 -1018 오류 설명입니다.
MSExchangeIS (248) 페이지 체크섬 읽기가 동시에 겹쳐서 -1018
((1:1057816 1:3688618971) (3106-310013) (0-312215)) 오류가 발생했습니다.
이전 백업으로부터 데이터베이스를 복원하십시오.
앞의 예제에서 괄호 안의 숫자를 다음과 같이 해석할 수 있습니다.
| • |
(1:3106 1:3106)은 데이터베이스에서 요청된 페이지(페이지 3106)를 나타내며 실제로 발견된 페이지 번호는 이 페이지(페이지 3106)에 기록됩니다. 1:은 이 데이터베이스가 데이터베이스 1, 즉 Exchange Server 5.5의 Priv.edb임을 나타냅니다. 데이터베이스 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을 사용하여 페이지에 대한 더 많은 논리 정보를 볼 수도 있습니다. Eseutil의 Exchange 2000 버전을 사용하여 Exchange 2000과 Exchange Server 5.5 데이터베이스의 페이지 구조 정보를 볼 수 있습니다.
경고 데이터베이스에 기록하는 어떠한 모드에서도 Exchange Server 5.5 데이터베이스에 대해 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 (http://support.microsoft.com/kb/262196/) XADM: 데이터베이스의 특정 페이지를 소유하고 있는 사서함을 확인하는 방법
Eseutil 출력이 페이지에 대한 리프 페이지를 나열하지 않으면 복구가 완벽하게 작동할 가능성이 높습니다. 대부분의 내부 또는 구조 페이지는 복구 프로세스로 완벽하게 다시 구성할 수 있습니다.
출력은 이것을 "빈 페이지"로 표시할 수도 있습니다. 이 경우에 오프라인 조각 모음은 데이터베이스에서 잘못된 페이지를 삭제합니다.
페이지가 데이터베이스 파일에 속하지 않는 데이터의 블록에 의해 완전히 교체된 경우 Eseutil 출력이 의미가 없을 수 있습니다.
다음 오류는 또 다른 예제입니다.
MSExchangeIS ((247) ) 페이지 체크섬 읽기가 동시에 겹쳐서 -1018
((1:1057816 1:3688618971) (3688618971-3688618971) (0-16815256)) 오류가 발생했습니다.
이전 백업으로부터 데이터베이스를 복원하십시오.
이 예제에서 페이지(3688618971)에서 실제로 읽은 페이지 번호는 요청된 페이지와 일치하지 않습니다. 즉, 페이지 번호가 저장된 페이지 헤더 영역이 손상되었음을 의미입니다. 페이지 번호가 데이터베이스에도 존재하지 않을 가능성이 있습니다. 이런 경우인지 확인하려면 페이지 번호에 4,096을 곱한 다음 데이터베이스 파일의 바이트 크기와 비교하십시오. 이 경우 페이지 번호는 데이터베이스 크기가 15TB(3,688,618,971 x 4,096 = 15,108,583,305,216)가 아닌 경우 Exchange가 원래 기록한 것과 다를 가능성이 있습니다.
또한 첫 번째
dbtime 값이 페이지 번호 패턴을 정확하게 반복시키는지 확인합니다. 3688618971을 16진수(과학 모드에서 Calc.exe 사용)로 변환하면 0xDBDBDBDB가 됩니다. Exchange 2000과 Exchange Server 5.5에서 8바이트
dbtime 값이 4바이트 페이지 번호 값 다음에 바로 저장됩니다. 따라서 두 개의 다른 필드에 대해 최소 12개의 연속적인 바이트가 특정 패턴으로 덮어쓰입니다. Esefile을 사용하여 이 페이지를 직접 보면 전체 페이지가 패턴 0xDB로 덮어쓰이는 것이 검색됩니다. 자주 발견되는 또 다른 잘못된 바이트 패턴은 0xFF입니다. 이것이 위의 오류에 해당하는 경우라면
dbtime 값이 4294967295가 됩니다.
다음 오류는 바이트 오프셋을 페이지 번호가 아닌 파일로 페이지 정보를 제공합니다.
정보 저장소 (2160) - 페이지 체크섬이 일치하지 않아
"d:\exchsrvr\MDBDATA\PRIV.EDB" 파일(오프셋 897024(0x00000000000db000),
4096(0x00001000)바이트)에서 읽은 데이터베이스 페이지를
확인하지 못했습니다. 필요한 체크섬은 2651583211(0x9e0bf2eb)인데
실제 체크섬은 2651582996(0x9e0bf214)입니다. -1018(0xfffffc06) 오류로 인해
읽기 작업을 수행할 수 없습니다. 이 상태가 계속되면
이전 백업으로부터 데이터베이스를 복원하십시오.
세 개의 후행 0을 제거하고 1을 빼고 결과를 10진수로 변환하여 첫 번째 오프셋을 페이지 번호로 변환할 수 있습니다. 이 예제에서 0x00000000000db - 1은 0xda, 즉 십진수 218입니다. Esefile 또는 Eseutil을 사용하여 이 십진수 페이지 번호를 사용할 수 있습니다.
참고 오프셋은 0x1 대신 0x0에서 카운트를 시작하기 때문에 데이터베이스에서 두 헤더 페이지를 고려하도록 2 대신 1만 뺍니다. Esefile 또는 Eseutil을 사용하여 헤더 페이지를 확인하려는 경우 페이지 -1과 페이지 0을 참조하십시오.
Exchange 데이터베이스 헤더는 실제로 단일 페이지만 요구합니다. 두 번째 페이지는 헤더의 "섀도" 복사본입니다.
Esefile /D 페이지 덤프 기능을 사용할 때 보고되는 체크섬은 데이터베이스를 정상적으로 종료한 후에 페이지 -1과 0에 대해 항상 같아야 합니다. 충돌 동안 헤더가 다시 써지는 경우 Exchange는 Exchange를 다시 시작할 때 빈 체크섬을 가진 헤더 복사본을 사용합니다.
이전 예제를 사용하여 계속하면 체크섬은 실제로 두 문자만 다르고 서로 매우 유사합니다. 체크섬이 유사하면 이것은 페이지의 변경 사항이 최소라는 것을 나타냅니다. 아마도 단일 비트 오류일 가능성이 높습니다. 이 페이지에
Eseutil /M /P를 분석할 수 있을 만큼 충분한 논리 구조가 포함되어 있을 가능성이 큽니다.
오류 메시지에서 예상되는 체크섬은 지금 데이터베이스에 있는 페이지에서 실제로 읽은 체크섬입니다. 오류 메시지의 실제 체크섬은 페이지를 읽을 때 Exchange가 동적으로 다시 계산하는 체크섬입니다.
페이지의 실제 체크섬이 0x89abcdef인 경우 페이지에는 모두 0x00 문자가 포함되어 있습니다. 실제 체크섬이 0x76543210인 경우 페이지에는 모두 0xFF 문자가 포함되어 있습니다.
다음 예제는 -1019 오류입니다.
정보 저장소 (3928) - 페이지 데이터가 없어서
"d:\exchsrvr\MDBDATA\PRIV.EDB" 파일(오프셋 1675264(0x0000000000199000),
4096 (0x00001000)바이트)에서 읽은 데이터베이스 페이지를
확인하지 못했습니다. -1019(0xfffffc05) 오류로 인해 읽기 작업을 수행할 수 없습니다.
이 상태가 계속되면 이전 백업으로부터 데이터베이스를
복원하십시오.
일반적인 작업 동안 페이지가 -1019 오류나 -1018 오류를 보고할 경우 -1019 오류가 우선적으로 보고됩니다. -1019 오류는 페이지에 기록된 페이지 번호가 0x00000000인데 Exchange는 페이지가 사용 중일 것으로 예상할 때마다 발생합니다. -1019 오류가 파일 시스템이 0의 블록을 데이터베이스 파일에 매핑하거나 Exchange가 실수로 사용되지 않는 페이지를 "사용 중"으로 참조하기 때문에 발생하는지 여부를 증명하는 것이 어려울 수 있습니다.
페이지가 초기화되지 않았거나 일부 다른 상태에 있는지 여부를 이전 오류와 구분할 수 없습니다. Esefile과 Eseutil을 사용하여 페이지를 추가로 검사해야 합니다. 이 예에서 페이지 번호는 십진수 408(0x199에서 파생)입니다.
Eseutil을 사용하여 페이지를 추가로 검사할 수 있습니다.
pgnoThis 값은 쿼리한 페이지 번호와 일치해야 하며
ulChecksumParity 값은 페이지의 체크섬이 잘못된 경우 추가
** computed checksum 값을 보고합니다. Esefile
/D 스위치를 사용하여 원시 페이지를 보고 초기화되지 않았는지(모두 0x00 문자) 여부를 확인할 수 있습니다.
위로 가기
거짓 -1018 오류
거짓" -1018 오류는 디스크에 있는 페이지가 올바르지만 I/O 시스템이 데이터를 잘못 검색할 때 발생합니다. 이러한 오류는 대개 일시적이며 찾기 어렵습니다. 그러나 "일시적인" -1018 오류는 심각한 신호가 될 수 있습니다. 저장소 시스템의 신뢰성이 손상될 수 있으며 시스템에 추가 문제나 오류가 발생할 위험이 있을 수 있습니다.
시스템에서 일시적인 읽기 오류가 의심되는 경우 Esefile
/D 스위치 또는
Eseutil /M /P를 사용하여 관련된 개별 페이지를 확인하십시오. 유틸리티를 사용하여 전체 데이터베이스를 검색하면 I/O 시스템에 부담을 주어 더욱 나쁜 결과가 발생할 수 있습니다.
Exchange Server 5.5 서비스 팩 2(SP2)에는 일시적인 읽기 오류를 확인하는 데 도움이 되는 기능이 추가되었습니다. Exchange는 읽기 확인 오류 후에 페이지를 16번 다시 읽습니다. 페이지 읽기를 여러 번 시도한 후에 겨우 성공하는 경우는 시스템에 문제가 있어서 디스크에서 안전하게 읽지 못함을 나타냅니다. 16번의 읽기가 모두 실패해도 페이지가 잘못되었음을 최종적으로 증명하지 못합니다. Esefile 또는 Eseutil로 보조 테스트를 수행하십시오.
위로 가기
데이터베이스 제로화
데이터베이스 제로화는 데이터베이스 파일을 직접 검사하여 복구하거나 읽을 수 없도록 Exchange 데이터베이스에서 삭제된 정보를 숨기려는 작업입니다. 데이터베이스 제로화에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
223161 (http://support.microsoft.com/kb/223161/) XADM: ESE 제로화에 대한 정보
데이터베이스 제로화가 사용되는 경우 비어 있거나 부분적으로 비어 있는 페이지의 섹션은 특정 문자 패턴으로 덮어쓸 수 있지만 페이지는 여전히 초기화되지 않은 상태로 돌아가지 않습니다.
