Добрый день.

Версия 2016 SP2 CU10 Enterprise.

Есть база размером 1.2 ТБ. В ней есть свободное место, шринк базы показывает минимум 620 ГБ. Появилась задача уменьшить размер до 650 ГБ.
Перед работами в выходные был выполнен бекап, база переведена в режим simple и запущено сжатие.
Через 18 часов запрос всё ещё продолжался, лог базы вырос до 460 ГБ, а в дата-файле показывало, что занято 900 ГБ. По самым крупным таблицам рост во время сжатия был около 30%. Была таблица 626к строк и размером 540 ГБ, во время сжатия стала 836 ГБ при всё тех же 626к строк, и так по всем таблицам. На самой большой таблице всего 1 некластерный индекс, как был размером 1МБ так и оставался. Свободного места на диске было 570 ГБ, оставалось около 110 ГБ. За несколько часов наблюдений ничего не менялось, сжатие было остановлено, лог очищен, база переведена в режим фулл, создан новый фулл-бекап.
Сегодня проверяю базу - размер таблиц и свободное место в базе вернулось к исходному.

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

Если кто-то сталкивался или просто знает - что это было и как решить?

Гавриленко Сергей Алексеевич,

Сжатие файла из SSMS с реорганизацией страниц.

a_voronin,

Тему прочитал, но вроде не очень похоже.

У меня на таблице нет кластерного индекса, массовой вставки данных во время работ тоже не было.
В базе уже давно было свободное место в дата-файле, когда-то удаляли ненужные уже таблицы.

Danion,

Перепроверил индекс на самой большой таблице - я утром всё же не туда посмотрел и индекс там кластерный уникальный, хотя и не РК. Fill factor - 0.

alexeyvg,

Не очень понял, можно пример?
По 50 МБ это как, если файл сейчас 100000 МБ указывать сжимать до 99950? (ну или текущее - 50 МБ). Так вроде всё равно будет долго выполняться такое.

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

База из серии 1С, к документообороту относится.

Самая большая таблица:



Единственный индекс:



[_Fld9746] [varbinary](max) - ага, похоже на BLOB.

У таблицы топ 2 по размеру и росту во время шринка тоже [_SettingsData] [varbinary](max) NULL
У следующей по размеру одно из полей [_Fld1030] [varbinary](max) NOT NULL

Пойду пока освежу воспоминания по блобам.

alexeyvg,

Нашел пример сжатия частями на https://infostart.ru/public/1031815/
5 пост
и в https://www.sqlshack.com/shrinking-your-database-using-dbcc-shrinkfile/
На тестовой базе отработало нормально, проверю как будет себя вести база при таком способе.
Что-то подобное используете?

aleks222,

В смысле? 1 целое, 2 десятых ТБ - оно же 1229 ГБ. Какие 18 суток?
Если нормально всё происходит, то меньше суток на среднем сервере подобные размеры обрабатывает.

aleks222,

Если реально так долго выполняется у вас - то сочувствую. Я пока встречал только ситуации, что к моменту базы 1ТБ все же разорялись хоть на сколько-то приличное железо.

Пока немного позапускал сжатие частями из поста выше и получается неплохо. Таблицы не растут, можно останавливать в любой момент и прошлые куски уже выполнены. За два подхода 100+ ГБ освободилось.
До этого как-то запускал шринк именно с небольшим уменьшением размера файла и времени занимало уйму, но это видимо зависит ещё от разброса пустого места по файлу.

alexeyvg,

За идею спасибо! С сжатием базы реально намного проще пошло. Понаблюдаю ещё за базой несколько дней.

Хотя именно с причинами почему обычное сжатие пошло так странно осталось не ясно. У блоба с налёту не нашел описаний похожего поведения, кластерные индексы могут расти обратно при планах обслуживания индекса, но не самого шринка.