데이터베이스 복구 전략
마지막으로 수정된 항목: 2006-06-12
이 섹션에서는 데이터베이스 구조를 설명하고 데이터베스 복구 전략에 대해 알아봅니다.
데이터베이스 구조 이해
데이터베이스 구조를 이해하려면 데이터베이스의 페이지 수준, ESE(Exchange Store Engine) 테이블 수준 및 응용 프로그램 수준을 이해해야 합니다. 다음은 각 수준에 대한 간단한 설명입니다.
페이지 수준: 파일에는 각 페이지마다 공통된 조직 구조를 공유하는 일련의 페이지(일반적으로 4KB 또는 4KB의 배수)가 순서대로 포함되어 있습니다. 각 페이지에는 페이지 헤더 정보와 페이지 데이터가 있습니다. 헤더 정보에는 Exchange가 데이터 무결성을 확인하고 페이지의 단일 비트 오류를 수정할 수 있도록 하는 체크섬이 들어 있습니다.
ESE 테이블 수준: 페이지 그룹은 ESE 데이터베이스 그룹에서 관리하는 테이블이 소유합니다. 일반적인 Exchange 데이터베이스에는 수천 개의 개별 테이블이 들어 있습니다.
응용 프로그램 수준: ESE는 여러 응용 프로그램에서 사용할 수 있는 일반 데이터베이스입니다. 예를 들어 Exchange와 Active Directory 디렉터리 서비스 둘 다 ESE를 사용합니다. ESE 데이터베이스 엔진은 특정 응용 프로그램에서 지정하는 대로 해당 테이블에 정보를 저장합니다. ESE 자체는 응용 프로그램에서 정의하는 테이블 간의 관계 또는 각 테이블에 저장된 데이터의 의미를 이해하지 못합니다.
데이터베이스 복구 전략 이해
손상된 데이터베이스 파일을 복구하는 가장 기본적인 전략은 백업에서 알려진 데이터베이스 복사본을 복원하고 이어서 생성되는 트랜잭션 로그 파일을 사용하여 데이터베이스를 롤포워드하는 것입니다. 이 전략을 사용하려면 다음 세 가지 가정을 만족해야 합니다.
- 데이터베이스의 올바른 백업이 있습니다.
- 백업 이후에 생성된 트랜잭션 로그 파일을 모두 사용할 수 있으며 손상된 파일이 없습니다.
- 논리적 손상이나 의도하지 않은 삭제로 인한 데이터베이스 문제가 없습니다. 예를 들어 바이러스 검색 프로그램이 메시지를 손상시키거나 삭제한 경우 이러한 손상 및 삭제는 트랜잭션 로그 레코드에 기록되며 백업에서 복원한 이후에 데이터베이스에 재생됩니다.
다른 데이터베이스 복구 전략은 다음과 같습니다.
사서함 이동
Exchange 사서함을 다른 데이터베이스로 이동하면 Exchange 정보 저장소에서 해당 사서함 내용을 처음 만들어졌을 때와 동일하게 처리합니다. 손상된 항목은 생략됩니다. 따라서 손상된 항목을 제거하고 이와 동시에 복구되는 사용자 콘텐츠의 양을 극대화하려면 모든 사서함을 새 데이터베이스로 이동하는 것이 좋은 전략입니다.
사서함이 이동되고 나면 클라이언트를 새 데이터베이스 또는 서버에 연결하도록 Outlook 클라이언트 프로필이 자동으로 업데이트됩니다. 이 경우 이전 서버는 모든 클라이언트가 한 번씩 로그온하고 리디렉션될 때까지 실행 중인 Information Store 서비스와 함께 온라인 상태를 유지해야 합니다. 이전 서버가 온라인 상태를 유지하지 않을 경우에는 스크립트를 사용하거나 수동으로 Outlook 클라이언트 프로필을 업데이트해야 합니다.
이전 오프라인 또는 캐시된 모드의 클라이언트 파일은 사서함을 이동한 후에도 계속 사용할 수 있습니다. 또한 클라이언트 규칙 기능도 사서함이 이동될 때 보존됩니다.
사서함을 이동하는 경우 대상 서버에는 사서함의 모든 항목을 한 번에 다시 전달하는 것과 동일한 부하가 발생합니다. 따라서 많은 사서함을 이동할 때는 사용량이 적은 시간대에 작업을 수행하고 이동이 발생하는 시간 및 이동 후 로그온 문제가 발생한 경우 도움을 받을 수 있는 방법 등의 정보를 클라이언트에 미리 제공하는 것이 좋습니다.
많은 사서함을 이동하면 대상 데이터베이스에 일반적으로 생성되는 것보다 많은 수의 데이터베이스 트랜잭션 로그 파일이 생성될 수 있습니다. 따라서 대량 사서함 이동 작업을 수행하는 동안에는 대상 서버의 트랜잭션 로그 디스크 공간을 면밀히 살펴야 합니다. 트랜잭션 로그 디스크 공간이 점점 부족해지면 온라인 전체 또는 증분 백업을 실행하여 로그 파일을 지우거나 이동 전에 순환 로깅을 설정한 다음 이동 후에 바로 해제할 수 있습니다.
모든 사서함을 새 데이터베이스로 이동하고 이전 데이터베이스를 무시하면 데이터베이스 중단 시간을 최소화하면서 동시에 복구 가능한 사용자 콘텐츠를 최대한으로 유지할 수 있습니다.
Exchange 데이터베이스를 다른 서버 또는 저장소 그룹으로 이동하는 방법에 대한 자세한 내용은 다른 서버 또는 저장소 그룹으로 Exchange 사서함 데이터베이스 이동을 참조하십시오.
데이터베이스 복구
일반적으로 데이터베이스는 복원 및 롤포워드할 수 없는 경우에만 복구해야 합니다. 대개 데이터베이스 복구 작업에는 백업에서 복원할 때보다 많은 시간이 소요됩니다.
참고 데이터베이스가 심하게 손상된 경우에는 복구를 실행하는 데 오래 걸리고 성공 가능성도 희박합니다. 손상되지 않았거나 약간 손상된 데이터베이스에서 복구를 실행하는 데 일반적인 엔터프라이즈급 서버 하드웨어를 사용하는 경우 보통 5GB의 데이터 양을 기준으로 약 1시간이 걸립니다. 따라서 SLA(서비스 수준 계약)를 계획할 때 복구 시간을 계산하려면 사용자 조직의 Exchange에 사용되는 것과 유사한 하드웨어에서 실행되는 대표적인 데이터베이스를 자체적으로 벤치마킹해야 합니다. 데이터베이스가 심하게 손상된 경우에는 복구 시간이 10배 이상 늘어날 수 있습니다.
Eseutil을 사용하여 데이터베이스를 복구하는 방법에 대한 자세한 내용은 Eseutil /P 복구 모드를 참조하십시오.
복원, 복구 및 병합
데이터베이스 복원, 복구 및 병합을 대개 혼합 전략이라고 합니다. 이 전략은 적절한 데이터베이스 백업이 있지만 백업 후 생성되지 않은 트랜잭션 로그가 있는 경우에 사용할 수 있습니다.
이 경우 백업을 복원하고 동시에 같은 서버 또는 시험 서버의 복구 저장소 그룹에 있는 손상된 데이터베이스 복사본을 복구할 수 있습니다. 그런 다음 복구 저장소 그룹 기능을 사용하여 두 데이터베이스 복사본을 모두 개별적으로 탑재하고 복구된 데이터베이스의 데이터를 복원된 데이터베이스에 병합할 수 있습니다.
이 전략이 성공한다면 트랜잭션 로그를 사용할 수 있을 때와 거의 비슷한 양의 데이터를 복구할 수 있습니다.복구 저장소 그룹을 사용한 여러 가지 혼합 전략에 대한 자세한 내용은 Exchange Server 2003 복구 저장소 그룹 사용(https://go.microsoft.com/fwlink/?LinkId=47589)에 관한 가이드를 참조하십시오.
자세한 내용
자세한 내용은 Exchange 서버 데이터베이스 유틸리티 가이드에서 다음 항목을 참조하십시오.