Здравствуйте.

исходные данные:
1С 8.2 ЗКБУ
база была сформирована из 1с ЗиК 7.7
конфигурация типовая
пробовались разные типы баз - файловая, терминал и sql (windows server 2008. sql server 2008.)
размер базы - 800Мб
платформа и конфигурация обновляются регулярно.
С базой работают 2 расчётчика


Проблема в следующем:

При одновременном расчёте заработной платы разным сотрудникам, у одного из расчётчиков(рандомно) возникает следующая ошибка:

Ошибка:
{ОбщийМодуль.ПроведениеРасчетовПереопределяемый.Модуль(4887)}: Ошибка при вызове метода контекста (Записать)
НаборЗаписейРегистра.Записать(Истина, ТолькоЗапись, Истина, Ложь);
по причине:
Конфликт блокировок при выполнении транзакции:
Microsoft SQL Server Native Client 10.0: Превышено время ожидания запроса на блокировку.
HRESULT=80040E31, SQLSrvr: SQLSTATE=HYT00, state=2D, Severity=10, native=1222, line=1

В конфигураторе ссылается на следующую строку:

// записываем набор перед расчетом каждой категории начислений
Если ИмяРегистра = "ОсновныеНачисленияРаботниковОрганизаций" Тогда
НаборЗаписейРегистра.Записать(Истина, ТолькоЗапись, Истина, Ложь);
Иначе
НаборЗаписейРегистра.Записать(Истина, ТолькоЗапись);
КонецЕсли;
ТолькоЗапись = Истина;

Данная проблема возникает не только у нас. Фирма, которая осуществляет сопровождение сначала причиной называло медленный компьютер на котором стоит база (файловый вариант) или линии ЛВС(исключили эту причину сразу), базу перенесли на терминальный сервер - та же ошибка, на SQL то же самое.

ЕСТЬ ли решение этой проблеме?

Все не так просто. Конфликт блокировок при выполнении транзакции.

(0) не знаю как устроена конфа, но попробуйте включить управляемые блокировки

и еще сотрудники может быть и разные, но какие-то измерения у записываемых данных одинаковые. Добейтесь того, чтобы значения измерений были разными у обоих расчетчиков

Конфликт блокировок в 99% случаях говорит об ошибках в алгоритмах доступа к данным. Если конфа типовая, обращайтесь в поддержку 1С.

Переписывать. Всё. Не дожидаясь перитонита.

файловая база стоит на обычном ПК (Dual-Core E5200, (2.50/800/2Mb); 2GB DDRII-800; Seagate (320 Gb/ 7200/8Mb/ SATA ).
терминальный и sql сервер ещё на более древнем компе(1 гб ОЗУ), НО
цитата:
"Конфликт блокировок при выполнении транзакции" = Дедлок

В данном случае повышение производительности не решит проблему, а только сделает вероятность ее возникновения меньше. Т.е. только отложит проблему на будущее

(5) Переписывать что? поподробнее пожалуйста.
Кстати, данная База 1с 8.2 ЗКБУ собиралась из 6 баз 1с 7.7 ЗиК, из которых 2 были не типовые с правленой конфигурацией. Переводили базу в течении 3-4 месяцев, до сих пор возникают ошибки в базе (конкретные примеры пока привести не могу), у расчётчиков очень много вопросов к сотрудникам фирмы, которая занималась переводом базы. Данный сотрудник и в данный момент приходит и что то доробатывает по преензиям наших расчётчиков

(7) Про управляемые блокировки тебе уже сказали. Вот с них и начинай.

(8) Ну зачем путаешь человека?

Если организация большая (а раз несколько расчетчиков - это так), то и регистр "основные начисления организации" явно не маленький. А судя по коду его "держат" довольно долго.

Т.е. нужно смотреть всю процедуру проведения расчетов. Косметикой "управляемые блокировки" тут явно не обойдёшься

(0) При расчете добавляются записи в регистр расчета, потом все считается. Раз конфликт возникает - значит считают одновременно одно и то же.

(9) Фига се косметика...
Это не косметика... Это хирургия уже...
А вот более радикально - это уже реинкарнация будет...
Исправление ошибок методом Ctrl-A - Del...

(11) "Исправление ошибок методом Ctrl-A - Del..."

Ещё скажи "Format c:"

(10) "значит считают одновременно одно и то же."

Конфликт будет даже если один расчетчик заблокировал регистр для "заполнения", а другой попробует рассчитать.

Тут явная проблема с алгоритмом проведения.

(0) есть отличное решение - забить. зп считается не так часто, тем более расчетчика всего два.

(7) >Данный сотрудник и в данный момент приходит и что то доробатывает по преензиям наших расчётчиков

Ну вот и виновник нарисовался.

Пусть считают в разное время.

(12) Ага, что-нибудь типа вопроса "Ну чо, проводим?" висит в обработке проведения или заполнения...

"Пусть считают в разное время."
Правильно - один в первую смену, второй - во-вторую, ну а третий = ночью.. Ибо нефик.. Заодно на количестве компов сэкономят (все расчетчики могут считать на одном компе).

ПыСы... Оптимизировать код - не предлагать

(17) оптимизировать код ЗиК БУ - не предлагать точно

(18) Расчет начислений в "бюджетном учреждении" нервно курит в сторонке перед расчетом начислений на крупном производстве с кучей сменных графиков и прочих нюансов одновременно.

(18) Если "оптимизировать" = "выкинуть все костыли внедренцев", то очень даже стоит.

(19) да что Вы?! видимо с медиками не работали... зарабатывающими медиками, а не поликлиническими

(20) какие костыли внедренцев, если база типовая?

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

(21) Я делал расчеты для крупных северных предприятий - с их северными, с их надбавками, с их сменами,  перемещениями и т.д....

(22) Ни факт что "типовая".. Читам у ТС

"Кстати, данная База 1с 8.2 ЗКБУ собиралась из 6 баз 1с 7.7 ЗиК, из которых 2 были не типовые с правленой конфигурацией."

(22) Судя по (7) она совсем не типовая...

(24), (25) а судя по (0) - типовая. то, что в нее запихивали данные 6 разных баз, еще не означает снятия с поддержки.
(23) то, что Вы делали такие расчеты в ?ЗуП/УПП/КА дает Вам право говорить, что расчет в бюджете более легок?

(26) Как в (0) все говорят, а потом оказывается что перепилена половина. Да и в (7) ясно сказано, что сотрудник до сих пор приходит и что-то дорабатывает.

(26) "что расчет в бюджете более легок? "
(задумчиво) вообще-то, как я понимаю, вопросом  "сравнения" (что на свете всего сложнее) начали заниматься в (18) именно Вы. Я не прав?

(27) +++ Уже одно только " Переводили базу в течении 3-4 месяцев, до сих пор возникают ошибки в базе" говорит о том, что база сейчас уже явно "не типовая".

(29) база типовая. ошибки возникают следующего характера: не правильно рассчитывались налоги, компенсация за неиспользованный отпуск сотрудникам и т.п. в общем то, что решается средствами программы, не конфигуратора.

(30) а неправильно это как?то есть выползло сообщение и расчетчик забил?

(30) Сколько сотрудников в базе?

(32) 400-500 чел.
(31) с сотрудников не брала налог при расчёте

(8) Режим управления блокировкой данных для всей конфигурации установлен Управляемый (по умолчанию).

(33) Это большая база.
Без оптимизации кода твои расчетчики будут постоянно влетать в блокировки.

Так что тут "или - или": Или ты меняешь свой существующий бизнес-процесс расчета под типовой (например переводишь расчетчиков в сменный режим работы", либо ты меняешь типовую конфу под особенности своей бизнес-логики.

(35) перевод расчётчиков на сменный режим работы невозможен, штатное расписание менять никто не будет - бюджетное учреждение.
"оптимизировать код" - Предлагаете вносить изменения в конфигурацию? Каждую неделю выходят обновления, неужели эту проблему не могут решить производители ПП.
Посоветовали установить более мощное железо(сервак) - Возникают сомнения в том что это кардинально решит проблему, а не сделает вероятность ее возникновения меньше.

(36) еще раз - 400/500 человек не то количество сотрудников, которое нельзя посчитать поочередно. абсолютно нет необходимости расчетчикам работать в разные смены. более мощное железо может сможет помочь в плане быстроты обработки одного документа.

(36) Доступ на уровне записей используете? Если да - отключите.

(36) "Каждую неделю выходят обновления, неужели эту проблему не могут решить производители ПП. "

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

(37) На самом деле "считать начисления" на такое количество сотрудников вполне может и 1 расчетчик. А работа расчетчика это не только "нажимать кнопку расчет", поэтому вполне можно перераспределить функции без ущерба для штатки (если лом подправлять конфу под свои особенности)

(28) неа, не правы. в (18) я всего лишь сказала, что переписывать расчетные конфигурации - дело очень неблагодарное. я бы такое и про ЗуП, и про расчетный блок в УПП сказала.
(39) Вы оптимизировали расчеты? исключили блокировки? ТС можете посоветовать к себе, например, за доработками обратиться?

(40) " переписывать расчетные конфигурации - дело очень неблагодарное"

Да ладно, "переписывается все", безусловно, что аспект "расчеты ЗП" - один из сложных, но "не боги горшки обжигают".

здорово,а как связали бардак в (7) и блокировки?телепат детектед

(42) "телепат детектед"

Да нет, просто внимательно прочли в (0) "Конфликт блокировок при выполнении транзакции: "

купите нормальный сервер. а эту жесть выбросите на свалку

какая оптимизация? о чем вы говорите. на железо посмотрите. оптимизировать код и архитектуру выйдет на пару порядков дороже чем купить более менее нормальное железо с которым еще пяток лет париться об оптимизации не придется

(43)сначала данные кошерные,потом можно заниматься блокировками.рлс отключить например,ведь зачем нужно если всего 2 пользователя

(46) "рлс отключить например"
РЛС на регистр расчета в типовых никогда не ставится - не выдумывайте

договоритесь перенести к кому-нибудь на более мощный сервер свою базу и посмотрите будут блокировки или нет

(48) "договоритесь перенести к кому-нибудь на более мощный сервер свою базу "

Да-да-да.. конечно-конечно.. И заодно посадить своих расчетчиков на "чужой сервак", чтобы 100-пудово смоделировать ситуацию (и пусть поработают так месяца 2 для чистоты эксперимента)

(47) В типовой УПП есть.

(40)  Вы оптимизировали расчеты?
каким образом мы может их оптимизировать?

исключили блокировки?
тут непонятная ситуация. Перевёл базу sql на управляемые блокировки + регистр расчёта ОсновныеНачисленияРаботниковОрганизаций так же перевёл на управляемые блокировки. Результат тот же.
НО в файловой базе 1 раз расчёт одновременно с 2 пользователей прошёл, далее о5 возникала блокировка уже на др документе "Документ.НачислениеЗарплатыРаботникамОрганизаций" - так же изменил - поставил для него режим упр. блокировок.
не помогло

ТС можете посоветовать к себе, например, за доработками обратиться?
у нас договор с оф. представителем 1с на сопровождение, разве они не должны решать эту проблему?

(51) Сколько идет расчет в случае 1 пользователя?

(45) минимально-рекомендуемую конфигурацию пк-сервера какую посоветуете?
P.s. по рекомендуемым требования к windows server 2008, sql server 2008, 1c 8.2 наши ПК-сервера подходят, хотя согласен устарели оч давно

(52) не более 10-15 сек

(48) попробую завтра поднять сервак на виртуалке, на более мощном компе.
Вопрос есть ли смысл пробовать установить windows server 2003 и соответственно sql server 2003 ?

(54) Тогда надо выяснить - это просто замедление из-за параллельной работы или взаимные блокировки. Для этого надо попробовать увеличить время ожидания блокировки, допустим, до минуты.

(48) что для вас более мощный?

(47) то есть по организации и физикам для вас нет?

(56) Для этого надо попробовать увеличить время ожидания блокировки, допустим, до минуты.

как увеличить в файловой базе до минуты время ожидания блокировки?
В sql средствами самого sql

(57) i3-4130/4gb/1tb[7200об] примерно такой

купите вот такой http://www.ulmart.ru/goods/3448420
всего 20т. и ваш зуп будет летать

(59) В Конфигураторе Администрирование -> Параметры информационной базы.

(56) на sql "управляемые блокировки" не помогли:
Конфликт блокировок при выполнении транзакции: Microsoft SQL Server Native Client 10.0: Превышено время ожидания запроса на блокировку. HRESULT=80040E31, SQLSrvr: SQLSTATE=HYT00, state=2D, Severity=10, native=1222, line=1
увеличивать таймаут блокировки средствами sql пока не пробовал

в файловом варианте: {Документ.НачислениеЗарплатыРаботникамОрганизаций.МодульОбъекта(1233)}: Ошибка при вызове метода контекста (Записать)
    НаборЗаписейРабочееВремя.Записать();
по причине:
Конфликт блокировок при выполнении транзакции:
(61) попробую

(62) управляемые блокировки?

(61) увеличил время ожидания блокировки до 90 сек. Двое сотрудников одновременно рассчитали по 1 человеку, в sql варианте.
В файловом варианте конфликт блокировок


(63) Имеется ввиду: Установка режима блокировок в конфигурации - на управляемые

тоже давно воюю с блокировками, хочу снизить количество, прочел недавно интересную инфу http://www.softpointplus.ru/poddergka-subd/blokirovki-v-rabote-it-i-sql-subd.html там ссылка на статью подробную есть.

есть 3 основных пути ухода от "блокировок":
1. наращивание железа
2. оптимизация кода (запросов)
3. управляемые блокировки

в вашем случае при катастрофической нехватки мощей и полном отсутствии компетенции в п.2 и п.3 - единственный вариант (причем самый менее трудо и финансово затратный в вашем случае) - это наращивание железа.

(66) Нуф-Нуф, не мути воду, пусть переписывает код.

(66) Вы по-моему путаете блокировки и взаимоблокировки. У ТС как раз последние. А от них наращиванием железа не уйти.

(64) В файловом варианте блокируется вся таблица, так что, видимо, без клиент-сервера не обойтись.

(68) чета не нашел в сообщение ТС про дэдлок ни слова, ожидание у него на блокировках.

(70) Что-то я тоже теперь не нахожу. Это (6) все запутал. :)

Похожая ситуация. Типовая УПП, несколько расчетчиков. Расчет з/п марта + одновременная работа с табелем апреля, даже по разным подразделениям = дедлок.
Саппорт 1С пока отмазывается в стиле "это не баг, а фича"

(6) > терминальный и sql сервер ещё на более древнем компе(1 гб ОЗУ)

Это не сервер. Это смартфон. (с) кто-то из мистян.

> файловая на обычном ПК (Dual-Core E5200, (2.50/800/2Mb); 2GB DDRII-800; Seagate (320 Gb/ 7200/8Mb/ SATA )

Для файловой в монопольном доступе это может быть и потянет. В сетевом доступе с одновременной работой пользователей с одними и теми же таблицами на запись - этого явно мало.

> "Конфликт блокировок при выполнении транзакции" = Дедлок

У вас явно проблема с ожиданием на блокировках. Учитывая, что конфа типовая и переписывание кода не рассматривается, то лечится только увеличением производительности железа.
Возможны конечно еще и проблемы с самими данными, но удаленно об этом судить невозможно.

Так что ИМХО, абсолютно правы
> Фирма, которая осуществляет сопровождение причиной называло медленный компьютер на котором стоит база

Из опробованных вами вариантов
- файловый вариант можно рассматривать, если только база будет вертеться на нормальном производительном файловом сервере (НЕ на обычном компьютере в сети, а именно на полноценном настроенным сервере)
- клиент-серверный вариант однозначно не на том железе, которое вы по какому-то недоразумению называете сервером. И на этом сервере ничего не должно быть кроме СУБД и 1С (никаких почтовых серверов, терминальных, контроллеров домена и прочих служб и сервисов).

(73) > Это не сервер. Это смартфон. (с)
согласен.
"Смартфон" за неимением более производительного ПК был использован для пробы, как поведут себя блокировки в клиент-серверном варианте.
P.s. по рекомендуемым системным требованиям (со слов поддержки) используемых программных продуктов и ОС, на "смартфоне" должно всё хорошо работать. хотя вариант с сервером терминалов здесь нецелесообразен в связи с более худшим железом на "смартфоне", чем на ПК пользователей.

ssd есть смысл покупать-ставить или использовать стандартные HHD для сервера?

В ближайшее время, если будет возможность, купим "полноценный" сервер.
По результатам обязательно отпишусь.

(0) (74) У вас ФАЙЛОВАЯ база, переключаться между автоматическим и управляемым режимом блокировок бесполезно.
В файловом варианте блокируются таблицы целиком.
В вашем случае выход один - считать зарплату в монопольном режиме

http://1c.ru/news/info.jsp?id=17577

всего 14 400 руб.... и скуль бесплатный...

(75) > В вашем случае выход один - считать зарплату в монопольном режиме
не вариант в монопольном.

есть второй выход: купить норм железо-сервер.

(76) ИМХО не совсем в тему ссылка, если я правильно понял.
Из моего 0 поста следует, что у нас уже имеется MS SQL Server 2008, сервер 1С:Предприятия 8.2, клиент-серверная версии 1С: Предприятие 8.2

блин, тут остались вообще спецы или нет? неужели только я один вижу что на "еще более древнем чем (Dual-Core E5200, (2.50/800/2Mb); 2GB DDRII-800; Seagate (320 Gb/ 7200/8Mb) и с 1Гб ОЗУ)" ничего сделать нельзя. ну нет тут предметного разговора.

(78) да да ты один супер крут, может ветку почитаешь?

(79) а что там?

(80) читай еп ))

человек хочет задрочить базу блокировками в файловом режиме, пусть дальше терзает

(81) ты о чем? у человека маленькая базы с типовой конфигурацией, которая тратит на простую процедуру столько времени, что успевает повесить другого пользователя, а все из-за 1гб на винду, скуль, сервер 1с и два терминальных подключения.

(82) да попутал я, чет думал, что он говорил, что на нормальном серваке пытался, а он до сих пор олень. Согласен с тобой

(83)> да попутал я, чет думал, что он говорил,
eklmn уважаемый Алёша, вы по жизни "попутали" и верно сказали, что не думаете, когда говорите.
(81)> человек хочет задрочить базу блокировками в файловом режиме, пусть дальше терзает
рассматривается одновременно и клиент-серверный вариант, вы опять несёте чушь. По существу вам сказать и предложить нечего, а нафлудили вы достаточно, с вами закрыли эту тему.

(81) Спс информацию, я услышал вас и других умных людей, компетентных в этом вопросе и сделал выводы.

(84) а какие выводы сделаны, если не секрет?

+(84) Тоже почитал бы про выводы, а то чета нафлудили вагон, а по существу 0. Рассказал бы по какому ресурсу блочится, хоть анализ бы провел, тогда можно и варианты искать решения.

(86) еще один

(86) ты бы еще сказал ЦУП развернуть, профайлер посмотреть.

+(88) уже говорил :)

Ну помочь вроде хотим же.

(90) чем поможешь неадеквату?

(85) в вашем случае при катастрофической нехватки мощей и полном отсутствии компетенции в п.2 и п.3 - единственный вариант (причем самый менее трудо и финансово затратный в вашем случае) - это наращивание железа. (с) Ваши слова.
вывод - Будем покупать новое железо.
(91) не неадекват, а некомпетент. Я понимаю, что вы местный тролль, давайте не будем засорять тему, пожалуйста. Может этот пост поможет др. людям, а им не интересно будет читать вашу чушь, не по теме.

ахахаха, всех обо$рал и все равно сделал как ему сказали

(92) аааааа! спасибо. камень с души упал. а думал ваще безнадега.

Ну вот, а говорили безнадега,неадекват.

(94) учреждение гос. бюджетное и задачи всегда ставят примерно так: Денег нет и не будет! Через неделю всё должно работать!
Жуём этот вопрос долго, так как мы недостаточно компетентны в нём и поэтому пытались решить его без финансовых вливаний, что понятно - невозможно.

(96) возможно, но Вы не хотите регламентировать работу расчетчиков.

(97) кстати вариант.

(97) вопрос не в моей компетенции, но как временное решение  его уже прорабатываем.

(99) на самом деле... странно все это... они либо чего-то не успевают делать, потому что с них требуют результат по расчету слишком рано, либо они не хотят ничего делать с ситуацией. так как у меня не одно гос.учреждение (а в одном даже канцтовары периодически начинают покупать себе сами), то я знаю о вопросах финансирования. и расчетчики как-то договариваются о том, кто и что проводит.

(99) Расскажи им как раньше было: идешь со своим набором перфокарт, стоишь в очереди к ЭВМ...