Режим на управление на блока за данни. Механизъм на контролирано блокиране

Механизъм блокове за транзакции Използвани за конкурентоспособност на потребителския достъп до DBMS.
Транзакцията е определена неразривна работа, през която състоянието на основата се променя. Това е минимален размер на промяната: е невъзможно да се направи половин транзакция; Ако транзакцията не е завършена, базата се връща обратно към първоначалното състояние.
Тъй като транзакцията улавя множество данни, настъпването на достъп до този масив: например една транзакция променя данните, а другият се опитва да ги прочете. Резултатът от четенето може да бъде неправилен, защото няма да включват последните промени. Следователно, на ниво СДБД, изолацията на транзакцията работи. Възможни са следните нива на изолация:

  • Прочетете Communmited - Докато една транзакция променя масива, другата не може да я промени, но може да чете. По-ниско ниво на изолация.
  • Прочетете. - докато една транзакция променя масива, другата не може да я промени, нито чете
  • Повторяем четене. - докато една транзакция чете масива, другата не може да я промени, но може да чете
  • Сериализурама - докато една транзакция чете масива, другата не може да я променя или да прочете. Всички операции са последователни. Максимално ниво на изолация.

Ако за конфигуриране 1С: инсталирани предприятия автоматичен режим на заключванеИзбрана е транзакцията, изолираща DBMS. В случай на MS SQL, той ще бъде повторяем чете или сериализиращи нива, т.е. изолацията на данни е близо до максимума. Това решава проблеми с верността на данните, но може да доведе до появата на ключалки на нивото на СУБД по време на интензивната работа на потребителите. Ето защо, в 1C: Компанията има своя собствена функционалност със ключалки, която се активира от включването на контролирани ключалки. В този случай нивото на изолиране на транзакцията за MS SQL ще бъде прочетено. Самата платформа ще изолира данните, без да разчита на СУБД.

Включването на контролирания режим на заключване възниква в конфигурационните свойства:

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

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

За режима, автоматичен и управляем е един момент. Транзакция, един потребител може да бъде няколко транзакции от гледната точка на платформата. Например интерактивното поведение на регистъра прави дветранзакции - записване на самия документ и в рамките на тези редове за запис на транзакции за регистър. В зависимост от режима за управление на заключването за самия документ и за преместването на регистъра, са възможни четири ситуации:

  1. Режим на документи Автоматично, Регистрирайте се автоматичен режим -\u003e
  2. Режим на режим на документи, Регистрирайте Режим Управляван-\u003e Регистрирайте се в режим управляван режим
  3. Режим на документ Автоматично, Регистрирайте Режим Управляван -\u003e Регистрирайте се в автоматичен режим
  4. Режим на документ, регистър автоматичен регистър -\u003e Изключителна ситуация (грешка)

Въпрос 06.59 Изпит 1в: Професионален на платформата. При провеждане на документ във всеки регистър, ако документът има автоматичен режим на управление на транзакцията, и се управлява регистърът (в конфигурационните свойства се използва опцията "автоматична и управляема"), тогава такова поведение ще доведе:

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

Въпрос 06.60 Изпит 1в: Професионален на платформата. При провеждане на документ за всеки регистър, ако документът има контролен режим за управление на транзакцията, и регистърът е автоматичен (в конфигурационните свойства се използва опцията "автоматична и управляема"), след това такова поведение ще доведе:

  1. до появата на погрешна ситуация
  2. цялата транзакция ще се извършва автоматично
  3. цялата транзакция ще бъде извършена в управлявания режим.

Правилният отговор е първият, дефинирайте на първата транзакция, ако се управлява, след това грешка.

Въпрос 06.61 Изпит 1в: Професионален на платформата. При провеждане на документ във всеки регистър, ако документът има автоматичен режим на управление на заключването на транзакции и се управлява регистърът (в конфигурационните свойства се използва "управляема" опция), тогава такова поведение ще доведе:

  1. до появата на погрешна ситуация
  2. цялата транзакция ще се извършва автоматично
  3. цялата транзакция ще бъде извършена в управлявания режим.

Системата "1c: Enterprise" ви позволява да използвате две работни режима на база данни: автоматичен режим на заключване в транзакцията и контролирани ключалки в транзакцията.

Фундаменталната разлика в тези режима е както следва. Режимът за автоматично заключване не изисква разработчик на каквито и да било действия за контрол на ключалките в транзакцията по ред. Тези правила се предоставят от платформата 1C: Enterprise System чрез използване на нива на изолация на транзакции в даден СУБД. Такъв начин на работа е най-прост за разработчика, но в някои случаи (например с интензивно едновременно функциониране на голям брой потребители), нивото на входа на изолацията на транзакцията в СУБД не може да осигури достатъчно паралелизъм на работата, \\ t което се проявява под формата на голям брой блокиращи конфликти, когато потребителите работят.

Когато работите в контролирани ключалки, системата "1c: Enterprise" използва много по-ниско ниво на изолиране на транзакцията в СУБД, което дава възможност значително да се увеличи паралелизмът на прилагането на приложеното решение. За разлика от режима за автоматично заключване, това ниво на изолиране на транзакцията вече не може да изпълни всички правила за работа с данни в сделката. Следователно, когато работите в управляем режим, разработчикът се изисква самостоятелно да контролира ключалките, инсталирани в транзакцията.

В обобщение на разликата по време на работа в режим на автоматично заключване и в режим на контролирано заключване вижте следната таблица:

Lock Type. Ниво на изолация на транзакции
Автоматично блокиране
Файлова база данни Таблици Сериализаруем
MS SQL Server. Рекорд
IBM DB2. Рекорд Повтарящи се четене или сериализаруеми
PostgreSQL. Таблици Сериализаруем
Oracle база данни. Таблици Сериализаруем
Контролирано блокиране
Файлова база данни Таблици Сериализаруем
MS SQL Server. Рекорд Прочетете.
IBM DB2. Рекорд Прочетете.
PostgreSQL. Рекорд Прочетете.
Oracle база данни. Рекорд Прочетете.

Настройване на заключването в конфигурацията
Конфигурацията има свойство. Всеки конфигурационен обект също има свойство. Режим на управление на блока за данни.
Режимът за блокиране на данни за цялата конфигурация като цяло може да бъде настроен на автоматични стойности, управлявани (по подразбиране за нова конфигурация) и Автоматично и управляемо. Стойностите са автоматични и управлявани означават, че съответният режим на заключване ще се използва за всички конфигурационни обекти, независимо от стойностите, зададени за всеки от обектите. Стойност Автоматично и управляемо означава, че режимът, който е посочен в нейния имот, ще бъде използван за конкретен обект на конфигуриране. Режим на управление на блокиране на данни: Автоматично или управлявано.
Трябва да се отбележи, че режимът на блокиране на данни, определен за обекта на метаданните, е зададен за транзакции, които са инициирани от системата "1c: Enterprise", когато работите с данните на този обект (например, когато променяте данните за обекта).
Ако например операцията за запис на обект се извършва в транзакция, инициирана от разработчика (метод Старт напрежение ()) Режимът за управление на заключването на данни ще се определя от стойността на параметъра. Режим на заключванеметод Старт напрежение (), а не стойността на свойствата на обекта на метаданните Режим на управление на блокиране на данни.
По подразбиране параметърът Режим на заключване има значението Регистрационни ключалки. Автоматичнотака и за
За да използвате контролирани ключалки в изрична транзакция, трябва да зададете стойността на този параметър.
Разтърси ключалки (Задайте този параметър има смисъл, акоза конфигурацията свойство "режим на управление на данни" е избран "автоматичен и управляем") .

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

Условията са настроени на равенството на полевата стойност на определената стойност или да въведете стойността на полето в определения диапазон.
Условията могат да бъдат зададени по два начина:

● Използване на изричната спецификация на името и стойността на полето (метод Зададена стойност () Обект Елементи на елементите);
● Чрез задаване на източника на данни, съдържащ необходимите стойности (собственост на изходния обект Елементи на елементите).

За всеки блокиращ елемент може да се зададе един от двата режима на заключване:

● споделен
● Изключителен.

Таблицата за съвместимост на контролираните ключалки е както следва.

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

Характеристики на работата в режим "Автоматичен и управляем"

Когато работите в режим на управление на заключването, трябва да се вземат предвид и автоматични и управлявани:

● Независимо от режима, определен за тази транзакция, системата ще инсталира подходящо управлявано
Ключалка.
● Режимът за управление на заключването се определя от транзакцията на самата "горна" ниво. С други думи, ако друга транзакция, започнала от началото на транзакцията, началната транзакция може да бъде изпълнена само в режима, който е инсталиран за операцията, която вече работи.

Погледнете повече подробности.
Първа функция Това е, че дори ако транзакцията се използва автоматичен режим за управление на заключването, системата ще инсталира допълнително и съответните контролирани ключалки при писане на данни в тази транзакция. От това следва, че сделките, изпълнявани в контролирани ключалки, могат да се изправим с транзакции,
Извършени в режим на автоматично управление на заключването.
Втора характеристика Именно, че режимът за управление на заключването е посочен за обекта на метаданните в конфигурацията или зададената, когато транзакцията е изрично посочена (като параметър на метода Старт напрежение ()) е само "желаният" режим. Реалният режим на управление на заключването, в който ще бъде изпълнена транзакцията, зависи от това дали това предизвикателство за началото на транзакцията е първо или по това време друга транзакция вече е започнала в тази сесия на системата "1c: Enterprise".
Например, ако искате да контролирате ключалките, когато записвате записите в регистъра, когато провеждате документ, контролираният режим на заключване трябва да бъде инсталиран както за самия регистър, така и за документа, тъй като записването на вписванията в регистъра ще бъде записано в сделката отворете при писане на документ.

Системата "1c: Enterprise" ви позволява да използвате два режима на база данни: автоматичен режим на заключване в транзакцията и контролирани ключалки в транзакцията.

Фундаменталната разлика в тези режима е както следва. Режимът за автоматично заключване не изисква разработчик на каквито и да било действия за контрол на ключалките в транзакцията по ред. Тези правила се предоставят от системната платформа "1C: Enterprise", като се използват нива на изолация на транзакции в даден СУБД. Такъв начин на работа е най-прост за разработчика, но в някои случаи (например с интензивно едновременно функциониране на голям брой потребители), нивото на входа на изолацията на транзакцията в СУБД не може да осигури достатъчно паралелизъм на работата, \\ t което се проявява под формата на голям брой блокиращи конфликти, когато потребителите работят.

При работа с контролирани ключалки, системата "1c: Enterprise" използва много по-ниско ниво на изолация на транзакции в СУБД, което позволява значително да се увеличи паралелизмът на прилагането на приложеното решение. За разлика от режима за автоматично заключване, това ниво на изолиране на транзакцията вече не може да изпълни всички правила за работа с данни в сделката. Следователно, когато работите в управляем режим, разработчикът се изисква самостоятелно да контролира ключалките, инсталирани в транзакцията.

В обобщение на разликата по време на работа в режим на автоматично заключване и в режим на контролирано заключване вижте следната таблица:

Настройване на заключването в конфигурацията

Конфигурацията има режим на управление на имота. Всяко приложение за конфигуриране също има режим на блокиране на данни.
Режимът за блокиране на данни за цялата конфигурация като цяло може да бъде настроен на автоматични стойности, управлявани (по подразбиране за нова конфигурация) и автоматично и управляемо. Стойностите са автоматични и управлявани означават, че съответният режим на заключване ще се използва за всички конфигурационни обекти, независимо от стойностите, зададени за всеки от обектите. Стойността е автоматична и контролирана означава, че режимът, който е посочен в неговия имот, е автоматичен или контролиран, ще се използва за конкретен обект на конфигуриране.
Трябва да се отбележи, че режимът на блокиране на данни, определен за обекта на метаданните, е зададен за транзакции, които са инициирани от системата "1c: Enterprise", когато работите с данните на този обект (например, когато променяте данните за обекта).
Ако например операцията за запис на обект се извършва в транзакция, иниция, инициирана от разработчика (методът на стартовата транзакция ()), режимът за управление на блока ще бъде определен от параметъра за блокиране
Методи Стартиране на напрежение (), а не стойността на свойствата на метаданните обект на режима на блокиране на данни.
По подразбиране параметърът за блокиране има стойност на регистрираните блокове. Автоматично, така за
За да използвате контролирани ключалки в изрична транзакция, трябва да зададете стойността на този параметър.
Разтърси ключалки .. продължава.

Работа с контролирани ключалки в вградения език

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

Условията са настроени на равенството на полевата стойност на определената стойност или да въведете стойността на полето в определения диапазон.
Условията могат да бъдат зададени по два начина:

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

За всеки блокиращ елемент може да се зададе един от двата режима на заключване:

  • разделен
  • изключителен.

Таблицата за съвместимост на контролираните ключалки е както следва.

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

Характеристики на работата в режим "Автоматичен и управляем"

Когато работите в режим на управление на заключването, трябва да се вземат предвид и автоматични и управлявани:

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

Погледнете повече подробности.

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

Втората функция е, че режимът за управление на заключването, посочен за обекта на метаданните в конфигурацията или е посочен в началото на транзакцията изрично (като параметър на началото на стартовото напрежение ()), е само "желаният" режим. Реалният режим на управление на заключването, в който ще бъде изпълнена транзакцията, зависи от това дали това предизвикателство за началото на транзакцията е първо или по това време друга транзакция вече е започнала в тази сесия на системата "1c: Enterprise".

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

Нека да разгледаме как изглежда типична монополна ключалка в 1C.

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

Мисля, че знаеш добре какво в 1s.има две режими на заключване: Автоматични и управлявани.

  • В автоматичен режим Всичко е просто:
    • С всяко показание-.
    • НО с всеки записХ.- - освен това заключва само на сървъра на DBMS, 1С не поставя никакви ключалки.
  • Много по-интересно управляван режим. Основната му характеристика е това в 8.2 и в 8.3, блокиране на работа по различни начини.
    • Например, в 8.2.ти всяко четене ще поставиС.- Блокиране. Освен това четенето не е просто искане. Попълнете (), но също така и link.revevizit, справка. Фокусиране () и т.н.
    • НО в 8.3.без режим на съвместимост вече бравата за четене няма да бъде. Така 8.3 определено печели по отношение на паралелизма на работата.
    • Е, тогава най-интересните започват - например, за проектиране на комплекта. Прочетете ()в контролиран режим 8.2 Ще имате S-LOCK на сървъра на DBMS (това е естествено). Но освен това също ще бъде споделено блокиране на сървъра 1cи това се проявява и в 8.2 и в 8.3. И основният проблем е, че това споделя ви блокиране ще продължи до края на сделката - докато транзакцията не свършва, данните ще бъдат блокирани.
      Ето защо, препоръката номер едно е - ако имате нужда от набор от записи само за четене, по-добре е да използвате заявката, а не обектния модел. Тогава няма да блокирате нищо и ако сте, това не е дълго.
    • Естествено, с всяка промяна на данните (записване, задържане, заличаване) ще бъде поставете изключителна блокиране на 1C сървъра и изключителния DBMS сървър.

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

Продължителност на ключалките в контролиран режим

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

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

Що се отнася до заявката за проектиране. Попълнете (), след това, ако е 8.2, блокирането ще бъде премахнато веднага след изпълнението на заявката и ако е 8.3 (или в DBMS MS SQL, режимът на прочетения режим е активиран), тогава заключването няма да бъде въобще. Следователно ако имате 8.2 или 8.3 в режим на съвместимост от 8.2Аз съм по всякакъв начин препоръчвам да включите режимаПрочети. Ангажиран Моментална снимка Изолация. - Във всеки случай, във всеки случай ще увеличи паралелизма на работата.

Ето един типичен пример: първо можете да поставите заключването, да изпълните някои изчисления и чекове (вижте дали реквизитите се попълват и т.н.) и само тогава транзакцията е завършена - тогава ще имате дълго време за блокиране. Но е по-добре, ако има такава възможност, да се прави по различен начин: първо да направите всички видове изчисления (проверка на пълнежа и т.н.), а заключването се налага вече в самия край. Тогава имате времето за блокиране ще бъде по-малко и съответно рискът от очаквания също ще намалее. Следователно, опитайте се да наложите явни контролирани ключалки или вход в базата данни, за да направите възможно най-близо до края на транзакцията.

Най-честото причините за ключалките

Заявка със сканиране

Често изчакване на блокиране възниква в случай на неоптимално искане. Например, имате потребител на Иванов, който в процеса на провеждане на документ е блокирал няколко позиции на номенклатурата - само това, от което се нуждае. И има потребител на Петров, който е извършил заявка за сканиране в транзакцията (заявка. Fill ()). И ако, когато прочетете това искане, това искане протича върху номенклатурата, която е блокирана от Иванов, след това в случай на използване на версия 8.2 (или 8.3 в режим на съвместимост от 8.2), той ще спре и ще изчака по подразбиране 20 секунди . В същото време потребителят Петров ще бъде в очакване, че, разбира се, той няма да го харесва. Как да решим тази ситуация? Изглежда, че отговорът е очевиден - можете да вземете и пренапишете заявката, така че да не се чете допълнителни линии, тогава всичко ще бъде чудесно.

И ако тази заявка е платформа? Или тази заявка се използва в типична конфигурация, която може да не се променяте по очевидни причини - какво тогава да направите? Какви са опциите?

Изключете режима на съвместимост? По-правилно е да се каже - да се пресичат, да създадете копие, да тествате седмицата и след това да се изключите, защото ако веднага се изключите, можете да имате "забавен уикенд" и може би не само през уикенда.

Друг вариант е активиране на режим на версия заГ-ЦА. SQL Сървър. Незабавно направете резервация, че описаната само ситуация е възможна само в блокера на DBMS, защото ако имате DBMS версия, не може да има такава ситуация. И ако включите прочетете прочетете изолацията на снимката, тогава имате MS SQL започва да работи почти като версия. И вашето искане няма да блокира линии.

В 1c няма "магическа таблетка", но активирайте режимаПрочети. Ангажиран Моментална снимка Изолация. - най-близо аналогов Това "Магически таблетки". Можете веднага да намалите броя на очакванията във вашата база данни при минимални действия. За това просто трябва да изпълните няколко редапоказан на екрана сценарий Б.Г-ЦА. SQL сървърИ веднага получавате много добро увеличение на паралелизма на работата. Разбира се, има смисъл само за управляван режим на заключване в 1с конфигурация. За автоматичен режим, включете режима RCSI на DBMS сървъра без смисъл.

Липса на регистрите

Често очакванията възникват именно върху регистрите на натрупване и на счетоводните регистри - в случая, когато става въпрос за същите данни. Да се \u200b\u200bизбегнат такива очаквания, е изобретен общ режим на разделяне.

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

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

Преместване на границата на последователността при провеждане

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

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

Дълги сделки

Опитайте се да направите най-кратки сделки:

  • Ти носиш всички видове проверки и изчисления извън сделката - Всяко влизане, всяко налагане на ключалки трябва да се извърши в самия край.
  • В никакъв случай няма диалогови прозорци в транзакция Не се нуждаят, особено ако се използва дебел клиент. Срещнахме такива случаи, че счетоводителят има диалогов прозорец с "да" и "не" при провеждането на документ. И докато тя решава, че ще се обади на някого с някого, докато някой се обади - ще виси този прозорец и през цялото това време транзакцията ще бъде активна и съответно, блокирането също ще бъде активно - времето му ще бъде много дълго. Така че не е необходимо да се прави.
  • Как мога да ускоря времето на транзакцията? Мога скорост на кодакойто работи там. Ускоряване на заявкитеАко знаете как да го направите. Това незабавно ще даде рязко увеличаване на производителността.
  • Друг вариант е ускоряване на влизането в регистрите. Как? Възможно е да програмирате и можете да харвате. Например, ако сте закупили нормални SSD устройства, тогава скоростта на запис ще се увеличи естествено - дори запитванията ще се извършват по-бързо. И съответно времето на сделката също ще намалее. Това не означава, че едно надграждане на дискове може да реши проблема с ключалките, но поне можете да изгладите този ефект - няма да е толкова забележим.

Ескалиране в режим на много резба

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

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

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

Кога обикновено се появява ескалация в 1с? Най-често това е някаква твърда работа - затварянето на месеца, изчисляването на цената и т.н. - когато в една гигантска транзакция започва много документи, цялата таблица е блокирана и в този момент никой не може да работи - паралелността пада. Такива операции трябва да бъдат взети предвид отделно и да ги харчатЗащото в паралелен режим не можете да ги обработвате.

Грешка при платформата - заключване при използване на сепаратор за областта на данните

Платформата има няколко грешки, които водят до прекомерни очаквания за блокиране. Например, има грешка, че бях много изненадан. Ситуацията е следната - събирахме данни за очакванията и видяхме това заявка за ред. Попълнете ()налага контролирано изключително блокиране, което по принцип не може да бъде и не трябва. Когато го видяхме, си мислехме, че инструментът е "празник". Отново качени данни. Всички се презиждат. Наистина, налага. Оказа се, че такава грешка се появява в платформата 8.3.6. При четене - без значение, заявка. Попълнете () или постоянен. Нагоре () - като цяло, с всяко четене - платформа Наложено изключване на изключителното (x) заключване на полето, което е разделител на данни И паралелът веднага падна. Освен това блокирането беше точно изключително.

Ето такава грешка в платформата.

За щастие за нас, клиент, който се прояви, изобщо не използва този сепаратор на данни, така че ние просто премахнахме знака, че е сепаратор. И всичко това, грешката изчезна. Но тя е била фиксирана или не, аз все още не знам. Мога да кажа със сигурност, че в 1c за тази грешка знам, но когато го оправят, аз, за \u200b\u200bсъжаление, не е известно. Затова бъдете готови, че можете да бъдете.

Грешка при платформа - сканиране на индекса за изчисляване на сканиране

Често сме изправени пред грешките на платформата за работа с регистъра за изчисление. От гледна точка на изпълнението, той има много проблеми, защото регистът за изчисляване е единственият обект в 1с, който няма индекс на клъстера. Ето защо, когато записвате няколкостотин струни в регистъра за изчисление (ако има малки редове, тази грешка не се възпроизвежда) или да почистите движението там (напишете празен набор от движения там) - това ще бъде индекс за изчисляване на таблицата за изчисляване на таблицата. И тъй като това е заявка за платформа, не можете да я коригирате и тъй като това е премахване (X Lock е насложено), тогава включването на режима на прочетено плащане също не променя ситуацията.

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

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

Грешка по платформата - невъзможността за паралелно записване в периодичен независим информационен регистър

Много стара грешка, за която в 1c също значи перфектно, но въпреки това тя все още не е фиксирана - тя е невъзможността за паралелно записване в периодичен независим информационен регистър. Изглежда, че ако имате различни периоди (измерванията съвпадат, но периодите са различни), можете да записвате данни паралелно. Но това не се случва, въпреки че трябва да бъде. Като на 1C сървър, излишно блокиране по дата. На проекти тази ситуация не е често срещана - информационният регистър много рядко се превръща в "затруднение" за блокиране. Обикновено възникват проблеми поради регистъра на натрупване или поради счетоводния регистър. Но въпреки това, ако срещнете това, можете да се опитате да направите период на измерване. Да, разбира се, в този случай няма да има виртуални таблици в този случай (намаляването на най-новите) този регистър на информацията вече няма да формат, но можете спокойно да пишете в него паралелно и искането за получаване на разделите на Първият / последният може да бъде оформен.

  • Първо, отидете в режим на контролирано заключване. Мисля, че е доста очевидно, защото ако сте използван автоматичен режим, може дори да не сте изненадани от въпросите "Защо имаме малък работен паралелизъм, защо много брави?" Първо отидете в управлявания режим и ако след това имате проблеми, ще останете, тогава можете да продължите да разбирате.
  • Когато прехвърляте конфигурацията на контролирания режим на заключване, не забравяйте собственост, за да бъде включен в режим на DBMSПрочети. Ангажиран Моментална снимка Изолация.. Тя е пряко трябва да има - ще има рязко увеличение на паралелизма на работата.
  • Използвайте разделителя на резултатите за регистрите. Когато няма остатъчен контрол, е необходимо да се включи, че няма очаквания.
  • И Задаване на записи. Нагоре () - Опитайте изобщо за четене да не се използваЗащото ще бъде насложено от контролирано блокиране, което ще "виси" до края на сделката. Защо ви е нужна? Прочетете тези заявки, а ключалките няма да бъдат изобщо, ако имате 8.3 без режим на съвместимост или режимът на прочетения режим на снимката е активиран.
  • За границата на последователността - също се опитвайте да поемате по подразбиране границата да премести само регулаторната задача в часове. Когато извършвате да не се движите.
  • Големи транзакции за споделяне на няколко. Какво да прекарате един милион документи в една сделка, по-добре е да се правят малки транзакции от 100 документа, 1000 документа са още по-добри, ако са в един многоходен режим. Тя ще бъде по-стабилна.
  • Всички видове изчисления, проверки и т.н. направете извън сделката. Времето на транзакцията трябва да бъде минимално възможно най-малко.

Пример за решаване на блокиращ проблем

Как иначе можете да се отървете от ненужните очаквания?

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

Как може да се избегне това? Мога когато изтегляте документи, за да създадете, но не провеждайте, и тогава напишете механизъм, например, изпълнения Това е допълнително хОЛДИНГ в многопоказания режимкъдето всяка нишка ще държи документи в склада им. Разпространявайте, така че тези процеси във времето: първият поток провежда документи на един склад, вторият поток - във втория склад и др. Тогава проблемът ще бъде решен.

Брави и оборудване

Как блокирането засяга оборудването? Изправени пред проблема с блокирането, може да искате да закупите нов сървър. Разбира се, можете да опитате, но корен все още не променяте нищо. Да, сделките ще бъдат по-бързи, заявките ще станат по-бързи. Но себе си проблем с ключалките ще остане, защото тя може да бъде решен само на ниво код.

Как блокиращата оптимизация влияе върху оборудването? Например, вие сте преминали към управляеми или взети и включите прочетете извършената снимка. Докато системата чака, тя е оборудване не го използва в този случай празен. НО веднъжвашата система е спечелена в пълен капацитет, няма очакванияВеднага имате рязко увеличение. И, в зависимост от това, което е в момента, в момента е, тя може да бъде критична. Например, ако сървърът е бил зареден с 80%, и също така елиминирате ключалката, тя изобщо може да "лежи". Необходимо е да се обмисли.

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

Инструмент за анализ на блока

И в заключение, искам да покажа инструмент, с който вие в реално време можете да видите какви данни понастоящем са блокирани в системата..

Основните причини за прехода към управлявани ключалки:

  • Основната причина е 1C препоръка: експерт въз основа на показания или 1C: PC
  • Проблеми с паралелната работа на потребителите ()
  • Използвайте Oracle, PostgreSQL и.

Цената на работата:

Същност на контролираното блокиране

При работа в режим на автоматично управление на заключването 1C: компанията определя висока степен на изолация на данни в транзакцията на нивото на СУБД. Това прави възможно напълно да се премахне възможността за получаване на неопределените или неправилни данни без никакви специални усилия от прилаганите разработчици.

Това е удобен и правилен подход с малък брой активни потребители. Цената на лекотата на развитие е определено количество излишно блокиране на нивото на СУБД. Тези ключалки са свързани както с характеристиките на прилагането на заключващите механизми в самата СОБ и така, че СУБД не могат да вземат под внимание (и не вземат под внимание) физическото значение и структура на метаданните обекти 1C: предприятия.

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

След като конфигурацията се преобразува в контролирания режим, опционалният "мениджър на заключване" и контрол над целостта на данните се активират сега отстрани на СУБД, но отстрани на сървъра 1c. Това увеличава натоварването на желязото на IC сървъра (необходимите по-бързи процесори и повече памет) и всъщност прави дори малко забавяне (няколко процента), но много по-значимо подобрява ситуацията с ключалки (по-малко блокове поради запушвания към обекта, и не на комбинация от таблици, по-малко блок зона и в някои случаи по-малко спасяване на живота, т.е. не до края на транзакцията). Поради това общият паралелизъм се подобрява.


Новите 1с конфигурации се изпълняват незабавно в управляван режим.

  • Въпрос: Възможно ли е първо да направите одит и след това да се прехвърлите в UB?

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

  • Въпрос: За да прехвърлите в UB, какво точно за предоставяне на достъп - RDP, TeamViewer? Или можете да изпратите конфигурация на файла?

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

  • Въпрос: Имаме 10 редовни програмисти, които променят нещо на конференцията всеки ден. Използвана обща конфигурационна памет ". Как ще бъде организирана взаимодействието при прехвърляне на UB? Или всички програмисти трябва да бъдат изпратени на почивка?

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



Статии по темата: