Exchange 2010의 데이터베이스 유지 관리

Article
02/17/2012

최초 문서 게시일: 2011년 12월 14일 수요일

지난 몇 개월 동안 백그라운드 데이터베이스 유지 관리가 무엇인지, 그리고 Exchange 2010 데이터베이스에 대해 이 유지 관리가 중요한 이유는 무엇인지에 대한 많은 문의 사항이 있었습니다. 이 문서에서는 이러한 문의 사항에 대한 답변을 제공합니다.

데이터베이스에 대해 수행해야 하는 유지 관리 작업

Exchange 데이터베이스의 경우 다음과 같은 작업을 주기적으로 수행해야 합니다.

데이터베이스 압축
데이터베이스 조각 모음
데이터베이스 체크섬
페이지 패치
페이지 비우기

데이터베이스 압축

데이터베이스 압축은 기본적으로 데이터베이스 파일 내에서 사용되지 않는 공간을 확보하기 위한 것이지만, 이렇게 해도 사용되지 않는 공간이 파일 시스템으로 반환되지는 않습니다. 즉, 데이터베이스 압축에서는 레코드를 최대한 적은 수의 페이지로 압축하여 필요한 I/O를 줄임으로써 데이터베이스의 페이지를 확보합니다. ESE 데이터베이스 엔진은 이를 위해 데이터베이스의 테이블을 설명하는 데이터베이스 내의 정보인 데이터베이스 메타데이터를 가져온 다음 각 테이블의 페이지마다 방문하여 레코드를 논리적으로 순서가 지정된 페이지로 이동합니다.

린(lean) 데이터베이스 파일 공간 유지 관리가 중요한 이유는 다음과 같습니다.

데이터베이스 파일 백업과 관련된 시간 단축
예측 가능한 데이터베이스 파일 크기 유지(서버/저장소 크기 조정 시 중요)

Exchange 2010이 출시되기 전에는 온라인 유지 관리 창 동안 데이터베이스 압축 작업을 수행했습니다. 이 프로세스 중에 데이터베이스 내의 페이지를 확인하고 전체 페이지의 레코드 순서를 다시 지정하는 과정에서 임의의 I/O가 생성되었습니다. 이전 버전에서는 데이터베이스 페이지를 확보하고 레코드 순서를 다시 지정했으므로 페이지가 항상 임의의 순서로 배열되었습니다. 이 프로세스를 저장소 스키마 아키텍처에서 사용하는 경우 폴더 내의 항목을 다운로드하는 것과 같이 데이터 집합을 가져오는 요청에서는 항상 임의의 I/O가 생성되었습니다.

Exchange 2010에서는 데이터베이스 압축이 다시 설계되어 공간 압축이 아닌 인접 항목 압축 방식이 기본 사용됩니다. 또한 이제 데이터베이스 압축은 온라인 유지 관리 창 동안 수행되지 않으며, 지속적으로 실행되는 백그라운드 프로세스로 제공됩니다.

데이터베이스 조각 모음

데이터베이스 조각 모음은 Exchange 2010에 새롭게 추가된 기능으로, OLD v2 및 B+ 조각 모음이라고도 합니다. 데이터베이스 조각 모음의 목적은 순차 항목으로 표시되거나 해당 힌트가 제공된 데이터베이스 테이블을 압축하는 동시에 조각 모음을 수행해 순차 항목으로 만드는 것입니다. 시간의 경과에 따라 디스크 리소스를 계속해서 효율적으로 사용하고(임의가 아닌 순차 I/O 생성) 순차로 표시된 테이블을 압축 상태로 유지하려면 데이터베이스 조각 모음을 수행해야 합니다.

데이터베이스 조각 모음 프로세스는 다른 데이터베이스 페이지 작업을 감시하여 필요한 작업이 있는지를 결정하는 모니터의 개념으로 생각할 수 있습니다. 이 프로세스에서는 모든 테이블에서 사용 가능한 페이지를 모니터링하며, 테이블이 특정 임계값에 도달해 총 B+ 트리 페이지의 수 중에서 사용 가능한 페이지의 비율이 매우 높아지면 사용 가능한 페이지를 다시 루트로 보냅니다. 또한 순차 공간 힌트를 포함하는 테이블 집합(알려진 순차 사용 패턴을 사용하여 작성된 테이블) 내에서 인접 항목의 위치를 유지하는 작업도 수행합니다. 데이터베이스 조각 모음 과정에서 순차 테이블에 대한 검색/미리 읽기가 확인되는 경우 레코드가 테이블 내의 순차 페이지에 저장되어 있지 않으면 해당하는 페이지를 모두 B+ 트리의 새로운 범위로 이동하여 해당 테이블 섹션의 조각 모음을 수행합니다. 모니터링 섹션에 나와 있는 성능 카운터를 사용하여 데이터베이스가 안정적인 상태에 도달한 후 데이터베이스 조각 모음을 수행하는 빈도를 확인할 수 있습니다.

데이터베이스 조각 모음은 작업을 수행하면서 데이터베이스를 지속적으로 분석한 다음 필요할 때 비동기 작업을 트리거하는 백그라운드 프로세스입니다. 다음과 같은 두 시나리오에서는 데이터베이스 조각 모음이 제한됩니다.

최대 미해결 작업 수에 도달한 경우데이터베이스가 크게 변경된 경우 데이터베이스 조각 모음의 첫 단계에서 너무 많은 작업이 수행되지 않도록 합니다.
대기 시간 제한 100ms에 도달한 경우 시스템이 오버로드되면 데이터베이스 조각 모음에서 조각 모음 작업을 펀트하기 시작합니다. 펀트된 작업은 다음 번에 데이터베이스가 동일한 작동 패턴으로 작동될 때 실행됩니다. 어떤 조각 모음 작업이 펀트되었는지에 대한 내용은 저장되지 않으며, 시스템에서 추가 리소스가 확보되면 조각 모음이 다시 실행됩니다.

데이터베이스 체크섬

온라인 데이터베이스 검색이라고도 하는 데이터베이스 체크섬은 데이터베이스를 여러 개의 큰 청크로 읽은 다음 각 페이지를 체크섬(페이지가 실제로 손상되었는지 확인)하는 프로세스입니다. 체크섬은 부실 페이지와 같이 기본적으로 트랜잭션 작업에서는 검색되지 않을 수 있는 실제 손상 및 손실된 플러시를 검색하기 위한 것입니다.

Exchange 2007 RTM 및 모든 이전 버전에서는 체크섬 작업이 백업 프로세스 중에 수행되었습니다. 이로 인해 복제된 데이터베이스의 경우 문제가 발생했습니다(체크섬할 복사본이 현재 백업 중인 복사본뿐임). 수동 복사본을 백업하는 경우에는 활성 복사본에 대해 체크섬이 수행되지 않았습니다. 이 문제를 해결하기 위해 Exchange 2007 SP1에는 새로운 선택적 온라인 유지 관리 작업인 온라인 유지 관리 체크섬이 추가되었습니다. 자세한 내용은 Exchange 2007 SP1 ESE에서 변경된 내용 - 2부(영문일 수 있음)를 참조하십시오.

Exchange 2010에서는 데이터베이스 검색 시에 데이터베이스 체크섬 및 Exchange 2010 저장소 손상 이후의 작업이 수행됩니다. 손상으로 인해 공간이 유출될 수 있는데, 온라인 데이터베이스 검색에서 손실된 공간을 찾아 복구합니다. 현재 검색 중인 각 데이터베이스(활성 복사본과 수동 복사본 모두 해당)에 대한 데이터베이스 체크섬의 읽기 속도는 초당 약 5MB이며 사용하는 I/O는 256KB이고 모두 순차입니다. Exchange 2010의 시스템은 모든 데이터베이스에 대해 매주 한 번씩 전체 검색을 수행한다는 가정 하에 설계되었습니다.

검색이 7일보다 오래 걸리는 경우에는 응용 프로그램 로그에 다음 이벤트가 기록됩니다.

이벤트 ID: 733
이벤트 유형: 정보
이벤트 원본: ESE
설명: 정보 저장소 (15964) MDB01: 'd:\mdb\mdb01.edb' 데이터베이스에 대한 온라인 유지 관리 데이터베이스 체크섬 백그라운드 작업이 제시간에 완료되지 않습니다. 이 단계는 2011/11/10에 시작되었으며, 지금까지 7일에 걸쳐 총 604800초 동안 실행되었습니다.

활성 데이터베이스 복사본에 대한 검색이 7일보다 오래 걸리는 경우에는 검색이 완료된 후 다음 항목이 응용 프로그램 로그에 기록됩니다.

이벤트 ID: 735
이벤트 유형: 정보
이벤트 원본: ESE
설명: 정보 저장소 (15964) MDB01 데이터베이스 유지 관리가 'd:\mdb\mdb01.edb' 데이터베이스에서 전체 과정을 완료했습니다. 이 단계는 2011/11/10에 시작되어 총 777600초 동안 실행되었습니다. 이 데이터베이스 유지 관리 작업은 7일 유지 관리 완료 임계값을 초과했습니다. 다음 작업 중 하나 이상을 수행해야 합니다. 데이터베이스를 호스트하는 볼륨의 IO 성능/처리량을 늘리거나, 데이터베이스 크기를 줄이거나, 데이터베이스 이외의 유지 관리 IO를 줄이십시오.

또한 검색을 완료하는 데 7일보다 오래 걸리는 경우에는 응용 프로그램 로그에 실시간 경고도 기록됩니다.

Exchange 2010에서는 두 가지 모드로 활성 데이터베이스 복사본에 대해 데이터베이스 체크섬을 실행할 수 있습니다.

백그라운드에서 연중 무휴로 실행기본 동작입니다. 모든 데이터베이스에 사용해야 하며, 특히 크기가 1TB 이상인 데이터베이스에는 반드시 사용해야 합니다. Exchange에서는 최대 하루에 한 번만 데이터베이스를 검사하며, 이 읽기 I/O는 모두 순차이고(디스크 사용 면에서 효율적임) 검색 속도는 대부분의 시스템에서 초당 약 5MB입니다. 검색 프로세스는 단일 스레드 작업이며 I/O 대기 시간에 의해 제한됩니다. 대기 시간이 길수록 데이터베이스 체크섬에서 다른 페이지 일괄 검색(한 번에 8개 페이지를 읽음)을 실행하기 전에 마지막 일괄 검색이 완료되도록 기다려야 하는 시간이 길어지므로, 체크섬 속도가 느려집니다.
예약된 사서함 데이터베이스 유지 관리 프로세스에서 실행 이 옵션을 선택하면 데이터베이스 체크섬이 마지막 작업으로 실행됩니다. 사서함 데이터베이스 유지 관리 일정을 변경하여 체크섬 실행 시간을 구성할 수 있습니다. 이 옵션은 크기가 1TB보다 작아 전체 검색을 완료하는 데 시간이 적게 걸리는 데이터베이스에 대해서만 사용해야 합니다.

데이터베이스 크기와 관계없이 기본 동작을 사용하고, 활성 데이터베이스에 대해 데이터베이스 체크섬 작업을 예약된 프로세스로 구성하지 않는 것이 좋습니다. 즉, 데이터베이스 체크섬을 온라인 유지 관리 창 내의 프로세스로 구성해서는 안 됩니다.

수동 데이터베이스 복사본의 경우 데이터베이스 체크섬은 런타임 중에 수행되며 백그라운드에서 지속적으로 작동합니다.

페이지 패치

페이지 패치는 손상된 페이지가 정상 페이지로 바뀌는 프로세스입니다. 앞서 설명한 것처럼, 손상된 페이지는 데이터베이스 체크섬에서 검색되며 페이지가 데이터베이스 캐시에 저장되어 있는 경우에는 런타임에도 검색됩니다. 페이지 패치는 HA(항상 사용 가능한) 데이터베이스 복사본에 대해 작동합니다. 손상된 페이지의 복구 방법은 HA 데이터베이스 복사본이 활성인지 수동인지에 따라 달라집니다.

페이지 패치 프로세스

활성 데이터베이스 복사본

수동 데이터베이스 복사본

손상된 페이지가 검색됩니다.
활성 로그 파일에 표식이 기록됩니다. 이 표식은 손상된 페이지 번호 및 해당 페이지를 교체해야 함을 나타냅니다.
페이지 패치 요청 목록에 항목이 추가됩니다.
활성 로그 파일이 닫힙니다.
복제 서비스에서 로그 파일을 수동 데이터베이스 복사본에 전달합니다.
대상 사서함 서버의 복제 서비스에서 전달된 로그 파일을 받아 확인합니다.
대상 서버의 정보 저장소에서 로그 파일을 표식이 있는 부분까지 재생하고 정상 페이지 버전을 검색한 다음, 재생 서비스 콜백을 호출하여 페이지를 원본 사서함 서버로 전달합니다.
원본 사서함 서버에서 정상 페이지 버전을 받아 페이지 패치 요청 목록에 항목이 있음을 확인한 다음 페이지를 로그 버퍼에 씁니다. 그러면 페이지가 데이터베이스 캐시에 삽입됩니다.
페이지 패치 요청 목록의 해당 항목이 제거됩니다.
이 시점에서 데이터베이스는 캐시된 것으로 간주됩니다. 얼마 후에는 검사점이 앞으로 이동하고 데이터베이스 캐시가 플러시되며 디스크의 손상된 페이지가 덮어쓰기됩니다.
페이지 패치 요청 목록에 해당하는 목록이 더 이상 없으므로, 다른 수동 복사본에서 받은 이 페이지의 다른 복사본은 자동으로 삭제됩니다.

손상된 페이지가 검색된 사서함 서버에서 해당 데이터베이스 복사본에 대해 로그 재생이 일시 중지됩니다.
복제 서비스에서 활성 데이터베이스 복사본을 호스팅하는 사서함 서버와의 조정을 통해 활성 복사본의 데이터베이스 헤더에서 손상된 페이지와 필요한 로그 범위를 검색합니다.
사서함 서버에서 필요한 로그 범위를 새로 삽입하여 해당하는 데이터베이스 복사본의 데이터베이스 헤더를 업데이트합니다.
사서함 서버에서 활성 데이터베이스 복사본을 호스팅하는 사서함 서버에 필요한 로그 파일을 알립니다.
사서함 서버에서 필요한 로그 파일을 받아 확인합니다.
사서함 서버에서 활성 데이터베이스 복사본으로부터 검색된 정상 데이터베이스 페이지 버전을 주입합니다. 그러면 페이지가 로그 버퍼에 기록되고 데이터베이스 캐시에 삽입됩니다.
사서함 서버에서 로그 재생을 다시 시작합니다.

페이지 비우기

데이터베이스 페이지 비우기는 보안을 위해 데이터베이스에서 삭제된 페이지를 특정 패턴으로 덮어쓰는(비우는) 프로세스입니다. 이렇게 하면 데이터를 검색하기가 훨씬 어려워집니다.

Exchange 2007 RTM 및 모든 이전 버전에서는 페이지 비우기가 스트리밍 백업 프로세스 중에 수행되었으며, 따라서 로깅되는 작업이 아니었습니다. 즉, 페이지 비우기를 수행해도 로그 파일이 생성되지 않았습니다. 이로 인해 복제된 데이터베이스에서 문제가 발생했는데, 수동 복사본의 경우 페이지를 비운 적이 없으며 활성 복사본의 경우에는 스트리밍 백업을 수행한 경우에만 페이지 비우기가 수행되었기 때문입니다. 이 문제를 해결하기 위해 Exchange 2007 SP1에서는 새로운 선택적 온라인 유지 관리 작업인 체크섬 중에 데이터베이스 페이지 비우기가 도입되었습니다. 자세한 내용은 Exchange 2007 SP1 ESE에서 변경된 내용 - 2부(영문일 수 있음)를 참조하십시오. 이 작업을 사용하도록 설정하는 경우 온라인 유지 관리 창 중에 페이지를 비우고 변경 내용을 기록하며, 해당 내용은 수동 복사본으로 복제됩니다.

Exchange 2007 SP1 구현에서는 예약된 유지 관리 창 중에 비우기 프로세스가 수행되므로 페이지가 삭제되는 시점과 비워지는 시점 간에 지연 시간이 매우 길었습니다. 이를 보완하기 위해 Exchange 2010 SP1에서는 페이지 비우기 작업이 지속적으로 작동하는 런타임 이벤트로 실행되며, 보통 영구 삭제를 수행하면 트랜잭션 시간에 페이지를 비웁니다.

또한 온라인 체크섬 프로세스 중에 데이터베이스 페이지를 지울 수도 있습니다. 이와 같이 지울 수 있는 페이지는 다음과 같습니다.

과도한 시스템 오버로드로 인해 작업이 삭제되었거나, 작업에서 데이터를 지우기 전에 저장소가 손상되어 런타임 중에는 지울 수 없는 삭제된 레코드
삭제된 테이블 및 보조 인덱스. 이러한 항목은 삭제해도 실제로 콘텐츠가 지워지지는 않으므로, 온라인 체크섬에서는 이러한 페이지가 더 이상 유효한 개체에 속하지 않은 것으로 확인하여 페이지를 지웁니다.

Exchange 2010의 페이지 비우기에 대한 자세한 내용은 Exchange 2010 페이지 비우기 이해를 참조하십시오.

이러한 작업이 예약된 유지 관리 창 중에 수행되지 않는 이유

페이지 비우기, 데이터베이스 조각 모음, 데이터베이스 압축 및 온라인 체크섬 작업을 위해 예약된 유지 관리 창을 지정하면 다음을 비롯한 심각한 문제가 발생합니다.

예약된 유지 관리 작업을 수행하는 경우 여러 표준 시간대의 사서함을 호스팅하는 연중 무휴 데이터 센터를 관리하기가 매우 어려워지며, 예약된 유지 관리 창에 지정할 수 있는 시간이 거의 또는 전혀 없습니다. 이전 Exchange 버전의 데이터베이스 압축에는 제한 메커니즘이 없고 I/O가 거의 임의로 생성되므로 사용자 환경의 성능이 저하될 수 있습니다.
낮은 계층 저장소(예: 7.2K SATA/SAS)에 배포된 Exchange 2010 사서함 데이터베이스의 경우 ESE에서 사용 가능한 유효 I/O 대역폭이 낮아 유지 관리 창 작업을 수행하기가 어렵습니다. 즉, 유지 관리 창 중에 I/O 대기 시간이 길어져 유지 관리 작업을 원하는 시간 내에 완료할 수 없습니다.
JBOD를 사용하는 경우 데이터 확인 측면에서 데이터베이스에 또 다른 문제가 발생합니다. RAID저장소에서는 보통 배열 컨트롤러를 통해 지정된 디스크 그룹의 백그라운드 검색을 수행하여 불량 블록을 찾은 다음 다시 지정합니다. 불량 블록(섹터)은 디스크 입자가 물리적으로 손상되는 등 디스크에서 영구적으로 손상되어 사용할 수 없는 블록입니다. 또한 초기 읽기 요청에서 불량 블록이 검색되면 배열 컨트롤러는 대개 대체 미러 디스크를 읽은 후에 불량 블록을 "불량"으로 표시하고 새 블록에 데이터를 씁니다. 이 모든 작업이 수행되는 것을 응용 프로그램은 인식하지 못하며, 디스크 읽기 대기 시간만 약간 길어질 뿐입니다. RAID 또는 배열 컨트롤러가 없으면 이러한 불량 블록 검색 및 수정 방법을 더 이상 사용할 수 없습니다. RAID를 사용하지 않는 경우에는 응용 프로그램(ESE)이 불량 블록을 검색하여 데이터베이스 체크섬 등의 수정 작업을 수행해야 합니다.
용량이 큰 디스크에 큰 데이터베이스가 있는 경우 데이터베이스 순차성/압축을 유지하기 위한 유지 관리 시간이 더 길어집니다.

이러한 문제로 인해 Exchange 2010에서는 데이터베이스 유지 관리 작업이 예약된 프로세스에서 수행되지 않고 런타임 동안 백그라운드에서 지속적으로 수행되도록 변경되었습니다.

백그라운드 작업이 최종 사용자에게 주는 영향

이러한 백그라운드 작업은 데이터베이스에 대해 수행되는 작업을 기준으로 자동 제한되도록 설계되었습니다. 또한 메시지 프로필에 대한 크기 조정 지침에는 이러한 유지 관리 작업 관련 사항이 반영되어 있습니다. 그렇다고 해도, 저장소 아키텍처는 세심하게 설계해야 합니다. 같은 LUN 또는 볼륨에 여러 데이터베이스를 저장하려는 경우에는 모든 데이터베이스를 합한 크기가 2TB를 초과하지 않도록 해야 합니다. 데이터베이스 유지 관리는 데이터베이스/볼륨의 수에 따른 직렬화를 통해 제한되며, 총 데이터베이스 크기가 2TB보다 크지 않다고 가정하기 때문입니다.

백그라운드 유지 관리 작업의 효율성을 모니터링하는 방법

이전 Exchange 버전에서는 응용 프로그램 로그의 이벤트를 사용하여 온라인 조각 모음 등의 작업을 모니터링할 수 있었습니다. Exchange 2010에서는 조각 모음 및 압축 유지 관리 작업에 대해 이벤트가 더 이상 기록되지 않습니다. 그러나 성능 카운터를 통해 MSExchange Database ==> Instances 개체 아래에서 백그라운드 유지 관리 작업을 추적할 수 있습니다.

카운터	설명
Database Maintenance Duration	이 데이터베이스에 대한 유지 관리가 마지막으로 완료된 이후 경과한 시간입니다.
Database Maintenance Pages Bad Checksums	데이터베이스 유지 관리 과정 중에 발견된 수정할 수 없는 페이지 체크섬 수입니다.
Defragmentation Tasks	현재 실행 중인 백그라운드 데이터베이스 조각 모음 작업의 수입니다.
Defragmentation Tasks Completed/Sec	실행이 완료되는 백그라운드 데이터베이스 조각 모음 작업의 수입니다.

다음 페이지 비우기 카운터는 MSExchange Database 개체 아래에 있습니다.

카운터	설명
Database Maintenance Pages Zeroed	성능 카운터를 호출한 후 데이터베이스 엔진에서 비운 페이지의 수를 나타냅니다.
Database Maintenance Pages Zeroed/sec	데이터베이스 엔진에서 페이지를 비우는 속도를 나타냅니다.

데이터베이스의 공백을 확인하는 방법

셸을 통해 데이터베이스에서 사용 가능한 공백을 확인할 수 있습니다. 사서함 데이터베이스의 경우 다음을 사용합니다.

Get-MailboxDatabase MDB1 -Status | FL AvailableNewMailboxSpace

공용 폴더 데이터베이스의 경우 다음을 사용합니다.

Get-PublicFolderDatabase PFDB1 –Status | FL AvailableNewMailboxSpace

공백을 회수하는 방법

데이터베이스에 사용 가능한 공백이 있으면 회수해야 합니다. 이 섹션에서는 공백 회수 방법을 설명합니다.

대부분의 사용자는 공백을 회수하려면 ESEUTIL을 사용하여 오프라인 데이터베이스 조각 모음을 수행해야 한다고 생각할 것입니다. 그러나 더 효율적인 방법이 있습니다. 오프라인 조각 모음을 수행하면 완전히 새로운 데이터베이스가 작성되며, 이 새 데이터베이스를 작성하기 위해 수행한 작업은 트랜잭션 로그에 기록되지 않습니다. 또한 새 데이터베이스에는 새 데이터베이스 서명이 있으므로, 이 데이터베이스와 연결된 데이터베이스 복사본은 무효화됩니다.

데이터베이스에 공백이 많으며 일반적인 작업으로는 공백을 회수할 수 없는 경우에는 다음을 수행하는 것이 좋습니다.

새 데이터베이스 및 연결된 데이터베이스 복사본을 만듭니다.
모든 사서함을 새 데이터베이스로 이동합니다.
원래 데이터베이스 및 연결된 데이터베이스 복사본을 삭제합니다.

혼동하기 쉬운 용어

가장 혼동하기 쉬운 용어는 백그라운드 데이터베이스 유지 관리입니다. 집합적인 의미로 보면 위에서 설명한 모든 작업이 백그라운드 데이터베이스 유지 관리 작업이라 할 수 있습니다. 그러나 셸, EMC 및 JetStress에서는 모두 데이터베이스 체크섬을 백그라운드 데이터베이스 유지 관리로 지칭합니다. 이러한 도구를 사용하여 백그라운드 데이터베이스 유지 관리를 사용하거나 사용하지 않도록 설정할 때는 데이터베이스 체크섬을 구성합니다.

그림 1: EMC를 사용하여 데이터베이스에 대해 백그라운드 데이터베이스 유지 관리를 사용하도록 설정

셸을 사용하는 경우에는 다음과 같이 백그라운드 데이터베이스 유지 관리를 사용하도록 설정합니다.

Set-MailboxDatabase -Identity MDB1 -BackgroundDatabaseMaintenance $true

그림 2: JetStress 테스트의 일부분으로 백그라운드 데이터베이스 유지 관리 실행

저장소 공급업체에서 백그라운드 유지 관리 작업으로 설정된 데이터베이스 체크섬을 사용하지 않도록 권장하는 경우

저장소가 적절하게 설계되어 있지 않으면 순차 저장소에서도 데이터베이스 체크섬으로 인한 I/O 부담이 커질 수 있습니다. 데이터베이스 체크섬에서는 256K 읽기 I/O를 수행하고 데이터베이스당 약 5MB의 I/O를 생성하기 때문입니다.

Microsoft에서는 저장소 지침의 일부분으로 저장소 배열 스트라이프 크기(배열에서 각 디스크에 쓰는 스트라이프의 크기로, 블록 크기라고도 함)를 256KB 이상으로 구성할 것을 권장합니다.

또한 JetStress를 사용해 저장소를 테스트(영문일 수 있음)하여 데이터베이스 체크섬 작업이 테스트 과정에 포함되도록 해야 합니다.

마지막으로, 데이터베이스 체크섬으로 인해 JetStress를 실행할 수 없는 경우에는 다음을 수행할 수 있습니다.

스트라이핑 사용 안 함 RAID-1 쌍이나 JBOD(아키텍처를 변경해야 할 수 있음)를 사용하고, Exchange 2010에서 사용 가능한 순차 I/O 패턴을 최대한 활용합니다.
체크섬 예약 데이터베이스 체크섬을 백그라운드 프로세스가 아닌 예약된 프로세스로 구성합니다. 데이터베이스 체크섬을 백그라운드 프로세스로 구현했을 때 일부 저장소 배열이 임의 I/O에 대해 최적화되거나 대역폭이 제한되어 순차 읽기 I/O를 효율적으로 처리하지 못하는 현상이 확인되었습니다. 따라서 데이터베이스 체크섬은 해제 가능하도록 작성되었으며, 해제하는 경우 체크섬 작업이 유지 관리 창으로 이동합니다.

이와 같이 예약하는 경우에는 데이터베이스 크기를 줄이는 것이 좋습니다. 또한 수동 복사본의 경우에는 데이터베이스 체크섬이 계속 백그라운드 프로세스로 수행되므로, 저장소 아키텍처에서 해당 처리량을 고려해야 합니다. 이 주제에 대한 자세한 내용은 Jetstress 2010 및 백그라운드 데이터베이스 유지 관리(영문일 수 있음)를 참조하십시오.
다른 저장소를 사용하거나 저장소 기능 개선 Exchange 모범 사례(스트라이프 크기 256KB 이상)를 충족할 수 있는 저장소를 선택합니다.

결론

Exchange Server 2010에서는 데이터베이스 엔진의 아키텍처가 변경되어 성능과 기능이 크게 향상되었지만, 그와 동시에 데이터베이스 유지 관리 작업도 이전 버전과는 다르게 변경되었습니다. Exchange 2010의 백그라운드 데이터베이스 유지 관리에 대해 파악하는 데 이 문서가 도움이 되기를 바랍니다.

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

이 문서는 번역된 블로그 게시물입니다. 원본 문서는 Database Maintenance in Exchange 2010을 참조하십시오.