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

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

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

Информацията е приложима за версията клиент-сървър на 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)

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

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

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

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

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

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

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

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

В създадения по-рано план за поддръжка създайте нов подплан с име „Reindex“ Добавете към него задача за възстановяване на индекса:

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

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

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

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

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

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

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

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

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

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

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

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

Самите брави (включително в 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:Enterprise 8.x:
Информационна система 1C 8.1., 1C 8.2., 1C 8.3. автоматично използва заключвания от излишен тип (REPEATABLEREAD, SERIALIZABLE). Това води до влошаване на потребителското изживяване от 100.
Решение:

• Управляваните брави 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след това оставете заявка и ние ще се свържем с вас възможно най-скоро.

Здравейте всички!

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

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

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

Първият ден - проблемът се появи следобед, първоначално изглеждаше, че проблемът е в отдалечения потребител, който е заседнал в конфигуратора. Изглеждаше, че изпълнението току-що е спряло в даден момент и ключалката, разбира се, не е освободена. След няколко часа успяхме да освободим конфигуратора, но проблемът не изчезна. Беше изключително нежелателно да се убива насилствено конфигуратора, може би те работеха в него. След това Google пое управлението. Намерих статия на този сайт, която казва как да намеря ключалки в 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, това е нашият номер за ВРЪЗКА. Отиваме на сървърната конзола, отиваме на Connections, намираме този номер и гледаме номера на сесията. В моя случай имаше две сесии на потребител - неуспешна и друга. Срив на сесията, посочена от техническия журнал. И за едно чудо! Всичко работи, радостта няма ограничение! Но, както се оказа по-късно, сесията не беше окачена :), те работеха в нея. Ето защо за в бъдеще е препоръчително да се свържете с потребителя и да предупредите.

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

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

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

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

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

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

Пример 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 сървърът взема "икономично" решение за памет и процесор - да заключи цялата таблица наведнъж!..

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

ПРЕПОРЪКИ ЗА ЕЛИМИНИРАНЕ НА ПРЕКОЛЕРНОТО БЛОКИРАНЕ ЗА 1C: ПРЕДПРИЯТИЕ

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

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

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

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

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

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

Етикети за търсене:

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

В многопотребителски системи важна роляиграе правилна организацияконструкции и настройка на брави. Ако не, потребителите често ще срещат грешки, причинени от конкуренция за определени системни ресурси. Но има проблем с конфликт на заключване, с който много потребители са запознати. Защо възниква конфликт на заключване на 1C и как да го коригирате?

Конфликт на заключване в 1C 8.3 и неговото значение

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

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

Причини за блокиране на грешки в 1C

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

Ако не вземете идеални опции, възникват конфликти при заключване на 1C поради следните причини:

Едновременна работа на потребители с голямо количество данни.Тази основна причина е продиктувана от вътрешните механизми на 1C. Те предполагат забрана за промяна на данните, включени в транзакция, стартирана от името на друг потребител;

Грешки и недостатъци в конфигурацията.Структурата на стандартните решения от компанията "1C" взема предвид препоръките за максимизиране на производителността. Но разработчиците на трети страни не винаги се придържат към високите стандарти и често можете да намерите следните недостатъци в техния код:

• Неоптимални заявки;
• Заявка за баланси в началото на действията;
• Неразбиране на предназначението на конфигурационните обекти и неправилното им използване;
• Излишък, присъщ на системата или допълнително разработени ключалки.

Как да коригирате конфликт на заключване в 1C 8.3

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

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

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

Бързо разрешаване на конфликт на заключване на 1C

В работата на администратор или разработчик може да има ситуация, при която няма време да се провери грешката и да се намерят основните причини за проблема. Например, трябва да подадете отчет или да изпратите данни до определено време, а грешките при блокиране на 1C предотвратяват това.

Има два начина за бързо решаване на проблема:

• Намерете и прекратете сесията, която е заключила необходимите данни. IN малки компании, където броят на потребителите на 1C не надвишава няколко десетки души, това е най-доброто решение;
• Ако контролирате система, която има стотици служители, намирането на правилната сесия без специализиран софтуер може да отнеме много време. В този случай ще бъде много по-ефективно да рестартирате сървъра.

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