Exchange 2007의 손실된 로그 복원 및 트랜잭션 로그 작업
적용 대상: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
마지막으로 수정된 항목: 2009-01-14
이 항목에서는 LLR(손실된 로그 복원) 및 로그 롤이라는 보조 기능에 대해 설명합니다. 이 두 기능은 Microsoft Exchange Server 2007 RTM(Release to Manufacturing) 버전에서 도입되었으며, Exchange 2007 SP1(서비스 팩 1)에서 해당 동작이 수정되었습니다. 이들 기능은 모든 사서함 서버에서 제공됩니다. 그러나 해당 동작은 사서함 서버 구성과 설치되어 있는 Exchange 2007 버전에 따라 다릅니다.
손실된 로그 복원
Exchange 2007에서 ESE(Extensible Storage Engine)의 내부 구성 요소인 LLR을 사용하면 가장 최근에 생성된 트랜잭션 로그 파일 중 하나 이상이 손실되거나 손상된 경우에도 Exchange 데이터베이스를 복구할 수 있습니다. LLR은 기본적으로 모든 Exchange 2007 사서함 서버에서 사용하도록 설정됩니다. LLR을 사용하면 최근에 생성된 로그 파일을 사용할 수 없는 경우에도 사서함 데이터베이스를 탑재할 수 있습니다. 로그 파일을 사용할 수 없는 경우의 원인 중 하나는 예약되지 않은 중단이라고도 하는 CCR(클러스터 연속 복제) 환경의 손실 장애 조치(failover)입니다. 손실 장애 조치(failover)에 대한 자세한 내용은 예약된 중단 및 예약되지 않은 중단을 참조하십시오. 로그 파일이 누락된 데이터베이스 복구 방법에 대한 자세한 내용은 Eseutil /R 복구 모드를 참조하십시오.
참고
연속 복제 환경에서 LLR은 활성 데이터베이스 복사본에 대해서만 사용하도록 설정됩니다. 수동 데이터베이스는 최대한 항상 최신 상태로 유지되므로 수동 복사본에 대해서는 LLR이 사용되지 않습니다.
Exchange 데이터의 쓰기 작업 순서는 항상 메모리, 로그 파일, 데이터베이스 파일 순입니다. LLR은 지정한 로그 생성 수가 만들어질 때까지 데이터베이스에 대한 쓰기를 지연하는 방식으로 작동합니다. 즉, LLR은 잠시 동안 데이터베이스 파일에 대한 최신 업데이트를 지연합니다. 쓰기가 지연되는 시간은 로그 생성 속도에 따라 달라집니다.
장애 조치(failver)가 수행될 때 손실된 로그의 수가 관리자가 구성한 허용 로그 수보다 적은 경우에는 Microsoft Exchange 정보 저장소 서비스를 통해 수동 데이터베이스 복사본을 자동으로 탑재할 수 있습니다. 관리자는 AutoDatabaseMountDial 매개 변수를 설정하여 장애 조치(failover) 시에 데이터베이스를 탑재할 수 있는 손실이 허용되는 최대 로그 수를 결정합니다. msExchDataLossForAutoDatabaseMount라는 Exchange 특성에 의해 Active Directory 디렉터리 서비스에 표시되는 이 매개 변수는 Lossless, Good Availability 그리고 Best Availability라는 값을 가집니다. Lossless는 0개 로그가, Good Availability는 3개 로그가, 기본값인 Best Availability는 6개 로그가 손실된 것입니다. 이러한 값을 구성하는 방법에 대한 자세한 단계는 클러스터 연속 복제의 장애 조치 및 탑재 설정을 조정하는 방법을 참조하십시오. Good Availability 또는 Best Availability에 대해 시스템을 구성할 때는 공백을 사용하지 마십시오(예: GoodAvailability 및 BestAvailability 사용).
트랜잭션 로그 롤
데이터 손실을 최소화하기 위해 로그 롤이라는 메커니즘이 사용됩니다. 로그 롤은 현재 트랜재션 로그 파일을 주기적으로 닫은 후 다음 생성을 만드는 방식으로 작동합니다. 이 메커니즘은 LLR 및 CCR에서 주로 손실 장애 조치(failover) 이후에 손실된 로그 파일로 인한 데이터 손실을 줄이도록 도와줍니다.
중요
로그 롤 메커니즘은 사용자 또는 기타 데이터베이스 작업이 없는 경우 트랜잭션 로그를 생성하지 않습니다. 실제로 로그 롤은 부분적으로 채워진 로그가 있을 때만 발생하도록 설계되었습니다.
로그를 롤포워드하면 현재(Exx.log) 로그 파일이 꽉 차지 않은 경우에도 로그 파일을 닫은 후 새 트랜잭션 로그 파일을 생성합니다. 트랜잭션 로깅에 대한 자세한 내용은 트랜잭션 로깅 이해를 참조하십시오.
로그 롤 동작은 LLR 깊이 값을 기준으로 합니다. Exchange 2007 RTM을 실행 중인 CCR 환경에서 LLR 깊이는 AutoDatabaseMountDial 매개 변수 값을 통해 지정된 손실이 허용되는 로그 수에 1을 더한 숫자 값입니다. 예를 들어, AutoDatabaseMountDial 매개 변수의 값이 6(시스템이 Best Availability용으로 구성되어 있음)이면 LLR 깊이의 값은 7입니다.
Exchange 2007 SP1을 실행 중인 CCR 환경에서 LLR 깊이는 AutoDatabaseMountDial 매개 변수의 값에 관계없이 10으로 하드 코드됩니다.
Exchange 2007 RTM과 SP1 둘 다에서 LCR 및 단일 복사본 클러스터를 포함하거나 포함하지 않는 독립 실행형 사서함 서버 등 CCR 환경에 없는 모든 사서함 서버에 대해 LLR 깊이는 1로 하드 코드됩니다.
시스템이 계산된 시간 동안 유휴 상태이면 로그 롤이 발생합니다. 시스템은 로그 롤이 발생하는 시간을 계산하는 데 다음 수식을 사용합니다.
[15(분) ÷ LLR 깊이 값] = 로그 롤 작업 빈도(분)
그러면 하루의 분 수인 1,440을 로그 롤 작업 빈도로 나누면 저장소 그룹당 로그 롤 작업의 결과로 매일 생성되는 최대 로그 파일 수를 결정할 수 있습니다.
예를 들어, Exchange 2007 SP1을 실행 중인 CCR 환경의 LLR 깊이는 10이므로 로그 롤 작업은 1.5분마다 수행되며, 저장소 그룹당 로그 롤 작업의 결과로 매일 생성되는 최대 로그 파일 수는 960개입니다.
로그 롤 크기
저장소 그룹에서 로그 롤 크기가 상당히 커질 수 있으려면 다음 조건을 만족해야 합니다.
저장소 그룹에 사서함 데이터베이스가 있어야 합니다.
저장소 그룹에 트랜잭션 로그를 만드는 사용자 작업이 거의 없어야 합니다.
저장소 그룹에 프로세스나 응용 프로그램에 의해 자주 로그온되는 하나 이상의 사서함이 있어야 합니다.
유휴 저장소 그룹에 대해 매일 생성되는 최대 로그 파일 수는 사서함 서버의 구성에 따라 다릅니다. 각 사서함 서버 구성에 대한 유휴 저장소 그룹당 최대 로그 파일 수는 다음 표에 나와 있습니다.
각 Exchange 2007 RTM 사서함 서버 구성에 대한 유휴 저장소 그룹당 최대 로그 파일 수
| 사서함 서버 구성 | 유휴 저장소 그룹에 의해 하루에 생성되는 트랜잭션 로그 파일의 최대 수 |
|---|---|
|
96 |
Good Availability의 CCR |
384 |
Best Availability의 CCR |
672 |
각 Exchange 2007 SP1 사서함 서버 구성에 대한 유휴 저장소 그룹당 최대 로그 파일 수
| 사서함 서버 구성 | 유휴 저장소 그룹에 의해 하루에 생성되는 트랜잭션 로그 파일의 최대 수 |
|---|---|
|
96 |
무손실, Good Availability 및 Best Availability을 위한 CCR |
960 |
사서함 서버는 일반적으로 사용자 작업, 온라인 유지 관리 및 기타 요소 때문에 앞의 표에 나오는 값보다 더 많은 트랜잭션 로그를 만듭니다.