В статье показано как, используя новый функционал платформы, получать данные из журнала регистрации привычным запросом.
Начиная с версии платформы 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 и встроенную обработку «Пример».
Спасибо за внимание.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Очень интересный подход через внешниии источники данных. По сути можно иметь it-базу и там анализировать журналы разных баз.
Но есть один нюанс. Единожды переключив журнал в новый формат — обратно не вернешься. А текущие версии КИПа не поддерживают новый журнал регистрации в принципе %)
А что можно сказать по производительность в сравнении со старым механизмом?
(3) metmetmet, Ускорилось…
о мой бог, неужели все таки
додумалисьсделали на sqlite. это ж какой ад и кошмар был(4) awk,
То что это ускоряет чтение не надо быть 7 пядей во лбу
Интересно как запись , есть ли блокировки из за этого — т.к. стандартно 1С пишет каждый чих пользователя,
SQLLite при записи блокируют всю таблицу
(6) kiruha, очевидно, что пользователь БД в этом случае один и блокировки не страшны в принципе 🙂
На каждого пользователя своя база SQLLIte ?
(6) kiruha, Сомнительно, что там вообще накладываются блокировки — ибо нафига? Кого может волновать грязное чтение журнала регистрации?
(10) JohnyDeath,
Почитал — да, так и есть.. В лучшем случае можно включить WAL как я понимаю.
Классно. Интересно, если базы с более старой платформы 1С переводить на 8.3, то к уже имеющийся журнал регистрации как перегнать в SQLLite?
А скриншот есть что на выходе получаем? Так как таблица есть EventLog там все поля по -английски называются и информация в таблице невнятная.
(13) zombi81, Да, имена таблиц и полей используют английские названия. В своем примере, я как раз частично их перевел для внешнего источника, используя в основном устоявшиеся термины. Можете изучить ЖР.cf и я думаю станет понятнее.
(1) petrov_al, тоже самое можно было делать и на 8.2. Без sqlLite, но суть та же. Вот смотри
(12) maxx,
Автоматом вроде конвертится..
(16) Что-то мне кажется, что автоматом не конвертится.
(15) adapter, разница только в 10тыс рублей 😉 сейчас тоже самое но из коробки бесплатно
(17) ediks,
Ну вот ток что на тестовой базе перевел на новый формат, старые файлы журнала поудалял — вся старая информация осталась.
(19) Не, я предполагал, что не нужно нажимать никакие кнопки. Типа само, без участия оператора все происходит.
А так я тоже конвертнул — появился новый файл 1Cv8.lgd. Скачал конфигу и посмотрел, что получается.
Вот только вопрос — сколько будет конвертироваться журнал размером 120 Гб (все, что нажито нелегким трудом за много лет)?
И какой будет размер базы данных журнала? У меня после конвертации тестового журнала размером 10 Мб получилась база размером 17 Мб.
зачем держать такие журналы? они все равно не используемы.. забэкапил то что нажито и ничего переносить не надо. ИМХО
(20) ediks,
Режьте его серпом по корень ) Все равно в старом журнале разобраться в 120 гигах практически нереально )
(22) Пока только вопрос стоит об архивировании этого гигантского журнала. Вопрос о конвертации такого журнала был поставлен с чисто теоретической, познавательной целью.
У нас
и мальчика-то1С 8.3.5 нет 🙂(7) BabySG, В SQLite нет блокировок таблиц. Есть блокировка баз. Только один пользователь может писать. Остальные только читают.
(26) JohnyDeath, по теме есть что? Или только троллить зашел?
Для файловой базы все работает, а вот для серверной версии не работает. Хочу вытянуть список документов которые изменял пользователь. Даже через режим «Конфигуратор» не могу подключится для получение структуры. В файловой все ок.
С вопросом разобрался. Нужно ставить SQLite на сервер 1С и у сервера должен быть доступ к файлу.
К вопросу о блокировках в sqlite.
Для начала отмечу, что блокировки в sqlite накладываются на всю базу.
Когда и как они накладываются, зависит от способа обращения к файлу базы данных sqlite.
Независимо от способа — писать в базу sqlite в один момент времени может только один писатель.
А вот насчет читателей — есть нюансы.
В случае, если к файлу идут обращения только с одного компьютера, есть возможность включить режим WAL.
В этом режиме писатель блокирует только других писателей, но не блокирует читателей, также как и наличие читателей не блокируют писателя.
Просто каждый читатель видит то состояние базы данных, какое оно было на момент начала чтения, и не видит изменений, вносимых в этот момент писателем.
Отмечу, что в этом режиме изменения записываются в отдельный файл, и периодически наступает «чекпоинт», когда данные из дополнительного файла переносятся в основной.
В этот момент блокируются все — и читатели, и писатель.
Если режим WAL для данной базы данных не включен, наличие читателей не дает писать, а наличие писателя — не дает читать.
То есть при начале записи сначала блокируется подключение читателей, потом дожидается окончание чтение существующих читателей, потом делается запись, и только потом из базы снова можно читать.
Режим WAL нельзя использовать, если обращение к файлу базы данных выполняется одновременно с разных компьютеров.
При многопоточном обращении к файлу БД из одного процесса есть возможность установить несколько соединений с одним файлом БД.
В этом случае для читающего соединения можно установить режим «read uncommited», когда одно соединение сразу видит изменения, вносимые другим соединением еще до завершения транзакции. Если и читать и писать через одно соединение, то там всегда сразу видно вносимые изменения.
Вот так вот коротенько о блокировках в sqlite.
А вот сама идея вести лог сразу в базу данных sqlite — мне кажется, 1С облажалась, как всегда, пытаясь выдумать свой велосипед.
Во всём мире журналы логов пишутся максимально быстро в обычные текстовые файлы, которые уже потом периодически засасываются в различные конвертеры и анализаторы.
Задача стоит только в том, чтобы реализовать возможность инкрементальной перекачки из текстовых файлов в анализатор. Самое простое — каждые сутки/час/неделю заводить новый файл.
Нет необходимости «на лету» писать в формате, пригодном для анализа. Тем более, что sqlite — не самый быстрый способ писать в файлы.
Например, apache, ngnix спокойно и не парясь ведет лог в текстовые файлы. Хотя, о чём это я — nginix быстрый, ему так надо. А для 1С наверняка запись в журнал регистрации не является «бутылочным горлышком» платформы, и ускорять запись в этом месте нет особого смысла, потому что это копейки по сравнению с другими тормозными местами.
Кто может подсказать?. Есть большой журнал регистраций ~ 30 Gb, пользователей много+ работает автоматическая выгрузка из другой системы. В общем, в лог постоянно что-то пишется.
Посмотреть историю изменений по документу просто нереально, журнал повисает и вешает за собой базу. Есть какие то пути решения? Хочется смотреть журнал на горячую при работающей базе.
(30) orefkov,
Реализовано в версии 8.3.5.1068.
Мы значительно переработали журнал регистрации для того, чтобы увеличить скорость выполнения запросов к журналу и повысить надёжность хранения данных.
Для этого, в том числе, потребовалось изменить формат хранения журнала регистрации. Теперь он хранится в одном файле базы данных SQLite. Этот файл имеет расширение lgd.
Наши тесты показывают, что практически по всем условиям отбора выборка данных ускорилась. При некоторых условиях выборка ускорилась существенно. Например, в случае отбора по пользователю, разделителям и по данным, представленным одним значением. Что касается записи, то скорость однопоточной записи тоже немного ускорилась. А вот скорость многопоточной записи возросла почти в полтора раза. Как в файловом варианте, так и в клиент-серверном.
Создавая новую реализацию журнала, мы стремились учесть пожелания по архивированию журнала и сокращению его размера. Теперь во встроенном языке есть два метода, которые позволяют копировать данные журнала регистрации или удалять их, используя условия фильтрации. Это методы СкопироватьЖурналРегистрации() и ОчиститьЖурналРегистрации(). С их помощью архивирование или очистку журнала можно выполнять автоматически, регламентными заданиями, в период наименьшей загрузки системы.
Также мы ввели в журнале ещё одно изменение. Время событий хранится теперь в формате всемирного координированного времени (UTC). Это позволят избежать проблем, связанных с работой в разных часовых поясах.
Показать
Это как писать надо было, что бы дозапись в файл тормазила…. :))))
(31) swwb, решение уже сказали выше:
orefkov
.
logManager так и работает (
При сокращении журнала не всегда срабатывает корректно запись в файл.
При попытке читать лог ОДНОЙ БАЗЫ блокируется запись в него, что приводит к остановке работы rmngr, что в свою очередь, приводит к остановке обслуживания ВСЕХ БАЗ СЕРВЕРА.
Дадад, это не баг, это фича…
ЗЫ Неудача нового формата для крупных масштабов признана 1С фактом с версии 8.3.12 возможности интерактивно выбирать формат журнала регистрации (т.е. опытные люди выбирают старый формат). (