SERG1257,

1.совсем
2 не следить
3. Удалить джоб

Мир изменился. Реагируете только на реальные проблемы и автоматизируйте это, если нужно. А если припрёт, вначале подумайте об REORGANISE

alexeyvg,

...не только запись превращается в случайную, но и чтение. Кроме того, ситуация сильно зависит от реализации алгоритма рассеивания записи, многоие не дорогие диски в этом халтурят. Также, большое влияние могут оказывать разные кеши на пути ввода-вывода. За счёт того, что производительность операций у SSD на порядки выше, не только мы, но и разработчики дисков и контроллеров пренебрегают потерями на фргментации. Давно уже никого не смущает, что оерационка не дефрагментирует диск. Раньше это рекомендовали повсеместно. По аналогии и внешняя фрагментация. Не будет в реальности скана последовательно расположенных на диске страниц.
Алгоритмы размещения страниц в буферном пуле, их там удерживания и сброса на диск не такие тупые, как может показаться после продчтения высказываний апонентов. Каждому процессу выдаётся конечный и отнюдь не большой объём ресурсов. Если их нехватает, используется промежуточная материализация. В сухом остатке влияние незаполненных страниц и лишних страниц подхваченных упреждающим чтением будет сильно невелированно. Основные потери времени здесь и раньше и теперь были именно на физических операциях ввода-вывода, а они теперь на пару порядков быстрее.
Кстати, нормальная очередь к диску уже лет десять 250 ;)

Владислав Колосов,

Простите, я не работаю с виртуалками.

alexeyvg,

Влияния на производительность не замечал, мы уже давно от ребилда отказались и ничего, всё и так прекрасно работает. Обновление статистики делайте, где надо, этого в большинстве случаев достаточно. Если много удаляете и велико число расщиплений, вполне можно использовать REORGANISE, он лечит внутреннюю фрагментацию.
Зато уменьшение числа операций налицо, как раз засчёт отказа от дефрагментации, которая бъёт по всем чувствительым местам SQL Server. Но самая главная боль дефрагментации, это то, что она убивает SSD. И не так что бы они чуть меньше прослужили. Вы рассчитываете, что новый массив SSD у вас прослужит положенные 5 лет. А на практике, только из-за дефрагментации, срок сократиться до 2-х, а я своими глазами видел прецеденты, когда и года не служили. Причём, отказ дисков будет не такой "плавый", как у HDD, массив сломается весь сразу и менять его придётся целиком. Что бы этого избежать, вы сделаете AlwaysON кластер, а он не будет работать, потому что из-за очереди на REDO (а это самое узкое место этой технологии) реплика у вас не будет синхронизироваться, будет всё больше отставать. И виной этому будет (угадайте какая операция)?
Я не говорю сейчас о маленьких приложениях, речь о системах с нагрузкой. Понятно, что мизерная нагрузка не будет пораждать проблем.

alexeyvgВот, я смотрю на любой тест SSD, и вижу, что при чтении со случайным доступом небольшими блоками поток падает в 3-10 раз.
Почему?
Не из за головок, понятно, а из за того, что есть латентность операции, затраты времени на обращение к драйверу, латентность физического интерфейса и т.д.
Потому что код, который читает эту жалкую страницу, жалкие 8 кб, должен попасть в кэш процессора, вытеснив что нибудь, и только потом начать выполняться. А перед этим нужно переключить контекст, перезаписав TLB, переопределив области адресного пространства.
Вот отсюда и получаются эти 3-10 раз.

Маленький блок был проблемой всегда и не только при чтении. Мало того, операции REDO очень чувствительны к величине страйпа, для них оптимално 64Kb. На SSD рамер ячейки существенно большье. Понятно что это не будет эффективно. Но это влияние не зависит от фрагментации. Задержки, кстати, будут не плохими, они как раз растут при увеличении размера блока. Причём, эти самые 3-10 раз будут в разы быстрее, чем то же самое на дефрагментированных жёстких дисках.

alexeyvgЭто не из за SSD, это из за совершенствования операционок. Винды с NTFS эффективно хранят данные, и дефрагментация не так страшна, если иметь на диске некоторый свободный объём.
Ну и второй фактор - ненжужность, ибо "производительности достаточно".
Не потому, что дефрагментация не полезная вещь, а потому, что она невыгодна, не имеет смысл заморачиваться.

Операционка тут не при чём. Это проблема NTFS, а он не изменился. Дефрагменацию не делают по уверениям Майкрософт именно потому, что она убивает диск. Есть тонны частных утилит, которые не только дефрагментацию отключают, но и ещё много ненужных телодвижений операционки с файлами, типа прописывание коротких имён, изменение атрибут архивности, простановка последнего времени доступа и т.п. Это всё реально продлевает жизнь дискам.