none
Дефрагментация БД RRS feed

  • Вопрос

  • Делаю дефрагментацию БД. Размер очень большой, около 850 ГБ. Сам процесс выполняется уже вторые сутки, выполнено менее 50%. Так как завтра рабочий день новой недели, то естественно, всё должно работать, но в этой БД очень много "основных" пользователей, которым почта просто необходима.

    Собственно вопрос - можно прервать процесс дефрагментации, потому что по всем показателям, даже к обеду, а то и вечеру завтрашнего дня, процесс этот не закончится (( 

    Спасибо!

    21 июня 2020 г. 15:15

Все ответы

  • При дефрагментации eseutil /d записывает информацию из исходной БД во временный файл БД (он называется по умолчанию temp-что-то-там.edb, этот файл можно задать через ключ /t), а по окончании процесса удаляет исходный файл БД и переименовывает или копирует временный файл с именем исходного файла БД. Если процесс прервать, то исходный файл БД просто останется нетронутым (а времнный файл eseutil, если ее прервать по Ctrl+C, кажется, удаляет сама).

    PS Если будете дефрагментировать в следующий раз, то задайте расположение временной БД через ключ /t на другом физическом диске (если вы это ещё не сделали и если есть такая возможность). Это может сильно ускорить процесс, т.к. диску не придется двигать головки от одного файла к другому.


    Слава России!


    • Изменено M.V.V. _ 21 июня 2020 г. 15:35
    21 июня 2020 г. 15:34
  • При дефрагментации eseutil /d записывает информацию из исходной БД во временный файл БД (он называется по умолчанию temp-что-то-там.edb, этот файл можно задать через ключ /t), а по окончании процесса удаляет исходный файл БД и переименовывает или копирует временный файл с именем исходного файла БД. Если процесс прервать, то исходный файл БД просто останется нетронутым (а времнный файл eseutil, если ее прервать по Ctrl+C, кажется, удаляет сама).

    PS Если будете дефрагментировать в следующий раз, то задайте расположение временной БД через ключ /t на другом физическом диске (если вы это ещё не сделали и если есть такая возможность). Это может сильно ускорить процесс, т.к. диску не придется двигать головки от одного файла к другому.


    Слава России!


    Спасибо! Да, наверное моя ошибка как раз в том, что и сама БД и темповый файл БД, находятся на одном и том же диске (( отсюда, скорее всего, и скорость такая низкая ((

    21 июня 2020 г. 15:56
  • С таким объёмом БД процесс дефрагментации априори не будет быстрым независимо от того где будет расположена новая база.

    Если ваша цель уменьшить white space, то почему вы просто не хотите мигрировать пя в новую БД? Как минимум это не доставит неудобств пользователям, да и ваша нервная система не пострадает.

    21 июня 2020 г. 19:19
  • Выполнил дефрагментацию, темповый файл БД стал существенно меньше, но встал вопрос - теперь что, в пути к БД указывать этот новый созданный файл?
    24 июня 2020 г. 14:11
  • Переименуйте файл БД (или, для надежности - переместите файл БД и все содержимое папки с логами в другую папку на том же диске) и скопируйте результат сжатия на место файла БД под именем старого файла БД.

    PS Возможно (точно не помню), в свойствах БД для успешного монтирования придется указать, что БД может быть перезаписана при восстановлении (Set-MailboxDatabase имя_БД -AllowFileRestore в EMS, или через EAC в свойствах БД).


    Слава России!

    24 июня 2020 г. 14:32
  • Переименуйте файл БД (или, для надежности - переместите файл БД и все содержимое папки с логами в другую папку на том же диске) и скопируйте результат сжатия на место файла БД под именем старого файла БД.

    PS Возможно (точно не помню), в свойствах БД для успешного монтирования придется указать, что БД может быть перезаписана при восстановлении (Set-MailboxDatabase имя_БД -AllowFileRestore в EMS, или через EAC в свойствах БД).


    Слава России!

    Однако, какие извращения.... Почти 1 ТБ туда сюда гонять...Ну совсем не мой вариант ((

    Прибегну, скорее всего, к правке реестра, и изменения параметра лимита БД,,,,сервер всё равно один, ДАГов нету ...
    • Изменено Kkk395 24 июня 2020 г. 14:42
    24 июня 2020 г. 14:37
  • Однако, какие извращения.... Почти 1 ТБ туда сюда гонять...Ну совсем не мой вариант ((

    Прибегну, скорее всего, к правке реестра, и изменения параметра лимита БД,,,,сервер всё равно один, ДАГов нету ...

    Где вы нашли терабайт? Перемещение файла на диске данные не перемещает (меняется только содержимое каталогов), а результат дефрагметации у вас, сами же пишете, стал сильно меньше.

    PS Штатный способ изменения пути БД - это не правка реестра, а команда EMS Move-DatabasePath:

     Move-DatabasePath -Identity <DatabaseIdParameter> -EdbFilePath <EdbFilePath> -LogFolderPath <NonRootLocalLongFullPath> -ConfigurationOnly


    Слава России!


    • Изменено M.V.V. _ 24 июня 2020 г. 15:06
    24 июня 2020 г. 15:04
  • Однако, какие извращения.... Почти 1 ТБ туда сюда гонять...Ну совсем не мой вариант ((

    Прибегну, скорее всего, к правке реестра, и изменения параметра лимита БД,,,,сервер всё равно один, ДАГов нету ...

    Где вы нашли терабайт? Перемещение файла на диске данные не перемещает (меняется только содержимое каталогов), а результат дефрагметации у вас, сами же пишете, стал сильно меньше.

    PS Штатный способ изменения пути БД - это не правка реестра, а команда EMS Move-DatabasePath:

     Move-DatabasePath -Identity <DatabaseIdParameter> -EdbFilePath <EdbFilePath> -LogFolderPath <NonRootLocalLongFullPath> -ConfigurationOnly


    Слава России!


    Результат то да, сильно меньше стал, но это размер файла temp.edb, который, как я понимаю, должен был автоматом после окончания дефрагментации "замениться" на боевую БД. Но вот какая проблема, сама БД как была того же размера, так и осталась,,,,а файл temp.edb лежит на другом диске....Тоже самое проделал в тестовой среде ( там правда Exch 2019 CU5), так вот там, после выполнения дефрагментации, файл temp.edb пропадает, а размер боевой базы, естественно, становиться меньше...
    24 июня 2020 г. 15:15
  • Может, у вас temp.edb на оставшееся на диске место не влез? Тогда, по идее, в конце дефрагментации должно быть сообщение об этой ошибке. Ну, или в команде вдруг еще и ключ  /p указали после /d (он в этом случае означает сохранить стаурю базу, но это вряд ли).


    Слава России!

    24 июня 2020 г. 16:47
  • Да странно вообще всё это конечно. Почему файл бд не заменился, ума не приложу...Размер конечно почти 1 ТБ, может следовало подождать просто с часок, другой...Всё таки сама БД на одном диске, а файл temp.edb на другом...Пока такой объём перекопируется...

    26 июня 2020 г. 10:15