Есть таблица независимого регистра сведений, некий лог.
Постоянно пишутся новые данные и очищаются старые.
Одно из полей таблицы - строка неограниченной длины (если это важно).
Количество записей примерно постоянно, но занимаемое место на диске не освобождается и только растет с каждым днем.

Всего 700 тыс записей и занято этой таблицей уже 60Гб (из них индексы занимают 300Мб).
Если сделать реструктуризацию таблицы в 1С через конфигуратор (поменять реквизит), то она проходит за пару минут и останется "честных" 2Гб.

Какой командой добиться в SQL аналогичного освобождения места?

Речь не про шринк! 1) на данной базе это слишком долго. 2) эффекта не дает.
Наверняка поможет перекидывание данных во временную, truncate, и перекидывание обратно, но может есть какая-то одна хитрая команда?

DBCC CLEANTABLE и DBCC DBREINDEX - не помогают.

(0) проверил на ограниченных строках, вне норм очищает, если Набор.Очистить() Набор.Записать()

*все

(0) У вас измерение строковое неограниченной длины?)

(0) SQL Server? Покажи через SSMS сколько места занимают данные и сколько индексы. Скорее всего тебе нужно REBUILD  индексов сделать

а, невнимательно почитал, с индексами у тебя норм

(4) https://disk.yandex.ru/i/oEUfwDLK8ITRag

(6) а, так это зарезервированное место. Есть хранимка для очистки

Не могу найти что-то. А какая версия скуля? В последних версиях есть сжатие
https://docs.microsoft.com/ru-ru/sql/relational-databases/data-compression/enable-compression-on-a-table-or-index

Вот тут пишут, что это невозможно.
Ну, ты можешь скриптом сделать копию, пепебросить туда данные и потом обратно, только так.

https://stackoverflow.com/questions/49610084/sql-server-deleting-updating-lob-data-in-a-heap

Ну и можно попробовать это

Perform ALTER INDEX ALL .. DISABLE to disable all non-clustered indexes;

Perform ALTER INDEX ALL .. REORGANIZE WITH (LOB_COMPACTION = ON) to compact LOB pages of the underlying heap (this will leave the disabled indexes alone);

Perform ALTER TABLE .. REBUILD to rebuild the in-row data of the heap, as well as all data of the indexes, and re-enable them.

освободить в табличке - перетусовать данные что-бы в блоках оставалось незаполненными только дефолтовое место (10% что-ли) - остальные блоки останутся в файле/файлах базы но будут пустыми, а отдать файловой системе не подразумевается в принципе!

Во-первых,все зависит от модели восстановления,так как могут храниться как транзакции добавления так и транзакции удаления,а также данные реально не удаляться.
Во-вторых,при удалении записей место освобожается только если очищена вся страница,если остаются страницы хоть с одной записью,то они так и будут жить.
Кроме того,строки неограниченной длины то бишь BLOB при удалении оставляют дыры,которые потом могут быть заняты,но для освобождения этого места нужно делать переупаковку BLOB.

(0)Выгрузка-загрузка в dt+ shrink

используешь простую модель восстановления?

(10) Не помогло. Сделал перекидывание во временную + truncate. Не критичная таблица, 2 минуты отрабатывает, впихну в задачи планировщика.
(11) Полная. Но речь про конкретную таблицу, не про файл лога.
"для освобождения этого места нужно делать переупаковку BLOB." - вот что-то не получилось.
Еще есть другой РС без строковых значений, тоже размер непропорциональный данным, но там не критичный рост.
(13) Понятно, что выгрузка через DT всё лечит, но это чересчур.

Если этот РС - только как лог и не нужны срезы, то переделать регистр на непериодический.
Первым измерением сделать поле ПериодЛога.
Таким образом кластерный индекс будет соответствовать течению лога и страницы будут обрезаться полностью при удалении старых записей