Exchange 2010 저장소 이해

적용 대상: Exchange Server 2010 SP2, Exchange Server 2010 SP3

마지막으로 수정된 항목: 2016-11-28

Exchange 저장소는 여러 가지 유형의 정보를 하나의 인프라에서 관리하기 위한 단일 리포지토리를 제공하는 저장소 플랫폼입니다. Exchange 저장소(store.exe)는 MicrosoftExchange Server 2010의 핵심 데이터 저장소 리포지토리입니다.

목차

Exchange 2010 버전의 데이터베이스

Exchange 저장소의 논리 구성 요소

Exchange 저장소의 파일 구조

트랜잭션 로깅 이해

Extensible Storage Engine

저장소 상태

데이터베이스 로그 또는 데이터베이스 드라이브의 디스크 공간 부족

Exchange 저장소 제한

Exchange 2010 버전의 데이터베이스

Exchange 2010은 Standard Edition과 Enterprise Edition 서버 버전으로 제공됩니다. Exchange 2010 Standard Edition은 중소기업의 메시징과 공동 작업 요구 사항을 충족하도록 설계되었습니다. 또한 특정 서버 역할 또는 지점에 적합합니다. Exchange 2010 Enterprise Edition은 대기업용으로 설계되었습니다.

Exchange 2010 Standard Edition은 최대 5개 데이터베이스를 지원합니다. Exchange 2010 Enterprise Edition은 최대 100개 데이터베이스를 지원합니다.

Exchange 저장소의 논리 구성 요소

Exchange 저장소의 주요 구성 요소는 사서함 데이터베이스와 공용 폴더 데이터베이스입니다. 이러한 구성 요소는 단일 서버에 위치하거나 여러 서버에 분산될 수 있습니다.

사서함 데이터베이스는 Exchange 2010에서 사서함을 구성하는 데이터, 데이터 정의, 인덱스, 체크섬, 플래그 및 기타 정보를 포함합니다. 사서함 데이터베이스는 개별 사용자의 개인 데이터를 보관하며 사용자의 사서함을 만들 때 생성되는 사서함 폴더를 포함합니다. 사서함 데이터베이스는 Exchange 데이터베이스(.edb) 파일로 저장됩니다.

공용 폴더 데이터베이스는 Exchange 조직에서 공용 폴더를 구성하는 데이터, 데이터 정의, 인덱스, 체크섬, 플래그 및 기타 정보를 포함합니다.

Exchange 2010에서는 Exchange 관리 셸을 사용하여 공용 폴더를 관리합니다. 또한 Exchange 관리 콘솔에서도 제한된 수의 공용 폴더 데이터베이스 관리 작업을 수행할 수 있습니다. 공용 폴더를 관리하는 방법에 대한 자세한 내용은 공용 폴더 관리 및 공용 폴더 이해를 참조하십시오.

Exchange 2010 버전의 데이터베이스

Exchange 저장소의 파일 구조

Exchange 저장소는 데이터베이스 등의 논리 구성 요소를 통해 관리합니다. 그러나 Exchange 2010에서는 Exchange 데이터베이스 파일(.edb), 트랜잭션 로그 파일(.log) 및 검사점 파일(.chk)과 같은 특수한 데이터 파일 집합에 데이터가 저장됩니다. 데이터를 백업 또는 복원할 때가 아니면 이러한 파일을 직접 사용하는 경우는 거의 없습니다. 다음 표에서는 이러한 각 파일에 대해 자세히 설명합니다.

Exchange 저장소의 파일 구조

Exchange 2010 버전의 데이터베이스

트랜잭션 로깅 이해

Exchange 트랜잭션 로깅은 Exchange 데이터베이스가 갑자기 중지된 경우에 해당 데이터베이스를 일관성 있는 상태로 안정적으로 복원하도록 설계된 강력한 ESE 복구 메커니즘입니다. 온라인 백업을 복원하는 경우 로깅 메커니즘도 사용됩니다. 이 섹션에서는 순환 로깅에 대한 간략한 설명을 포함하여 Exchange 2010 트랜잭션 로깅에 대해 자세히 설명합니다.

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 [log file name] 명령을 실행하면 헤더 정보가 표시됩니다.

헤더를 표시할 때 잘못된 스위치를 사용하면(예: 데이터베이스 헤더에 /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 명령으로 데이터베이스를 복구하여 일관성 있고 시작할 수 있는 상태로 만들어야 합니다.

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

Exchange 2010 버전의 데이터베이스

순환 로깅

순환 로깅을 사용하도록 설정하여 디스크 공간을 절약하도록 Exchange를 구성할 수 있습니다. 순환 로깅을 사용하면 Exchange는 트랜잭션 로그 파일 내의 데이터가 데이터베이스로 커밋된 후에 트랜잭션 로그 파일을 덮어씁니다. 그러나 순환 로깅을 사용하면 마지막 전체 백업을 수행할 때까지만 데이터를 복구할 수 있습니다. 예를 들어, 백업을 만들지 않는 Exchange 고유 데이터 보호를 사용하는 경우 순환 로깅을 사용하도록 설정할 수 있습니다. 로그가 너무 많이 쌓이지 않게 하려면 순환 로깅을 사용하도록 설정해야 합니다.

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

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

순환 로깅을 사용하거나 사용하지 않도록 설정하는 방법에 대한 자세한 내용은 사서함 데이터베이스 속성 구성을 참조하십시오.

Exchange 2010 버전의 데이터베이스

Extensible Storage Engine

Exchange 사서함 데이터베이스와 허브 전송 서버의 큐 및 Edge 전송 서버의 큐는 ESE 데이터베이스를 활용합니다. ESE는 DML(데이터 조작 언어) 및 DDL(데이터 정의 언어) 기능을 완전히 갖춘 다중 사용자 ISAM(Indexed Sequential Access Method) 테이블 관리자입니다. 응용 프로그램에서는 ESE를 사용하여 레코드를 저장하고 인덱스를 만들어 해당 레코드에 다양한 방식으로 액세스할 수 있습니다. ESE에 대한 자세한 내용은 ESE(Extensible Storage Engine) 아키텍처를 참조하십시오. Exchange 2010 ESE의 향상 기능에 대한 자세한 내용은 새 Exchange 핵심 저장소 기능을 참조하십시오.

Exchange 2010 버전의 데이터베이스

저장소 상태

Exchange 저장소는 해당 저장소가 비정상적인 상태가 되게 하는 여러 시나리오를 검색하고 수정할 수 있습니다. Exchange 저장소는 포이즌 사서함 및 스레드 시간 제한을 처리하고, 보고서 및 경고 기능을 사용하여 비정상적인 Exchange 저장소 상태를 알리고, 사서함 데이터베이스 및 공용 폴더 데이터베이스 문제를 검색하고 복구할 수 있습니다.

포이즌 사서함 검색 및 수정

손상된 데이터가 포함된 단일 사서함(논리적 또는 물리적)으로 인해 Exchange 저장소에서 오류가 발생하고 서버에 호스트된 모든 사서함에 대해 서비스가 거부될 수 있습니다. 마찬가지로, 포이즌 사서함으로 인해 Exchange 저장소에서 반복적으로 오류가 발생할 수도 있습니다. 이 섹션에서는 Exchange 저장소가 포이즌 사서함을 검색하고 차단하기 위해 수행하는 작업에 대해 설명합니다.

포이즌 사서함 격리

Exchange 저장소에서 사서함이 잠재적 위협 요소로 태그가 지정되는 여러 가지 이벤트가 있습니다.

• 사서함에 관련 작업을 수행하는 스레드가 실패하는 경우

• 사서함에 오랫동안 진행이 중지된 스레드가 6개 이상 있는 경우

잠재적 위협 요소로 태그가 지정되는 사서함은 태그 지정 횟수가 함께 저장됩니다. 이 정보는 레지스트리에 저장됩니다. Exchange 저장소는 사서함이 잠재적 위협으로 식별된 시기에 대한 타임스탬프 정보도 유지합니다.

데이터베이스 탑재 중에 Exchange 저장소는 사서함이 잠재적 위협으로 식별된 시간을 읽습니다. 2시간 이상 경과한 경우 사서함의 레지스트리 키가 삭제됩니다. 이 정보를 레지스트리에 유지할 경우 고가용성 환경에서 클러스터 데이터베이스가 이 정보를 복제하는 이점이 있습니다. Exchange 저장소 장애 조치(failover) 중에도 다른 컴퓨터에 이 정보가 포함됩니다. 포이즌 사서함 격리에 사용되는 레지스트리 하위 키는 **HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<서버 이름>\Private-{db guid}\QuarantinedMailboxes\{mailbox guid}**입니다. 이 경로의 키는 CrashCount와 LastCrashTime입니다.

사서함이 격리되게 하는 오류 수와 사서함이 격리된 상태로 유지되는 기간에 대한 설정은 HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<서버 이름>\Private-{db guid} 하위 키의 MailboxQuarantineCrashThreshold 및 MailboxQuarantineDurationInSeconds 키에 저장됩니다.

이러한 키의 기본값은 MailboxQuarantineCrashThreshold는 오류 3회이고 MailboxQuarantineDurationInSeconds는 21,600초(6시간)입니다.

포이즌 사서함에 대한 작업

기본적으로 사서함이 2시간 내에 오류 또는 교착 상태를 3회 발생시키는 것으로 식별되면 Exchange 저장소는 레지스트리에서 사서함에 격리되었다는 태그를 지정합니다. OPEN_AS_ADMIN 플래그가 전달되지 않은 경우 사서함 액세스가 허용되지 않습니다. Exchange 프로세스(예: 콘텐츠 인덱싱 또는 사서함 도우미)는 로그온할 수 없습니다. QuarantineState 및 QuarantineTime 레지스트리 키는 사서함이 격리되었는지 여부를 추적합니다. 사서함이 최근 2시간 동안 오류를 발생시키지 않았으며 격리되지 않은 경우 Exchange 저장소가 사서함의 레지스트리 경로를 정리합니다. 사서함이 LastCrashTime 값 이후 MailboxQuarantineDurationInSeconds 값보다 오래 격리된 경우에는 자동으로 격리에서 해제됩니다.

격리된 사서함 다시 설정

포이즌 사서함의 원인이 식별되고 수정된 경우 격리된 사서함의 레지스트리 키를 삭제하여 수동으로 다시 설정해야 합니다. 하지만 이 수동 단계를 잊어버린 경우 Exchange 저장소에서 격리됨 플래그가 설정된 시간부터 6시간 후에 격리된 사서함을 자동으로 다시 설정합니다. 이 기간 내에 문제가 디버그되어 해결되지 않은 경우에는 다른 일련의 오류가 발생하고 사서함이나 메시지가 다시 격리될 수 있습니다.

격리된 사서함을 다시 설정하는 기간은 레지스트리 키 HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\Private-{db guid}\QuarantinedMailboxes\MailboxQuarantineDurationInSeconds를 사용하여 제어할 수 있습니다.

보고 및 경고

Get-MailboxStatistics cmdlet을 사용하여 격리된 사서함 상태를 보고할 수 있습니다. Exchange 저장소에는 격리된 사서함 수를 계산하는 성능 모니터 카운터가 있습니다. 카운터 이름은 MSExchangeIS Mailbox\Quarantined Mailbox Count입니다.

또한 Exchange 저장소는 사서함을 격리할 때마다 해당 사서함과 시간에 대한 세부 정보를 포함하여 이벤트를 기록합니다. 격리된 사서함은 이벤트 10018로 확인됩니다.

Exchange 2010 버전의 데이터베이스

데이터베이스 복구

Exchange 2010 SP1(서비스 팩 1)에서는 New-MailboxRepairRequest cmdlet을 사용하여 사서함 손상을 검색하고 복구할 수 있습니다. 특정 사서함이나 사서함 데이터베이스에 대해 이 cmdlet을 실행할 수 있습니다. 이 작업이 실행되는 경우에는 복구되는 사서함에 대한 액세스는 중단됩니다. 사서함 데이터베이스에 대해 이 cmdlet을 실행하는 경우 복구되는 사서함에 대한 액세스만 중단됩니다. 데이터베이스의 다른 모든 사서함은 작동 상태를 유지합니다. 자세한 내용은 사서함 복구 요청 만들기을 참조하십시오.

New-MailboxRepairRequest cmdlet은 다음과 같은 사서함 손상 유형을 검색하고 복구합니다.

• 검색 폴더 손상(CorruptionType 매개 변수의 SearchFolder 값 사용)

• 올바른 값을 반영하지 않는 폴더의 집계 수(CorruptionType 매개 변수의 AggregateCounts 값 사용)

• 올바른 내용을 반환하지 않는 폴더의 보기(CorruptionType 매개 변수의 FolderView 값 사용)

• 프로비전되지 않은 상위 폴더를 잘못 가리키는 프로비전된 폴더(CorruptionType 매개 변수의 ProvisionedFolder 값 사용)

New-MailboxRepairRequest cmdlet을 실행한 후에 이벤트 뷰어를 사용하여 요청의 세부 정보를 볼 수 있습니다. 자세한 내용은 이벤트 뷰어에서 사서함 복구 요청 항목 보기을 참조하십시오.

New-PublicFolderDatabaseRepairRequest cmdlet을 사용하여 공용 폴더 데이터베이스의 복제 문제를 검색하고 해결할 수도 있습니다. 공용 폴더 데이터베이스의 공용 폴더는 요청이 실행되는 동안에도 계속 액세스할 수 있습니다. 그러나 복구가 진행 중인 공용 폴더는 액세스할 수 없습니다. 자세한 내용은 공용 폴더 데이터베이스 복구 요청 만들기을 참조하십시오.

Exchange 2010 버전의 데이터베이스

시간 제한 검색 및 보고

Exchange 저장소가 상태가 비정상적인 상태임을 나타내는 다른 표시는 스레드가 교착 상태에 있거나 더 이상 진행되지 않는 경우입니다. 단일 사서함에 6개 이상의 스레드가 있거나, 단일 데이터베이스에 10개의 스레드가 있거나, 1분 동안 진행되지 않은 단일 서버에 20개의 스레드가 있는 경우 서버에서 시간 제한이 보고됩니다. 검색된 시간 제한을 나타내는 성능 카운터는 MSExchangeIS\ RPC Request Timeout Detected입니다.

또한 Exchange 저장소는 서버에 다음 이벤트를 기록합니다.

• 10025 - Exchange 서버에 대한 시간 제한을 보고합니다.

• 10026 - 데이터베이스에 대한 시간 제한을 보고합니다.

• 10027 - 개별 사서함에 대한 시간 제한을 보고합니다.

단일 사서함에서 시간 제한이 검색된 경우 해당 사서함은 잠재적으로 포이즌으로 간주되며 CrashCount 키를 증가시켜 오류와 유사하게 처리됩니다. 이 경우 사서함이 격리될 수 있습니다.

Exchange 2010 버전의 데이터베이스

데이터베이스 로그 또는 데이터베이스 드라이브의 디스크 공간 부족

Exchange 저장소는 로그 또는 데이터베이스 드라이브에서 사용 가능한 공간이 1GB 미만으로 검색될 경우 해당 데이터베이스에 대한 모든 전송 배달을 차단합니다. 이렇게 하면 디스크 공간이 부족해지는 것을 방지할 수 있습니다. 디스크 공간이 부족하면 데이터베이스를 탑재하거나 디버그할 수 없습니다. 데이터베이스 공간을 다시 사용할 수도 없습니다. 이는 모니터링 인프라의 공간 문제 경고에 적절하게 반응하지 않는 경우에만 발생하는 자체 보호 메커니즘입니다.

디스크 공간이 1.5GB를 초과하면 Exchange 저장소에서 배달이 계속되도록 허용합니다. 이 동작을 나타내는 성능 카운터는 다음과 같습니다.

• MSExchangeIS Mailbox\ Delivery Blocked: Low Database Space

• MSExchangeIS Mailbox\ Delivery Blocked: Low Log Space

또한 Exchange 저장소는 서버에 다음 이벤트를 기록합니다.

• 10014 - 로그의 디스크 공간이 부족함을 나타냅니다.

• 10015 - 데이터베이스의 디스크 공간이 부족함을 나타냅니다.

디스크 공간 부족 문제가 발생할 경우 다음 작업을 수행하여 문제를 해결할 수 있습니다.

• 사서함에서 콘텐츠를 삭제합니다. 특히 지운 편지함 및 보낸 편지함 폴더에서 메시지를 삭제할 수 있습니다.

• 복구 가능한 항목 폴더에서 항목을 제거합니다. 자세한 내용은 복구 가능한 항목 폴더 정리를 참조하십시오.

• 데이터베이스 유지 관리를 실행합니다. 자세한 내용은 사서함 데이터베이스 유지 관리를 참조하십시오.

• 트랜잭션 로그를 제거합니다. 자세한 내용은 고가용성 요소 이해를 참조하십시오.

• 순환 로깅을 사용하도록 설정합니다. 자세한 내용은 사서함 데이터베이스 속성 구성를 참조하십시오.

• 데이터베이스 경로를 추가 공간이 있는 하드 디스크 드라이브로 변경합니다. 자세한 내용은 사서함 데이터베이스 복삭본에 대한 사서함 데이터베이스 이동를 참조하십시오.

Exchange 2010 버전의 데이터베이스

Exchange 저장소 제한

Exchange 2010에서는 단일 응용 프로그램 또는 단일 사용자가 Exchange 저장소에 대한 사용 가능한 연결을 모두 사용할 수 없도록 Exchange 저장소의 연결 및 사용이 제한됩니다. 단일 사용자 또는 응용 프로그램이 모든 연결을 사용하는 경우에는 다른 사용자나 응용 프로그램이 Exchange 저장소에 액세스할 수 없어 가동 중지 시간이 발생할 수 있습니다.

자세한 내용은 Exchange 저장소 제한을 참조하십시오.

Exchange 2010 버전의 데이터베이스

 © 2010 Microsoft Corporation. 모든 권리 보유.