unfilled's blog. 1С старый формат журнала регистрации 1с

Переключение журнала регистрации в старый формат — Техлаб

11/03/2016

Переключение журнала регистрации в старый формат

Введение

Новый формат журнала регистрации был реализован в платформе 1С:Предприятие 8 в версии 8.3.5.1068. Начиная с этой версии при создании новой информационной базы журнал регистрации будет храниться в одном файле базы данных SQLite с расширением .lgd, который располагается:

• Для файлового варианта информационной базы – в подкаталоге 1Cv8Log каталога информационной базы.
• Для клиент-серверного варианта информационной базы – в подкаталоге 1Cv8Log каталога информационной базы в каталоге служебных файлов кластера. Имя каталога можно определить по файлу реестра данных кластера.

Целью переработки журнала регистрации и перевода его в новый формат было увеличение скорости выполнения запросов к нему и повышение надежности хранения данных. Новость об этом была размещена на официальном ресурсе фирмы 1С. Обновление платформы до версии 8.3.5.1068 и выше не приводит к автоматическому переводу журнала регистрации в новый формат у уже созданных информационных баз. Но при этом имеется возможность смены формата на новый штатными средствами платформы. Для этого следует открыть диалог настройки журнала регистрации (Главное меню –> Администрирование –> Настройка журнала регистрации) и нажать кнопку «Новый формат».

Проблемы при работе с новым форматом журнала регистрации

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

Итак, одна из проблем возникает после перезапуска кластера серверов или аварийного завершения работы менеджера кластера. При этом возможно разрушение структуры файла журнала регистрации .lgd. При попытке открыть такой журнал регистрации происходит ошибка:

sqlite3_step failed: database disk image is malformed

Также иногда можно заметить проявление следующей ошибки при попытке в конфигураторе открыть файл журнала регистрации нового формата:

sqlite3_exec failed: attempt to write a readonly database

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

0,EXCP,1,process=rmngr,p:processName=RegMngrCntxt,p:processName=ServerJobExecutorContext,Exception=81029657-3fe6-4cd6-80c0-36de78fe6657,Descr='src\RemoteInterfaceImpl.cpp(963):

81029657-3fe6-4cd6-80c0-36de78fe6657: Передача данных прервана по инициативе принимающей стороны.'

Данная строка ТЖ говорит о том, что процесс rmngr центрального сервера не отвечает, так как занят работой с журналом регистрации. И далее в технологическом журнале можно видеть следующие записи:

0,EXCP,0,process=rmngr,p:processName=RegMngrCntxt,p:processName=ServerJobExecutorContext,Exception=81029657-3fe6-4cd6-80c0-36de78fe6657, Descr='src\RMngrCalls.cpp(549): 81029657-3fe6-4cd6-80c0-36de78fe6657:server_addr=tcp://[сервер]:[порт] descr=Сервер недоступен (Не отвечает, завершается аварийно или порт занят другим приложением) line=1073 file=src\DataExchangeTcpClientImpl.cpp'

Помимо этого, достаточно часто возникает проблема с высоким потреблением памяти журналом регистрации в новом формате. Данное поведение проявляется, например, если кто-то из пользователей случайно запустит выборку по ЖР без ограничения по периоду. При этом весь журнал регистрации попадет в память, вытеснит весь кэш и "положит" сервер.

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

Перевод журнала регистрации в старый формат

Штатные средства платформы 1С не позволяют перевести журнал регистрации из нового формата в старый. Здесь мы опишем способ, который позволит выполнить данную задачу вручную. Итак, для начала необходимо остановить службу 1С. При этом, необходимо согласовать данное действие с пользователями, так как при этом они не смогут работать с информационными базами, которые находятся в соответствующих кластерах 1С.

После того как служба 1С остановлена, переходим в каталог файлов информационной базы для которой необходимо изменить формат журнала регистрации. Данный каталог выглядит следующим образом:

…\1cv8\[каталог служебных файлов службы 1С, обычно srvinfo]\reg_ + [номер порта менеджера кластера]\[UUID информационной базы]

Уникальный идентификатор информационной базы (UUID) можно получить из файла «1CV8Clst.lst», который располагается в каталоге реестра кластера. Для быстрого получения идентификаторов баз и их имен из файла реестра кластера можно воспользоваться следующим регулярным выражением:

\{(\w{8}\-.*\w{12})\,\"(.*?)\"\,.*[\\r]*\n+.*\"\,\d+\}

Далее в каталоге файлов информационной базы ищем папку «1Cv8Log» и переносим оттуда все файлы в отдельный каталог. Затем в папке «1Cv8Log» создаем пустой файл журнала регистрации в старом формате «1Cv8.lgf».

После того как все этапы данной процедуры выполнены, запускаем службу 1С. Готово, теперь журнал регистрации переведен в старый формат. Чтобы обратно вернуться к новому формату ЖР воспользуйтесь инструкцией, описанной во введении данной статьи.

Заключение

В статье мы постарались описать возможные проблемы при работе с новым форматом журнала регистрации. Такие проблемы чаще всего возникают на предприятиях с большим числом пользователей 1С. Далее мы описали способ перехода с нового формата на старый. Это может быть полезно, так как на данный момент не существует стандартных средств, предоставляемых платформой 1С, которые бы позволили это сделать.

Надеемся, вы сможете с легкостью выполнить нужную вам задачу и продолжите с удовольствием пользоваться продуктами 1С. Ну а если у вас что-то не получится, или вы столкнетесь с какими-то трудностями, обращайтесь к нам, мы обязательно поможем!

techlab.rarus.ru

Сокращаем журнал регистрации в базах 1с при помощи обновлятора

Сокращаем журнал регистрации в базах 1с при помощи обновлятора

2018-06-22T12:56:09+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 для серверных баз

С серверными базами всё несколько сложнее, в том смысле что полной автоматизации выполнения команды Vacuum для избранных баз простым пакетным скриптом не достичь.

Не достичь хотя бы потому, что невозможно автоматически определять путь к журналу регистрации серверной базы. Это нужно делать разбором файла настроек сервера 1с (1CV8Clst.lst), который тоже ещё надо правильно обнаружить. Все эти возможности выходят за рамки пакетного скрипта.

Но так как мы изначально планируем сделать Vacuum только после первого сокращения журнала регистрации, то полной автоматизации нам здесь и не надо.

Я опишу лишь примерный порядок действий:

1. Находим папку с настройками кластера 1с. Обычно это что-то типа: "c:\Program Files\1cv8\srvinfo\reg_1541".

2. В ней подпапки - на каждую базу своя. В каждой из этих подпапок есть папка 1Cv8Log с нужным нам 1Cv8.lgd, на который и нужно направить команду Vacuum.

Например, так (указанный внутри скрипт пишется и запускается в командном файле vacuum.cmd без обновлятора):

cd /d "c:\Program Files\1cv8\srvinfo\reg_1541\0deaa216-26dd-4ae0-9483-51a85b38c093\1Cv8Log" "x:\work\sqlite3.exe" "1Cv8.lgd" vacuum

Перед его выполнением нужно остановить службу сервера 1с.

А что если нам требуется определить какой папке соответствует какая база? Для этого открываем файл 1CV8Clst.lst в корне reg_1541 и из него находим, что, например, папке 0deaa216-26dd-4ae0-9483-51a85b38c093 соответствует база test:

То есть мы можем выполнить vacuum как для всех баз на сервере, так и для избранных.

На этом всё

С уважением, Владимир Милькин (преподаватель школы 1С программистов и разработчик обновлятора). Как помочь сайту: расскажите (кнопки поделиться ниже) о нём своим друзьям и коллегам. Сделайте это один раз и вы внесете существенный вклад в развитие сайта. На сайте нет рекламы, но чем больше людей им пользуются, тем больше сил у меня для его поддержки.

Нажмите одну из кнопок, чтобы поделиться:

helpme1c.ru

Чудеса с журналом регистрации в 1С 8.2.13.205

В конце мая пришлось столкнуться со следующей проблемой. После того как все пользователи выйдут из одной из информационных баз 1С (по причине обновления, перезапуска службы, перезагрузки сервера, либо просто все закончили работу и отправились по домам), подключение к этой же базе 1С занимало неоправданно долгое время - 3-5 минут. Потом, спустя эти самые 3-5 минут, наконец появляось окно для ввода логина и пароля, и никаких проблем в дальнейшем пользователи не испытывали. До тех пор пока все снова не выйдут из 1С. После этого ситуация повторялась. При этом, проблема возникала только на одной, основной, информационной базе. Из других баз пользователи могли входить и выходить когда им удобно, "злополучное" окно появлялось моментально. В качестве временной меры было выбрано такое решение - на моем компьютере, включенном постоянно, 1С не закрывалась никогда. Если мне тоже требовалось выйти из 1С, чтобы программисты могли обновиться - у нас была договоренность - до тех пор пока три человека не войдут в эту ИБ, они не закрывают конфигуратор. Естественно, это не избавляло нас от всех проблем. Во-первых, программисты могли забыть об этом и закрыть конфигуратор, во-вторых, сервер 1С "любит" перезагрузки. Увы, но это так, если не перезагружать его длительное время, начинаются непонятные тормоза в произвольные моменты времени у произвольных пользователей (к серверу СУБД это не имеет никакого отношения). Соответственно, время этих процедур увеличивалось на 5 минут, что было совершенно неприемлимо. С одной стороны, если бы это была какая-нибудь редкоиспользуемая ИБ, никто даже не обратил бы на это внимания, но именно для этой базы требовалось обеспечить максимальную скорость работы. Тогда, в мае, я обратил внимание на следующее: на любой копии базы, на любом сервере (как тестовом, так и на рабочем) проблема не появляется. При этом, процесс rmngr.exe (Менеджер кластера сервера 1С) потреблял 25 процентов процессорного времени, т.е. фактически захватывал одно ядро, на все 5 минут, которые длилось ожидание. После того, как он переставал "жрать" процессор, работа возобновлялась в нормальном режиме. Зная, что у 1С возможны проблемы с "локальным кэшем", я предположил, что серверный кэш так же может быть причиной проблемы. Однако, ни удаление всех "временных" папок, создаваемых 1С, ни удаление каталога snccntx, ни запуск сервера 1С под другим пользователем, ни даже полная переустановка платформы не приносили никакого результата. В результате, я удалил информационную базу с сервера 1С и создал ее под другим именем. И, о чудо, проблема решилась. Прошло 4 месяца. Возникла та же самая проблема. Программисты "выгнали" всех из 1С для проведения обновления, а когда работу можно было продолжить - оказалось, что войти в эту самую информационную базу, никто не может. Окно с предложением ввести логин и пароль появилось только через 5 минут... В этот раз, я твердо знал, что "пересоздание" информационной базы на сервере 1С поможет железно, но решил, что это решение не отличается ни простотой, ни красотой и следует найти что-нибудь более удобное. В первую очередь задумался: в чем разница между новой информационной базой и старой, при условии, что сама база данных на сервере СУБД остается нетронутой. И единственное различие, которое я увидел - это журнал регистрации. Да, журнал регистрации, в который могут записываться ошибки, предупреждения и просто все действия пользователей. У нас, это было известно точно, в журнал регистрации писалось все возможное и еще немного сверху. В то время когда мы принимали участие в проекте ЦКТП, программисты добавляли в журнал регистрации записи о времении выполнения самых важных для предприятия процедур. После завершения проекта было решено, продолжать записывать эти данные, поскольку по ним можно увидеть как себя ведет система с течением времени. Заглянув в каталог журнала регистрации (по адресу C:\Program Files\1cv82\srvinfo\reg_1641\id_базы\ - чтобы узнать id_базы посмотрите содержимое файла 1CV8Reg.lst) я увидел два каталога: 1Cv8FTxt и 1Cv8Log. Первый из которых содержал кучу файлов (период разделения ЖР установлен в "день") с совершенно нечитаемым содержимым, а второй содержал вполне привычные файлы журнала регистрации с расширениями .lgf и .lgp. Итак, поскольку, я решил, что проблема найдена, в Конфигураторе был выбран пункт меню Сервис->Настройки журнала регистрации и нажата кнопка "Сократить". Я сохранил сокращаемые записи ЖР в папку и решил, что проблема решена. Увы, это оказалось не так. Суммарный размер файлов журнала регистрации составлял 900 мегабайт до сокращения и 450 мегабайт после его сокращения. Казалось бы, минимум в два раза время ожидания должно сократиться. Но нет, время не уменьшилось, совсем. Готовясь плюнуть на все и "пересоздать" ИБ на сервере 1С, я, для успокоения совести, решил скопировать папки с ЖР на тестовый сервер, в идентичную базу и посмотреть что из этого получится. Как только копирование завершилось, я решил войти в эту ИБ конфигуратором - и, вот здесь произошло второе чудо, не смог. Тестовый сервер жалобно пыхтел одним ядром, а я любовался на белый квадрат в середине экрана. Окна с предложением ввести логин и пароль, не было. Спустя 35 минут окно появилось, конфигуратор открылся, rmngr.exe снова потреблял не больше 1-2 процентов процессорного времени. Таким образом, было очевидно - причина в журнале регистрации. Однако, уменьшение его в размере совершенно не помогало. Тут произошло третье чудо - я вспомнил про чудесную утилиту FileMon от Марка Руссиновича. Оказалось, что такого продукта больше не существует, а его место занял ProcMon, совмещающий в себе функционал как FileMon, так и RegMon. Скачать его можно здесь. Первым делом, нужно настроить фильтр, поскольку на работающей операционке каждую секунду производятся десятки и сотни вызовов к реестру, файловой системе, сети и другим ресурсам. В первую очередь я создал правило, исключающее всю информацию о процессах, имя которых отличается от "rmngr.exe" и еще одно правило, отсекало все записи, в которых путь не содержал в себе "C:\Program Files (x86)\1Cv82\" (это каталог в который устанвливается 32-х разрядная серверная и клиентская части 1С на 64-битной ОС). И вот что я увидел:Процесс rmngr.exe медленно и грустно "пережевывал" файл 1Cv8.lgf в папке журнала регистрации. Самое удивительное для меня заключалось в том, что размер файла был очень и очень небольшим - 11 мегабайт. Когда rmngr.exe закончил с этим файлом, я вошел в режиме Конфигуратора и снова сократил журнал регистрации. Каково же было мое удивление, когда я увидел, что из папки журнала регистрации удалились файлы .lgp до той даты которую я выбрал, а вот файл 1Cv8.lgf остался нетронутым! И, естественно, при следующей попытке запуска конфигуратора, rmngr.exe снова "прочесывал" весь 1Сv8.lgf. Методом научного тыка было выяснено:

• если сокращать журнал регистрации до определенного момента в прошлом, файл 1Cv8.lgf, проверяемый процессом rmngr.exe, не изменяется в размерах;

• если сокращать журнал регистрации на сегодняшний день, 1Cv8.lgf не изменяется;
• если выбрать дату завтрашнего дня - бинго! файл 1Cv8.lgf очищается.

Естественно, при выборе последнего (да и второго варианта) информационная база, фактически остается без журнала регистрации (т.е. встроенными средствами через Сервис->Журнал регистрации) его нельзя будет просмотреть, поэтому требуется, при сокращении, ЖР сохранять его в папку, доступ к которой должен быть у всех пользователей, работающих с журналом регистрации.

aronov-oleg.blogspot.com

---

• 
  Журнал форбс 2016 богатые люди россии
• 
  Журнал двухступенчатого контроля по охране труда
• 
  По кредиту счета 60 журнал ордер
• 
  Когда отменят бумажный журнал в школе
• 
  Электронный журнал тульская область школа 2
• 
  Журнал хочу все знать все выпуски
• 
  Электронный журнал город советск лицей 10
• 
  Справка по проверке журналов по тб
• 
  Фото ирина салтыкова для журнала плейбой
• 
  Образец журнал производственного контроля в доу
• 
  Электронный журнал 1 школы города котельнича