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

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

См. также

Администрирование СУБД Системный администратор Программист

В крупных компаниях, где много типовых и сильно доработанных баз с режимом работы 24/7, переход с MS SQL на PostgreSQL затягивается. Получается гетерогенная структура – когда прод уже на PostgreSQL, а разработка и тестирование – пока на MS SQL. О том, какие варианты помогут постепенно перевести прод с несколькими базами MS SQL на PostgreSQL, не сломав среду тестирования и разработки, пойдет речь в статье.

21.11.2024    3084    a.doroshkevich    7    

15

Администрирование СУБД Системный администратор Платформа 1С v8.3 Бесплатно (free)

Пользовался ранее https://infostart.ru/1c/articles/1120161/#, но она устарела, т.к. службы запускаются через systemctl, да и сами службы слегка изменились. Возможно, где-то на ИТС уже есть нужная инструкция, но мне не попалась.

15.11.2024    399    Baser    2    

1

HighLoad оптимизация Администрирование СУБД Системный администратор Программист Платформа 1С v8.3 Россия Бесплатно (free)

Мы исследуем проблему долгого выполнения запросов PostgreSQL при использовании конструкции VALUES: когда она возникает, как на нее можно повлиять, а главное, почему ее продуманная отработка важна для более быстрого функционирования решений на базе 1С

12.11.2024    971    Tantor    20    

15

HighLoad оптимизация Администрирование СУБД Механизмы платформы 1С Программист Платформа 1С v8.3 ИТ-компания Россия Бесплатно (free)

В данной статье мы рассмотрим, как работает механизм временных таблиц на postgres на платформе 8.3.23 и что изменилось в нем при добавлении новых возможностей в платформе 8.3.25. А также на примере покажу, как понимание работы платформы позволяет оптимизировать СУБД для работы с 1С.

29.10.2024    3574    Tantor    38    

35

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

CDC - очень мощный механизм, который можно использовать во многих сценариях, возможность развернуть его в Docker показывает простоту и лёгкость данной технологии.

08.10.2024    847    AlexSvoykin    1    

7

Администрирование СУБД Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Анализ и решение ошибок СУБД. Во время реиндексации базы Ошибка СУБД: Microsoft SQL Server Native Client 11.0: Не удалось найти объект "ИмяБазы.dbo._RefSInf21806", так как он не существует, или отсутствуют разрешения. Во время проверки целостности Ошибка СУБД: Microsoft SQL Server Native Client 11.0: Недопустимое имя объекта "dbo._RefSInf21806".

19.09.2024    4632    Xershi    10    

17

HighLoad оптимизация Администрирование СУБД Архивирование (backup) Системный администратор Программист Платформа 1С v8.3 Бесплатно (free)

Бэкап в Postgres состоит из набора граблей, которые нужно обойти для успешного восстановления. Они заложены в самых неожиданных местах от предмета резервного копирования (база или кластер) до структуры каталогов. Один неверный шаг и восстановление будет невозможным. Почему нельзя было сделать проще, как в MS SQL или Oracle? Почему бэкап в Postgres оставляет впечатление чьей-то лабораторной работы? Статья адресована прежде всего специалистам 1С, избалованным комфортом в MS SQL, в суровых буднях импортозамещения на Postgres.

13.08.2024    3060    1CUnlimited    9    

4
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. nvv1970 11.04.24 08:59 Сейчас в теме
Есть какая-то статистика, сколько времени занимает шринк относительно "обычного", когда освобождают сразу 50-90% базы? Т.е. это ускоряет или замедляет общий процесс?
2. Garilia 68 14.04.24 00:49 Сейчас в теме
(1) для моих кейсов порционный шринк всегда оказывался быстрее, да и в случае необходимости прервать операцию - прогресс шринка теряет только последнюю запущенную итерацию. На днях сравню время выполнения высвобождения 900 Гб из базы 3.7 ТБ обоими вариантами.
3. Garilia 68 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 68 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) а вот как чз гуи показывает
Прикрепленные файлы:
Оставьте свое сообщение