Вход | Регистрация
    1  2  3  4  5  6  7  8
1С:Предприятие :: 1С:Предприятие 7.7 и ранее

v7: 1С 7.7 ТИС ДБФ УРИБ 40 юзеров. Надо победить блокировки транзакций

v7: 1С 7.7 ТИС ДБФ УРИБ 40 юзеров. Надо победить блокировки транзакций
Я
   tgu82
 
28.10.20 - 13:18
1С 7.7 ТИС ДБФ УРИБ 40 юзеров.

В понедельник вообще с утра работать не могли. И так почти полтора часа.
Только когда я стал по очередности выгонять всех ввидимо отцепилась блокировка и
и все наконец заработали.

Заметил что 3 варианта блокировок:
1. при обмене урбд, попытка захвата доступа к 1SUPDTS
2. При попытке создать новый документ - попытка захвата 1SJOURN
3. При поытке создать элемент справочника - попытка заквата SC214 или 1SDNLOCK
3.1 Блокировка 1SDNLOCK возникает и при создании нового документа (видимо из-за нумерации что ли)

Ну с обменами не так часто и понятно потому что обмен я вижу.
С остальным все на так ясно.

Базы не малые, регистр RA328 подходит к 1.7 ГБ
Я так понимаю что многие проблемы из-за проведения документов задним числом ну и перепроведения если надо
Время ожидания захвата БД сброшено в ноль у всех вроде бы, но уточню. Может кого прозевал.
Заметил что в понедельник много потому что делают много приходов и в пятницу тоже.
Причем всем надо с утра.

На ПБ как-то особенно с этим всем проблем и нет а вот на ЦБ бывают, и неприятные
Мне бы хотя бы четко понимать из-за кого в любой конкретный момент времени возникает блокировка (за исключением обмена)
Тогда бы можно было его притормозить а другие бы работали дальше.
В ЦБ банк касса розница енвд перемещения поступления оптовые реализации комплектации и т.д.
Магазины для себя в ЦБ делают большие перемещения с Центрального склада.

Мне бы хотя бы четко понимать из-за кого в любой конкретный момент времени возникает блокировка (за исключением обмена)
Тогда бы можно было его притормозить а другие бы работали дальше !!!
   Злопчинский
 
701 - 10.11.20 - 10:34
нормально они дружат.
   tgu82
 
702 - 12.11.20 - 15:28
(701) НачатьТранзакцию пытается заблокировать журнал(как я теперь понял), не знаю мне кажется что попытка и начатьтранзакцию все-таки плохо совмещаются по крайней мере в моей голове
   tgu82
 
703 - 12.11.20 - 15:34
(702) Тут вопрос в том что при ОтменитьТранзакцию не происходит выполнения ЗафиксироватьТранзакцию. То есть если на НачатьТранзакцию система показала большую фигу то в ЖР пойдет красная запись об ошибке. Если сначала Попытка а потом НачатьТранзакцию то при невозможности ее начать по исключению будет откат наверх. А если сначала НачатьТранзакцию а потом попытку то получается что чего-то пытаешся в начавшейся транзакции но непонятно куда уходить тогда по исключению получается опять внутрь транзакции или в исключение ставить ОтменитьТранзакцию? Короче малость туманно
   Mikeware
 
704 - 12.11.20 - 15:34
(702) кроме журнала еще много чего может быть заблокировано.
   tgu82
 
705 - 12.11.20 - 15:43
(704) Ну это да. Но речь о том что во что обертывать и надо ли это. Транзакцию в попытку или попытку в транзакцию?
   Mikeware
 
706 - 12.11.20 - 15:45
(705) смотря что надо сделать....
   tgu82
 
707 - 12.11.20 - 16:08
(706) Например? Вот просто хочу понять. ну скажем формирую я массово какие доки - например РКО по премии по сотрам. Юзеры другие работают ддокументы проводят всякие - вот как здесь правильно когда в цикле РКО создаются? НачатьТранзакцию перед циклом? И нужна ли здесь попытка и где?
   tgu82
 
708 - 12.11.20 - 16:15
(707)+ Мне кажется так. Если документ проводится очень быстро то создать полсотни проведенных доков это фигня, а вот если не очень быстро тогда лучше паузы с попыткой опять провести данный документ чтобы другие могли работать в это время тоже
   Злопчинский
 
709 - 12.11.20 - 20:20
(702) "НачатьТранзакцию пытается заблокировать журнал"
- нет.
откуда в самом начале транзакции транзакция знает какие объекты в ней будут юзатся чтобы их заблокировать?
   Злопчинский
 
710 - 12.11.20 - 20:21
(703) нормально там все уходит/приходит. аккуратно писать и все.
   Злопчинский
 
711 - 12.11.20 - 20:24
(705) НачатьТранзакцию ничего не блокирует.\Поэтому ситуация когда рухнет именно на НачатьТранзакцию - представляется мне ооочень маловерятной. Рухнуть при начале транзакции может тогда когда внутри открытой транзакции ты попытался взять заблокированный объект - тут транзакция твоя и навернулась. Но именно на попытке взять заблокированный объект. Но не на "НАчатьТранзакцию".
.
могу конечно ошибаться.
пусть спецы меня поправят содержательно
   Злопчинский
 
712 - 12.11.20 - 20:25
(707) "например РКО по премии по сотрам." неудачный пример. это явно можно сделать вне рабочего времени. даже не роботом.
   Злопчинский
 
713 - 12.11.20 - 20:30
(707) нахера в этом примере транзакция? Премия Петрова (РКО на премию ПетровУ) зависит от премии Сидорова (от РКО на Сидорова) что ли?
.
закрутил цикл. в цикле захерачил Попытку на каждый документ (будет медленее чем без попытки). Если создаваемый документ свалился в исключение - да и хрен с ним, пропустил, подождал и дальше херачишь (можно попытку вне цикла, а по исключению - переход на голову цикла к продолжению работы).
.
в результате сгенерил не 50, а 47 доков. ну и зашибись. следующим проходом (через час или как-то же ты понимаешь что РКО у тебя еще не созданы) сгенеришь оставшиеся 3
   tgu82
 
714 - 12.11.20 - 22:47
(713) Ну на самом деле так и есть. Ну а что тогда делает НачатьТранзакцию? Она же объявляет всем что будет что-то писаться в базу данных?
   Вуглускр1991
 
715 - 12.11.20 - 23:17
Написал для этой проблемы следующий слоеный пирог:
1) Сервис сообщений и регистрации подписчиков на сообщения.
2) Внешнюю компоненту для приема сообщений с этого сервиса - технологии COM.
3) Консольную утилиту с командами "109" - выйти немедленно всем, "107" - остановить работу и "108" - продолжить работу.
4) Ввел глобальные переменные - как "параметры сеанса", типа можно работать или нельзя.
В момент когда начинался обмен УРБД - отправлял из скрипта (обмен автоматический) 107 и все клиенты изменяли значения параметров сеанса. Когда кто-то из них пытался сделать запись в базу данных, до того, как произойдет блокировка, проверялось при помощи этих параметров: а не начат ли УРБД обмен, и если начат - вываливалось модальное окно, блокирующее его работу. Затем обмен кончался, всем отправлялось 108 и люди продолжали работать.
5) Настроил Formex.dll на события открытия форм и прописал логику, критическую к блокировкам.
6) Настроил глобальные вызовы ПриЗаписи, ПриОткрытии, ПриСозданииНового, ПриВводеНаОсновании при помощи ActiveMD - зашел во все формы всех метаданных и расставил процедуры.
7) Работает уже более 10 лет.
   tgu82
 
716 - 12.11.20 - 23:27
(715) Интересно, собственно я об этом и говорил все время
Правад вот насчет написания внешней компоненты - сложно это )
   hogik
 
717 - 12.11.20 - 23:53
(711)
«пусть спецы меня поправят содержательно»(с)
Открой, наконец, файл «ПроТранзакции.odt».
Я это написал специально для ТЕБЯ в январе 2019 года.
А если лень открывать, то читай тут:
=====================================
Положение № 1.
Транзакции запускаются/активизируются:
1) Явно, оператором языка 1С НачатьТранзакцию().
2) Неявно, в модуле проведения документа.
3) Неявно, в любом операторе языка 1С вызывающем модификацию таблицы БД. Например: Новый(), Записать().
Положение № 2.
Вложенные транзакции являются фикцией - на "поведение" блокировок они не влияют. Реальной транзакцией является транзакция "верхнего" уровня.
Положение № 3.
Блокировки накладываются на всю таблицу, а не на отдельные записи таблицы.
Положение № 4.
При выполнении операций внутри транзакции чтения или модификация (изменение записи или добавлении записи) "возникают" следующие блокировки:
1) До первого оператора обращения к таблице никаких блокировок не накладывается.
2) При (перед/до) выполнении первого оператора чтения таблицы накладывается блокировка по записи.
3) При (перед/до) выполнении первого оператора модификации таблицы накладывается блокировка по чтению (или подымается уровень с "по записи" на и "по чтению", если чтение таблицы уже было ранее в этой транзакции).
Положение № 5 (спорное).
Первый оператор (по логики алгоритма) языка 1С выполняющий обращение к таблице внутри транзакции "возбуждает флаг" т.н. "групповой блокировки". Основное назначение этого "инструмента" - запомнить имя таблицы, используемое в выдачи "системного" сообщения о невозможности начать очередную транзакцию. Думаю, что по задумки разработчиков 1С-а этот "флаг" должен обеспечить последовательное выполнение транзакций в различных сессиях 1С. Данная задумка сможет работать, если разработчик на языке 1С будет во всех транзакциях придерживаться единой последовательности в алгоритме на порядок  обращения к таблицам. Примером успешного срабатывания данной задумки - модуль проведения документов. Т.к. такой "первой" таблицей является "Журнал документов" для всех видов документов.
Положение № 6.
1) Операторов модификации БД вне транзакции не существует в 1С (см. пункт № 3 в положении № 1). И если выполняется модификация таблицы БД этим неявным способом активизации транзакции, а таблица заблокирована в транзакции другой сессии 1С, то операция модификации сваливается "мгновенно" и настройка "Время ожидания захвата таблицы..." на это не влияет.
2) Чтение вне транзакции не накладывает никаких блокировок. Но, производится проверка блокировки таблицы по чтению сделанная из транзакции другой сессии 1С. И если таблица заблокирована модификацией в транзакции другой сессии 1С, то данное чтение перейдёт в длительное ожидание не зависящее от настройки "Время ожидания захвата таблицы...".
Положение № 7 (общее).
В 1С 7.7 DBF-ая версия обеспечивается на 100% требования ACID (SQL-ная не обеспечивает). Т.е. все изменения выполняемые в транзакции "нашей" сессии не видны в других сессиях и не могут изменится другими сессиями. В "нашей" сессии повторное чтение данных не даст разный результат (если не использовать прямые запросы на FoxPro). Но, существует проблема не "описанная" требованиями ACID. Это случай когда две разные сессии читают данные и на основании их анализа делают выводы о дальнейшем поведении алгоритма. Если не выполнить блокировку по чтению всех читаемых данных, то сессии будут делать вывод на основании информации, которая может быть изменена в другой сессии уже после выводов сделанных в "нашей" сессии. Классический пример этой ситуации - обновление итогов:
1) Читаются данные в оперативную память (переменная Х) старого значения итогов.
2) Выполняется Х=Х+Добавка.
3) Записывается Х в базу данных.
Если одна сессия выполнит пункт № 1 до выполнения пункта №3 в другой сессии, то итог будет неверным. И транзакции 1С никак не решают эту проблему. Кроме обеспечения инструмента "флага", как это существует при проведении документов.
   hogik
 
718 - 13.11.20 - 01:03
Вопрос к участникам темы.
Ниже привожу код из глобального модуля.
Возникала ли проблема в вашей системе решаемая подобным кодом?

//--------------------------------------

Процедура ШальнаяТранзакция()
   Пока (0=0) Цикл
      Попытка
         ОтменитьТранзакцию();
         ЗаписьЖурналаРегистрации("Шальная транзакция: "+ИмяПользователя(),,,,5);
      Исключение
         Прервать;
      КонецПопытки;
   КонецЦикла;
КонецПроцедуры
//--------------------------------------

ОбработкаОжидания("ШальнаяТранзакция",1);
//--------------------------------------
   tgu82
 
719 - 13.11.20 - 07:31
(717) То есть если я выбираю ВыгрузитьИтоги или РассчитатьИтогиНа или По то в таблица регистра которую я анализирую или даже несколько таблиц регистров - блокируются и по записи и по чтению? И тогда чем хуже закрыты регистры тем больше времени требуется на чтение итогов?
   tgu82
 
720 - 13.11.20 - 07:41
(718) транзакция может выполняться в данный конкретный момент только одна? ведь не обязательон же проводить документ, иожно создать или модифицировать документы и справочники в разных сессиях разные. новый, записать. Тогда какую транзакция отменяет ваша процедура ожидания каждую секунду?
   Mikeware
 
721 - 13.11.20 - 07:52
(713) премиальный фонд вычисляется по объему продаж за педыдущий период , насчитанному ровно в 16:28:37 четверга четной недели, следующего за отчетным периодом; и распределяется по отделам, а внутри отделов по сотрудникам методом Монте-Карло.
   tgu82
 
722 - 13.11.20 - 08:04
(721) Да нет у нас такого фонда давно, я просто пример привел. Вот из (720) какая транзакция отменится? Ведь есть же транзакции блокирующие и по записи и по чтению (самый высокий уровень), при этом транзакционные операции производятся как с документами так и со справочниками. При этом блокируется или Журнал или днлок или упдтс кстати больше и не помню никаких других вариантов блокировок когда ошибки в ЖР пишутся
   Вуглускр1991
 
723 - 13.11.20 - 09:43
(716) Если интересно, то могу все передать.
   tgu82
 
724 - 13.11.20 - 09:56
(716) Интересно даже очень. А это для ДБФ или без разницы?Я хотел на почту написать но у вас она скрыта
   Злопчинский
 
725 - 13.11.20 - 11:31
(714) "Ну на самом деле так и есть" - премия одного сотрудника влияет на премию другого сотрудника?
   Злопчинский
 
726 - 13.11.20 - 11:43
(720) " Тогда какую транзакция отменяет ваша процедура ожидания каждую секунду?"
скорее всего, это подстраховка от повисшей незакрытой транзакции где-то (только транзакция открытая в своем сеансе?)
.
а вот действует ли ОтменитьТранзакцию() на открытые транзакции которые были открыты в других сеансах? - вот не знаю.
по здравому размышлению - ОтменитьТранзакцию действует только на транзакции своего сеанса..
   Злопчинский
 
727 - 13.11.20 - 11:44
(723) и мне можно прислать? e.meil@mail.ru
   Злопчинский
 
728 - 13.11.20 - 11:45
Кстати.
у  hogik есть весьма полезная приблуда, которая позволяет тормознуть 1С в тот момент когда нет никаких транзакций
   tgu82
 
729 - 13.11.20 - 15:08
(728) Какая?
   tgu82
 
730 - 13.11.20 - 17:56
(726) Транзакции именно своего сеанса. И как бы теперь более менее понятно что к чему
 
 Рекламное место пустует
   hogik
 
731 - 13.11.20 - 21:39
(720) (726)
В сообщении (43) написано:

«Или кто-то долбит документы а все стоят, а долбит впустую ибо один вид дока наезжает на другой. Увидел это - тут же его отключил и все заработали. Но как сделать чтобы аж визжал комп и ругался что Сидоров лупит черт что в одиночку»(с)

Допускаю, что в сессии «Сидорова» образовалась незакрытая транзакция (на уровне движка БД) из-за сбоя в неком алгоритме. И последующие транзакции выполняются как написано в положении № 2 сообщения (717), давая возможность работать «Сидорову» в диалоговом режиме. Тогда код из (718) сообщения может решить проблему.
   Злопчинский
 
732 - 13.11.20 - 23:27
(731) " образовалась незакрытая транзакция (на уровне движка БД) из-за сбоя в неком алгоритме. "
-то есть тутречь о том, что именно прогрраммистом открытая транзакция где-то незакрывается..
но вроде как если форму закрыли или процедура, в которой открыта транзакция заканчивается - выход из процедуры - то транзакция должна закрыться или отмениться автоматом.
   hogik
 
733 - 14.11.20 - 00:42
(732)
Должна. :-) Но, я написал выше «из-за сбоя в неком алгоритме»(с). Я вспомнил, что за 15 лет эксплуатации мы имели пару похожих случаев, как описывает Юрий. Причину мы не смогли найти. А у Юрия, по его словам, это возникает раз в три месяца. Те. разглядывая журнал событий, можно будет попытаться найти «точку» в действиях пользователя/системы с которой пошла эта бяка.
Это если код из (718) сообщения сработает. Ну, и автоматизировать снятие проблемной сессии без ручных действий.
   tgu82
 
734 - 14.11.20 - 09:03
(732) Понимаешь - вся идея открытой мной ветки заключалась именно в том чтобы
1. Понять вот все эти сбои - это следствие каких-то моих устанвок типа "секретных" релизов или патчения каких-то библиотек, либо падения периодического - журнала или же это вполне объяснимые и даже управляемые в рамках штатной (или с добавлением формекса) 1с и тогда вопросы в скорости проведения документов, тормоза из-за незакрытых регистров и т.д.
2. Чтобы все-таки отделить транзакции от попытки - у меня это понятия смешивались в голове как-то.
3. .....Что-то еще попутно узнать и применить типа кэш по константам.

Я получил очень сильную серию консультаций (даже где-то натаскиваний) от hogik. И многое в голове прояснилось. За что я ему очень благодарен!
Ну и массу полезнейших советов и подсказок от остальных форумчан за что вам всем большое спасибо

Просто первые ветки о том что только под скуль можно что-то выяснить по транзакциям - не совсем верные и штатные механизмы платформы 1С и его встроенный язык имеют очень большие и достаточно прозрачные возможнсти которыми в большой степени можно штатно или почти штатно управлять
   tgu82
 
735 - 14.11.20 - 09:34
(734)+ Ну и как я понял - что все-таки при всех нюансах лучше использовать ОбработкуОжидания одну на сенс, тогда все намного прозрачнее ну и обработку внещнего события - тоже одну - и тоже именно в глобальном контексте. Эти же процедуры в локальном контексте мне кажется для таких не очень сложных алгоритмов как у меня - применять не стоит потому что как вообще работает вся эта "адская" смесь глобального и локального контекста особенно в плане когда есть глабальная обработка ожидания (точнее с ипспользованием Формекса - их несколько же можно делать) и обработки ожидания из локальных контекстов. Конечно в этом случае глобальная процедура ожидания - штатная - получается довольно сложной и длинной но тут уж ничего не поделаешь. Ну и выгонялка пользователей - возможно толкьо с помощью жесткого киллера а до это отправки сообщения во все сеансы
   Djelf
 
736 - 14.11.20 - 09:49
Да, к сожалению бывает такое как описано в (733). Редко, но бывает. Кто-то один работает, но в параллельной реальности т.к. документы у него по факту не сохраняются, а все остальные курят бамбук. Синтетическими тестами добиться такого не удалось.
А вот взаимоблокировки получить - легко! Код, конечно идиотский, но зато одна сессия четко залипает на захвате таблицы Журнала, а другая на Номерах документов.
Процедура СоздатьВзаимоблокировки()
  Система=СоздатьОбъект("Система");
  НачатьТранзакцию();// без этого взаимоблокировки не будет!

  Для ии=1 По 100 Цикл
    Состояние(ии);
    Попытка
      ОтменитьТранзакцию();
      Сообщить(1/0);    
    Исключение
      Попытка
        НачатьТранзакцию();
        Реализаиця=СоздатьОбъект("Документ.Реализация");
        Реализаиця.Новый();
        ОтменитьТранзакцию();
      Исключение
      КонецПопытки;
    КонецПопытки;
    Система.Уснуть(100);
  КонецЦикла;
КонецПроцедуры

   tgu82
 
737 - 14.11.20 - 10:35
(736) И все это в обработке ожидания глобальной должно быть?
Каждую секунду будет запускаться?
   Djelf
 
738 - 14.11.20 - 10:51
(737) Во внешнюю обработку засунь. И запусти в 2х сессиях. Честно говоря не очень понимаю как это работает, но обе сессии зависнут.
Это не лечилка от hogik, это наоборот - убивалка!
   tgu82
 
739 - 14.11.20 - 15:40
(738) Я понял кадется. Это как пример вот такого поведения базы как я описывал
   Eeeehhhh
 
740 - 14.11.20 - 16:13
8 страниц ни о чем ... Ау Ромикс ты где?
   Mikeware
 
741 - 14.11.20 - 16:37
(740) ромикса похитили инопланетяне с Нибиру за разоблачение эфирно-кефирного заговора мирового правительства иллюминатов. Только тс-с-с!
   Вуглускр1991
 
742 - 14.11.20 - 17:22
(741) А ведь тебе не платят за забалтывание и сокрытие сведений о деятельности верхушки глобального управления. Зачем ты льёшь воду на их мельницу?
   Mikeware
 
743 - 14.11.20 - 17:49
(742) это не вода! :-)
   Злопчинский
 
744 - 14.11.20 - 18:02
(743) Главное - после того ка котлил - не забыть про ширинку...
   tgu82
 
745 - 14.11.20 - 19:31
(740) Еще как о чем!

Ведь здесь по-сути вообще затрагивались как практические так и теоретические основы работы с транзакциями
и способы устранения ошибок и способы корректного управления транзакциями
   tgu82
 
746 - 14.11.20 - 19:33
(745)+ Я например набрался наглости и некоторые проблемные места уже проработал и кое-какие задачки
за которые никак не мог взяться потому что висело мое непонимание всех этих вещей надо мной дамокловым мечом
  1  2  3  4  5  6  7  8

Список тем форума
Рекламное место пустует  Рекламное место пустует
Выдавать глобальные идеи — это удовольствие; искать сволочные маленькие ошибки — вот настоящая работа.
Фредерик Брукс-младший
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.