Maintenance Plan для Shrink Log базы 1C 7.7

Почему возникла такая задача, дело в том, что буквально на днях было что почему никто не может зайти в базу 1С 7.7 выдавалось окно

1С:Предприятие

Ошибка блокировки открытия базы данных

Причем часть сотрудников успешно подключается, а часть нет.

Доступ 500р в месяц к материалам сайта через Telegram

Доступ 500р в месяц к материалам сайта через MAX

Полный доступ к статье только по подписке

По моим записям наработок и предыдущих отчетов, когда такое происходило всему виной был файл лога (WorkBase20251800_28052026_0.ldf) который стал больше чем 10Gb, также обычно я ограничиваю его максимальный размер:

На заметку: У меня база в Simple режиме работает, не Full.

• Enable Autogrowth: отмечаю галочкой
• File Growth: In Percent (10)
• Maximum File Size: Limited to (MB): 10240

но когда помимо меня к управлению развертыванию баз привлекают программистов, то и случают казусы они такими тонкими моментами на заморачиваются, просто умолчанию параметр "Limited to (MB)" равняется: 2 097 152

Есть выход можно для системной базы Model предопределить как бы по дефолту значение в 10240 и в последствии не будет проблем. Стоп, нет, для баз, восстанавливаемых из бэкапа, это не сработает.

База Microsoft SQL Server model используется только как шаблон при создании новой базы данных (CREATE DATABASE).

А значит мне нужен либо скрипт, либо Maintenance Plan (План обслуживания) который будет делать Shrink Log.

На заметку: В наличии:

OS: Windows Server 2012 R2 Std (Version 6.3.9600)

SQL Server 12.0.6372.1

но все ниже справедливо и для последующих SQL серверов, если база в Simple режиме работает.

На заметку: В компании используется связка 1С 7.7 Folder + SQL

Шаг №1: Если делать Shrink Log вручную, то это выглядит так:

mstsc /v:srv-db02-test.polygon.local, как Domain Admins

открываю оснастку SQL Management Studio (Versions: 12.0.6372.1)

подключаюсь к SQL Server 12.0.6372.1 либо через Windows аутентификацию, либо SQL Authentication

через правый клик мышью на нужной базе выбираю Tasks - Shrink - Files

• Database: WorkBase20251800_15082025
• File type: выбираю "Log"
• File name: WorkBase2025_log
• Location: D:\SQL\WorkBase20251800_15082025_0.ldf
• Currently allocated space: 313,56 MB
• Available free space: 310,52 MB (99%)
• Shrink action: Release unused space

и нажимаю «ОК». Но повторюсь, это делать нужно вручную, т.к. кликать мышью.

Шаг №2: Я хочу либо написать скрипт, который это будет делать либо план обслуживания со скриптом внутри, но это не на регулярной основе, а как раз в месяц к примеру.

Шаг №3: Сначала узнаем логическое имя файла:

Ctrl + N (New Query)

USE WorkBase20241200_02052024;

GO

SELECT name, physical_name, type_desc

FROM sys.database_files;

из этого вывода именование файл журнала — это колонка «name», т.е. WorkBase2025_log

с учетом полученного имени файла лога, запрос на уменьшение файла лога будет, с учетом если в файле лога есть пробелы возьмем его именование в одинарные кавычки:

На заметку: В DBCC SHRINKFILE нельзя указывать путь к файлу (physical_name). Нужно указывать только логическое имя (name из sys.database_files).

USE WorkBase20241200_02052024;

GO

DBCC SHRINKFILE (N'WorkBase2025_log', 10240);

GO

результат выполнения:

DbId FileId  CurrentSize  MinimumSize  UsedPages    EstimatedPages

24  2   1241328 256 1241328 256

это не то.

На заметку: Самому себе

• DBCC SHRINKFILE (N’WorkBase2025_log’) — уменьшает только файл журнала до минимально возможного размера.
• DBCC SHRINKDATABASE — пытается уменьшить все файлы базы (данные и журнал).

На заметку: то есть уменьшить файл до 10240 МБ, хотя он уже меньше этого размера. Поэтому команда либо ничего не сделает, либо сообщит, что уменьшение не требуется.

Шаг №4: С учетом полученного выше, shrink файла лога базы данных которая работает в режиме Simple:

На заметку: Запрос ниже делает две операции: фиксирует все «грязные» страницы на диск, а затем пытается уменьшить файл журнала транзакций до минимально возможного размера. Выполняет контрольную точку (Checkpoint). Что происходит:

а) все измененные страницы данных, находящиеся в памяти, записываются на диск;

б) журнал транзакций помечает часть своих записей как больше не нужные для восстановления (при модели восстановления SIMPLE).

Следующая конструкция:

DBCC SHRINKFILE (N'WorkBase2025_log');

GO

Поскольку не указан второй параметр (размер), SQL Server:

а) уменьшает файл настолько, насколько это возможно;

б) не уменьшает его до 0 МБ;

в) не может переместить активные виртуальные журналы (VLF), поэтому минимальный размер зависит от того, какие части журнала сейчас используются.

Это и есть поведение, наиболее близкое к опции Maintenance Plan → Shrink Database → Release unused space.

USE WorkBase20241200_02052024;
GO

CHECKPOINT;
GO

DBCC SHRINKFILE (N'WorkBase2025_log');
GO

На заметку: в одинарные кавычки заключаем именование файла лога если в именовании присутствуют пробелы, но лучше всегда указывать.

К примеру, вот есть еще одна тестовая база:

результат выполнения запроса:

Отлично, что мне и нужно было, но к дополнению нужно для развернутой базы данных проверить параметры роста файла журнала (База в моем случаем в Simple режиме)

Шаг №5: С учетом запроса выше создаю Maintenance Plan где задействую

Итого что мне и нужно было сделать я разобрал

New Maintenance Plan…

Name: SQLShrinkDB

через Toolbox выбираю "Execute T-SQL Statement Task"

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

На этом все, с уважением автор блога ekzorchik./groups_member]