У розрахованих на багато користувачів системах важливу рольграє правильна організаціяструктури та налаштування блокувань. Якщо її немає, користувачам доведеться часто стикатися з помилками, спричиненими конкуренцією за певні ресурси системи. Але є проблема конфлікту блокувань, знайома багатьом користувачам. Чому виникає конфлікт блокувань 1С та як його усунути?
Конфлікт блокувань в 1С 8.3 та його значення
Для більшості користувачів повідомлення про конфлікт блокувань 1С означає лише помилку, що заважає виконувати свою роботу. Вони хочуть якнайшвидше позбутися цієї проблеми і беруть в облогу IT-відділ скаргами на те, що «1С не працює».
Але для системних адміністраторівта розробників таке повідомлення говорить про можливу наявність проблем у структурі конфігурації. Перед тим, як намагатися догодити користувачам та прибрати блокування, необхідно проаналізувати ситуацію та зрозуміти причину виникнення повідомлення про помилку.
Причини виникнення помилок блокування в 1С
Показові тести навантаження демонструють, що сервер 1С витримує паралельну роботу більш ніж п'яти тисяч користувачів. Але ідеальні умови подібних експериментів недосяжні у повсякденних умовах великих та середніх компаній. Щоб досягти аналогічної швидкодії та безпомилковості, конфігурація має бути ідеально розроблена та заточена під конкретні бізнес-процеси підприємства.
Якщо не брати ідеальні варіанти, то конфлікти блокувань 1С трапляються з наступних причин:
Одночасна робота користувачів із великим обсягом даних.Ця причина продиктована внутрішніми механізмами 1С. Вони передбачають заборону зміни даних, залучених до транзакції, запущеної від імені іншого користувача;
Помилки та недоліки у конфігурації.У структурі типових рішень від компанії «1С» враховано рекомендації щодо максимізації продуктивності. Але сторонні розробники не завжди дотримуються високих стандартів, і в їхньому коді часто можна зустріти такі недоліки:
- неоптимальні запити;
- Запит залишків на початку дій;
- Нерозуміння призначення об'єктів конфігурації та його неправильне застосування;
- Надмірність закладених у системі або додатково розроблених блокувань.
Як виправити конфлікт блокувань у 1С 8.3
Системне повідомлення «конфлікт блокування при виконанні транзакції 1С 8.3» не характеризує конфігурацію як неправильно спроектовану. Але якщо подібні сигнали ігнорувати, існує ймовірність у найвідповідальніший момент, наприклад, при здачі квартальної чи річної звітності отримати великі проблеми. У найкращому разі – гальмуючу систему та незадоволених користувачів. У гіршому – неправильні дані на виході, що може спричинити штрафні санкції від контролюючих органів.
Вирішенням проблеми конфлікту блокувань в 1С 8.3 може стати переведення конфігурації на керований (ручний) режим керування блокуванням. Реалізований у версії 8.1 механізм у руках грамотних фахівців вирішує проблему конфлікту блокувань при транзакції в 1С.
Але варто мати на увазі, що ця дія зменшить рівень захисту даних від зміни в процесі читання їх іншими користувачами. Тому, якщо ви не готові самостійно контролювати всі блокування в системі, не поспішайте змінювати конфігураційні установки.
Швидке вирішення конфлікту блокувань 1С
У роботі адміністратора або розробника може статися ситуація, коли немає часу на перевірку помилки та пошук причин проблеми. Наприклад, необхідно подати звіт або подати дані до певного часу, а помилки блокувань 1С перешкоджають цьому.
Для швидкого вирішення проблеми існують два шляхи:
- Знайти та завершити сеанс, який заблокував необхідні дані. У невеликих компаніяхде кількість користувачів 1С не перевищує пари десятків осіб, це оптимальний варіант рішення;
- Якщо ви контролюєте систему, де працюють сотні співробітників, пошук потрібного сеансу без спеціалізованого програмного забезпеченняможе затягнутися надовго. У цьому випадку набагато ефективніше перезавантажити сервер.
Ці рішення радикальні та спрямовані лише на швидке вирішення проблеми та звільнення даних для термінової подання звітів. Викоренити її можна лише розібравшись у причині, через яку виник конфлікт блокувань при виконанні транзакції 1С. Після таких дій необхідно знайти вразливі місця у системі, оптимізувати конфігурацію чи роботу працівників. Використовувати подібні заходи на постійній основі за регулярних конфліктів блокувань на транзакціях не рекомендується.
Всім привіт!
Днями на роботі зіткнувся з проблемою блокувань, а саме стало з'являтися повідомлення "Конфлікт блокувань при виконанні транзакції. Перевищено максимальний час очікування блокування".
Очевидно, що тут немає проблеми взаємоблокувань, просто якийсь сеанс поставив блокування і "забув" прибрати. При цьому проблема загрожувала серйозними наслідками – не проводився документ Реалізації товарів та послуг. В базі одночасно працює близько 100 осіб, і неможливо виконати типову та часту операцію!
Рішення було два – перезавантаження сервера або пошук збійного сеансу. Перше рішення просте і швидке, але, як тут уже хтось писав – ребутати сервер можна доти, доки тебе не звільнять. Вирішив піти другим шляхом.
Перший день - проблема з'явилася вдень, спочатку здавалося, що проблема у віддаленому користувачеві, який засів у конфігураторі. Було схоже, що просто виконання зупинилося на точці, і блокування, звісно, не знялося. За кілька годин вдалося звільнити конфігуратор, але проблема не пішла. Примусово вбивати конфігуратор було вкрай небажано, можливо, в ньому працювали. Після цього в хід пішов Гугл. Знайшов статтю на цьому сайті, де пишеться, як знайти блокування в СУБД MS SQL, перевірив, блокувань на рівні СУБД не було. Дивно. Далі були спроби налаштувати тих. журнал. Налаштував, а далі що? За 15 хвилин пара гігів логів! Як їх читати, що шукати? Невідомо.
Знайшов статтю, як побачити, що заблоковано через SQL Trace. Та навіть якщо знайду, що далі? Мені потрібний сеанс!
Ближче до 16:00, коли я зрозумів, що далі не можна тягнути, я зробив ребут. В надії, що такого більше не повториться (а це був перший випадок за півроку роботи), полегшено зітхнув, все запрацювало. А дарма... Другий день – та сама ситуація. Копав години півтори, знову незрозумілі спроби гуглити та інше. Без результатів. Ребут. Наприкінці дня сталося ще раз. Ну, думаю, чудово, спокійно приїду додому і сиджу, копирсаюся. Приїжджаю додому, все вже гаразд. Сумно.
На третій день глянув вебінар, розповіли про цікавий і ефективний спосібпошуку проблеми. Запам'ятав, але проблема не виникала. Минув тиждень і ось воно – знову блокування! Потираю руки та починаю діяти.
Перше – налаштовуємо журнал. Так, без нього ніяк, але тепер я вмію читати його. Ставимо дві події: перша TLOCK, друга TTIMEOUT. Перше відображає всі події блокування, друге показує блокування, які не змогли встановити у відведений час. Насправді, швидше за все, достатньо лише TTIMEOUT.
Копіюємо файл техжурналу у відведене місце, летимо у програму, викликаємо блокування, отримуємо повідомлення та прибираємо або перейменовуємо файл техжурналу. Нам же не потрібні тонни інформації про інші блокування!
Переходимо до папки rphost_PID, знаходимо текстові файли та робимо пошук за словом TTIMEOUT. Бачимо рядок:
53:16.789126-0,TTIMEOUT,5,process=rphost,p:processName=*****,t:clientID=16536,t:applicationName=1CV8,t:computerName=ASUSM,t:connectID=17272,SessionID= 2242,Usr=*******,WaitConnections=8239До слова, папок rphost_PID може бути кілька, все залежить від того, скільки робочих процесів запущено на сервері.
А далі все просто: дивимося в кінець рядка – WaitConnections = 8239, це наш номер З'ЄДНАННЯ. Заходимо до консолі сервера, переходимо до З'єднання, знаходимо цей номер і дивимося номер сеансу. У моєму випадку на одного користувача було два сеанси – збійний та якийсь інший. Гримнув сеанс, на який вказував техжурнал. І о диво! Все запрацювало, радості немає меж! Але, як з'ясувалося пізніше, сеанс був не завислий:), у ньому працювали. Тому на майбутнє – бажано зв'язуватися з користувачем та попереджати.
На мій погляд, достатньо типове рішеннядосить типової проблеми. Невідомо, чому воно мені не потрапило, можливо через те, що доводилося його шукати по тривозі, а коли користувачі не підтискали, то й тести проводити не виходило – помилки ж немає.
«Конфлікт блокувань при виконанні транзакції: Перевищено максимальний час очікування надання блокування» — помилка, що досить часто зустрічає в 1С 8.3 і 8.2, пов'язана з конкуренцією за використання ресурсів у системі.
Система 1С дозволяє працювати паралельно великій кількості користувачів: як показують тести навантаження, сьогодні ця кількість не обмежується і п'ятьма тисячами користувачів, що одночасно працюють в системі. Однак, щоб база даних 1С 8 могла одночасно підтримувати велика кількістьпро користувачів, конфігурація має бути правильно розроблена.
Отримайте 267 відеоуроків з 1С безкоштовно:
Виконання великої кількості операцій
Цілком ймовірно, що будь-який користувач запустив, наприклад, за великий період однієї транзакції. Архітектура 1С 8.3 передбачає, що система не дає змінювати дані, що використовуються в одній транзакції іншим користувачем, та блокує їх.
Можливо, це тимчасова помилка, яка перестане виникати, коли інший користувач завершить дії в системі. Якщо ця помилка виникає часто, то, швидше за все, справа в іншому.
Помилка конфігурації
Крім помилок у коді часто трапляються методично невірні рішення. Наприклад, він сам собою має на увазі послідовне проведення документів. Партійний облік можна замінити на РАУЗ – цим Ви серйозно підвищите продуктивність системи.
Як виправити цю помилку у 1С 8.3?
У будь-якому випадку, поява помилки «Конфлікт блокувань при виконанні транзакції» говорить про необхідність інспекції системи, особливо для середніх та великих інформаційних систему клієнт-серверному режимі роботи (MS SQL, PostgreSQL тощо). Якщо це проігнорувати на ранньому етапі, можливі незворотні наслідки пізніше, коли робота системи буде особливо важливою (у період подання звітності).
Для аудиту та виправлення помилок найкраще вибрати надійного партнера. Просто зателефонуйте нам, і ми вирішимо будь-які Ваші завдання у найкоротший термін. Подробиці на сторінці.
Нерідко під час роботи в 1С виникає помилка «Конфлікт блокувань під час виконання транзакцій: Перевищено максимальний час очікування надання блокування». Суть її полягає в тому, що кілька сеансів намагаються одночасно виконати схожі дії, торкаючись одного і того ж ресурсу. Сьогодні ми розберемося як виправити цю помилку
Велика кількість виконуваних операцій
Насамперед при пошуку причин слід уточнити, скільки одночасно користувачів, що працюють одночасно, знаходиться в тій інформаційній базі, в якій видається подібна помилка. Як ми знаємо, максимальна їх кількість може бути досить великою. Це і тисяча і п'ять тисяч.
Механізм блокувань та транзакцій описаний у посібнику розробника. Їх використовують при зверненні кількох сеансів до одних і тих самих даних одночасно. Логічно, що ті самі дані не можуть змінюватися різними користувачами в один і той же момент.
Також слід перевірити, чи не запущено у когось із користувачів обробки масової зміни даних. Це може бути як закриття місяця тощо. У разі після закінчення роботи обробки помилка пропаде як така.
Регламентні завдання
Не рідкісні випадки, коли причина помилки криється в , що обробляє велику кількість даних. Рекомендується подібні речі робити вночі. Вкажіть розклад виконання таких регламентних завдань у позаробочий час.
Таким чином, і користувачі будуть працювати в стабільній системі, і самі регламентні завдання будуть завершуватися успішно, оскільки знизиться ймовірність виникнення конфліктів з сеансами користувача.
«Завислі сеанси»
Проблема "завислих сеансів" користувачів знайома практично кожному, хто стикався з обслуговуванням 1С. Користувач міг уже давно вийти з програми, або закрити будь-який документ, але його сеанс, як і раніше, залишається в системі. Проблема найчастіше поодинока і досить завершити подібний сеанс через консоль адміністратора. Такі проблеми можуть виникнути і з фоновими завданнями.
За численними коментарями на просторах інтернету подібні ситуації найчастіше трапляються під час використання мережевих ключів захисту. Якщо ситуація із «зависаючими сеансами» повторюється систематично, це причина провести ретельну перевірку та обслуговування системи та серверів (якщо база клієнт-серверна).
Помилки під час написання конфігурації
Усі типові конфігурації розроблені кваліфікованими фахівцямита експертами. Кожна система ретельно тестується та оптимізується для більш швидкої та коректної роботи у ній.
У зв'язку з цим причина помилки може бути у неоптимальному коді, написаному стороннім розробником. Це може бути «важкий» запит, який блокуватиме дані на тривалий проміжок часу. Так само часті випадки побудови алгоритмів з низькою продуктивністю та порушенням логіки.
Велика ймовірність, що конфлікт блокування виник саме через помилки розробника, якщо він виник після оновлення програми. Для перевірки можна просто «відкотити» доопрацювання, або зробити рефакторинг коду.
Запитання: УТ11.1. Пакетне створення Реалізацій. Конфлікт блокувань
Добридень! Конфігурація УТ11.1. Клієнт-серверний варіант. Параметри 1С Сервера та SQL Сервера за промовчанням. Програмно формуємо реалізацію. На етапі запису документів періодично виникає конфлікт блокувань. Підкажіть, яким чином вирішуються подібні питання? Чи використовуються транзакції з керованими блокуваннями? Заздалегідь дякую.
Відповідь:
не треба вимикати) переведи їх на ніч - там може і розрахунок собівартості та індекси пошуку вважаються.
Питання: Конфлікт блокувань під час виконання транзакції
Щодня майже одночасно при проведенні документа на 5-10 хвилин вискакує дана помилка 1С 8.3.10.26.99 УТ11(11.4.1.261):
Конфлікт блокувань під час виконання транзакції:
Microsoft Sql Server Native Client 11.0: Перевищено час очікування на блокування.
HERESULT=80040E31, SqlServer: SQLSTATE=HYT00, state=38, Severity=10, native=1222, line=1
Підкажіть, від куди починати копати?
Відповідь:() Включи профайлер у цей час на події Lock:Acquired та Lock:Escalation. Потім доповіли, що спіймав.
Запитання: Відновлення бази (конфлікт блокувань)
Добридень. База вмирає. Серверні.
З'ясувалося не відразу, т.к. все працювало окрім документа сф виданий. А його не так часто творять. Тому бекап не актуальний (минув уже мабуть кілька днів), намагалися розгортати копію 2-х денної давності – півдня було нормально, а потім вилізла та сама проблема.
Симптоми: при спробі скасування проведення сф отримуємо конфлікт блокувань, навіть якщо один користувач у базі. ТІІ (перевірка логічної та посилальної цілісності) валиться з конфліктом блокувань, створення бекапа через sql management studio - те саме ("Перевищено час очікування типу короткочасного блокування буфера 3 для сторінки").
Хочемо спробувати залити cf тижневої давності, але надій мало.
Відповідь:Тут проблеми з сервером баз даних, а не 1С, версій конфігурації та ін ні до чого.
Можливо не обслуговуваний вилиць жив як міг поки вистачало ресурсів, а тепер у автора починається новий етап освоєння знань.
Якщо розмір дозволяє – вивантажуйте у файлову та починайте вивчати sql глибше.
Запитання: УТ10. Конфлікт блокувань
Добридень! Клієнт-серверний варіант. Мені дісталася у спадок дуже допрацьована конфігурація БітАвто (автосервіс на базі УТ10). В обробнику проведення документа "замовлення-наряд", основного для майстрів-приймачів та менеджерів, загорнуто формування підлеглих документів (реалізація, рахунок-фактура, вимога накладна), розрахунок з/п механіків, резервування товару, якщо новий документ, то створення замовлення- покупця та ще деякий функціонал. База зросла і часто виникало конфлікт блокувань. У вихідні, коли народу менше конфліктів немає.
Підозрюю, що за такої кількості аналізу, під час проведення документа, довгий часблокує журнал документів, хоча начебто повністю блокується журнал замовлень.
Якщо обробником кнопки "Ок" зробити свою процедуру, де послідовно запускати "ОбробкаПроведення", а потім процедуру, наприклад, Сформувати Підпорядковані Документи, потім розрахувати зарплатню і т.п. Не впевнений, що такий варіант допоможе. Додавати кнопки навішувати формування документів не підійде, т.к. користувачі забуватимуть про неї.
Відповідь:
| Zerro |
|---|
| vde69, Так це напевно якась Раруська фігня |
Ні, це не Рарус, це БітАвто
Питання: 1c конфлікт блокувань під час відкриття форми документа
УВП
З недавнього часу раз на 2-3 дні виникає блокування на документі Вимога-накладна. Тобто. жоден документ цього не відкривається. Весь час
Інші документи працюють нормально.
У налагоджувачі проблем не знайшов, у жодному модулі не встигає зупинитися - відразу конфлікт блокувань.
Я підозрюю якусь проблему SQL.
Відповідь:Проблема була в заданні обслуговування індексів, що не завершилося.
Питання: помилка SQL2000 у процесі виконання транзакції в 1С77
в MSSQL база 1С77 (реліз 27) ТіС. Регулярно під час проведення проводок вискакує помилка:
Під час транзакції сталася помилка!
SQL State: HYT00
Native:0 Message: Час очікування минув.
у результаті провести документ не вдається. Це може тривати 20 хв., а може й годину.
Як із цим боротися, де копати?
З повагою,
Steve242
До повідомлення додано файл. Розмір - 21Kb
Відповідь:
штатний perfmonitor вінди показав, що на Термінальнику йде адова завантаження системного диска C:\.
Все інше: Пам'ять, CPU - на обох серверах (термінальник і скигля) ніяких аномальних сплесків не відображає.
я створив RAMdrive на 2Gb (з 12Gb, що є на термінальному сервері фізично) і намагаюся перенаправити туди tempові системні каталоги профілів користувачів терміналу.
поки що якось так.
Питання: Ще раз, про Конфлікт блокувань при виконанні транзакції
Відповідь:
Запитання: Блокування при підписці на РТіУ
Відповідь:
Питання: Linux, Postgres, Роздріб 2.0.5.1 Україна РИБ по магазину - помилка блокування...
Може, хтось підкаже? Налаштовую обмін по магазину. Все нормально працює, руками виходить робити обмін. 4-5 повідомлень надсилаються. Потім налаштовую сценарій за розкладом і починаються гойдалки... Перша помилка:
"Помилка запису даних у файл повідомлення обміну: (Обробка.КонвертаціяОб'єктівРозподіленихІнформаційнихБаз.МодульОб'єкта()): Error calling context method (ЗаписатиЗміни): Lock conflict during the transaction:
Maximum idle time for lock access has been exceeded due to the wait for the session"
Усі наступні:
"Помилка запису даних у файл повідомлення обміну: (Обробка.КонвертаціяОб'єктівРозподіленихІнформаційнихБаз.МодульОб'єкта()): Помилка при виклику методу контексту (ЗаписатиЗміни): Конфлікт блокувань при виконанні транзакції:
Перевищено максимальний час очікування блокування"
Ані переіндексація, ані закриття сеансів не допомагає. Блокувань у 1С не варто. Допомагає лише видалення бази та створення знову.
Як я зрозумів блокування відбувається в СУБД? Використовую Postgres на Linux, 1 база, 4Гб оперативної пам'яті. Якщо я маю рацію, питання - Неправильно налаштований Postgress або брак пам'яті? Чи може взагалі проблема не в цьому?
Відповідь:() Так то свіжий – це 8.3.10.2375
Питання: Помилка блокування при очищенні регістру відомостей
Запитом вибираю записи РС, далі:
Набір Записів. Завантажити (Результат Запиту. Вивантажити ()); Набір Записів. Очистити (); Набір Записів. Записати ();
При спробі записати вивалюється помилка:
"Конфлікт блокувань під час виконання транзакції".
Регістр не періодичний, реєстратор не підпорядкований.
У чому причина помилки?
Відповідь:() "Я чомусь був упевнений, що відбір застосовується тільки в момент читання, а записується відповідно те, що потрапило у відбір." - де в тебе в коді хоч раз використовується слово відбір?
