gifts2017

Быстрый журнал регистрации

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

Еще один механизм анализа изменений в базе. Радикальное отличие от аналогов - является копией штатного журнала регистрации, но хранится в регистре сведений, что позволяет получать необходимую информацию (в т.ч. действия в конфигураторе) моментально.

Также есть возможность встраивания в объекты конфигурации дополнительной кнопки, по нажатию на которую показывается история изменения объекта (в данной поставке механизм встраивания кнопки отсутствует):

// Открывает форму с информацией о истории изменения объекта
//
Процедура ПоказатьИнформациюОИсторииИзмененийОбъекта(Кнопка, Форма, Объект)
 ФормаРегистра = РегистрыСведений.жр_ЖурналРегистрации.ПолучитьФормуСписка( , Форма, Форма);
 ФормаРегистра.ПараметрОтборПоИзмерению = Новый Структура("DataRef", Объект.Ссылка);
 ФормаРегистра.Открыть();
КонецПроцедуры

Для включения механизма необходимо либо нажать кнопку "Загрузить данные журнала" (нужна соответствующая роль пользователя) либо принудительное включение регламентного задания.

Приложенная обработка нужна для первоначальной загрузки данных за произвольный период. Автоматическая загрузка выполняется либо с начала журнала (если ранее не проводилась), либо с момента последней загрузки.

Будет работать только на клиент-серверном варианте базы

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

Наименование Файл Версия Размер
- 665
.1240297469 90,96Kb
19.02.13
665
.1240297469 90,96Kb Скачать
- 558
.1240297553 10,28Kb
19.02.13
558
.1240297553 10,28Kb Скачать

См. также

Подписаться Добавить вознаграждение
Комментарии
1. Gamm (Gamm) 21.04.09 13:52
2. cs25 (cs25) 21.04.09 17:06
3. Misha ⁠ (Magister) 22.04.09 10:37
Интересно! Достали уже тормоза стандартного журнала...
4. spidem (spidem) 22.04.09 10:39
5. Валерий Просвирнин (Expert1C) 22.04.09 10:58
Скорость - это не единственное что можно извлечь.
По данному регистру можно делать запросы, что позволяет:

- отслеживать ошибки - если пользователи молчат как рыбы
- составлять статистику интенсивности работы пользователей
- можно реализовать отчет по времени проведения документов (т.к. в данных фиксируется время начала и окончания транзакции)
- ...
Evg-Lylyk; German; +2 Ответить
6. Князев Евгений Юрьевич (noblekey) 22.04.09 12:13
7. Валерий Просвирнин (Expert1C) 22.04.09 12:21
(6) отличия следующие:
0) представленная разработка является копией штатного журнала регистрации, но только хранится в базе и соответственно позволяет быстро считывать данные
1) не снижает производительность при записи объектов
2) корректно показывает в т.ч. отмененные транзакции
3) позволяет отследить длительность этих самых транзакций
4) не показывает изменение реквизитов
8. Валентин Терёхин (Valet) 22.04.09 12:28
(6) По всей видимости тем, что здесь используется стандартный журнал регистрации, просто загруженный в регистр сведений (т.е. в нем кроме изменений в данных еще куча информации: ошибки, сеансы и.т.д).
А то что по ссылке работает на подписках на события и ловит только изменения данных:
"Дополнительный журнал регистрации предназначен для быстрого получения данных о фактах изменения объектов базы данных."
9. Доржи Хренов (Кадош) 22.04.09 13:06
посмотри в последней УПП версионность
10. inse0f (inse0f) 22.04.09 14:48
но ведь на справочнике быстрее будет работать чем в регистре...
не пойму зачем разрешать системному механизму каждый раз при записи делать проверку уникальности регистра сведений.. её ж никак неотключить
а на справочнике - пожалуйста..
11. Валерий Просвирнин (Expert1C) 22.04.09 14:52
(10) сам придумал или кто подсказал? проверка выполняется при вставке индекса на стороне SQL сервера
12. inse0f (inse0f) 22.04.09 14:58
по тестам (гдето на мисте была статья даже)
запись около 10000 эл в справочник vs Рег Сведений
Справочник соотв. без автонумерации и контроля
пишет в 2 раза быстрее в среднем :)
вот так то
13. inse0f (inse0f) 22.04.09 15:03
думаю самый быстрый вариант будет через ole доступ к sql-серверу
+ создание дополнительной базы и сохранение только guidов или ключей ссылки (что даже предпочтительнее, ищется быстрее чем по МД)
14. Валерий Просвирнин (Expert1C) 22.04.09 16:39
(12) Результаты теста:
Запись справочника 1 : 0сек.
Запись регистра 1 : 0сек.
Запись справочника 10 : 0сек.
Запись регистра 10 : 0сек.
Запись справочника 100 : 0сек.
Запись регистра 100 : 0сек.
Запись справочника 1 000 : 4сек.
Запись регистра 1 000 : 0сек.
Запись справочника 10 000 : 37сек.
Запись регистра 10 000 : 2сек.

вот так то
15. inse0f (inse0f) 22.04.09 16:56
хы) ну значит ацкие прогеры с мисты опять накосячили
а я им верил...
16. artmicro (artmicro) 22.04.09 19:21
А как это скажется на размере базы с большим количеством пользователей, за продолжительное время? Примерные цифры есть?
17. Валерий Просвирнин (Expert1C) 22.04.09 19:31
есть, но это уже за отдельную плату.

механизм используется на большом количестве баз с числом активных пользователей до 100, так же работает на центральной базе для РИБ из ~15узлов.
правда для больших баз пришлось изменить структуру индексов в SQL
18. Герман (German) 22.04.09 21:28
Сам недавно об этом думал .. и именно такую реализацию прикидывал...

Ну наверно об возможности безболезненного удаления объектов из ИБ можно забыть :)
19. Сергей Старых (tormozit) 23.04.09 08:27
(18) Если у в конфе есть журналы, то конечно их нужно игнорить при проверке ссылок на объект перед удалением.
20. Валерий Просвирнин (Expert1C) 23.04.09 09:28
(19) представленный механизм учитывает необходимость удаления объектов, при этом записи в журнале и ссылки на объекты в этих записях остаются.
21. Игорь Исхаков (Ish_2) 23.04.09 10:46
(14) Цитата :
"Запись справочника 10 000 : 37сек.
Запись регистра 10 000 : 2сек."

Правильно ли я понял описание теста ?
Рассматривается клиент-серверный вариант 1сПредприятия 8.

Цикл с количеством итераций 10 000 , добавляющий записи в справочник, имеет продолжительность - 37 сек

Для регистра сведений с аналогичной структурой процедура формирования набора записей 10 000 шт. для регистра с аналогичной структурой
и единственная запись набора занимает - 2 сек.
22. Валерий Просвирнин (Expert1C) 23.04.09 10:58
(21)да
в представленном механизме, записи делаются не по одной, а пачкой
23. Игорь Исхаков (Ish_2) 23.04.09 11:04
(22) Такая реализация предполагает при эффективности записи возможность потери изменений . Так ?
24. Валерий Просвирнин (Expert1C) 23.04.09 11:32
(23) нет. потери данных журнала не происходит ни при каких обстоятельствах
25. Игорь Исхаков (Ish_2) 23.04.09 11:48
(24) ...Предполагаю , что необходимо смотреть текст , чтобы убедиться в этом.

Здесь неоднократно поднимался вопрос "регистр или справочник ?"

И хотя , несомненно что :
1. Одна запись в справочник добавляется значительно быстрее чем в регистр.
2. При записи в справочник отсутствуют "тормозящие" блокировки , в отличие
от записи в регистр.
Тем не менее , Вы выбрали в качестве объекта хранения данных Регистр сведений с записью "пачками" и с "тормозящими" блокировками.
Возможно , в данной конкретной задаче у Вас были какие-то основания для этого ?
Чем так привлекателен оказался для Вас - регистр сведений ?
26. Игорь Исхаков (Ish_2) 23.04.09 12:09
Извиняюсь , нужно уходить . До вечера.
27. Валерий Просвирнин (Expert1C) 23.04.09 12:18
(25) регистр - быстрее значительно если пачкой. тест я уже привел
28. Игорь Исхаков (Ish_2) 23.04.09 18:38
(27)
Вопросов нет. Есть замечание .
Вставка описания теста в сообщение (14) -
1. сделала бы ненужной фразу "вот так-то "
2. и пост не сбил бы с толку (15)
29. inse0f (inse0f) 24.04.09 00:29
странно в том что в версии ЖР от Бизнес-Плюс сделано таки на справочнике...
мне кажется тут надо провести диагностику скорости записей на разных базах, от 1 пользователя до 100 и более.
и скорее всего до какого то момента выгоднее использовать справочник

хотя отдельное спасибо за фри версию) жаль не могу плюс поставить
рейта не хватает :(
30. Олег (Sol) 24.04.09 07:43
Прикольная штука, только одно небольшое замечание.

Если уж делаешь сделал для своего ЖР Роли, то негоже использовать в коде конструкции:

Код
ПриложениеСсылка = Справочники.жр_Приложения.НайтиПоКоду(Код);
Показать полностью


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

Всё-таки в этом случае нужно использовать Запрос, с ключевым словом РАЗРЕШЕННЫЕ
31. Валерий Просвирнин (Expert1C) 24.04.09 09:54
(28) Методика теста повторяет используемую в решении логику.
(29) Представленное решение ВООБЩЕ не снижает производительность системы. В регистр пишутся данные в режиме оффлайн, в отличие от механизмов Бизнес-Плюса.
(30) А не надо лазить куда не надо.
32. Евгений (wirg) 11.06.09 12:01
Супер. Очень даже ничего, вот еще бы штатно во всех конфах подобное было.
33. Stas N (StasN) 18.06.09 14:29
В нашей конфе присутствует подобное решение около года, т.е. все изменения документов и справочников регистрируются в регистре свидений. В результате накопилось более 2 млн. записей - при этом при открытии списка записей происходит висяк, даже если нужно посмотреть историю изменения с отбором по документу - открывается достаточно долго...
34. Валерий Просвирнин (Expert1C) 18.06.09 14:39
(33) всего 2 миллиона? это мало
35. Stas N (StasN) 18.06.09 14:49
я считаю такой способ хранения лога источником лишних блокировок и раздувания размера базы. Как результат - снижение производительности в целом.
36. Stas N (StasN) 18.06.09 14:50
(34) подрезали переодически. а так в день до более 20 тыс. записий было
37. Валерий Просвирнин (Expert1C) 18.06.09 14:56
1) блокировки - в предложенном решении их нет по определению. В других решениях - в зависимости от реализации
2) размер базы - ну да, данные хранятся в базе и увеличивают ее размер. с этим ничего поделать нельзя. Можно конечно хранить данные не в объектах 1С, а непосредственно в базе и обращаться прямыми запросами - но тогда интерфейсная часть будет более сложной и может притормаживать.
3) общее снижение производительности из-за роста базы - бред. наличие в базе большой таблицы, не влечет за собой снижения производительности. Также правильно организованная структура данных (и алгоритмов работы с этими данными) позволяет добиться стабильно высокой производительности вне зависимости от размеров таблицы.
38. Валерий Просвирнин (Expert1C) 18.06.09 14:57
39. Stas N (StasN) 18.06.09 15:08
почему же нет блокировок - запись в данный регистр это уже блокировка, насколько я знаю и увеличение времени проведения документа.
40. Валерий Просвирнин (Expert1C) 18.06.09 15:13
(41) В моем решении дополнительных блокировок нет в принципе. Увеличения времени записи / проведения документов нет в принципе.
41. Stas N (StasN) 18.06.09 15:16
и к тому же, если обычный просмотр записей с отбором по измерениям этого регистра грузит проц и забивает память - это уже мешает остальным пользователям работать.
42. Валерий Просвирнин (Expert1C) 18.06.09 15:22
(41) анализ данных за большой период без отборов может нагрузить систему на несколько секунд. но я не вижу ситуации, когда это надо. Даже если выполняется статистический анализ с использованием запросов - это весегда дополнительные условия, и если правильно писать запросы - это несколько секунд.
43. Stas N (StasN) 18.06.09 15:27
(40) В какой момент тогда у тебя происходит запись в регистр
44. Валерий Просвирнин (Expert1C) 18.06.09 15:30
(43) запись в регистр происходит в отдельном фоновом задании.
45. Stas N (StasN) 18.06.09 15:38
(44) т.е. это делается в отдельное время или во время работы юзеров ?
и данные получается собираются из стандартного журнала ?
46. Валерий Просвирнин (Expert1C) 18.06.09 15:40
(45) в описании написано:

... является копией штатного журнала регистрации ...
47. Сергей Ожерельев (Поручик) 22.07.09 10:04
Автору спасибо. Третий месяц работы подсистемы в живой базе. Сколько раз выручала.
48. Артур Аюханов (artbear) 25.07.09 09:12
Есть ли возможность программной записи в данный журнал регистрации без регистрации в системном журнале регистрации, т.е. аналог штатного метода ЗаписьЖурналаРегистрации ?

Т.е. не хочется дублировать данные в 2-х журналах, а сразу писать в быстрый журнал.
49. Валерий Просвирнин (Expert1C) 26.07.09 19:10
нет, это противоречит идеологии решения - в регистре хранится копия данных
50. Игорь Исхаков (Ish_2) 27.07.09 09:23
Общий вопрос о выборе объекта хранения изменений.

Если в качестве объекта хранения изменений использовать справочник с единственным реквизитом Дата и табличной частью по структуре аналогичной регистру сведений , то тогда добавление "пачки" строк не будет приводить к перезаписи всей табличной части элемента справочника .
И такая операция будет осуществляться значительно быстрее , чем запись "пачки" в регистр сведений.

С Вашей точки зрения , оправдан ли такой подход ?
Велики ли дополнительные издержки , с ним связанные ?
51. Валерий Просвирнин (Expert1C) 27.07.09 10:32
(50) а попробывать?
и есть подводный камень - как удалять объекты, на которые есть ссылки в журнале? при использовании регистра это проблема решается - в автоматическом режиме и при этом данные из регистра не удаляются.
52. Игорь Исхаков (Ish_2) 27.07.09 10:39
53. Артур Аюханов (artbear) 30.07.09 10:44
Схема работы понравилась, ввел в свои рабочие базы.
Вопросы:
1. каким образом можно вести работу в базах на РБД?
2. есть ли опыт ввода подобной системы для РБД, например, для контроля работы удаленных пользователей?
54. Валерий Просвирнин (Expert1C) 30.07.09 11:10
(53) ни на одном проекте пока не требовался перенос данных журнала в ЦБД

однако при необходимости можно подумать, но за некоторое вознаграждение...
55. Игорь Исхаков (Ish_2) 10.08.09 12:24
(51) Нет. Не стоит.
Если скорость записи "пачки" в регистр удовлетворительна , то идея замены регистра на справочник и создания дополнительного функционала становится неразумной.
56. Артур Аюханов (artbear) 13.10.09 16:58
(0) Похоже, что нарисовалось неудобство использования подсистемы после нескольких месяцев использования при большем объеме РС.
При добавлении в базу новых объектов (справочник, документов) идет очень долгая реструктуризация всех записей РС :(
ИМХО это происходит, потому что у 3-го измерения стоит тип условия ЛюбаяСсылка.

А ведь добавление новых объектов в рабочую базу происходит не так и редко.
Что можно сделать?
57. Сергей Старых (tormozit) 30.10.09 19:25
(56) Обрезать регистр. Ну мы вот сейчас остановились на обрезании по глубине времени. Для журнальных регистров для каждого задаем свою глубину хранения по времени. Можно еще сделать по количеству записей конечно, но это менее предсказуемо.
58. Сергей Старых (tormozit) 24.11.09 01:50
Взял идею данной подсистемы и воплотил в нашей системе.
Заметил одну неприятную штуку -
8.1.15.14
Установлено разделение хранения журнала регистрации "день" и уровень "Ошибки, Предупреждения"

Периодически выполняется выгрузка кодом
Фильтр = Новый Структура;
Фильтр.Вставить("ДатаОкончания", ТекущаяДата());
Фильтр.Вставить("ДатаНачала", ДатаАктуальности + 1);
ИмяФайлаДанных = ПолучитьИмяВременногоФайла("xml");
ВыгрузитьЖурналРегистрации(ИмяФайлаДанных, Фильтр);

Стал замечать, что на границах суток журнал перестает выгружаться. Похоже пока не откроешь системную форму журнала регистрации, метод ВыгрузитьЖурналРегистрации почему то возвращает пустой файл. Как только я открываю системную форму журнала (главное меню, сервис, Журнал регистрации), все сразу само начинает работать (создается ожидаемый файл выгрузки).
59. Сергей Старых (tormozit) 24.11.09 01:52
В описании не совсем точно написано "Будет работать только на клиент-серверном варианте базы". Hаботает и в файл-серверном, но с ручным обновлением/запуском регламентного задания.
60. Артур Аюханов (artbear) 12.12.09 09:04
1. Каким образом можно быстро очистить сабжевый регистр сведений?
Штатный способ - создать набор записей и тут же его записать - работает очень медленно (за полгода набрали 14 млн записей).
Или хотя бы убрать самую старую часть данных, т.е. ограничение по времени.

2. Кстати, а почему измерения регистра, кроме DateRef, не индексируются?
Например, поле Date вообще не индексировано, в результате отборы по периодам также могут подтормаживать.
61. Валерий Просвирнин (Expert1C) 14.12.09 09:27
(60) 1 - или так, или напрямую в SQL.
2. ну поле Date индексируется по определению, оно вообще первое в кластерном индексе, индекс по номеру записи вообще не имеет смысла, а по DataRef индекс есть. но вообще на больших таблицах есть смысл перестроить индексы напрямую в SQL - убрать все составные индексы и сделать только по нужным полям. Это позволит значительно сократить объем индексов
62. Артур Аюханов (artbear) 14.12.09 10:09
(61) Скрипт по индексам не подскажешь? я лично подобное на 8.1 еще не делал :(
63. Валерий Просвирнин (Expert1C) 14.12.09 10:14
(62) нахаляву - только типовой вариант, а оптимизация - за отдельную плату.
64. Андрей (oscar2002) 13.04.10 16:51
Интересно, а как будет работать данная разработка при полном перепроведении базы в монопольном режиме (Перепроведение мес занимает 12 часов) :)
Регламентное задание отработает после снятия мнопольного режима и повиснит на чтении XML файла. В тоже время, даже, если XML файл будет прочтен, далее повиснит на записи в регистр, т.к. будет записываться огромный кусок информации.
65. Валерий Просвирнин (Expert1C) 12.05.10 10:27
(64) нормально будет работать
нигде ничего не зависнет
66. sound sound (sound) 19.05.11 18:09
(0) А на 8.2 эта штука заработает? Может я что-то конечно не так сделал, но у меня в консоли регламентных заданий обработка загрузки завершилась с ошибкой:
ОбщийМодуль.жр_ЖурналРегистрации.Модуль(205)}: Поле объекта не обнаружено (EventName).
67. sound sound (sound) 20.05.11 12:08
Стал искать журнальчик для себя, среди прочих, и по крайней мере из того, что пока удалось найти, Ваш лидирует по качеству исполнения и кода, а еще вообще сама идея хорошая. Я бы еще добавил для себя вот такое http://infostart.ru/public/19949/, и тогда было бы вообще все просто зашибись. Однако у меня оно на 8.2 так и не заработало :cry:
68. sound sound (sound) 30.05.11 14:39
Люди-и-и, хоть у кого-нибудь эта штука на 8.2 работает а? Или все на 8.1 сидят?
69. Артур Аюханов (artbear) 29.09.11 14:49
(68) У меня заработало, недавно перевел конфу на 8.1 и решил проблему неверной работы.
70. sound sound (sound) 29.09.11 14:53
(69) Поздно, я уже себе переписал :)
71. Вася Васькин (yushmakovmv) 25.10.11 10:21
72. Михаил Иванов (wwizard) 15.03.12 18:17
У меня 8,2
При сравнении и объединении конфигураций, база перестала работать....
т.е. она загружается но ни один документ, справочник не работает.
73. Александр Койносов (Abenefic) 18.09.13 17:30