четверг, 7 октября 2010 г.

Восстановление баз данных при помощи ESEUTIL

imageПусть не часто, но все же бывают ситуации, когда необходимо произвести какие-либо манипуляции с базой данных почтовых ящиков Exchange на достаточно низком уровне. В подавляющем большинстве случаев необходимость такая возникает в аварийных ситуациях, когда нужно восстановить работоспособность базы, либо в совсем критических случаях, для того, чтобы вытащить из неё как можно больше информации. Процедуру дефрагментации базы в расчет не берем, т.к. сервер Exchange 2010 практически в ней не нуждается.

Так вот, прежде чем приступить к вопросу восстановления нужно понять принцип работы базы данных на сервере Exchange.

Принцип работы базы данных почтовых ящиков

Дело в том, что актуальная информация о состоянии почтовых ящиков пользователей хранится в двух местах:

  • в файле с расширением *.EDB – файл самой базы;
  • в лог-файлах.

При этом лог-файлов есть несколько видов

  • E00.log - это лог файл, используемый в настоящее время механизмом базы данных;
  • E00tmp.log - новый лог файл, который создается в текущий момент;
  • E00000003A.log, E00000003B.log, E00000003C.log - это лог файлы, хранящиеся на диске, которые можно использовать для восстановления;
  • E00res00001.jrs и E00res00002.jrs - это предварительно созданные лог файлы, используемые, когда диск, содержащий лог файлы, заполнен.

Ещё в папке с логами есть файл E00.chk - это файл контрольной точки, используемой для отслеживания отношений между лог-файлами и файлом базы данных.

В результате процесс работы базы данных можно проиллюстрировать следующим образом:

clip_image002

Рис.1: Работа базы данных

  1. Почтовые данные сначала обрабатываются в памяти, разделяются на страницы (32 Kb – Exchange 2010, 8 Kb – Exchange 2007).
  2. Обновленные страницы, образующие транзакцию, записываются в лог файл - E00.log.
  3. Если страницы больше не требуются, они записываются в базу данных.
  4. Файл контрольной точки (E00.chk) обновляется и отображает новое место контрольной точки, файл E00.log переименовывается в следующий E0000000...log, а на место него приходит E00tmp.log.

Примечание: В пределах сервера у каждой базы должен быть индивидуальные префикс, в данном примере это E00, для следующей созданной на сервере базы данных будет сгенерирован префикс E01 и т.д..

В процессе создания и получения новых писем, может возникнуть ситуация когда новая информация находится только в транзакционном логе и еще не была записана в файл базы данных. Следовательно, если некорректно выключить сервер, то часть данных останется в файле E00.log. При этом база останется в состоянии «Неправильного отключения» (Dirty Shutdown).

Если отключить базу корректно при помощи командлета Unmount-Database, то вся информация будет перемещена в основной файл базы данных (*.EDB) и логи можно будет удалять. При этом база будет в состоянии «Правильного отключения» (Clean Shutdown). Для того, чтобы смонтировать базу на сервер Exchange, её нужно перевести в состояние Clean Shutdown.

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

Далее давайте рассмотрим ситуацию, когда сама база не монтируется, либо она повреждена и вам нужно её восстановить.

Реанимация базы данных

Все манипуляции с файлами базы данных придется производить из командной строки при помощи утилиты ESEUTIL.

Первое что нам нужно сделать – это оценить обстановку, для этого используем ключи /MH и /ML для получения информации из заголовков файла базы данных и лог-файлов.

Eseutil /MH MDB.edb

Eseutil /ML E00.log

Для проверки целостности всех лог-файлов нужно использовать команду:

Eseutil /ML E00

clip_image003

Рис.2: Заголовок edb-фала.

clip_image005

Рис.3: Заголовок лог-файла

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

1. State – Dirty Shutdown – говорит нам о том, что база была отключена не корректно;

2. Информация о связанных лог-файлах;

3. Сигнатура базы;

4. Сигнатура лог-файлов;

5. Системные директории.

Также можно обратить внимание на строку lGeneration – это номер, под которым будет сохранен текущий лог-файл. А по сигнатурам лог-файлов и базы можно оценить принадлежность этих файлов конкретной базе.

Оценив ситуацию, давайте перейдем непосредственно к реанимации базы

Начать стоит с мягкого восстановления, для этого используется ключ /R – Recovery, следующим образом:

Eseutil /R E00

При этом нужно обратить внимание на такую вещь, как расположение файла базы данных и лог-файлов. Если мы вернемся к рис.3, то под цифрой 5 на нем указано, где должны лежать системные файлы, лог-файлы и файл базы данных. Следовательно, если мы восстанавливаем базу из архива в альтернативное место, то нам нужно перезаписать эту информацию новыми значениями. Здесь проще всего положить лог-файлы в каталог с самой базой данных и использовать ключик /D для перезаписи путей.

Примечание: Нужно знать, что совместно с ключом /R ключик /D не дефрагментирует базу, а выполняет перезапись путей. Если переключатель /D указан без пути, в качестве пути к файлам базы данных будет использован текущий каталог. Если сразу за переключателем /D следует путь к файлу (без пробелов), этот путь будет использован для поиска файлов базы данных.

Если все же вы хотите использовать альтернативные системные директории, то вам понадобятся ключи /S – для системных файлов, /L – для лог-файлов, /D – для файла базы данных. При этом в данном контексте писать путь нужно НЕ отделяя его пробелом от ключа.

В результате, перейдя в каталог с файлом базы данных (edb), для мягкого восстановления можно использовать следующую команду:

Eseutil /R E00 /D /Ld:\temp\logs /Sd:\temp\logs

clip_image006

Рис.4: Мягкое восстановление базы данных и проверка состояния файла EDB.

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

Если в ходе восстановления вы получаете ошибку:

Operation terminated with error -1216 (JET_errAttachedDatabaseMismatch, An outstanding database attachment has been detected at the start or end of recovery, but database is missing or does not match attachment info)

то к команде следует добавить ключ /i.

Заключение

Если мягкое восстановление прошло удачно и база перешла в состояние Clear Shutdown, значит у вас все получилось и теперь можно монтировать EDB-файл к базе данных восстановления, либо к любой другой базе в этом лесе.

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

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

Александр комментирует...
Этот комментарий был удален автором.
Анонимный комментирует...

Спасибо, помогло поднять группу восстановления в Exchange 2007

Pablo Forestier комментирует...

спасибо Вам, очень помогли!

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

Operation terminated with error -1003 (JET_errInvalidParameter, Invalid API parameter) after 0.0 seconds.

Andrew Belovitsky комментирует...

Алексей, добрый день. А есть ли возможность вывести базу из Dirty Shutdown, если были удалены (запорчены) лог файлы?

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

eseutil /p должно помочь

Владимир Злипух комментирует...

Добрый день!
Ошибка при выполнении
Eseutil /MH MDB.edb
This may have happened due to a corrupted database header.
Explicitly setting a page size might bypass this failure.
Operation terminated with error 1206 jet_errdatabasecorrupted non database file corrupted db
Что делать подскажите ???

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