通过

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

  • 项目

Исходная статья опубликована в среду, 9 ноября 2011 г.

Недавно я общался с одним из руководителей программы возможностей поддержки, Нино Биличем (Nino Bilic), и он упомянул об одной настораживающей вещи  — самой распространенной причиной, по которой наши клиенты уровня Premier заявляли о критическом сбое в Exchange 2010, было отключение баз данных почтовых ящиков из-за нехватки дискового пространства на LUN журнала транзакций. 

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

Планирование загрузки 101

Чтобы правильно определить размер LUN журнала транзакций, необходимо знать ряд параметров среды.

  1. Сколько почтовых ящиков будет размещаться в базе данных?
  2. Каков режим обмена сообщениями для почтовых ящиков в базе данных?
  3. Каков средний размер сообщения?
  4. Каков средний размер ящика?
  5. Сколько почтовых ящиков перемещается каждый день?
  6. Какое используется решение резервного копирования и восстановления?
  7. Должно ли решение учитывать какие-либо другие сценарии отказа, например сетевые сбои?

Для данного обсуждения давайте предположим, что каждая база данных вмещает 250 почтовых ящиков. Каждый почтовый ящик отправляет/получает 150 сообщений в день, а средний размер сообщения составляет 100 КБ. Благодаря таблице в статье Обзор базы данных почтовых ящиков и объема журнала мы знаем, что в режиме со 150 сообщениями и средним размером сообщения в 75 КБ порождается 30 записей журнала транзакций в день (24 часа). Поскольку рассматриваемый нами размер сообщения больше 75 КБ, это необходимо учитывать при оценке количества записей журнала транзакций для каждого почтового ящика. В руководстве сказано:

Если средний размер сообщения удваивается до 150 КБ, число записей журнала, порождаемых для каждого почтового ящика, увеличивается с коэффициентом 1,9. Это число соответствует процентной части базы данных, где хранятся приложения и таблицы сообщений (тела сообщений и приложения).

Следовательно, влияние среднего размера сообщения в 100 КБ можно определить по следующей формуле:

150 / 1,9 = [средний размер сообщения в профиле] / x

x = (100 * 1,9) / 150

x = 1,266666666666667 ~ 1,27

Таким образом, если размер сообщения на 25 КБ больше базового, число записей журнала транзакций, порождаемых в день для одного почтового ящика, увеличивается с коэффициентом 1,27. Следовательно, 30 записей журнала транзакций * 1,27 = 39 записей журнала транзакций в день для одного почтового ящика. Это значит, что для базы данных из 250 почтовых ящиков будет порождаться 39 * 250 = 9750 записей журнала транзакций в день на одну базу данных.

При перемещении почтовых ящиков также создаются записи журнала транзакций. Каждый почтовый ящик, перемещенный в целевую базу данных, порождает записи журнала (в целевой, а не в исходной базе), количество которых примерно равно размеру почтового ящика (включая содержимое папок "Элементы для восстановления"). Например, при перемещении 1% почтовых ящиков в день в базу данных каждый день будет перемещаться примерно 2,5 почтовых ящиков. Если каждый почтовый ящик имеет средний размер 5,4 ГБ (включая хранящиеся в течение 14 дней удаленные элементы при включенном режиме Single Item Recovery), то 2,5 * 5,4 ГБ/ 1024 = 13888 записей о перемещении почтового ящика в журнале транзакций в день для одной базы данных.

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

  Усечение журнала транзакций Рекомендуемая защита от сбоев с помощью резервного копирования
Ежедневное полное резервное копирование Ежедневно 3 дня
Еженедельное полное резервное копирование / Ежедневное инкрементное резервное копирование Ежедневно 3 дня
Еженедельное полное резервное копирование / Ежедневное разностное резервное копирование Еженедельно 7 дней
Полное резервное копирование 2 раза в месяц / Ежедневное инкрементное резервное копирование Ежедневно 3 дня
Встроенная защита данных Exchange Журналы больше не требуются 3 дня

Разумеется, существуют другие сценарии, которые может потребоваться учитывать. Например, при развертывании группы обеспечения доступности баз данных, размещенной в двух центрах обработки данных, усечение журнала будет происходить, только если сетевое подключение между двумя центрами исправно и копии базы данных работоспособны. Если известно, что на восстановление работы подключения по глобальной сети может уйти 5 дней, следует изменить защиту с помощью резервного копирования в соответствии с этим.

Для нашей ситуации предположим, что нам нужно обеспечить защищенную работу в течение 3 дней, независимо от сбоев усечения журнала. Это означает, что нам нужно 9750 / 1024 * 3 = 28,5 ГБ дискового пространства для записей журнала транзакций, порождаемых почтовыми ящиками.

Кроме того, необходимо учитывать объем дискового пространства, необходимого для событий перемещения почтовых ящиков на целую неделю: 13 888 / 1014 * 7 дней = 94,9 ГБ дискового пространства для операций перемещения почтовых ящиков.

Таким образом, для каждой базы данных требуется 123 ГБ дискового пространства для записей журнала транзакций. Также следует включить дополнительное пространство на случай непредвиденных ситуаций: 123 ГБ * 1,2 = 148 ГБ дискового пространства для записей журнала транзакций.

При развертывании выделенного LUN для журнала транзакций мы не будем выделять LUN размером 150 ГБ, поскольку это означало бы, что мы можем израсходовать все доступное дисковое пространство в случае сбоев резервного копирования и интенсивного перемещения почтовых ящиков. Обычно следует выделять LUN такого размера, чтобы использовалось только 80 % дискового пространства. Для этого применяется следующая формула:

Объем LUN = [прогнозируемое использование дискового пространства] / (1 – [желаемый процент свободного пространства])

Объем LUN = 148 ГБ / (1 – 0,2) = 148 ГБ / 0,8 = 185 ГБ для LUN для размещения выделенного журнала транзакций

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

Как предотвратить израсходование всего дискового пространства для журнала транзакций?

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

  1. Дисковое пространство LUN для журнала транзакций. Задайте несколько пороговых значений и различные механизмы предупреждений. Первое предупреждение не должно сообщать о том, что 90 % дискового пространства уже израсходовано. Если известны базовые характеристики порождения журнала, можно задать пороговое значение, чтобы предупреждение выдавалось при превышении порога, например, на 20 %.
  2. Отслеживание успешного завершения резервного копирования (если встроенная защита данных Exchange не используется). Первое указание на сбой резервного копирования не должно появляться тогда, когда дисковое пространство уже закончилось.
  3. Отслеживание событий усечения в журнале приложений.
  4. Отслеживание исправности реплики копии базы данных. 

Что делать, если возникает необъяснимое увеличение журнала транзакций?

Мой друг, Майк Лагейз (Mike Lagase), написал отличную статью о том, как разобраться с этой проблемой- https://blogs.technet.com/b/mikelag/archive/2009/07/12/troubleshooting-store-log-database-growth-issues.aspx (имейте в виду, что эта статья писалась для Exchange 2007, поэтому некоторые средства и рекомендации могут оказаться неприменимы к Exchange 2010). Помимо указанных Майком действий, в Exchange 2010 можно выполнить следующие действия, чтобы определить причины необъяснимого увеличения журнала транзакций (спасибо Тодду Лютинену (Todd Luttinen) за составление этого списка):

  1. Можно воспользоваться командлетом, собирающим статистику по использованию хранилища (get-StoreUsageStatistics, DigestCategory = ‘LogBytes’), чтобы определить почтовые ящики, которые порождают очень большие журналы. Обратите внимание, что это не всегда работает, когда журналы порождаются не владельцем почтового ящика или когда операция выполняется от имени клиента (как CopyOnWrite) и не ведет к порождению записей журнала системными службами (указывается в Событии 9826). Эта статистика дает сводку по последним 10 минутам активности для почтовых ящиков, порождающих журналы наибольшего объема (до 6 выборок за последний час). Далее показано, как использовать статистику использования хранилища, чтобы найти почтовый ящик, породивший за последний час журнал самого большого размера.

    [PS] C:\>$stats = Get-StoreUsageStatistics –Database <Database Name>
    [PS] C:\>$stats | ? {$_.DigestCategory -eq 'LogBytes'} | group MailboxGuid |sort count -Descending | Select -first 1 -ExpandProperty Group | sort SampleTime | ft -a MailboxGuid,Sample*,Log*

    Guid почтового ящика ИД выборки Время выборки Число записей журнала Объем записей журнала
    c007c87a-e030-4414-b741-9cf61e88b9de 5 7/11/2011 16:25:05 237 274163
    c007c87a-e030-4414-b741-9cf61e88b9de 4 7/11/2011 16:35:05 451 387362
    c007c87a-e030-4414-b741-9cf61e88b9de 3 7/11/2011 16:45:06 483 144999
    c007c87a-e030-4414-b741-9cf61e88b9de 2 7/11/2011 16:55:06 734 293433
    c007c87a-e030-4414-b741-9cf61e88b9de 1 7/11/2011 17:05:06 933 411485
    c007c87a-e030-4414-b741-9cf61e88b9de 0 7/11/2011 17:15:06 247 209987

  2. Также существуют события приложения, порождаемые для клиентов администрирования (Событие 9826). Такая статистика отражает 2 часа активности.

    Starting from <date/time> service <name> has performed this activity on the server:
    RPC Operations: 24168.
    Database Pages Read: 1329 (of which 629 pages preread).
    Database Pages Updated: 12418 (of which 11555 pages reupdated).
    Database Log Records Generated: 13906.
    Database Log Records Bytes Generated: 660331.
    Time in Server: 19142 ms.
    Time in User Mode: 6100 ms.
    Time in Kernel Mode: 63 ms.

  3. Для определения того, какой тип клиента вызывает увеличение журнала, можно использовать счетчик системного монитора "Клиент MSExchangeIS(*)\Байтов записано в журнал JET/с".

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

Росс Смит IV (Ross Smith IV)
старший руководитель программы
программа улучшения качества программного обеспечения Exchange

Это локализованная запись блога. Исходная статья доступна по адресу: Capacity Planning – Yes Transaction Log Space is Critical to Keeping your Databases Healthy and Mounted