0. rtnm 561 17.09.14 17:03 Сейчас в теме

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

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

Перейти к публикации

Комментарии
Сортировка: Древо
1. petrov_al 10 18.09.14 09:43 Сейчас в теме
Очень интересный подход через внешниии источники данных. По сути можно иметь it-базу и там анализировать журналы разных баз.
bidond; Makushimo; demkonst; rtnm; +4 Ответить
15. adapter 482 25.09.14 09:38 Сейчас в теме
(1) petrov_al, тоже самое можно было делать и на 8.2. Без sqlLite, но суть та же. Вот смотри
http://infostart.ru/public/283362/

18. AllexSoft 06.10.14 14:07 Сейчас в теме
(15) adapter, разница только в 10тыс рублей ;) сейчас тоже самое но из коробки бесплатно
2. AlX0id 19.09.14 15:31 Сейчас в теме
Но есть один нюанс. Единожды переключив журнал в новый формат - обратно не вернешься. А текущие версии КИПа не поддерживают новый журнал регистрации в принципе %)
3. metmetmet 58 21.09.14 13:00 Сейчас в теме
А что можно сказать по производительность в сравнении со старым механизмом?
4. awk 687 21.09.14 13:36 Сейчас в теме
(3) metmetmet, Ускорилось...
artichoke; +1 Ответить
6. kiruha 366 22.09.14 10:02 Сейчас в теме
(4) awk,
То что это ускоряет чтение не надо быть 7 пядей во лбу
Интересно как запись , есть ли блокировки из за этого - т.к. стандартно 1С пишет каждый чих пользователя,
SQLLite при записи блокируют всю таблицу
7. BabySG 22.09.14 10:04 Сейчас в теме
(6) kiruha, очевидно, что пользователь БД в этом случае один и блокировки не страшны в принципе :)
24. awk 687 06.10.14 18:12 Сейчас в теме
(7) BabySG, В SQLite нет блокировок таблиц. Есть блокировка баз. Только один пользователь может писать. Остальные только читают.
9. AlX0id 22.09.14 15:47 Сейчас в теме
(6) kiruha, Сомнительно, что там вообще накладываются блокировки - ибо нафига? Кого может волновать грязное чтение журнала регистрации?
10. JohnyDeath 291 22.09.14 17:26 Сейчас в теме
(9) AlX0id, так устроен SQLite из коробки. Когда пишем - блокируем всё.
11. AlX0id 23.09.14 11:46 Сейчас в теме
(10) JohnyDeath,
Почитал - да, так и есть.. В лучшем случае можно включить WAL как я понимаю.
25. AlexO 126 14.01.15 23:18 Сейчас в теме
(10) JohnyDeath,
так устроен SQLite из коробки
Причем тут устройство или неустройство SQLlite? Так устроен любой SQL - если запись в таблицу, то блокируется вся таблица. А журнал - это практически одна основная таблица.
5. cool.vlad4 43 21.09.14 18:38 Сейчас в теме
о мой бог, неужели все таки додумались сделали на sqlite. это ж какой ад и кошмар был
1cmax; bulpi; Yashazz; +3 Ответить
8. kiruha 366 22.09.14 10:52 Сейчас в теме
На каждого пользователя своя база SQLLIte ?
12. maxx 652 24.09.14 10:19 Сейчас в теме
Классно. Интересно, если базы с более старой платформы 1С переводить на 8.3, то к уже имеющийся журнал регистрации как перегнать в SQLLite?
16. AlX0id 29.09.14 14:09 Сейчас в теме
(12) maxx,
Автоматом вроде конвертится..
17. ediks 325 06.10.14 13:44 Сейчас в теме
(16) Что-то мне кажется, что автоматом не конвертится.
Прикрепленные файлы:
19. AlX0id 06.10.14 15:37 Сейчас в теме
(17) ediks,
Ну вот ток что на тестовой базе перевел на новый формат, старые файлы журнала поудалял - вся старая информация осталась.
20. ediks 325 06.10.14 16:20 Сейчас в теме
(19) Не, я предполагал, что не нужно нажимать никакие кнопки. Типа само, без участия оператора все происходит.
А так я тоже конвертнул - появился новый файл 1Cv8.lgd. Скачал конфигу и посмотрел, что получается.
Вот только вопрос - сколько будет конвертироваться журнал размером 120 Гб (все, что нажито нелегким трудом за много лет)?
И какой будет размер базы данных журнала? У меня после конвертации тестового журнала размером 10 Мб получилась база размером 17 Мб.
22. AlX0id 06.10.14 17:06 Сейчас в теме
(20) ediks,
Режьте его серпом по корень ) Все равно в старом журнале разобраться в 120 гигах практически нереально )
23. ediks 325 06.10.14 18:10 Сейчас в теме
(22) Пока только вопрос стоит об архивировании этого гигантского журнала. Вопрос о конвертации такого журнала был поставлен с чисто теоретической, познавательной целью.
У нас и мальчика-то 1С 8.3.5 нет :)
13. zombi81 7 24.09.14 13:06 Сейчас в теме
А скриншот есть что на выходе получаем? Так как таблица есть EventLog там все поля по -английски называются и информация в таблице невнятная.
14. rtnm 561 25.09.14 08:57 Сейчас в теме
(13) zombi81, Да, имена таблиц и полей используют английские названия. В своем примере, я как раз частично их перевел для внешнего источника, используя в основном устоявшиеся термины. Можете изучить ЖР.cf и я думаю станет понятнее.
21. AllexSoft 06.10.14 16:34 Сейчас в теме
зачем держать такие журналы? они все равно не используемы.. забэкапил то что нажито и ничего переносить не надо. ИМХО
26. JohnyDeath 291 24.01.15 22:36 Сейчас в теме
(26) Вы это серьезно? Или просто пытаетесь так толсто протроллить?
27. AlexO 126 25.01.15 18:25 Сейчас в теме
(26) JohnyDeath, по теме есть что? Или только троллить зашел?
28. pepe 61 12.11.15 16:12 Сейчас в теме
Для файловой базы все работает, а вот для серверной версии не работает. Хочу вытянуть список документов которые изменял пользователь. Даже через режим "Конфигуратор" не могу подключится для получение структуры. В файловой все ок.
29. pepe 61 12.11.15 16:48 Сейчас в теме
С вопросом разобрался. Нужно ставить SQLite на сервер 1С и у сервера должен быть доступ к файлу.
30. orefkov 1957 18.11.15 10:04 Сейчас в теме
К вопросу о блокировках в sqlite.
Для начала отмечу, что блокировки в sqlite накладываются на всю базу.
Когда и как они накладываются, зависит от способа обращения к файлу базы данных sqlite.
Независимо от способа - писать в базу sqlite в один момент времени может только один писатель.
А вот насчет читателей - есть нюансы.
В случае, если к файлу идут обращения только с одного компьютера, есть возможность включить режим WAL.
В этом режиме писатель блокирует только других писателей, но не блокирует читателей, также как и наличие читателей не блокируют писателя.
Просто каждый читатель видит то состояние базы данных, какое оно было на момент начала чтения, и не видит изменений, вносимых в этот момент писателем.
Отмечу, что в этом режиме изменения записываются в отдельный файл, и периодически наступает "чекпоинт", когда данные из дополнительного файла переносятся в основной.
В этот момент блокируются все - и читатели, и писатель.
Если режим WAL для данной базы данных не включен, наличие читателей не дает писать, а наличие писателя - не дает читать.
То есть при начале записи сначала блокируется подключение читателей, потом дожидается окончание чтение существующих читателей, потом делается запись, и только потом из базы снова можно читать.
Режим WAL нельзя использовать, если обращение к файлу базы данных выполняется одновременно с разных компьютеров.
При многопоточном обращении к файлу БД из одного процесса есть возможность установить несколько соединений с одним файлом БД.
В этом случае для читающего соединения можно установить режим "read uncommited", когда одно соединение сразу видит изменения, вносимые другим соединением еще до завершения транзакции. Если и читать и писать через одно соединение, то там всегда сразу видно вносимые изменения.
Вот так вот коротенько о блокировках в sqlite.

А вот сама идея вести лог сразу в базу данных sqlite - мне кажется, 1С облажалась, как всегда, пытаясь выдумать свой велосипед.
Во всём мире журналы логов пишутся максимально быстро в обычные текстовые файлы, которые уже потом периодически засасываются в различные конвертеры и анализаторы.
Задача стоит только в том, чтобы реализовать возможность инкрементальной перекачки из текстовых файлов в анализатор. Самое простое - каждые сутки/час/неделю заводить новый файл.
Нет необходимости "на лету" писать в формате, пригодном для анализа. Тем более, что sqlite - не самый быстрый способ писать в файлы.
Например, apache, ngnix спокойно и не парясь ведет лог в текстовые файлы. Хотя, о чём это я - nginix быстрый, ему так надо. А для 1С наверняка запись в журнал регистрации не является "бутылочным горлышком" платформы, и ускорять запись в этом месте нет особого смысла, потому что это копейки по сравнению с другими тормозными местами.
sergathome; LsrGroup; VladC#; endym; marochkin; JohnyDeath; +6 Ответить
32. awk 687 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

Это как писать надо было, что бы дозапись в файл тормазила.... :))))
sergathome; +1 Ответить
31. swwb 15 22.01.16 11:54 Сейчас в теме
Кто может подсказать?. Есть большой журнал регистраций ~ 30 Gb, пользователей много+ работает автоматическая выгрузка из другой системы. В общем, в лог постоянно что-то пишется.
Посмотреть историю изменений по документу просто нереально, журнал повисает и вешает за собой базу. Есть какие то пути решения? Хочется смотреть журнал на горячую при работающей базе.
33. adapter 482 28.01.16 09:24 Сейчас в теме
(31) swwb, решение уже сказали выше:
orefkov
быстро писать в текст и медленно инкрементировать в удобную для анализа систему
.
logManager так и работает (http://infostart.ru/public/283362/)
34. progr-2008 118 04.01.17 08:56 Сейчас в теме
При сокращении журнала не всегда срабатывает корректно запись в файл.
35. sergathome 29.08.18 16:41 Сейчас в теме
При попытке читать лог ОДНОЙ БАЗЫ блокируется запись в него, что приводит к остановке работы rmngr, что в свою очередь, приводит к остановке обслуживания ВСЕХ БАЗ СЕРВЕРА.
Дадад, это не баг, это фича...

ЗЫ Неудача нового формата для крупных масштабов признана 1С фактом с версии 8.3.12 возможности интерактивно выбирать формат журнала регистрации (т.е. опытные люди выбирают старый формат). (http://www.gilev.ru/oldjr/)
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии



Ведущий программист 1С
Москва
зарплата от 150 000 руб. до 180 000 руб.
Полный день

Руководитель проектов 1С
Москва
Полный день

Консультант-аналитик 1С: ЗУП
Санкт-Петербург
Полный день