Достаточно ли часта еженедельная онлайн-дефрагментация магазина SBS 2003 Exchange?
(этот пост немного длинный, поэтому советуем СПАСИБО тем, кто до конца его придерживается)
У меня есть клиент, чей сервер SBS 2003 внезапно начал падать каждую ночь. Симптомы крушения были странными. Обычно система просто зависает. Я все еще мог видеть интерфейс Windows на экране, но сама система не реагировала на действия мыши и клавиатуры. В конце концов мне пришлось бы перезагрузить сервер, чтобы он снова заработал (безобразно).
Изучив системные журналы, я заметил, что сбои происходили вскоре после того, как начались онлайн-процессы обслуживания в системном Exchange, Private Store. Онлайн-обслуживание должно было проводиться каждую ночь в нерабочее время. Я считаю, что это было установлено на 1 утра до 4 утра.
Поскольку процессы онлайн-обслуживания были предвестником сбоя, я отключил их все вместе, пока не смог выяснить истинную причину проблемы. Например, я хотел убедиться, что проблема не связана с неисправным оборудованием.
Прошло несколько недель после отключения онлайн-обслуживания, и сервер работал нормально, но я заметил, что размер Exchange Store рос быстрее, чем обычно. Я объяснил это тем, что таких вещей, как онлайн-дефрагментация, не происходило. Я знал, что в конечном итоге мне нужно будет снова запустить задачи онлайн-обслуживания, но я не мог запланировать их запуск в будний вечер, потому что сервер требовался для производственных задач первым делом каждое утро буднего дня.
Одна догадка о сбоях, которую я испытал, заключается в том, что процессы онлайн-обслуживания сводили на нет другие запланированные задачи, которые выполнялись примерно в одно и то же время (например, процессы VSS, резервные копии и т. Д.).
Чтобы проверить эту догадку, я настроил онлайн-обслуживание частного магазина в первые дни воскресенья утром и позаботился о том, чтобы на тот же период не было запланировано никаких других запланированных задач.
Я заснул в субботу вечером, ожидая, что я проснусь и обнаружу, что сервер вышел из строя к тому времени, когда я проснулся в воскресенье утром. К моему облегчению, он не разбился. Я проверил системные журналы и отметил, что процессы онлайн-обслуживания успешно завершены.
Поэтому я склонен разрешить процессам обслуживания базы данных Exchange на этом конкретном сервере в течение некоторого времени еженедельно (каждое воскресное утро). Это позволит мне увидеть, правильна ли моя догадка или есть какая-то другая основная проблема (например, неисправное оборудование), которую необходимо исправить.
У меня вопрос (и спасибо, что прочитали мой "роман" до этого момента)... Достаточно ли, чтобы процессы онлайн-обслуживания происходили один раз в неделю, а не каждую ночь? В чем недостаток не выполнять эту задачу каждую ночь?
2 ответа
Процесс обслуживания базы данных очищает элементы, срок хранения которых превышает установленную для хранилища почтовых ящиков, а также выполняет несколько других задач. Это позволяет создавать новые элементы без увеличения физического размера файла. Я бы посмотрел на настройку хранения удаленных элементов и убедился, что они уместны. Что касается физического размера файла, то онлайн-дефрагментация не будет сокращать физический файл, это будет делать только автономная дефрагментация. Если вы считаете, что прирост файла опережает объем обслуживания базы данных, вам следует обратить внимание на сокращение времени хранения удаленных элементов. От того, вызывает ли сбой обслуживание хранилища почтовых ящиков, зависит от размера базы данных и объема выполняемой работы по ее очистке. По своему опыту могу сказать, что это сомнительно. Если это так, возможно, это связано с неадекватным или неисправным оборудованием. Я управляю сервером Exchange 2003 (Enterprise Edition) с 4 хранилищами почтовых ящиков, каждый из которых превышает 100 ГБ, состоит из 650 почтовых ящиков, и я без проблем запускаю процесс обслуживания хранилища почтовых ящиков.
Единственное, что я хотел бы отметить, это то, что вы должны запланировать обслуживание хранилища почтовых ящиков и резервных копий в разных временных окнах, так как они не могут работать одновременно. Процесс обслуживания базы данных malbox остановится, когда он обнаружит, что резервное копирование запущено. Если две задачи конфликтуют, то процесс обслуживания вашей базы данных может никогда не завершиться. Он подхватит в следующий раз, когда остановился. Вы можете проверить журнал событий приложений на наличие идентификатора события 1207, который означает, что очистка элементов после даты хранения завершена, события 1209, который означает, что задача обслуживания завершена, и события 1221, который означает, что онлайн-дефрагментация завершена.
Также обратите внимание, что процесс будет продолжаться минимум 15 минут и максимум 1 час. Время, которое вы конфигурируете в графике обслуживания, - это время, в течение которого оно МОЖЕТ работать, а не время, в течение которого оно БУДЕТ работать.
Вот краткое изложение того, что делает процесс:
http://support.microsoft.com/default.aspx?scid=kb;en-us;324358
Чисто спрашивая о дефрагментации, ответ будет "это зависит". Насколько это фрагментировано? Насколько интенсивно используется почтовый сервер? Во-первых, плохо используемый почтовый сервер вряд ли сильно пострадает от фрагментации.
Я полагаю, вы могли бы получить приблизительную оценку, посмотрев, сколько времени занимает работа. Легко ли вписывается работа в окно технического обслуживания, которое вы дали для дефрагментации?
Если выполняемая дефрагментация соответствует времени, которое вы выделяете, и вы не сталкиваетесь с проблемами производительности между запусками (или выявляете ошибки), тогда да, достаточно использовать планирование обходных путей для дефрагментации хранилища.
Дефрагментация не предназначена для поддержания работоспособности хранилища Exchange. Если вы никогда не дефрагментируете его, сервер Exchange не умрет. Производительность может со временем ухудшаться и в конечном итоге сканировать, но она не будет просто расти и терять данные или повреждаться только потому, что она не дефрагментирована.