понедельник, 11 октября 2010 г.

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

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

Исправление

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

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

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

eseutil /P MDB2.edb

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

clip_image003

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

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

clip_image005

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

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

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

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

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

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

clip_image006

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

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

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

Exchange 2010

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

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

clip_image007

Рис.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

clip_image009

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

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

clip_image011

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

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

clip_image013

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

Заключение

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

16 комментариев:

Анонимный комментирует...

При проведении операции eseutil /D вышла ошибка Jet_errOutOfSequentialIndexValues. не знаю что делать.
Извиняюсь. не удалось авторизоваться. Я сюда уже не раз писал. email ua1wcz@gmail.com

Алексей Богомолов (Alexx) комментирует...

Нужен полный текст ошибки, так трудно что-то сказать.

Анонимный комментирует...

Добрый день, Алексей!
Исправление базы при помощи команды ESEUTIL /P, происходит в данный момент.
Сейчас подключена временная база. Т.е. пользователь может работать как в автономном режиме со старой почтой, так и отправлять/получать письма в ящик временной базы.
После восстановления планируется создание новой базы и перемещение всех ящиков и их содержимого из старой базы. Вопрос, как избежать задвоений, при переносе писем из временной базы в новую, которые могут оказаться как в новой базе(в которую перемещена вся почта из восстановленной), так и во временной?
Вопрос возник после того, как я собственными глазами увидел, что некоторые пользователи импортировали все письма из автономного п/я, во временный.

Владимир. invisiblecrow@gmail.com

Алексей Богомолов (Alexx) комментирует...

Если они сами письма переносят, то "задвоения" ни как не избежать.

Unknown комментирует...

У меня выдало ошибку при выполнении команды ESEUTIL /P
Checking database integrity.

Scanning Status (% complete)

0 10 20 30 40 50 60 70 80 90 100
|----|----|----|----|----|----|----|----|----|----|
......................



Operation terminated with error -1620 (JET_errDecompressionFailed, Internal erro
r: data could not be decompressed) after 1269.312 seconds.

Что можно еще попробовать? Есть ли какие варианты чтоб все таки восстановить базу?

Алексей Богомолов (Alexx) комментирует...

К сожалению, в таком случае, базу восстановить не получится. Надеюсь у вас есть бэкап.

Если профили в Outlook`х ещё не пересоздавали, то можно попробовать выгрузить данные в PST, чтобы потом вернуть их обратно в новую базу.

Unknown комментирует...

Алексей, доброго времени суток! Сделал полное восстановление командой eseutil /p, пишет что все успешно восстановлено, но при подключении базы все равно выдает ошибку. Необходимо ли делать дефрагментацию базы после восстановления и вообще что еще можно сделать? Стоит exchange 2010

Алексей Богомолов (Alexx) комментирует...

Нет, не нужно, если база в Clean shutdown, то должна смонтироваться.

Unknown комментирует...

К сожалению база так и не смонтировалась, хотя перевел ее из состояния dirty в clear shutdown

Анонимный комментирует...

Алексей, добрый день. Не могли бы подсказать по следующей проблеме: сейчас мигрировало 90% ящиков с EX2010 на EX2013CU9. Проявилась проблема с поиском писем, в частности OWA - при поиске выдает не все письма а лишь небольшую их часть, от 5 до 15. При этом, если сделать сортировку по отправителю (без поиска), по требуемому отправителю видны все письма. Индексы поиска обновлял, не помогло. Проблема массовая, на всех ящиках мигрировавших с 2010. На ящиках созданных уже на новом сервере проблемы с поиском нет.

Анонимный комментирует...

Здравствуйте, Алексей!
Во время миграции двух почтовых ящиков из одной базы данных в другую в рамках одного сервера произошел сбой оборудования, и вторая база данных оказалась повреждена, причем Recover не сработал (кажется, в ошибке было что-то о Null Page). Базу чинили медодом Repair, но теперь в обеих базах есть эти два ящика, и из сбойной их никак не удалить. Пробовал переключать их в сбойную базу (Set-Mailbox, потом Disable-Mailbox) - у них не устанавливается DisconnectReason. Пробовал Clean-MailboxDatabase - тоже не помогает. Можете что-нибудь посоветовать?

Алексей Богомолов (Alexx) комментирует...

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

Unknown комментирует...

Спасибо помогло, на заметку, после выполнения ESEUTIL /P, в отчете было сказано, что все успешно, но БД все равно отказывалась монтироваться, помогло удаление всех log файлов, в том числе E00.log

Анонимный комментирует...

Добрый день,Алексей Богомоловю
у меня такая проблема. Мы создали базу в hyper v и у нас база заполнилась до 1,6 Т.Б, как мене быть надо добавить новый диски и перемонтировать его ? или есть другой способ? можно ваши контакты ?

Алексей Богомолов (Alexx) комментирует...

Если база ещё жива и смонтирована - быстро создаем 5-6 новых и переносим туда все ящики. Старую - удаляем.
Если место закончилось и база не монтируется - то переносим её на новый, более просторный LUN и делаем п.1.

Unknown комментирует...

Доброй ночи! Александр, может Вы поможете/посоветуете куда еще копнуть осталось? Такая проблема - два сервака в DAGе, одна база, как оказалось была "Failed and Suspended", а на втором сервере глюкнул диск и умер сам файлик edb, но остались все логи. В результате имеем актуальные логи с одного сервака и файлик базы недельной давности со второго. Все перепробовали (что взбрело в голову). Посоветуете, куда копать? eseutil /r пробовали, маунтить старую тоже. Пробовали файл брать с одного сервера, а логи с другого и eseutil /r. Процесс заканчивался успешно. но файлик не менялся. менялся .chk Статус базы "incremental reseed in progress"...

Отправить комментарий