Не міг записати зміни для передачі в розподілену базу, звернувшись на підтримку 1с, запропонували наступне. У мене вирішилося просто перезавантаженням сервера додатків та сервера з SQL. Взагалі можна поставити галочку «Блокування регламентних
завдань включено»
Теж допомогло без перезавантаження.

Регламентні операції на рівні СУБД для MS SQL Server

Інструкція щодо виконання регламентних операцій на рівні СУБД.

Інформація застосовна до клієнт-серверного варіанта 1С:Підприємства 8 під час використання СУБД MS SQL Server.

Загальні відомості

Однією з найпоширеніших причин неоптимальної роботи системи є неправильне чи несвоєчасне виконання регламентних операцій лише на рівні СУБД. Особливо важливо виконувати ці регламентні процедури у великих інформаційних системах, які працюють під значним навантаженням та обслуговують одночасно велику кількість користувачів. Специфіка таких систем у тому, що звичайних дій, що виконуються СУБД автоматично (на підставі налаштувань) недостатньо для ефективної роботи.

Якщо в працюючій системі спостерігаються будь-які симптоми проблем з продуктивністю, слід перевірити, що в системі правильно налаштовані та регулярно виконуються всі рекомендовані регламентні операції на рівні СУБД.

Виконання регламентних процедур має бути автоматизовано. Для автоматизації цих операцій рекомендується використовувати вбудований засіб MS SQL Server: Maintenance Plan. Існують також інші способи автоматизації виконання цих процедур. У цій статті для кожної регламентної процедури наведено приклад її налаштування за допомогою Maintenance Plan для MS SQL Server 2005.

Рекомендується регулярно контролювати своєчасність та правильність виконання даних регламентних процедур.

Оновлення статистик

MS SQL Server будує план запиту виходячи з статистичної інформації про розподіл значень індексах і таблицях. Статистична інформація збирається на основі частини (зразка) даних та автоматично оновлюється при зміні цих даних. Іноді цього виявляється недостатньо у тому, що MS SQL Server стабільно будував найоптимальніший план виконання всіх запитів.

У цьому випадку можливий прояв проблем із продуктивністю запитів. У цьому планах запитів спостерігаються характерні ознаки неоптимальної роботи (неоптимальні операції).

Для того щоб гарантувати максимально правильну роботуОптимізатор MS SQL Server рекомендується регулярно оновлювати статистики бази даних MS SQL.

Для оновлення статистик по всіх таблицях бази даних необхідно виконати наступний запит SQL:

exec sp_msforeachtable N"UPDATE STATISTICS ? WITH FULLSCAN"

Оновлення статистик не призводить до блокування таблиць і не заважатиме роботі інших користувачів. Статистика може оновлюватися настільки часто, наскільки це потрібно. Слід враховувати, що навантаження на сервер СУБД під час оновлення статистик зросте, що може негативно вплинути на загальної продуктивностісистеми.

Оптимальна частота оновлення статистик залежить від величини та характеру навантаження на систему та визначається експериментальним шляхом. Рекомендується оновлювати статистики не рідше одного разу на день.

Наведений вище запит оновлює статистику для всіх таблиць бази даних. У реально працюючій системі різні таблиці вимагають різної частоти оновлення статистик. Шляхом аналізу планів запиту можна встановити, які таблиці більше за інших потребують частого оновлення статистик, і налаштувати дві (або більше) різних регламентних процедур: для таблиць, що часто оновлюються, і для всіх інших таблиць. Такий підхід дозволить суттєво знизити час оновлення статистик та вплив процесу оновлення статистики на роботу системи загалом.

Налаштування автоматичного оновлення статистики (MS SQL 2005)

Запустіть MS SQL Server Management Studio та підключіться до сервера СУБД. Відкрийте папку Management та створіть новий планобслуговування:

Створіть субплан (Add Subplan) та назвіть його «Оновлення статистик». Додайте завдання Update Statistics Task з панелі завдань:

Налаштуйте розклад оновлення статистики. Рекомендується оновлювати статистики не рідше одного разу на день. При необхідності частота оновлення статистики може бути збільшена.

Налаштуйте параметри завдання. Для цього слід двічі клацнути на завдання в правому нижньому куті вікна. У формі вкажіть ім'я базу даних (або кілька баз даних) для яких буде виконуватися оновлення статистик. Крім цього, ви можете вказати для яких таблиць оновлювати статистики (якщо точно невідомо, які таблиці потрібно вказати, то встановлюйте значення All).

Оновлення статистик необхідно проводити з увімкненою опцією Full Scan.

Збережіть план. Після настання вказаного у розкладі терміну оновлення статистик буде запущено автоматично.

Очищення процедурного КЕШу

Оптимізатор MS SQL Server кешує плани запитів їхнього повторного виконання. Це робиться для того, щоб заощаджувати час, що витрачається на компіляцію запиту в тому випадку, якщо такий запит вже виконувався і його відомий план.

Можлива ситуація, коли MS SQL Server, орієнтуючись на застарілу статистичну інформацію, побудує неоптимальний план запиту. Цей план буде збережено у процедурному КЕШі та використаний при повторному виклику такого ж запиту. Якщо Ви оновили статистику, але не очистили процедурний кеш, SQL Server може вибрати старий (неоптимальний) план запиту з КЕШу замість того, щоб побудувати новий (більш оптимальний) план.

Для очищення процедурного кешу MS SQL Server необхідно виконати наступний SQL запит:

Цей запит слід виконувати безпосередньо після оновлення статистики. Відповідно, частота його виконання повинна співпадати із частотою оновлення статистики.

Налаштування очищення процедурного кешу (MS SQL 2005)

Оскільки процедурний КЕШ необхідно очищати при кожному оновленні статистики, цю операцію рекомендується додати до вже створеного субплану «Оновлення статистик». Для цього слід відкрити субплан і додати до його схеми завдання Execute T-SQL Statement Task. Потім слід з'єднати завдання Update Statistics Task стрілочкою з новим завданням.

У тексті створеного завдання Execute T-SQL Statement Task слід вказати запит «DBCC FREEPROCCACHE»:

Дефрагментація індексів

p align="justify"> При інтенсивній роботі з таблицями бази даних виникає ефект фрагментації індексів, який може призвести до зниження ефективності роботи запитів.

sp_msforeachtable N"DBCC INDEXDEFRAG (<имя базы данных>, ""?"")"

Дефрагментація індексів не блокує таблиці, і не заважатиме роботі інших користувачів, проте створює додаткове навантаження на SQL Server. Оптимальна частота виконання цієї регламентної процедури повинна підбиратися відповідно до навантаження на систему та ефекту, що отримується від дефрагментації. Рекомендується виконувати дефрагментацію індексів не рідше ніж один раз на тиждень.

Можливе виконання дефрагментації однієї чи кількох таблиць, а чи не всім таблиць бази даних.

Налаштування дефрагментації індексів (MS SQL 2005)

У раніше створеному плані обслуговування створіть новий субплан з ім'ям «Реіндексація». Додайте до нього завдання Rebuild Index Task:

Вкажіть розклад виконання для завдання дефрагментації індексів. Рекомендується виконувати завдання не рідше одного разу на тиждень, а за високої мінливості даних у базі ще частіше – до одного разу на день.

Реіндексація таблиць бази даних

Реіндексація таблиць включає повну перебудову індексів таблиць бази даних, що призводить до суттєвої оптимізації їхньої роботи. Рекомендується виконувати регулярну переіндексацію таблиць бази даних. Для реіндексації всіх таблиць бази даних необхідно виконати наступний запит SQL:

sp_msforeachtable N"DBCC DBREINDEX ("?"")"

Реіндексація таблиць блокує їх весь час своєї роботи, що може суттєво позначитися роботі користувачів. У зв'язку з цим реіндексацію рекомендується виконувати під час мінімального завантаження системи.

Після виконання реіндексації не потрібно робити дефрагментацію індексів.

Налаштування реіндексації таблиць (MS SQL 2005)

У раніше створеному плані обслуговування створіть новий субплан під назвою «Дефрагментація індексів». Додайте до нього завдання Rebuild Index Task:

Вкажіть розклад виконання для завдання реіндексування таблиць. Рекомендується виконувати завдання під час мінімального навантаження на систему, не менше одного разу на тиждень.

Налаштуйте завдання, вказавши базу даних (або кілька баз даних) та вибравши необхідні таблиці. Якщо достеменно невідомо, які таблиці слід вказати, то встановлюйте значення All.

Що таке блокування в 1С, навіщо вони потрібні і як уникнути проблем під час роботи з ними

Напевно, багато хто з Вас при використанні інформаційних систем 1С Підприємство (1С 7.7, 1С 8.1, 1С 8.2, 1С 8.3) стикалися з таким явищем, як блокування. Причому, як правило, всі називають це явище по-різному: Блокування 1С, Конфлікт блокувань 1С, Помилки блокувань 1С, Блокування транзакцій 1С та інші назви. Давайте коротко розберемося в тому, що таке блокування (не взаємоблокування), навіщо вони потрібні і як уникнути проблем з ними.

Самі собою блокування (зокрема в 1С та інших системах) корисний інструментщо забезпечує можливість послідовної роботи із загальними ресурсами. Для прикладу, поняття «загальні ресурси» оточує нас у житті, наприклад, поки Ви керуєте автомобілем, ніхто інший не може ним керувати. Отже, автомобіль – загальний ресурс. А другий водій чекає доки Ви приїдете, наприклад, Ваша дружина/чоловік. Ви обидва конкуруєте за загальний ресурс – автомобіль. Хто керуватиме автомобілем у поточний моментВи визначаєте на понятійному рівні, а як нам бути в автоматизованих системах??? Для цього і вигадали інструмент блокування, які забезпечують організацію процесу доступу до спільного ресурсу та визначають чергу. Як правило, в житті, як і в інформаційних системах (1С 7.7, 1С 8.1, 1С 8.2, 1С 8.3), загальних ресурсів дуже багато, тому і блокувань теж багато. Тепер другий важливий момент – як довго чекатиме звільнення вашого автомобіля дружина/чоловік, логічно припустити, що не вічне. Тому для блокувань задається граничний час очікування – інакше час таймууту. Таймаут – це максимальний час очікування конкуруючим учасником (вашої дружини/чоловіка) звільнення загального ресурсу. Далі або він продовжує чекати ще такий самий час, або йде пішки. В інформаційних системах 1С закінчення таймууту закінчується повідомленням "Конфлікт блокувань 1С", "Помилки блокувань 1С", "Блокування транзакцій 1С", "Таймаут при блокуванні".

Важлива деталь, яку слід пам'ятати, блокування (зокрема в 1С) бувають явні (задаються користувачем) і неявні (задаються платформою SQL). У статті ми говоримо про явні блокування, тому вони завжди використовуються в транзакції, звідси виходить, що «Блокування 1С» та «Блокування транзакцій 1С» синоніми.

Ми визначилися, що при перевищенні таймууту користувачеві виводитиметься повідомлення про помилку, сам процес очікування для нього виглядає залипанням екрану інформаційної системи 1С. На ймовірність появи повідомлення про таймаут (помилки 1С у користувача) впливають такі показники:

• Безліч блокувань 1С транзакції;
• Тривалість транзакції.

Для мінімізації повідомлень, пов'язаних з помилками блокувань, необхідно або зменшувати множину блокувань (оптимізувати селективність), або зменшувати тривалість транзакцій.
Тепер визначимося яким чином ці показники можна проводити реальної інформаційної системі 1С.

Для зменшення безлічі блокувань:

У 1С: Підприємство 7.7:

Інформаційна система 1С 7.7. для блокувань використовують табличні блокування, які паралізують роботу користувачів. Як правило, понад 50 осіб в одній базі даних не можуть безпомилково працювати, при цьому проблеми можуть з'являтися і в базах даних від 20 користувачів.
Рішення:

• Гнучкі блокування 1С від компанії "Софтпоінт". З їхньою допомогою ви не тільки оптимізуєте безліч блокувань (заміна табличних блокувань на користувацькі), а й прискоріть підбирання, пошуки та звіти.

В 1С:Підприємство 8.x:
Інформаційна система 1С 8.1., 1С 8.2., 1С 8.3. в автоматичному режимі використовує надлишкові блокування виду (REPEATABLEREAD, SERIALIZABLE). Це спричиняє погіршення роботи користувачів від 100.
Рішення:

• Керовані блокування 1С – вбудований засіб платформи 1С для більш селективного налаштування блокувань. Щоб його використати, програміст повинен сам прописати у потрібних місцях коду спеціальні оператори, щоб заблокувати потрібні ( на його думку!) записи у таблицях інформаційної системи;
• Гнучкі блокування 1С – технологія компанії Софтпоінт для заміни стандартних блокувань на користувацькі.

Для зменшення тривалості транзакцій:

Для будь-яких інформаційних систем 1С (1С 7.7., 1С 8.1, 1С 8.2, 1С 8.3) як і інших інформаційних систем застосовується подібні підходи:

Перевірка та правильне налаштування регламентного обслуговуваннябази даних (обслуговування файлів, індексів, статистик, бази тимчасових таблиць, налаштування Windows та SQLServer);

Аналіз та оптимізація важких запитів 1С та SQL (індексний тюнінг, переписування запитів);

Перевірка надмірність транзакцій. У багатьох випадках необґрунтовано транзакцію включають операції не усвідомлюючи, як це вплине на тривалість, а разом з нею на продуктивність.

1. Якщо Ви хочете самостійно розбиратися з технічними проблемами продуктивності 1С (1С 7.7, 1С 8.1, 1С 8.2, 1С 8.3) та інших інформаційних систем , то для Вас унікальний список технічних статей у нашому Альманасі (Блокування та взаємоблокування, велике навантаження на CPU та диски, обслуговування баз даних та індексний тюнінг – лише мала частина технічних матеріалів, які Ви там знайдете).
2. якщо Ви хочете обговорити з нашим експертом проблеми продуктивності або замовити рішення моніторинг продуктивності PerfExpert, то залиште заявку і ми зв'яжемося з Вами у найкоротші терміни.

Всім привіт!

Днями на роботі зіткнувся з проблемою блокувань, а саме стало з'являтися повідомлення "Конфлікт блокувань при виконанні транзакції. Перевищено максимальний час очікування блокування".

Очевидно, що тут немає проблеми взаємоблокувань, просто якийсь сеанс поставив блокування і "забув" прибрати. При цьому проблема загрожувала серйозними наслідками – не проводився документ Реалізації товарів та послуг. В базі одночасно працює близько 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: купівля квитка на літак чи поїзд. Припустимо, ми озвучили свої побажання касиру. Касир повідомляє нам наявність вільних місць, з яких ми можемо вибрати найбільше (якщо їх кілька, звичайно). Поки ми вибираємо і підтверджуємо свою згоду з запропонованим варіантом, ці місця не можуть бути продані будь-кому, тобто. тимчасово блокуються. Якби вони не блокувалися, то на момент підтвердження могла б бути ситуація, коли вибрані нами квитки вже продані. А в цьому випадку цикл вибору може бути непрогнозованою кількістю повторень. Поки що вибираємо місця, а їх уже продали!.. Поки що обираємо інші, і їх уже немає...

Приклад 2: купівля чогось у магазині чи базарі. Підійшли ми до прилавка, вибрали найкрасивіше яблуко із сотні доступних. Вибрали і полізли в кишеню по гроші. Як буде виглядати, якщо в той момент, поки ми рахуємо гроші, саме обране нами яблуко буде продано покупцеві, що підійшов пізніше нас?

Таким чином, саме собою блокування - це потрібне і корисне явище. Саме завдяки блокуванню ми гарантуємо виконання дій за один етап. А до негативу найчастіше наводить не найвдаліша реалізація програмного забезпечення, коли, наприклад:

• блокується надмірна кількість об'єктів (квитків, яблук);
• час блокування невиправдано розтягується.

НАДЛИВНІ БЛОКУВАННЯ У ТИПОВИХ КОНФІГУРАЦІЯХ 1С

на великих проектах, як правило, ми використовуємо «1С:Підприємство». Тому практичні рекомендаціївирішення проблем блокувань ми спробуємо описати з прикладу зв'язки «1С:Підприємство»+MS-SQL.

8-е покоління 1С:Підприємства забезпечує дуже і дуже непогану паралельність використання. Одночасно з однією конфігурацією (тобто на одній базі) при нормальних серверах та каналах зв'язку може працювати велика кількістькористувачів. Наприклад, сотні комірників оформляють видачі чи надходження товарів, економісти одночасно вважають витрати на оплату праці за різним підрозділам, розрахунники проводять розрахунок та нарахування зарплати і т.д.

Але є причина, через які існує думка про протилежне - міф про те, що при інтенсивному одночасному використанні працювати з рішеннями на базі 1С:Підприємства некомфортно чи неможливо. Адже як тільки типові рішення під 1С:Підприємство починають використовувати сотні користувачів на промислових масштабах, все частіше на екрані з'являється віконце з гордим написом: «Помилка під час виклику методу контексту (Записати): Конфлікт блокування при виконанні транзакції: ...» і далі в Залежно від виду застосовуваного SQL-сервера щось типу «Microsoft OLE DB Provider for SQL Server: Lock request time out period exceeded. ...».

Майже всі типові рішення в пропонованій «із коробки» реалізації налаштовані на автоматичний режим керування блокуванням. "Автоматичний" тут можна сприймати як "параноїдальний". Про всяк випадок при проведенні будь-якого документа блокуємо все, що хоч якось з ним може бути пов'язано. Ось і виходить, що коли один користувач щось проводить (а іноді й просто записує), решта може тільки чекати.

Висловлю свою думку, чому 1С вирішила не налаштовувати свої типові рішення під високу паралельність використання. Трудовитрати на таке доопрацювання не високі - кілька "людини", що за масштабами 1С не значимо. Мені здається причина в іншому.

По-перше, така доопрацювання значно ускладнює обробники проведення всіх документів. Отже для тих споживачів, хто використовує 1С на невеликих завданнях, без будь-якого виграшу буде лише недолік - складність доопрацювання типової конфігурації ускладниться. Статистика в той же час нагадує, яка категорія клієнтів є основною годівницею для 1С.

Друга причина зарита в типових базових налаштуваннях SQL-серверів, наприклад, MS-SQL, який все ще використовується найчастіше. Так повелося, що пріоритети в налаштуваннях віддані економії оперативної пам'яті серверів, а не скорочення блокувань. Це призводить до того, що при необхідності заблокувати кілька рядків SQL-сервер приймає «економне» для пам'яті та процесора рішення – заблокувати відразу всю таблицю!

Ось ці недоробки типових рішеньабо специфіку налаштування сервера баз даних часто і ототожнюють з проблемами, викликаними блокуваннями. В результаті технічні недоробки призводять до дуже значних організаційним проблемам. Адже якщо співробітнику дати привід відволіктися від роботи або обґрунтувати, чому роботу не можна було зробити – ефективно працюватиме меншість. Ну а повідомлення про блокування транзакцій або «гальмуюча» програма - ідеальне обґрунтування, чому не можна було щось зробити.

РЕКОМЕНДАЦІЇ ЩОДО УСУНЕННЯ НАДЛИВНИХ БЛОКУВАНЬ ДЛЯ 1С:ПІДПРИЄМСТВА

Що ж робити, якщо вирішення проблем надлишкових блокувань настільки важливе?

На завершальній стадії застосування всіх великих комплексів потрібно провести тонку доопрацювання щодо усунення зайвих блокувань транзакцій. Вкрай важливо вирішити проблеми, які можуть виникати через недостатньо опрацьовані умови блокування або методики реалізації.

Т.к. дана операціяВкрай важлива, її доводиться виконувати постійно. Тому для спрощення проведення подібного доопрацювання ми виробили низку основних рекомендацій, яких намагаємось дотримуватись. Рекомендацій, отриманих та перевірених на досвіді значної кількості масштабних впроваджень.

1. Якщо СУБД або система розробки (наприклад, 1С:Підприємство) за замовчуванням використовує автоматичний режим блокування даних, відмовтеся від автоматичного керуванняблокування. Налаштуйте правила блокування самостійно, опишіть критерії блокування цілих таблиць або окремих рядків.
2. Під час розробки програми завжди, коли це можливо, звертайтеся до таблиць в одному порядку.
3. Постарайтеся не писати в ту саму таблицю кілька разів у межах однієї транзакції. Якщо це складно, то хоча б мінімізуйте проміжок часу між першою та останньою операцією запису.
4. Проведіть аналіз можливості вимкнення ескалації блокувань на рівні SQL-сервера.
5. Уважно інформуйте користувачів про причини неможливості виконання будь-яких дій, якщо вони обумовлені блокуваннями. Давайте доступні та зрозумілі рекомендації, що робити далі.

Якщо уважно подивитися на рекомендації, стає зрозумілим, що подібне відпрацювання доречне не тільки для 1С:Підприємства, але для будь-яких систем. Абсолютно не важливо якою мовою вони написані і з якою працюють сервером БД. Більшість рекомендацій мають універсальний характер, а тому однаково справедливі і при використанні 1С:Підприємства, і для «самописних» програм чи інших «коробкових» ERP-систем.

P.S. А Ви знали про те, що ми пропонуємо професійну допомогу з оновленням 1С кращою ціною?

Теги для пошуку:

• Блокування транзакцій
• Усунення блокувань
• Блокування 1С
• Блокування
• Конфлікт блокувань
• Конфлікт блокувань під час транзакції

У розрахованих на багато користувачів системах важливу рольграє правильна організаціяструктури та налаштування блокувань. Якщо її немає, користувачам доведеться часто стикатися з помилками, спричиненими конкуренцією за певні ресурси системи. Але є проблема конфлікту блокувань, знайома багатьом користувачам. Чому виникає конфлікт блокувань 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С. Після таких дій необхідно знайти вразливі місця у системі, оптимізувати конфігурацію чи роботу працівників. Використовувати подібні заходи на постійній основі за регулярних конфліктів блокувань на транзакціях не рекомендується.