Загрузка журнала регистрации 1С v8 в базу SQLServer

Публикация № 931195

Администрирование - Журнал регистрации

sql server журнал регистрации структура

6
Загрузка журнала регистрации 1С v8 в базу SQLServer, для хранения архивной информации по журналам, быстрого поиска и/или переноса данных из журнала и его усечения.

Журнал регистрации 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

6

Скачать файлы

Наименование Файл Версия Размер
Загрузка журнала регистрации 1С v8 в SQL:
.7z 111,45Kb
26.10.18
7
.7z 111,45Kb 7 Скачать

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. Iveperfect 08.11.18 09:49 Сейчас в теме
Здравствуйте! У вас не возникло проблемы кодировки для столбца Data в таблице EventLog? В базу SQL данные выгружаются в читаемом виде или что-то такое: "Получение регР?
3. user1054014 6 08.11.18 10:23 Сейчас в теме
(1) Приветствую.
Возникло, поэтому не только "as is" загрузка идет, но и добавлена функция по преобразованию кодировки и записи данных в отдельное поле
2. herfis 282 08.11.18 10:14 Сейчас в теме
Есть робкое предложение по доработке - добавить возможность выгружать через стандартный ВыгрузитьЖурналРегистрации() (с настраиваемой порционностью по временным промежуткам). Я бы купил.
4. user1054014 6 08.11.18 10:30 Сейчас в теме
(2) пока не готов ответить будет или нет.
самый большой нюанс, который сейчас пытаюсь побороть это нарезка журнала. Так как загрузка идет через оперативную память, и сейчас столкнулся с журналом регистрации (который три года не резался) в 140GB. Сейчас ищу более изящное решение, кроме долгой и нудной нарезки средствами 1С.
Также замечу, что не зависимо от версии sql server если грузить большой журнал и оперативной памяти не хватит, то будет ошибка, и память останется занятой, либо пока не перезапустите sql, либо пока не "убьете" хендл с подчиненным процессом sql server-а, который держит журнал.
5. herfis 282 08.11.18 10:39 Сейчас в теме
Просто я пришел к старому формату лога (текстовому) как наиболее удобному и функциональному. В том числе там штатно настраивается порционность хранения лога, что позволяет очень просто чистить его при необходимости и настраивать авторотацию (плюс нет проблем, которые могут возникать с sqlite). Проблема объемов и скорости анализа штатными средствами частично решена выборочной записью событий. Поэтому до агрегации логов руки никак и не доходят. Хотя видимо рукава закатать все же придется.
7. user1054014 6 08.11.18 11:19 Сейчас в теме
Тут все просто
любая система требует обслуживания и мониторинга
разрастание журнала регистрации, который еще и на системном диске лежит, это не доработка тех кто обслуживает систему и их руководителей.
но это лирика...
6. kuzev 40 08.11.18 11:13 Сейчас в теме
Если у Вас клиент-серверная архитектура, то как Вы работаете "на лету" с файлом журнала? Разве он не "схвачен" сервером 1С?
8. user1054014 6 08.11.18 11:21 Сейчас в теме
(6)
1. остановили сервер 1С
2. скопировали лог
3. произвели усечение или удаление лога, освободив память
4. запустили сервер 1С

далее работаем с копией лога как захотим
9. kuzev 40 08.11.18 11:23 Сейчас в теме
10. chessman 179 22.01.19 15:00 Сейчас в теме
Вопросы такие - какими порциями и как часто подкачивается у вас журнал? При подкачке Вы ориентируетесь на rowID? В реальном режиме времени чтение из журнала не сильно влияет на работу 1С-ой базы? И какой при этом размер файла журнала?
Спасибо.

Тут же: (вдруг кому пригодится) после создания linked server, sql ругался на невозможность установки соединения. Помогла установка глобального параметра сервера 'lightweight pooling' в 0.

На одной из картинок к публикации, создается view. А не проще сбоку прикрутить табличку соответствия событий анг <-> рус., вместо бесконечных case'ов?
11. user1054014 6 23.01.19 07:56 Сейчас в теме
(10) Была задача загрузки исторических журналов от нескольких систем 1С в одну базу и дальнейшая, регулярная загрузка журналов в общую базу.

"какими порциями и как часто подкачивается у вас журнал?"
Текущая частота 1 раз в месяц

"При подкачке Вы ориентируетесь на rowID?"
в журнале есть дата, при загрузке идет сравнение по идентификатору базы которой принадлежит журнал, rowid и дате записи строки.
чтобы не грузить дубликаты

"В реальном режиме времени чтение из журнала не сильно влияет на работу 1С-ой базы?"
в реальном режиме чтение (загрузка журнала в базу) не производим, загружаем во время проведения регламентных работ.
после чего производим усечение журнала до необходимой даты

"И какой при этом размер файла журнала? "
сейчас до 2ГБ, исторические файлы весили до 300ГБ (на текущий момент имеем в загрузке 2мрд. записей из журналов)

"А не проще сбоку прикрутить табличку соответствия событий анг <-> рус., вместо бесконечных case'ов?"
Проще
12. chessman 179 23.01.19 08:42 Сейчас в теме
(11) А в реальном режиме времени не пробовали грузить? Скажем, раз в минуту...Тогда, можно было бы прикрутить к SQL'ой базе систему мониторинга и анализа ошибок. Я смотрю, народ активно использует разные интересные сторонние сервисы. Да даже без сторонних можно что-то придумать. Не смотрели в эту сторону? Спасибо.
Оставьте свое сообщение