Пусть не часто, но все же бывают ситуации, когда необходимо произвести какие-либо манипуляции с базой данных почтовых ящиков Exchange на достаточно низком уровне. В подавляющем большинстве случаев необходимость такая возникает в аварийных ситуациях, когда нужно восстановить работоспособность базы, либо в совсем критических случаях, для того, чтобы вытащить из неё как можно больше информации. Процедуру дефрагментации базы в расчет не берем, т.к. сервер Exchange 2010 практически в ней не нуждается.
Так вот, прежде чем приступить к вопросу восстановления нужно понять принцип работы базы данных на сервере Exchange.
Принцип работы базы данных почтовых ящиков
Дело в том, что актуальная информация о состоянии почтовых ящиков пользователей хранится в двух местах:
- в файле с расширением *.EDB – файл самой базы;
- в лог-файлах.
При этом лог-файлов есть несколько видов
- E00.log - это лог файл, используемый в настоящее время механизмом базы данных;
- E00tmp.log - новый лог файл, который создается в текущий момент;
- E00000003A.log, E00000003B.log, E00000003C.log - это лог файлы, хранящиеся на диске, которые можно использовать для восстановления;
- E00res00001.jrs и E00res00002.jrs - это предварительно созданные лог файлы, используемые, когда диск, содержащий лог файлы, заполнен.
Ещё в папке с логами есть файл E00.chk - это файл контрольной точки, используемой для отслеживания отношений между лог-файлами и файлом базы данных.
В результате процесс работы базы данных можно проиллюстрировать следующим образом:
Рис.1: Работа базы данных
- Почтовые данные сначала обрабатываются в памяти, разделяются на страницы (32 Kb – Exchange 2010, 8 Kb – Exchange 2007).
- Обновленные страницы, образующие транзакцию, записываются в лог файл - E00.log.
- Если страницы больше не требуются, они записываются в базу данных.
- Файл контрольной точки (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
Рис.2: Заголовок edb-фала.
Рис.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
Рис.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-файл к базе данных восстановления, либо к любой другой базе в этом лесе.
В случае, если такого не произошло, и мягкое восстановление окончилось неудачей, то стоит прибегнуть к другим методам, о которых мы поговорим в следующей части данной статьи.
8 комментариев:
Спасибо, помогло поднять группу восстановления в Exchange 2007
спасибо Вам, очень помогли!
Operation terminated with error -1003 (JET_errInvalidParameter, Invalid API parameter) after 0.0 seconds.
Алексей, добрый день. А есть ли возможность вывести базу из Dirty Shutdown, если были удалены (запорчены) лог файлы?
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
Что делать подскажите ???
Спасибо, Алексей! ваши посты очень помогают!!
Отправить комментарий