Порционный шринк базы

28.03.24

База данных - Администрирование СУБД

Скрипт позволяет высвобождать место в операционную систему, занятое файлом базы MS SQL в итерациях с заданным количеством мегабайт

О шринке расписывать не буду, яндекс полон ответов "Для чего, зачем и как".

Готовых скриптов порционного шринка на просторах я не обнаружил, прошу не кидать тапками, если все же такие есть.

Проблемы полноценного шринка базы:

1. Непонятно, сколько времени это займет с учетом нагрузки на базу (если приходится это делать на активно используемой базе)

2. Освобождение места произойдет непосредственно при окончании шринка.

Данный скрипт обрабатывает файл базы данных в цикле, итерация которого шринкует базу до определенного размера, вычисленного из доступного места в базе с учетом заданного размера порции шринка.

Скрипт выводит информацию о прогрессе через print, оповещая о том, с какого размера база шринкуется и до какого, скорость обработки порции, прогнозируемая скорость для обработки всего доступного в базе пространства, количество Mb, оставшиеся для шринка.

Сам скрипт:

use YourBase -- Выберите базу для шринка

set NOCOUNT ON;

DECLARE @PortionInMB INT = 1000 -- Замените на нужное значение, количество МБ. освобождаемое за итерацию
DECLARE @StopSizeInMB INT = 1000 -- Количество свободного места в базе, при котором нужно прекратить шринк
DECLARE @CurrentSizeInMB INT
DECLARE @FreeSpaceInMB INT
DECLARE @CurrentDBName nvarchar(64) = DB_NAME()
DECLARE @MomentumSize INT
DECLARE @StartTime datetime2
DECLARE @EndTime datetime2
DECLARE @IterationTime INT
DECLARE @RequiredSeconds INT

SET @FreeSpaceInMB = (select convert(decimal(12,2),round((a.size-fileproperty(a.name,'SpaceUsed'))/128.000,2)) as FreeSpaceMB from dbo.sysfiles a where status & 64 = 0)

WHILE @FreeSpaceInMB > @StopSizeInMB
BEGIN
    SET @CurrentSizeInMB = (select convert(decimal(12,2),round(a.size/128.000,2)) as FileSizeMB from dbo.sysfiles a where status & 64 = 0)
    SET @FreeSpaceInMB = (select convert(decimal(12,2),round((a.size-fileproperty(a.name,'SpaceUsed'))/128.000,2)) as FreeSpaceMB from dbo.sysfiles a where status & 64 = 0)
	SET @MomentumSize = @CurrentSizeInMB - @PortionInMB

    IF @FreeSpaceInMB > @StopSizeInMB
    BEGIN
		SET @StartTime = CURRENT_TIMESTAMP
		print CONVERT(VARCHAR(100), CURRENT_TIMESTAMP) + ': Start shrink iteration for database [' + @CurrentDBName + ']. From ' + CONVERT(VARCHAR(100), @CurrentSizeInMB) 
			+ ' to ' + CONVERT(VARCHAR(100), @MomentumSize) + '. Remains: ' + CONVERT(VARCHAR(100), @FreeSpaceInMB - @PortionInMB - @StopSizeInMB) + ' Mb.'
		RAISERROR( '',0,1) WITH NOWAIT
		DBCC SHRINKFILE (@CurrentDBName , @MomentumSize)
		SET @EndTime = CURRENT_TIMESTAMP
		SET @RequiredSeconds = (@FreeSpaceInMB - @StopSizeInMB) / @PortionInMB * datediff(s, @StartTime, @EndTime)
		print 'Iteration successfull on ' + CONVERT(VARCHAR(100), datediff(s, @StartTime, @EndTime)) + ' sec. The required time for all iteration: '
			+ CONVERT(VARCHAR(100), @RequiredSeconds) + ' sec. Completion time: ' + CONVERT(VARCHAR(100), DATEADD(s,@RequiredSeconds,CURRENT_TIMESTAMP))
		RAISERROR( '',0,1) WITH NOWAIT
    END
    ELSE
    BEGIN
        BREAK;
    END
END
 
 Выводимые данные


Нюансы:

Если в вашей базе больше одной файловой группы, скрипт не сработает, необходимо прицелиться в необходимый файл, данные по которому получаются в скрипте из dbo.sysfiles, можно либо отобрать топ по размеру, отобрать по имени и т.д.

RAISERROR использован для оперативного получения информации, переданной в print.

Вступайте в нашу телеграмм-группу Инфостарт

скрипт шринк mssql dba sql порционный шринк shrinkfile shrinkdatabase

Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».

  • 0% комиссии — оплата напрямую исполнителю;
  • Исполнители любого масштаба — от отдельных специалистов до команд под проект;
  • Прямой обмен контактами между заказчиком и исполнителем;
  • Безопасная сделка — при необходимости;
  • Рейтинги, кейсы и прозрачная система откликов.

См. также

HighLoad оптимизация Администрирование СУБД Разработчик 1С:Предприятие 8 1С:ERP Управление предприятием 2 Бухгалтерский учет Бесплатно (free)

После миграции с MS SQL на PostgreSQL закрытие месяца в 1С:ERP стало идти 8 часов вместо 12 минут. Рассказываем, как мы нашли причину в оценке Hash Join, которую планировщик завышал в миллионы раз, и как исправили её так, что проблемный запрос теперь выполняется за 18 секунд вместо часа.

19.10.2026    929    Tantor    0    

10

Администрирование СУБД HighLoad оптимизация Разработчик 1С:Предприятие 8 1С:ERP Управление предприятием 2 Россия Бесплатно (free)

Большинство материалов о компрессии в PostgreSQL отвечают на вопрос «во сколько раз удалось уменьшить базу». Мы предлагаем посмотреть на проблему с другой стороны — какой ценой достигается эта экономия? В статье разбираем архитектурные компромиссы различных подходов к компрессии страниц, объясняем, почему при разработке CSM в Tantor Postgres отказались от погони за максимальным коэффициентом сжатия, и показываем результаты нагрузочных испытаний на реальных базах 1С.

01.10.2026    1430    Tantor    6    

17

DevOps и автоматизация разработки Администрирование СУБД Групповая разработка (Git, хранилище) Разработчик 1С 8.3 Абонемент ($m)

В корпоративных инсталляциях «1С:Предприятие 8.3» под управлением PostgreSQL всё чаще проявляются архитектурные пределы масштабирования: рост числа пользователей, обязательная маркировка, плотный поток API-интеграций и высокая стоимость простоя. Вводная часть цикла разбирает ключевые факторы современной эксплуатационной нагрузки и формирует инженерную методологию эволюционной модернизации без остановки продуктивного контура. Материал основан на практическом кейсе «Торговый контур» и показывает, как определить целевые метрики (p95, MTTR, APDEX), выстроить наблюдаемость, стабилизировать работу кластера и подготовить инфраструктуру к дальнейшему масштабированию. Публикация задаёт фундамент для последующих частей, посвящённых телеметрии, оптимизации PostgreSQL, CI/CD и архитектурному росту.

1 стартмани

10.09.2026    1506    Ninel_S    0    

6

HighLoad оптимизация Администрирование СУБД Разработчик 1С:Предприятие 8 1С:ERP Управление предприятием 2 Бесплатно (free)

В рамках 18 релиза СУБД Tantor Postgres мы рассказывали об оптимизациях, которые помогают планировщику сделать более точный выбор между Nested Loop и Hash Join. В следующем релизе у нас планируются оптимизации, которые позволят ускорить выполнение как Nested Loop, так и Hash Join. Сегодня мы расскажем об одном из таких методов - фильтре Блума.

31.08.2026    6105    Tantor    3    

18

Администрирование СУБД Системный администратор Разработчик 1С 8.3 Бесплатно (free)

Мы подготовили для сообщества Infostart.ru практическое занятие, в котором каждый желающий сможет: научиться собирать реальные данные о процессах кластера 1С; выявлять «перестарков» — процессы старше периода и без соединений; выполнять безопасный перезапуск (с dry-run и подтверждением); настраивать автоматическую проверку через systemd на Linux; отправлять уведомления (Telegram, почта) при обнаружении проблем; работать с логами, ротацией, профилями кластеров и конфигурацией; развернуть полноценный учебный проект AdminClusterMonitor у себя в тестовой среде.

30.08.2026    1717    Ninel_S    2    

6

Администрирование СУБД Системный администратор 1С:Предприятие 8 Бесплатно (free)

На infostart.ru вышел разбор Ивана Недомолкова «Сервер 1С падает: настройка сбора дампов (logcfg.xml), лимиты памяти и передача дампа в поддержку» - это хорошая инструкция, как ловить и разбирать падение rphost постфактум: logcfg.xml, procdump, анализ дампа. Но там нет ответа на вопрос «а почему кластер вообще прибил процесс сам, ещё до всякого краша». Мы дополняем разбор тремя сводными таблицами лимитов памяти и автомасштабирования кластера - и заодно фиксируем, чем в этой части лицензия ПРОФ урезана относительно КОРП.

12.08.2026    2342    Ninel_S    5    

6

Администрирование СУБД Системный администратор Разработчик Бесплатно (free)

5,5 тысячи пользователей в единой базе 1С, розница в режиме 24/7 и SLA 99,98% – в таких условиях любая авария быстро превращается в очереди на кассах, потерю денег и давление со стороны бизнеса. Показываем, как выстроить процесс аварийно-восстановительных работ: от первых алертов и базового скрининга системы до подключения команды, проверки гипотез и дебрифа после инцидента. Разбираем, как метрики, дашборды, техжурнал, Zabbix, Prometheus, Grafana, Telegram-боты и скрипты помогают не гадать, а быстро находить причину проблемы. На реальных авариях объясняем, почему «быстро» не должно означать «рискованно», как работа над ошибками снижает панику и почему каждая авария может сделать систему надежнее.

11.08.2026    3392    jul.dolganova    9    

24
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. nvv1970 11.04.24 08:59 Сейчас в теме
Есть какая-то статистика, сколько времени занимает шринк относительно "обычного", когда освобождают сразу 50-90% базы? Т.е. это ускоряет или замедляет общий процесс?
2. Garilia 73 14.04.24 00:49 Сейчас в теме
(1) для моих кейсов порционный шринк всегда оказывался быстрее, да и в случае необходимости прервать операцию - прогресс шринка теряет только последнюю запущенную итерацию. На днях сравню время выполнения высвобождения 900 Гб из базы 3.7 ТБ обоими вариантами.
3. Garilia 73 17.04.24 14:53 Сейчас в теме
(1)
Дано:
База 3.7 ТБ
Свободно внутри базы - 877 ГБ
Операция полного шринка одной итерацией для базы - 15 часов и 5 минут
Порционный шринк - 22 часа.

Время для отпуска первой порции в текущей схеме распределения данных внутри базы - 2613 секунд, последующие по разному от 177 до 1700 секунд с порцией в 5000 МБ.

Скорость выполнения вероятно будет у всех разная, т.к. у меня 877 ГБ места получается после точечного вырезания определенных данных из файла базы, находящихся на всем поле размеченного пространства (свертка баз по последним N дням с сохранением ссылочной целостности для регистров и т.д. конкретно с этой базой чистились технологические таблицы и различные конф. данные - поэтому неразмеченные блоки располагаются практически везде)

На других базах, время для высвобождения первой порции памяти варьируется от 100+ секунд до 1000
METAL; nvv1970; +2 – Ответить
4. sutygin 36 21.05.24 12:43 Сейчас в теме
(3) А имеет ли смысл делать вот это все, т.к. субд все равно займет не используемое пространство, а на размер бэкапов это не как не скажется?
5. Garilia 73 11.06.24 18:24 Сейчас в теме
(4) При восстановлении базы на сервере СУБД, она запросит такое количество пространства с учетом неразмеченных областей внутри файла базы.

Т.е. если взять две базы:
[0] Одна весит 100 ГБ, внутри базы неразмечено 50 ГБ
[1] Эта же база, но после шринка весит 50 ГБ, внутри базы неразмечено 0 ГБ

Файлы бэкапов будут весить одинаково

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

Так же, если произошла не самая нормальная реструктуризация, которая создала кучу ng таблиц в процессе, например возьмем какой нибудь регистр, при реструктуризации файл базы вырос на размер этой таблицы, условно - 300 ГБ. В случае если это не единственная база на диске, для возможности работоспособности других, необходимо либо увеличить диск, либо шринкануть разросшийся файл базы.

Update:
Отшринкованный файл бэкапа будет весить чуть меньше.
6. sutygin 36 11.06.24 22:15 Сейчас в теме
Ну попробую на своей, может действительно быстрее
7. fetch19 30.09.24 12:06 Сейчас в теме
Не работает ваш скрипт почему то.
Вот что выдает

он вроде как шринкует, но текущий размер не меняется

Но тут дело в базе, не получается ее ни каким способом шринкануть. скуль ошибок не выдает но результата нет, хотя в базе 80 процентов свободного места...
Прикрепленные файлы:
8. fetch19 30.09.24 12:12 Сейчас в теме
(7) вот что в messages пишет

Sep 30 2024 12:08PM: Start shrink iteration for database [_C1_ERP_COPY_YESTERDAY_ZIP]. From 1785880 to 1784880. Remains: 1439698 Mb.

File ID 1 of database ID 6 cannot be shrunk as it is either being shrunk by another process or is empty.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Iteration successfull on 14 sec. The required time for all iteration: 20160 sec. Completion time: Sep 30 2024 5:44PM

Sep 30 2024 12:08PM: Start shrink iteration for database [_C1_ERP_COPY_YESTERDAY_ZIP]. From 1785880 to 1784880. Remains: 1439698 Mb.

DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Iteration successfull on 83 sec. The required time for all iteration: 119520 sec. Completion time: Oct 1 2024 9:22PM

Sep 30 2024 12:10PM: Start shrink iteration for database [_C1_ERP_COPY_YESTERDAY_ZIP]. From 1785880 to 1784880. Remains: 1439697 Mb.

DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Iteration successfull on 100 sec. The required time for all iteration: 144000 sec. Completion time: Oct 2 2024 4:12AM

Sep 30 2024 12:12PM: Start shrink iteration for database [_C1_ERP_COPY_YESTERDAY_ZIP]. From 1785880 to 1784880. Remains: 1439696 Mb.

DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Iteration successfull on 22 sec. The required time for all iteration: 31680 sec. Completion time: Sep 30 2024 9:00PM

Sep 30 2024 12:12PM: Start shrink iteration for database [_C1_ERP_COPY_YESTERDAY_ZIP]. From 1785880 to 1784880. Remains: 1439695 Mb.
9. fetch19 30.09.24 12:15 Сейчас в теме
(8) а вот как чз гуи показывает
Прикрепленные файлы:
Для отправки сообщения требуется регистрация/авторизация