Exchange Server 데이터베이스 아키텍처 및 데이터베이스 엔진 개요

기술 자료 번역 기술 자료 번역
기술 자료: 271987 - 이 문서가 적용되는 제품 보기.
모두 확대 | 모두 축소

이 페이지에서

요약

이 문서에서는 Microsoft Exchange Server 데이터베이스 아키텍처 및 데이터베이스 엔진은 일반적인 개요를 제공합니다. 토론 데이터베이스 구성 요소에 대한 정보, 데이터베이스 일관성 유지 관리, 가능한 유형의 데이터베이스 실패 및 데이터베이스 유틸리티를 포함합니다.

추가 정보

Exchange Server 내결함성, 트랜잭션 기반 데이터베이스를 사용하여 데이터베이스에 적용되기 전에 메시지 및 디렉터리 정보를 저장합니다. Exchange Server 5.5 스탠더드 위해, 각 데이터베이스에 최대 16 GB (기가바이트) 로 증가할 수 있습니다. Exchange Server 5.5 Enterprise Edition에 대해 크기는 하드웨어에 의해서만 제한됩니다.

정전 또는 기타 비정상적인 시스템 오류가 발생하면 Exchange Server 트랜잭션 로그 파일이 서버에 의해 이미 수락된 있지만 아직 데이터베이스에 쓴 데이터를 재구축하는 데 사용합니다.

데이터베이스 구성 요소

Exchange Server의 디자인 표준 데이터베이스 기술은 기반으로 합니다. 시스템 메모리 Exchange 서버에 대한 out 디스크의 구조를 레이아웃하는 관리하고 있는 포함된 데이터베이스 엔진이 의존합니다. 또한 데이터베이스 엔진 기술에 다른 Windows 응용 프로그램에서 예를 들어, Windows 인터넷 이름 서비스(WINS) 및 동적 호스트 구성 프로토콜(DHCP) 내부적으로 사용됩니다.

정보 저장소

키 구성 요소가 Exchange Server 에서 데이터베이스 관리 정보 저장소가 별도의 두 데이터베이스를 실제로 것입니다. 개인 정보 저장소 데이터베이스를 Priv.edb, 사용자 사서함 데이터를 관리합니다. 공용 정보 저장소를 Pub.edb, 공용 폴더 에서 데이터를 관리합니다.

정보 저장소에 있는 MAPI (메시징 응용 프로그래밍 인터페이스 () 과 데이터베이스 엔진이 서버의 하드 디스크에 기록된 모든 사용자 작업을 하기 위해 실행됩니다. 예를 들어, 사용자가 Microsoft Outlook에서 메시지를 저장하면 MAPI 다음 변경 내용을 디스크에 씁니다 데이터베이스 엔진이 호출하는 정보 저장소를 먼저 호출합니다.

JET 데이터베이스 엔진

Exchange Server 데이터베이스의 추적하고 정보를 유지 관리하는 데 사용하는 로그 파일을 JET 형식으로 기반으로 합니다. Microsoft JET는 속도와 성능을 트랜잭션 기반 처리 기능을 향상시키기 위해 다른 고급 기능과 함께 결합하여 고급 32비트 멀티스레드 데이터베이스 엔진입니다.

데이터베이스 엔진이 데이터 위치 및 메모리 부족 4 KB (KB) 페이지 스와핑을 디스크를 메모리에 캐시합니다. 메모리에 있는 페이지를 업데이트하고 새로운 또는 업데이트된 페이지를 다시 디스크에 씁니다. 때 요청, 데이터베이스 엔진이 버퍼 데이터를 지속적으로 디스크로 이동하는 대신 메모리에 오는 때문에 이 시스템을 보다 효율적으로 수행할 수 있습니다.

Exchange Server 5.5 이전 버전에서 버퍼 캐시 크기가 고정되어 있습니다. 더 많은 메모리가 필요한 경우 관리자가 버퍼 크기를 수동으로 변경해야 합니다.

Exchange Server 5.5에서 동적 버퍼 할당 버퍼 캐시를 증가 또는 사용 가능한 메모리 양에 따라 및 리소스를 Microsoft Windows NT Server 컴퓨터에서 실행 중인 다른 서비스가 사용 중인 축소할 수 있습니다. 메모리 다른 서비스를 사용하는 경우 Exchange Server 데이터베이스 엔진의 필요한 대로 많은 메모리를 사용합니다. 다른 서비스에 메모리가 필요한 경우 데이터베이스 엔진은 하드 디스크에 페이지 전송 및 버퍼 크기를 축소하는 일부 메모리를 제공합니다.

사용자가 요청하면 데이터베이스 엔진은 해당 요청을 메모리로 로드합니다 및 "더티" 페이지로 표시합니다 ("더티" 페이지를 데이터로 작성된 메모리에서 여전히 감금되어 있습니다 페이지가 있음). 나중에 이러한 커밋되지 않은 페이지는 정보 저장소 데이터베이스는 디스크에 기록됩니다.

데이터베이스 일관성 유지

메모리 캐싱 가장 효율적으로 데이터를 처리할 수 있지만 디스크의 정보는 절대로 최신 상태로 완벽하게 한 효과입니다. 커밋되지 않은 페이지를 메모리에 일반적으로 Exchange Server를 실행하는 경우에도 일관성이 없는 것으로 플래그가 수 데이터베이스를 인해. 데이터베이스가 실제로 있는 모든 커밋되지 않은 페이지를 성공적으로 있는 경우에만 일관된 상태로 디스크에 오류가 발생하는 종료 중에 전송된.

메모리의 내용이 손실된 경우에는 어떻게? 예를 들어, 디스크 및 사용자가 데이터를 쓰기 전에 서버의 경우에는 어떻게 충돌 일관성 없는 데이터베이스와 남아 있는? Exchange는 트랜잭션 로그 파일이 이 상황에서 복구하는 데 사용합니다.

트랜잭션 로그 파일

트랜잭션 로그 파일을 안전하게 복사본을 메모리에 일시적 데이터 보관합니다. 시스템이 손상된 경우, 데이터베이스가 손상되지 가정할 때 로그 파일을 데이터 충돌이 전에 마지막으로 커밋된 트랜잭션 복구할 수 있습니다. (로그를 데이터베이스가 손상될 수 가능한 디스크 오류에 의해 영향을 받지 않도록 로그 파일 전용 하드 디스크에 저장하는 것이 좋습니다 참고.)

Exchange "트랜잭션 기반" 메시징 시스템 및 정보 저장소는 트랜잭션 데이터베이스입니다. 트랜잭션 삽입, 삭제 및 업데이트, 시스템 네 가지 ACID"고정 용어에 다음과 같습니다 (예: 데이터베이스의 변경 내용 집합을 다음과 같습니다.
  • 원자: 양쪽 모든 작업이 발생할 또는 그 중 발생할 수 있습니다.
  • 일관된: 데이터베이스가 올바른 한 상태에서 다른 형식으로 변환됩니다.
  • 격리된: 커밋할 때까지 변경 표시되지 않습니다.
  • 영속적인: 시스템 충돌하더라도 규정된 트랜잭션은 데이터베이스에 유지됩니다.
이러한 고정 용어에 다음 경우에만 이를 데이터 손상 또는 기타 오류 영속적 또는 영구, 보호되어 있는지 보장할 수 때 데이터베이스 엔진은 트랜잭션을 커밋합니다 의미합니다. 경우에만 해당 데이터를 메모리에서 하드 디스크에 트랜잭션 로그 파일에 전송된 경우 데이터베이스 엔진은 데이터를 커밋합니다.

예를 들어, 받은 편지함 폴더에서 중요 폴더로 메시지를 이동하려면 Exchange 서버 세 가지 작업을 수행합니다.
  1. 받은 편지함 폴더에서 메시지를 삭제합니다.
  2. 중요 폴더로 메시지를 삽입합니다.
  3. 항목 및 읽지 않은 항목 수를 반영하도록 각 폴더에 대한 정보를 업데이트합니다.
이러한 작업은 한 트랜잭션에서가 수행됩니다. 작업 순서는 중요하지 않습니다. 안전하게 중요 폴더로 메시지가 삽입될 때 삭제가 커밋된 있기 때문에 Exchange Server 편지함 폴더에서 메시지를 안전하게 삭제할 수 있습니다. 시스템이 손상된 경우, Exchange Server 절대로 메시지를 이동하는 동안 잃어 두 개의 메시지 복사본이 절대로 끝나는.

논리적으로 메모리에서 디스크에 로그 파일 및 데이터베이스를 이동하는 것과 데이터의 생각할 수 있지만 실제로 수행되는 데이터를 데이터베이스에 메모리에서 디스크에 이동하도록 있습니다. 로그 파일이 고속 쓰기 위한 최적화된 정상적인 작동 중에 데이터베이스 엔진이 실제로 로그 파일을 읽고 있습니다. 경우에만 정보 저장소 서비스가 비정상적으로 중지하거나 충돌 및 데이터베이스 엔진이 로그 파일을 재생하여 복구해야 할 경우 로그 파일에서 읽습니다.

검사점 파일

데이터베이스 엔진이 모든 로그 파일 시퀀스 Edb.chk 아직 디스크의 데이터베이스 파일에 기록되지 않은 데이터를 추적하기 위해 검사점 파일이 유지 관리합니다. 포인터가 로그에서 오류가 대비하여 복구 시작 파일을 정보 저장소가 하는 위치를 나타내는 로그 시퀀스 검사점 파일입니다. 검사점 파일에 대한 효율적인 복구 필수적입니다. 서버가 없으면 정보 저장소 것입니다 디스크에 있는 가장 오래된 로그 파일의 시작 부분에서 시작하고 특히 원하는 모든 데이터베이스가 일관되도록 경우 이를 이미 데이터베이스--시간이 오래 걸릴 작성된 가지고 있는지 여부를 확인하려면 모든 로그 파일의 모든 페이지를 확인합니다.

검사점 파일은 시스템 디스크에 있습니다. 시스템 디스크를 복구해야 할 경우 이 파일이 아마도 없습니다 또는 잘못된 버전을. 그러나 대부분의 경우 검사점 파일을 자체적으로 수행합니다.

기본 로깅

다음 단계를 수행하여 "일반 로깅 데이터가 트랜잭션 로그 파일에 쓰여진" 프로세스를 보여 줍니다.
  1. 사용자에게 메시지를 보냅니다.
  2. MAPI는 메시지를 보내는 사용자에게 알려 주는 정보 저장소를 호출합니다.
  3. 정보 저장소 데이터베이스 엔진은 트랜잭션을 시작하고 데이터를 해당 내용을 변경합니다.
  4. 데이터베이스 엔진이 새 페이지를 메모리에 dirtying 메모리에 있는 트랜잭션을 기록합니다.
  5. 동시에, 데이터베이스 엔진이 트랜잭션 로그 파일의 트랜잭션이 보안하는, 로그 레코드를 만듭니다. 데이터베이스 엔진이 트랜잭션 로그 파일의 끝에 도달하면 이를 합해져서 시퀀스에서 새 로그 파일을 만듭니다.
  6. 데이터베이스 엔진이 커밋되지 않은 페이지가 하드 디스크의 데이터베이스 파일에 씁니다.
  7. 검사점 파일은 업데이트됩니다.
순환 로깅

Exchange Server 관리자는 데이터 복구에 대한 서버 디스크 공간에 대한 관심이 더욱 있던 때 한 번에 구현된 순환 로깅 기능을 지원합니다.

순환 로깅 거의 검사점 파일이 전송되는 정보를 추적하기 위한 필수 점을 제외하고는, 동일한 방식으로 일반 로깅 작동 디스크에. 다음 로그 파일 검사점 파일 이동합니다 같이 순환 로깅 중에 이전 파일은 다시. 이런 경우 백업 미디어 함께 에서 디스크의 로그 파일을 가장 최근의 커밋된 트랜잭션을 복원할 수 없습니다.

기본적으로, 순환 로깅은 Exchange Server 5.5 로그 파일에 대해 고정된 크기를 유지하고 작성하면 않도록 설정되어 있습니다. 로그 파일 크기가 5 MB 제한에 도달하면 데이터베이스 엔진은 해당 삭제되고 새 로그 파일 시퀀스에서 만듭니다. 따라서 Exchange Server 충돌이 발생하면 데이터베이스가 일관되도록 하드 디스크에 충분한 데이터를 유지합니다.

Exchange Server 컴퓨터에서 순환 로깅을 활성화하는 것이 좋습니다. 순환 로깅은 디스크 공간이 필요성 있습니다 있지만 오류 발생 전에 마지막으로 커밋된 트랜잭션 개까지 복구 기능을 없애 줍니다. 로그 파일을 재생할 수 없습니다. 그리고 데이터를 마지막 전체 백업 경우에만 복구할 수 있습니다. 한 로그 파일을 덮어쓸 경우 다른 99% 로그 데이터를 복구할 방법이 없습니다.

사실 순환 로깅이 트랜잭션 기반 시스템의 장점은 부정합니다. 순환 로깅을 설정한 상태에서 남겨 두고 데이터가 필요 없는 경우 또는 다른 데이터 복구 방법을 있으면 좋습니다. 로그 파일 디스크 리소스를 소비하는 것에 대한 관심이 있는 경우 이를 정기적으로 온라인 백업을 수행하여 정리하는 데 더 좋습니다. 더 이상 필요하지 않을 때 백업 트랜잭션 로그 파일을 자동으로 제거합니다.

데이터 보호

논리 데이터베이스 파일이 가장 중요한 측면은 데이터 복구 있는지 고려해야 할 것 같습니다. 그러나 데이터베이스 파일에 없는 정보를 포함하므로 Exchange Server 트랜잭션 로그 파일을 더 중요합니다. (합니다 및 안정적인 서버에서 찾은 전용, 고성능 디스크에 배치하는 즉 느린 디스크의 데이터베이스 파일을 저장하는 경우에도 이유입니다.)

트랜잭션 로그 파일을 디스크에 오류가 발생한 시스템을 복구할 수 있도록 메모리에 있는 휘발성 데이터의 보안 복사본을 보관합니다. 시스템이 손상된 로그 파일이 있을 때 데이터베이스가 손상되지 경우 마지막으로 커밋된 트랜잭션 실패 전에 데이터를 복구할 수 있습니다.

또한 트랜잭션 로그 파일을 빠르게 순차적으로 페이지를 데이터베이스에 삽입하는 데 비해 로그 파일에서 페이지를 업데이트할 수 있기 때문에 보다 효율적으로 데이터를 쓰는 합니다. 데이터베이스에서 변경될 때 데이터베이스 엔진은 데이터를 메모리에 업데이트합니다. 이를 동기적으로 트랜잭션 레코드를 시스템 오류가 발생하면 트랜잭션이 다시 실행 방법을 알려 주는 로그 파일에 씁니다. 다음 데이터베이스 엔진이 데이터베이스에 데이터를 디스크에 씁니다. 디스크 입/출력 최소화하기 위해 데이터베이스 엔진이 일괄적으로 디스크로 페이지를 전송합니다.

각 로그 파일 시퀀스의 최대 5 MB의 데이터가 포함될 수 있습니다. 로그 파일이 꽉 찼을 때 이전 로그 파일로 이름이 바뀌고 새 Edb.log 파일 이름으로 만들어집니다. Exchange Server 16진수 세대 번호를 가진 각 로그 파일에 연결합니다. 따라서 로그 파일을 동일한 이름, 데이터베이스 엔진 스탬프 머리글 각 파일에 고유한 서명 사용하여 시퀀스에서 가질 수 있으므로 로그 파일의 다른 세대 간에 구별할 수 있습니다.

데이터베이스 손상

Exchange는 시스템 일관성 있는 상태로 다시 가져오는 데 필요한 하드웨어 오류와 같은 오류가 발생할 수 있습니다. 다른 유형의 서로 다른 현상이 함께 데이터베이스 손상 때문에 다른 도구 및 기술을 진단하고 문제를 해결하는 데 필요합니다.

두 가지 유형의 손상 다음과 같습니다.
  • 물리적 손상
    가장 낮은 수준에서 데이터는 디스크에 물리적으로 손상될 수 있습니다. 일반적으로 항상 백업에서 복원하는 데 필요한 하드웨어 관련 문제가 있습니다.
  • 논리 손상
    일반적인 논리적 손상은 데이터베이스 수준에서 발생합니다. 예를 들어, 인덱스 항목이 누락된 값을 가리킬 수 데이터베이스 엔진 오류로 인해 발생할 수 있습니다. 사서함, 메시지, 폴더 및 첨부 파일이 있는 응용 프로그램 수준에서 논리적 손상이 발생할 수도 있습니다. 예를 들어, 응용 프로그램 수준 손상은 있습니다 잘못된 참조 개수, 잘못된 액세스 제어 수준, 메시지 본문 없이 메시지 머리글을 발생할 등을.

물리적 손상

실제 데이터를 파괴할 수 있고 백업에서 Exchange를 복원해야 할 수 있는 유일한 작업은 있기 때문에 심각한 손상입니다. 물리적 손상 초기에 검색하고 문제를 신속하게 해결하는 것이 중요합니다.

물리적 손상 검색

물리적 손상 정보 저장소에 있는 이벤트 뷰어의 응용 프로그램 로그에 다음 오류가 발생하는 경우를 보여 줍니다.
  • -1018 (JET_errReadVerifyFailure) 디스크를 읽을 데이터가 쓰여진 데이터 같은 아닌 디스크에.
  • -1022 (JET_errDiskIO) 하드웨어, 장치 드라이버 또는 운영 체제 오류를 반환합니다.
  • -510 JET_errLogWriteFail 디스크 공간이 부족하여 로그 파일 또는 하드웨어 오류 로그 파일 디스크가 있는 것입니다.
물리적 손상 때 Exchange 일반적으로 -1018 또는 -1022 오류 메시지를 표시하지만 데이터 백업 Microsoft의 좋습니다 온라인 백업을 수행하여 또한 물리적 손상을 감지할 수 있습니다. 온라인 백업이 가장 좋은 방법은 모든 데이터베이스에서 단일 페이지에 체계적으로 검사하여 유일한 프로세스 때문에 손상 데이터베이스 파일에서 검색할 수도 있습니다.

온라인 백업을 실행할 때 Windows NT 백업 소프트웨어 데이터베이스 파일에 있는 각 4 KB 페이지, 데이터베이스 엔진에 전달합니다 읽고 테이프에 씁니다. 데이터베이스 엔진이 각 페이지의 체크섬 올바른지 확인합니다. 페이지 체크섬 데이터베이스 엔진이 계산하는 체크섬이 일치하지 않는 경우 하드 디스크 및 NT 백업 로그를 실제 데이터베이스 손상을 -1018 오류.

물리적 손상 방지

물리적 손상을 방지하는 가장 좋은 방법은 품질 하드웨어 구성 요소 사용하여 서버를 준비하는 및 시스템이 올바르게 구성하는 것입니다. Exchange Server를 실행하는 컴퓨터에서 데이터베이스 및 로그 파일에 대해 바이러스 백신 소프트웨어 같은 파일 수준의 유틸리티를 실행하지 않는 것을 확인하십시오.

신뢰할 수 있는 하드웨어가 있는 경우 결코 물리적 손상 나타내는 항목을 볼 수 있습니다. -1018 오류가 일관되게 실행하지 아마도 하드웨어 문제, 가능하면 불량 디스크 또는 디스크 컨트롤러에 합니다.

나중 쓰기 캐싱을 대한 단어: 데이터를 실제로 보안이 전에 일부 나중 쓰기 캐싱 배열 컨트롤러를 잘못 성공적인 커밋 트랜잭션에 대한 반환 디스크에. 가장 안전한 방법은 백업 설정하는 프로세스를 배터리 있지 않으면 write-back 캐싱을 해제하는 것입니다. 사용자가 사용하는 경우 나중 쓰기 캐싱, 데이터가 완전하게 보호되는 하며 캐시된 데이터 충돌이 발생한 후 오른쪽 디스크로 재생된 차지 않도록 하는 절차가 있어야 하여 손상된 데이터베이스를 열지 마십시오.

물리적 손상 복구

물리적 데이터베이스 손상에서 복구할 수 있는 유일한 방법은 마지막 올바른 백업에서 복원하는 것입니다 (백업이 오류 없이 실행한 경우 좋은 있습니다) 및 로그 파일을 앞으로 롤백할 시스템 일관성 있고 손상되지 않은 상태로 전환합니다. 반복되는 오류 아마도 데이터베이스가 위치한 디스크 문제가 있음을 나타냅니다.

실제로 안전한 데이터베이스에 물리적 손상을 복구하는 방법이 있습니다. 해당 Eseutil.exe 실행할 수 Eseutil 단순히 잘못된 페이지를 삭제하기 때문에 복구 모드로 다시 작동하는 데이터베이스를 가져올 수 있지만 이 유틸리티에서 권장되지 않습니다.

참고: 모든 가능한 경우, 복구 모드에서 Eseutil 사용하지 않도록 합니다 (Eseutil/p를). Exchange Server와 함께 제공되는 Eseutil 다른 모든 데이터베이스 손상을 복구하기 위한 최후의 것입니다. 복구 모드에서 손상된 페이지를 삭제하여 다시 실행 끊어진된 데이터베이스를 가져옵니다. 데이터를 복구하려면 Eseutil 절대로 사용해야 합니다. Eseutil/p 를 명령을 실행하면 또한 오프라인 조각 모음 (Eseutil/d) 실행해야 및 다음 데이터베이스가 일관된 상태로 복원하려면 Isinteg - 테스트 alltests - 수정 명령을 실행해야 합니다.

논리 손상

논리 손상을 논리적 손상이 예측할 수 없는 소프트웨어 버그로 인해 일반적으로 때문에 보다 물리적 손상 진단하고 훨씬 더 어렵습니다. 일반적으로 논리 손상을 경고하도록 문제가 필요합니다. (논리적 손상입니다 거의 Exchange Server 5.5.)

논리 손상 방지

논리 손상을 따라서 예측할 수 있으므로 이를 방지하기 위해 간단하지 방법이 없습니다. 그러나 가지가 위험을 줄일 수 있습니다.
  • Microsoft Exchange 최신 서비스 팩을 설치하는 Server 버전 5.5 최대한 빨리. 서비스 팩은 Exchange Server 5.5에서 여러를 가지 알려진된 문제 수정합니다.

    서비스 팩 및 이를 구하는 방법에 대한 자세한 내용은 Microsoft 기술 자료 문서를 보려면 해당 자료의 문서를 참조하십시오.
    241740Exchange Server 5.5 서비스 팩 3에서 수정된 버그 목록
    254682XADM: Exchange Server 5.5 SP3 데이터베이스 엔진 수정 프로그램
    191014최신 Exchange Server 5.5 서비스 팩을 구하는 방법
  • Exchange Server 컴퓨터를 안전하며 구성이 변경되지 확인하십시오.
문제를 발견하고 이러한 조치를 수행한 후에도 문제가 지속되는 경우 새 버그를 찾을 가질 수 있습니다. 이 경우 Microsoft을 가능한 한 빨리 알려 줍니다.
논리 손상 복구

논리적 손상은 정보 저장소 데이터베이스 엔진이 발생할 수 있습니다. 논리적 손상은 데이터에 심각한 손상이 발생할 수 있으므로 오류 보고서를 무시하십시오.

Isinteg 사용할 수 유틸리티 정보 저장소 또는 데이터베이스 엔진이 문제가 확인하려면 Eseutil 유틸리티의 문제가 확인하십시오. 참고 백업에서 시스템을 복원하는 시도한 후에 이러한 유틸리티를 마지막 수단으로만 사용해야 합니다.

Isinteg 유틸리티

(Isinteg) 정보 저장소 무결성 검사기 찾아 공용 및 개인 정보 저장소 데이터베이스의 오류를 없애 줍니다. 이러한 오류는 정보 저장소가 시작되지 않을 수도 있고 로그온 및 수신, 열기 또는 전자 메일 삭제 방지 있습니다.

Isinteg 일반 정보 저장소 유지 관리의 일부로 사용할 수 없습니다, 재해 복구 상황에서 지원하기 위해 제공됩니다. 예를 들어, 시스템 손상 후 동기화되어 가져올 경우 정보 저장소 카운터 메모리에 해결하려면 Isinteg을 실행할 수 있습니다.

논리 스키마 수준에서 Isinteg 유틸리티를 사용할 수 있기 때문에 Eseutil 유틸리티의 복구할 수 없는 데이터를 복구할 수 있습니다. 논리 스키마 수준에서 Eseutil 유틸리티의 실제 스키마 수준에서 유효한 데이터를 구문적으로 잘못된 수 있기 때문입니다. 복구 진행 상황을 추적할 수 있도록 Isinteg 이벤트 뷰어의 응용 프로그램 로그에 정보를 기록합니다.

Isinteg 유틸리티를 두 가지 주요 작업을 수행합니다.
  • 오프라인 백업 복원 후 정보 저장소를 패치합니다.
  • 테스트한 다음 필요에 따라 정보 저장소 오류를 수정합니다.
정보 저장소 및 Isinteg 유틸리티를 문제 해결에 대한 추가 정보는 아래 문서 번호를 눌러 Microsoft 기술 자료에 있는 문서를 클릭하십시오.
182081XADM: ISINTEG와 유틸리티에 대한 설명

또는 Exchange Server 5.5 컴팩트 디스크 Support\Utils 디렉터리 Isinteg.rtf 문서를 참조하십시오.

Eseutil 유틸리티

Eseutil 유틸리티를 데이터베이스 테이블 및 레코드의 구조 및 조각 모음을 수행한다, 복구 및 정보 저장소와 디렉터리 무결성을 검사하는 예제입니다. 복구 모드에서 Eseutil 실행 단순히 손상된 페이지를 삭제하기 때문에 경우에만 백업에서 복원하는 시도한 후에 이 유틸리티를 사용하십시오.

Eseutil 유틸리티에 대한 자세한 내용은 아래 문서 번호를 눌러 Microsoft 기술 자료에 있는 문서를 클릭하십시오.
192185XADM: ESEUTIL 유틸리티 (Eseutil.exe) 조각 모음 방법
또는 Exchange 5.5 Support\Utils 디렉터리의 디스크 압축 Eseutil.rtf 문서를 참조하십시오.

데이터 백업

Exchange Server 트랜잭션 기반 때문에 디스크에 데이터베이스 파일의 파일 수준 또는 오프라인 백업을 수행하지 마십시오. 아직 않은 트랜잭션을 포함하여 시스템에 있는 모든 데이터 유지 하기 위해 가장 좋은 방법은 디스크로 플러시되지, 정기적으로 온라인 백업을 수행하는 것입니다.

온라인 백업

온라인 백업 서버를 종료하지 않고 Exchange Server 데이터베이스를 백업 미디어에 백업하는 수 있습니다. Exchange Server는 온라인 백업을 수행할 때 정보 저장소를 포함하여 모든 서비스를 계속 정상적으로 실행됩니다. 페이지를 계속 메모리에서 업데이트되고 디스크의 데이터베이스 파일을 전송할 수, 트랜잭션이 로그 파일에 기록됩니다 및 검사점 파일을 계속 이동합니다.

Exchange 백업 소프트웨어가 백업 중에 수정된 페이지를 또한 백업되는지 확인하십시오 실행되는 동안 업데이트된 페이지를 추적합니다 (패치) .pat 파일을 사용합니다. Priv.pat에 대한 개인 정보 저장소 및 공용 정보 저장소에 대해 Pub.pat 두 .pat 파일이 있습니다.

정기적으로 온라인 백업을 수행하면 백업이 성공적으로 완료 하려면 이벤트 뷰어의 응용 프로그램 로그를 확인하십시오.

온라인 백업 프로세스

백업 프로그램, Windows NT 예를 들어 백업 (Ntbackup.exe), 전체 백업 또는 복사본 백업 중에 다음을 수행합니다.
  1. 데이터베이스 복사본 및 최대 테이프 백업합니다.
  2. 하위 페이지 테이프에 복사된 후 변경할 페이지를 .pat 파일에 추가합니다.
  3. 현재 Edb.log 파일을 x 로그 파일 생성 번호 16진수 형식으로 되어 및 새 로그 생성을 만든 Edb x .log으로 이름을 바꿉니다.
  4. .pat 파일 및 모든 로그 파일을 백업하려면 전체 백업을 새 Edb.log) 제외하고 검사점 테이프 끌어온 후 백업합니다. 복사본 백업은 검사점이 전후에 모든 로그 파일을 백업합니다.
  5. 전체 백업을 검사점 보다 오래된 트랜잭션 로그 파일을 삭제합니다. 복사본 백업은 트랜잭션 로그 파일을 삭제하지 않습니다.
백업 프로그램을 증분 백업이나 차등 백업을 수행하는 동안 다음을 작업을 수행합니다.
  1. 복사본 로그 파일 및 최대 테이프 백업합니다에 대한 증분 백업, 사용하면에서. 차등 백업 테이프에 데이터베이스를 복사합니다.
  2. 하위 페이지 테이프에 복사된 후 변경할 페이지를 .pat 파일에 추가합니다.
  3. Edb x .log 현재 Edb.log 파일의 이름을 바꾸고 새 로그 생성이 만듭니다.
  4. .pat 파일 및 모든 로그 파일을 테이프에 새 Edb.log 포함하여 검사점 전후에 백업.
  5. 증분 백업을 검사점 보다 오래된 트랜잭션 로그 파일을 삭제합니다. 차등 백업은 로그 파일을 삭제하지 않습니다.

오프라인 백업

오프라인 백업을 수행하지 않는 것이 좋습니다. 온라인 백업이 백업 프로그램 파일, 관리하는 있지만 오프라인 백업을 휴먼 오류가 발생하기 수동, labor-intensive 프로세스가 있습니다. 또한 오프라인 백업은 데이터베이스의 각 페이지의 체크섬을 확인할 수 없습니다. 온라인 백업을 손상 검색 및 데이터 복구 수행 단일 가장 유용한 도구가 있습니다.

백업에 대한 자세한 내용은 Microsoft 기술 자료 문서를 보려면 해당 자료의 문서를 참조하십시오.
191357XADM: 단일 데이터베이스에서 전체 온라인 백업 복원
179308XADM: Exchange 온라인 백업 확인 방법

속성

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

피드백 보내기

 

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