gifts2017

Получение запросом данных журнала регистрации хранящегося в SQLite

Опубликовал rtnm rtnm (rtnm) в раздел Администрирование - Журнал регистрации

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

Начиная с версии платформы 8.3.5.1068 журнал регистрации хранится в файловой базе данных SQLite.

Вспоминаем про функциональность внешних источников данных.

Соединяем два механизма и получаем такой вот результат:

ПараметрыСоединения = Новый ПараметрыСоединенияВнешнегоИсточникаДанных;
ПараметрыСоединения.СтрокаСоединения = "DRIVER=SQLite3 ODBC Driver;Database=" + ФайлЖурналаРегистрации + ";BigInt=1;";
ВнешниеИсточникиДанных.ЖурналРегистрации.УстановитьОбщиеПараметрыСоединения(ПараметрыСоединения);
ВнешниеИсточникиДанных.ЖурналРегистрации.УстановитьСоединение();

Запрос = Новый Запрос();
Запрос.Текст = "ВЫБРАТЬ
               |	ЗаписиЖурнала.Код,
               |	ЗаписиЖурнала.Важность,
               |	ЗаписиЖурнала.Дата,
               |	ЗаписиЖурнала.СтатусТранзакции,
               |	ЗаписиЖурнала.ДатаТранзакции,
               |	ЗаписиЖурнала.ИдентификаторТранзакции,
               |	ЗаписиЖурнала.Пользователь,
               |	ЗаписиЖурнала.Пользователь.Код,
               |	ЗаписиЖурнала.Пользователь.Наименование,
               |	ЗаписиЖурнала.Компьютер.Код,
               |	ЗаписиЖурнала.Компьютер.Наименование,
               |	ЗаписиЖурнала.Приложение.Код,
               |	ЗаписиЖурнала.Приложение.Наименование,
               |	ЗаписиЖурнала.Событие.Код,
               |	ЗаписиЖурнала.Событие.Наименование,
               |	ЗаписиЖурнала.Комментарий,
               |	ЗаписиЖурнала.Данные,
               |	ЗаписиЖурнала.ПредставлениеДанных,
               |	ЗаписиЖурнала.РабочийСервер,
               |	ЗаписиЖурнала.РабочийСервер.Код,
               |	ЗаписиЖурнала.РабочийСервер.Наименование,
               |	ЗаписиЖурнала.ОсновнойПорт,
               |	ЗаписиЖурнала.ВспомогательныйПорт
               |ИЗ
               |	ВнешнийИсточникДанных.ЖурналРегистрации.Таблица.ЗаписиЖурнала КАК ЗаписиЖурнала";
				   
ТаблицаДанных = Запрос.Выполнить().Выгрузить();
ВнешниеИсточникиДанных.ЖурналРегистрации.РазорватьСоединение();

Не забываем скачать и установить ODBC-драйвер для SQLite нужной разрядности.

Обращаю внимание на параметр в строке подключения "BigInt=1", только так, поле хранящее дату будет возвращать корректный результат. Кстати, дата хранится как целое число. Например, если дата равна 635453673444260, то чтобы перевести в привычный тип Дата, нужно сделать так:

ОбычнаяДата = '00010101000000' + 635453673444260/10000; //03.09.2014 18:55:44

Если остались вопросы, просто посмотрите ЖР.cf и встроенную обработку "Пример".

Спасибо за внимание.

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

Наименование Файл Версия Размер Кол. Скачив.
ЖР.cf
.cf 20,90Kb
17.09.14
117
.cf 20,90Kb 117 Скачать

См. также

Подписаться Добавить вознаграждение

Комментарии

1. al petrov (petrov_al) 18.09.14 09:43
Очень интересный подход через внешниии источники данных. По сути можно иметь it-базу и там анализировать журналы разных баз.
bidond; Makushimo; demkonst; rtnm; +4 Ответить 1
2. Алексей 1 (AlX0id) 19.09.14 15:31
Но есть один нюанс. Единожды переключив журнал в новый формат - обратно не вернешься. А текущие версии КИПа не поддерживают новый журнал регистрации в принципе %)
3. metal doctor (metmetmet) 21.09.14 13:00
А что можно сказать по производительность в сравнении со старым механизмом?
4. Василий Казьмин (awk) 21.09.14 13:36
(3) metmetmet, Ускорилось...
5. Ийон Тихий (cool.vlad4) 21.09.14 18:38
о мой бог, неужели все таки додумались сделали на sqlite. это ж какой ад и кошмар был
1cmax; bulpi; Yashazz; +3 Ответить
6. kiruha Дронов (kiruha) 22.09.14 10:02
(4) awk,
То что это ускоряет чтение не надо быть 7 пядей во лбу
Интересно как запись , есть ли блокировки из за этого - т.к. стандартно 1С пишет каждый чих пользователя,
SQLLite при записи блокируют всю таблицу
7. BabySG (BabySG) 22.09.14 10:04
(6) kiruha, очевидно, что пользователь БД в этом случае один и блокировки не страшны в принципе :)
8. kiruha Дронов (kiruha) 22.09.14 10:52
На каждого пользователя своя база SQLLIte ?
9. Алексей 1 (AlX0id) 22.09.14 15:47
(6) kiruha, Сомнительно, что там вообще накладываются блокировки - ибо нафига? Кого может волновать грязное чтение журнала регистрации?
10. Евгений Мартыненков (JohnyDeath) 22.09.14 17:26
(9) AlX0id, так устроен SQLite из коробки. Когда пишем - блокируем всё.
11. Алексей 1 (AlX0id) 23.09.14 11:46
(10) JohnyDeath,
Почитал - да, так и есть.. В лучшем случае можно включить WAL как я понимаю.
12. Maxim Goncharov (maxx) 24.09.14 10:19
Классно. Интересно, если базы с более старой платформы 1С переводить на 8.3, то к уже имеющийся журнал регистрации как перегнать в SQLLite?
13. Alex Bol (zombi81) 24.09.14 13:06
А скриншот есть что на выходе получаем? Так как таблица есть EventLog там все поля по -английски называются и информация в таблице невнятная.
14. rtnm rtnm (rtnm) 25.09.14 08:57
(13) zombi81, Да, имена таблиц и полей используют английские названия. В своем примере, я как раз частично их перевел для внешнего источника, используя в основном устоявшиеся термины. Можете изучить ЖР.cf и я думаю станет понятнее.
15. Adapter Бахтыреев (adapter) 25.09.14 09:38
(1) petrov_al, тоже самое можно было делать и на 8.2. Без sqlLite, но суть та же. Вот смотри
http://infostart.ru/public/283362/

16. Алексей 1 (AlX0id) 29.09.14 14:09
(12) maxx,
Автоматом вроде конвертится..
17. ediks (ediks) 06.10.14 13:44
(16) Что-то мне кажется, что автоматом не конвертится.
Прикрепленные файлы:
18. Алексей Белоусов (AllexSoft) 06.10.14 14:07
(15) adapter, разница только в 10тыс рублей ;) сейчас тоже самое но из коробки бесплатно
19. Алексей 1 (AlX0id) 06.10.14 15:37
(17) ediks,
Ну вот ток что на тестовой базе перевел на новый формат, старые файлы журнала поудалял - вся старая информация осталась.
20. ediks (ediks) 06.10.14 16:20
(19) Не, я предполагал, что не нужно нажимать никакие кнопки. Типа само, без участия оператора все происходит.
А так я тоже конвертнул - появился новый файл 1Cv8.lgd. Скачал конфигу и посмотрел, что получается.
Вот только вопрос - сколько будет конвертироваться журнал размером 120 Гб (все, что нажито нелегким трудом за много лет)?
И какой будет размер базы данных журнала? У меня после конвертации тестового журнала размером 10 Мб получилась база размером 17 Мб.
21. Алексей Белоусов (AllexSoft) 06.10.14 16:34
зачем держать такие журналы? они все равно не используемы.. забэкапил то что нажито и ничего переносить не надо. ИМХО
22. Алексей 1 (AlX0id) 06.10.14 17:06
(20) ediks,
Режьте его серпом по корень ) Все равно в старом журнале разобраться в 120 гигах практически нереально )
23. ediks (ediks) 06.10.14 18:10
(22) Пока только вопрос стоит об архивировании этого гигантского журнала. Вопрос о конвертации такого журнала был поставлен с чисто теоретической, познавательной целью.
У нас и мальчика-то 1С 8.3.5 нет :)
24. Василий Казьмин (awk) 06.10.14 18:12
(7) BabySG, В SQLite нет блокировок таблиц. Есть блокировка баз. Только один пользователь может писать. Остальные только читают.
25. Алекс Ю (AlexO) 14.01.15 23:18
(10) JohnyDeath,
так устроен SQLite из коробки
Причем тут устройство или неустройство SQLlite? Так устроен любой SQL - если запись в таблицу, то блокируется вся таблица. А журнал - это практически одна основная таблица.
26. Евгений Мартыненков (JohnyDeath) 24.01.15 22:36
(26) Вы это серьезно? Или просто пытаетесь так толсто протроллить?
27. Алекс Ю (AlexO) 25.01.15 18:25
(26) JohnyDeath, по теме есть что? Или только троллить зашел?
28. pepe (pepe) 12.11.15 16:12
Для файловой базы все работает, а вот для серверной версии не работает. Хочу вытянуть список документов которые изменял пользователь. Даже через режим "Конфигуратор" не могу подключится для получение структуры. В файловой все ок.
29. pepe (pepe) 12.11.15 16:48
С вопросом разобрался. Нужно ставить SQLite на сервер 1С и у сервера должен быть доступ к файлу.
30. Александр Орефков (orefkov) 18.11.15 10:04
К вопросу о блокировках в sqlite.
Для начала отмечу, что блокировки в sqlite накладываются на всю базу.
Когда и как они накладываются, зависит от способа обращения к файлу базы данных sqlite.
Независимо от способа - писать в базу sqlite в один момент времени может только один писатель.
А вот насчет читателей - есть нюансы.
В случае, если к файлу идут обращения только с одного компьютера, есть возможность включить режим WAL.
В этом режиме писатель блокирует только других писателей, но не блокирует читателей, также как и наличие читателей не блокируют писателя.
Просто каждый читатель видит то состояние базы данных, какое оно было на момент начала чтения, и не видит изменений, вносимых в этот момент писателем.
Отмечу, что в этом режиме изменения записываются в отдельный файл, и периодически наступает "чекпоинт", когда данные из дополнительного файла переносятся в основной.
В этот момент блокируются все - и читатели, и писатель.
Если режим WAL для данной базы данных не включен, наличие читателей не дает писать, а наличие писателя - не дает читать.
То есть при начале записи сначала блокируется подключение читателей, потом дожидается окончание чтение существующих читателей, потом делается запись, и только потом из базы снова можно читать.
Режим WAL нельзя использовать, если обращение к файлу базы данных выполняется одновременно с разных компьютеров.
При многопоточном обращении к файлу БД из одного процесса есть возможность установить несколько соединений с одним файлом БД.
В этом случае для читающего соединения можно установить режим "read uncommited", когда одно соединение сразу видит изменения, вносимые другим соединением еще до завершения транзакции. Если и читать и писать через одно соединение, то там всегда сразу видно вносимые изменения.
Вот так вот коротенько о блокировках в sqlite.

А вот сама идея вести лог сразу в базу данных sqlite - мне кажется, 1С облажалась, как всегда, пытаясь выдумать свой велосипед.
Во всём мире журналы логов пишутся максимально быстро в обычные текстовые файлы, которые уже потом периодически засасываются в различные конвертеры и анализаторы.
Задача стоит только в том, чтобы реализовать возможность инкрементальной перекачки из текстовых файлов в анализатор. Самое простое - каждые сутки/час/неделю заводить новый файл.
Нет необходимости "на лету" писать в формате, пригодном для анализа. Тем более, что sqlite - не самый быстрый способ писать в файлы.
Например, apache, ngnix спокойно и не парясь ведет лог в текстовые файлы. Хотя, о чём это я - nginix быстрый, ему так надо. А для 1С наверняка запись в журнал регистрации не является "бутылочным горлышком" платформы, и ускорять запись в этом месте нет особого смысла, потому что это копейки по сравнению с другими тормозными местами.
LsrGroup; VladC#; endym; marochkin; JohnyDeath; +5 Ответить 1
31. Сергей Хомутов (swwb) 22.01.16 11:54
Кто может подсказать?. Есть большой журнал регистраций ~ 30 Gb, пользователей много+ работает автоматическая выгрузка из другой системы. В общем, в лог постоянно что-то пишется.
Посмотреть историю изменений по документу просто нереально, журнал повисает и вешает за собой базу. Есть какие то пути решения? Хочется смотреть журнал на горячую при работающей базе.
32. Василий Казьмин (awk) 25.01.16 14:24
(30) orefkov,
29.10.2013 Как мы улучшили журнал регистрации

Реализовано в версии 8.3.5.1068.

Мы значительно переработали журнал регистрации для того, чтобы увеличить скорость выполнения запросов к журналу и повысить надёжность хранения данных.

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

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

Создавая новую реализацию журнала, мы стремились учесть пожелания по архивированию журнала и сокращению его размера. Теперь во встроенном языке есть два метода, которые позволяют копировать данные журнала регистрации или удалять их, используя условия фильтрации. Это методы СкопироватьЖурналРегистрации() и ОчиститьЖурналРегистрации(). С их помощью архивирование или очистку журнала можно выполнять автоматически, регламентными заданиями, в период наименьшей загрузки системы.

Также мы ввели в журнале ещё одно изменение. Время событий хранится теперь в формате всемирного координированного времени (UTC). Это позволят избежать проблем, связанных с работой в разных часовых поясах.
http://v8.1c.ru/o7/201310log/index.htm

Это как писать надо было, что бы дозапись в файл тормазила.... :))))
33. Adapter Бахтыреев (adapter) 28.01.16 09:24
(31) swwb, решение уже сказали выше:
orefkov
быстро писать в текст и медленно инкрементировать в удобную для анализа систему
.
logManager так и работает (http://infostart.ru/public/283362/)
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа