none
Ошибка подключения архивной базы. RRS feed

  • Вопрос

  • Добрый день!

    Из-за нехватки места на дисках отвалились две архивные базы MDB-ARCH-04 и MDB-ARCH-05.

    Начал заниматься реанимацией.

    Что сделал:

    1) Добавил по 300 Гб к каждому виртуальному диску для того, чтобы можно было сделать repair баз данных (Собственно повреждены не сами базы и данные в них, а логи транзакций).

    2) В соответствии с мануалом Microsoft сделал следующее:

    * определил состояние баз (ESEUTIL /MH выдал Clean Shutdown, что вселяло определенные надежды, что сами данные в базе не повреждены)

    * определил поврежденный файл лога

    * удалил поврежденный файл

    * произвел операцию восстановления БД при помощи eseutil /P.

    3) Подключил базы

    В результате удалось восстановить и подключить базу MDB-ARCH-04, база MDB-ARCH-05 не подключилась, выдает множественные ошибки при подключении: 

    Не удалось подключить базу данных MDB-ARCH-05. Ошибка: Сбой операции Active Manager. Ошибка: The database action failed. Error: Operation failed with message: MapiExceptionDatabaseError: Unable to mount database. (hr=0x80004005, ec=1108) Diagnostic context: Lid: 65256 Lid: 10722 StoreEc: 0x454 Lid: 1494 ---- Remote Context Beg ---- Lid: 45120 dwParam: 0x825C60 Lid: 57728 dwParam: 0x825D2B Lid: 53632 dwParam: 0x825E44 Lid: 61824 dwParam: 0x825E44 Lid: 46144 dwParam: 0x825F00 Lid: 34880 dwParam: 0x825F7D Lid: 34760 StoreEc: 0xFFFFFC07 Lid: 41344 Guid: 50409975-9c76-4bb9-805e-d10c78547559 Lid: 35200 dwParam: 0x9DE4 Lid: 46144 dwParam: 0x826EDE Lid: 34880 dwParam: 0x826EDE Lid: 54472 StoreEc: 0x1388 Lid: 42184 StoreEc: 0x454 Lid: 1750 ---- Remote Context End ---- Lid: 1047 StoreEc: 0x454 [База данных: MDB-ARCH-05, Сервер: *******

    Что бы вы могли в данной ситуации посоветовать? 


    18 декабря 2017 г. 12:23

Ответы

  • Не обязательно покупать для разовой процедуры. Рецепт вот тут, сэкономленные средства можете высылать мне. 

    • Помечено в качестве ответа Volzek 7 февраля 2018 г. 7:26
    25 декабря 2017 г. 6:42
  • Так уже Clean Shutdownесть ТС написал, нет?

    eseutil /P ключик такой ключик...  Попробуйте только файл базы оставить и монтировать. Есть еще ключ -force при монтировании ,надо хорошенько помолиться и попоститься перед его использованием, может не помочь.

    Ну и до волшебства /P надо было РК сделать всего добра. Есть способ сконструлить новую базу из логов, если они тоже есть  и присутствуют. Хоть что-то вытащите, есть мнение что базу уже не поднять и надо искать хоть и старый но бэкап.

    • Помечено в качестве ответа Volzek 21 декабря 2017 г. 5:08
    18 декабря 2017 г. 14:40

Все ответы

  • Добрый день,

    Базу чините до состояния Clean Shutdown. Переносите от этой БД все логи, файл .chk куда нибудь во временную локацию, в общем оставляете только файл .edb. Монтируете.

    18 декабря 2017 г. 12:40
  • Так уже Clean Shutdownесть ТС написал, нет?

    eseutil /P ключик такой ключик...  Попробуйте только файл базы оставить и монтировать. Есть еще ключ -force при монтировании ,надо хорошенько помолиться и попоститься перед его использованием, может не помочь.

    Ну и до волшебства /P надо было РК сделать всего добра. Есть способ сконструлить новую базу из логов, если они тоже есть  и присутствуют. Хоть что-то вытащите, есть мнение что базу уже не поднять и надо искать хоть и старый но бэкап.

    • Помечено в качестве ответа Volzek 21 декабря 2017 г. 5:08
    18 декабря 2017 г. 14:40
  • Добрый день! Спасибо за ответы, но данное решение, увы, не помогло. У меня есть подозрения, что в данном случае проблема возможно не совсем с базой, а с файловой системой NTFS. Например, ей не хватало места на разделе для хранения системной информации или копии MFT. Возможно, после проверки диска с БД чекдиском базу удастся подключить. Как вы считаете, целесообразна подобная проверка, и не приведёт ли она к более плачевной картине?

    19 декабря 2017 г. 7:06
  • Не удастся, потому что был ключ /р уже. Вы же внимательно прочитали справку как им пользоваться, напугались предупреждений ,что можете потерять данные? Или ловко нагуглили в превом попавшемся блоге жгучего брюнета? Плохо, если так. Сделайте нужные выводы.

    Чекдиск во-первых долгий, во-вторых медленный. В-третьих, он не поможет с  ese. Будет здорово (для Вас) если, конечно окажется что я неправ, но по мне это пустая трата времени. Если для Вас это последняя надежда, можете запустить. Если объем диска большой, можно запланировать такую работу на выходные дни, чтобы влезть в окно. А вообще, я бы предложил бы не трогать чекдиск, а извлечь из этого правильные уроки:

    а) отсутствие оповещений зло

    б) отсутствие рк зло вдвойне

    в) ничегонеделание и не планирование будущих задач самое злейшее из зол.

    Всех благ.

    19 декабря 2017 г. 7:27
  • Навряд ли вам уже поможет checkdisk после того как сделали hard recovery, да и если БД уже в Clean Shutdown.
    19 декабря 2017 г. 7:50
  • ТС, можете прояснить, вы точно попробовали смонтировать отремонтированную базу MDB-ARCH-05 без логов, как вам написали ?

    Мне что-то кажется, что нет. Не мог вам eseutil выдать clean shutdown, если база на самом деле побита.

    21 декабря 2017 г. 10:12
  • Да, все файлы кроме самой базы я перенёс в другое место и попытался смонтировать, ничего не вышло, ошибки те же. 
    21 декабря 2017 г. 11:46
  • Ну, или вы что-то путаете (например, почистили логи не в той папке), или вам действительно с базой уже ничего не сделать.

    22 декабря 2017 г. 11:50
  • Нет, напутать невозможно, есть сбойная база и именно в ней я очистил всё, кроме *.Edb базы. Сторонним софтом я вижу содержимое, т.е все архивные ящики. Если ничего не выйдет, то придётся покупать программу и выковыривать содержимое в PST. 
    25 декабря 2017 г. 5:20
  • Не обязательно покупать для разовой процедуры. Рецепт вот тут, сэкономленные средства можете высылать мне. 

    • Помечено в качестве ответа Volzek 7 февраля 2018 г. 7:26
    25 декабря 2017 г. 6:42