Хмм, это очень странно.

Что именно тормозит, truncate table или shrinkfile

А насколько база заполнена после truncate table?

Может быстрее будет отребилдить все оставшиеся таблицы и шринкать с truncateonly?

Логи тоже шринкуются?

Если база остается заполнена на 70%, то ребилд не ваш вариант.


alter table .. rebuild
Но при 70% заполнении, как я уже сказал, это не вариант.
Могло бы помочь, оставайся в базе 5-10 % данных, тогда ребилд с высокой вероятностью "прижал" бы данные к началу файла(ов) данных и, что самое главное, сделал бы это значительно быстрее, чем shrink. После чего shrinkfile c truncteonly быстро бы высвободил место "справа" от последних существующих данных.

Кстати, truncate - операция асинхронная, т.е. физическое удаление данных (а значит и освобождение страниц) происходит не мгновенно.
Возможно, ваш shrink в том числе переносит уже удаленные данные.




Пустой не значит не занимает место на диске, какие файлы и с какими опциями вы шринкаете?

И вообще, зачем вам шринк при такой внушительной заполненности базы. Выиграете 300 - 400 ГБ при исходном размере в 1.2 ТБ, не уж то это так критично?

А насколько 1С (я сейчас про сам сервер приложений) позволяет секционировать данные?
Могу ли я на свое усмотрение секционировать, например, какую-нибудь ГК по дате проводки?
Не возникнет ли при этом сбоев в работе самой 1С?

Только если эти приложения не занимаются "сверкой" текущей структуры базы с их ожиданиями.
Насколько я слышал, 1С это делает.