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