Решено БД не монтируется

Облако на базе VMware

Fedor

Активный участник
11.05.2018
337
20
18
Добрый день! Несколько БД в Exchange server 2019 стали в статусе unmounted, при попытке смонтировать БД вижу ошибку:
Failed to mount database "DATABASE22". Error: An Active Manager operation failed. Error: The database action failed. Error: Operation failed with message: MapiExceptionDatabaseError: Unable to mount database. (hr=0x80004005, ec=1108)
Помогите починить БД и найти причину падения баз
 
Ошибка 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, она не монтируется из-за проблем с логами или контрольными точками. В этом случае помогает следующий прием:
  1. Переместите ВСЕ файлы из папки с логами транзакций вашей базы данных (файлы с расширениями .log, .jrs, .chk) во временную папку на другом диске. Оставьте в исходной папке только файл базы данных (.edb).
  2. Выполните команду монтирования:
    Mount-Database -Identity "DATABASE22"
    Если база смонтировалась, Exchange создаст новые, пустые логи.

Шаг 5: Действия после успешного монтирования​

Если вам пришлось использовать eseutil /p или перемещать логи, не считайте проблему полностью решенной.
  1. Немедленно создайте полную резервную копию базы данных. Это очистит накопившиеся логи и создаст новую точку восстановления.
  2. Запланируйте создание новой базы данных и переместите все почтовые ящики из восстановленной базы в новую. База данных, восстановленная через /p, считается ненадежной, и ее использование в долгосрочной перспективе не рекомендуется.

Альтернативная причина: Права доступа​

В редких случаях ошибка 0x80004005 может быть связана с отсутствием права "Управление аудитом и журналом безопасности" для группы DomainName\Exchange Servers на сервере. Это можно проверить через secpol.msc -> Локальные политики -> Назначение прав пользователя. Однако, гораздо чаще проблема кроется именно в состоянии базы данных.

Резюме​

  1. Проверьте состояние: eseutil /mh "путь\DATABASE22.edb". Скорее всего, увидите Dirty Shutdown.
  2. Проверьте свободное место на дисках с базой и логами.
  3. Попробуйте мягкое восстановление: eseutil /r E00 /l "путь\логи" /d "путь\база".
  4. Если не помогло, примените жесткое восстановление (eseutil /p), осознавая риски потери данных.
  5. Переместите старые логи во временную папку и смонтируйте базу.
  6. Сделайте бэкап и спланируйте миграцию почтовых ящиков в новую, здоровую базу.
Пожалуйста, будьте предельно осторожны с командой eseutil /p и, если возможно, перед ее выполнением восстановите базу данных из последней резервной копии.
 
Облако на базе VMware
Место закончилось, уже сам разобрался. Но всем спасибо кто откликнулся✌️
 
Облако на базе VMware