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

Регулярный ребилд на SSD тупо убийство дисков, чистый вред и никакой пользы! А теперь вопрос - почему?

Я ни за что не выступаю.
Дефрагментация и ребилд - близнецы, братья.
SSD используют алгоритм рассеивания записи, что бы продлить ресурс диска, т.к. число циклов перезаписи ячейки конечно. Т.е. последовательная запись превращается в случайную.
Дефрагментация была изобретена для оптимизации работы с данными на жёстких дисках, где большинство времени тратилось на перемещение головок и поворот диска до нужного сектора. В SSD этого нет. Т.е. внешняя фрагментация - это на SSD не повод для беспокойства, если только у вас не огромное число фантомных записей.
Внутренняя фрагментация лечится не ребилдом. У неё другие причины и другое влияние на производительность.
А вот после того, что вы прочитали, должен выступать не я, а здравый смысл ;)

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

Если смотреть на такую "работу" глазами бухгалтера, то он бы навесил на всё это ярлык: ФИНАНСОВОЕ ПРЕСТУПЛЕНИЕ

alexeyvg,

Не согласен ни с одним пунктом. Первый заметно поможет разве что ребилду. Второй не будет писать в одну ячейку только то, что нам хотелось бы. И читать тоже не будет только столько, сколько нам нужно для производительности. Но всё это не важно и получаемые задержки и производительность позволяют не париться на этот счёт. Пока я знаю только один сценарий, где это реально полезно, о нём было выше. Зато чтение реплики от очереди на Redo может стать бессмысленным из-за отставания. Ито не только ребилд так гадит. Понимаю, что сложно отказаться от стереотипов, потому и избрал такую форму подачи ;)

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

Вы заблуждаетесь. Так было раньше.

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

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

Danion,

Вы хоть сами смотрели этот ролик? ...там чудным образом у него вначале получалось только опровергнуть себя же :)
Я не буду коментировать результаты тестов производительности запросов, выполненные на ноутбуке. Жаль на это время тратить.
Повторю одно, выигрыш от ребилда на современных серверах с хранилкой на SSD настолько мизерный, что им можно пренебречь. Я вот вред наносится серьёзный. Делайте ребилд только при явной необходимости.

Перечислю вред по мере убывания влиияния на работу:

1. Безсмысленноое расходование циклов перезаписи SSD
2. Дополнительная нагрузка на REDO (мы же ещё помним тему топика)
3. Давление на память во время ребилда
4. Блокировка таблицы в момент переключения метаданных

0wl,

Почитайте лучше документацию, что такое B-дерево. Не нужно придумывать....

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, а он не изменился. Дефрагменацию не делают по уверениям Майкрософт именно потому, что она убивает диск. Есть тонны частных утилит, которые не только дефрагментацию отключают, но и ещё много ненужных телодвижений операционки с файлами, типа прописывание коротких имён, изменение атрибут архивности, простановка последнего времени доступа и т.п. Это всё реально продлевает жизнь дискам.