Сокращаем журнал регистрации в базах 1с при помощи обновлятора
2021-11-16T22:45:31+00:00Введение
В этом уроке мы научимся использовать обновлятор для однократного (или регулярного по расписанию) сокращения журнала регистрации в одной или группе баз.
При этом я покажу как сохранять и архивировать сокращаемую часть журнала на отдельный диск.
Пакетные скрипты
Все операции мы будем проводить на закладке обновлятора "Скрипты":

Если вы ещё не работали с пакетными скриптами в обновляторе, советую бегло пробежаться по их возможностям: ссылка.
Оговорка
Всю следующую практическую часть мы будем делать на примере одной базы и запускать этот скрипт вручную.
Но в реальных задачах ничего не помешает нам запускать скрипт для любого количества баз (в том числе параллельно) и сохранять этот скрипт в расписание с уведомлением на почту - обо всё этом здесь.
Простейший вариант скрипта
За сокращение журнала регистрации (для любых типов баз: файловых и серверных) отвечает ключ ReduceEventLogSize в пакетном режиме конфигуратора.
В качестве параметра он принимает новую (левую) границу журнала регистрации в формате ГГГГ-ММ-ДД.
И если мы, например, хотим сократить все записи в журнале регистрации до 1 января 2018 года, то простейший вариант скрипта будет таким:

Текст скрипта
%run_1c_d% /ReduceEventLogSize 2018-01-01 |
Добавляем сохранение удаляемой части в архив
Но этого мало. Мы хотим не просто сокращать журнал регистрации (который обычно занимает непростительно много места на системном диске), но ещё и сохранять сокращаемую часть на другом диске (и желательно в сжатом архиватором виде). Чтобы в случае чего к ней можно было обратиться через меню "Файл-Открыть " в конфигураторе.
Предположим, что общим местом хранения архивов журналов регистрации (для всех баз) является папка "x:\Backups\1C\EventLogs".
Этот путь уже должен существовать.
Модифицируем наш скрипт, чтобы сокращаемая часть писалась в эту папку с правильным именем:

Текст скрипта
%run_1c_d% /ReduceEventLogSize 2018-01-01 -saveAs "x:\Backups\1C\EventLogs\%stamp%.lgd" |
Сжимаем сокращаемую часть архиватором
Для этого файл выгрузки сокращаемой части упакуем архиватором 7z (он идёт вместе с обновлятором), а затем удалим сам файл.
Скрипт будет таким:

Текст скрипта
%run_1c_d% /ReduceEventLogSize 2018-01-01 -saveAs "x:\Backups\1C\EventLogs\%stamp%.lgd"
"%seven_zip%" a "x:\Backups\1C\EventLogs\%stamp%.zip" "x:\Backups\1C\EventLogs\%stamp%.lgd" -tzip -mx3
del "x:\Backups\1C\EventLogs\%stamp%.lgd" |
Всегда сокращаем журнал на текущую дату
У нас получился универсальный скрипт, который уже можно выполнять для группы баз и ставить в планировщик.
Если бы не дата, которая жёстко прописана в скрипте, что делает бессмысленным многократный запуск этого скрипта в неизменном виде.
Давайте изменим скрипт так, чтобы при его запуске всегда подставлялась текущая дата. Это позволит нам поставить скрипт в планировщик на запуск, скажем раз в месяц, и забыть о ручном сокращении журнала регистрации раз и навсегда.
Задача получить текущую дату в скрипте в формате ГГГГ-ММ-ДД не такая простая, если рассматривать универсальное решение для всех случаев жизни.
Но для случая, когда представление даты на компьютере имеет вид ДД.ММ.ГГГГ (обычно это так по умолчанию), вытащить нужные числа и поставить их в нужном порядке можно вот так:
set current_date=%date:~6,4%-%date:~3,2%-%date:~0,2% |
Обратите внимание, что мы здесь просто вытаскиваем по индексу и длине нужные части из даты, которая первоначально имеет вид ДД.ММ.ГГГГ, то есть переводим строку в формате ДД.ММ.ГГГГ в формат ГГГГ-ММ-ДД.
В итоге получим вот такой скрипт:

Текст скрипта
set current_date=%date:~6,4%-%date:~3,2%-%date:~0,2%
%run_1c_d% /ReduceEventLogSize %current_date% -saveAs "x:\Backups\1C\EventLogs\%stamp%.lgd"
"%seven_zip%" a "x:\Backups\1C\EventLogs\%stamp%.zip" "x:\Backups\1C\EventLogs\%stamp%.lgd" -tzip -mx3
del "x:\Backups\1C\EventLogs\%stamp%.lgd" |
Удаляем неиспользуемые страницы из журнала регистрации
Вы удивитесь, но несмотря на все вышеописанные процедуры, размер файла в котором журнал физически хранится в формате sqllite не уменьшится совершенно.
То есть если он был 10 гигабайт до процедуры сокращения записей, то 10 гигабайт и останется.
Всё дело в том, что, после удаления записей из журнала регистрации, физически данные с диска не удаляются, а лишь помечаются как удаленные. Это сделано для повышения производительности.
За сжатие журнала регистрации отвечает команда Vacuum, она позволяет удалить все неиспользуемые страницы и дефрагментировать данные.
Выполнение этой команды требует остановки сервера 1с (если речь о серверной базе), чтобы получить монопольный доступ к файлу журнала регистрации.
Поэтому я рекомендую сделать эту операцию (если файл журнала регистрации уже сейчас очень сильно вырос) один раз и в дальнейшем регулярно выполнять сокращение через ключ конфигуратора ReduceEventLogSize (мы его рассмотрели выше). Это позволит удерживать размер журнала регистрации примерно на одном уровне.
Подготовительные работы
Для выполнения команды Vacuum нам понадобится утилита sqlite3, которую можно скачать с официально сайта: http://www.sqlite.org/download.html
Качаем и распаковываем вот этот пункт:

Там 3 утилиты, из которых нам нужна sqlite3.exe.
Альтернативное место для скачивания этой же утилиты - мой сайт (я подписал её своей электронной подписью).
Распакуем эту утилиту, например, в папку "x:\work" и соответственно будем обращаться к ней из скриптов как "x:\work\sqlite3.exe".
Vacuum для файловых баз
Для файловых баз выполним команду Vacuum через новый пакетный скрипт обновлятора, полагая что журнал регистрации хранится в папке с базой в "1Cv8Log\1Cv8.lgd".

Текст скрипта
if exist "%base_path%\1Cv8Log\1Cv8.lgd" (
cd /d "%base_path%\1Cv8Log"
"x:\work\sqlite3.exe" "1Cv8.lgd" vacuum
) |
Ещё раз напомню, что команду Vacuum имеет смысл выполнять уже после сокращения журнала регистрации при помощи описанного выше ключа конфигуратора ReduceEventLogSize.
С серверными базами всё несколько сложнее, в том смысле что полной автоматизации выполнения команды Vacuum для избранных баз простым пакетным скриптом не достичь.
Не достичь хотя бы потому, что невозможно автоматически определять путь к журналу регистрации серверной базы. Это нужно делать разбором файла настроек сервера 1с (1CV8Clst.lst), который тоже ещё надо правильно обнаружить. Все эти возможности выходят за рамки пакетного скрипта.
Но так как мы изначально планируем сделать Vacuum только после первого сокращения журнала регистрации, то полной автоматизации нам здесь и не надо.
1. Находим папку с настройками кластера 1с. Обычно это что-то типа: "c:\Program Files\1cv8\srvinfo\reg_1541".
2. В ней подпапки - на каждую базу своя. В каждой из этих подпапок есть папка 1Cv8Log с нужным нам 1Cv8.lgd, на который и нужно направить команду Vacuum.
Например, так (указанный внутри скрипт пишется и запускается в командном файле vacuum.cmd без обновлятора):
А что если нам требуется определить какой папке соответствует какая база? Для этого открываем файл 1CV8Clst.lst в корне reg_1541 и из него находим, что, например, папке 0deaa216-26dd-4ae0-9483-51a85b38c093 соответствует база test:
То есть мы можем выполнить vacuum как для всех баз на сервере, так и для избранных.