Проблема: На сервере растут логи баз на платформе 8.3.
Необходимо: Часть логов, например, за месяц, оставить доступными напрямую из базы, остальные обрезать и хранить на других дисках. Делать это необходимо автоматически.
Как было раньше(8.1 и 8.2): В конфигураторе можно было указать настройку: «Разделять хранение журнала по периодам» и указать период, например, Неделя. Таким образом, каждая неделя логов хранилась в отдельном файле. Батником копировались и архивировались старые логии на отдельный диск, чтобы они не занимали место на сервере. При необходимости посмотреть «древний» лог, мы возвращали файл за требуемый период на место и просматривали его стандартными средствами 1С.
Как нынче в 8.3: Журнал регистрации хранится в файле 1Cv8.lgd – это файл базы данных sqlite. Настройка «Разделять хранение журнала по периодам» в конфигураторе отсутствует. Осталась кнопка «Сократить», с помощью которой обрезается часть журнала и переносится в указанный файл. Однако после этого размер логов не уменьшается. Что нужно сделать, чтобы размер файла уменьшился, напишу чуть ниже.
Напомню, что все должно работать автоматически. Конфигурация типовая, поэтому трогать ее не будем.
Что было сделано: В планировщике заданий добавил задание, которое выполняет cmd-файл, который запускает 1С с параметрами. В параметре «/Execute», указан путь до обработки, которая копирует часть журнала регистрации в файл, затем эту часть обрезает.
В обработке воспользовался процедурами по работе с журналом регистрации:
Фильтр = Новый Структура("ДатаОкончания");
Фильтр.ДатаОкончания = НачалоГода(ТекущаяДата());
СкопироватьЖурналРегистрации(,ИмяФайлаКопииЖурнала, Фильтр);
ОчиститьЖурналРегистрации(Фильтр);
Обработку запускаю cmd-файлом:
"C:Program Files1cv82common1cestart.exe" ENTERPRISE /S "ServerName:PortNumberNameBD" /N "ИмяПользователя" /P "Пароль" /Execute "D:Сократить журнал регистрацииСократитьЖурналРегистрацииПериод.epf" /C "Период=Неделя; СохранитьЖР=D:Сократить журнал регистрацииНашиЛоги"
В параметре «/С» передается период деления журнала регистрации (День / Неделя / Месяц / Год) и путь до места, где будут храниться обрезанные логи.
После сокращения журнала регистрации размер файла журнала регистрации не изменяется. Чтобы он изменился, необходимо остановить агент сервера и выполнить команду vacuum. Затем запустить службу агента сервера. В планировщике заданий добавил задание, которое выполняет следующий cmd-файл:
net stop "1C:Enterprise 8.3 Server Agent (x86-64)"
sleep 5
D:scriptssqlite3.exe D:ДиректорияХраненияЛоговНаСервере1Cv8Log1Cv8.lgd vacuum
net start "1C:Enterprise 8.3 Server Agent (x86-64)"
Утилиту sqlite3.exe можно скачать с официального сайта http://www.sqlite.org/
Для того чтобы в cmd-файле можно было использовать кириллицу, сохраняю его через «Notepad++» в кодировке ОЕМ866.
Что получили: Логи хранятся за каждую неделю в отдельных файлах. Размер файла 1Cv8.lgd не увеличивается.
Обрезанную часть логов, перенесенную в отдельный файл, можно просмотреть штатными средствами 1С: Все функции->Стандартные->Журнал регистрации->Еще->Просмотреть из файла.
Для того чтобы, при необходимости была возможность восстановить обрезанные данные написал небольшую внешнюю обработку, в которую так же добавил весь функционал описанный выше.
Есть идея более простого обрезания и сохранения логов без запуска 1С на сервере с обработкой: можно останавливать агент сервера, переименовывать файл 1Cv8.lgd и запускать сервер. При первом запуске 1С будет создан новый пустой файл журнала регистрации. Главный минус этого варианта: если после переименования файла потребуется посмотреть журнал регистрации, то придется открывать журнал из внешнего файла, который может лежать на недоступном для пользователя диске сервера. В варианте же приведенном выше, в журнале будет храниться история не меньше, чем за указанный период (День / Неделя / Месяц / Год).
В общем-то и все. Если есть замечания и дополнения, добро пожаловать в комментарии. Все важные нюансы обязательно добавлю в статью. Спасибо.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
в принципе не обязательно выполнять vacuum — новые записи будут добавляться в освободившееся внутри файла базы место
(1) oldfornit,
Это когда базу не раздуло. А то у меня например она занимает 90Гб. Из 240 Гб дискового места…. мне она такая большая за год не нужна….
(2) TODD22, настройте очистку по регламенту, один раз сожмите и в будущем будет занимать ровно столько места, сколько надо. по аналогии с журналом транзакции в MS SQL
Спасибо.
Пригодится.
(2) TODD22, обработка как раз писалась в то время, когда 1С выпустили проблемное обновление платформы и логи баз росли по 300МБ в день…
(1) oldfornit, хороший вариант, особенно для тех, кто не перезапускает агент сервера каждый день.
Полезная штука. Тем более заметил, что иногда начинаются непонятные глюки с сервером 1с и зависанием сеансов. Но каким-то странным образом после удаления логов эти глюки уходят, а через некоторое время возвращаются. И каждый раз чистка логов помогает на время.
Не знаю от чего это, мистика просто. Релизы платформ причем могут быть разные. Но на некоторых серверах такого нет. То ли еще и ОС замешали что ли
Вот я не пойму. Раз уж сделала 1С хранение журнала в SQLite, почему не хранить журнал в отдельной СУБД вообще на другом сервере?
(8) karapuzzzz,
предполагаю, что это сделано для универсальности работы с журналом регистрации для серверных и файловых баз.
(9) а как насчет скорости? Все-таки писать в локальную sqlite/текстовые файлы быстрее, чем на удаленный сервер.
(10) oldfornit, возможно. Скорость действительно тут очень важна.
Но когда у вас файловый вариант базы, больше некуда писать, кроме как в локальную sqlite.
Если я удалю(перемещу) файл журнала регистрации который на sqlite. У меня при перезапуске сервер новый файл создаст?
А то старый не сжимается. Вываливается при сжатии платформой с ошибкой.
(12) TODD22, да, сервер создаст новый файл. При желании можно сделать так, чтобы новый журнал был в старом (текстовом формате). Для этого достаточно положить в каталог журналов файл с именем «1с.LGP» (если не напутал)
(13) oldfornit, Да создал новый файл.
Мне старый формат не нужен. Лог стал 100Гб и никак не хотел урезаться. При сжатии падал с ошибкой.
Я так понял обработка при операции копирования журнала регистрации просто заменяет данные в старом журнале регистрации т.е удаляет старые и добавляет новые записи, сделанной аналогичным образом, а не дополняет?
(15) danya1606, верно, копирует часть журнала регистрации текущей базы в файл. Если файл уже существует, то он будет заменен. Если установлена галка «Скопировать и сократить», то ЖР будет скопирован в файл и затем удален из базы до указанной даты.
(16) А можно ли как то добиться того что — архивный файл ЖР будет дополняться записями допустим делать такой перенос каждый квартал?
(17) danya1606, стандартная процедура СкопироватьЖурналРегистрации(<ИмяВходногоФайла>, <ИмяВыходногоФайла>, <Фильтр>) заменяет файл, если он существует. Можно восстанавливать ЖР из файла в базу, а потом снова обрезать но большим периодом))) Но в чем смысл?
(18) Смысл в том чтобы держать копить один файл журнала регистрации допустим за год, ну а с функцией скопировать получается что он делает копию ЖР а не дополняет тот архивный. Объясню по простому например учет в программе 1С начнем с 01-01-2016, т.е. от это даты и начинается ЖР:
1)01-04-2016 делаем первый — срезку ЖР
2)01-07-2016 делаем вторую срезку ЖР получается второй отдельный файл
3)01-10-2016 делаем третью срезку ЖР получается третий отдельный файл
В итоге если вдруг нам понадобиться проанализировать за целый год разом ЖР по определенному объекту нам придется три раз файлы подменять для данной операции.
Чтобы не иметь гемора с настройкой ротации логов, я просто веду ЖР в старом формате (можно стопорнуть сервак и подложить пустой файлик со старым названием, после старта ЖР будет вести в него запись в старом формате). И вообще считаю перевод логов на SQLite ошибкой.
Никто не реализовывал службу переноса всех данных из файла в, например, MS-SQL?
А то логи, за пару месяцев в 90 гиг немножко утомили, если честно уже ….
(21) enzain, реализовывал. Не стоит оно того. Запись в базу данных происходит достаточно медленно — практически день в день. Итоговые размеры базы — по размеру больше чем в SQLITE.
Есть решение по переносу ЖР в elasticsearch — посмотрите тут вебинар по big data
Пишу скрипт так, как указано в статье не выполняет команду, в чем может быть проблема?
(23) Вы запускаете sqlite3.exe, в статье же описывается как запустить сжатие из командной строки D:scriptssqlite3.exe D:ДиректорияХраненияЛоговНаСервере1Cv8Log1Cv8.lgd vacuum
На больших базах логов (десятки ГБ) мне не удавалось дождаться сжатия, приходилось писать журнал с нуля, а потом вовремя обрезать.
(24) sqlite ругается «unreconized token» на открытие файла
(25)
по команде .open 1cv8.lgd (при этом файл лога лежит в той же папке где и sqlite) и затем с новой строки vacuum; у меня получилось, но скриптом не удается выполнить действия в две строки.
обработка копирует только неделю, и какую неделю — последнюю, 7 дней от запуска, с начала? Или копирует определенное количество строк?
Что остается — лог .lgd без недели, который потом ужимается, или неделя забирается в отдельный файл, остается тоже условная «неделя», а остальное стирается?
поясните пожалуйста, в чем разница между обработками, из описания откровенно говоря не понял…
(28) Обработка «Работа с журналом регистрации 1С83» — это обработка в которой можно ВРУЧНУЮ:
— восстановить журнал из файла,
— очистить журнал до даты(место не освободится, если не выполнить vacuum),
— скопировать часть журнала регистрации в файл.
При запуске обработки «Сократить журнал регистрации» сразу запустится сокращение журнала регистрации по параметрам, которые передаются при открытии 1С.
Поставили задачу сократить журнал регистрации. Впервые с таким столкнулся вообще и вот те на! Ваша статья. Спасибо большое, буду пробовать сейчас.