Сценарий: я использую выделенный том (том RAID) для хранения всех моих данных для моего сервера Exchange 2007. Сегодня из любопытства я решил проверить, насколько фрагментированы файлы на этом томе данных. К моему удивлению, ответ чрезвычайно. Итак, вопрос из трех частей:
В первую очередь, СЛЕДУЕТ ли мне дефрагментировать этот том (конечно, после полного резервного копирования)? Укажите, почему бы и нет, если я не должен, или причины, по которым я обязательно должен, если должен.
Во-вторых, о том, сколько времени я должен выделить в течение этого периода обслуживания на гигабайт. Все диски - это диски SATA 7200 об / мин на контроллере Hardware RAID 5 (Perc 5i / 6i, не могу вспомнить), файлы чрезвычайно фрагментированы. (Более 5000 файловых фрагментов на гигабайт).
В-третьих, здесь что-то не так? Мне кажется, диск не должен быть настолько фрагментированным. Может быть, что-то настроено неправильно, из-за чего это могло произойти?
Вы храните файлы базы данных и журналы транзакций на одном томе?
Это могло бы стать причиной такой фрагментации (а также определенно не рекомендуется).
Журналы транзакций - это множество небольших файлов, которые создаются на лету, в то время как основные файлы базы данных постоянно растут; это идеальный рецепт для тяжелой фрагментации NTFS.
Я предполагаю, что нет ничего, кроме обмена база данных на этом томе ... очереди почты также могут быть большим источником фрагментации.
О дефрагментации: не делайте этого, если вы можете этого избежать.
Есть ли у вас свободное место даже на внешнем диске? Просто остановите службы Exchange, скопируйте все в другое место, отформатируйте том и снова скопируйте все обратно.
Или выполните резервное копирование / восстановление, если у вас есть надлежащее программное обеспечение и устройства для резервного копирования.
Дефрагментация диска на месте - одна из самых медленных и опасных операций, которые вы можете выполнять в производственной системе. И RAID 5 (который довольно медленно пишет) здесь действительно не помогает.
0/3. Есть ли на этом томе что-нибудь, кроме файлов базы данных (* .edb и * .stm)? Я думаю, вы могли бы сказать, что я спрашиваю, насколько посвящен посвящен. Однажды я видел серьезную фрагментацию, вызванную хранением теневых копий на томе обмена. В небольших установках нередко можно увидеть файлы индекса, файлы журнала, очередь smtp, очередь mta на одном томе. Любой из них также приведет к фрагментации файлов базы данных.
Дефрагментация ОС не вызовет у вас проблем, но если у вас нет большого количества свободного места на диске, я бы не ожидал, что это будет делать много. Я думаю, вы бы хотели остановить службу хранилища информации. Большая часть документации, посвященной обмену дефрагментацией, сосредоточена на логической фрагментации пустого пространства в базе данных обмена, а не на фрагментации на уровне файлов. http://msexchangeteam.com/archive/2004/10/25/247342.aspx обсуждает это и упоминает, что ведение журнала сбивает с толку отложенную запись во время дефрагментации на уровне файла.
Я не уверен в расчете скорости / времени. Я слишком занят, чтобы заниматься математикой.