Ошибка MapiExceptionDatabaseError (hr=0x80004005, ec=1108) при монтировании базы данных Exchange в большинстве случаев указывает на то, что база данных была отключена нештатно, и теперь её состояние —
Dirty Shutdown ("грязное" завершение работы). Это часто происходит из-за нехватки места на диске с логами транзакций. Ваш диагностический контекст очень похож на те, что описываются в подобных ситуациях.
Вот пошаговый план по устранению проблемы.
Шаг 1: Диагностика состояния базы данных
Первым делом нужно проверить текущее состояние базы данных с помощью утилиты eseutil. Запустите командную строку или Exchange Management Shell от имени администратора и выполните команду:
eseutil /mh "полный_путь_к_вашей_базе_данных.edb"
В выводе найдите строку State:. Если вы видите
State: Dirty Shutdown, это подтверждает диагноз. База данных ждет применения транзакционных логов, которые либо отсутствуют, либо повреждены, либо диск с ними был переполнен.
Шаг 2: Попытка мягкого восстановления (Soft Recovery)
Если база в состоянии Dirty Shutdown, и у вас есть все необходимые логи, Exchange может восстановить ее самостоятельно. Выполните мягкое восстановление:
eseutil /r "E00" /l "путь_к_папке_с_логами" /d "путь_к_папке_с_базой"
- E00 — это префикс файлов логов (обычно E00, E01, E02 и т.д.). Нужно указать тот, который соответствует вашей базе.
- Эта команда попытается применить все ожидающие транзакции к базе данных.
После выполнения снова проверьте состояние командой eseutil /mh. Если состояние стало
State: Clean Shutdown, база готова к монтированию.
Шаг 3: Жесткое восстановление (Hard Recovery) — Крайняя мера
Если мягкое восстановление не помогло и состояние базы осталось Dirty Shutdown, единственным вариантом (кроме восстановления из бэкапа) является жесткое восстановление командой eseutil /p.
Это крайняя мера, которая может привести к потере данных, и Microsoft не рекомендует использовать восстановленные таким образом базы в продакшене без последующего перемещения всех почтовых ящиков в новую БД.
eseutil /p "полный_путь_к_вашей_базе_данных.edb"
После завершения команды
обязательно снова проверьте состояние базы (eseutil /mh). Оно должно стать Clean Shutdown.
Шаг 4: Перемещение логов и монтирование базы
Иногда, даже если база в Clean Shutdown, она не монтируется из-за проблем с логами или контрольными точками. В этом случае помогает следующий прием:
- Переместите ВСЕ файлы из папки с логами транзакций вашей базы данных (файлы с расширениями .log, .jrs, .chk) во временную папку на другом диске. Оставьте в исходной папке только файл базы данных (.edb).
- Выполните команду монтирования:
Mount-Database -Identity "DATABASE22"
Если база смонтировалась, Exchange создаст новые, пустые логи.
Шаг 5: Действия после успешного монтирования
Если вам пришлось использовать eseutil /p или перемещать логи, не считайте проблему полностью решенной.
- Немедленно создайте полную резервную копию базы данных. Это очистит накопившиеся логи и создаст новую точку восстановления.
- Запланируйте создание новой базы данных и переместите все почтовые ящики из восстановленной базы в новую. База данных, восстановленная через /p, считается ненадежной, и ее использование в долгосрочной перспективе не рекомендуется.
Альтернативная причина: Права доступа
В редких случаях ошибка 0x80004005 может быть связана с отсутствием права
"Управление аудитом и журналом безопасности" для группы DomainName\Exchange Servers на сервере. Это можно проверить через secpol.msc -> Локальные политики -> Назначение прав пользователя. Однако, гораздо чаще проблема кроется именно в состоянии базы данных.
Резюме
- Проверьте состояние: eseutil /mh "путь\DATABASE22.edb". Скорее всего, увидите Dirty Shutdown.
- Проверьте свободное место на дисках с базой и логами.
- Попробуйте мягкое восстановление: eseutil /r E00 /l "путь\логи" /d "путь\база".
- Если не помогло, примените жесткое восстановление (eseutil /p), осознавая риски потери данных.
- Переместите старые логи во временную папку и смонтируйте базу.
- Сделайте бэкап и спланируйте миграцию почтовых ящиков в новую, здоровую базу.
Пожалуйста, будьте предельно осторожны с командой eseutil /p и, если возможно, перед ее выполнением восстановите базу данных из последней резервной копии.