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

Не можах да запиша промените за прехвърляне в разпределена база данни, свързах се с поддръжката на 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)

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

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

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

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

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

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

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

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

Пример 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
• блокиране
• Конфликт при заключване
• Конфликт на заключване при изпълнение на транзакция

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

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

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

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

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

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

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

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

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

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

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

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

„Заседнали сесии“

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

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

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

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

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

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