none
Сбой eseutil при попытке восстановления поврежденной базы в exchange 2016 сборка 11 RRS feed

  • Вопрос

  • Сигнатура проблемы:
      Имя события проблемы: APPCRASH
      Имя приложения: eseutil.exe
      Версия приложения: 15.1.1591.12
      Отметка времени приложения: 5bf8cc80
      Имя модуля с ошибкой: ESE.dll
      Версия модуля с ошибкой: 15.1.1591.12
      Отметка времени модуля с ошибкой: 5bf8cbb2
      Код исключения: c0000005
      Смещение исключения: 0000000000143c0d
      Версия ОС: 6.3.9600.2.0.0.272.7
      Код языка: 1049
      Дополнительные сведения 1: 6db4
      Дополнительные сведения 2: 6db47167b8ef4d08d36cec17a9789ee1
      Дополнительные сведения 3: d88a
      Дополнительные сведения 4: d88a3e956fa23fe41c81d1dcab6853a7

    Ознакомьтесь с заявлением о конфиденциальности в Интернете:
      http://go.microsoft.com/fwlink/?linkid=280262

    Если заявление о конфиденциальности в Интернете недоступно, ознакомьтесь с его локальным вариантом:
      C:\Windows\system32\ru-RU\erofflps.txt
    7 февраля 2019 г. 8:26

Ответы

  • Переименуйте файл БД, скопируйте его в отдельный каталог куда угодно.

    Верните оригинальное имя исходнику и копии, потом запустите eseutil для копии, указав папку с логами (иначе eseutil не найдет логи).

    Если не прокатит, можно попробовать подсунуть другие версии ese.dll, но скорее всего это не сработает. Видимо руководство останется без писем.

    p.s. Проблема с дисками для бэкапов у вас совсем не технического характера, это проблема наплевательского отношения к своим обязанностям, к сожалению. Техническая проблема - это когда нет технической возможности что-то сделать (например сервер удаленный без доп. дисков и возможности их поставить, а подключение к инету 100кбит при объеме бэкапа в 100ГБ. Вот это техническая проблема. Но только если действительно нет административных вариантов устранить блокирующие факторы, например купить более широкий канал в инет или докупить железо)

    8 февраля 2019 г. 7:40

Все ответы

  • Доброго дня.

    Выбивает на этапе восстановления базы, при применении команды /p

    Подскажите, что можно сделать?!

    7 февраля 2019 г. 8:28
  • /p - это ключ последней надежды. Вы пробовали Soft Recovery, в этом случае тоже выбивает?
    7 февраля 2019 г. 8:39
  • А с базой у вас вообще что случилось? Можете кинуть вывод команды:

    eseutil.exe /mh database.edb

    И ещё вот этой:

    Get-MailboxDatabaseCopyStatus | ft -AutoSize

    7 февраля 2019 г. 8:53
  • [PS] C:\Users\Администратор.DC01\Desktop>eseutil /mh "D:\MailDatabase\DB01\db01.edb"

    Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
    Version 15.01
    Copyright (C) Microsoft Corporation. All Rights Reserved.

    Initiating FILE DUMP mode...
             Database: D:\MailDatabase\DB01\db01.edb


    DATABASE HEADER:
    Checksum Information:
    Expected Checksum: 0x76284fa8
      Actual Checksum: 0x76284fa8

    Fields:
            File Type: Database
             Checksum: 0x76284fa8
       Format ulMagic: 0x89abcdef
       Engine ulMagic: 0x89abcdef
     Format ulVersion: 0x620,60,120  (attached by 9040)
     Engine ulVersion: 0x620,60,120  (efvCurrent = 9040)
    Created ulVersion: 0x620,20
         DB Signature: Create time:02/07/2019 08:24:39.625 Rand:2669713513 Computer:
             cbDbPage: 32768
               dbtime: 31751289 (0x1e47c79)
                State: Dirty Shutdown
         Log Required: 0-0 (0x0-0x0)
        Log Committed: 0-0 (0x0-0x0)
       Log Recovering: 0 (0x0)
       Log Consistent: 0 (0x0)
      GenMax Creation: 00/00/1900 00:00:00.000 LOC
             Shadowed: Yes
           Last Objid: 46380
         Scrub Dbtime: 0 (0x0)
           Scrub Date: 00/00/1900 00:00:00.000 LOC
         Repair Count: 18
          Repair Date: 02/07/2019 08:24:39.625 UTC
     Old Repair Count: 0
      Last Consistent: (0x0,0,0)  00/00/1900 00:00:00.000 LOC
          Last Attach: (0x0,0,0)  02/07/2019 08:24:39.647 UTC
          Last Detach: (0x0,0,0)  00/00/1900 00:00:00.000 LOC
        Last ReAttach: (0x1252A,2,268)  02/04/2019 06:07:42.997 UTC
                 Dbid: 1
        Log Signature: Create time:00/00/1900 00:00:00.000 Rand:0 Computer:
           OS Version: (6.2.9200 SP 0 NLS 6020e.6020e)

    Previous Full Backup:
            Log Gen: 0-0 (0x0-0x0)
               Mark: (0x0,0,0)
               Mark: 00/00/1900 00:00:00.000 LOC

    Previous Incremental Backup:
            Log Gen: 0-0 (0x0-0x0)
               Mark: (0x0,0,0)
               Mark: 00/00/1900 00:00:00.000 LOC

    Previous Copy Backup:
            Log Gen: 0-0 (0x0-0x0)
               Mark: (0x0,0,0)
               Mark: 00/00/1900 00:00:00.000 LOC

    Previous Differential Backup:
            Log Gen: 0-0 (0x0-0x0)
               Mark: (0x0,0,0)
               Mark: 00/00/1900 00:00:00.000 LOC

    Current Full Backup:
            Log Gen: 0-0 (0x0-0x0)
               Mark: (0x0,0,0)
               Mark: 00/00/1900 00:00:00.000 LOC

    Current Shadow copy backup:
            Log Gen: 0-0 (0x0-0x0)
               Mark: (0x0,0,0)
               Mark: 00/00/1900 00:00:00.000 LOC

         cpgUpgrade55Format: 0
        cpgUpgradeFreePages: 0
    cpgUpgradeSpaceMapPages: 0

           ECC Fix Success Count: none
       Old ECC Fix Success Count: none
             ECC Fix Error Count: none
         Old ECC Fix Error Count: none
        Bad Checksum Error Count: none
    Old bad Checksum Error Count: none

      Last Database Maintenance Finish Date: 00/00/1900 00:00:00.000 LOC
    Current Database Maintenance Start Date: 02/04/2019 05:11:04.034 UTC
          Highest Continuous Database Maintenance Page: 0
          Highest Database Maintenance Page: 0

      Database Header Flush Signature: Create time:02/07/2019 08:24:39.655 Rand:207645170 Computer:
     Flush Map Header Flush Signature: Create time:02/07/2019 08:24:39.648 Rand:3070997450 Computer:


    Operation completed successfully in 0.140 seconds.

    [PS] C:\Users\Администратор.DC01\Desktop>














    7 февраля 2019 г. 8:58
  • Случилось невозможное: отпал диск с базой и диск с бэкапом. Была проблема с железом. Все восстановил, кроме лог файла
    7 февраля 2019 г. 9:00
  • при попытке сделать с логом вылетает ошибка:

    [PS] C:\Users\Администратор.DC01\Desktop>eseutil /r "D:\MailDatabase\DB01\E01.log"

    Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
    Version 15.01
    Copyright (C) Microsoft Corporation. All Rights Reserved.

    Initiating RECOVERY mode...
        Logfile base name: D:\MailDatabase\DB01\E01.log
                Log files: <current directory>
             System files: <current directory>

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



    [PS] C:\Users\Администратор.DC01\Desktop>

    7 февраля 2019 г. 9:01
  • [PS] C:\Users\Администратор.DC01\Desktop>Get-MailboxDatabaseCopyStatus | ft -AutoSize

    Name                               Status     CopyQueueLength ReplayQueueLength LastInspectedLogTime ContentIndexState
    ----                               ------     --------------- ----------------- -------------------- -----------------
    Mailbox Database 0594766762\EXCH01 Mounted    0               0                                      FailedAndSuspended
    DB01\EXCH01                        Dismounted 0               0                                      Failed
    DB02\EXCH01                        Mounted    0               0                                      Healthy
    7 февраля 2019 г. 12:13
  • при попытке сделать с логом вылетает ошибка:

    [PS] C:\Users\Администратор.DC01\Desktop>eseutil /r "D:\MailDatabase\DB01\E01.log"

    Синтаксис неправильный, без .log надо

    eseutil /R "D:\MailDatabase\DB01\E01"

    7 февраля 2019 г. 19:40
  • Такое ощущение, что у вас эксч установлен на КД. Это так?

    Покажите какую команду вы выполняете, чтобы восстановить базу.

    Также почитайте статью: https://blog.bissquit.com/mail-servers/exchange-server/vosstanovlenie-baz-dannyh-exchange-2013/

    7 февраля 2019 г. 19:44
  • [PS] C:\Users\Администратор.DC01\Desktop>eseutil /R "D:\MailDatabase\DB01\E01"

    Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
    Version 15.01
    Copyright (C) Microsoft Corporation. All Rights Reserved.

    Initiating RECOVERY mode...
        Logfile base name: D:\MailDatabase\DB01\E01
                Log files: <current directory>
             System files: <current directory>

    Operation terminated with error -1003 (JET_errInvalidParameter, Invalid API parameter) after 0.0 seconds.
    7 февраля 2019 г. 20:31
  • Да, действительно exch поднят на DC. Это сильно критично?

    Команда на восстановление:

    eseutil /p "D:\MailDatabase\DB01\db01.edb"

    7 февраля 2019 г. 20:33
  •  статью: https://blog.bissquit.com/mail-servers/exchange-server/vosstanovlenie-baz-dannyh-exchange-2013/ читал. Выбивает eseutil((( Ошибка в вверху обсуждения....
    7 февраля 2019 г. 20:36
  • в настоящий момент поднята новая база DB02. Ящики от испорченной базы отключены, в новой созданы заново и восстановлены из локальный кешей outlook. Но, именно у руководства локальный кеш был выключен. Сейчас стоит задача как то содержимое некоторых ящиков выдернуть из старой базы. А eseutil отказывается работать((
    7 февраля 2019 г. 20:41
  • А бэкапы?

    Вы уверены, что базу никто не использует? Проверить легко - попробовать переименовать файл и если получится, значит он никем не используется. Не забудьте вернуть прежнее имя.

    8 февраля 2019 г. 5:29
  • Файл с базой переименовывается легко. Однако каталог переименовать не получается. exch периодически пытается базу подключить и флудит ошибками.

    Бэкапов к сожалению нет по техническим причинам. Диск под бэкапы сдох((

    8 февраля 2019 г. 7:33
  • Переименуйте файл БД, скопируйте его в отдельный каталог куда угодно.

    Верните оригинальное имя исходнику и копии, потом запустите eseutil для копии, указав папку с логами (иначе eseutil не найдет логи).

    Если не прокатит, можно попробовать подсунуть другие версии ese.dll, но скорее всего это не сработает. Видимо руководство останется без писем.

    p.s. Проблема с дисками для бэкапов у вас совсем не технического характера, это проблема наплевательского отношения к своим обязанностям, к сожалению. Техническая проблема - это когда нет технической возможности что-то сделать (например сервер удаленный без доп. дисков и возможности их поставить, а подключение к инету 100кбит при объеме бэкапа в 100ГБ. Вот это техническая проблема. Но только если действительно нет административных вариантов устранить блокирующие факторы, например купить более широкий канал в инет или докупить железо)

    8 февраля 2019 г. 7:40
  • Копия базы запускалась для восстановления с другого диска. проблема та же - глюк в eseutil.

    Свои обязанности я знаю))) в данном случае устраняю чужие ошибки)

    Замена ese.dll ведет к ошибки winnt.dll и не решает проблему. Вопрос: куда можно выслать описание данного глюка, дабы гении от microsoft его прокомментировали... Получается что последняя сборка (11) 16 экса кривая!

    8 февраля 2019 г. 11:43
  • Вопрос похоже заглох....

    Перенес базу на другой 2016 эксч четвертой сборки. Та же самая ошибка....

    Господа, есть возможность как то донести эту проблему до специалистов?

    12 февраля 2019 г. 16:36

  • Господа, есть возможность как то донести эту проблему до специалистов?

    Создайте кейс в поддержку. Но учтите, что никто вам моментально не выпустит хотфикс и не исправит проблему, так что надеяться на быстрое рассмотрение обращения не стоит.
    12 февраля 2019 г. 18:41