Комментарии 33
Не могли бы вы поделиться опытом борьбы с фрагментацией для MSSQL Standard?
Тут некоторые люди пытаются лицензироваться и Enterprise не всем по карману, тем более одна фича онлайн ребилда индексов не оправдывает разницу в стоимости (при условии что остальные фичи явным образом не требуются).
Ну в standard это ночные rebuild для frag более 60, и reorganize для меньшего. Но если базы большие и нет maintenance window, то ква. А если есть, то можно даже ставить simple recovery, и все перестраивать
Впрочем, я могу открыт одну тайну: в одной стране стоимость enterprise не отличается от standard и равна нулю
Не миф, в среднем у меня размер баз уменьшается в 1.7 раза - но там не все индексы настолько фрагментированы
Смерть SSD дисков сильно преувеличена. Это было верно лет 5 назад. После года активной работы диски показывают 97% ресурса,в пятницу как раз смотрели. Это на 30 лет
Современные SSD очень хороши (а для tempdb NVMe)
Чтобы не быть голословным, один из дисков. Один из дисков tempdb
Не все так радужно. Данный счетчик чаще врет и с реальным миром мало связан. Был случай когда диски показывали за год 1-2% износа, а на второй ушли на покой с показателем <30%. Хорошо что быстро привезли и удалось заменить диски без последствий.
Был случай когда диски показывали за год 1-2% износа, а на второй ушли на покой с показателем <30%
на всех накопителях, что я видел, это просто отношения числа случившихся циклов erase к расчётному ресурсу; так что такое поведение говорит о изменении нагрузки.
Данный счетчик чаще врет и с реальным миром мало связан.
с этим сложно спорить, показатель ну очень примерный.
Фрагментация большая была потому, что до меня в этой фирме никто не пытался это делать на регулярной основе по причинам, описанным в статье
Наконец не понял про Buffer Cache Hits Ratio - не будет хуже
Как это, если число страниц будет меньше?
Именно. И чем меньше страниц, тем лучше они кешируются, потому что больший процент страниц помещается в память
Вот на практике у меня (было -> стало)
Rows: 3995946761 -> 4074573862 (выросла за время анализа)
Page count: 64164949 -> 40253602
Frag count: 56089774 -> 1168526
frag_pct: 86.30% -> 2.17%
Space, Mb: 504122 -> 319043Что касается SSD, то при современном времни жизни SSD это предубеждение (имеется в виду конечно enterprise level SSD)
Одновременно? Совпадение? Не думаю)
Я спросил, тут за пять лет умер один диск.
Число циклов зависит от технологии TLC/MLC/SLC и насколько больше память диска того размера, который он изображает (что позволяет размазывать writes ровнее). Enterprise диски недаром более дорогие.
Что касается времени выполнения, то для больших таблиц (>>размер памяти) время при скане (OLAP нагрузка) растет линейно с размером, при OLTP нагрузке как правило падает логарифмически.
"памяти и процессоров" добавить как раз сложно, если 64 cores и 2Tb максимум что можно в эту материнку запихнуть.
P.S. Я также слежу за двумя репликами, last_hardened_time отстает не более чем на 5-10 секунд, Такие же пики бывают и просто от обычной нагрузки
И кстати, TLC же наименее живучие...
… я так думал до того, как у меня одновременно "умерли" восемь enterprise level SSD в массиве
что за накопители были? больше похоже на проблемы с прошивкой, таких у dc накопителей было достаточно, я приводил некоторые примеры
> full table scans
Стесняюсь спросить, а как может случится фрагментация индекса на таблице без индекса?
У нас используются пороги 10 и 30 процентов, подсмотрели в стандартном скрипте Микрософт. Но здесь тонкость, в стандарт редакции ребилд блокирует таблицу, онлайн может только ентерпрайз. Если таблица большая- это нарушает работу пользователей. Второй момент- при ребилде создается копия таблицы. Для больших таблиц это может закончиться катастрофическим ростом базы, под это может просто не хватить места на диске (СХД).
Есть и третий момент. Запрос фрагментации- процедура долгая. Куда проще огульно делать реорг всем таблицам кроме самых крупных, по списку. По ресурсам то на то и выходит. С самыми крупными смотреть отдельно. Зачастую они накопительные, меняются мало и фрагментируются не сильно.
Дефрагментация таблиц в высоко нагруженных базах данных (MSSQL)