Журнал регистрации 1С храниться в виде файла базы SQLite и имеет следующую структуру
структура журнала разная, в зависимости от версии 1С мы рассматриваем структуру 1Сv8
AppCodes
ComputerCodes
ComputerToUserCodes
EventCodes
EventLog
EventLogMetadata
MetadataCodes
PrimaryPortCodes
SecondaryPortCodes
SessionDataCodes
SessionDataSplits
SessionHosts
SessionParamCodes
SessionUsers
UserCodes
WorkServerCodes
на изображении схема данных, в структуре созданной в базе SQL Server с префиксом «t_»
Для работы с файлом журнала в SQL как с линкованным сервером, его необходимо подключить
Но для начала
обязательно необходимо установить ODBC драйвера для работы с SQLite
скачать драйвер (помним про разрядность системы)
После установки драйвера, нам необходимо создать линкованный сервер, т.е. подключиться к файлу журнала
у нас есть 2 способа:
1. создать системный DSN и подключиться со ссылкой на DSN
2. создать подключение в SQL с указанием ссылки на файл и провайдера данных
Далее
После подключения журнала регистрации 1С к SQL серверу можно приступать к работе
при чтении журнала в SQL, необходимо помнить что все обращения идут через оперативную память сервера, поэтому читать данные необходимо порциями и/или предварительно «резать» журнал
При попытке загрузить "толстый журнал", после загрузки 3-5 гигабайт в оперативную память (если столько есть) SQL Server выдаст ошибку, поэтому рекомендую размер файла до 1 гигабайта
обращаться к таблицам журнала можно через OPENQUERY или на прямую, но для обращений на прямую, необходимо скорректировать настройки провайдера данных руками, или скриптом
Все, мы можем работать с журналом в SSMS и ни в чем себе не отказывать.
При необходимости настраиваем партиционирование и работаем с журналом по выбранным периодам.
Причины купить
Возможность загружать множество журналов регистрации 1Сv8 в базу данных SQL Server
для хранения и анализа
Достоинства
Готовое решение для загрузки журнала в базу SQL Server
просто и понятно в виде скриптов и описаний
при необходимости возможно изменение для себя, полностью открытый код на tsql
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Здравствуйте! У вас не возникло проблемы кодировки для столбца Data в таблице EventLog? В базу SQL данные выгружаются в читаемом виде или что-то такое: «РџРѕР»СѓС‡РµРЅРёРµ регР?
Есть робкое предложение по доработке — добавить возможность выгружать через стандартный ВыгрузитьЖурналРегистрации() (с настраиваемой порционностью по временным промежуткам). Я бы купил.
(1) Приветствую.
Возникло, поэтому не только «as is» загрузка идет, но и добавлена функция по преобразованию кодировки и записи данных в отдельное поле
(2) пока не готов ответить будет или нет.
самый большой нюанс, который сейчас пытаюсь побороть это нарезка журнала. Так как загрузка идет через оперативную память, и сейчас столкнулся с журналом регистрации (который три года не резался) в 140GB. Сейчас ищу более изящное решение, кроме долгой и нудной нарезки средствами 1С.
Также замечу, что не зависимо от версии sql server если грузить большой журнал и оперативной памяти не хватит, то будет ошибка, и память останется занятой, либо пока не перезапустите sql, либо пока не «убьете» хендл с подчиненным процессом sql server-а, который держит журнал.
Просто я пришел к старому формату лога (текстовому) как наиболее удобному и функциональному. В том числе там штатно настраивается порционность хранения лога, что позволяет очень просто чистить его при необходимости и настраивать авторотацию (плюс нет проблем, которые могут возникать с sqlite). Проблема объемов и скорости анализа штатными средствами частично решена выборочной записью событий. Поэтому до агрегации логов руки никак и не доходят. Хотя видимо рукава закатать все же придется.
Если у Вас клиент-серверная архитектура, то как Вы работаете «на лету» с файлом журнала? Разве он не «схвачен» сервером 1С?
Тут все просто
любая система требует обслуживания и мониторинга
разрастание журнала регистрации, который еще и на системном диске лежит, это не доработка тех кто обслуживает систему и их руководителей.
но это лирика…
(6)
1. остановили сервер 1С
2. скопировали лог
3. произвели усечение или удаление лога, освободив память
4. запустили сервер 1С
далее работаем с копией лога как захотим
(8) ясно.
Вопросы такие — какими порциями и как часто подкачивается у вас журнал? При подкачке Вы ориентируетесь на rowID? В реальном режиме времени чтение из журнала не сильно влияет на работу 1С-ой базы? И какой при этом размер файла журнала?
Спасибо.
Тут же: (вдруг кому пригодится) после создания linked server, sql ругался на невозможность установки соединения. Помогла установка глобального параметра сервера ‘lightweight pooling’ в 0.
На одной из картинок к публикации, создается view. А не проще сбоку прикрутить табличку соответствия событий анг <-> рус., вместо бесконечных case’ов?
(10) Была задача загрузки исторических журналов от нескольких систем 1С в одну базу и дальнейшая, регулярная загрузка журналов в общую базу.
«какими порциями и как часто подкачивается у вас журнал?»
Текущая частота 1 раз в месяц
«При подкачке Вы ориентируетесь на rowID?»
в журнале есть дата, при загрузке идет сравнение по идентификатору базы которой принадлежит журнал, rowid и дате записи строки.
чтобы не грузить дубликаты
«В реальном режиме времени чтение из журнала не сильно влияет на работу 1С-ой базы?»
в реальном режиме чтение (загрузка журнала в базу) не производим, загружаем во время проведения регламентных работ.
после чего производим усечение журнала до необходимой даты
«И какой при этом размер файла журнала? »
сейчас до 2ГБ, исторические файлы весили до 300ГБ (на текущий момент имеем в загрузке 2мрд. записей из журналов)
«А не проще сбоку прикрутить табличку соответствия событий анг <-> рус., вместо бесконечных case’ов?»
Проще
(11) А в реальном режиме времени не пробовали грузить? Скажем, раз в минуту…Тогда, можно было бы прикрутить к SQL’ой базе систему мониторинга и анализа ошибок. Я смотрю, народ активно использует разные интересные сторонние сервисы. Да даже без сторонних можно что-то придумать. Не смотрели в эту сторону? Спасибо.