none
Оптимизация размера баз RRS feed

  • Вопрос

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

    Начал заниматься почтой по причине ухода всех почтовых админов. Exchange раньше не занимался.

    Имеется: 2 DAG (в каждом по 2 сервера с базами). В одном DAG - 24 базы, в другом 45. DAG расположены на разных площадках. Плюс есть PFDB на каждом из 4х серверов. Для баз включено "фоновое обслуживание базы данных"

    Базы растут и места все меньше. На сколько я понимаю, даже если ящик удаляется или перемещается в другую базу, в своей исходой БД он места не освобождает (в смысле сама база остается столько же весить). Это так? Тогда новые письма, которые будут приходить, они будут занимать место оставшееся от старого ящика без увеличения размера базы, или все же будут увеличивать размер базы?

    Правильно ли я понимаю, что в моем случае оффлайн дефрагментация не допустима?

    Тогда, получается, нужно создавать новую базу, туда мигрировать почтовые ящики из нужной базы, после чего старую базу удалить? Или есть более простые варианты?

    В команде Get-MailboxDatabase -Server server_name -status | select Name, DatabaseSize, AvailableNewMailboxSpace, в поле AvailableNewMailboxSpace будет выведен объем который освободится при дефрагметации базы? Растущая база сможет использовать это место без дефрагментации?

    Да, у меня часть вопросов скорее всего дублируют друг друга, но хотелось бы уточнить все это.

    Заранее благодарю за ответы.

    9 января 2020 г. 8:21

Ответы

  • "Базы растут и места все меньше. На сколько я понимаю, даже если ящик удаляется или перемещается в другую базу, в своей исходой БД он места не освобождает (в смысле сама база остается столько же весить). Это так?"

    Да

     "Тогда новые письма, которые будут приходить, они будут занимать место оставшееся от старого ящика без увеличения размера базы, или все же будут увеличивать размер базы?"

    Будут занимать оставшееся, пока оно есть

    "Правильно ли я понимаю, что в моем случае оффлайн дефрагментация не допустима?"

    Допустима, но простоями и возможно большими

    "Тогда, получается, нужно создавать новую базу, туда мигрировать почтовые ящики из нужной базы, после чего старую базу удалить? Или есть более простые варианты?"

    Это наиболее правильный вариант

    "В команде Get-MailboxDatabase -Server server_name -status | select Name, DatabaseSize, AvailableNewMailboxSpace, в поле AvailableNewMailboxSpace будет выведен объем который освободится при дефрагметации базы?"

    Да

    "Растущая база сможет использовать это место без дефрагментации?"

    Сначала будет использоваться это место, при нехватке, дополнительное.

    • Помечено в качестве ответа Reaplay 9 января 2020 г. 8:43
    9 января 2020 г. 8:34

Все ответы

  • "Базы растут и места все меньше. На сколько я понимаю, даже если ящик удаляется или перемещается в другую базу, в своей исходой БД он места не освобождает (в смысле сама база остается столько же весить). Это так?"

    Да

     "Тогда новые письма, которые будут приходить, они будут занимать место оставшееся от старого ящика без увеличения размера базы, или все же будут увеличивать размер базы?"

    Будут занимать оставшееся, пока оно есть

    "Правильно ли я понимаю, что в моем случае оффлайн дефрагментация не допустима?"

    Допустима, но простоями и возможно большими

    "Тогда, получается, нужно создавать новую базу, туда мигрировать почтовые ящики из нужной базы, после чего старую базу удалить? Или есть более простые варианты?"

    Это наиболее правильный вариант

    "В команде Get-MailboxDatabase -Server server_name -status | select Name, DatabaseSize, AvailableNewMailboxSpace, в поле AvailableNewMailboxSpace будет выведен объем который освободится при дефрагметации базы?"

    Да

    "Растущая база сможет использовать это место без дефрагментации?"

    Сначала будет использоваться это место, при нехватке, дополнительное.

    • Помечено в качестве ответа Reaplay 9 января 2020 г. 8:43
    9 января 2020 г. 8:34
  • 1. Дефрагментация допустима только либо в случае тестовых БД, либо в случае если возможен простой почты, т.к. в этот момент все пя в дефрагментируемой БД будут недоступны. Также учтите, что при дефрагментации по сути создаётся новая БД и данные копируются в неё, т.е. у вас должен быть запас места на диске для создания такой же БД. Приоритетный вариант без простоев - перемещение пя в новую БД и удаление старой.

    2. Если кончается место, то можно почистить логи либо выполнив полный/инкрементальный бэкап (рекомендуется), либо включив цикличное перезаписывание логов (на случай полного ахтунга). При создании тома вы можете 50 ГБ держать нераспределёнными как раз на случай если закончилось место и они вас спасут.

    3. Ещё хотелось бы понять размер ваших БД (может быть там аж ТБ) и почему у вас так разбалансированы DAG по нагрузке?

    9 января 2020 г. 9:09
  • "включив цикличное перезаписывание логов"

    Включено

    При создании тома вы можете 50 ГБ держать нераспределёнными как раз на случай если закончилось место и они вас спасут.

    Сервера виртуальные, для каждой БД выделен отдельный диск и добавить место так-то всегда можно, но на самом хранилище его не так много осталось. Плюс это может занять время, т.к. есть определенный процесс согласования. Поэтому вариант с увеличением места рассматривается как резервный вариант.

    3. Ещё хотелось бы понять размер ваших БД (может быть там аж ТБ) и почему у вас так разбалансированы DAG по нагрузке?
    В среднем на базу уходит около 220-230 ГБ. Некоторые ящики занимают по 10-15 ГБ, некоторые под 100. Плюс общий ящик, там под 600, но он на отдельной базе расположен.

    Почему так загружены DAG не скажу, ибо все это так настроено было до меня. Предположу, что такая нагрузка, скорее всего, обусловлена площадками размещения. Главный офис и доп. офис. На одной площадке, где-то 1,5к ящиков, в другой 800.

    За счет такого размещения лишний трафик между площадками не гоняется.



    9 января 2020 г. 10:17