В прошлой статье мы обсудили вопрос мягкого восстановления базы данных при помощи команды 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 заключается в том, что во время её работы база данных почтовых ящиков должна находиться в отключенном состоянии, а это означает достаточно длительный простой в случае большого размера базы.
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.
Заключение
В заключение хочется ещё раз напомнить, что задумываться о резервном копировании данных нужно задолго до того, как вам понадобится их восстанавливать, так что этот процесс должен быть заранее продуман и отработан.
Богомолов Алексей (Alexx)
VN:R_U [1.9.20_1166]
