Exchange, 스텁 및 데이터베이스 공간 다시 확보
최초 문서 게시일: 2012년 8월 28일 화요일
Exchange 2010 SP2 RU1에는 데이터베이스 공간 다시 확보와 관련한 문제를 해결하는 픽스가 포함되어 있었습니다. 이 문제와 관련하여 혼동하는 사용자가 있는 듯하여 해당 문제와 픽스, 그리고 데이터베이스 내에서 타사 제품 스텁 항목을 사용하는 경우의 예상 상황에 대해 설명합니다. 스텁은 메시지를 포인터 개체로 바꾸고 원본 버전을 외부 저장소에 저장하는 프로세스입니다.
버그 및 픽스
Exchange 2010에서는 항목을 영구 삭제(저장소에서 항목을 제거함)하는 여러 시나리오에서 데이터베이스 공간이 다시 확보되지 않는 문제가 있었습니다. 여기에는 항목을 날짜 기준으로 대량 삭제하는 보관 시나리오, 첨부 파일을 삭제하는 스텁 시나리오, 그리고 저널링 사서함/공용 폴더 복제 등의 기타 시나리오가 포함됩니다. 이 문제는 많은 고객에게 영향을 주었으며, 항목 삭제 작동 방식과 관련하여 발생했습니다.
Exchange 2010은 보통 항목을 영구 삭제하고 몇 분 이내에 삭제된 항목에 해당하는 행 정리를 시도합니다. 그러나 해당 항목에 대해 참조를 열어 둔 항목이 아직 있으면 정리는 실패합니다. 예를 들어 정리가 실패할 수 있는 시나리오로는 콘텐츠 인덱싱에서 메시지를 인덱싱하는 경우, 다른 클라이언트가 메시지를 읽고 있는 경우 등이 있습니다. 이처럼 다른 항목이 열어 둔 참조가 있으면 정리가 실패합니다. 픽스가 제공되기 전에는 이 시점에서 정리가 실패한 경우 해당 공간이 실제로 누수되어 사서함을 이동하지 않으면 복구할 수 없었습니다.
사서함을 저널링할 때나 타사 보관 소프트웨어를 사용할 때는 삭제된 항목에 대해 참조가 남아 있는 경우가 많으므로 이 버그를 경험한 대부분의 고객은 해당 문제를 저널링이나 타사 소프트웨어 중 하나와 연관이 있다고 생각했습니다. 그러나 기술적으로는 어떤 클라이언트에서나 참조를 열어 두어 항목 정리를 차단할 가능성이 있습니다.
SP2 RU1에 포함된 픽스는 정리 다시 시도 메커니즘을 추가하여 이 문제를 해결합니다. 특정 항목에서 참조를 계속 열어 두어서 정리가 실패하면 저장소에서 정리가 성공할 때까지 주기적으로 정리를 다시 시도합니다.
스텁 문제 해결 여부
스텁이란 타사 보관 제품이 큰 메시지를 가져와 더 작은 항목(스텁)으로 만드는 프로세스를 말합니다. 일반적으로 스텁은 첨부 파일을 삭제하고 메시지 본문을 더 작게 수정하는 방식으로 수행됩니다.
스텁은 첨부 파일을 삭제한다는 측면에서 이 버그의 영향을 받을 수 있습니다. 참조가 열려 있으면 삭제된 첨부 파일의 정리가 실패할 수 있기 때문입니다. 그러나 이 문제를 제외하면 해당 버그는 스텁과는 관련이 없습니다.
스텁을 수행해도 예상만큼 공간이 확보되지 않는 경우
Exchange 정보 저장소는 지난 몇 년간 크게 변경되었지만, 스텁을 수행하면 사서함 크기를 추가할 때 데이터베이스가 기대했던 것보다 훨씬 커지는 현상은 동일하게 발생합니다(Exchange 2003과 2007에서도 마찬가지임). 이러한 현상은 주로 두 가지 유형의 오버헤드로 인한 것입니다.
첫 번째 오버헤드 유형은 메시지 크기에 합산되지 않는 속성입니다. Outlook에서 메시지 크기를 확인할 때 표시되는 크기는 Exchange에서 해당 메시지에 대해 저장하는 모든 데이터의 총 크기가 아닙니다. 즉, 사용자에게 표시되는 메시지 크기에 합산 및 반영되지 않는 특정 속성도 저장됩니다. 여기에는 PR_URL_NAME과 같이 공개적으로 문서화된 속성 또는 클라이언트가 액세스할 수 없는 기타 내부 속성이 포함될 수 있습니다.
두 번째 유형의 오버헤드는 페이지 조각화입니다. 데이터베이스 페이지 크기는 Exchange 2003에서는 4k, Exchange 2007에서는 8k, Exchange 2010에서는 32k로 계속 바뀌었습니다. 데이터베이스의 각 레코드를 이러한 페이지에 정렬해야 하는데 해당 정렬 작업의 효율성에 따라 페이지에 일부 공간이 남아 있을 수 있습니다. 이러한 현상을 페이지 조각화라고 하며, 페이지 조각화로 인해 데이터베이스 유지 관리를 통해서는 다시 확보할 수 없는 빈 공간이 생깁니다. 최근 Exchange 버전에서는 페이지 크기가 커져서 여러 개의 작은 항목을 단일 페이지에 정렬하기가 더 쉬워졌으며 이로 인해 조각화 발생 가능성이 낮아지기는 했지만 어느 정도의 조각화는 항상 발생합니다.
오버헤드의 정도는 대개 메시지 간에 변경되지 않습니다. 즉, 메시지 크기가 작든 크든 비슷한 오버헤드가 발생합니다. 따라서 데이터베이스에 작은 항목을 채우면 오버헤드가 훨씬 뚜렷하게 나타납니다.
예를 들어 모두 크기가 1MB인 항목(각각 오버헤드가 1k)으로 데이터베이스를 채우는 시나리오를 가정해 보겠습니다. 이 경우 데이터베이스의 오버헤드는 약 0.09%입니다. 이제 데이터베이스의 모든 항목을 스텁하여 크기를 4k로 줄인다고 가정합니다. 그러면 항목 하나의 오버헤드에 불과한 1k가 데이터베이스의 25%를 차지하므로 훨씬 크게 느껴집니다. 개인적으로도 작은 항목으로 채운 Exchange 2003 데이터베이스의 전체 항목을 스텁한 결과 오버헤드가 70%에 육박한 적도 있었습니다.
Exchange 2010의 경우
Exchange 2010에는 스텁을 통한 공간 다시 확보에 영향을 줄 수 있는 추가적인 요인이 있습니다. 해당 요인은 데이터베이스 디자인 변경입니다.
Exchange 2010에서는 데이터베이스 IOPS를 줄이기 위해 많은 사항이 변경되었습니다. 그 중에서 중요한 요소 중 하나는 매일 밤 데이터베이스 전체를 확인하고 공간 최적화를 위해 항목을 이동하는 기존의 온라인 조각 모음 프로세스가 제거된 것입니다. Exchange 2010에서는 IO를 줄이기 위해 연속 페이지에 사서함 콘텐츠를 저장하는 데 주력하는데, 이로 인해 사용되지 않는 공간이 생길 수 있습니다. 다시 말해서 Exchange 2010은 메시지가 갑자기 축소될 때 단순히 공간을 다시 확보하지 않습니다. 이 시나리오는 IO를 개선하기 위해 아키텍처에서 최소한으로만 수행됩니다. 유지 관리 변경 내용에 대한 자세한 내용은 Exchange 2010의 데이터베이스 유지 관리를 참조하십시오.
그러면 스텁을 통해 공간을 절약할 수는 없는 것일까요? 그렇지는 않습니다. 스텁 제품은 보통 첨부 파일을 삭제하므로 해당 공간은 확보할 수 있습니다. 그리고 Exchange 2010에서도 의도한 바는 아니지만 첨부 파일이 없는 항목을 스텁할 때도 공간이 어느 정도 확보되는 것으로 나타났습니다.
그러나 이러한 동작은 Exchange 2010의 원래 디자인이 아니기 때문에 스텁 보관을 사용하는 경우 확보할 수 있는 공간의 양은 예상하기가 어렵습니다. 이러한 예상치는 직접 테스트를 수행하거나 보관 소프트웨어 공급업체가 제공하는 데이터를 통해 확인해야 합니다.
바꾸어 말하자면, 항목을 수정하여 해당 속성을 이전보다 작게 만들 때 공간이 다시 확보된다고 보장할 수는 없습니다. 항목을 수정하여 더 작게 만드는 경우 공간이 전혀 확보되지 않는다면, Exchange 2010은 원래 그렇다고 말할 수밖에 없습니다. 다른 모든 경우와 마찬가지로, 타사 제품을 사용할 때의 데이터베이스 공간 문제와 관련한 지원이 필요한 경우 Exchange가 정상적으로 작동한다면 Microsoft에서는 해당 타사에 지원을 요청할 것을 안내할 수 있습니다.
결론
Exchange 2010 SP2 RU1에는 영구 삭제된 항목이 안정적으로 정리되도록 함으로써 고객이 모든 유형의 보관 또는 스텁을 수행할 수 있도록 하는 픽스가 포함되었습니다. 그러나 스텁 자체를 통해 절약할 수 있을 것으로 예상되는 디스크 공간의 양은 고객 및 보관 소프트웨어 공급업체가 직접 확인해야 합니다. 저장소를 구축할 때는 Microsoft에서 게시한 지침(타사 보관 솔루션을 사용하지 않아도 되도록 큰 사서함을 사용하라는 지침 포함)을 따르고 관련 도구를 사용하여 Exchange 데이터용으로 적절한 공간을 마련하는 것이 좋습니다.
Bill Long
이 문서는 번역된 블로그 게시물입니다. 원본 문서는 Exchange, Stubbing, and Database Space Reclamation을 참조하십시오.