Как я диагностировал проблемы блокировок. Как я диагностировал проблемы блокировок Ошибка блокировки транзакции 1с 8.3

Не мог записать изменения для передачи в распределенную базу, обратился в поддержку 1с предложили следующее. У меня решилось просто перезагрузкой сервера приложений и cсервера с SQL. Вообще можно поставить галочку «Блокировка регламентных
заданий включена»
Тоже помогло без перезагрузки.

Регламентные операции на уровне СУБД для MS SQL Server

Инструкция по выполнению регламентных операций на уровне СУБД.

Информация применима к клиент-серверному варианту 1С:Предприятия 8 при использовании СУБД MS SQL Server.

Общие сведения

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

Если в работающей системе наблюдаются какие-либо симптомы проблем с производительностью, следует проверить, что в системе правильно настроены и регулярно выполняются все рекомендуемые регламентные операции на уровне СУБД.

Выполнение регламентных процедур должно быть автоматизировано. Для автоматизации этих операций рекомендуется использовать встроенное средства MS SQL Server: Maintenance Plan. Существуют так же другие способы автоматизации выполнения этих процедур. В настоящей статье для каждой регламентной процедуры дан пример ее настройки при помощи Maintenance Plan для MS SQL Server 2005.

Рекомендуется регулярно контролировать своевременность и правильность выполнения данных регламентных процедур.

Обновление статистик

MS SQL Server строит план запроса на основании статистической информации о распределении значений в индексах и таблицах. Статистическая информация собирается на основании части (образца) данных и автоматически обновляется при изменении этих данных. Иногда этого оказывается недостаточно для того, что MS SQL Server стабильно строил наиболее оптимальный план выполнения всех запросов.

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

Для того, чтобы гарантировать максимально правильную работу оптимизатора MS SQL Server рекомендуется регулярно обновлять статистики базы данных MS SQL.

Для обновления статистик по всем таблицам базы данных необходимо выполнить следующий SQL запрос:

exec sp_msforeachtable N"UPDATE STATISTICS ? WITH FULLSCAN"

Обновление статистик не приводит к блокировке таблиц, и не будет мешать работе других пользователей. Статистика может обновляться настолько часто, насколько это необходимо. Следует учитывать, что нагрузка на сервер СУБД во время обновления статистик возрастет, что может негативно сказаться на общей производительности системы.

Оптимальная частота обновления статистик зависит от величины и характера нагрузки на систему и определяется экспериментальным путем. Рекомендуется обновлять статистики не реже одного раза в день .

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

Настройка автоматического обновления статистик (MS SQL 2005)

Запустите MS SQL Server Management Studio и подключитесь к серверу СУБД. Откройте папку Management и создайте новый план обслуживания:

Создайте субплан (Add Subplan) и назовите его «Обновление статистик». Добавьте в него задачу Update Statistics Task из панели задач:

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

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

Обновление статистик необходимо проводить с включенной опцией Full Scan.

Сохраните созданный план. При наступлении указанного в расписании срока обновление статистик будет запущено автоматически.

Очистка процедурного КЭШа

Оптимизатор MS SQL Server кэширует планы запросов для их повторного выполнения. Это делается для того, чтобы экономить время, затрачиваемое на компиляцию запроса в том случае, если такой же запрос уже выполнялся и его план известен.

Возможна ситуация, при которой MS SQL Server, ориентируясь на устаревшую статистическую информацию, построит неоптимальный план запроса. Этот план будет сохранен в процедурном КЭШе и использован при повторном вызове такого же запроса. Если Вы обновили статистику, но не очистили процедурный кэш, то SQL Server может выбрать старый (неоптимальный) план запроса из КЭШа вместо того, чтобы построить новый (более оптимальный) план.

Для очистки процедурного КЭШа MS SQL Server необходимо выполнить следующий SQL запрос:

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

Настройка очистки процедурного КЭШа (MS SQL 2005)

Поскольку процедурный КЭШ необходимо очищать при каждом обновлении статистики, данную операцию рекомендуется добавить в уже созданный субплан «Обновление статистик». Для этого следует открыть субплан и добавить в его схему задачу Execute T-SQL Statement Task. Затем следует соединить задачу Update Statistics Task стрелочкой с новой задачей.

В тексте созданной задачи Execute T-SQL Statement Task следует указать запрос «DBCC FREEPROCCACHE»:

Дефрагментация индексов

При интенсивной работе с таблицами базы данных возникает эффект фрагментации индексов, который может привести к снижению эффективности работы запросов.

sp_msforeachtable N"DBCC INDEXDEFRAG (<имя базы данных>, ""?"")"

Дефрагментация индексов не блокирует таблицы, и не будет мешать работе других пользователей, однако создает дополнительную нагрузку на SQL Server. Оптимальная частота выполнения данной регламентной процедуры должна подбираться в соответствии с нагрузкой на систему и эффектом, получаемым от дефрагментации. Рекомендуется выполнять дефрагментацию индексов не реже одного раза в неделю.

Возможно выполнение дефрагментации для одной или нескольких таблиц, а не для всех таблиц базы данных.

Настройка дефрагментации индексов (MS SQL 2005)

В ранее созданном плане обслуживания создайте новый субплан с именем «Реиндексация».Добавьте в него задачу Rebuild Index Task:

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

Реиндексация таблиц базы данных

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

sp_msforeachtable N"DBCC DBREINDEX (""?"")"

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

После выполнения реиндексации нет необходимости делать дефрагментацию индексов.

Настройка реиндексации таблиц (MS SQL 2005)

В ранее созданном плане обслуживания создайте новый субплан с именем «Дефрагментация индексов». Добавьте в него задачу Rebuild Index Task:

Задайте расписание выполнения для задачи реиндексирования таблиц. Рекомендуется выполнять задачу во время минимальной нагрузки на систему, не реже одного раза в неделю.

Настройте задачу, указав базу данных (или несколько баз данных) и выбрав необходимые таблицы. Если точно неизвестно, какие таблицы следует указать, то устанавливайте значение All.

Что такое блокировки в 1С, зачем они нужны и как избежать проблем при работе с ними

Наверняка многие из Вас при использовании информационных систем 1С Предприятие (1С 7.7, 1С 8.1, 1С 8.2, 1С 8.3) сталкивались с таким явлением, как блокировки. Причем, как правило, все называют это явление по-разному: «Блокировки 1С», «Конфликт блокировок 1С», «Ошибки блокировок 1С», «Блокировки транзакций 1С» и прочие названия. Давайте кратко разберемся в том, что такое блокировки (не взаимоблокировки), зачем они нужны и как избежать проблем при работе с ними.


Сами по себе блокировки (в том числе в 1С и в других системах) полезный инструмент, который обеспечивает возможность последовательной работы с общими ресурсами. Для примера, понятие «общие ресурсы» окружает нас по жизни, например, пока Вы управляете автомобилем никто другой не может им управлять. Следовательно, автомобиль – общий ресурс. А второй водитель ожидает пока Вы приедете, например, Ваша жена/муж. Вы оба конкурируете за общий ресурс – автомобиль. Кто будет управлять автомобилем в текущий момент Вы определяете на понятийном уровне, а как нам быть в автоматизированных системах??? Для этого и придумали инструмент блокировки , которые обеспечивают организацию процесса доступа к общему ресурсу и определяют очередь. Как правило в жизни, как и в информационных системах (1С 7.7, 1С 8.1, 1С 8.2, 1С 8.3), общих ресурсов очень много, поэтому и блокировок тоже много. Теперь второй важный момент – как долго будет ждать освобождение вашего автомобиля жена/муж, логично предположить, что не вечно. Поэтому для блокировок задается предельное время ожидания – иначе время таймаута. Таймаут - это максимальное время ожидание конкурирующим участником (вашей жены/мужа) освобождения общего ресурса. Дальше либо он продолжает ждать еще такое же время, либо идет пешком. В информационных системах 1С истечение таймаута заканчивается сообщением «Конфликт блокировок 1С», «Ошибки блокировок 1С», «Блокировки транзакций 1С», «Таймаут при блокировке».

Важная деталь, которую также следует помнить, блокировки (в частности в 1С) бывают явные (задаются пользователем) и неявные (задаются платформой SQL). В статье мы говорим о явных блокировках, поэтому они всегда используются в транзакции, отсюда выходит, что «Блокировка 1С» и «Блокировка транзакций 1С» синонимы.

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

  • Множество блокировок 1С в транзакции;
  • Длительность транзакции.

Для минимизации сообщений, связанных с ошибками блокировок, необходимо либо уменьшать множество блокировок (оптимизировать селективность), либо уменьшать длительность транзакций.
Теперь определимся каким образом на эти показатели можно влиять в реальной информационной системе 1С.

Для уменьшения множества блокировок:

В 1С:Предприятие 7.7:

Информационная система 1С 7.7. для блокировок используют табличные блокировки, которые парализуют работу пользователей. Как правило более 50 человек в одной базе данных не могут безошибочно работать, при этом проблемы могут появляться и в базах данных от 20 пользователей.
Решение:

  • Гибкие блокировки 1С от компании «Софтпоинт». С их помощью вы не только оптимизируете множество блокировок (замена табличных блокировок на пользовательские), но и ускорите подборы, поиски и отчеты.
В 1С:Предприятие 8.x:
Информационная система 1С 8.1., 1С 8.2., 1С 8.3. в автоматическом режиме использует избыточные блокировки вида (REPEATABLEREAD, SERIALIZABLE). Это приводит к ухудшению работы пользователей от 100.
Решение:
  • Управляемые блокировки 1С – встроенное средство платформы 1С для более селективной настройки блокировок. Чтобы его использовать, программист должен сам прописать в нужных местах кода специальные операторы, чтобы заблокировать нужные (по его мнению! ) записи в таблицах информационной системы;
  • Гибкие блокировки 1С – технология компании Софтпоинт для замены стандартных блокировок на пользовательские.

Для уменьшения длительности транзакций:

Для любых информационных систем 1С (1С 7.7., 1С 8.1, 1С 8.2, 1С 8.3) как и для других информационных систем применяется схожие подходы:

    Проверка и правильная настройка регламентного обслуживания базы данных (обслуживание файлов, индексов, статистик, базы временных таблиц, настройка Windows и SQLServer);

    Анализ и оптимизация тяжелых запросов 1С и SQL (индексный тюнинг, переписывание запросов);

    Проверка на избыточность транзакций. Во многих случаях необоснованно в транзакцию включают операции не осознавая, как это повлияет на длительность, а вместе с ней на производительность.

  1. Если Вы хотите самостоятельно разбираться с техническими проблемами производительности 1С (1С 7.7, 1С 8.1, 1С 8.2, 1С 8.3) и других информационных систем , то для Вас уникальный список технических статей в нашем Альманахе (Блокировки и взаимоблокировки, большая нагрузка на CPU и диски, обслуживание баз данных и индексный тюнинг - лишь малая часть технических материалов, которые Вы там найдете).
  2. сли Вы хотите обсудить с нашим экспертом проблемы производительности или заказать решение мониторинг производительности PerfExpert , то оставьте заявку и мы свяжемся с Вами в кратчайшие сроки.

Когда с программами и данными одновременно работают сотни пользователей, появляются проблемы, свойственные только масштабным решениям. Речь о проблемах, вызванных блокировками данных.

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

Проблемы, вызванные блокировками, не имеют общего решения. Поэтому мы попробуем проанализировать причины возникновения таких проблем и систематизировать варианты их решения.

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

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

Пример 1: покупка билета на самолет или поезд. Предположим, мы озвучили свои пожелания кассиру. Кассир сообщает нам наличие свободных мест, из которых мы можем выбрать наиболее понравившееся (если их несколько, конечно). Пока мы выбираем и подтверждаем своё согласие с предлагаемым вариантом, эти места не могут быть проданы кому-либо еще, т.е. временно «блокируются». Если бы они не блокировались, то к моменту подтверждения могла бы быть ситуация, когда выбранные нами билеты уже проданы. А в этом случае цикл выбора может быть непрогнозируемого количества повторений. Пока выбираем места, а их уже продали!.. Пока выбираем другие, и их уже нет...

Пример 2: покупка чего-либо в магазине или на базаре. Подошли мы к прилавку, выбрали самое красивое яблоко из сотни доступных. Выбрали и полезли в карман за деньгами. Как будет выглядеть, если в тот момент, пока мы считаем деньги, именно выбранное нами яблоко будет продано подошедшему позже нас покупателю?

Таким образом, сама по себе блокировка - это нужное и полезное явление. Именно благодаря блокировке мы гарантируем выполнение действий за один этап. А к негативу чаще всего приводит не самая удачная реализация программного обеспечения, когда, например:

  • блокируется избыточное количество объектов (билетов, яблок);
  • время блокировки необоснованно растягивается.

ИЗБЫТОЧНЫЕ БЛОКИРОВКИ В ТИПОВЫХ КОНФИГУРАЦИЯХ 1С

На крупных проектах, как правило мы используем «1С:Предприятие». Поэтому практические рекомендации решения проблем блокировок мы попробуем описать на примере связки «1С:Предприятие»+MS-SQL.

8-е поколение 1С:Предприятия обеспечивает очень и очень неплохую параллельность использования. Одновременно с одной конфигурацией (то есть на одной базе) при нормальных серверах и каналах связи может работать огромное количество пользователей. Например, сотни кладовщиков оформляют выдачи или поступления товаров, экономисты одновременно считают затраты на оплаты труда по различным подразделениям, расчетчики проводят расчет и начисление зарплаты и т.д.

Но есть причина, из-за которых бытует мнение об обратном - миф о том, что при интенсивном одновременном использовании работать с решениями на базе 1С:Предприятия некомфортно или невозможно. Ведь как только типовые решения под 1С:Предприятие начинают использовать сотни пользователей на промышленных масштабах, всё чаще на экране появляется окошко с гордой надписью: «Ошибка при вызове метода контекста (Записать): Конфликт блокировки при выполнении транзакции: ...» и дальше в зависимости вида применяемого SQL-сервера что-то типа «Microsoft OLE DB Provider for SQL Server: Lock request time out period exceeded. ...».

Почти все типовые решения в предлагаемой «из коробки» реализации настроены на автоматический режим управления блокировками. «Автоматический» тут можно воспринимать как «параноидальный». На всякий случай при проведении любого документа блокируем всё, что хоть как-то с ним может быть связано. Вот и получается, что когда один пользователь что-то проводит (а иногда и просто записывает), остальные могут только ожидать.

Выскажу свое мнение, почему 1С решила не настраивать свои типовые решения под высокую параллельность использования. Трудозатраты на такую доработку не высоки - несколько «человекомесяцев», что по масштабам 1С не значимо. Мне кажется причина в другом.

Во-первых, такая доработка значимо усложняет обработчики проведения всех документов. А значит для тех потребителей, кто использует 1С на небольших задачах, без какого-либо выигрыша будет только недостаток - сложность доработки типовой конфигурации усложнится. Статистика в то же время подсказывает, какая категория клиентов является основной кормушкой для 1С...

Вторая причина зарыта в типовых базовых настройках SQL-серверов, например, MS-SQL, который всё еще используется чаще других. Так уж повелось, что приоритеты в настройках отданы экономии оперативной памяти серверов, а не сокращению блокировок. Это приводит к тому, что при необходимости заблокировать несколько строк SQL-сервер принимает «экономное» для памяти и процессора решение - заблокировать сразу всю таблицу!..

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

РЕКОМЕНДАЦИИ ПО УСТРАНЕНИЮ ИЗБЫТОЧНЫХ БЛОКИРОВОК ДЛЯ 1С:ПРЕДПРИЯТИЯ

Что же делать, если решение проблем избыточных блокировок настолько важно?

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

Т.к. данная операция крайне важна, её приходится выполнять постоянно. Поэтому для упрощения проведения подобной доработки мы выработали ряд основных рекомендаций, которых стараемся придерживаться. Рекомендаций, полученных и проверенных на опыте значительного количества масштабных внедрений.

  1. Если используемая СУБД или система разработки (например, 1С:Предприятие) по умолчанию использует автоматический режим блокировки данных, откажитесь от автоматического управления блокировками. Настройте правила блокировок самостоятельно, опишите критерии блокировки целых таблиц или отдельных строк.
  2. При разработке программы всегда, когда это возможно, обращайтесь к таблицам в одном порядке.
  3. Постарайтесь не писать в одну и ту же таблицу несколько раз в пределах одной транзакции. Если это сложно, то хотя-бы минимизируйте промежуток времени между первой и последней операцией записи.
  4. Проведите анализ возможности отключения эскалации блокировок на уровне SQL-сервера.
  5. Внятно информируйте пользователей о причинах невозможности выполнения каких-либо действий, если они обусловлены блокировками. Давайте доступные и понятные рекомендации, что делать дальше.

Если внимательно посмотреть на рекомендации, то становится понятным, что подобная отработка уместна не только для 1С:Предприятия, но для любых систем . Абсолютно не важно на каком языке они написаны и с каким работают сервером БД. Большинство рекомендаций имеют универсальный характер, а потому одинаково справедливы и при использовании 1С:Предприятия, и для «самописных» программ или других «коробочных» ERP-систем.

P.S. А Вы знали о том, что мы предлагаем профессиональную помощь с обновлением 1С по лучшей цене?

Тэги для поиска:
  • Блокировки транзакций
  • Устранение блокировок
  • Блокировки 1С
  • Блокировка
  • Конфликт блокировок
  • Конфликт блокировок при выполнении транзакции

Вопрос: УТ11.1. Пакетное создание Реализаций. Конфликт блокировок


Добрый день! Конфигурация УТ11.1. Клиент-серверный вариант. Настройки 1С Сервера и SQL Сервера по умолчанию. Программно формируем реализации. На этапе записи документов периодически возникает конфликт блокировок. Подскажите каким образом решаются подобные вопросы? Используются транзакции c управляемыми блокировками? Заранее спасибо.

Ответ:
не надо выключать) переведи их на ночь - там может и расчет себестоимости и индексы поиска считаются.

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


Каждый день почти в одно и тоже время при проведении документа на 5-10 минут выскакивает данная ошибка 1С 8.3.10.26.99 УТ11(11.4.1.261):
Конфликт блокировок при выполнении транзакции:
Microsoft Sql Server Native Client 11.0: Превышено время ожидания запроса на блокировку.
HERESULT=80040E31, SqlServer: SQLSTATE=HYT00, state=38, Severity=10, native=1222, line=1
Подскажите от куда начинать копать?

Ответ: () Включи профайлер в это время на события Lock:Acquired и Lock:Escalation. Потом доложи что поймал.

Вопрос: Восстановление базы (конфликт блокировок)


Добрый день. База помирает. Серверная.
Выяснилось не сразу, т.к. все работало кроме документа сф выданный. А его не так часто создают. Поэтому бекап не актуален (прошло уже видимо несколько дней), пытались разворачивать копию 2х дневной давности - полдня было нормально, а потом вылезла та же проблема.

Симптомы: при попытке отмены проведения сф получаем конфликт блокировок, даже если один пользователь в базе. ТИИ (проверка логической и ссылочной целостности) валится с конфликтом блокировок, создание бекапа через sql management studio - то же ("Превышено время ожидания типа кратковременной блокировки буфера 3 для страницы").

Хотим попробовать залить cf недельной давности, но что-то надежд мало.

Ответ: тут проблемы с сервером баз данных, а не 1С, версий конфигурации и пр. ни при чем.
Возможно не обслуживаемый скул жил как мог покуда хватало ресурсов, а теперь у автора начинается новый этап освоения знаний.
Если размер позволяет - выгружайте в файловую и начинайте изучать sql глубже.

Вопрос: УТ10. Конфликт блокировок


Добрый день! Клиент-серверный вариант. Мне досталась в наследство сильно доработанная конфигурация БитАвто (автосервис на базе УТ10). В обработчике проведения документа "заказ-наряд", основного для мастеров-приемщиков и менеджеров, завернуто формирование подчиненных документов (реализация, счет-фактура, требование накладная), расчет з/п механиков, резервирование товара, если новый документ, то создание заказа-покупателя и еще некоторый функционал. База выросла и часто стал возникать конфликт блокировок. По выходным, когда народа меньше конфликтов нет.

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

Если обработчиком кнопки "Ок" сделать свою процедуру, где последовательно запускать "ОбработкаПроведения", а потом процедуру, например, СформироватьПодчиненныеДокументы, затем РассчитатьЗарплату и т.п. Не уверен, что такой вариант поможет. Добавлять кнопки на которые навешивать формирование документов не подойдет, т.к. пользователи будут забывать про нее.

Ответ:

Zerro
vde69,

Дак это наверное какая-нибуть Раруская фигня

Нет, это не Рарус, это БитАвто

Вопрос: 1c конфликт блокировок при открытии формы документа


УПП
С недавнего времени раз в 2-3 дня возникает блокировка на документе Требование-накладная. Т.е. ни один документ этого типа не открывается. Все время
Другие документы работают нормально.
В отладчике проблем не нашел, ни в одном модуле не успевает остановиться - сразу конфликт блокировок.
Я подозреваю какую-то проблему в SQL.

Ответ: Проблема была в не завершившемся задании обслуживания индексов.

Вопрос: ошибка SQL2000 в процессе выполнения транзакции в 1С77


в MSSQL база 1С77(релиз 27) ТиС. Регулярно при выполнении проводок выскакивает ошибка:

При выполнении транзакции произошла ошибка!
SQL State: HYT00
Native:0 Message: Время ожидания истекло.

в итоге провести документ не удается. Это может длиться 20 мин., а может и 1 час.
Как с этим бороться, где копать?

С Уважением,
Steve242

К сообщению приложен файл. Размер - 21Kb

Ответ:

штатный perfmonitor винды показал что на Терминальнике идет адовая загрузка системного диска C:\.
Все остальное: Память, CPU - на обоих серверах(терминальник и скуля) практически никаких аномальных всплесков не отображает.

я создал RAMdrive на 2Gb (из 12Gb, имеющихся на терминальном сервере физически) и пытаюсь перенаправить туда tempовые системные каталоги профилей пользователей терминала.
пока как-то так.

Вопрос: Еще раз, про Конфликт блокировок при выполнении транзакции


Проблема описана хорошо на форумах. Но для моего случая Решения не видел. Опишу мою проблему пошире.
УПП 1С:Предприятие 8.2 (8.2.19.90) редакция 1.3 (1.3.74.1)
возникает ошибка такая ошибка.... Везде. Почти при проводке каждого документа.
А Эта, ниже при...- выгрузике информационной базы в.Конфигураторе

Понятно, что это не простое блокирование документа. Даже опишу начало возникновения этой проблемы. На ночь поставил Перепроводку документов за квартал.
Она закончилась ошибкой

Все после этого ПРОВОДКИ ЛЮБЫХ ДОКУМЕНТОВ приводит в ошибки блокировки.
Думаю что проблема в MSSQL . Помогите, кто встречался с этой проблемой. Может
поможет переход на новую версию.

Ответ:

попробуйте сделать dbcc checktable with no_infomsgs для таблицы этого регистра. По идее должны быть ошибки

Вопрос: Блокировки при подписке на РТиУ


Коллеги подскажите. Конф Упп 1.3.
Компания включает несколько фирм. Пусть фирма 1 - главная, фирма 2 - продажная. Есть подписка на проведение РТиУ в момент, когда из фирмы 2 происходит продажа внешним контрагентам. Подписка создает автоматическую перепродажу(из фирмы 1 в 2): создается еще одна РТиУ и расходный ордер, плюс создает поступление товаров и услуг в фирму 2.
Плюс я сделал еще подписку на эту РТиУ в момент перепродажи просто происходит запись в свой регистр определенных данных.

Так вот периодически у пользователя, который делает реализацию внешним контрагентам - происходит конфликт блокировок при выполнении транзакции. Главное день может не быть проблем - все проводится, а бывает просто пользователь замучает: не проводится и все(конфликт блокировок), регламентные в этот момент не выполняются(если выполняются, понятно что блок из за них). Я полагаю дело в подписках, т.к. проблема возникает у юзера, который как раз делает продажу из фирмы 2.
Как оптимизировать этот момент?
Подписки выполняются после события, как они могут влиять? Не могу понять, где косяк. Вообще все события происходят неявно в 1 транзакции? Может перепродажу надо сделать в другой надо? И вообще косяк в самом доке РТиУ или все таки в перепродажах(других РТиУ, РО, ПТиУ), которые создаются автоматом, как понять?

Ответ:

У меня только при закрытии бывает тр-тр-тр, видимо какой-то замок не "понимает" что он закрылся и тыркает сам себя N-ное число раз.

Вопрос: Linux, Postgres, Розница 2.0.5.1 Украина РИБ по магазину - ошибка блокировки...


Может кто-то подскажет? Настраиваю обмен по магазину. Все нормально работает, руками получается делать обмен. 4-5 сообщений пересылаются. Потом настраиваю сценарий по расписанию и начинаются качели... Первая ошибка:

"Ошибка записи данных в файл сообщения обмена: {Обработка.КонвертацияОбъектовРаспределенныхИнформационныхБаз.МодульОбъекта()}: Error calling context method (ЗаписатьИзменения): Lock conflict during the transaction:
Maximum idle time for lock access has been exceeded due to the wait for the session"

Все последующие:

"Ошибка записи данных в файл сообщения обмена: {Обработка.КонвертацияОбъектовРаспределенныхИнформационныхБаз.МодульОбъекта()}: Ошибка при вызове метода контекста (ЗаписатьИзменения): Конфликт блокировок при выполнении транзакции:
Превышено максимальное время ожидания предоставления блокировки"

Ни переиндексация, ни закрытие сеансов не помогает. Блокировок в 1С не стоит. Помогает только удаление базы и создание снова.
Как я понял блокировка проходит в СУБД? Использую Postgress на Linux, 1 база, 4Гб оперативки. Если я прав, вопрос - Неправильно настроен Postgress или нехватка памяти? Или может вообще проблема не в этом?

Ответ: () Так то свежий - это 8.3.10.2375

Вопрос: Ошибка блокировок при очистке регистра сведений


Запросом выбираю записи РС, далее:

НаборЗаписей.Загрузить(РезультатЗапроса.Выгрузить()); НаборЗаписей.Очистить(); НаборЗаписей.Записать();
При попытке записать вываливается ошибка:

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

В чем причина ошибки?

Ответ: ()"Я почему-то был уверен, что отбор применяется только в момент чтения, а записывается соответственно то, что попало в отбор." - где у тебя в коде хоть раз используется слово "отбор"?