Исправление базы данных почтовых ящиков в Exchange

В прошлой статье мы обсудили вопрос мягкого восстановления базы данных при помощи команды Esutil /R. В подавляющем большинстве случаев эта команда отрабатывает успешно и базу удается смонтировать на сервер. Но бывают и такие ситуации, когда база сильно повреждена и мягко восстановить её не получается, в таких случаях необходимо попытаться вытащить из базы как можно больше информации.

Исправление

Для исправления базы данных придется использовать команду ESEUTIL /P. Стоит несколько раз подумать, прежде чем пользоваться функцией Repair, т.к. данная операция в ЛЮБОМ случае приведет к потере данных, и сколько именно данных будет потеряно спрогнозировать не реально, можно только с уверенностью сказать, что информация, находящаяся в лог-файлах будет на 100% потеряна.

Все дело в том, что база данных почтовых ящиков не является реляционной, а состоит из множества деревьев с указателями на страницы с данными. Так вот, ESEUTIL /P будет проверять все эти указатели и при обнаружении несоответствий, просто удалит указатель, в независимости от того, на какие данные он ссылается.

Процесс исправления запускается не по отношению к лог-файлам, как было с восстановлением, а по отношению к файлу самой базы данных.

eseutil /P MDB2.edb

После запуска на экран выводится предупреждение, которое позволяет одуматься и отказаться от этого метода восстановления базы.

Рис.1: Предупреждение перед операцией Repair.

Если все же вы твердо решили продолжать, то нужно нажать ОК и утилита ESEUTIL сделает все сама.

Рис.2: Исправление базы при помощи команды ESEUTIL /P.

После операции Repair может быть заметно снижена производительность базы данных, в связи с этим рекомендуется делать автономную дефрагментацию базы при помощи команды ESEUTIL /D, в результате выполнения команды будет создана абсолютно новая база данных, но тут нужно помнить, что для дефрагментации базы у вас должно быть свободного места больше на 110%, чем занимает исходная база.

Проверка логической целостности

После дефрагментации нужно будет проверить логическую целостность базы данных. Ранее, для этого используется утилита ISINTEG. На серверах Exchange 2007 и старше можно было выполнить команду:

isinteg -s имя_сервера -fix -test alltests

тем самым инициировав процесс проверки базы данных.

Рис.3: Проверка логической целостности базы при помощи ISINTEG.

Описание программы ISINTEG.

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

Exchange 2010

Плюсом к этому, с приходом Exchange 2010 ISINTEG перестала понимать все функции новой базы данных. Но это и нормально, ведь данное средство не изменялось с 2000-го года!

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

Рис.4: Фоновое обслуживание базы данных.

Exchange 2010 SP1

С входом Exchange 2010 SP1, появилась замена средства ISINTEG в виде новых командлетов:

· New-MailboxRepairRequest – тестирование и исправление почтовых ящиков;

· New-PublicFolderDatabaseRepairRequest – тестирование и исправление общих папок.

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

Синтаксис использования командлетов следующий:

new-MailboxRepairRequest [-Mailbox <MailboxID> | -Database <DatabaseID>] -CorruptionType <CorruptionType> [-DetectOnly] [-DomainController <FQDN>]

Здесь

· Mailbox или Database – это соответственно почтовый ящик или база данных;

· CorruptionType – вид проверки, которую вы желаете запустить:

o SearchFolder;

o AggregateCounts;

o ProvisionedFolder;

o FolderView.

· DetectOnly – используется, если вы хотите лишь обнаружить ошибки, но не исправлять их;

· DomainController – определяет контроллер домена для обновления данных.

Для того, чтобы запустить сразу все виды проверки, то необходимо их перечислить через запятую:

New-MailboxRepairRequest -Mailbox <MailboxID> -CorruptionType SearchFolder,AggregateCounts,ProvisionedFolder,FolderView

Если нужен только один вид проверки для базы данных, то команда будет выглядеть следующим образом:

New-MailboxRepairRequest –Database MDB2 –CorruptionType AggregateCounts

Рис.5: Проверка всей базы.

В результате команда будет выполняться в фоновом режиме, а вам будет доступен её RequestID. Также в журнале событий Windows вы найдете событие под номером EventID = 10059, которое будет означать запуск сканирования

Рис.6: Запуск сканирования базы данных в журнале событий Windows.

И событие с EventID = 10048, которое будет означать успешное завершение операции.

Рис.7: Завершение операции сканирования базы данных в журнале событий Windows.

Заключение

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