Назад | Перейти на главную страницу

Уменьшение размера базы данных Exchange 2003

Наша компания использует Exchange 2003 на сервере 2003. Наш основной файл хранилища обмена (priv1.edb) продолжает расти и сейчас составляет более 45 ГБ. Если я сложу размер почтовых ящиков в этом магазине, я получу меньше 16 ГБ. Я запустил автономную дефрагментацию, но не восстановил ни одного КБ из файла .edb (файл .stm уменьшился с 8 ГБ до 2 ГБ). Я также посмотрел размер восстанавливаемых элементов с помощью производительности, и он кажется незначительным (не уверен, отображается ли отображение в байтах или КБ, в любом случае это не учитывает расхождения). Как мне узнать, что занимает все это пространство, и, что более важно, как его удалить?

Вы получаете хорошие резервные копии в Интернете? Я предполагаю, что это не так, и в результате вы видите, что удаляемые элементы накапливаются, а не очищаются. Это согласуется с отсутствием какого-либо уменьшения размера, которое вы видели при автономной дефрагментации.

Вы можете принудительно сохранить удаленные элементы для удаления элементов, даже если в хранилище информации не было хорошей резервной копии в Интернете, но я бы рекомендовал сначала исправить ваши резервные копии, если окажется, что это является виновником. Если вы хотите попробовать это, снимите флажок «Не удалять почтовые ящики и элементы безвозвратно до тех пор, пока хранилище не будет выполнено резервное копирование» на вкладке «Ограничения» свойств хранилища почтовых ящиков.

Дайте нам знать, как это получается.

Найдите событие с кодом 1221 в журнале событий приложений. Это покажет вам, сколько свободного «пробела» находится в вашей базе данных Exchange.

Также см:

Событие с кодом 1221 сообщает о меньшем объеме свободного места, чем должно быть.

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

Автономная дефрагментация должна уменьшить размер вашей базы данных. У вас есть общие папки в той же базе данных, размер которых увеличивается? Каков срок хранения удаленных элементов? Включаете ли вы размер журнала в файл EDB (если да, то создается ли его резервная копия?)

Это всего лишь некоторые вещи, которые нужно проверить. Однако, скорее всего, виноват срок хранения.

Еще несколько шагов, которые вы можете предпринять:

  • ESEUTIL / G. Это позволит проверить наличие каких-либо проблем на уровне хранилища ESE; если найдет, то вам понадобится ...
  • ESEUTIL / P. Приходит поврежденная база, выходит отремонтированная.
  • ИСИНТЕГ. Это заполнение исправляет любую ошибку на уровне хранилища Exchange, уделяя особое внимание логическим несоответствиям; ты необходимость запустить его после восстановления базы данных с помощью ESEUTIL, но вы также можете запустить его самостоятельно, если подозреваете, что ваша база данных имеет какие-либо логические проблемы; и я думаю, вы должны подозревать это на данный момент.

Как у вас резервное копирование? Мне интересно, если ваше программное обеспечение резервного копирования не устанавливает правильные флаги для Exchange для запуска обслуживания после резервного копирования.

Что произойдет, если вы действительно запустите резервное копирование с учетом обмена с помощью NTBackup?

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

Убедитесь, что резервное копирование не выполняется в течение установленных периодов обслуживания. Возможно, вам придется оставить расширенный период и отключить резервное копирование, скажем, на выходных, чтобы получить полное представление, если этого не было раньше.

После завершения онлайн-обслуживания в журнале событий будет указано, сколько места будет восстановлено автономным.

Спасибо всем за вашу помощь. В конечном итоге я использовал exmerge для экспорта данных каждого пользователя (после использования автоархива, чтобы снизить их до предела в 2 ГБ, почему exmerge не использует более новый unicode .psts?), Создавая новый частный магазин, а затем используя exmerge еще раз, чтобы повторно импортировать почтовые ящики. К сожалению, это заставляет Outlook переходить в режим восстановления для каждого пользователя, но, по крайней мере, он работал с минимальным временем простоя.

Несмотря на снижение стоимости с Exchange 2010, вы потеряете дисковую емкость хранилища единственных экземпляров, извлекая и импортируя почтовые ящики с помощью ExMerge.

Я обычно добавляю фильтры по дате и папкам при распаковке с помощью ExMerge. Не забывайте игнорировать Контакты, пользователи расстраиваются, когда половина из них внезапно "уходит" из-за экспорта ..;) Импортировать "только" контакты обратно было не так уж плохо ..

Между магазином почтовых ящиков, колеблющимся около 72 Гбайт, и все меньше и меньше пробелов, я взял на себя ответственность и начал экспортировать почту. Не мог дождаться, когда пользователи достигнут моего лимита хеджирования 73G. Теперь .. автономная дефрагментация. Хорошие времена!