Чем открыть журнал регистрации 1с lgd
В 1С 8 журнал регистрации хранится в текстовых файлах, которые находятся в подкаталоге 1Cv8Log. Для клиент-серверной ищем где-то в "C:\Program Files\1cv82\srvinfo\reg_1541\\1Cv8Log\".
Обычно журнал регистрации 1С 8 состоит из одного файла описаний (ELF в 8.1 / LGF в 8.2) и одного или нескольких файлов данных (LOG в 8.1 / LGP в 8.2). Существуют еще так называемые архивы журнала регистрации – в этом случае описания и данные находятся в одном файле последовательно, сначала описания, затем данные, при этом расширение как у файла данных.
В первой строке файла журнала регистрации пишется маркер
"1CV8LOG_" для 8.1 и "1CV8LOG(ver 2.0)" для 8.2.
Во второй строке пишется GUID.
Для файла данных журнала регистрации пишется еще дополнительно третья пустая строка.
Дальше идут непосредственно данные, которые заключены в фигурные скобки "<>" и отделяются друг от друга запятой.
При парсинге журнала регистрации сталкиваемся с проблемой отделения друг от друга записей – ведь они имеют переменную длину и могут быть разбиты на разное число строк, которое получается из-за следующих правил, добавляющих дополнительные символы новой строки (Символы.ПС):
2) Закрывающие фигурные скобки ">" не могут идти подряд – они всегда разделены символом новой строки;
3) Символ новой строки может встретиться внутри кавычек.
Таким образом отделить запись можно по следующим критериям
1) Первый символ – открывающая фигурная скобка "
3) Последний символ – закрывающая фигурная скобка ">";
4) Так же у правильной записи всегда будет четное число кавычек.
Структура записей файла описаний 8.1 сильно отличаются от 8.2.
При анализе файла описаний 8.1 по приведенным выше правилам получим всего одну запись, которая будет состоять из элемента "Legend" и вложенных записей. Структура вложенных записей одинакова – это заголовок и вложенная запись. Заголовок может принимать следующие значения "Users" – GUIDы пользователей, "UserNames" – имена пользователей, "Hosts" – компьютеры, "Apps" – приложения, "Events" – события, "MDID" - GUIDы метаданных, "MDCodes" – имена метаданных, "SrvHosts" – серверы, "MainPorts" – основные порты, "SyncPorts" – вспомогательные порты. Вложенные записи состоят по сути из массивов. Первый элемент – размер массива, дальше идут непосредственно значения. Разделитель – запятая.
При анализе файла описаний 8.2 увидим другую картину. Файл содержит много записей размером от обычно трех элементов до четырех, в случае если надо указать GUID – для пользователей и метаданных.
Формат записи прост – первый элемент код массива, второй – значение, третий – номер в массиве. В случае четырех записей, между первым и вторым элементом появляется GUID.
Коды массивов были обнаружены следующие:
7 – основные порты;
8 – вспомогательные порты.
Так же встречаются пока неопознанные коды 11, 12 и 13
Таким образом, из файлов описаний получаем необходимые справочники, которые будут использованы в файлах данных.
Структура записей файлов данных 8.1 отличается от 8.2 по сути только количеством элементов. В 8.1 запись состоит жестко из 16 элементов, а в 8.2 число элементов переменно и может быть от 19 штук и до в принципе любого количества.
Далее приведу значения элементов в записи:
1) Дата и время в формате "yyyyMMddHHmmss", легко превращается в дату функцией Дата();
2) Статус транзакции – может принимать четыре значения "N" – "Отсутствует", "U" – "Зафиксирована", "R" – "Не завершена" и "C" – "Отменена";
3) Транзакция в формате записи из двух элементов преобразованных в шестнадцатеричное число – первый – число секунд с 01.01.0001 00:00:00 умноженное на 10000, второй – номер транзакции;
4) Пользователь – указывается номер в массиве пользователей;
5) Компьютер – указывается номер в массиве компьютеров;
6) Приложение – указывается номер в массиве приложений;
7) Соединение – номер соединения;
8) Событие – указывается номер в массиве событий;
9) Важность – может принимать четыре значения – "I" – "Информация", "E" – "Ошибки",
"W" – "Предупреждения" и "N" – "Примечания";
10) Комментарий – любой текст в кавычках;
11) Метаданные – указывается номер в массиве метаданных;
12) Данные – самый хитрый элемент, содержащий вложенную запись;
13) Представление данных – текст в кавычках;
14) Сервер – указывается номер в массиве серверов;
15) Основной порт – указывается номер в массиве основных портов;
16) Вспомогательный порт – указывается номер в массиве вспомогательных портов;
17) Сеанс – номер сеанса;
Теперь рассмотрим вложенную запись элемента 12 (Данные), который может принимать следующие значения:
1) – Неопределено – можно преобразовать через ЗначениеИзСтрокиВнутр();
2) – Строка – можно преобразовать через ЗначениеИзСтрокиВнутр();
3) – Ссылка c GUID, где метаданные с id. Для получения id метаданных пока нашел только немного извращенный способ – ЗначениеИзСтрокиВнутр(ТипМетаданных.ИмяМетаданных.ПустаяСсылка()) и парсить полученную строку.
4) ,>>– что-то вроде массива но пока не понятно что значит 6 – на ее месте пока встречал только 1, 2 и 6. Возможно это разные типы - массив, структура и т. п.
Позже появилась довольно интересная публикация - Периодическая загрузка событий из журналов регистрации в базу MS SQL Server, где автор парсит файлы журнала регистрации напрямую, причем он пишет, что разбирал формат журнала регистрации сам, задолго до текущей публикации, но к сожалению пока дополнительно найденной информацией по формату с сообществом не поделился.
Добрый день!
Выгрузили журнал регистрации, большой, больше 200Гб. Погуглил программки для просмотра таких файлов, не нашел бесплатных вариантов. Кто чем просматривает, поделитесь?
Благодарю.
LGD - это журнал нового формата.
Да. И вот чем его открыть и посмотреть, если файл 200+Гб и желательно бесплатный вариант программы?
Спасибо за ответы!
PS. У вас база колол не вставала при таком размере?
Как это понять? Если только вместо колокол-колом? Бывает. Ищем причины. Она вставать не перестала и после выгрузки ЖР.
(8) База не вставала, а вот любая попытка просмотра ЖР вызывала всеобщее зависание. Выгрузка журнала регистрации не уменьшает размер файла. Нужно еще уменьшить файл.
Нужно определить кто вносил данные по счетам определенным. Скачал по указанным ссылкам проги, установил. Файл ЖР .lgd открывается, но как база данных. Удобоваримого интерфейса для поиска не нашел. Неужто придется sql запросы писать? Или может инструкция где есть как пользоваться?
(12) А разве можно узнать, что изменили в счете? Я всегда думал, что можно увидеть, что "записали", "изменили", "провели" и подобное, но деталей не замечал в журнале регистрации.
Сейчас (в ЗУП точно) придумали версионирование - там можно.
(18) этому сейчас уж лет 10 в обед. Еще на УПП 1.3 было (или мы стырили откуда-то тогда, уж не помню точно)))
(19) (20) Я с УТ не работаю, только с ЗУП. Там я такого не замечал. Только версионирование, но это не журнал регистрации
(24) У меня все нагруженные базы - нетиповые. Там альтернативное логирование. Стандартный "срач" отключен.
Лучше бы потратили время на конвертацию журнала в последовательный формат с разбивкой по периодам, чтобы каждый файл был не больше 100Мб.
А потом смотрели бы его себе спокойно из конфигуратора.
Старый формат - новый формат.
Если вдруг кто не в курсе, 1С давно признала формат журнала регистрации в виде базы данных SQLite ошибкой. И с версии 8.3.13 форматом журнала регистрации по умолчанию является последовательный формат (в виде текстовых файлов).
А в версии 8.3.17 реализовано индексирование файлов журнала регистрации. Индексация выполняется в фоновом режиме. Оптимизированы алгоритмы последовательного чтения файлов журнала регистрации.
За счет индексации существенно ускорен отбор записей журнала регистрации по индексируемым полям (список индексируемых полей в документации).
При открытии в конфигураторе файла журнала регистрации другой информационной базы, индексирование данного файла выполняется в фоновом режиме и индексный файл стирается после завершения работы с просматриваемого журнала регистрации.
Для новой информационной базы значение параметра Разделять хранение журнала по периодам устанавливается в значение Неделя. Для существующих информационных баз рекомендуется установить разделение таким образом, чтобы размер одного файла журнала не превышал 100 Мбайт.
(0) А стандартный "ВыгрузитьЖурналРегистрации" не взлетит с lgd? Там и отборы по ссылкам, периодам, событиям. Можно указать путь к журналу.
(27) "1С давно признала формат журнала регистрации в виде базы данных SQLite ошибкой" // Это лишь домыслы. Какого-то более-менее официального разъяснения ни в инфописьмах, ни на партнерке вроде как по этому поводу нет (и, вероятно, не будет).
(26) Не. Используется стандартный ЖР. Просто системная регистрация переключена в "регистрировать ошибки, предупреждения" и все что надо дополнительно - через подписки и т.п. Фактически приведен к семерочной стратегии ЖР.
(30) Не домыслы. Обратная смена дефолта - это де-факто признание того, что в среднем новый формат оказался вовсе не таким классным, как они себе сначала думали.
Ну и я ретроград. Первичный журнал должен быть локальным текстовым сегментированным по периодам с возможностью настроить ротацию. Точка.
Дальше - агрегируй уже куда угодно, во что угодно и как угодно. А святое - не трожь :)
После жалоб пользователей на замедление 1С:Предприятие администраторы высказали подозрение, что причиной тормозов является Журнал регистрации. Журналы – это несколько файлов формата lgd от одного до двух гигабайт. Чтобы развеять все сомнения, и вооружившись трехзвенкой 8.3.12.1469 x86, а также инструментами от производителя, решено было изучить вопрос вдоль и поперек или другими словами, узнать, «что там под капотом».
Чтобы 1С:Предприятие хранила журнал в данном формате, необходимо его указать явно в конфигураторе или файле настроек. Либо просто удалить все файлы из каталога журнала, если там файлы предыдущего формата. Разделение данных, как было в предыдущей версии, не поддерживается. Корневой каталог журналов указывается в параметрах запуска службы после ключа -d. Например, -d “d:\temp\srvinfo”
Итак, журнал представляет из себя не что иное, как базу данных sqlite, хотя 1С использует свое именование расширения и даже свой драйвер для доступа, который входит в поставку платформы. Разработчики 1С не стали использовать предлагаемый авторами sqlite драйвер, а просто скомпилировали свой, видимо для совместимости и/или простоты использования, благо исходники доступны на сайте sqlite. Но используется он своеобразно. К примеру, если пометить на удаление записи в журнале любым доступным вам способом, то это ничего не даст потому, что 1С просто игнорирует эту метку. То есть при просмотре отразятся все без исключения записи.
Разработчики sqlite утверждают, что размер файла базы данных может превышать сотню гигабайт и даже сотню терабайт. Так что, если бы 1С:Предприятие тормозила из-за журнала, то скорее всего это могло случиться только из-за кривого драйвера от 1С или неумения его правильно готовить использовать. Хотя конечно могут влиять и внешние факторы, как например, дефрагментация диска и тому подобное. К примеру, одно из последних нововведений разработчиков sqlite – метод VACUUM. И хотя он также упоминается в драйвере 1С, на деле этот метод никак не используется или я не смог спровоцировать его выполнение. Если вы решите сократить полностью журнал из Конфигуратора, то вместо того, чтобы заново создать файл или основную таблицу журнала, 1С:Предприятие начнет удалять все записи в таблице EventLog. И если у вас он большого размера, то придется запастись терпением. За то при этом все пользователи могут продолжать свою работу в обычном режиме, вот только вряд ли при этом что-то отразится в журнале об их работе. Многопоточность? Нет, не слышал.
В документации сказано, что при загрузке информационной базы все записи журнала не очищаются. Для чего так сделано? Ведь если конфигурация иная, то в базе останутся никому не нужные записи об объектах предыдущей конфигурации, которых просто может не быть в новой. Видимо пользователю предлагается самому найти этот файл и удалить.
Службы 1С:Предприятие автоматически создает файл 1Cv8.lgd при первом же обращении будь то конфигуратор или web-приложение. Что интересно база не формируется сразу же целиком, а только по необходимости. К примеру, если установить уровень «Регистрировать ошибки», запустить регламентное задание, то создадутся только две таблицы, пусть и пустые. То есть о выполнении регламентных заданий вы не узнаете, пока не начнется нормальное ведение журнала, а для этого нужно хотя бы раз открыть 1С:Предприятие (в любом режиме). Кстати регламентные задания в журнале отражаются как фоновые. Почему так? Зачем понадобилось два термина?
И только при запуске 1С:Предприятие в режиме конфигуратора или обычного приложения создадутся все оставшиеся необходимые таблицы. Записи создаются по такому же алгоритму. К примеру, есть таблица MetadataCodes, в которой хранятся объекты конфигурации. Но все объекты разом не записываются, хотя это можно было бы сделать, к примеру, при обновлении конфигурации, а записываются только по требованию.
Структура базы нормализована по полной программе. Размер записи основной таблицы равен примерно 140 байт, что совсем немного для такого рода сценария использования как ведение логов.
Но есть вопросы. К примеру, для чего нужно было создавать отдельные таблицы используемых портов? Сколько килобайт планировали сэкономить авторы? Видимо это все ради того, чтобы потом быстро показать/использовать в форме отбора. Другого объяснения не нашел. Но опять же для чего надо было создавать поле Name, когда его значение можно было хранить в поле Code. Если у кого есть идеи, поделитесь.
Следующий момент больше похож на ошибку разработчиков. Столкнулся с ней, когда попытался соединить эти таблицы. Дело в том, что ключ metadataCodes в основной таблице EventLog имеет тип TEXT, хотя должен был быть INTEGER. Выкрутился преобразованием «на лету»: SELECT 0+ metadataCodes FROM . Драйвер ODBC позволил такое проделать. Хотя можно просто изменить структуру таблицы, работоспособность журнала от этого никак не пострадает.
И эта песня тянется уже не один год.
При любом несложном нарушении структуры базы она будет восстановлена. К примеру, мной были удалены некоторые индексы, и при следующем моем обращении к журналу из главного меню конфигуратора Администрирование – Журнал регистрации все индексы были благополучно восстановлены после небольшой паузы.
Итак, вернемся к файлу журнала, с которого все и началось. Размер его чуть превышал 1 гигабайт, что по меркам авторов sqlite это копейки. Нельзя не отметить всеобщий сарказм администраторов в отношении к 1С, многие относят ее к разряду «для киосков с оборотом 3 рубля». Это, конечно же, отдельная история. Хотя предыдущая статья лишь подтверждает этот момент, особенно аргументы в обсуждении.
Принимая во внимание все вышеперечисленные проблемы, сомнения все же оставались. Мною было решено просто проверить, как влияет рост размера журнала на производительность. Была создана обработка, которая в цикле выполняла одну лишь команду:
20 циклов/замеров по миллиону записей. Размер файла вырос с пары-тройки десятков килобайт до почти трех гигабайт. Обратите внимание, что скорость никоим образом не изменилась, более того даже не деградировала от того, что файл сильно распух. Все же авторы sqlite правы, говоря, что это копейки.
Так же для контроля скорости записи на диск использовалась программа Process Monitor (Procmon) из набора утилит Sysinternals Марка Руссиновича и Брюса Когсвела, которая лишь подтвердила полученные данные.
Размер файла журнала регистраций никак не влияет на скорость записи. Конечно, надо учитывать еще много других факторов. Но текущая задача была лишь проверить как сама 1С:Предприятие работает с файлами sqlite большого размера.
Но тут, надо понимать "зачем" открываете и что дальше будете с этим делать?
Частельно это, очень объемный файл, в выше перечисленных программах проблемно обрабатывать данный файл.
есть различные документы откуда нужно удалить автора документа и мне посоветовали открыть этот файлик т.к. в нем изменяется.
Это журнал регистрации, что в базе делают пользователи. И никаких данных там нет.
Константин, спрошу тогда по другому.
где хранится инфа и как удалить автора?
у документа есть реквизит, вот в него и пишется инфа по Автору. Как и Организация, Контрагент, Валюта и прочие реквизиты.
а удалить очистить значение данного реквизита, любой обработкой групповое изменение реквизитов. Часто такие обработки встроены в конфгурацию.
Константин, можно по подробнее где хранится такая встроенная обработка? просто у нас белорусская 1с и на нее мало инструкций в инете
ну как у вас называется не ХЗ.
а так ищите "Групповая обработка справочников и документов", какой-нибуть раздел Сервис
varfi,
Всё подробно.
varfi, Открыть и удалить автора называется преступлением.
Хоть и до жути просто)))
Извините, такую информацию я не компетентен раздавать)
Однозначным ответом может быть только: не трогать этот файл и просматривать журнал регистрации непосредственно из той базы 1С, к которой он относится.
Судя по содержимому комментариев на самом деле требуется обработка с ИТС для групповой замены реквизитов или "Инструменты Разработчика" с целью удалить информацию из ряда документов в базе.
Журнал регистрации в 1С 8.3 очень полезен тем, что в нем отображаются события, произошедшие в информационной базе с указанием времени, имени компьютера и пользователя и ссылки на изменяемые данные. При аутентификации пользователей в журнале так же создаются записи с указанием способа входа в программу. Данный механизм позволяет ответить на один из частых вопросов – кто последний вносил изменения в конкретный объект.
Где найти журнал регистрации в 1С 8.3? Через меню «Все функции» — «Стандартные» или, в типовых конфигурациях 1C, в меню «Администрирование» — «Поддержка и обслуживание».
Настройка
Настройка журнала регистрации производится в режиме конфигуратора. В меню «Администрирование» выберите пункт «Настройка журнала регистрации».
Здесь настраиваются те события, которые будут отображаться в журнале регистрации.
Выбор первого пункта настройки позволяет не вести журнал регистрации вообще. Остальные настройки расположены по возрастанию их значимости. При большом количестве пользователей не рекомендуется регистрировать примечания, дабы не засорять базу.
При создании новой информационной базы по умолчанию устанавливается режим регистрации всех событий.
Просмотр и поиск записей
Когда вы откроете сам журнал регистрации, на первый взгляд может показаться, что та очень много информации и найти ее просто нереально. На самом деле это не так.
Получите понятные самоучители по 1С бесплатно:
По умолчанию в журнал регистрации выводится по 200 записей. Отображение большого количества записей может негативно сказаться на работоспособности вашей программы или попросту она зависнет.
В форме списка журнала регистрации можно установить отбор и воспользоваться поиском. Поиск накладывается только на записи, которые уже отображаются (в данном случае последние 200 событий). Отбор же применяется ко всем записям.
Поиск осуществляется по выведенным данным в табличной части, поэтому при его использовании необходимо только указать колонку и данные, которые нужно найти.
Отбор позволяет отобрать данные по конкретным пользователям, именам компьютеров, событиям и т. п. Так же у вас есть возможность вывести записи журнала регистрации только по конкретным метаданным, данным (указывается ссылка на нужный объект, например, конкретный документ) и прочие настройки.
В данном примере приведены настройки журнала регистрации для отбора всех событий пользователя «Admin», начиная с 20.06.2017.
Где хранится файл журнала 1cv8.lgd
Место физического хранения журнала регистрации напрямую зависит от того, файловая база или клиент — серверная.
Файловая база
При данном режиме размещения, журнал регистрации находится в папке с самой базой. Место ее расположение можно узнать либо из списка баз, либо из справки «О программе».
Если перейти по данному адресу, вы найдете папку с именем «1Cv8Log». Именно тут расположены данные журнала регистрации в файле 1Cv8.lgd.
При необходимости переноса базы из одного места в другое можно скопировать так же и этот каталог, тогда данные журнала регистрации перенесутся вместе с базой.
При удалении данного каталога, журнал регистрации очистится.
Клиент-серверная база
В таком режиме все так же, как и в предыдущем, только данные журнала регистрации 1С хранятся на сервере. Чаще всего его место расположения следующее:
Оптимизация
Журнал регистрации при необходимости можно оптимизировать, особенно когда в базе происходит большое количество событий.
Одним из способов является рассмотренная выше настройка регистрации только определенных событий. Например, незачем отслеживать примечания, если они вам попросту не нужны.
В более старых релизах платформы в настройках журнала регистрации было доступно разделение журнала регистрации по периодам. Весь журнал можно было разделить на отдельные файлы с указанной периодичностью (день, месяц, год и т. п.).
Начиная с версии платформы 1С 8.3.5.1068, журнал регистрации хранится в файле базы данных sqlite с расширением *.lgd, и данная настройка стала недоступна. Данный способ хранения журнала регистрации значительно производительнее, чем старый.
Как уменьшить или удалить журнал регистрации в 1С
В случае необходимости частичной, либо полной очистки записей журнала регистрации в окне настроек нажмите на кнопку «Сократить». В появившемся окне укажите дату, до которой все записи должны удалиться. Так же удаляемые записи можно сохранить в файл на всякий случай.
Читайте также: