За последние несколько месяцев было много разговоров о том, что такое фоновое обслуживание баз данных и почему оно важно для баз данных Exchange 2010. Надеюсь, эта статья ответит на подобные вопросы.
Какие задачи обслуживания требуется выполнять для базы данных?
Для баз данных Exchange необходимо регулярно выполнять следующие задачи обслуживания:
Сжатие базы данных
Основная цель сжатия базы данных — освободить неиспользуемое пространство в файле базы данных (однако следует отметить, что при этом неиспользуемое пространство не возвращается файловой системе ). Смысл этой операции — освободить страницы в базе данных за счет сжатия записей до минимально возможного числа страниц, тем самым сократив необходимое количество операций ввода-вывода. Компонент ESE реализует эту операцию, беря метаданные базы данные, т. е. информацию в базе данных, описывающую таблицы, и для каждой таблицы просматривает каждую страницу и пытается переместить записи в логически упорядоченные страницы.
Обеспечение экономичности структуры файла базы данных важно по нескольким причинам, в том числе следующим:
- уменьшение времени, связанного с резервным копированием файла базы данных;
- поддержка предсказуемого размера файла базы данных, что важно для процедуры определения размера сервера или хранилища.
До Exchange 2010 операции сжатия базы данных выполнялись в течение периода обслуживания . Этот процесс генерировал случайные операции ввода-вывода при проходе по базе данных и изменении порядка записей на страницах. Этот процесс был буквально слишком хорош в предыдущих версиях — за счет освобождения страниц базы данных и изменения порядка записей страницы всегда были упорядочены случайным образом. Наряду с архитектурой схемы хранилища это означало, что любой запрос на извлечение набора данных (например, загрузка элементов из папки) всегда приводил к возникновению случайных операций ввода-вывода.
В Exchange 2010 сжатие базы данных было переработано, чтобы смежность имела больший приоритет, чем сжатие. Кроме того, сжатие базы данных было удалено из периода обслуживания и теперь это фоновый процесс, который выполняется постоянно .
Дефрагментация базы данных
Дефрагментация базы данных — это новая возможность в Exchange 2010, которую также называют дефрагментацией дерева OLD v2 и B+. Ее цель — сжать, а также дефрагментировать (расположить последовательно) таблицы базы данных , которые были отмечены как последовательные. Дефрагментация базы данных важно для обеспечения эффективного использования дисковых ресурсов со временем (сделать операции ввода-вывода более последовательными, а не случайными), а также обеспечения компактности таблиц, отмеченных как последовательные.
Процесс дефрагментации базы данных можно представить как монитор, отслеживающий другие страничные операции базы данных, чтобы определить, нужно ли что-то сделать. Этот процесс отслеживает все таблицы для свободных страниц, а если таблица достигает порогового значения со слишком высоким процентом свободных страниц от общего числа страниц дерева B+, она возвращает свободные страницы корневой таблице. Процесс также обеспечивает смежность в табличном наборе с помощью подсказок о последовательности данных (таблица создана с известным последовательным шаблоном использования). Если дефрагментация данных обнаруживает операцию сканирования или предварительного чтения в последовательной таблице, а записи не хранятся на последовательных страницах в таблице, процесс выполнит дефрагментацию раздела таблицы, переместив все затронутые страницы в обновленное дерево B+. Вы можете использовать счетчики производительности (описывается в ), чтобы узнать, как мало операций выполняется при дефрагментации после достижения стабильного состояния.
Дефрагментация базы данных — это фоновый процесс, который анализирует непрерывность базы данных при выполнении операций, а затем инициирует асинхронные операции. Дефрагментация базы данных запускается в двух ситуациях:
- Максимальное количество незавершенных задач — не позволяет процессу дефрагментации выполнять слишком много операций при первом проходе, если база данных была значительно изменена.
- Задержка 100 мс — если система перегружена, дефрагментация базы данных начнет откладывать задачи дефрагментации. Эти операции будут выполнены при следующем проходе этого операционного шаблона. Ничто не запоминает, какая операция была отложена, и не возвращается к ней после освобождения ресурсов.
Проверка контрольной суммы базы данных
Проверка контрольной суммы базы данных (которую также называют проверкой базы данных ) — это процесс, при котором база данных читается крупными блоками, а для каждой страницы проверяется контрольная сумма (проверка физического повреждения страницы). Основная цель проверки контрольной суммы — обнаружить физические повреждение и потерянные данные , которые нельзя обнаружить транзакционными операциями (просроченные страницы).
В Exchange 2007 RTM и во всех предыдущих версиях, операции проверки контрольной суммы выполнялись во время резервного копирования. Это представляло проблему для реплицированных баз данных, так как резервная копия создавалась только для копии, контрольная сумма которой была проверена. В ситуации, когда была архивирована пассивная копия, это означало, что контрольная сумма активной копии не проверялась. Поэтому в Exchange 2007 SP1 мы ввели дополнительную задачу обслуживания, контрольная сумма обслуживания (дополнительные сведения см. в разделе ).
В Exchange 2010 при сканировании базы данных проверяется контрольная сумма базы данных и выполняются операции после сбоя хранилища Exchange 2010. Пространство может быть занято из-за сбоев системы, а процедура сканирования базы данных находит и восстанавливает потерянное пространство. При проверке контрольной суммы базы данных считывается примерно 5 МБ в секунду для каждой активно сканируемой базы данных (для активных и пассивных копий) с помощью операций ввода-вывода по 256 КБ. Операции ввода-вывода на 100% последовательны. Система в Exchange 2010 создана с предположением, что каждая база данных полностью сканируется один раз в семь дней.
Если на сканирование уходит больше семи дней, в журнал приложений заносится событие:
Код события: 733
Тип события: информация
Источник события: ESE
Описание: банк данных (15964) MDB01: задача проверки контрольной суммы обслуживания базы данных НЕ будет завершена вовремя для базы данных "d:\mdb\mdb01.edb". Это проход начался 10.11.2011 и выполнялся 604800 секунд (больше 7 дней).
Если на завершение проверки активной копии базы данных уйдет больше семи дней, следующая запись будет добавлена в журнал приложений после завершения проверки:
Код события: 735
Тип события: информация
Источник события: ESE
Описание: хранилище информации (15964) MDB01: завершен полный проход обслуживания базы данных "d:\mdb\mdb01.edb". Проход начался 10.11.2011 и выполнялся 777600 секунд. Эта задача обслуживания базы данных превысила пороговое значение в 7 дней для завершения обслуживания. Следует выполнить одно или несколько следующих действий: увеличьте производительность или пропускную способность операций ввода-вывода тома, на котором расположена база данных, сократите размер базы данных и число операций обслуживания, не связанных с базой данных.
Кроме того, предупреждение также будет записано в журнал приложений, если на выполнение операции потребуется более 7 дней.
В Exchange 2010 есть два режима для проверки контрольной суммы для активных копий базы данных:
- Фоновое выполнение 24 часа в сутки, 7 дней в неделю — этот механизм используется по умолчанию. Его следует применять для всех баз данных, особенно для тех, размер которых превышает 1 ТБ. Exchange проверяет базу данных не чаще одного раза в день. Эта операция чтения на 100% последовательна (что упрощает ее выполнение на диске) и уравнивает скорость сканирования до 5 МБ/с в большинстве систем. Процесс сканирования выполняется в одном потоке и регулируется задержкой операций ввода-вывода. Чем больше задержка, тем больше проверка контрольной суммы замедляет систему, так как она дольше ждет завершения последнего задания перед переходом к другому набору страниц (одновременно читаются 8 страниц).
- Выполнение в запланированном процессе обслуживания базы данных почтовых ящиков — при выборе этого параметра проверка контрольной суммы базы данных выполняется последней. Вы можете настроить длительность ее выполнения, изменив расписание обслуживания базы данных почтовых ящиков . Этот вариант следует использовать только с базами данных меньше 1 терабайта (ТБ), для полного сканирования которых требуется меньше времени.
Независимо от размера базы данных рекомендуется использовать механизм по умолчанию и не настраивать операции проверки контрольной суммы для активной базы данных как запланированный процесс (т. е. не настраивайте их как процесс в периоде обслуживания).
Для пассивных копий баз данных проверка контрольной суммы может осуществляться во время выполнения непрерывно в фоновом режиме.
Исправление страниц
Исправление страниц — это процесс, при котором поврежденные страницы заменяются работоспособными копиями . Как было сказано ранее, обнаружение поврежденных страниц — это часть проверки контрольной суммы (кроме того, поврежденные страницы также проверяются во время выполнения, если страница хранится в кэше базы данных). Операция исправления страниц выполняется только для копий базы данных высокой доступности. Способ восстановления поврежденной страницы зависит от того, является ли копия базы данных высокой доступности активной или пассивной.
Процесс исправления страниц
| Для активных копий базы данных | Для пассивных копий базы данных |
|
|
Обнуление страниц
Обнуление страниц базы данных — это процесс, при котором удаленные страницы в базе данных перезаписываются шаблоном (нулями) для обеспечения безопасности , что значительно усложняет обнаружение данных.
В Exchange 2007 RTM и всех предыдущих версиях операции обнуления страниц выполнялись в процессе потокового резервного копирования. Кроме того, из-за этого они не записывались в журнал (т.е. обнуление страниц не приводило к созданию файлов журнала). Это представляло проблему для реплицированных баз данных, так как в пассивных копиях страницы никогда не обнулялись, а в пассивных копиях обнуление страниц происходило только при потоковом резервном копировании. Поэтому в Exchange 2007 SP1 мы ввели дополнительную задачу обслуживания, обнуление страниц базы данных во время проверки контрольной суммы (дополнительные сведения см. в разделе ). При активации этой задачи обнуление страниц выполняется в период обслуживания, изменения при этом записываются в журнал и реплицируются в пассивные копии.
В реализации Exchange 2007 SP1 между удалением и обнулением страницы есть значительная задержка, связанная с тем, что обнуление выполняется в течение запланированного периода обслуживания. Поэтому в Exchange 2010 SP1 задача обнуления страниц теперь реализуется постоянно во время выполнения, при этом страницы обнуляются во время транзакции при необратимом удалении .
Кроме того, страницы базы данных также могут быть обнулены в процессе проверки контрольной суммы. В этом случае обрабатываются следующие страницы:
- удаленные записи, которые не удалось очистить во время выполнения из-за остановленных задач (если система перегружена) или сбоя хранилища перед обнулением данных;
- удаленные таблицы и дополнительные индексы — при удалении этих элементов их содержимое не очищается активно, поэтому процедура проверки контрольной суммы обнаруживает, что эти страницы не принадлежат допустимым объектам, и очищает их.
Дополнительные сведения об обнулении страниц в Exchange 2010 см. в разделе Основные сведения об обнулении страниц в Exchange 2010 .
Почему эти задачи просто не выполняются в запланированный период обслуживания?
Использование запланированного периода обслуживания для обнуления страниц, дефрагментации и сжатия базы данных и проверки контрольной суммы вызывает серьезные проблемы, в том числе следующие:
- Применение запланированных операций обслуживания усложняет круглосуточное управление центрами обработки данных, в которых размещены почтовые ящики из разных часовых поясов, а период обслуживания небольшой или вообще отсутствует. В предыдущих версиях у сжатия базы данных не было механизмов регулирования, а так как операции ввода-вывода в основном случайные, это может привести к ухудшению производительности.
- У баз данных почтовых ящиков Exchange 2010, развернутых на более низком уровне хранилища (например, 7.2K SATA/SAS), эффективная пропускная способность операций ввода-вывода компонента ESE для выполнения задач периода обслуживания сокращена. Это вызывает проблемы, так как это значит, что задержки операций ввода-вывода увеличатся в период обслуживания, что не позволит завершить операции обслуживания вовремя.
- Использование JBOD вызывает дополнительные трудности для баз данных в области проверки данных. При применении хранилища RAID контроллер массива часто проверяет указанную группу дисков, находя и переназначая поврежденные блоки. Поврежденный блок (или сектор) — это блок на диске, который нельзя использовать из-за необратимого сбоя (например, физического повреждения частей диска). Контроллер массива также часто читает данные с зеркального диска, если при исходном запросе на чтение был обнаружен поврежденный блок. Контроллер массива отмечает блок как поврежденный и записывает данные в новый блок. Все это происходит без ведома приложения, лишь слегка увеличивается задержка при чтении диска. Без RAID или контроллера массива оба эти метода обнаружения и исправления поврежденных блоков недоступны. Без RAID приложение (ESE) обнаруживает и исправляет поврежденные блоки (т. е. проверяет контрольную сумму базы данных).
- Для больших баз данных на больших дисках требуются более длительные периоды для обслуживания последовательности и сжатия базы данных.
Из-за указанных ранее проблем в Exchange 2010 требовалось вынести задачи обслуживания базы данных из запланированного процесса и реализовать их во время выполнения в фоновом режиме.
Не повлияют ли эти фоновые задачи на конечных пользователей?
Мы разработали эти фоновые задачи так, чтобы они автоматически регулировались в зависимости от действий, выполняемых с базой данных. Кроме того, рекомендации по определению размера профилей сообщений учитывают эти задачи обслуживания . Однако следует быть осторожными при разработке архитектуры хранилища. Если вы планируете хранить несколько баз данных на одном LUN или томе, убедитесь, что общий размер всех баз данных не превышает 2 ТБ. Поэтому обслуживание базы данных регулируется за счет сериализации в зависимости от количества баз данных или томов, при этом предполагается, что общий размер не превышает 2 ТБ.
Как можно отслеживать эффективность фоновых задач обслуживания?
В предыдущих версиях Exchange события в журнале приложений использовались для отслеживания таких операций, как дефрагментация базы данных. В Exchange 2010 события дефрагментации и сжатия не записываются в журнал. Однако вы можете использовать счетчики производительности для отслеживания фоновых задач обслуживания в объекте База данных MSExchange==> Экземпляры :
Следующие счетчики обнуления страниц можно найти в объекте База данных MSExchange :
Как проверить пустое пространство в базе данных?
Вы можете использовать командную консоль для проверки пустого пространства в базе данных. Для баз данных почтовых ящиков используйте следующую команду:
Get-MailboxDatabase MDB1 -Status | FL AvailableNewMailboxSpace
Для баз данных общих папок используйте следующую команду:
Get-PublicFolderDatabase PFDB1 -Status | FL AvailableNewMailboxSpace
Как можно освободить пустое пространство?
Естественно, что после того, как вы обнаружили пустое пространство в базе данных, возникает вопрос: "Как освободить пустое пространство?"
Многие предполагают, что ответ заключается в выполнении дефрагментации в автономном режиме с помощью ESEUTIL. Однако это не рекомендуется . При выполнении дефрагментации в автономном режиме создается новая база данных, а операции, выполняемые для создания базы данных, не записываются в журналы транзакций. У новой базы данных также новая подпись базы данных, т. е. вы аннулируете копии, связанные с этой базой данных.
Если вы обнаруживаете базу данных со значительным объемом пустого пространства и сомневаетесь в том, что оно будет освобождено в ходе нормальной работы, рекомендуется следующее:
- создайте новую базу данных и связанные копии;
- переместите все почтовые ящики в новую базу данных;
- удалите исходную базу данных и связанные с ней копии.
Путаница с терминологией
Путаница во многом связана с понятием фоновое обслуживание базы данных . В целом все указанные выше задачи включены в фоновое обслуживание базы данных. Однако командная консоль, EMC и JetStress считают проверку контрольных сумм базы данных фоновым обслуживанием базы данных, и именно эту операцию вы настраиваете при включении или отключении с помощью этих средств.
Рис. 1. Включение фонового обслуживания базы данных с помощью EMC
Включение фонового обслуживания базы данных с помощью командной консоли:
Set-MailboxDatabase -Identity MDB1 -BackgroundDatabaseMaintenance $true
Рис. 2. Выполнение фонового обслуживания базы данных в тесте JetStress
Производитель хранилища порекомендовал отключить проверку контрольной суммы базы данных при фоновом обслуживании базы данных. Что мне делать?
Проверка контрольной суммы базы данных может стать тяжелым бременем для системы, если хранилище неправильно спроектировано (даже если оно последовательное), так как при этом выполняются операции чтения по 256 КБ и записи по 5 МБ/с на базу данных.
Заключение
Архитектурные изменения ядра СУБД в Exchange Server 2010 значительно улучшили производительность и надежность, но изменили поведение задач обслуживания базы данных по сравнению с предыдущими версиями. Надеемся, что эта статья позволит вам понять, что такое фоновое обслуживание базы данных в Exchange 2010.
(Короткие заметки)
Когда база приблизилась к своему предельному значению (например, 100 Гб), нужно начать перемещение части почтовых ящиков в новую базу. Какие ящики перемещать, чтобы добиться стабилизации размера почтовой базы?
Понятно, что те почтовые ящики, которые заметно увеличиваются в размерах. Но чтобы выделить такие почтовые ящики, нужно регулярно снимать статистику по почтовым ящикам и анализировать ее.
Если такой процесс не налажен, то можно опираться на некоторые эвристические утверждения (спорные, но полезные для начала).
1. Нет смысла перемещать почтовые ящики, которые уже достигли или скоро достигнут предельно разрешенного размера.
2. Нет смысла перемещать почтовые ящики, которые существуют относительно долго (созданы давно) и сохраняют небольшой размер или сохраняют стабильный размер.
Для перемещения почтового ящика пользователя используется GUI или командлет New-MoveRequest
ExchangeServer 2010 позволяет перемещать почтовый ящик в другую базу без прерывания работы пользователя. http://blogs.technet.com/b/exchange/archive/2011/01/24/3411868.aspx
Число одновременных потоков копирования ограничивается. Это защищает сервер (хранилище) от перегрузки. Копирование может занять достаточно много времени.
После перемещения почтовый ящик в исходной базе помечается как SoftDeleted. (начиная с SP 1 http://technet.microsoft.com/en-us/library/dd298174.aspx )
Get-MailboxStatistics -Database «Mailbox Database 01» | where { $_ . DisconnectReason -eq «SoftDeleted» }
После перемещения почтовых ящиков исходная база не уменьшается в размерах и в ней не освобождается место:
|
ServerName |
Name |
DatabaseSize |
AvailableNewMailboxSpace |
|
———- |
—- |
———— |
———————— |
|
MB2 |
Mailbox Database 01 |
101.4 GB (108,859,031,552 … |
5.7 MB (5 , 976 , 883 bytes) |
|
MB2 |
Mailbox Database 02 |
75.26 GB (80,807,526,400 b… |
2.5 MB (2 , 621 , 440 bytes) |
|
MB1 |
Mailbox Database 03 |
53.88 GB (57,856,294,912 b… |
12.28 MB (12,877,824 bytes) |
|
MB1 |
Mailbox Database 04 |
26.88 GB (28,865,265,664 b… |
87.63 MB (91,881,472 bytes) |
После завершения переноса нужно проверить успешность завершения процесса и удалить запросы на перемещение через GUIили
Get-MoveRequest -MoveStatus Completed | Remove-MoveRequest -Confirm: $false
Нужно удалить SoftDeletedпочтовые ящики:
$b = Get-MailboxStatistics -Database «RUMS Mailbox Database 01» | where { $_ . DisconnectReason -eq «SoftDeleted» }
$b | % { Remove-StoreMailbox -Confirm: $False -Database $_ . database -Identity $_ . mailboxguid -MailboxState «SoftDeleted» }
После этого в исходной почтовой базе появится свободное место:
Get-MailboxDatabase -Status | select ServerName , Name , DatabaseSize , AvailableNewMailboxSpace
|
ServerName |
Name |
DatabaseSize |
AvailableNewMailboxSpace |
|
———- |
—- |
———— |
———————— |
|
MB2 |
Mailbox Database 01 |
101.4 GB (108,859,031,552 … |
55.97 GB (60,094,939,136 b… |
|
MB2 |
Mailbox Database 02 |
75.26 GB (80,807,526,400 b… |
28.5 GB (30,605,312,000 by… |
|
MB1 |
Mailbox Database 03 |
53.88 GB (57,856,294,912 b… |
12.28 MB (12,877,824 bytes) |
|
MB1 |
Mailbox Database 04 |
26.88 GB (28,865,265,664 b… |
87.63 MB (91,881,472 bytes) |
Затем базу можно упаковать для уменьшения ее размера.
Упаковка базы может быть выполнена по двум сценариям.
Первый – традиционный для одиночной базы. База размонтируется и упаковывается утилитой eseutil /d. Процесс требует наличия свободного места +10%*<размер исходной базы>. На все время работ сервис
Второй подходит для DAG. Создается новая база на новых хранилищах. Почтовые ящики копируются в новую базу. Этот способ работает и для одиночной базы. Накладные расходы на свободное место выше, чем в первом способе: новые хранилища надо создать для всех копий в DAG. (Стратегия может быть разной: для ускорения копирования можно создать одну дополнительную копию для новой базы, а после окончания процесса переноса почтовых ящиков, добавить остальные копии на освободившиеся от исходной базы хранилища.)
Если свободных хранилищ у вас нет, то в случае DAG, вам придется удалить все дополнительные копии базы, размонтировать ее, упаковать, смонтировать и снова добавить дополнительные копии – очевидно, что это может занять намного больше времени. Поэтому рекомендуется базы делать не более 100Гб, а в случае DAGиметь свободное пространство для маневра.
При дефрагментации данные, хранящиеся на жестких дисках компьютера, перемещаются таким образом, чтобы файлы были разбиты на меньшее число частей. Дефрагментация помогает ускорить доступ к данным и их получение. Дефрагментация данных на жестких дисках повышает их производительность и эффективность работы серверов организации. В Exchange 2007/2010 дефрагментация (точнее оффлайн дефрагментация) позволяет освободить место на диске. Спросите каким образом? Все очень просто, при удалении информации из базы данных, она автоматически не сжимается (остаются пустые области), и соответственно размер файла базы не уменьшается.
Например, если из почтовой базы размером 100 Гб удалить/ переместить ящики пользователей, общим размером 5 Гб, то размер файла останется неизменным 100 ГБ. Однако, освободившиеся 5 Гб «свободного» места в дальнейшем будет использоваться новыми элементами.
Тем не менее если вам необходимо уменьшить размер файла почтовой базы в Exchange 2010, удалив незанятые страницы, вы можете воспользоваться одной из следующих методик:
Создать новую базу данных, перенести вся ящики в нее и удалить старую базу
Выполнить оффлайн дефрагментацию текущей базы
Каждый из этих методов имеет свои плюсы и минусы. Первый хорош тем, что процедура менее рискованная, но и менее удобна, т.к. если у вас в базе 500 эл. ящиков, то в ручную переносить их будет очень тяжко. Второй метод не удобен тем, что требует не мало ресурсов (об этом пойдет речь дальше) и в случае сбоев, не известно к чему это может привести, но зато с большой базой справиться относительно быстро. Выбор за вами. Первый способ описывать, я думаю, не стоит, все интуитивно понятно, остановлюсь на описании второго метода.
Для того что бы воспользоваться оффлайн дефрагментацие используется команда Eseutil. В режиме Eseutil составной частью процесса дефрагментации является создание новой базы данных, содержащей все данные, входившие в исходную базу данных, за исключением того, что пустые страницы отбрасываются и индексы перестраиваются. После завершения дефрагментации исходная база данных удаляется или сохраняется в указанном пользователем месте, а новая версия получает такое же имя, какое было у исходной базы данных.
Перед тем как начать уменьшение базы Exchange2007/ 2010 с помощью команды Eseutil, предлагаю рассмотреть команды Exchange Management Console
которые могут пригодится для понимания ситуации с базами и электронными ящиками.
C помощью следующего командлета мы можем посмотреть доступные почтовые базы организации:
Get-MailboxDatabase
Теперь посмотрим какие почтовые ящики в конкретной базе (в данном примере Mailbox Database 1)
Get-MailboxDatabase "Mailbox Database 1" | Get-Mailbox
Для того что бы импортировать статистику в CSV файл в конце команды дописываем
| Export-CSV C:\mailboxes.csv
В корне диска С создается файл mailboxes.csv
Теперь перейдем к командам для оффлайн форматирования, первое что необходимо сделать перед уменьшением базы- отмонтировать ее, для этого можно запустить команду Dismount-Database ИМЯ БАЗЫ , либо запустить Exchange Management Console, зайти "Server Configuration- Mailbox " с правой стороны будут все Database выбираем необходимый нам кликаем на нем правой кнопкой мыши и выбираем Dismount Database .
ESEUTIL /d "G:\Exchange server\OTS\ots.edb"
Дефрагментированный временный файл будет создан в корне диска С, может занять до 110% первоначальной базы- это необходимо учесть.
ESEUTIL
/d "G:\Exchange server\ROZN\rozn.edb" /t"G:\temp\tempdfg.edb"
Дефрагментированный временный файл будет создан на диске G в папке temp, может занять до 110% первоначальной базы, (предварительно необходимо создать файл tempdfg.edb ) затем он заменит собой существующую базу (в данном примере rozn.edb)
Надеюсь статья оказалась вам полезна и вы успешно уменьшили размер почтовой базы.
Microsoft Exchange Server, начиная с версии 2007, хранит сообщения очередей в базе данных формата ESE - Mail.que , расположенной в папке . После нескольких лет эксплуатации база данных транспортных очередей может вырасти до огромных размеров. В моем случае, примерно за 4 года эксплуатации Exchange Server 2010 она выросла до 900МБ, не много конечно, но в Интернете встречаются случаи, когда ее размер доходил до 80-100 ГБ. После создания базы заново ее размер будет 8Мб. Большой объем базы может сказаться на производительности системы и занимать лишнее пространство на диске. Я же обратил на это внимание, когда один из моих транспортных серверов начал жутко «тормозить» из-за работы антивируса. После пересоздания базы данных очередей, проблема исчезла.
Хоть Exchange и совершает автоматическую онлайн дефрагментации этой базы, но размер ее никогда не уменьшится. К примеру, если во время сбоя, ваш транспортный сервер принял и хранил в очереди 10Гб почты, то потом, когда почта уйдет, размер файла хранения останется 10Гб. Поэтому моя рекомендация, если база выросла больше 200Мб, то ее нужно создать заново . Делается это следующим образом.
1. Необходимо поставить сервис Microsoft Exchange Transport на паузу. Сервис перестанет принимать сообщения, но «разделается» со всеми сообщениями в очередях.
2. Запустите коммандлет Get-Queue и убедитесь, что в очередях не осталось сообщений.
3. Остановите сервис Microsoft Exchange Transport .
4. Откройте папку %ExchangeInstallPath%TransportRoles\data\Queue и убедитесь, что файл mail.que находится в нем.
5. После этого этого переименуйте каталог %ExchangeInstallPath%TransportRoles\data\Queue
в %ExchangeInstallPath%TransportRoles\data\Queue1
.
6. Запустите сервис Microsoft Exchange Transport , папка Queue , база mail.que и лог файлы будут созданы. Размер заново созданной базы будет около 8,2 Мб.
7. Удостоверьтесь, что служба транспорта нормально работает и можно удалять папку Queue1 .
Информация о расположении файла базы данных находятся в файле %ExchangeInstallPath%Bin\EdgeTransport.exe.config , поэтому, если вы хотите переместить базу, то вместо шага 5 измените путь к новому файлу и выполните шаг 6.
Связанные записи:
Понравилась публикация? Хотите получать новые прямо в свой почтовый ящик? Нет ничего проще, подпишитесь на рассылку прямо сейчас.
Необходимость дефрагментации почтовых баз в Exchange Server 2010 возникает из-за того, что при удалении информации из базы данных, она автоматически не сжимается (остаются пустые страницы), и соответственно размер файла базы не уменьшается. Например, если из почтовой базы размером 20 Гб перенести ящики пользователей, общим размером 5 Гб, то размер файла останется неизменным 20 ГБ. Однако, освободившиеся 5 Гб «свободного» места в дальнейшем будет использоваться новыми элементами.
Поэтому если вам необходимо уменьшить размер файла почтовой базы в Exchange 2010, удалив незанятые страницы, вы можете воспользоваться одной из следующих методик:
- Создать новую базу данных, перенести вся ящики в нее и удалить старую базу
- Выполнить офлайн дефрагментацию текущей базы
Каждая из указанных методик имеет свои плюсы и минусы. Офлайновая дефрагментация предполагает простой ящиков пользователей, но она является единственным доступным решением при нехватке дискового пространства (вам просто негде создать новую базу данных).
С другой стороны миграция ящиков в новую базу менее рискованная процедура, но помимо необходимости иметь достаточно свободного места для хранения двух почтовых хранилищ, генерирующая большое количество транзакций, также существенно увеличивающих требования к доступному свободному месту, и как результат, процесс переноса пользователей может занять несколько дней.
Следует четко различать процессы офлайн и онлайн (интерактивной) дефрагментации базы Exchange 2010. Интерактивная дефрагментация в Exchange выполняется постоянно при включенной опции Enable background database maintenance (24 x 7 ESE scanning). Эта процедура выполняется в фоновом режиме включает в себя удаление устаревших элементов в хранилище и оптимизацию расположения страниц. Основная задача – освободить неиспользуемое пространство за счет сжатия записей до минимально возможного количества страниц с целью сокращения количества операций ввода/вывода. Отметим, что неиспользуемое пространство не возвращается системе. Офлайн дефрагментация позволяет высвободить это пространство.
Определяем размер свободного места в базе Exchange 2010
Чтобы в Exchange 2010 узнать текущий размер базы данных и количество свободного места в ней (те самые неиспользуемые страницы), в Exchange Management Shell выполните следующую команду:
C:\>Get-MailboxDatabase -Status | ft name,databasesize, availablenewmailboxspace -auto
Name DatabaseSize AvailableNewMailboxSpace—- ———— ————————
WI-DB-01 17.26 GB (18,604,766,720 bytes) 8.544 GB (9,247,766,016 bytes)
В данном примере видно, что текущий размер базы WI-DB-01 17 Гб, причем свободного места в ней аж 8.5 Гб. И если вы хотите высвободить это место, размер файла почтовой базы можно уменьшить, выполнив дефрагментацию утилитой ESEUTIL.
ПРИМЕЧАНИЕ. Если ваш сервер входит в в группу DAG не используйте данную инструкицю !
Подготовка к дефрагментации Exchange 2010
При планировании дефрагментации базы нужно четко понимать, что для выполнения данной работы, необходимо отмонтировать нужную базу, что недоступность почты для всех пользователей, находящиеся в этой базе данных.
Далее необходимо удостовериться, что имеется достаточно свободного места для выполнения дефрагментации. В процессе дефрагментации создается новый файл базы и на диске одновременно хранятся старый и новый файл, кроме того нужно дополнительное место для временных файлов, создаваемых утилитой eseutil.
Поэтому, если вы собираетесь выполнить дефрагментацию почтовой Exchange, необходимо иметь свободное место, равному не менее 110% от текущего размера базы (без учета пустых страниц).
В моем случае это означает, что нам необходимо иметь как минимум 9,6 Гб свободного места на диске:
17.26 – 8.54 = 8.72
8.72 x 1.1 = 9.6
Если на текущем диске такого количества места нет, необходимо в параметрах eseutil указать альтернативное расположение временных файлов. Это может быть другой диск или сетевой UNC-путь, однако следует учесть, что при использовании UNC пути время дефрагментации может существенно увеличиться из-за пропускной способности и задержек сети.
Также нужно удостовериться, что вы у вас есть актуальная резервная копия дефрагментируемой базы данных, чтобы не было потом мучительно больно…
Использование ESEUtil для дефрагментации базы Exchange
Откройте командную строку Exchange Management Shell и перейдите в каталог с файлом почтовой базы:
Cd D:\Data\WI-DB-01
Размонтируем базу.
Dismount-Database WI-DB-01
Запускаем дефрагментацию с помощью утилиты ESEUtil.
D:\Data\WI-DB-01>eseutil /d WI-DB-01.edb /t\\tmp_srv\exch\temp.edb
Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Copyright (C) Microsoft Corporation. All Rights Reserved.
Initiating DEFRAGMENTATION mode…
Database: WI-DB-01.edb
Defragmentation Status (% complete)
……………………………………………
Moving ‘\\ tmp_srv\exch\temp.edb’ to ‘WI-DB-01.edb’…
File Copy Status (% complete)
0 10 20 30 40 50 60 70 80 90 100
|—-|—-|—-|—-|—-|—-|—-|—-|—-|—-|
……………………………………………
It is recommended that you immediately perform a full backup
of this database. If you restore a backup made before the
defragmentation, the database will be rolled back to the state
it was in at the time of that backup.
Operation completed successfully in 2798.218 seconds.
Монтируем базу:
Mount-Database WI-DB-01
Убедимся, что ее размер уменьшился:
Get-MailboxDatabase -Status | ft name,databasesize,availablenewmailboxspace -auto
Name DatabaseSize AvailableNewMailboxSpace
—- ———— ————————
WI-DB-01 8.328 GB (8,942,190,592 bytes) 5.219 MB (5,472,256 bytes)
WI-DB-02 14.63 GB (15,785,670,144 bytes) 4.696 GB (4,968,761,856 bytes)
WI-DB -Archive-01 658.1 MB (689,542,784 bytes) 234.6 MB (241,164,544 bytes)
