Home Без рубрики Unable to mount database — Восстановление базы Exchange Dirty Shutdown 380gb

Unable to mount database — Восстановление базы Exchange Dirty Shutdown 380gb

by admin

Ошибка базы

[PS] C:\Windows\system32>Mount-Database DB_TEMP_2011_2006

Confirm
At least one committed transaction log file is missing. Mounting this database will result in data loss. If you can
locate the missing log files, don't continue. Are you sure you want to continue?
[Y] Yes [A] Yes to All [N] No [L] No to All [?] Help (default is "Y"): A
Failed to mount database "DB_TEMP_2011_2006". Error: An Active Manager operation failed. Error: The database action
failed. Error: Operation failed with message: MapiExceptionJetErrorRequiredLogFilesMissing: Unable to mount database.
(hr=0x80004005, ec=-543)
Diagnostic context:
Lid: 65256
Lid: 10722 StoreEc: 0xFFFFFDE1
Lid: 1494 ---- Remote Context Beg ----
Lid: 1238 Remote Context Overflow
Lid: 34760 StoreEc: 0xFFFFFDE1
Lid: 41344 Guid: 680b5538-3fad-49fa-8d95-f7c8b47a6ca6
Lid: 35200 dwParam: 0x6DE0
Lid: 59596 dwParam: 0x2271F6AE Msg: JI20
Lid: 43212 dwParam: 0x2271F6AE Msg: JT05
Lid: 43212 dwParam: 0x2271F6AE Msg: JT08
Lid: 59596 dwParam: 0x2271F6AE Msg: WM19
Lid: 59596 dwParam: 0x2271F6AE Msg: WM20
Lid: 59596 dwParam: 0x2271F6AE Msg: WM21
Lid: 56264 StoreEc: 0x980
Lid: 46280 StoreEc: 0xFFFFFDE1
Lid: 10786 dwParam: 0x0 Msg: 15.02.1544.004:V19MBX1:680b5538-3fad-49fa-8d95-f7c8b47a6ca6
Lid: 51578 Guid: 680b5538-3fad-49fa-8d95-f7c8b47a6ca6
Lid: 1750 ---- Remote Context End ----
Lid: 1047 StoreEc: 0xFFFFFDE1 [Database: DB_TEMP_2011_2006, Server: V19MBX2.CTDRUS.loc]
+ CategoryInfo : InvalidOperation: (DB_TEMP_2011_2006:ADObjectId) [Mount-Database], InvalidOperationExcep
tion
+ FullyQualifiedErrorId : [Server=V19MBX1,RequestId=7f1dfc8b-f98e-426e-9ecc-5bc364e7a127,TimeStamp=12/16/2024 2:32
:27 PM] [FailureCategory=Cmdlet-InvalidOperationException] 2D27BA9D,Microsoft.Exchange.Management.SystemConfigurat
ionTasks.MountDatabase
+ PSComputerName : v19mbx1.ctdrus.loc

Проверим состояние базы

[PS] C:\Windows\system32>Eseutil /mh E:\Database\DB_TEMP_2011_2006\DB_TEMP_2011_2006.edb

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

Initiating FILE DUMP mode...
         Database: E:\Database\DB_TEMP_2011_2006\DB_TEMP_2011_2006.edb


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

Fields:
        File Type: Database
         Checksum: 0xb1fc8819
   Format ulMagic: 0x89abcdef
   Engine ulMagic: 0x89abcdef
 Format ulVersion: 0x620,20,0  (attached by 0)
 Engine ulVersion: 0x620,60,140  (efvCurrent = 9060)
Created ulVersion: 0x620,20
     DB Signature: Create time:11/02/2022 13:42:05.242 Rand:3548611131 Computer:
         cbDbPage: 32768
           dbtime: 170213332 (0xa253fd4)
            State: Dirty Shutdown
     Log Required: 547808-547910 (0x85be0-0x85c46)
    Log Committed: 0-547911 (0x0-0x85c47)
   Log Recovering: 543317 (0x84a55)
   Log Consistent: 547808 (0x85be0)
  GenMax Creation: 12/16/2024 13:50:09.007 UTC
         Shadowed: Yes
       Last Objid: 10507
     Scrub Dbtime: 0 (0x0)
       Scrub Date: 00/00/1900 00:00:00.000 LOC
     Repair Count: 0
      Repair Date: 00/00/1900 00:00:00.000 LOC
 Old Repair Count: 0
  Last Consistent: (0x76DA6,D8,B0)  02/23/2024 12:14:05.386 UTC
      Last Attach: (0x76DA7,2,268)  02/23/2024 13:16:25.908 UTC
      Last Detach: (0x0,0,0)  00/00/1900 00:00:00.000 LOC
    Last ReAttach: (0x844BD,2,268)  12/09/2024 22:02:13.610 UTC
             Dbid: 1
    Log Signature: Create time:11/02/2022 13:42:05.195 Rand:2981120043 Computer:
       OS Version: (6.2.9200 SP 0 NLS ffffffff.ffffffff)

Previous Full Backup:
        Log Gen: 494404-494533 (0x78b44-0x78bc5) - OSSnapshot
           Mark: (0x78BC6,1,0)
           Mark: 05/05/2024 11:02:18.055 UTC

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: 10/17/2024 19:58:48.023 UTC
      Highest Continuous Database Maintenance Page: 0
      Highest Database Maintenance Page: 0

  Database Header Flush Signature: Create time:12/16/2024 14:37:12.211 Rand:3345693962 Computer:
 Flush Map Header Flush Signature: Create time:00/00/1900 00:00:00.000 Rand:0 Computer:

Проверяем путь до базы

[PS] C:\Windows\system32>Get-MailboxDatabase -identity DB_TEMP_2011_2006 | fl Name,EdbFilePath,LogFolderPath


Name          : DB_TEMP_2011_2006
EdbFilePath   : E:\Database\DB_TEMP_2011_2006\DB_TEMP_2011_2006.edb
LogFolderPath : F:\DB_TEMP_2011_2006
Восстановите файл базы данных с помощью файлов журнала:
Сначала проверьте состояние файлов журнала, используя следующую команду.
eseutil /ml "F:\DB_TEMP_2011_2006\E00″

[PS] C:\Windows\system32>eseutil /ml "F:\DB_TEMP_2011_2006\E00"

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

Initiating FILE DUMP mode...

Verifying log files...
Base name: E00

Log file: F:\DB_TEMP_2011_2006\E0000078B44.log - OK
Log file: F:\DB_TEMP_2011_2006\E0000078B45.log - OK
Log file: F:\DB_TEMP_2011_2006\E0000078B46.log - OK
Log file: F:\DB_TEMP_2011_2006\E0000078B47.log - OK
Log file: F:\DB_TEMP_2011_2006\E0000078B48.log - OK
Log file: F:\DB_TEMP_2011_2006\E0000078B49.log - OK
Log file: F:\DB_TEMP_2011_2006\E0000078B4A.log - OK
Log file: F:\DB_TEMP_2011_2006\E0000078B4B.log - OK
Log file: F:\DB_TEMP_2011_2006\E0000078B4C.log - OK
Log file: F:\DB_TEMP_2011_2006\E0000078B4D.log - OK
Log file: F:\DB_TEMP_2011_2006\E0000078B4E.log - OK
Log file: F:\DB_TEMP_2011_2006\E0000078B4F.log - OK

Запускаем восстановление базы . При колличестве 80к логов и размера базы в 380гб , восстановление длилось 61 минуту.

Eseutil /r E00 /l F:\DB_TEMP_2011_2006 /d E:\Database\DB_TEMP_2011_2006\DB_TEMP_2011_2006.edb /i

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

Initiating RECOVERY mode...
    Logfile base name: E00
            Log files: F:\DB_TEMP_2011_2006
         System files: <current directory>
   Database Directory: E:\Database\DB_TEMP_2011_2006\DB_TEMP_2011_2006.edb

Performing soft recovery...
                      Restore Status (% complete)

          0    10   20   30   40   50   60   70   80   90  100
          |----|----|----|----|----|----|----|----|----|----|
          ...................................................



Operation completed successfully in 4274.250 seconds.

Проверяем еще раз

[PS] C:\Windows\system32>Eseutil /mh E:\Database\DB_TEMP_2011_2006\DB_TEMP_2011_2006.edb

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

Initiating FILE DUMP mode...
         Database: E:\Database\DB_TEMP_2011_2006\DB_TEMP_2011_2006.edb


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

Fields:
        File Type: Database
         Checksum: 0x6caaad10
   Format ulMagic: 0x89abcdef
   Engine ulMagic: 0x89abcdef
 Format ulVersion: 0x620,20,0  (attached by 0)
 Engine ulVersion: 0x620,60,140  (efvCurrent = 9060)
Created ulVersion: 0x620,20
     DB Signature: Create time:11/02/2022 13:42:05.242 Rand:3548611131 Computer:
         cbDbPage: 32768
           dbtime: 193843538 (0xb8dd152)
            State: Dirty Shutdown
     Log Required: 543320-543320 (0x84a58-0x84a58)
    Log Committed: 0-543321 (0x0-0x84a59)
   Log Recovering: 0 (0x0)
   Log Consistent: 543320 (0x84a58)
  GenMax Creation: 12/16/2024 16:07:21.497 UTC
         Shadowed: Yes
       Last Objid: 11127
     Scrub Dbtime: 0 (0x0)
       Scrub Date: 00/00/1900 00:00:00.000 LOC
     Repair Count: 0
      Repair Date: 00/00/1900 00:00:00.000 LOC
 Old Repair Count: 0
  Last Consistent: (0x84A56,1,31)  12/16/2024 16:07:13.858 UTC
      Last Attach: (0x84A56,5,268)  12/16/2024 16:07:21.400 UTC
      Last Detach: (0x0,0,0)  00/00/1900 00:00:00.000 LOC
    Last ReAttach: (0x84A59,2,268)  12/16/2024 17:45:21.674 UTC
             Dbid: 1
    Log Signature: Create time:11/02/2022 13:42:05.195 Rand:2981120043 Computer:
       OS Version: (6.2.9200 SP 0 NLS ffffffff.ffffffff)

Previous Full Backup:
        Log Gen: 494404-494533 (0x78b44-0x78bc5) - OSSnapshot
           Mark: (0x78BC6,1,0)
           Mark: 05/05/2024 11:02:18.055 UTC

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: 10/17/2024 19:58:48.023 UTC
      Highest Continuous Database Maintenance Page: 0
      Highest Database Maintenance Page: 0

  Database Header Flush Signature: Create time:12/16/2024 17:45:21.674 Rand:205634769 Computer:
 Flush Map Header Flush Signature: Create time:00/00/1900 00:00:00.000 Rand:0 Computer:


Operation completed successfully in 0.110 seconds.

[PS] C:\Windows\system32>

В логах указано, что для восстановления необходим только один лог: 543320-543320. Убедитесь, что файл лога с именем E00543320.log находится в директории F:\DB_TEMP_2011_2006.

Лога нет придется восстановится хардом и так что мы имеем

Состояние базы данных:

State: Dirty Shutdown

База данных не была корректно закрыта. Это значит, что есть изменения, которые хранятся в логах, но ещё не применены к базе .edb.

Требуемые логи (Log Required):

Log Required: 543320-543320 (0x84a58-0x84a58)

База данных ожидает применения транзакционного лога с номером 543320. Этот лог содержит незавершённые транзакции, которые не были записаны в файл базы данных .edb.

Последний зафиксированный лог (Log Committed):

Log Committed: 0-543321 (0x0-0x84a59)

Это значит, что все операции до лога с номером 543320 (и включая его) были зафиксированы в логах, но не все из них перенесены в .edb. Лог 543321 является первым логом, который был полностью завершён.

Последнее согласованное состояние базы (Last Consistent):

Last Consistent: (0x84A56,1,31)  12/16/2024 16:07:13.858 UTC

Это последний момент времени, до которого база данных была полностью согласованной. Изменения, произошедшие после этого времени, ещё не записаны в файл .edb — они находятся в логах.

Последний присоединённый лог (Last Attach):

Last Attach: (0x84A56,5,268)  12/16/2024 16:07:21.400 UTC

Это время последней попытки работы базы данных с логами. Здесь видно, что база данных пыталась обработать изменения, записанные в логах, но операция не была завершена.

Что произойдет при Hard Repair (eseutil /p )

На какой момент вы откатитесь?

Hard Repair удалит из базы данных .edb все ссылки на транзакции, которые хранятся в логах и ещё не были применены. База данных будет восстановлена на момент времени, указанного в Last Consistent

Last Consistent: 12/16/2024 16:07:13.858 UTC

Все данные и изменения, которые произошли после 16:07:13 16 декабря 2024 года, будут утеряны. Это включает все письма, созданные, отправленные, удалённые или изменённые после этого времени.

Поскольку Hard Repair игнорирует логи (Log Required), любые данные, находящиеся в этих логах, не будут применены. Даже если эти логи физически присутствуют на диске, они больше не будут связаны с базой после Hard Repair.

Всё, что было зафиксировано в базе до Last Consistent (12/16/2024 16:07:13), сохранится. Если логи 543320 и 543321 важны, попробуйте сначала сохранить их копии если такова есть. Если это невозможно, то Hard Repair — ваш последний вариант.

Hard Repair просто отбрасывает все незавершённые транзакции из логов, потому что цель этой операции — «починить» базу .edb, даже если для этого приходится терять часть данных.

Hard Repair базы данных с помощью утилиты Eseutil

еред жестким восстановлением сделайте резервную копию базы данных и убедитесь, что на диске достаточно свободного места (эквивалентно размеру базы данных). Обязательно нужно столько места сводобного сколько весит база +10%

eseutil /p "E:\Database\DB_TEMP_2011_2006\DB_TEMP_2011_2006.edb"

Большие базы данных (>100 ГБ): Восстановление может занять несколько часов или даже дней, в зависимости от состояния базы и логов.

3 часа процесс

Конечный результат. 419 минут = 7 часов

После завершения eseutil /p, обязательно выполните проверку базы данных с помощью команды /mh:

eseutil /mh "E:\Database\DB_TEMP_2011_2006\DB_TEMP_2011_2006.edb"

Проверьте, чтобы состояние изменилось на Clean Shutdown. Если база данных успешно восстановлена и находится в состоянии Clean Shutdown, она может быть смонтирована в Exchange.

После восстановления пользователи имели доступ к почтовым ящикам , но отправить и получить ничего не могли. Outlook писал что подключено, отключено . Множетсво почтовых ящиков падали в карантин.
Выход миграция в PST или миграция в другую базу.

You may also like

Leave a Comment