Контролиран режим на блокиране 1s. Управление на транзакционно заключване

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

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

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

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

Тип заключване Ниво на изолация на транзакция
Автоматични брави
Файлова база данни Маси Може да се сериализира
MS SQL сървър Публикации
IBM DB2 Публикации Повторно четене или сериализиране
PostgreSQL Маси Може да се сериализира
База данни на Oracle Маси Може да се сериализира
Управлявани ключалки
Файлова база данни Маси Може да се сериализира
MS SQL сървър Публикации Прочетете Посветено
IBM DB2 Публикации Прочетете Посветено
PostgreSQL Публикации Прочетете Посветено
База данни на Oracle Публикации Прочетете Посветено

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

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

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

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

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

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

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

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

Характеристики на работа в режим „Автоматично и контролирано“.

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

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

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

Ускорете 1C, като натиснете няколко бутона 2. Контролирани ключалки. 4 септември 2011 г

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

Първо, кратка теоретична екскурзия - защо е необходимо блокиране: Тези, които имат достъп, разбира се, могат да го прочетат тук: http://kb.1c.ru/articleView.jsp?id=30 1C си направи труда да напише доста достъпна статия относно блокирането на данни. За тези, които нямат достъп, ще опиша накратко защо са необходими брави:

Пример 1. Ако след активиране на контролирани ключалки не правите нищо и в същото време започнете да обработвате 2 документа паралелно (единият от тях все още е част от секундата по-рано), тогава ще получим приблизително следната картина:

Транзакция 1 Транзакция 2 Състояние на балансите
Започнете | 1 бр
| Започнете 1 бр
| | 1 бр
Салда за четене | 1 бр
| Салда за четене 1 бр
| | 1 бр
Отписване от салда | 0 бр
| Отписване на салда -1 бр
Завършване |
Завършване

какво не е наред тук Контролът на остатъците е неуспешен. Вторият документ успя да прочете остатъка, преди първият да успее да ги запише. В същото време видях, че е останал само 1 артикул и спокойно ги отписах след първия. Струва си да се отбележи, че всъщност тук все още ще има запушвания. 2 документа няма да могат да отписват баланси едновременно; това е необходимо за логическата цялост на базата данни, но за решаване на проблема с приложението в този пример едва ли е полезно.

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

Е, сега, след като разбрахме защо са необходими брави, остава само да инсталираме контролирани брави, където са необходими: а именно - само когато се извършва контрол на остатъчните вещества. Ако мениджър във вашата база данни има право да публикува документ, независимо дали има продукт (пари) на склад или не, защо ви е необходимо блокиране тогава? Можете просто да не ги инсталирате или да ги регистрирате и коментирате до по-добри времена. Ако наблюдавате баланси, тогава като правило това са 3-4 регистъра, добре, максимум 10. Контролът може да бъде спрян както в общите процедури и функции, така и в модулите на набора от RN записи. Кодът е изключително прост, отворете асистента за синтаксис и вижте:

Ключалка = NewDataLock;
LockElement = Заключване. Добавяне ( "Регистър на натрупванията. Стоки в складове") ;
Заключващ елемент. SetValue("Качество", Директории. Качество. FindByCode("1" ) ) ;
Заключващ елемент. Режим = DataLockMode. Изключителен;
Заключващ елемент. DataSource = DocumentObject. ReturnableContainer;
Заключващ елемент. UseFromDataSource("Номенклатура" , "Номенклатура" ) ​​;
Заключващ елемент. UseFromDataSource("Склад" , "Склад" );
Блокиране. Блок() ;

Всъщност всичко е ясно веднага - блокираме „стоки в складове“, изрично задаваме 1 измерение, вземаме стойностите на другите 2 от източника на данни - PM документ.

Тези, които са чели книги за 8.2, вероятно си спомнят за „Новата логика на осчетоводяване“ - когато балансите се контролират след записване на движенията на документи. Чудите се защо е така? Но нека преначертаем същата тази плоча, така че контролът на балансите и блокирането да бъде след запис на движенията:

Транзакция 1 Транзакция 2 Състояние на балансите
Започнете | 1 бр
| Започнете 1 бр
| | 1 бр
Отписване от салда | 0 бр
| Отписване от салда -1 бр
Ключалка | -1 бр
Салда за четене Опит за блокиране -1 бр
| Чака в блока -1 бр
| Чака в блока -1 бр
Завършване Чака в блока -1 бр
Ключалка -1 бр
Салда за четене -1 бр
| -1 бр
Отказ 0 бр

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

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

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

За да варират между такива различни задачи, СУБД излязоха с нива на изолация. Като зададете нивото на изолация на транзакцията, можете да кажете на СУБД кои заключвания да наложи в различни случаи (при писане и при четене в транзакция); в различни случаи, S (можете да четете или пишете) или X (не можете нито да четете, нито писане) се налагат ключалки.

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

А в управляван ще имате READ COMMITED, който ще прилага и незабавно освобождава S lock при четене, а X lock само при писане. Най-сложното ниво. Бързо приложено S заключване просто ви позволява да проверите дали някъде върху тези данни е поставено заключване X, което гарантира, че се четат само последователни данни, както е обичайно за дадено ниво на изолация, и дали сте прочели и изпълнили действията, препоръчани в предишната статия, тогава не. Дори ще има S заключвания при четене, така че на ниво СУБД само записът ще бъде блокиран по време на запис - което е правилно и необходимо за съгласуваност на данните.

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

Днес ще говорим за блокиране както на ниво 1C 8.3 и 8.2, така и на ниво СУБД. Блокирането на данни е задължителен елемент на всяка система с повече от един потребител.

По-долу ще опиша как работи блокирането и какви видове биват.

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

Само излишни („ненужни“) ключалки могат да причинят вреда на системата; това са бравите, които блокират ненужната информация. Трябва да се научите как да премахвате такива блокажи; те могат да доведат до неоптимална работа на системата.

Бравите в 1C условно се разделят на обектни и транзакционни.

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

Предметни брави 1C

Този тип заключване е напълно внедрен на ниво платформа 1C и по никакъв начин не засяга СУБД.

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

Песимистични брави

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

Оптимистични брави

Тази ключалка сравнява версиите на обект: ако двама потребители са отворили формуляр и единият от тях е променил и записал обекта, тогава при запис на втория системата ще даде грешка, че версиите на обектите са различни.

Транзакционни брави 1C

Механизмът за заключване на транзакции 1C е много по-интересен и по-функционален от механизма за заключване на обекти. Този механизъм активно включва заключване на ниво СУБД.

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

  • проблем със загубена промяна;
  • проблем с мръсното четене;
  • уникалност на четенето;
  • четящи фантоми.

Тези проблеми бяха обсъдени подробно в статията за.

Автоматично блокиране на транзакции 1C и СУБД

В автоматичен режим СУБД е изцяло отговорна за заключването. Разработчикът в този случай абсолютно не участва в процеса. Това улеснява работата на 1C програмист, но създаването на информационна система за голям брой потребители с автоматични ключалки е нежелателно (особено за PostgreSQL и Oracle BD DBMS - когато променят данни, те напълно заключват таблицата).

За различните СУБД се използват различни степени на изолация в автоматичен режим:

  • SERIALIZABLE за цялата таблица – файлов режим 1C, Oracle;
  • SERIALIZABLE на записи – MS SQL, IBM DB2 при работа с необективни обекти;
  • ПОВТОРНО ЧЕТЕНЕ на записи – MS SQL, IBM DB2 при работа с обектни обекти.

Управляван режим на транзакционни заключвания 1C и СУБД

Разработчикът на приложното решение на ниво 1C поема пълна отговорност. В този случай СУБД задава доста високо ниво на изолация за транзакции - READ COMMITED (SERIALIZABLE за файлова СУБД).

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

Две брави НЕ са съвместими, ако: са инсталирани от различни потребители, са от несъвместими типове (изключителни/споделени) и са инсталирани на един и същи ресурс.

Физическа реализация на заключвания в СУБД

Физически ключалките са таблица, която се намира в базата данни, наречена master. Самата таблица за заключване се нарича syslockinfo.

Таблицата обикновено има четири полета:

  1. Идентификатор на сесията на блокиране SPID;
  2. какво точно се блокира от RES ID;
  3. тип заключване - S,Uили х РЕЖИМ(всъщност в MS SQL има 22 типа, но само три се използват заедно с 1C);
  4. състояние на блокиране - може да приеме стойност ГРАНТ(инсталиран) и ИЗЧАКАЙТЕ(чака реда си).

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

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

Моят опит показва, че сте потребител (а не системен администратор или програмист) и вашата информационна база е базирана на файлове (ако базата данни е SQL, специалистите вече се занимават с вашия проблем). Да започна трябва да разберете в коя папка (директория) се намира и да изтриете един файл в тази папка - 1Cv8.cdn(не е нужно да запазвате файла, той вече няма да е необходим).

*Ако сте ИТ специалист, можете спокойно да продължите към четене на раздела „Блокиране и деблокиране от информационната база 1C“.

В прозореца със списък с информационни бази намерете вашата база (номер 1 на илюстрацията по-долу) и щракнете върху нея веднъж (и само веднъж!) с мишката. След това щракнете върху бутона „Промяна“ (номер 2).

В списъка може да има само една база данни, така че този прозорец може да ви е познат като „прозорец за стартиране на 1C“. В този случай просто щракнете върху бутона "Промяна".

Ако видите, че информационната база се намира на даден компютър или в локална мрежа, моят опит не ме разочарова – базата данни е базирана на файлове и ние правим всичко правилно. Копирайте този път ( номера 3 и 4).

Сега отидете в тази папка.

За всеки случай, ето няколко опции за стартиране на Explorer:

  • Имате Windows XP или Windows 7. Щракнете върху Старт, Изпълни, поставете копираното преди това местоположение на информационната база. Explorer ще се отвори.
  • Имате Windows 7. Но няма опция „Изпълни“. Поставете местоположението веднага след като щракнете върху Старт. Explorer ще се отвори.
  • Имате Windows 8 или Windows 10. Щракнете върху Старт, щракнете върху лупата в горния десен ъгъл, поставете копираното преди това местоположение на информационната база, натиснете Enter. Explorer ще се отвори.

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

  • Универсален метод за всички версии на Windows и неговите настройки. Натиснете бутона с флаг на клавиатурата и, без да го пускате, натиснете латинския R (или руския K) на клавиатурата. Ще се отвори прозорецът „Изпълни“, поставете копираното преди това местоположение на информационната база там и щракнете върху OK.

Използвайки една от предложените опции, ще бъдете отведени до прозорец на Explorer с местоположението на информационната база.


В прозореца на Explorer намерете файла 1Cv8.cdn в списъка с файлове, щракнете с десния бутон върху него, изберете „Изтриване“, както е показано на предишната фигура.

Готов! Вашият „1C: Счетоводство“ или „1C: Заплати и управление на човешките ресурси“ или „1C: Управление на търговията“ започва отново.

Блокиране и деблокиране от информационната база 1C. Разрушаваме митовете.

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

Как да настроя заключване?

Механизмът за блокиране на информационната база е предназначен да прекрати отворените в момента сесии и да предотврати нови връзки. Местоположението на функцията за заключване в менюто може да варира в зависимост от конфигурацията. Например в UT, издание 11 (11.3.3.163) това са основни данни и администриране, [Услуга] Блокиране на работата на потребителя. Алтернативен вариант: Проучване на данни и администриране, Поддръжка и поддръжка, Блокиране на работата на потребителите. В UT, издание 10.3 (10.3.21.2) това е услуга, потребители, блокиране на връзки към информационната база.

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


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


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

Препоръчително е да зададете параметъра „Начален час“ като текущата дата/час + времето, необходимо на потребителите да се подготвят за излизане и запазване на редактирани документи. Например, сега е 9:50 сутринта, даваме на потребителите 10 минути да запазят резултатите си. Общото начално време на блокирането трябва да бъде 10 часа 00 минути.

Краен час – не е необходимо да го въвеждате, но обектът ще бъде блокиран за неопределено време (завинаги).

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

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


И така, след щракване върху бутона „Задаване на блокиране“ и положителен отговор на потвърждението...


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


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


Планирано? Може би това има нещо общо с рутинни задачи?

Ще работи ли планираното блокиране на работата на потребителя, ако рутинните задачи са блокирани? Да, ще работи. Механизмът за блокиране не използва планирани задачи.

Какво ще видим потребителите и аз?

Докато блокирането започне, активните потребители ще получават „учтиви“ напомняния за изключване. В този диалог времето за изчакване се задейства от „Да“, така че потребителите, които не са на работното си място, успешно ще излязат от 1C сесията.


Инициаторът на заключване получава друго съобщение:


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



Бомбата избухва точно в уречения час. Сирената вие, докато не гръмне.

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

Няма изключения от режимите за въвеждане на референтни стойности, в които се въвежда стойност, която не е в справочника - не можете да излезете от режима на въвеждане (например затворете 1C с кръст), но това няма да ви попречи да завършите работата. Режимът на модален диалог е от по-голям интерес, така че ще бъде разгледан по-подробно.

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

Ще избухне ли наистина?

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

Потребител на файлова информационна сигурност, който реши например да изтрие документ и след това отиде на обяд, оставяйки диалоговия прозорец „Маркиране на документ за изтриване?“ на екрана, ще запази връзката с информационната база отворена. Разбира се, сесията му ще приключи след обяд, след като отговори с "Да" или "Не", но дотогава ще видите, че има активни потребители. В този случай инициаторът на блокиране ще види следното съобщение:


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


И това не е единствената причина, поради която блокирането може да не работи. (вижте допълнителните раздели „До чии часове?“ и „Какво ще кажете за моите потребители във Владивосток?“).

Модален диалог в SQL версията на информационната база върху управлявани формуляри

1C Application Server има възможност да изтрие сесия въпреки режима на модален диалог. Интерфейсът 1C и модалният диалог ще останат на екрана на потребителя, създавайки вид на незавършена сесия, но в действителност сесията ще бъде изтрита и връзката с информационната сигурност ще бъде прекратена своевременно. Когато се опитва да продължи да работи, потребителят ще види съобщение за грешка „Сесията липсва или е изтрита“ или „Сесията е прекратена от администратора“, в зависимост от нюансите.



Модален диалог в SQL версията на информационната база на обикновени форми

Потребителските сесии се прекратяват.

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



Ще работи ли блокирането, ако задам блокирането и затворя диалоговия прозорец?

Ще работи ли блокирането, ако зададете блокирането и незабавно излезете от 1C (т.е. прекратете сесията 1C преди да започне блокирането)?

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

По кой часовник ще работи блокирането, ако времето на компютрите е малко по-различно?

Проблем с десинхронизация на часовника

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

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

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

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

Какво ще кажете за моите потребители във Владивосток?

Абсолютен проблем с времето с потребители от различни часови зони

Времевият диапазон на блокиране се записва в информационната база. Погледнете съдържанието на блокиращия файл 1Cv8.cdn (който е създаден във файловата версия на IB), той записва началния час на блокирането като 07/17/2017 13:59 във формат YYYYMMDDDHHMMSS без никаква индикация за часа зона:


Без посочване на часова зона би било ясно за какво абсолютно време говорим, ако времето винаги се отнася за определена часова зона, например UTC+0. Но базата данни съхранява местното време според часовника на компютъра, който е инициирал блокирането. Не е известно от коя часова зона е този компютър, което означава, че абсолютното време на блокиране е неизвестно.

Ако в Москва, в централизирана система за информационна сигурност, зададете блок в 13:59 и този момент за московските потребители е в бъдещето, тогава за потребителите на същата система за информационна сигурност във Владивосток, 13:59. беше преди 7 часа. И в зависимост от техническото решение, в съответствие с което се извършва работа с информационната сигурност на потребителите във Владивосток, блокирането на тези потребители ще работи или не.

Какви технически решения може да има, при които блокирането да не работи правилно за потребителите на Владивосток? Тези, в които клиентската част на 1C ще получи време във Владивосток, а не в Москва. Например офисите са свързани към локална мрежа чрез VPN, а клиентската част на 1C се стартира от локален компютър с време UTC+10. Но ако работят с базата данни чрез RDP връзка или в режим RemoteApp на московски сървър, изпълнявайки клиентската част 1C на този сървър, всичко ще бъде наред, т.к. ще има време UTC+3.

Има ли проблеми с десинхронизацията на часовника и часовата зона в случай на SQL версия на информационната база?

Не. В тази опция има „часовник на сървъра“, който се приема като стандарт.

Ще бъда ли изгонен от Конфигуратора, ако съм бил в него и блокирането е започнало да действа?

Ще бъде ли възможен достъп до Конфигуратора след началото на периода на блокиране?

Забранено е! Възможността за работа с конфигуратора се проверява само при стартиране и не се извършва по време на работа. Следователно, ако блокът е зададен за последваща работа в конфигуратора, е много по-лесно да го стартирате първо, отколкото да заобиколите забраната за стартиране по-късно.

Как да премахнете блока?

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

В случай на SQL версия на информационната сигурност, отключването е възможно и в модула „Администриране на 1C Enterprise Servers“. (виж отдолу)

За какво е кодът за отключване?

Да влезе в информационната сигурност в момента, в който е в сила блокирането. Ситуации, при които това е необходимо:

  • След инсталиране на ключалката сесията с информационната сигурност е завършена (ръчно или в резултат на заключването на самия инициатор) и трябва да се започне нова сесия;
  • Крайният час на блокиране по погрешка изобщо не е попълнен;
  • Крайният час на блокиране е въведен неправилно (например случайно е въведен следващият месец или година);
  • Информационната база е във версия SQL и за отмяна на неправилно зададено заключване е невъзможно да изтриете файла 1Cv8.cdn в директорията на информационната база.

В този случай използвайте подсказката, която се дава при стартиране. Тези. в прозореца със списък с информационни бази щракнете върху „Редактиране“ и въведете следния ред в допълнителните параметри за стартиране:

ПРЕДПРИЯТИЕ /F"Z:\Exchange\UT 11" /Callow Users to Work /UC12345

... като се вземе предвид директорията за местоположение и кода за отключване.


По-добре е да копирате този ред в клипборда и да го редактирате в диалоговия прозорец „Редактиране на информационна база“. Ако объркате вида на кавичките или руския „C“ и латинския, ще видите съобщение за грешка:



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

Какво трябва да направя, ако не съм задал заключване, но SQL базата данни е блокирана от някой? Не знам обаче кода за отключване.

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

Къде да го търся?

Добавката „1C:Enterprise Server Administration“ често се инсталира на същия сървър, където е разположен SQL сървърът, както и където е разположен самият „1C Server“ (или „1C Application Server“). Въпреки че това не е необходимо: ​​SQL може да бъде инсталиран на един компютър, 1C Application Server на друг и оборудването може да бъде разположено на вашата собствена работна станция. Най-вероятно можете да постигнете успех, като направите следното:

  • Свържете се чрез RDP към сървъра, посочен в реда Srvr=..., като използвате вашето потребителско име и парола за домейн. Ако не можете да се свържете, помолете вашия системен администратор да ви добави към групата Потребители на отдалечен работен плот. (Ако са отказани такива права, разположете и конфигурирайте модула „Администриране на 1C корпоративни сървъри“ на работната станция);

  • На сървъра намерете модула „1C:Enterprise Server Administration“;
  • Стартирайте модула, разгънете дървото до възела с вашата информационна база;

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

Какво да направите, ако всички потребители на SQL информационната база са излезли, но все още не можете да стартирате Конфигуратора, защото... има ли активни потребители?

В раздела „Връзки“ на информационната база, от дясната страна на екрана, можете да изтриете съществуващи връзки.


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

Ако все още имате въпроси:

  • Възможно ли е да работите според московското време, ако наемете сървър в Европа и не искате да зависи от неговата часова зона?
  • Как да намерите 1C Application Server, ако не знаете къде е инсталиран?
  • Как да внедрите модула „1C:Enterprise Server Administration“ и как да го конфигурирате?
  • Ако има няколко сървъра за приложения в една и съща локална мрежа, какво трябва да направите?
  • Какво да правим в случай на клъстерна система? и т.н.

Нашите сертифицирани технологични консултанти 1C ще се радват да отговорят на тях.

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

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

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

Същността на управляваните брави

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

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

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

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


Новите конфигурации от 1C бяха внедрени веднага в контролиран режим.

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

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

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

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

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

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



Свързани публикации