트랜잭션 로깅 이해

  • 아티클

 

적용 대상: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

마지막으로 수정된 항목: 2007-08-30

이 항목에서는 순환 로깅에 대한 간략한 설명을 포함하여 Microsoft Exchange Server 2007의 트랜잭션 로깅에 대해 자세히 설명합니다.

Exchange Server 트랜잭션 로깅은 Exchange 데이터베이스가 갑자기 중지된 경우에 해당 데이터베이스를 일관성 있는 상태로 안정적으로 복원하도록 디자인된 ESE(Extensible Storage Engine)의 강력한 복구 메커니즘입니다. 온라인 백업을 복원하는 경우 로깅 메커니즘도 사용됩니다.

Exchange 트랜잭션 로깅

Exchange 데이터베이스 파일을 변경하기 전에 Exchange에서는 트랜잭션 로그 파일에 변경 내용을 기록합니다. 변경 내용이 안전하게 기록된 후에는 데이터베이스 파일에 기록될 수 있습니다. 일반적으로 이러한 변경 내용은 트랜잭션 로그에 안전하게 기록된 후 데이터베이스 파일에 기록되기 전에 최종 사용자가 사용할 수 있습니다.

Exchange에서는 수십 GB의 데이터베이스 페이지 캐싱을 효율적으로 관리할 수 있고 고성능으로 설계된 정교한 내부 메모리 관리 시스템을 사용합니다. 따라서 정상적인 작동 중에 데이터베이스 파일에 변경 내용을 실제로 쓰는 작업은 우선 순위가 낮습니다.

데이터베이스가 갑자기 중지되는 경우 메모리 캐시가 손상되었다는 이유만으로 캐시된 변경 내용이 손실되지는 않습니다. 데이터베이스가 다시 시작되면 Exchange에서는 로그 파일을 검색한 다음 데이터베이스 파일에 아직 기록되지 않은 변경 내용을 재구성하고 적용합니다. 이 프로세스를 로그 파일 재생이라고 합니다. 데이터베이스는 Exchange에서 로그 파일의 작업이 데이터베이스에 이미 적용되었는지, 데이터베이스에 적용되어야 하는지 또는 데이터베이스에 속하지 않는지 확인할 수 있도록 구성됩니다.

Exchange는 하나의 큰 파일에 모든 로그 정보를 쓰지 않고 각 파일 크기가 정확히 1MB 또는 1,024KB인 일련의 로그 파일을 사용합니다. 한 로그 파일이 꽉 차면 Exchange에서는 해당 파일을 닫고 순번을 붙여 이름을 바꿉니다. 채워진 첫 번째 로그 이름은 Enn00000001.log로 끝납니다. nn은 기본 이름 또는 로그 접두사인 2자리 숫자를 나타냅니다.

각 저장소 그룹에 대한 로그 파일은 숫자가 매겨진 접두사(예: E00, E01, E02 또는 E03)가 붙은 이름으로 구분됩니다. 저장소 그룹에 대해 현재 열려 있는 로그 파일의 이름은 단순히 Enn.log입니다. 파일이 채워진 다음 닫히기 전까지는 순번이 매겨지지 않습니다.

검사점 파일(Enn.chk)은 Exchange에서 로그된 정보가 데이터베이스 파일에 어느 정도 기록되었는지 추적합니다. 각 로그 스트림에 대해 하나의 검사점 파일과 각 저장소 그룹에 대해 별도의 로그 스트림이 있습니다. 단일 저장소 그룹 내에서 모든 데이터베이스는 단일 로그 스트림을 공유합니다. 따라서 단일 로그 파일에는 대개 여러 데이터베이스에 대한 작업이 포함됩니다.

로그 파일은 16진수로 순번이 매겨집니다. 즉, E0000000009.log 다음의 로그 파일은 E0000000010.log가 아니라 E000000000A.log입니다. 공학용 모드로 설정된 Windows 계산기(Calc.exe) 응용 프로그램을 사용하여 로그 파일 순번을 10진수로 변환할 수 있습니다. 이렇게 하려면 Calc.exe를 실행한 다음 보기 메뉴에서 공학용을 클릭합니다.

특정 로그 파일의 10진수로된 순번을 보려면 Exchange Server 데이터베이스 유틸리티(Eseutil.exe) 도구를 사용하여 해당 헤더를 검토할 수 있습니다. 각 로그 파일의 처음 4KB 페이지에는 로그 파일과 해당 로그 파일이 속하는 데이터베이스를 설명하고 식별하는 헤더 정보가 있습니다. Eseutil /ml [로그 파일 이름] 명령을 실행하면 헤더 정보가 표시됩니다. Eseutil에 대한 자세한 내용은 Eseutil을 참조하십시오.

헤더를 표시할 때 잘못된 스위치를 사용하면(예: 데이터베이스 헤더에 /mh 대신 /ml 사용) 오류가 표시되거나 올바르지 않은 헤더 정보가 표시됩니다.

데이터베이스가 탑재되는 동안에는 해당 데이터베이스의 헤더를 볼 수 없습니다. 또한 저장소 그룹의 데이터베이스가 탑재되는 동안 현재 로그 파일(Enn.log)의 헤더를 볼 수 없습니다. Exchange에서는 하나의 데이터베이스에서라도 사용하고 있는 경우 현재 로그 파일을 열어 둡니다. 그러나 데이터베이스가 탑재되는 동안 검사점 파일 헤더를 볼 수 있습니다. Exchange에서는 30초 간격으로 검사점 파일을 업데이트합니다. 업데이트가 진행 중인 경우를 제외하고 해당 헤더를 볼 수 있습니다.

Exchange 파일 헤더를 이해하는 것이 Exchange 관리자에게 유용합니다. 파일 헤더를 이해하면 함께 속해 있는 데이터베이스 및 로그 파일과 성공적인 복구에 필요한 파일을 확인할 수 있습니다.

다음 로그 파일 헤더 예제에서 처음 네 개의 행을 확인하십시오.

Base name: e00
Log file: e00.log
lGeneration: 11 (0xB)
Checkpoint: (0xB,7DC,6F)

로그 파일 헤더에 대한 이러한 행은 로그 파일 이름에 순번이 없으므로 해당 파일이 현재 로그 파일임을 보여줍니다. lGeneration 행은 로그 파일이 채워진 후 닫힐 때 해당 로그 파일의 순번이 10진수 11에 해당하는 B가 된다는 것을 보여줍니다. 기본 이름은 e00이므로 최종 로그 파일 이름은 E000000000B.log가 됩니다.

앞의 헤더 예제에 나온 Checkpoint 값은 실제로 로그 파일 헤더에서 읽히지 않지만 마치 읽히는 것처럼 표시됩니다. Eseutil.exe는 Enn.chk에서 직접 Checkpoint 값을 읽으므로 검사점 파일의 위치를 알기 위해 별도의 명령을 입력할 필요가 없습나디. 검사점 파일이 손상되면 Checkpoint 값은 NOT AVAILABLE을 읽습니다. 이 경우 검사점은 현재 로그 파일(0xB)에 있으며 숫자 7DC 및 6F는 로그 파일에서의 검사점 위치를 나타냅니다. 실제로는 이 정보가 거의 필요하지 않습니다.

검사점 파일이 손상되어도 Exchange에서는 로그 파일을 복구하고 재생할 수 있습니다. 그러나 이를 위해 Exchange는 검사점 로그에서가 아니라 사용 가능한 가장 오래된 파일에서 로그 파일 검색을 시작합니다. Exchange에서는 데이터베이스에 이미 적용된 데이터는 건너뛰고, 적용되어야 하는 데이터가 발생할 때까지 로그를 사용하여 순차적으로 작업을 수행합니다.

일반적으로 Exchange에서 데이터베이스에 이미 적용된 로그 파일을 검색하는 데는 1~2초 정도만 걸립니다. 데이터베이스에 기록해야 하는 로그 파일의 작업이 있는 경우 해당 작업을 적용하는 데 10초에서 몇 분 정도 걸릴 수 있습니다. 평균적으로 30초 이내에 로그 파일의 내용을 데이터베이스에 쓸 수 있습니다.

Exchange 데이터베이스가 정상적으로 종료되면 처리되지 않은 데이터는 모두 데이터베이스 파일에 기록됩니다. 정상적인 종료 후 데이터베이스 파일 집합은 일관성 있는 상태에 있다고 간주되므로 Exchange에서는 해당 데이터베이스 파일 집합을 로그 스트림에서 분리합니다. 이는 데이터베이스 파일이 자체 포함된 상태 즉, 전적으로 최신 상태임을 의미합니다. 트랜잭션 로그는 데이터베이스 파일을 시작하는 데 필요하지 않습니다.

Eseutil /mh 명령을 실행하고 파일 헤더를 검토하여 데이터베이스가 완전히 종료되었는지 확인할 수 있습니다.

저장소 그룹의 모든 데이터베이스가 연결이 끊어지고 완전한 종료 상태가 되면 데이터베이스에 영향을 주지 않고 모든 로그 파일을 안전하게 삭제할 수 있습니다. 그런 다음 모든 로그 파일을 삭제하면 Exchange에서 Enn00000001.log로 시작하는 새 로그 시퀀스를 생성합니다. 데이터베이스 파일을 기존 로그 파일이 있는 다른 서버나 저장소 그룹으로 이동할 수 있으며 데이터베이스는 자동으로 다른 로그 스트림에 연결됩니다.

참고

저장소 그룹의 모든 데이터베이스가 종료된 후에 로그 파일을 삭제할 수 있지만 이렇게 하면 이전 백업의 복원 및 롤포워드에 영향을 줄 수 있습니다. 현재 데이터베이스에는 더 이상 기존 로그 파일이 필요하지 않지만 이전 데이터베이스를 복원해야 할 경우에는 기존 로그 파일이 필요할 수도 있습니다.

데이터베이스가 부적절한 종료 상태일 때 데이터베이스를 다시 탑재하려면 검사점 앞에서부터 기존의 모든 트랜잭션 로그가 있어야 합니다. 이러한 로그를 사용할 수 없으면 Eseutil /p 명령으로 데이터베이스를 복구하여 일관성 있고 시작할 수 있는 상태로 만들어야 합니다.

경고

데이터베이스를 복구해야 할 경우 일부 데이터가 손실됩니다. 일반적으로 최소한의 데이터 손실이 발생하지만 문제가 될 수도 있습니다. 데이터베이스에서 Eseutil /p를 실행한 후에 다음과 같은 두 가지 작업을 수행하여 데이터베이스를 완전히 복구해야 합니다. 먼저 Eseutil/d를 실행하여 데이터베이스를 조각 모음합니다. 이 작업은 모든 데이터베이스 인덱스 및 공간 트리를 삭제한 후 다시 작성합니다. 두 번째는 –fix 모드로 Information Store Integrity Checker(Isinteg.exe) 도구를 실행하는 작업입니다. 이 도구는 데이터베이스를 검색하여 처리되지 않은 트랜잭션 로그의 삭제로 인한 논리적 불일치가 있는지 확인합니다. 예를 들어, 데이터베이스에 서로 최신 상태가 아닌 참조가 있을 수 있습니다. Isinteg.exe를 실행하면 가능한 한 최소한의 데이터 손실로 이러한 문제를 해결하려고 시도합니다.

트랜잭션 로깅은 예기치 않은 데이터베이스 중지가 발생한 경우 Exchange에서 안전하게 복구할 수 있도록 하는 것 외에도 온라인 백업을 만들고 복원하는 데 반드시 필요합니다. 온라인 백업을 만들고 복원하는 방법에 대한 자세한 내용은 데이터베이스 백업 및 복원을 참조하십시오.

순환 로깅

권장되지는 사항은 않지만 순환 로깅을 사용하도록 설정하여 디스크 공간을 절약하도록 Exchange를 구성할 수 있습니다. 순환 로깅을 사용하면 Exchange는 해당 로그 파일 내의 데이터가 데이터베이스로 커밋된 후에 트랜잭션 로그 파일을 덮어씁니다. 그러나 순환 로깅을 사용하면 마지막 전체 백업을 수행할 때까지만 데이터를 복구할 수 있습니다.

Exchange 2007이 사용하는 표준 트랜잭션 로깅에서 저장소 그룹에 있는 각 데이터베이스 트랜잭션은 로그 파일에 기록된 다음 데이터베이스에 기록됩니다. 로그 파일이 1MB에 도달하면 이름이 바뀌고 새 로그 파일이 생성됩니다. 시간이 경과하면서 이러한 결과는 로그 파일 집합이 됩니다. Exchange가 예기치 않게 중지되면 이러한 로그 파일의 데이터를 데이터베이스로 다시 재생하여 트랜잭션을 복구할 수 있습니다. 순환 로깅은 첫 번째 로그 파일에 포함된 데이터가 데이터베이스에 기록된 후 그 로그 파일을 덮어쓰고 다시 사용합니다.

Exchange 2007에서 순환 로깅은 기본적으로 사용되지 않습니다. 순환 로깅을 사용하여 드라이브 저장 공간 크기를 줄입니다. 그러나 완전한 트랜잭션 로그 파일 집합이 없으면 마지막 전체 백업보다 최신 버전으로 데이터를 복구할 수 없습니다. 따라서 정상적인 작업 환경에서는 순환 로깅이 권장되지 않습니다.

Exchange 2007에서 순환 로깅을 사용하거나 사용하지 않도록 설정하는 방법에 대한 자세한 내용은 저장소 그룹에 대해 순환 로깅 사용 여부를 설정하는 방법을 참조하십시오.

연속 복제 및 순환 로깅

순환 로깅과 연속 복제를 조합할 수 있습니다. 이 구성에서는 이 항목의 앞에서 설명한 ESE 순환 로깅과는 다른 CRCL(연속 복제 순환 로깅)이라는 새로운 유형의 순환 로깅을 사용할 수 있습니다. ESE 순환 로깅은 Microsoft Exchange Information Store 서비스에 의해 수행되고 관리되지만 CRCL은 Microsoft Exchange Replication Service에 의해 수행되고 관리됩니다.

ESE 순환 로깅을 사용하도록 설정하면 추가 로그 파일을 생성하지 않고 필요한 경우 현재 로그 파일을 덮어씁니다. 그러나 연속 복제 환경에서는 로그 전달 및 재생을 위해 로그 파일이 필요합니다. 따라서 CRCL을 사용하도록 설정하면 현재 로그 파일이 덮어쓰여지지 않으며 로그 전달 및 재생 프로세스를 위한 닫힌 로그 파일이 생성됩니다. 특히 Microsoft Exchange Replication Service는 로그 연속성이 유지 관리되고 로그가 복제에 필요한 경우 로그 삭제기가 로그를 삭제하지 않도록 CRCL을 관리합니다. 따라서 CRCL을 사용하도록 설정해도 복제에 부정적인 영향은 없습니다.

Exchange 2007의 RTM(Release To Manufacturing) 버전에서는 순환 로깅과 CCR(클러스터 연속 복제) 또는 LCR(로컬 연속 복제)을 결합할 수 있습니다. 그러나 이렇게 하면 백업이 복원된 후에 롤포워드 복구가 허용되지 않으므로 권장되지 않습니다. Exchange 2007 SP1(서비스 팩 1)에서도 CCR, LCR 또는 SCR(대기 연속 복제) 환경의 저장소 그룹에 순환 로깅을 사용할 수 있습니다. 그러나 앞서 설명한 이유 때문에 이 방법 또한 권장되지 않습니다. 이러한 환경 중 하나에서 순환 로깅을 사용하면 JET(Joint Engine Technology) 순환 로깅이라고도 하는 ESE 순환 로깅이 아닌 CRCL이 적용됩니다. CCR, LCR 또는 SCR 환경에서는 항상 다음 프로세스를 사용하여 순환 로깅을 사용하거나 사용하지 않도록 설정해야 합니다.

  1. Suspend-StorageGroupCopy cmdlet를 사용하여 연속 복제를 일시 중단합니다.

  2. 순환 로깅을 사용하거나 사용하지 않도록 설정합니다. 순환 로깅을 사용하거나 사용하지 않도록 설정하는 방법에 대한 자세한 내용은 저장소 그룹에 대해 순환 로깅 사용 여부를 설정하는 방법을 참조하십시오.

  3. 순환 로깅이 사용되거나 사용되지 않는 저장소 그룹의 데이터베이스를 분리한 후 탑재합니다.

  4. Resume-StorageGroupCopy cmdlet를 사용하여 연속 복제를 다시 시작합니다.

LCR 환경의 저장소 그룹의 경우 Enable-StorageGroupCopy cmdlet를 실행하여 저장소 그룹에 대해 LCR을 켜기 전에 데이터베이스를 저장소 그룹에서 분리한 후 탑재하여 Microsoft Exchange Information Store 서비스가 현재의 순환 로깅 설정을 감지하고 활용할 수 있도록 해야 합니다. Microsoft Exchange Information Store 서비스는 구성 변경을 감지하고 활용하기 위해 데이터베이스를 분리한 후 탑재해야 하지만 Microsoft Exchange Replication Service는 다시 시작 작업 없이도 구성 변경을 동적으로 감지 및 활용할 수 있습니다. 따라서 앞의 절차를 수행하지 않으면 Microsoft Exchange Replication Service와 Microsoft Exchange Information Store 서비스가 데이터베이스의 순환 로깅 설정 상태(꺼짐 또는 켜짐)를 서로 반대로 인식하는 상황이 발생할 수 있습니다. 이로 인해 로그 파일이 중간에 잘릴 수 있습니다.

참고

LCR이나 SCR을 사용하지 않도록 설정하면 백업 또는 순환 로깅을 통해 로그 파일을 복사하지 않고 삭제할 수 있지만 CCR의 경우는 사용하지 않도록 설정하는 옵션이 없습니다. CRCL의 사용 여부에 관계없이 CCR의 경우는 복제되지 않은 로그는 삭제되지 않습니다.

관리자는 만들어진 트랜잭션 로그 양을 적절히 유지하기 위해 사서함 이동이 많은 상황에서 순환 로깅을 사용하도록 설정할 수 있습니다. 사서함 이동에는 두 개의 다른 데이터베이스가 사용되므로 사서함 이동 중에 두 데이터베이스에 대해 순환 로깅을 사용하도록 설정할 수 있습니다.

참고

순환 로깅은 오류 발생 시 저장소 그룹을 최신 상태로 유지할 수 없도록 하므로 장기간 동안 순환 로깅을 사용하는 것은 권장되지 않습니다.

사서함 이동이 필요하거나 로그 파일 크기 증가를 가져오는 기타 시나리오에서는 CCR, LCR 및 SCR 환경에서 CRCL을 사용하도록 설정할 수 있습니다. 그러나 CRCL이 사용하도록 설정된 경우 백업을 수행할 수 없습니다. 따라서 다음에 유의해야 합니다.

  • CRCL을 켜면 백업을 수행할 수 없으므로 사서함 이동이 백업 작업을 방해하지는 않습니다.

  • CRCL은 백업이 계속될 수 있도록 사서함 이동이 완료된 후에 사용할 수 없게 설정됩니다.