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

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

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

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

Реиндексирането на таблицата включва пълно възстановяване на индексите на таблицата на базата данни, което води до значително оптимизиране на тяхната производителност. Препоръчва се редовно да преиндексирате таблиците на вашата база данни. За да преиндексирате всички таблици на базата данни, трябва да изпълните следната 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 блокиране“ и „1C блокиране на транзакция“ са синоними.

Решихме, че ако времето за изчакване бъде превишено, потребителят ще получи съобщение за грешка; за него самият процес на изчакване изглежда така, сякаш екранът на информационната система 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.3 и 8.2, свързана с конкуренцията за използване на ресурси в системата.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Но има причина да има обратното мнение - митът, че при интензивна едновременна употреба работата с решения, базирани на 1C:Enterprise, е неудобна или невъзможна. В крайна сметка, веднага щом стандартните решения за 1C:Enterprise започнат да се използват от стотици потребители на индустриален мащаб, все по-често на екрана се появява прозорец с горд надпис: „Грешка при извикване на контекстния метод (Write): Конфликт при заключване при изпълнение на транзакция: ..." и след това, в зависимост от вида на използвания 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 брави
• Ключалка
• Конфликт на заключване
• Заключване на спора по време на транзакция

У дома » Инвестиции » Конфликт на заключване при извършване на 1s транзакция 8.2. Как диагностицирах проблеми с блокирането. Рутинни операции на ниво DB за ms sql сървър