Partager via

용량 계획 - 데이터베이스를 정상/탑재 상태로 유지하는 데 필수적인 역할을 하는 트랜잭션 로그 공간

  • Article

최초 문서 게시일: 2011년 11월 9일 수요일

얼마 전에 지원 가능성 프로그램 관리자인 Nino Bilic과 채팅을 하는 중에 꽤 놀라운 이야기를 들었습니다. Nino의 설명에 따르면, Exchange 2010을 사용하는 Microsoft의 주요 고객들에게 심각한 문제가 발생하는 가장 큰 이유는 트랜잭션 로그 LUN의 디스크 공간이 부족하여 사서함 데이터베이스가 분리되기 때문이라고 하더군요. 

잠시 그 설명에 대해 곰곰이 생각해 보았는데, 솔직히 충격을 받았습니다. 개인적으로는 사서함 요구 사항 계산기를 활용하고 TechNet의 지침을 참조하면 그런 문제는 발생하지 않을 것이라고 믿고 있었거든요. Nino는 저에게 이 정보를 알려 주면서 트랜잭션 로그 용량 계획이라는 주제에 대해 블로그 게시물을 작성할 것을 권했습니다(고마워요 Nino!).

용량 계획 101

트랜잭션 로그 LUN의 크기를 적절하게 지정하려면 작업 중인 환경에 대해 다음과 같은 몇 가지 사항을 파악해야 합니다.

  1. 데이터베이스에 포함할 사서함의 수
  2. 데이터베이스에 포함된 사서함의 메시지 프로필
  3. 평균 메시지 크기
  4. 평균 사서함 크기
  5. 매일 이동하는 사서함 수
  6. 백업 및 복원 솔루션
  7. 솔루션에서 네트워크 오류 등의 기타 오류 시나리오를 고려해야 하는지 여부

이 게시물에서는 각 데이터베이스에 사서함 250개가 포함된다고 가정하겠습니다. 각 사서함에서는 매일 150개의 메시지를 보내고 받으며, 평균 메시지 크기는 100KB입니다. 사서함 데이터베이스 및 로그 용량 요소 이해의 표를 참고하면, 평균 메시지 크기가 75KB인 150개의 메시지 프로필에서는 매일(24시간) 트랜잭션 로그가 30개 생성됩니다. 이 게시물에서 사용하는 예에서는 메시지 크기가 75KB보다 크므로 사서함 생성당 트랜잭션 로그 수를 계산할 때 해당 크기를 고려해야 합니다. 대략적인 지침은 다음과 같습니다.

평균 메시지 크기가 두 배(150KB)가 되면 사서함당 생성되는 로그 수는 1.9배 증가합니다. 이 값은 첨부 파일 및 메시지 테이블(메시지 본문과 첨부 파일)을 포함하는 데이터베이스의 비율을 나타냅니다.

따라서 다음 수식을 사용하면 평균 메시지 크기가 100KB인 사서함에 대한 로그 수 증가를 확인할 수 있습니다.

150/1.9 = [프로필의 평균 메시지 크기] / x

x = (100*1.9)/150

x = 1.266666666666667~1.27

보시다시피 기준보다 메시지 크기가 25KB 커지면 매일 사서함당 생성되는 트랜잭션 로그의 수는 1.27배 증가합니다. 따라서 사서함당 매일 생성되는 트랜잭션 로그 수는 트랜잭션 로그 30개*1.27 = 39개가 됩니다. 즉, 사서함이 250개인 데이터베이스의 경우 각 데이터베이스의 사서함에서 매일 생성되는 트랜잭션 로그의 수는 39*250 = 9,750개입니다.

사서함을 이동할 때도 트랜잭션 로그가 생성됩니다. 대상 데이터베이스로 각 사서함을 이동하면 사서함 크기(휴지통 폴더의 콘텐츠 포함)와 거의 같은 충분한 수의 로그가 원본이 아닌 대상 데이터베이스에 생성됩니다. 예를 들어 매일 사서함 중 1%를 이동하는 경우 사서함 2.5개가 데이터베이스로 이동되는 것입니다. 각 사서함의 평균 크기가 5.4GB이면(단일 항목 복구를 사용하도록 설정한 경우 삭제된 항목 보존 기간인 14일 동안의 콘텐츠 포함) 데이터베이스당 매일 사서함 이동 트랜잭션 로그의 수는 2.5*5.4GB/1024 = 13,888개입니다.

백업/복원의 경우에는 사용 중인 백업 아키텍처의 유형을 고려해야 합니다. 각 백업 시나리오에서는 사서함 생성 트랜잭션 로그의 용량을 고려하여 프로비전해야 하는 권장 추가 기간(일)에 해당하는 공간이 있습니다. 추가 공간을 프로비전하면 여러 오류가 발생해도 데이터베이스의 작동이 중단되지 않습니다. 트랜잭션 로그 자르기에 대한 자세한 내용은 백업, 복원 및 재해 복구 이해를 참조하십시오.

  트랜잭션 로그 자르기 권장 백업 오류 방지 기간
일별 전체 백업 매일 3일
주별 전체 백업/일별 증분 매일 3일
주별 전체 백업/일별 차등 매주 7일
격월 전체 백업/일별 증분 매일 3일
Exchange 기본 데이터 보호 로그가 더 이상 필요하지 않은 시점 3일

물론 다른 시나리오도 고려해야 할 수 있습니다. 예를 들어 두 데이터 센터 간에 확대된 DAG(데이터베이스 사용 가능 그룹)를 배포하는 경우에는 두 데이터 센터 간의 네트워크 링크가 작동하고 데이터베이스 복사본이 정상 상태일 때만 로그 자르기가 수행됩니다. WAN 링크의 작동이 중단되어 복구하는 데 5일이 걸리는 경우에는 해당 기간을 고려하여 백업 오류 방지 기능을 조정해야 합니다.

이 게시물에서 사용하는 시나리오에서는 자르기 오류 이벤트 기간 3일 동안 데이터베이스가 정상적으로 작동하도록 하면 됩니다. 즉, 사서함 생성 트랜잭션 로그용으로 9,750/1024*3 = 28.5GB의 디스크 공간이 필요합니다.

또한 해당 주에 계속 수행되는 사서함 이동 이벤트에 필요한 디스크 공간도 고려해야 합니다. 사서함 이동 작업을 위한 디스크 공간은 13,888/1014*7일 = 94.9GB입니다.

이러한 수치들을 종합할 때 각 데이터베이스에서 트랜잭션 로그에 필요한 디스크 공간은 123GB입니다. 또한 예기치 않은 현상이 발생할 경우에 대비하기 위한 데이터 오버헤드 요인도 포함해야 하므로, 트랜잭션 로그용으로 필요한 최종 디스크 공간은 123GB*1.2 = 148GB입니다.

트랜잭션 로그에 대해 전용 LUN을 배포하는 경우에는 150GB LUN을 프로비전해서는 안 됩니다. 백업 오류가 발생하고 사서함을 빈번하게 이동하는 경우에는 디스크 공간이 모두 사용될 수 있기 때문입니다. 일반적으로는 디스크 용량의 80%만 사용하도록 각 LUN을 프로비전해야 합니다. 해당 공식은 다음과 같습니다.

LUN 공간 = [예상 디스크 공간 사용률] / (1-[원하는 사용 가능한 공간 비율])

LUN 공간 = 148GB/(1-0.2) = 148GB/0.8 = 전용 트랜잭션 로그 볼륨에 대한 185GB LUN 공간

데이터베이스와 동일한 LUN에 트랜잭션 로그를 배포하는 경우에는 트랜잭션 로그 디스크 공간 요구 사항과 데이터베이스 디스크 공간 요구 사항을 더하면 [예상 디스크 공간 사용률] 값을 구할 수 있습니다.

트랜잭션 로그 디스크 공간을 모두 사용하지 않도록 방지하는 방법

가장 먼저 작업 환경의 기준을 파악하여 일반적인 일별 로그 생성 속도를 확인해야 합니다. 또한 모니터링을 설정하고 생성되는 경고에 대해 조치를 취해야 합니다. 모니터링을 통해 다음과 같은 시나리오를 모니터링해야 합니다.

  1. 트랜잭션 로그 LUN 디스크 공간. 여러 임계값과 각각 다른 경고 메커니즘을 설정하십시오. 예를 들어 디스크의 90%를 사용했다는 경고가 첫 번째로 표시되도록 해서는 안 됩니다. 일반적인 로그 생성 기준을 알고 있으면 디스크 공간 사용률이 20%를 초과하는 경우 보고하는 등의 임계값을 설정할 수 있습니다.
  2. Exchange 기본 데이터 보호를 사용하는 경우가 아니라면 정상적인 백업 완료를 모니터링합니다. 디스크 공간을 모두 사용했을 때 백업 오류가 처음으로 확인되도록 해서는 안 됩니다.
  3. 응용 프로그램 로그에서 자르기 이벤트를 모니터링합니다.
  4. 데이터베이스 복사본 복제 상태를 모니터링합니다. 

트랜잭션 로그가 갑자기 증가하는 경우

제 동료인 Mike Lagase가 이러한 시나리오의 문제를 해결하는 방법에 대한 유용한 정보를 제공하는 문서(https://blogs.technet.com/b/mikelag/archive/2009/07/12/troubleshooting-store-log-database-growth-issues.aspx(영문일 수 있음))를 작성했습니다. 이 문서는 Exchange 2007을 중심으로 작성되었으므로 몇 가지 도구 및/또는 권장 사항은 Exchange 2010에는 더 이상 적용되지 않을 수도 있습니다. 이 문서에서 Mike가 설명하는 단계 외에도, Exchange 2010에서 다음 방법을 통해 예기치 않은 트랜잭션 로그 증가 현상을 확인할 수 있습니다. 이 문서를 작성하는 데 도움을 준 Todd Luttinen에게 감사의 인사를 전합니다.

  1. 저장소 사용량 통계 cmdlet인 get-StoreUsageStatistics(DigestCategory를 ‘LogBytes’로 설정)를 사용하여 로그 바이트 카운트 생성량이 많은 사서함을 파악할 수 있습니다. 사서함 소유자가 로그 바이트를 생성하지 않거나, CopyOnWrite와 같은 작업이 클라이언트 대신 수행되어 시스템 서비스에서 생성하는 로그 바이트(이벤트 ID 9826에 보고됨)는 포함되지 않는 등의 경우에는 이 방법을 사용할 수 없습니다. 이러한 통계는 로그 작업을 가장 많이 생성한 상위 사서함에서 지난 10분 동안 수행한 작업의 요약이 포함됩니다(지난 1시간 동안의 작업을 포함하는 최대 6개 샘플). 아래 코드는 저장소 사용량 통계를 사용하여 지난 1시간 동안 로그 바이트를 가장 많이 생성한 상위 사서함을 찾는 방법을 보여 줍니다.

    [PS] C:\>$stats = Get-StoreUsageStatistics –Database <Database Name>
    [PS] C:\>$stats | ? {$_.DigestCategory -eq 'LogBytes'} | group MailboxGuid |sort count -Descending | Select -first 1 -ExpandProperty Group | sort SampleTime | ft -a MailboxGuid,Sample*,Log*

    MailboxGuid SampleID SampleTime LogRecordCount LogRecordBytes
    c007c87a-e030-4414-b741-9cf61e88b9de 5 2011/11/7 오후 4:25:05 237 274163
    c007c87a-e030-4414-b741-9cf61e88b9de 4 2011/11/7 오후 4:35:05 451 387362
    c007c87a-e030-4414-b741-9cf61e88b9de 3 2011/11/7 오후 4:45:06 483 144999
    c007c87a-e030-4414-b741-9cf61e88b9de 2 2011/11/7 오후 4:55:06 734 293433
    c007c87a-e030-4414-b741-9cf61e88b9de 1 2011/11/7 오후 5:05:06 933 411485
    c007c87a-e030-4414-b741-9cf61e88b9de 0 2011/11/7 오후 5:15:06 247 209987

  2. 관리 클라이언트에 대해 생성되는 응용 프로그램 이벤트(이벤트 ID 9826)도 있습니다. 이러한 통계는 2시간에 해당하는 작업을 나타냅니다.

    <날짜/시간>에서 시작한 <이름> 서비스가 서버에서 이 작업을 수행했습니다.
    RPC 작업: 24168
    읽은 데이터베이스 페이지: 1329(미리 읽은 629페이지 중)
    업데이트된 데이터베이스 페이지: 12418(다시 업데이트된 11555페이지 중)
    생성된 데이터베이스 로그 레코드: 13906
    생성된 데이터베이스 로그 레코드 바이트: 660331
    서버의 시간: 19142ms
    사용자 모드의 시간: 6100ms
    커널 모드의 시간: 63ms

  3. 성능 모니터 카운터 “MSExchangeIS Client(*)\JET Log Record Bytes/sec”를 사용하여 로그를 증가시키는 클라이언트 유형을 파악할 수 있습니다.

데이터베이스 가용성에 영향을 주지 않으려면 충분한 공간을 확보해야 합니다. 이 게시물의 정보가 트랜잭션 로그 용량을 계획하는 데 도움이 되었으면 합니다. 

Ross Smith IV
주임 프로그램 관리자
Exchange Customer Experience

이 문서는 번역된 블로그 게시물입니다. 원본 문서는 Capacity Planning – Yes Transaction Log Space is Critical to Keeping your Databases Healthy and Mounted를 참조하십시오.