Не рядко, когато работите в 1C, се появява грешката „Конфликт на заключване при изпълнение на транзакции: Максималното време за изчакване за предоставяне на заключване е превишено“. Същността му се крие във факта, че няколко сесии се опитват едновременно да извършват подобни действия, засягащи един и същ ресурс. Днес ще разберем как да поправим тази грешка.

Голям брой операции

Първата стъпка при търсене на причини трябва да бъде да се изясни колко едновременни потребители са в това информационна база, което създава подобна грешка. Както знаем, максималният им брой може да бъде доста голям. Това са хиляда и пет хиляди.

Механизмът на заключванията и транзакциите е описан в ръководството на разработчика. Те се използват, когато няколко сесии имат достъп до едни и същи данни по едно и също време. Логично е едни и същи данни да не могат да бъдат променяни от различни потребители в един и същи момент.

Трябва също да проверите дали някой от потребителите е започнал обработка за масова промяна на данните. Може да бъде като , приключване на месеца и други подобни. В този случай след края на обработката грешката ще изчезне сама.

Планирани задачи

Не е необичайно причината за грешката да се крие в това, което обработва голямо количество данни. Препоръчително е да правите такива неща през нощта. Планирайте изпълнението на такива планирани задачи в извънработно време.

По този начин и двамата потребители ще работят в стабилна система, а самите планирани задачи ще бъдат изпълнени успешно, тъй като вероятността от конфликти с потребителските сесии ще намалее.

"Заседнали сесии"

Проблемът с „окачените сесии“ на потребителите е познат на почти всеки, който се е сблъсквал с услугата 1C. Потребителят може да е напуснал програмата отдавна или да е затворил документ, но неговата сесия все още остава в системата. Проблемът най-често е единичен и е достатъчно да приключите такава сесия през администраторската конзола. Същите проблеми могат да възникнат и при фонови задачи.

Според многобройни коментари в интернет подобни ситуации са по-чести при използване на ключове за сигурност на мрежата. Ако ситуацията с "окачени сесии" се повтаря системно, това е причината за щателна проверка и поддръжка на системата и сървърите (ако базата е клиент-сървър).

Грешки при писане на конфигурация

Всички типични конфигурации се разработват от квалифицирани специалисти и експерти. Всяка система е внимателно тествана и оптимизирана за по-бърза и коректна работа в нея.

В тази връзка причината за грешката може да се крие в неоптимален код, написан от разработчик на трета страна. Това може да е "тежка" заявка, която ще блокира данни за дълъг период от време. Също така не е необичайно да се изграждат алгоритми с ниска производителност и нарушаване на логиката.

Много е вероятно конфликтът при заключване да е възникнал именно поради грешки на разработчиците, ако е възникнал след актуализиране на програмата. За да проверите, можете просто да „превърнете“ подобренията или да преработите кода.

Не можах да запиша промените за прехвърляне в разпределена база данни, свързах се с поддръжката на 1c и предложих следното. Реших просто да рестартирам сървъра на приложения и сървъра с SQL. По принцип можете да поставите отметка в квадратчето „Блокирането е планирано
включени задачи"
Помогна и без рестартиране.

Планирани операции на ниво СУБД за MS SQL сървър

Инструкции за извършване на рутинни операции на ниво СУБД.

Информацията е приложима за версията клиент-сървър на 1C:Enterprise 8 при използване на СУБД на MS SQL Server.

Главна информация

Една от най-честите причини за неоптимална работа на системата е неправилно или ненавременно изпълнение на рутинни операции на ниво СУБД. Особено важно е тези рутинни процедури да се спазват в голяма степен информационни системиах, които работят при значително натоварване и обслужват голям брой потребители едновременно. Спецификата на такива системи е, че обичайните действия, извършвани автоматично от СУБД (на базата на настройки), не са достатъчни за ефективна работа.

Ако работеща система показва някакви симптоми на проблеми с производителността, трябва да проверите дали системата е правилно конфигурирана и редовно извършва цялата препоръчителна рутинна поддръжка на ниво СУБД.

Изпълнението на рутинните процедури трябва да бъде автоматизирано. За автоматизиране на тези операции се препоръчва използването на вградените инструменти на MS SQL Server: План за поддръжка. Има и други начини за автоматизиране на тези процедури. В тази статия за всяка планирана процедура е даден пример за нейната конфигурация с помощта на плана за поддръжка за MS SQL Server 2005.

Препоръчва се редовно да се следи навременността и коректността на изпълнението на тези рутинни процедури.

Актуализация на статистиката

MS SQL Server изгражда план за заявка въз основа на статистическа информация за разпределението на стойностите в индекси и таблици. Статистическата информация се събира на базата на част (извадка) от данни и се актуализира автоматично при промяна на тези данни. Понякога това не е достатъчно, за да може MS SQL Server последователно да изгради най-оптималния план за изпълнение на всички заявки.

В този случай може да възникнат проблеми с производителността на заявката. В същото време в плановете за заявка се наблюдават характерни признаци на неоптимална работа (неоптимални операции).

За да се гарантира най-правилната работа на оптимизатора на MS SQL Server, се препоръчва редовно да се актуализира статистиката на MS SQL базата данни.

За да актуализирате статистиката за всички таблици на базата данни, трябва да изпълните следната SQL заявка:

exec sp_msforeachtable N"АКТУАЛИЗИРАНЕ НА СТАТИСТИКАТА? С ПЪЛЕН СКАН"

Актуализирането на статистиката не води до заключване на таблици и няма да пречи на работата на други потребители. Статистиката може да се актуализира толкова често, колкото е необходимо. Имайте предвид, че натоварването на сървъра на СУБД по време на актуализацията на статистиката ще се увеличи, което може да се отрази неблагоприятно на цялостната производителност на системата.

Оптималната честота на актуализиране на статистиката зависи от големината и естеството на натоварването на системата и се определя експериментално. Препоръчително е да актуализирате статистиката поне веднъж на ден.

Горната заявка актуализира статистическите данни за всички таблици в базата данни. В реална система различните таблици изискват различни скорости на актуализиране на статистическите данни. Чрез анализиране на плановете за заявки можете да определите кои таблици се нуждаят от най-честите актуализации на статистиката и да настроите две (или повече) различни рутинни процедури: за често актуализирани таблици и за всички останали таблици. Този подход значително ще намали времето за актуализиране на статистиката и въздействието на процеса на актуализиране на статистиката върху работата на системата като цяло.

Конфигуриране на автоматична актуализация на статистиката (MS SQL 2005)

Стартирайте MS SQL Server Management Studio и се свържете със сървъра на DBMS. Отворете папката Управление и създайте нов планобслужване:

Създайте подплан (Добавяне на подплан) и го наречете „Актуализация на статистиката“. Добавете задачата за актуализиране на статистиката към нея от лентата на задачите:

Настройте график за актуализиране на статистиката. Препоръчително е да актуализирате статистиката поне веднъж на ден. Ако е необходимо, честотата на актуализиране на статистиката може да бъде увеличена.

Задайте настройките на задачата. За да направите това, щракнете двукратно върху задачата в долния десен ъгъл на прозореца. Във формата, която се показва, посочете името на базата данни (или няколко бази данни), за които ще се актуализира статистиката. Освен това можете да посочите за кои таблици да актуализирате статистиката (ако не знаете точно кои таблици трябва да посочите, тогава задайте стойността на Всички).

Актуализирането на статистическите данни трябва да се извършва с активирана опция за пълно сканиране.

Запазете създадения план. Когато настъпи часът, посочен в графика, статистиката ще се актуализира автоматично.

Изчистване на процедурния кеш

Оптимизаторът на MS SQL Server кешира планове на заявки за повторно изпълнение. Това се прави, за да се спести време за компилиране на заявка, ако същата заявка вече е била изпълнена и нейният план е известен.

Възможно е MS SQL Server, разчитайки на остаряла статистическа информация, да изгради неоптимален план за заявка. Този план ще бъде съхранен в процедурния кеш и ще се използва, когато същата заявка бъде извикана отново. Ако сте актуализирали статистическите данни, но не сте изчистили процедурния кеш, тогава SQL Server може да избере стария (неоптимален) план за заявка от кеша, вместо да изгради нов (по-добър) план.

За да изчистите процедурния кеш на MS SQL Server, трябва да изпълните следната SQL заявка:

Тази заявка трябва да се стартира веднага след актуализиране на статистиката. Съответно честотата на неговото изпълнение трябва да съответства на честотата на актуализиране на статистиката.

Конфигуриране на процедурно изчистване на кеша (MS SQL 2005)

Тъй като процедурният кеш трябва да се изчиства всеки път, когато статистиката се актуализира, се препоръчва тази операция да се добави към вече създадения подплан "Актуализиране на статистиката". За да направите това, отворете подплана и добавете задачата Изпълнение на T-SQL оператор към неговата схема. След това трябва да свържете задачата за актуализиране на статистиката със стрелка към новата задача.

В текста на създадената задача за изпълнение на T-SQL оператор трябва да посочите заявката "DBCC FREEPROCCACHE":

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

Когато работите интензивно с таблици на база данни, възниква ефектът на фрагментиране на индекси, което може да доведе до намаляване на ефективността на заявките.

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

Дефрагментирането на индекса не блокира таблици и няма да пречи на работата на други потребители, но създава допълнително натоварване на SQL Server. Оптималната честота на извършване на тази рутинна процедура трябва да бъде избрана в съответствие с натоварването на системата и ефекта, получен от дефрагментацията. Препоръчваме ви да дефрагментирате индексите си поне веднъж седмично.

Възможно е да дефрагментирате една или повече таблици, а не всички таблици в базата данни.

Конфигуриране на дефрагментиране на индекс (MS SQL 2005)

В предварително създадения план за поддръжка създайте нов подплан с име "Reindex". Добавете Rebuild Index Task към него:

Задайте графика за изпълнение на задачата за дефрагментиране на индекса. Препоръчително е задачата да се изпълнява поне веднъж седмично, а ако данните в базата данни са силно нестабилни, дори по-често - до веднъж на ден.

Преиндексиране на таблици в базата данни

Преиндексирането на таблици включва цялостно възстановяване на индексите на таблици на базата данни, което води до значително оптимизиране на тяхната работа. Препоръчително е да извършвате редовно преиндексиране на таблиците на базата данни. За да преиндексирате всички таблици на базата данни, трябва да изпълните следната SQL заявка:

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

Преиндексирането на таблици ги блокира за времето на тяхната работа, което може значително да повлияе на работата на потребителите. В тази връзка се препоръчва преиндексирането да се извършва по време на минимално натоварване на системата.

След повторното индексиране няма нужда от дефрагментиране на индексите.

Настройка на преиндексиране на таблица (MS SQL 2005)

В предварително създадения план за поддръжка създайте нов подплан с име "Дефрагментация на индекса". Добавете задача за възстановяване на индекс към него:

Задайте графика за изпълнение на задачата за преиндексиране на таблицата. Препоръчително е задачата да се изпълнява при минимално натоварване на системата, поне веднъж седмично.

Персонализирайте задачата, като посочите базата данни (или множество бази данни) и изберете необходимите таблици. Ако не знаете точно кои таблици да посочите, задайте стойността на Всички.

„Конфликт на заключване по време на изпълнение на транзакция: Максималното време за изчакване за предоставяне на заключване е превишено“ е доста често срещана грешка в 1C 8.3 и 8.2, свързана с конкуренцията за използване на ресурси в системата.

Системата 1C позволява на голям брой потребители да работят паралелно: както показват тестовете за натоварване, днес този брой не е ограничен до пет хиляди потребители, работещи едновременно в системата. Въпреки това, за да може базата данни 1C 8 едновременно да поддържа голям брой потребители, конфигурацията трябва да бъде правилно проектирана.

Вземете 267 1C видео уроци безплатно:

Извършване на голям брой операции

Вероятно е някой потребител да е започнал, например, за дълъг период от време в една транзакция. Архитектурата 1C 8.3 предполага, че системата не позволява промяна на данните, които се използват в една транзакция от друг потребител, и ги блокира.

Може би това е временна грешка, която ще спре да се появява, когато друг потребител извърши действия в системата. Ако тази грешка се появява често, най-вероятно е нещо друго.

Грешка в конфигурацията

В допълнение към грешките в кода, често има методично неправилни решения. Например, - то само по себе си предполага последователно държане на документи. Пакетното отчитане може да бъде заменено с RAUS – по този начин ще увеличите сериозно производителността на системата.

Как да коригирам тази грешка в 1C 8.3?

Във всеки случай появата на грешка „Конфликт за заключване по време на изпълнение на транзакция“ показва необходимостта от проверка на системата, особено за средни и големи информационни системи в режим клиент-сървър (MS SQL, PostgreSQL и др.). Ако това се пренебрегне на ранен етап, може да има необратими последици по-късно, когато работата на системата е особено важна (през отчетния период).

За одит и коригиране на грешки е най-добре да изберете надежден партньор. Просто ни се обадете и ние ще решим всеки ваш проблем възможно най-скоро. Подробности на страницата.

Когато стотици потребители работят с програми и данни едновременно, има проблеми, присъщи само на широкомащабните решения. Говорим за проблеми, причинени от заключване на данни.

Понякога потребителите разбират за заключвания от съобщения, които показват невъзможност за запис на данни или извършване на някаква друга операция. Понякога поради много значителен спад в производителността на програмата (например, когато времето, необходимо за извършване на операция, нараства десетки или стотици пъти).

Проблемите, причинени от блокирането, нямат общо решение. Затова ще се опитаме да анализираме причините за подобни проблеми и да систематизираме вариантите за тяхното разрешаване.

ПРИЧИНИ ЗА БЛОКИРАНЕ НА ТРАНЗАКЦИИ

Нека първо си спомним какво представляват ключалките и в същото време ще разберем дали са необходими. Нека разгледаме няколко класически примера за блокиране, които срещаме в живота.

Пример 1: Закупуване на билет за самолет или влак. Да предположим, че сме изразили желанията си на касата. Касиерката ни казва наличността на места, от които можем да изберем това, което ни харесва най-много (ако са няколко, разбира се). Докато не изберем и потвърдим съгласието си с предложения вариант, тези места не могат да бъдат продадени на друг, т.е. временно блокиран. Ако не са били блокирани, тогава до момента на потвърждение може да има ситуация, при която избраните от нас билети вече са продадени. И в този случай цикълът на подбор може да бъде непредсказуем брой повторения. Докато избираме места, но те вече са продадени! .. Докато избираме други, а те вече ги няма...

Пример 2: купуване на нещо в магазин или пазар. Качихме се до гишето, избрахме най-красивата ябълка от стоте налични. Избраха и бръкнаха в джоба си за пари. Как ще изглежда, ако в този момент, докато броим парите, ябълката, която сме избрали, бъде продадена на купувача, който се появи по-късно от нас?

Следователно блокирането само по себе си е необходимо и полезно явление. Благодарение на блокирането ние гарантираме изпълнението на действията на един етап. И най-често не най-успешното изпълнение води до негатив софтуеркогато например:

• блокиран е прекомерен брой обекти (билети, ябълки);
• времето за блокиране се удължава неоправдано.

ПРЕКРАСНО БЛОКИРАНЕ В ТИПИЧНИ 1C КОНФИГУРАЦИИ

При големи проекти, като правило, използваме 1C: Enterprise. Така практически съветиЩе се опитаме да опишем решенията на проблемите с блокирането, като използваме примера на пакета 1C:Enterprise + MS-SQL.

8-то поколение на 1C:Enterprise осигурява много, много добър паралелизъм на използване. Едновременно с една конфигурация (тоест на една и съща база), с нормални сървъри и комуникационни канали, може да работи страхотно количествопотребители. Например, стотици складове обработват издаването или получаването на стоки, икономистите едновременно изчисляват разходите за заплати за различни отдели, счетоводителите изчисляват и изчисляват заплатите и т.н.

Но има причина да има мнение за обратното - митът, че при интензивна едновременна употреба работата с решения, базирани на 1C: Enterprise е неудобна или невъзможна. В крайна сметка, веднага щом стандартните решения за 1C:Enterprise започнат да се използват от стотици потребители на индустриален мащаб, все по-често на екрана се появява прозорец с горд надпис: „Грешка при извикване на контекстния метод (Запис): Конфликт на заключване по време на изпълнение на транзакция: ...“ и по-нататък, в зависимост от типа на използвания SQL сървър, нещо като „Доставчик на Microsoft OLE DB за SQL Server: Времето за изчакване на заявка за заключване е превишено. ...".

Почти всички стандартни решения в предложената "извън кутия" реализация са конфигурирани за автоматично управление на заключване. "Автоматично" тук може да се приеме като "параноично". За всеки случай, когато провеждаме някакъв документ, ние блокираме всичко, което може по някакъв начин да бъде свързано с него. Така се оказва, че когато един потребител харчи нещо (а понякога просто пише), останалите могат само да чакат.

Ще изразя мнението си защо 1C реши да не персонализира стандартните си решения за висок паралелизъм на използване. Разходите за труд за такова усъвършенстване не са високи - няколко "човеко-месеца", което не е значително по отношение на мащаба 1C. Мисля, че причината е друга.

Първо, такова усъвършенстване значително усложнява процесорите за публикуване на всички документи. Това означава, че за тези потребители, които използват 1C за малки задачи, без никаква печалба ще има само недостатък - сложността на финализирането на типична конфигурация ще стане по-сложна. В същото време статистиката показва коя категория клиенти е основният захранващ източник за 1C ...

Втората причина е заровена в типичните основни настройки на SQL сървърите, например MS-SQL, който все още се използва по-често от други. Така се случи, че приоритетите в настройките са дадени на запазването на RAM на сървъра, а не на намаляването на блокирането. Това води до факта, че ако е необходимо да се заключат няколко реда, SQL сървърът взема „икономично“ решение за паметта и процесора - да заключи цялата таблица наведнъж!..

Ето и недостатъците стандартни решенияили спецификата на използваната настройка на сървъра на базата данни често се смесва с проблеми, причинени от заключвания. В резултат на това техническите недостатъци водят до много значителни организационни проблеми. В края на краищата, ако на служителя е дадена причина да бъде разсеян от работата или оправдано защо работата не може да бъде свършена, малцинство ще работи ефективно. Е, съобщение за блокиране на транзакции или програма за „забавяне“ е идеално оправдание защо нищо не може да се направи.

ПРЕПОРЪКИ ЗА елиминиране на прекомерното блокиране ЗА 1С:ПРЕДПРИЯТИЕ

Какво да направите, ако решаването на проблемите с прекомерното блокиране е толкова важно?

На последния етап от внедряването на всички големи комплекси е необходимо да се извърши фино усъвършенстване, за да се премахнат ненужните заключвания на транзакции. От решаващо значение е да се разрешат проблеми, които могат да възникнат от недостатъчно разработени блокиращи условия или методология на прилагане.

Защото Тази операция е изключително важна, тя трябва да се извършва постоянно. Ето защо, за да опростим прилагането на такова усъвършенстване, ние разработихме редица основни препоръки, към които се опитваме да се придържаме. Получени и тествани препоръки върху опита на значителен брой мащабни реализации.

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

Ако се вгледате внимателно в препоръките, става ясно, че такава разработка е подходяща не само за 1C:Enterprise, но и за всякакви системи. Няма значение на какъв език са написани и с какъв сървър на база данни работят. Повечето от препоръките са от универсален характер и следователно са еднакво валидни при използване на 1C: Enterprise, както и за „самописни“ програми или други „опаковани“ ERP системи.

P.S. Знаете ли, че ние предлагаме професионална помощ при актуализиране на 1C на най-добра цена?

• Заключване на транзакции
• Премахване на блокажи
• Блокиране на 1C
• блокиране
• Конфликт за заключване
• Конфликт на заключване по време на изпълнение на транзакция

Какво представляват бравите в 1C, защо са необходими и как да избегнем проблеми при работа с тях

Със сигурност много от вас, когато използват информационни системи 1C Enterprise (1C 7.7, 1C 8.1, 1C 8.2, 1C 8.3), са се сблъсквали с такъв феномен като блокиране. Освен това, като правило, всеки нарича това явление по различен начин: „1C брави“, „1C lock konflikt“, „1C lock errors“, „1C lock locks“ и други имена. Нека накратко да разберем какво представляват заключванията (а не задънените), защо са необходими и как да избегнем проблеми при работа с тях.

Самите ключалки (включително в 1C и в други системи) полезен инструмент, което предоставя възможност за последователна работа със споделени ресурси. Например концепцията за „споделени ресурси“ ни заобикаля в живота, например, докато шофирате кола, никой друг не може да я кара. Следователно колата е споделен ресурс. И вторият шофьор ви чака да пристигнете, например, вашата съпруга / съпруг. И двамата се състезавате за общ ресурс – кола. Кой ще кара колата в момента вие определяте на концептуално ниво, но как трябва да бъдем ние автоматизирани системи??? За да направят това, те измислиха инструмент блокиране, които организират процеса на достъп до споделен ресурс и дефинират опашка. По правило в живота, както и в информационните системи (1C 7.7, 1C 8.1, 1C 8.2, 1C 8.3), има много общи ресурси и следователно има и много ключалки. Сега второ важен момент- колко време съпругата/съпругът ще чака пускането на колата ви, логично е да се предположи, че няма да продължи вечно. Следователно за заключванията е зададено ограничение за изчакване - в противен случай времето за изчакване. Времето за изчакване е максималното време, през което конкурентен участник (вашата съпруга/съпруг) може да изчака освобождаването на споделен ресурс. След това или продължава да чака същото време, или тръгва пеша. В информационните системи 1C изтичането на времето за изчакване завършва със съобщението „Конфликт при заключване на 1C“, „Грешки при заключване на 1C“, „Заключване на транзакциите на 1C“, „Време за изчакване при заключване“.

Важна подробност, която също трябва да се помни, е, че заключванията (по-специално в 1C) са явни (задавани от потребителя) и имплицитни (задавани от SQL платформата). В статията говорим за изрични заключвания, така че те винаги се използват в транзакция, откъдето се оказва, че "1C Lock" и "1C Transaction Lock" са синоними.

Решихме, че когато времето за изчакване бъде превишено, на потребителя се показва съобщение за грешка, самият процес на изчакване изглежда за него като лепкав екран на информационната система 1C. Следните индикатори влияят на вероятността от съобщение за изчакване (1C грешки за потребителя):

• Много 1C заключвания в транзакция;
• Продължителност на транзакцията.

За да се сведат до минимум съобщенията, свързани с грешки при заключване, е необходимо или да се намали наборът от заключвания (оптимизиране на селективността), или да се намали продължителността на транзакциите.
Сега нека решим как тези показатели могат да бъдат повлияни в реална информационна система 1C.

За да намалите много блокиране:

В 1C: Enterprise 7.7:

Информационна система 1C 7.7. за брави се използват ключалки за маса, които парализират работата на потребителите. По правило повече от 50 души в една база данни не могат да работят без грешки, а проблеми могат да се появят и в бази данни от 20 потребители.
Решение:

• Гъвкави брави 1C от фирма "Softpoint". С тяхна помощ вие не само оптимизирате много заключвания (заменяйки заключванията на таблицата с персонализирани), но и ускорявате селекциите, търсенията и отчетите.

• Управлявани брави 1C е вграден инструмент на платформата 1C за по-селективни настройки на заключване. За да го използва, програмистът трябва да напише специални оператори на правилните места в кода, за да блокира необходимите ( според него!) записи в таблиците на информационната система;
• Гъвкави брави 1C - Softpoint технология за смяна на стандартни брави с нестандартни.

За да намалите продължителността на транзакциите:

За всякакви информационни системи 1C (1C 7.7., 1C 8.1, 1C 8.2, 1C 8.3), както и за други информационни системи, се използват подобни подходи:

Проверка и правилна настройка на редовна поддръжка на база данни (поддръжка на файлове, индекси, статистики, временни таблици, настройки на Windows и SQLServer);

Анализ и оптимизиране на тежки 1C и SQL заявки (настройка на индекс, пренаписване на заявки);

Проверка за излишък на транзакциите. В много случаи е неразумно да се включват операции в транзакция, без да се осъзнава как това ще се отрази на продължителността, а с това и на производителността.

1. Ако искате самостоятелно да се справите с техническите проблеми с производителността на 1C (1C 7.7, 1C 8.1, 1C 8.2, 1C 8.3) и други информационни системи , след това за вас уникален списък с технически статии в нашия Алманах (Заключване и блокиране, тежко натоварване на процесора и диска, поддръжка на база данни и настройка на индекса - само малка част от техническите материали, които ще намерите там).
2. Ако искате да обсъдите проблеми с производителността с нашия експерт или да поръчате решение за мониторинг на производителността PerfExpertслед това оставете заявка и ние ще се свържем с вас възможно най-скоро.

У дома » Заеми » 1c 8 конфликт на заключване по време на изпълнение на транзакцията. Как диагностицирах проблеми с блокирането. Голям брой операции