Кончайте сраца, по делу давайте

По-моему, "втираешь мне какую-то дичь" и посылы вроде "Иди самоутверждайся в другом месте" — это прямое хамство.

> а ехидно поливать гавном собеседника - высокий тон?

Ссылку / цитату, или хватит врать.

Вообще, если подумать, фрагментация данных образуется только на определённых формах нагрузки на БД,
когда данные меняются, или когда вставляются особым образом.

Так что это не может быть в best practice для всех ...

А падение производительности отдельных запросов при этом было (особенно INSERT/UPDATE)?
Вообще, простое уменьшение размера индекса вдвое для "тупого" (в смысле, читаем весь индекс) ETL, конечно, даст существенный эффект... только вот таких нагрузок (которые, во-первых, "раздувают" индекс / таблицу так, чтобы его можно было так сжать, и, во-вторых требуют чтения всей таблицы) — очень мало, в норме.
Ну и так далее...

Заметного не было, иначе были бы инциденты

И да, вот ещё что — это, фактически, разделение нагрузки во времени, на самом деле — сейчас мы её увеличиваем (отдавая ресурсы на дефрагментацию), а потом "отыгрываем", получая более быстрый ETL.

Да уж совсем не обязательно были бы.
К примеру, создание дополнительных индексов мало кто замечает... а ведь это достоверно и доказуемо увеличивает нагрузку при каждом INSERT/UPDATE, и ничего. ;)

Это также и в целом про индексы можно сказать. Отдаём место на диске и ресурсы на их построение, получая взамен более быстрый отклик.

Обратное тоже верно — к примеру, удалили несколько (бесполезных, как выяснилось) индексов с интенсивно используемых таблиц — и уже write-intensive транзакции ощутимо ускорились.
Просто обычно именно для создания индексов такой trade-off — это нормально и выгодно.
А вот что касается их "навязчивой" дефрагментации — обычно ровно наоборот. ;)

Зачем тогда она существует?)

Потому что крайние случаи, когда это выгодно, существуют тоже.
К примеру, противочумные костюмы существуют не просто так, и их использование в определённых ситуациях — нормально и выгодно.
А вот рутинно (без конкретных причин) ходить в нём повсюду — уже мизофобия. ;)
(А вовсе не best practice, как тут утверждали.)

Хм. У меня из всего обсуждения сложилось впечатление, что это не нужно никогда. Наверное, не правильно чиитал и упустил суть)

Да нет же. Best practice — это то, что стоит делать "по-умолчанию", в большинстве реальных / обычных ситуаций.
Вот же пример приводили: https://t.me/sqlcom/137276 , да и другие несложно найти.

Ребята, как можно быстро скопировать данные из одной таблицы в другую и очистить первую?

alter table switch

Коллеги, всем доброго.
Подскажите плз, кто нибудь сталкивался с траблой фильтра в query store со значениями Max и Min?
в Top Resource Consuming Queries.
Ошибка доступа к базе возникает

Выдернул профайлером, там судя по всему ошибка в коде при конвертации значения в колонке max_query_wait_time из sys.query_store_wait_stats, при этом сама колонка в этой вьюшке названа max_query_wait_time_ms.

Пробовал заменить именование колонки в коде, но ошибка все равно возникает.

версия сиквела какая? версия студии какая?

сиквел 2019 15.0.2000.5, ssms 15.0.18330.0

на стэке нашел аналогичную проблему, всё один в один, но без ответа https://stackoverflow.com/questions/49198106/couldnt-connect-to-database-when-using-top-resource-consumers-querystore-report

18.5 уже давно