EDB 및 STM 파일들을 모두 Rename 합니다.

해당 저장소를 Mount 시키면 아래와 같은 확인 메세지와 함께 DB가 재 생성됩니다.

오늘은 Exchange 2003의 메모리 최적화 구성에 대하서 검토하도록 하겠습니다.
생각외로 이런 사항에 대해 정리된 문서를 찾기가 쉬운건 아니더군요...^^
그래서 한번 정리해 봅니다...^^
만약 인용하시더라도 꼭 출처를 밝혀 주시고 덧글로라도 어디로 퍼간다는 정도의 로그는 남겨 주시기 바랍니다.
(제가 경험과 노하우를 기록한 제 글들이 버젓이 도용되고 있는데 기분이 썩 좋은건 아닙니다.)

궁금한건 mail 이나 msn, nateon 으로 물어보세요.
주로 msn을 이용합니다...^^
windows의 메모리에 대한 이해가 없이는 보기 힘든 문서예요...^^

0. 3GB 설정
Windows 2003 서버의 경우 3GB 스위치를 이용하여, 사용자 프로세스에 메모리를 3G까지 제공할 수 있습니다.
Store.exe는 메모리가 부족할 시 심각한 문제를 일으킬 수 있습니다.

위치 : C:\boot.ini
설정값 : /3GB /USERVA = 3030
주의 사항 : frontend exchange의 경우 실제 IIS와 동일한 서비스를 하게 됩니다. 이때는 http에 대한 서비스를 함으로 실제로 사용자 메모리보다 커널 메모리가 더욱 필요합니다. 본 사항은 backend exchange에 한하여 적용하시기 바랍니다.

1. Systempages 설정
Defines the number of system page table entries that are reserved for mapping I/O buffers and other information into the system address space. Each system page table entry maps one page.
3GB 옵션을 사용하고 /USERVA 3030 스위치를 주셨을 경우 크게 건들 필요는 없습니다. 이미 /USERVA = 3030을 통해 시스템에 할당하는 메모리를 최대한 허용하라라고 명시했기 때문입니다.

위치 : HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
설정 값
- 0x0 : System이 최적의 값을 자동으로 설정합니다.
- 0x1 ~ 0xFFFFFFFE
- 0xFFFFFFFF : System이 사용할 수 있는 최대 양의 메모리를 시스템에 할당합니다. /USERVA = 3030 과 동일한 구성입니다.

2. HeapDeCommitFreeBlockThreshold
The HeapDecommitFreeBlockThreshold registry key specifies the number of contiguous bytes above which the memory is decomitted (the second option) rather than retained for reuse (the first option).
1G 이상의 메모리를 사용하는 경우 메모리 단편화를 줄이기 위해 연속된 공간이 좀더 긴 메모리를 반환 하게 하는것이 좋습니다. 물론 메모리의 크기가 작다면 바로 바로 OS에 반환해 줘야 하지만 1G 이상일 경우에는 262144 로 해당 값을 설정하는 것이 좋습니다.

위치 : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
설정 값
- 권장 설정 값은 262144 (0x00040000) 입니다.

3. msExchESEParamCacheSizeMax
SQL Server의 버퍼 캐시와 같이 Exchange 또한 ESE 버퍼를 가지고 있습니다. 기본적으로 Exchange Server 2003에서는 로컬 컴퓨터의 메모리 구성을 조회한 다음 Boot.ini 파일에 /3GB 스위치가 설정되어 있으면 896MB의 RAM을 할당하고 /3GB 스위치가 설정되어 있지 않으면 576MB의 RAM을 할당합니다. 이 수치는 8192의 배수로 설정되어야 하며 1200MB를 초과 할 수 없습니다.

설정 방법
1). ADSI(Active Directory Service Interfaces) Edit 유틸리티를 시작합니다. ADSI Edit 유틸리티는 Windows 2000 또는 Windows Server 2003 CD-ROM의 Support\Tools 폴더에 있는 Windows 지원 도구에 포함되어 있습니다.
2). Configuration Container [servername.example.com](여기서 servername.example.com은 해당 서버의 정규화된 도메인 이름 FQDN)에서 CN=Configuration, DC=example, DC=com을 확장합니다.
3). CN=Services, CN=Microsoft Exchange, CN=OrganizationName(여기서 OrganizationName은 해당 조직의 이름), CN=Administrative Groups, CN=First Administrative Group(여기서 First Administrative Group은 해당 관리 그룹의 이름), CN=Servers, CN=servername을 차례로 확장합니다.
4). CN=servername에서 CN=InformationStore를 마우스 오른쪽 단추로 누른 다음 속성을 누릅니다.
5). Select which properties to view 목록에서 Both를 누릅니다.
6). Select a property to view 목록에서 msExchESEParamCacheSizeMax를 누릅니다.
참고 msExchESEParamCacheSizeMax 속성 이름의 길이는 Select a property to view 목록의 너비를 초과하므로 화면에 완전히 표시되지 않습니다. 이 속성 대신 msExchESEParamCacheSizeMin 속성을 잘못 누르지 않도록 주의하십시오.
7). Edit Attribute 상자에서 이 특성에 할당할 값을 입력합니다.
참고 8,192의 배수 값을 입력해야 합니다.
8). Set을 누르고 OK를 누릅니다.
9). ADSI Edit 유틸리티를 종료합니다. 그런 다음 이 값이 Active Directory 포리스트에 복제될 때까지 충분히 기다립니다.
10). Exchange 서버에서 Microsoft Exchange 정보 저장소 서비스를 다시 시작합니다.

설정 값
- /3GB 스위치가 설정된 서버에서의 기본 크기: 229376(896MB)
- /3GB 스위치가 설정되지 않은 서버에서의 기본 크기: 147456(576MB)
- /3GB 스위치가 설정된 상태에서 권장되는 최대값: 311296(1.2GB) 모니터링 필요
- /3GB 스위치를 설정하지 않은 상태에서 권장되는 최대값: 196608(768MB) 모니터링 필요
참고 ESE 버퍼의 크기가 크게 설정되면 트랜잭션 로그의 재생이 상당히 빨라집니다. 재해 복구 시나리오에서 임시로 ESE 버퍼 크기를 311296 값으로 늘릴 수 있습니다.

모니터링
ESE에 너무 많은 메모리를 주게 되면 다른 프로세스들이 메모리를 할당 받지 못하여 종종 성능문제를 발생 시킬 수 있습니다.

성능 카운터
성능 개체: Process
성능 카운터: Virtual Bytes
인스턴스: STORE

모니터링 방법
성능 모니터링으로 수집된 정보를 통해 Store.exe 프로세스가 할당한 가상 주소 공간의 정확한 값을 알 수 있습니다. Boot.ini 파일에 /3GB 스위치가 설정되어 있는 서버에서 성능 유틸리티에 표시된 값은 대개 2.8GB보다 작습니다. Boot.ini 파일에 /3GB 스위치가 설정되지 않은 서버에서 이 값은 대개 1.8GB보다 작습니다. 1GB 이상의 메모리가 설치된 서버에서는 Boot.ini 파일에 /3GB 스위치를 추가하는 것이 좋습니다. 앞에서 설명한 것보다 큰 값이 나타나면 둘 중 어느 구성에서도 최대 버퍼 크기를 늘리지 마십시오. 앞에서 설명한 것보다 작은 값이 나타나면 두 구성 모두에서 데이터베이스의 최대 버퍼 크기를 늘릴 수 있습니다.
예를 들어, Boot.ini 파일에서 /3GB 스위치를 사용하도록 구성된 서버가 있고, 서버의 로드가 매우 클 때 성능 모니터의 Virtual Bytes 카운터가 2.5GB이면 최대 버퍼 크기를 약 300MB까지 늘려 총 크기가 1,200MB가 되도록 할 수 있습니다.
버퍼 크기를 늘리면 서버 성능이 저하될 수 있습니다. 버퍼가 커질수록 가상 주소 공간이 많이 소모됩니다. 따라서 서버에 가상 메모리 주소 공간 제약 조건이 발생한 경우 버퍼 크기를 늘리면 운영 체제가 불안정해질 수 있습니다. 매우 큰 사서함 서버에서는 시스템이 불안정해지지 않도록 기본 버퍼 크기를 줄여야 합니다.

관련 문서
http://support.microsoft.com/kb/315407
http://support.microsoft.com/kb/815372
http://technet2.microsoft.com/windowsserver/en/library/c5ccbaec-f552-4f61-a488-8ee3330d1eeb1033.mspx?mfr=true

보통 장애가 발생하면 이렇습니다.

오늘 오전은 약간 상황이 달랐습니다.

전 언제나와 같이 귀에 이어폰을 끼고 출근을 하고 있었죠.
부딩키고, 엉키다 보니... 전화를 2번이나 못받아 버렸습니다.
이윽고 고객사 도착

고객 (역시 다급한 목소리로) "민성씨 메일이 않되요 어떻게 된 일이예요??"

저 역시 머리가 쭈삣 쭈빗 솟음을 느꼈습니다.
(그때 사수의 이야기가 생각납니다.
"니가 겁먹을 필요 없어 침착하게 해결하면 돼! 고객사의 장애는 네게 큰 문제야 하지만 네가 문제를 일으킨 건 아니고, 또 고객사의 장애가 마음 아프긴 하지만 니가 허둥 지둥하면 될것도 않돼!")
다시 한번 침착함을 되세깁니다.

자 시작!

아 "Information Store" 가 시작이 않되는군...

DC와 연결을 볼까?
역시나 연결이 않됩니다.

로그를 보니 세벽 3시부터 연결이 끈겼습니다.
DC에서 보니 DC는 전혀 문제가 없습니다.

결론은 네트워크 장애...
(netstat -an 을 통해 서버의 모든 Connection을 볼 수 있습니다.)
(물론 기본적인 Ping도 많이 사용합니다.)
하지만 동일 서브넷의 Windows 들은 이상 없습니다.

결론은 Direct cable로 연결된 스팸을 필터링 하는 서버의 문제... (제품명 밝힐 수 없음)
문제 해결 완료 했습니다.

약 30분간의 급박했던 시간이 지났습니다.
서버 어드민 분들과 전 커피 한잔을 했습니다.

불과 6개월전이 생각나네요.
당황 황당으로 뛰어다니던... 철없던 신입 사원 시절...
(지금도 신입이지만...)
이제 어느정도 단련이 됐건만... 3년은 늙어 버린 기분입니다...ㅜㅜ

그래도 뿌듯합니다.
역시 기술 지원 엔지니어는 해 먹을게 못됩니다...
(하지만 재미있다는거...^^v)

PS. 이런 경우를 대비하여 MX Record의 가중치를 이용한 설계를 추천합니다.
물론 두 경우 모두 일장 일단이 있습니다. 하지만 스팸 필터 서버를 이중화 하지 못하는 상황이라면 MX Record를 사용하는 방안도 좋은 해결 책이 될 수 있을꺼 같습니다.