Exchange Server 트랜잭션 로그 파일을 제거하는 방법

Exchange Server/지식 자료 창고

Exchange Server 트랜잭션 로그 파일을 제거하는 방법

엘도라도29 2007. 5. 24. 19:12

요약

Exchange Server 데이터베이스 트랜잭션 로그는 모든 변경 내용을 Exchange Server 데이터베이스에 기록합니다. 이러한 로그 파일이 시간이 지남에 따라 점점 누적되므로 하드 디스크에서 정기적으로 제거하지 않으면 사용 가능한 디스크 공간을 모두 사용하게 됩니다.

Exchange 트랜잭션 로그 파일의 크기는 고정되어 있습니다. Microsoft Exchange Server 2003 및 Exchange Server의 모든 이전 버전의 경우 이 크기는 정확하게 5MB입니다. 트랜잭션 로그가 가득 차면 트랜잭션 로그 이름이 시퀀스 번호를 사용하여 변경되고 새로운 최신 로그가 생성됩니다.

최신 트랜잭션 로그는 Exchange Server에서 가장 최근에 만들어진 로그입니다. Microsoft Exchange Server 5.5에서 최신 트랜잭션 로그 이름은 항상 Edb.log입니다. Microsoft Exchange 2000 Server 및 Exchange Server 2003에서 최신 로그 이름은 저장소 그룹 접두사를 사용합니다. 자세한 내용은 "저장소 그룹” 절을 참조하십시오.

Exchange에서는 다음 방법 중 하나를 사용하여 불필요한 로그 파일을 자동으로 제거합니다.

•

순환 로깅을 사용하는 경우 Exchange Server에서는 데이터베이스 파일에 트랜잭션 로그를 기록한 후 즉시 제거합니다. 이 프로세스로 인해 관련 저장소 그룹의 현재 Exx.log 파일이나 Exchange Server 5.5의 Edb.log 파일이 가득 차고 이름이 변경될 때까지는 일부 유휴 시스템에서 지연이 발생할 수 있습니다. 새 로그 파일 작성 및 자동 삭제 프로세스의 속도를 높이려면 5MB의 첨부 파일이 있는 전자 메일 메시지를 사용자 자신에게 보냅니다.

참고 Exchange Server 5.5에서는 순환 로깅이 기본적으로 사용됩니다. Exchange 2000 Server 또는 Exchange Server 2003에서는 순환 로깅이 기본적으로 사용되지 않습니다.

•

순환 로깅을 사용하지 않을 경우 Exchange Server에서는 저장소 그룹에 있는 모든 데이터베이스의 전체 또는 증분 온라인 백업이 수행된 후에 과다하게 많은 로그를 제거합니다.

Exchange 로깅 메커니즘 작동 방식 및 변경 방법에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.

147524 (http://support.microsoft.com/kb/147524/) XADM: 순환 로깅이 트랜잭션 로그 사용에 미치는 영향

258470 (http://support.microsoft.com/kb/258470/) XADM: 순환 로깅 설정을 수정하는 방법

다음 조건 중 하나에 해당하는 경우 하드 디스크 드라이브 공간이 가득 찰 때까지 트랜잭션 로그 파일의 갯수가 늘어납니다.

•	백업 프로그램이 트랜잭션 로그 파일을 제거하지 않는 경우
•	백업 프로그램의 실행이 중지된 경우
•	트랜잭션 로그 파일이 다른 몇 가지 방법으로 제거되지 않는 경우

하드 디스크 공간이 부족한 경우 트랜잭션 로그 파일을 수동으로 제거해야 할 수 있습니다. 또는 특정 저장소 그룹에 있는 모든 데이터베이스의 전체 또는 증분 온라인 백업을 실행하기 전에 하드 디스크 공간이 부족할 것으로 예상되는 경우 트랜잭션 로그 파일을 수동으로 제거해야 할 수 있습니다. 아직 데이터베이스 파일에 기록되지 않은 데이터가 들어 있는 로그를 제거하면 비정상적인 정지 이후 데이터베이스를 더 이상 탑재하지 못하게 됩니다. 따라서 Exchange Server 트랜잭션 로그 파일을 수동으로 제거하기 전에 제거해도 괜찮은 로그가 무엇인지 확인해야 합니다.

참고 이 문서에서 트랜잭션 로그 파일을 "제거"한다는 것은 사용자 요구 사항에 따라 로그 파일을 백업, 저장 또는 삭제할 수 있는 다른 위치로 트랜잭션 로그 파일을 이동하는 것을 의미합니다. 트랜잭션 로그 파일을 "삭제"한다는 것은 트랜잭션 로그 파일을 백업하거나 복원할 수 없도록 제거하는 것을 의미합니다.

위로 가기

추가 정보

필요하지 않은 트랜잭션 로그 파일을 수동으로 제거

과다하게 많은 트랜잭션 로그 파일을 올바르게 제거하려면 다음 단계를 수행하십시오.

저장소 그룹에 있는 모든 데이터베이스를 중지합니다.

특정 저장소 그룹에 있는 각 데이터베이스 파일의 상태를 확인합니다. 각 데이터베이스 파일의 상태를 확인하는 방법에 대한 자세한 내용은 "데이터베이스 상태" 절을 참조하십시오.

다음 작업 중 하나를 수행합니다.

•

데이터베이스 중 하나 이상이 Dirty Shutdown 또는 Inconsistent 상태에 있는 경우 데이터베이스 일관성에 영향을 주지 않고 제거할 수 있는 트랜잭션 로그 파일이 무엇인지 확인합니다. 자세한 내용은 "로그 파일" 절을 참조하십시오.

•

모든 데이터베이스가 Clean Shutdown 또는 Consistent 상태에 있는 경우 현재 트랜잭션 로그 파일을 제외한 모든 트랜잭션 로그 파일을 제거할 수 있습니다. 모든 데이터베이스가 Clean Shutdown 상태에 있을 때 최신 로그 파일을 제거하면 로그 파일 시퀀스가 다시 설정됩니다. 이렇게 되면 데이터베이스를 시작할 수 없습니다. 그러나 이 경우 로그 파일 시퀀스가 다시 설정되면 이전 백업에서 데이터베이스를 롤 포워드하는 기능에 영향을 줍니다.

제거할 모든 트랜잭션 로그 파일을 트랜잭션 로그 하드 디스크에서 영구적으로 제거하기 전에 다른 위치로 복사합니다. 저장소 그룹에 있는 모든 데이터베이스의 전체 온라인 백업을 완료할 때까지 트랜잭션 로그 파일을 영구적으로 삭제하지 마십시오.

다음 절에서는 트랜잭션 로그 파일과 Exchange Server 데이터베이스 사이의 관계에 대해 설명합니다. 이 절에는 제거해도 괜찮은 로그 파일을 확인하는 방법에 대한 자세한 지침도 나와 있습니다.

위로 가기

데이터베이스 상태

Exchange Server 데이터베이스를 제대로 종료하지 않은 경우 데이터베이스는 트랜잭션 로그 스트림에 "연결된" 상태로 유지됩니다. 즉, 트랜잭션 로그 파일의 일부 데이터가 데이터베이스 파일에 대해 확보되지 않았음을 의미합니다. 다음에 데이터베이스를 시작하는 동안 Exchange Server에서 이 조건을 감지합니다. 그런 다음 Exchange Server에서 누락된 데이터를 데이터베이스 파일에 적용합니다. 이 데이터가 들어 있는 로그 파일을 사용할 수 없는 경우 데이터베이스를 시작할 수 없습니다.

Exchange Server 데이터베이스를 올바르게 종료하면 해당 데이터베이스는 트랜잭션 로그 스트림에서 "분리"됩니다. 이 경우 다음에 데이터베이스를 시작할 때 데이터베이스에서 이전 트랜잭션 로그 파일을 요구하지 않습니다. 그러나 데이터베이스의 백업이나 이전 버전을 복원하려는 경우에는 이러한 로그 파일이 유용할 수 있습니다. 로그 파일은 백업할 때 데이터베이스를 롤 포워드하는 데 사용됩니다. 따라서 데이터베이스의 이전 버전으로 재생할 필요가 없다고 판단할 때까지 트랜잭션 로그 파일을 영구적으로 삭제해서는 안 됩니다.

트랜잭션 로그 파일을 수동으로 제거하기 전에 특정 트랜잭션 로그 파일을 사용하는 모든 데이터베이스의 상태를 확인해야 합니다. 이 경우 특정 트랜잭션 로그 파일을 사용하는 모든 데이터베이스의 상태가 "연결" 또는 "분리" 중 어느 상태인지 확인하십시오. Eseutil 유틸리티의 /MH 명령 스위치를 사용하여 데이터베이스 파일 헤더를 검토하여 데이터베이스가 연결되어 있는지 분리되어 있는지 확인할 수 있습니다. 예를 들어 명령 프롬프트에서 다음 명령을 실행합니다. 여기서 database_name은 검사할 데이터베이스 이름입니다.

eseutil /MH database_name

예를 들어 Mailbox Store (Server1) 데이터베이스를 검사하려면 다음 명령을 입력합니다.

eseutil /MH “Mailbox Store (Server1).edb”

참고 Eseutil 명령을 사용하여 데이터베이스 헤더를 확인하려면 데이터베이스를 중지해야 합니다.

이 명령을 실행한 후에 나타나는 헤더 정보에서 State 값을 확인하십시오. State 값은 데이터베이스가 올바르게 분리되었는지 여부에 대한 다음과 같은 정보를 나타냅니다.

•

데이터베이스가 올바르게 분리된 경우 상태 값은 실행 중인 Exchange Server 버전에 따라 Clean Shutdown 또는 Consistent로 나타납니다.

•

데이터베이스가 제대로 분리되지 않은 경우 상태 값은 Dirty Shutdown 또는 Inconsistent로 나타납니다. 즉, 기존 트랜잭션 로그 파일 중 일부 파일에 데이터베이스에서 요구하는 처리되지 않은 트랜잭션이 포함되어 있습니다. 이 경우 트랜잭션 로그 파일을 제거하면 백업에서 데이터베이스를 복원하지 않거나 Eseutil 명령과 Isinteg 명령을 사용하여 데이터베이스를 복구하지 않을 경우 데이터베이스를 다시 시작할 수 없습니다.

Exchange Server 데이터베이스를 복구하는 방법에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.

812357 (http://support.microsoft.com/kb/812357/) Exchange Server 5.5, Exchange 2000 Server 및 Exchange Server 2003에서 Eseutil /p 도구를 사용하여 복구한 후 Exchange 데이터베이스를 관리하는 방법

트랜잭션 로그 파일이 저장된 하드 디스크가 가득 찰 경우에는 자리 표시자의 역할을 하고 하드 디스크 공간을 예약하는 두 개의 예약 트랜잭션 로그 파일을 사용할 수도 있습니다. 이러한 예약 트랜잭션 로그 파일 이름은 Res1.log와 Res2.log입니다. 트랜잭션 로그 파일이 있는 하드 디스크가 가득 차게 되면 Exchange Server가 이러한 두 개의 예약 트랜잭션 로그 파일을 사용하여 데이터베이스를 정상적으로 중지하는 데 충분할 만큼 로깅을 계속합니다. 로그 디스크가 가득 차 Exchange Server에서 추가 트랜잭션 로그 파일을 만들 수 없는 경우 Res2.log의 이름이 바뀌고 다음 로그로 사용됩니다. 필요할 경우 Res1.log도 사용됩니다.

일부 경우 예약 트랜잭션 로그 파일의 용량이 모두 초과될 수 있습니다. 따라서 저장소 그룹에 있는 모든 데이터베이스가 Dirty Shutdown 또는 Inconsistent 상태로 중지됩니다.

경고 트랜잭션 로그 드라이브에 디스크 공간이 부족할 경우 데이터베이스를 정상적으로 종료하지 못할 수 있습니다. 하나 이상의 데이터베이스가 Dirty Shutdown 또는 Inconsistent 상태에 있고 디스크 공간을 확보하기 위해 모든 트랜잭션 로그 파일을 삭제한 경우 이 파일을 복구하거나 복원하지 않으면 영향을 받는 저장소 그룹의 데이터베이스를 다시 탑재할 수 없습니다. 하나 이상의 데이터베이스에서 계속 필요로 하는 로그 파일은 삭제하지 말아야 합니다.

위로 가기

저장소 그룹

Exchange Server 데이터베이스는 저장소 그룹으로 구성됩니다. 저장소 그룹은 단일 트랜잭션 로그 파일 스트림을 공유하는 데이터베이스 집합입니다. Exchange Server 5.5에는 최대 두 개의 데이터베이스 파일이 포함된 단일 정보 저장소 그룹이 있습니다. 이러한 두 데이터베이스 파일 이름은 각각 Priv.edb와 Pub.edb입니다. 또한 Exchange Server 5.5에는 Dir.edb라고 하는 단일 데이터베이스 파일이 들어 있는 단일 디렉터리 서비스 저장소 그룹이 있습니다.

Exchange 2000 Server 및 Exchange Server 2003에는 디렉터리 서비스 저장소 그룹이 없습니다. Exchange 2000 Server 및 Exchange Server 2003에는 서버당 최대 4개의 정보 저장소 그룹이 있을 수 있습니다. 이러한 각 저장소 그룹에는 최대 5개의 데이터베이스를 포함할 수 있습니다. 이러한 데이터베이스의 이름은 관리자가 구성할 수 있습니다.

트랜잭션 로그 드라이브가 가득 차면 저장소 그룹에 있는 모든 데이터베이스가 즉시 중지됩니다. 저장소 그룹에 있는 데이터베이스를 시작하면 저장소 그룹에 있는 모든 데이터베이스 상태가 검사됩니다. 모든 데이터베이스에 필요한 트랜잭션 로그 파일 재생이 수행된 후 첫 번째 데이터베이스를 시작할 수 있습니다. 트랜잭션 로그 파일 재생 작업과 이벤트는 일반적으로 저장소 그룹의 모든 데이터베이스에 적용되며 개별 데이터베이스에는 적용되지 않습니다.

중요 모든 데이터베이스 파일이 Clean Shutdown 또는 Consistent 상태에 있는지 확인해야 합니다. 같은 저장소 그룹에 있는 다른 데이터베이스가 제대로 분리되지 않은 경우에도 특정 저장소 그룹에 있는 하나 이상의 데이터베이스가 올바르게 분리될 수 있습니다. 검사한 첫 번째 데이터베이스의 상태가 Clean Shutdown인 경우 이 상태를 기준으로 저장소 그룹에 있는 모든 데이터베이스가 Clean Shutdown 상태에 있다고 가정하지 마십시오.

참고 Exchange Server 5.5의 경우 Eseutil 명령을 사용하여 단일 .edb 파일에 포함된 모든 데이터베이스를 검사해야 합니다. Exchange 2000 Server 및 Exchange Server 2003의 경우 모든 데이터베이스가 두 파일로 분리됩니다. 두 파일은 .stm 파일과 .edb 파일입니다. Eseutil 명령을 사용하여 .stm 파일과 .edb 파일 모두의 상태를 검사합니다.

위로 가기

로그 파일

특정 저장소 그룹의 데이터베이스에서 필요로 하는 트랜잭션 로그 파일을 확인하려면 다음 단계를 수행하십시오.

Exchange Server 5.5의 경우

경고 레지스트리 편집기나 다른 방법을 사용하여 레지스트리를 잘못 수정하면 심각한 문제가 발생할 수 있습니다. 문제를 해결하기 위해 운영 체제를 다시 설치해야 할 수도 있습니다. Microsoft는 레지스트리 편집기를 잘못 사용하여 발생한 문제에 대해 해결을 보증하지 않습니다. 레지스트리의 수정에 따른 모든 책임은 사용자에게 있습니다.

1.	Exchange Server 관리자 프로그램에서 데이터베이스의 작업 경로를 확인합니다. 경로 위치는 `Server` 개체의 Database Paths 속성 페이지에 있습니다. 검사점 파일(Edb.chk)은 이 경로에 있습니다. 관리자 프로그램을 사용할 수 없는 경우 시스템 레지스트리에서 작업 경로를 확인할 수 있습니다. 레지스트리 편집기를 실행하여 아래의 레지스트리 하위 키를 확장합니다. 정보 저장소의 경우: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Working Directory 디렉터리의 경우: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDS\Parameters\DSA Working Directory
2.	명령 프롬프트에서 작업 경로 폴더로 이동합니다. Eseutil 명령을 사용하여 Edb.chk 파일의 헤더를 봅니다. eseutil /mk edb.chk 화면 출력이 다음과 유사하게 나타납니다. Microsoft(R) Windows NT(TM) Server Database Utilities Version 5.5 Copyright (C) Microsoft Corporation 1991-1998. All Rights Reserved. Initiating FILE DUMP mode... Checkpoint file: edb.chk LastFullBackupCheckpoint (0,0,0) Checkpoint (157,2860,500) comment: Checkpoint is in log 157 decimal FullBackup (90,8,10) FullBackup time:1/15/1999 18:18:36 IncBackup (0,0,0) IncBackup time:0/0/1900 0:0:0 . . . Checkpoint 줄에 있는 세 개의 숫자는 로그 파일 생성 번호, 로그 파일의 섹터 오프셋 및 섹터의 바이트 오프셋을 나타냅니다. 생성 번호를 적어 둡니다.
3.	생성 번호를 16진수로 변환합니다. 이 예에서 10진수 `157`은 16진수 `9D`로 변환됩니다. Exchange Server 로그 파일의 번호는 5자리 16진수로 지정됩니다. 예를 들어 로그 파일 이름은 `Edb12345.log`가 될 수 있습니다. 로그 번호를 5자리로 만들기 위해 0을 16진수 앞에 추가합니다. 따라서 이전 예제의 검사점 로그 파일은 `Edb0009d.log`입니다. 참고 Windows 계산기의 공학용 모드를 사용하면 10진수에서 16진수로 변환할 수 있습니다. 계산기를 시작합니다. 그런 다음 보기 메뉴에서 공학용을 누릅니다. 10진수를 입력하고 Hex를 누릅니다.
4.	검사점 로그 이후에 생성되는 검사점 로그와 모든 로그는 Inconsistent 상태에 있는 데이터베이스를 시작하는 데 필요합니다. 계산된 검사점 값에 해당하는 로그 파일을 찾지 못할 수도 있습니다. 이는 검사점 이름이 항상 Edb.log인 가장 최신 로그 파일에 있는 경우 발생할 수 있습니다. 이 로그가 가득 차서 새 로그가 생성될 때까지는 현재 로그의 파일 이름에는 로그 시퀀스 번호가 포함되지 않습니다. 다음 Eseutil 명령을 사용하여 로그 파일 헤더를 보면 Edb.log 파일의 실제 내부 시퀀스 번호를 확인할 수 있습니다. eseutil /ML Edb.log 로그 파일 헤더의 lGeneration 필드에는 로그 파일의 실제 시퀀스 번호가 나와 있습니다. lGeneration 값을 16진수로 변환해야 합니다.
5.	번호가 검사점 로그보다 작은 모든 로그는 제거해도 됩니다. 그러나 검사점 로그 자체는 제거하지 마십시오. 이 예제에서는 `Edb0009c.log`, `Edb0009b.log` 등은 제거할 수 있지만 Edb0009d.log 또는 최신 로그는 제거할 수 없습니다. 로그 파일을 삭제하는 것이 아니라 이동해야 한다는 점을 유념하십시오. 검사점보다 오래된 로그 파일을 제거하기 위해 데이터베이스 서비스를 중지할 필요는 없습니다.

백업을 복원해야 하는 경우 데이터베이스를 완전히 롤 포워드하려면 백업 이후에 만들어진 모든 로그 파일도 복원해야 합니다. 로그 시퀀스에 중단점이 있는 경우 중단점 이후로는 롤 포워드할 수 없습니다.

Exchange 2000 Server 및 Exchange Server 2003의 경우

1.	데이터베이스에 대한 .edb 및 .stm 파일의 경로와 파일 이름을 확인하려면 Exchange System Manager를 사용하여 각 데이터베이스 개체에 대한 속성 대화 상자의 데이터베이스 탭을 봅니다.
2.	명령 프롬프트에서 데이터베이스 파일의 경로로 이동합니다.
3.	다음 Eseutil 명령을 실행하여 데이터베이스 파일의 헤더를 봅니다. eseutil /mh `database_file`
4.	데이터베이스 파일 헤더에서 Log Required 필드를 확인합니다. Log Required 필드에는 이 데이터베이스를 시작하는 데 필요한 로그 파일 번호의 범위가 나와 있습니다. 범위가 `0 - 0`인 경우 이 데이터베이스를 시작하는 데 로그 파일이 필요하지 않습니다. 즉, 데이터베이스가 Clean Shutdown 또는 Consistent 상태에 있는 것을 의미합니다. 참고 Eseutil 명령을 사용하여 데이터베이스 헤더를 확인하려면 데이터베이스를 중지해야 합니다. 그러나 Exchange Server의 모든 버전에서 데이터베이스가 실행될 때 검사점 파일의 헤더를 확인할 수 있습니다. 검사점 파일을 확인하는 절차는 Exchange Server의 모든 버전에서 동일하며 "Exchange Server 5.5의 경우" 절에 나와 있습니다. 검사점 값을 보면 데이터베이스를 중지하지 않고 제거할 수 있는 로그 파일을 확인할 수 있습니다. 검사점 로그보다 오래된 로그 파일과 검사점 로그가 포함되지 않은 로그 파일은 제거할 수 있습니다.
5.	Exchange Server 2003 서비스 팩 1(SP1)보다 이전 버전의 Exchange Server를 실행하는 경우 Log Required 필드에 나와 있는 10진수 범위를 16진수 값으로 변환해야 합니다. 예를 들어 Log Required 값이 `28217 – 28221`인 경우 `06E39`에서 `06E3D`까지의 로그 파일은 이 데이터베이스에 필요합니다. Exchange Server 2003 SP1에서는 10진수와 16진수 값을 보고하도록 Log Required 필드가 향상되었습니다. 참고 Windows 계산기의 공학용 모드를 사용하면 10진수에서 16진수로 변환할 수 있습니다. 계산기를 시작하고 보기 메뉴에서 공학을 누릅니다. 10진수를 입력하고 Hex를 누릅니다. 참고 Exchange Server 5.5에서 로그 파일 이름은 `Edbxxxxx.log`입니다. 여기서 "xxxxx"는 5자리 16진수입니다. 각 저장소 그룹마다 특정 로그 파일 집합이 있는 Exchange 2000 Server 및 Exchange Server 2003에서 최대 4개의 저장소 그룹을 가질 수 있기 때문에 트랜잭션 로그 파일 이름에 "Edb" 접두사가 나타나지 않습니다. Exchange 2000 Server 및 Exchange Server 2003에서 "Edb" 접두사는 "E00," "E01," "E02," "E03"으로 대체됩니다. 복구 저장소 그룹의 경우 "Edb" 접두사는 "R00"으로 대체됩니다. 저장소 그룹 로그 파일 이름 접두사는 Exchange System Manager에서 특정 저장소 그룹 개체에 대한 속성 대화의 일반 탭에 나타납니다. 따라서 저장소 그룹 접두사가 "E01"이고 Log Required 항목이 `28217 – 28221` (`0x06E39 – 0x06E3D`)인 경우 필요한 실제 로그는 `E0106E39.log`에서 `E0106E3D.log`입니다. 해당 저장소 그룹에 대한 로그를 제거하기 전에 저장소 그룹에 있는 각 데이터베이스에 대한 Log Required 값을 검사해야 합니다.

저장소 그룹에 있는 데이터베이스에 대한 Log Required 필드에서 가장 작은 항목보다 작은 번호의 모든 로그 파일은 제거해도 됩니다. 로그 파일을 삭제하는 것이 아니라 이동해야 한다는 점을 유념하십시오.

참고 Log Required 필드는 특정 로그의 범위를 보고할 수 있지만 해당 번호의 로그 파일을 찾지 못할 수 있습니다. 예를 들어 Log Required 필드는 28221-28221의 범위를 보고할 수 있지만 번호가 28221인 로그 파일을 찾지 못할 수 있습니다. 이는 검사점이 가장 최근의 로그 파일에 있는 경우 발생할 수 있습니다. 가장 최근의 로그 파일 이름은 항상 저장소 그룹 접두사로만 되어 있습니다. 예를 들어 가장 최근의 로그 파일 이름은 E01.log가 될 수 있습니다. 이 로그가 가득 차서 새 로그가 생성될 때까지는 현재 로그의 파일 이름에는 로그 시퀀스 번호가 포함되지 않습니다.

다음 Eseutil 명령을 사용하여 로그 파일 헤더를 보면 현재 로그 파일의 실제 내부 시퀀스 번호를 확인할 수 있습니다.

eseutil /ML log_prefix.log

예를 들어 로그 접두사가 E01인 경우 eseutil /ML E01.log를 사용합니다. 로그 파일 헤더의 lGeneration 필드에는 로그 파일의 실제 시퀀스 번호가 나와 있습니다.

백업에서 Exchange Server 데이터베이스를 복원해야 하고 데이터를 손실하지 않고 Exchange Server 데이터베이스를 복구하려는 경우 백업을 수행한 후에 생성된 모든 트랜잭션 로그 파일도 복원해야 합니다. 트랜잭션 로그의 시퀀스에 중단점이 있는 경우 이 중단점 이후로 롤 포워드할 수 없습니다. 이 경우 중단점 이후의 더 높은 번호가 지정된 로그는 모두 제거해야 합니다. 여기에는 최신 로그 파일도 포함됩니다.

참고 저장소 그룹에 있는 모든 데이터베이스가 Clean Shutdown 또는 Consistent 상태에 있는 경우에도 최신 로그 파일을 제거해서는 안 됩니다. 최신 로그 파일을 제거하는 경우 시퀀스 번호 0x000001부터 시작하는 로그 파일의 새 집합이 생성됩니다. 새 로그 파일 집합이 생성되면 이전 백업의 Exchange Server 데이터베이스가 롤 포워드되지 않습니다.

Exchange Server 데이터베이스를 복구하는 방법에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.

893083 (http://support.microsoft.com/kb/893083/) Exchange 정보 저장소에 대한 주요 지원 문제