В Exchange 5 довольно большое количество клиентов применяли автономную дефрагментацию своих баз данных Exchange в качестве части своего ежемесячного цикла обслуживания системы. И честно говоря, это была не такая уж плохая идея (в те времена). Компания Microsoft сделала колоссальное улучшение в механизме баз данных ESE, и теперь вообще нет необходимости в выполнении автономной дефрагментации, как части ежемесячного цикла обслуживания систем. Но когда же все-таки нужно выполнять автономную дефрагментацию? Это нужно делать после перемещения большого количества баз данных (или больших объемов данных) в другую базу почтовых ящиков.
Представьте, что у вас есть 200 ГБ база данных почтовых ящиков и вы перемещаете 80 ГБ почтовых ящиков в другую базу данных почтовых ящиков. Когда время хранения удаленных почтовых ящиков выйдет, у вас будет 80 ГБ свободного места в базе данных почтовых ящиков. Есть процесс под названием оперативное обслуживание на серверах почтовых ящиков, и это оперативное обслуживание отвечает за удаление сообщений и почтовых ящиков по прошествии 14-дневного или 30-дневного срока времени сохранения. Оперативное обслуживание также выполняет дефрагментацию базы данных внутренне, чтобы делать ее более эффективной, но он не сжимает размер файла базы данных. Таким образом, в этом примере размер файла базы данных останется 200 ГБ, хотя на самом деле используется всего 120 ГБ!
Чтобы сжать базу данных до 120 ГБ выполняется автономная дефрагментация. Но что же происходит на самом деле при выполнении автономной дефрагментации?
- Прежде всего база данных почтовых ящиков должна быть отключена, поэтому вам придется столкнуться с определенным временем простоя
- Новая временная база данных будет создана и эта база получает случайное имя типа 'TEMPDFRG5268.EDB'
- ESEUTIL начинает копировать данные из старой базы данных в эту новую временную базу данных. В этом примере всего 120 ГБ данных будет скопировано во временную базу
- Когда все данные скопированы во временную базу данных, старая база удаляется физически с диска
- Временный файл под названием 'TEMPDFRG5268.EDB' переименовывается в название производственной базы данных, например 'Mailbox Database 2563992651.edb'
Рисунок 1: Выполнение автономной дефрагментации. Временная база данных отчетливо видна
Этот процесс может занять довольно длительное время. Обычно я использую скорость обработки от 5 до 10 ГБ в час для реальных данных (на Exchange Server 2003). Итак, почтовая база данных размером 200 ГБ будет содержать 120 ГБ реальных данных, поэтому может потребоваться до 12 часов на выполнение дефрагментации. Но все улучшается, в Exchange 2010 мне доводилось сталкиваться со скоростью автономной дефрагментации до 45 ГБ в час. 120 ГБ потребует около 3 часов на выполнение.
Примечание: автономная дефрагментация создает новую базу данных почтовых ящиков с новыми сигнатурами и т.д. Поэтому невозможно будет восстановить данные из предыдущих журналов. Вам придется создавать новую полную резервную копию сразу после выполнения автономной дефрагментации с помощью ESEUTIL!
Поскольку автономная дефрагментация создает новую базу данных почтовых ящиков, ее не просто выполнить в кластере CCR (Exchange 2007) или для группы DAG (Exchange 2010). Лучшим вариантом здесь будет создание новой базы данных почтовых ящиков и перемещение всех почтовых ящиков из старой дефрагментированной базы почтовых ящиков в новую. По окончании нужно удалить старую базу данных почтовых ящиков.
Исправление базы данных
Довольно редко, но все же случается так, что база данных почтовых ящиков может повреждаться после сбоя на сервере. Если у вас используется кластер CCR (Exchange 2007) или группа DAG (Exchange 2010), все будет в порядке, поскольку вторая копия базы данных почтовых ящиков заменит поврежденную. Но на одном сервере это может создавать проблемы. Если вы не можете восстановиться из резервной копии, у вас не будет других вариантов (даже звонок в службу технической поддержки Microsoft может быть более подходящим вариантом, чем работа с опциями исправления!), которые можно использовать для исправления базы данных с помощью ESEUTIL /P.
Использование ESEUTIL /P является разрушительной операцией, и ВСЕГДА будет приводить к определенной потере данных, но, к сожалению, невозможно предсказать, насколько значительными будут потери.
База данных почтовых ящиков не является реляционной базой данных, как SQL Server (где все таблицы предопределены в зависимости от используемого приложения), а являются Binary Plus или B+ Tree. База данных состоит из нескольких деревьев (может быть до тысячи) и каждое дерево состоит из указателей и страниц с данными. ESEUTIL /P будет проверять все деревья и все указатели, и при обнаружении нестыковок в указателе, они определяются независимо от тех данных, на которые ссылается указатель.
По окончании процесса ESEUTIL /P у вас будет база данных с отсутствующими указателями (и невозможно предсказать, сколько указателей будет отсутствовать), а, следовательно, и недостающими данными. Также по причине отсутствующих указателей деревья базы данных больше не будут смежными, что приведет к снижению производительности.
По этой причине рекомендуется выполнять автономную дефрагментацию (которая создаст абсолютно новую базу данных почтовых ящиков!) сразу после исправления базы данных почтовых ящиков с помощью ESEUTIL /P.
Однако подождите, есть еще кое-что. ESEUTIL исправляет базу данных почтовых ящиков на низком уровне, поэтому она исправляет все таблицы, индексы и указатели в файле базы данных. Однако ESEUTIL не понимает таких вещей, как почтовые ящики, папки, сообщения и т.д. После исправления и дефрагментации вашей поврежденной базы данных вам придется сканировать (и исправлять) ее на логическом уровне, используя ISINTEG. Для корректной работы ISINTEG база данных почтовых ящиков должна быть на своем изначальном месте.
Когда вы выполняете ISINTEG (ISINTEG 'fix 'test alltests), вы увидите различные сообщения. Просто повторяйте выполнять ISINTEG, пока все не будет в порядке, и вы не увидите никаких сообщений об ошибках.
Рисунок 2: Выполнение ISINTEG на сервере Exchange 2003 Mailbox
Также следует знать, что ISINTEG не будет работать в Exchange Server 2010 Service Pack 1. Ее функционал будет заменен новой командой: New-MailboxRepairRequest.
Если вы хотите быть полностью уверенными в том, что на 100% защищены, можете даже подумать о перемещении почтовых ящиков из этой конкретной базы данных почтовых ящиков (которую вы только что исправили) в новую базу почтовых ящиков. Если вы выполнили этот шаг, вы можете смело удалять старую базу и исправлять базу данных почтовых ящиков (и не забудьте создать новую резервную копию этой новой базы данных ;-)
Заключение
В этой части цикла статей я показал вам, как выполнять автономную дефрагментацию базы данных почтовых ящиков и как исправлять базу данных почтовых ящиков после повреждения. Следует знать, что последняя опция всегда означает, что определенные данные будут утеряны. Рекомендуется запускать исправление базы данных почтовых ящиков, если сотрудники службы технической поддержки Microsoft сказали вам сделать это. Также после исправления необходимо выполнить автономную дефрагментацию и логическое исправление с помощью инструмента ISINTEG.
В следующей части этого цикла о ESEUTIL я расскажу об оперативном резервном копировании, принудительном восстановлении и выполнении проверки целостности с помощью ESEUTIL.