Создание заглушек и реорганизация дискового пространства в базе данных Exchange


Дата публикации исходной статьи: вторник, 28 августа 2012 г.

В пакете обновления SP2 RU1 для Exchange 2010 содержится исправление ошибки, относящейся к реорганизации дискового пространства базы данных. С этой проблемой связана некоторая неопределенность, поэтому я хотел бы пояснить, в чем состоит сама проблема, что реализовано в исправлении, а также обсудить возможности применения сторонних заглушек (установка заглушки подразумевает замену сообщения объектом указателя и сохранение исходной версии во внешнем репозитории).

Суть проблемы и содержание исправления

Мы обнаружили, что в некоторых сценариях в Exchange 2010 при необратимом удалении элементов (с очисткой элемента из хранилища) не выполнялась реорганизация дискового пространства. К их числу относятся сценарии архивации с массовым удалением элементов в установленную дату, сценарии установки заглушек с удалением вложений и другие, в том числе сценарии работы с почтовыми ящиками журналов и репликации общедоступных папок. Эта проблема сопряжена с удалением элементов и затрагивает многих пользователей.

Приложение Exchange 2010 обычно пытается выполнить очистку строки удаленного элемента через несколько минут после его необратимого удаления. Тем не менее, если какой-либо объект по-прежнему использует открытые ссылки на этот элемент, очистка завершается сбоем. Например, сбой очистки может происходить в следующих случаях: система индексирования контента выполняет индексирование сообщения, сообщение считывается отдельным клиентом и т. д. Сбой происходит при наличии открытых ссылок. До установки исправления в случае такого сбоя очистки возникала утечка дискового пространства, которую можно было устранить только путем перемещения почтового ящика.

Как выяснилось, подобные открытые ссылки на удаленные сообщения особенно часто возникают в почтовых ящиках журналов, а также при использовании стороннего программного обеспечения архивации. Большинство ошибок такого рода возникало у пользователей, использующих эти компоненты. Однако с технической точки зрения открытую ссылку, мешающую очистке элемента, может использовать любой клиент.

В исправлении, включенном в пакет обновления SP2 RU1, эта ошибка была исправлена. Для этого мы добавили механизм периодического повторения очистки в случае сбоя из-за открытых ссылок.

Исправлена ли проблема с заглушками?

При установке заглушки стороннее программное обеспечение архивации преобразует большое сообщение в маленький элемент — заглушку. Обычно для этого удаляются вложения и сокращается текст самого сообщения.

При установке заглушек также возможен аналогичный сбой, связанный с попытками очистки удаленных сообщений, для которых существуют открытые ссылки. В остальном данная проблема не затрагивает механизм заглушек.

Почему при установке заглушек объем высвобождаемого пространства меньше ожидаемого?

Структура банка сообщений Exchange постоянно модифицируется, однако даже в версиях Exchange 2003 и 2007 при установке заглушек фактический размер базы данных значительно превышал ожидаемый в связи с увеличением размеров почтовых ящиков. Это связано преимущественно со служебными данными двух типов.

Первый — свойства, которые не учитываются при определении размера сообщения. В приложении Outlook отображаемый размер сообщения не всегда соответствует общему объему хранящихся в Exchange данных для этого сообщения. Некоторые свойства относятся к пользователю и не включаются в суммарный размер сообщения. Это могут быть как общедоступные свойства, например, PR_URL_NAME, так и другие недоступные клиенту внутренние свойства.

Второй тип служебных данных связан с фрагментацией страниц. Размер одной страницы базы данных постепенно увеличился с 4 КБ в Exchange 2003 до 8 КБ в Exchange 2007 и 32 КБ в Exchange 2010. Записи базы данных размещаются на страницах и, в зависимости от эффективности их размещения, некоторый объем пространства может оставаться незадействованным. Это так называемая фрагментация страниц, в результате которой в базе данных получается свободное пространство, недоступное для реорганизации. Увеличение размеров страниц в последних версиях Exchange позволяет упростить размещение нескольких небольших элементов на одной странице. Соответственно, степень фрагментации уменьшается, однако полностью искоренить это явление по-прежнему невозможно.

Объем служебных данных обычно не сильно зависит от размера сообщения и будет примерно одинаковым как для небольших, так и для крупных элементов. Соответственно, при наличии большого числа маленьких элементов в базе суммарный объем служебных данных может существенно возрастать.

В качестве примера рассмотрим базу данных, которая заполнена элементами суммарным размером 1 МБ с общим объемом служебных данных 1 КБ. В этом случае доля служебных данных в базе составит около 0,09%. Допустим, вы заменили все сообщения в базе заглушками, уменьшив их суммарный размер до 4 КБ. Объем служебных данных не изменится (1 КБ), а их доля увеличится до 25% от размера базы данных. Однажды при работе с базой Exchange 2003 с большим числом маленьких элементов, которые были полностью заменены на заглушки, я столкнулся с долей служебных данных в 70%.

Как обстоит ситуация в Exchange 2010?

В Exchange 2010 на реорганизацию дискового пространства при установке заглушек дополнительно влияет архитектура базы данных.

В Exchange 2010 значительно увеличена производительность подсистемы ввода-вывода базы данных. Во многом этого удалось добиться за счет исключения процесса оперативной дефрагментации, который каждую ночь осуществлял обход базы данных и перемещение элементов для оптимизации пространства. В Exchange 2010 для снижения числа операций ввода-вывода мы ориентируемся на хранение контента почтовых ящиков на нефрагментированных страницах, даже если при этом образуется определенное неиспользуемое пространство. Другими словами, механизм реорганизации дискового пространства Exchange 2010 не настроен на столь агрессивную обработку в случае уменьшения размеров сообщений, как раньше. Это изменение в первую очередь направлено на увеличение производительности подсистемы ввода-вывода. Дополнительные сведения об изменениях системы обслуживания см. в статье, посвященной обслуживанию баз данных в Exchange 2010.

Значит ли это, что вам не удастся сэкономить место при помощи заглушек? Необязательно. При установке заглушек обычно удаляются вложения, что, само собой, ведет к высвобождению пространства. Несмотря на архитектурные особенности, приложение Exchange 2010 высвобождает пространство даже при замене заглушками сообщений без вложений.

Однако поскольку такая особенность не предусмотрена архитектурой Exchange 2010, мы не можем точно предсказать объем высвобождаемого пространства при архивации с помощью заглушек. Любые предположения в этой области могут основываться лишь на вашем собственном опыте работы с используемым решением архивации.

Другими словами, мы не можем заявить какие-либо характеристики реорганизации дискового пространства при уменьшении размеров свойств элементов. Если это и вовсе не позволяет высвободить пространство, стоит рассматривать такие результаты как архитектурную особенность Exchange 2010. По любым вопросам, связанным с проблемами реорганизации пространства в базах данных при использовании сторонних продуктов вам лучше обратиться к соответствующему поставщику.

Заключение

В пакет обновления SP2 RU1 для Exchange 2010 включено исправление, позволяющее пользователям выполнять операции архивации, установку заглушек и аналогичные действия за счет гарантированной очистки необратимо удаленных элементов. Однако прогнозировать какие-либо значения высвобождаемого при этом пространства вы можете исключительно полагаясь на собственный опыт или рекомендации поставщика ПО архивации. Для адекватной реорганизации данных Exchange мы призываем следовать при подготовке системы хранения нашим опубликованным рекомендациям, в частности, использовать вместо сторонних решений архивации почтовые ящики крупного размера и наши средства.

Билл Лонг

Это локализованная запись блога. Исходная статья находится по адресу Exchange, Stubbing, and Database Space Reclamation


Comments (0)

Skip to main content