Есть документ, который делает запись в регистр сведений, но перед записью в регистр, он собирает данные запросом из этого же регистра. Запрос тяжелый, поэтому иногда возникают блокировки, т.к. он выполняется в ОбработкеПроведения,  т.е. в транзакции. А значит при выполнении этого запроса блокируется весь РС и в него в этот момент уже никто ничего записать не может.
Подкиньте идею как это можно избежать. Как вытащить этот запрос "извне" транзакции записи (модуль формы не предлагать)?

упростить запрос тоже не предлагать??
кстати, регистр записи не блокируется... блокируются записи, попавшие в отбор по регистру.

(0) Проверка перед проведением?

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

Если блокировки возникают, значит это кому-нибудь нужно...)))

ДЛЯ ИЗМЕНЕНИЯ юзай, чтоб провести таки смог, пусть сотальные подождут

(1) Упростить - это конечно первое, что надо сделать. Но пока это невозможно.

>> кстати, регистр записи не блокируется... блокируются записи, попавшие в отбор по регистру.

Можно поподробнее?
У меня там одно измерение. Подчинен регистратору, Периодичность по позиции регистратора. Есть вот такие участки:

ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.МойРС КАК МойРС
   |                ПО ДругаяТабл.Оборудование = МойРС.Оборудование
   |                    И (МойРС.Регистратор.МоментВремени > &МоментВремени)
   |                    И (НАЧАЛОПЕРИОДА(МойРС.Период, ДЕНЬ) = НАЧАЛОПЕРИОДА(ДругаяТабл.Дата, ДЕНЬ))

(2) не понял вопроса

(6) давай запрос полностью, шо ле

(5) мне б наоборот, сделать так, чтоб запрос выполнял "грязное" чтение и не накладывал блокировку на таблицу

(6) За это МойРС.Регистратор.МоментВремени повесить на первом суку.

(9) обычный запрос и не накладывает блокировку

(8) он тут не поместиться. И особо править его сейчас без тестов не могу. Там много нюансов, которые могу упустить

упправляемые блокировки вместо автоматических?

(12) да ладно, не ломайся :)

(11) в транзакции - накладывает

(9) тогда убери из запроса "ДЛЯ ИЗМЕНЕНИЯ"

(13) Тут рано еще пушку доставать, можно ище и винтовкой разобраться.

база файловая поди ещё?

(15) давно ли? :)

(15) не верю (с)

(10) а практический совет есть?

(0) Перепиши запрос на нормальный или организуй корректное хранение данных.

(22) это понятно, но это не одной недели/месяца работы

(19) да, давно. Можешь проверить

(21) если скл то переведи на управляемые блокировки и он ничего не будет блокировать

(19) например вот: v8: Тормоза при выполнение запроса в транзакции

(21) Судя по запросу он должен выполняться максимально долго. Надо его переписать. выносить из транзакции запросы к данным необходимые при записи оъекта не правильно.

(25) СКЛ. Блокировки управляемые

(19) (20) Вы чего? Всегда в автоматическом режиме на читаемые данные наклыдвалась разделяемая блокировка

(23) Лучше поработать в этом направление чем ловить блох в свитере Мани.

(27) Это не контроль остатков, оно там особо и не нужно

(31) если нужен при проведении, то выносить нельзя.

(10) Саш, а конкретно
МойРС.Регистратор.МоментВремени

на что изменил бы?
Отдельное левое соединение с регистратором и на него условие?

(29) пошёл читать библию...

(33) У тебя и так не явное левое соединение. Лучше всего пакетником собрать нужные Ссылки с отбором по моменту времени, а потом отобрать рс.

(35) + Чем больше типов сидит в "Регистраторе" тем быстрее будет явное соединение. Но структуру регистра надо перерабатывать. Например добавить реквизит.

(28) в этом доке стоят управляемые?

(35) Я не тупой и понимаю как оно там делается. но вот твои упреки без конкретики меня и насторожили.

>>Лучше всего пакетником собрать нужные Ссылки с отбором по моменту времени, а потом отобрать рс.

точно лучше не будет

(37) да

тогда не должно блокироваться....

(38) Будет. Так как при не явном соеднинии тянутся все поля. А тебе только ссылки нужны.

(41) А на пакетник Скуль может более оптимальный план нарисовать. В твоем случае на каждую строку РС строится отдельный цикл перебора записей регистраторов - что далеко не оптимально

(42) ОК, убедил. Здесь можно и явно задать соединение.
Регистраторов очень много, выносить их выборку в отдельную ВТ точно не буду

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

(43) Все ровно это мышиная возня. Переделай регистр ей богу ))) не мучай операторов.

(44) да, до окончании запроса, а не транзакции

(45) уже начал, но все рано сабж интересен

(44) Формирование блокировок при выполнении запроса что в упр , что в автомате - одинаковок (если не сказать заранее кодом)

а что кодом можно изменить?

(44) В автоматическом режиме, а не в управляемом. И не обязательно всю таблицу (зависит от sql)

(48) запрос в упр блокировках вообще не должен ничего блокировать, делал на 8.1 тесты, не блокируются

(50) Но автор заявил, что у него управляемый режим, так что это не актуально.

(48) (50) (51) чета нихрена уже не понимаю :)

(49) Конкретно указать зерно блокировки.

(54) я про блокировки, которые накладываются в момент выполнения запроса к таблицам из этого запроса

(55) скока по времени запрос выполняется?

(55) В момент выполнения запроса не накладываются блокировки в управляемом режиме

(51) +

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

(57) а есть этому подтверждения?

Вот цитата из 8.3:

Работа с СУБД. Управляемые блокировки.
Как стало
При работе с Microsoft SQL Server версии 2005 и выше, используется режим управления версиями строк, если конфигурация использует режим управляемых блокировок. Используется уровень изоляции транзакций READ_COMMITED_SNAPSHOT. При чтении данных вне транзакций используется согласованное чтение.    
Результат изменения
К уменьшению блокировок и взаимоблокировок при выполнении запросов, работающих в транзакции;

(57) Накладываются.

(57) а чем чревата разделяемая блокировка в момент выполнения запроса? не даст другим сессия установить разделяемую блокировку на те же данные пока выполняется запрос и возможен облом по таймауту?

(63) Разделяемая дает возможность установить разделяемую и прочитать, но не дает установить исключительную и изменить. Т.е. ее наложение гарантирует неизменность данных внутри транзакции

В общем в упр режиме если ничего не делать то будет:

1. Начало транзакции
2. Выпонление запроса (селект) - установка блокировки
3. Получение результата запроса - блокировка снята
4. Внесение данных в соседнем сеансе
5. Читаем результат селекта - грязное чтение
6. Конец транзакции

Автор, а оно такое надо. Смысл тогда запрос юзать если данные грязные.

(64) Соседний сеан не сможет изменить данные - что в общем нормально.

(65) ну оно как бы по этому измерению другими пользователями точно изменяться не будет

(67) А тут уже как план запроса построится и не факт что не будет избыточности. Поэтому лучше всего подсказывать скулю.

(68) + Причем только на выполнение селекта. А вот в момент чтение результата соседние ползователи могут спокойно колбасить.

(64) тогда вообще не понятно, каким образом это мешает автору

А никто не в курсе как именно происходит блокировка при Селекте в транзакции? Блокируется пока не выполнится весь пакет или блокировка ставится/снимается сразу после выполнения отдельного куска?

(71) Пока весь пакет не выполнится блокировка не снимется

И еще попутно вопрос. ЦУП мне показал следующий блокирующий запрос:
SELECT TOP 20001
*
FROM _InfoRg3840 T1
WHERE T1._RecorderTRef = ? AND T1._RecorderRRef = ?
ORDER BY T1._LineNo

На строках кода:

ОбщийМодуль.ПроведениеСервер.Модуль : 77 : Объект.Движения.Записать();


Что это? откуда эта цифра 20001 ??

(72) тогда можно будет попробовать разбить этот запрос на несколько. Ибо обращение к этому регистру идет далеко не везде.
А откуда инфа, если не секрет?

(73) а скока записей в наборе записей записывается?

И еще из того же ЦУПа.
Блокирующий запрос:
DELETE FROM T1
FROM _InfoRg3840 T1
WHERE T1._RecorderTRef = ? AND T1._RecorderRRef = ?
На тех же строках: ОбщийМодуль.ПроведениеСервер.Модуль : 77 : Объект.Движения.Записать();

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

Я ожидал, что при управляемом режиме они не должны друг другу мешать (потому как наложен фильтр на конкретные РАЗНЫЕ регистраторы)

(76) очень похоже на эскалацию блокировок, запрос твой не при делах похоже

(75) В одном документе чаще всего - одна )
Но куча этих документов может создаваться в транзакции записи другого "вышестоящего" документа.

(78) тогда моя не понимать :(

(77) это значит не хватает памяти серверу?

глянь план выполнения запроса, может у тебя скнирование там

Запрос переделывать буду. Но всё будет комплексно. А пока с этим хочется разобраться

(80) я не уверен, что это имеет место быть, но цифра 20001 подозрительна) память тут не при делах

(83) мне тоже это подозрительно. странно как-то

(83) а не ВЫБРАТЬ ПЕРВЫЕ 20001?

(85) не понял