Добрый день!
Подскажите, как идет работа с Регистром расчета в режиме совместимости с 8.2.

Дано: база клиент- серверная, Управляемые блокировки
      СУБД: SQL,
      8.3 в режиме совместимости с 8.2

Проводятся 2 независимых по данным документа в одном периоде. Чтения данных нет. Только запись.
Возникает блокировка СУБД по тайм- ауту.
В чем причина и как ее устранить?
p.s. в режиме совместимости 8.3 проблемы нет. Но нужно понять проблему 8.2 и найти решение именно с режимом совместимости с 8.2
Help please!

https://tavalik.ru/ishhem-blokirovki/

(0) поставьте PostgreSQL, там такой проблемы не должно быть. В MSSQL вся таблица блокируется по всем организациям, хоть и указаны блокируемые данные. Тестировал давно для ЗУП, в итоге из MSSQL сделали версионник http://catalog.mista.ru/1c/articles/91879/

(2) да и при перезагрузке службы сервера 1С надо переключать повторно

(2) Смелое утверждение, с чего бы это MSSQL сервер блокировал всю таблицу, если этого не указали явно кривые ручки разработчика

(4) поставьте ЗУП 2.5 в режиме совместимости 8.2, нажмите рассчитать по организации 1, поставьте точку останова, потом нажмите рассчитать для организации 2.
Потом выставьте 8.3, либо ЗУП 3.1 и убедитесь лично.

(4) Вы немного не в теме. (2) не совсем прав, но сказал путь подсказал правильный

(0) http://catalog.mista.ru/1c/articles/629017/
Тут тоже есть абзац на эту тему, искать по "Ошибка платформы – скан индекса регистра расчета".

(6) На сколько я понял это проблема не MSSQL, а 1с платформы или я не прав?

(2) - самое интересное, но на PostgreSQL та же проблема
(7) - и как это обходить? попробовала для таблицы записей регистра в менеджмент студио (в целях эксперимента) удалить все индексы и создать свой кластерный по полям период, регистратор, запись (аналогично существующему). Попробовала создать кластреный индекс по полям период, регистратор, запись, организация, сотрудник.
Но в структуре метаданных отображаются прежние изначальные индексы... Я новичок в этом деле- почему новые индексы не применились?

(9) "в структуре метаданных отображаются прежние изначальные индексы"
Это в какой? В 1с? А добавляла в SQL?
"Я новичок в этом деле" - поэтому оставь это дело (свои индексы добавлять) 1с:экспертам

(9) - добавляла в таблице SQL
структуру хранения метаданных смотрю из 1С- она разве не должна отображать актуальные изменения в индексах?

кроме как абзаца из статьи http://catalog.mista.ru/1c/articles/629017/, никакой информации об особенностях работы с таблицам регистров расчета нигде информацию не нашла

(9) каково ваше решение? как 1с:эксперта :)

(12) "в режиме совместимости 8.3 проблемы нет"
Всё уже украдено до нас.

(11) Нет. У 1с своя система индексов. Которую 1c проецирует в скуль. Но не наоборот.

(9) Индексы лучше смотреть в Management Studio. В базе sql - Tables - [Выбранная таблица] - Indexes.

(13) хотелось бы побороть это в режиме совместимости с 8.2

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

Поэтому (9) пошла в Management Studio. В базе sql - Tables - [Выбранная таблица] - Indexes.
Удалила существующие там "не кластерные" индексы и создала аналогичные, но кластерные.

в Management Studio все применилось.. вроде как.
А если смотреть на структуру индексов из 1С- все индексы остались прежними. Что я не доделала?

(16) Что вы имеете в виду под "на структуру индексов из 1С" ? Скиньте скрин. И, я бы начал с перевода базы на RСSI, а не индексов.

(16) "Что я не доделала"
Недочитала (14)

(14) У 1с своя система индексов. Которую 1c проецирует в скуль. Но можно и средствами Management Studio добавить свои индексы. Хотя бы на определенное время.
Вопрос только в том- почему это, как бы, не сработало

(17) RСSI - решит проблему на чтение, а у меня- запись

Имя таблицы: РегистрРасчета.Основной
Имя таблицы SQL: _CRg1807
Индексы: _CRg1807_ByPRecorder_TRN
Поле индекса: _Period, _RecorderRRef, _LineNo

То есть, "родной" индекс по периоду, ссылке на документ, записи. Должна работать параллельная запись.

Удалила "родной" индекс, сделала в Management Studio свой Кластерный, аналогичный этому. Проблема не ушла, в 1С отображается прежний индекс.
Добавила в свой кластерный индекс поля "_Fld1808RRef" (Организация) и "_Fld1809" (Сотрудник). в 1С отображается, по-прежнему, "родной" индекс, которого в Management Studio уже нет.

(9) (16) (21) а с чего вы взяли что новые индексы должны быть видны из 1С ?
1С об них ничего не знает вроде как ... там информация берётся из записанных структур таблицы Config на скуле.
Вопрос: так вы в итоге попробовали RCSI ? потому как в 8.3 без режима совместимости как раз он и используется, а в 8.2 его как опции не было.

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

(23) = с управляемыми блокировками

у меня не на блокировках 1С таймаут, а на блокировке СУБД

у меня ничего не читается
RCSI работает, когда идет чтение. Запросом, например...
А мне ничего читать не нужно. Нет блокировки на чтении.
Возникает блокировка СУБД в момент записи движений в регистр

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

есть блокировки 1С и есть блокировки СУБД
у меня- блокировка СУБД
как работает SQL с таблицей регистра расчетов в режиме совместимости 8.2?
неужели нет решения, кроме как отказ от совместимости с 8.2?

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

(21) Галочки "Индексировать" в 1С - берутся из самой конфигурации, это то, к чему в итоге "стремится" конфигурация. Если проблема та же и вы ее четко фиксируете, надо как то дальше смотреть. К примеру, посмотреть какие индексы создаются платформой при повышении режима совместимости до 8.3, может там состав полей отличается.

В статье же ясно написано...
"Еще одна проблема регистра расчета проявляется при чтении и заключается в том, что платформенный запрос, который читает данные из регистра расчета, тоже сканирует индекс. Но здесь уже помогает именно включение либо Read Committed Snapshot, либо, если у вас 8.3, вы можете убрать режим совместимости с 8.2, тогда этой проблемы у вас уже не будет."

Но мы же жители крайнего Севера, мы не читатели...

(30) При режиме совместимости с 8.2 в структуре метаданных 1С присутствует Основная таблица регистра расчетов "РегистрРасчета.Основной" и таблица "ПериодыДействия" "РегистрРасчета.Основной.ФактическийПериодДействия". В режиме 8.3 - остается только Основная таблица регистра расчетов "РегистрРасчета.Основной".
Если смотреть структуру индексов в Management Studio, то она одинакова- и в режиме совместимости 8.2 и в режиме совместимости 8.3.
Если в 1С дополнительно проиндексировать поля Организация и Сотрудник- ошибка блокировки в режиме совместимости 8.2 не уходит. Пробовала.

(16) >Удалила существующие там "не кластерные" индексы и создала аналогичные, но кластерные

Не лги! Больше одного кластерного индекса для таблице быть не может по определению! Кластерный индекс это симбиоз индекса с таблицей

Что там в технологическом журнале? По какому диапазону блокируется у СУБД?

Перейти на постгри или хотя-бы врубить у сиквела RCSI уже предлагали?

(33) имела в виду- для двух таблиц [dbo].[_CRg1807] и [dbo].[_CRgActP1811]

(34) на постгри то же самое
RCSI - спасительно только при блокировке при чтении

(36) проверяла?

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

(38) - параметр "изоляция моментальных снимков read comment включена" = "True"

(0) Все нормально там с блокировками.
Вы во всех объектах, участвующих при проведении документа, выставили "Управляемая блокировка"?

...Если вы выставили на самой конфигурации "Управляемые блокировки", то это только для новых документов работает... :)

В общем нам тут не видно, как вы тама настроили конфигурацию...

(40) для конфы установлен режим блокировок "Управляемый"
во всех объектах, участвующих при проведении документа, выставлена "Управляемая блокировка"

p.s. если для всей конфы установлена Управляемая блокировка, то она для все объектов управляемая
совмещать можно только при режиме для конфы "Автоматический и управляемый"

(39)
SELECT name, snapshot_isolation_state, snapshot_isolation_state_desc, is_read_committed_snapshot_on FROM sys.databases
и snapshot_isolation_state и is_read_committed_snapshot_on у вас 1?

(33)Яростно ++++++++
ТС реально не понимает тему.

(0) Читаем до умопомрачения например https://open-budget.ru/public/629017/
После этого (наверное это будет ждля вас оптимально, если не умеете парсить логи ТЖ) ставите ЦУП. Смотрите анализ запросов и анализ ожидания на блокировках.

Даже интересно.
Автор, если у тебя sql и безгемморойный доступ в enterprise
Напиши на [email protected]

в регистре расчета на одной из таблиц нет кластерного индекса.
лет 5 назад такой вопрос решал

хотя конечно одного индекса недостаточно

Еще раз проверила:
При режиме совместимости с 8.2 в структуре метаданных 1С присутствует Основная таблица регистра расчетов "РегистрРасчета.Основной" и таблица "ПериодыДействия" "РегистрРасчета.Основной.ФактическийПериодДействия".
В режиме 8.3 - остается только Основная таблица регистра расчетов "РегистрРасчета.Основной".
Если смотреть структуру индексов в Management Studio, то она одинакова- и в режиме совместимости 8.2 и в режиме совместимости 8.3.
И в 8.2 и в 8.3 уже присутствует кластерный индекс (поля ссылка, номер записи)
При реструктуризации после изменения режима совместимости- вносятся изменения в таблицу Плана видов расчета. Но не пойму, как это может влиять..
Проблема с таблицей "ФактическийПериодДействия"? но там есть регистратор в индексе... Не должно быть проблемы

(45) Кстати, а сейчас косяк косяк в платформе, что у оборотного РН у виртуальной таблицы обороты нет обычного индекса по первому измерению...
(44) Если поможешь ТС, то расскажи плиз. Мое предположение, что блокировка скорее всего на побочном РС типа "ПериодическиеНачисления" или каких-то РН.
(47) Почему вы решили, что проблема именно с регистром расчета???

(48) Индекс у виртуальной таблицы? О_о

похоже, в 8.2 накладывается блокировка на Вид расчета..

exec sp_executesql N'INSERT INTO #tt10 WITH(TABLOCK) (_CalcKindRRef) SELECT DISTINCT
T1._CalcKindRRef
FROM dbo._CRg1807 T1
WHERE T1._RecorderRRef = P1',N'P1 varbinary(16)',0x83B9001C428537A411E5AAFA3D70B658

и потом
exec sp_executesql N'INSERT INTO #tt12 WITH(TABLOCK) (_RecorderRRef, _LineNo, _CalcKindRRef, _ActionPeriod, _Period, _APDateFrom, _APDateTill, _Storno, _Fld1808RRef, _Fld1809) SELECT DISTINCT
T10._RecorderRRef,
T10._LineNo,
T10._CalcKindRRef,
T10._ActionPeriod,
T10._Period,
T10._APDateFrom,
T10._APDateTill,
T10._Storno,
T10._Fld1808RRef,
T10._Fld1809
FROM dbo._CRg1807 T9
INNER JOIN dbo._CRg1807 T10
ON T10._Fld1808RRef = T9._Fld1808RRef AND T10._Fld1809 = T9._Fld1809 AND T10._ActionPeriod = T9._ActionPeriod AND NOT ((T10._RecorderRRef = T9._RecorderRRef AND T10._LineNo = T9._LineNo))
LEFT OUTER JOIN #tt11 T11 WITH(NOLOCK)
ON T11._IDRRef = T9._CalcKindRRef AND T11._LINKEDRRef = T10._CalcKindRRef
WHERE T9._RecorderRRef = P1 AND T10._Active = 0x01 AND ((T9._RecorderRRef = T10._RecorderRRef AND T9._LineNo = T10._LineNo) OR T9._CalcKindRRef = T10._CalcKindRRef OR T11._IDRRef IS NOT NULL)',N'P1 varbinary(16)',0x83B9001C428537A411E5AAFA3D70B658

с ожиданием почти 20 секунд

_CalcKindRRef - это вид расчета

(49) херь я сморозил... имел ввиду таблицу итогов.

(47) То есть в 8.3 избавились от вспомогательных физических таблиц и теперь все "на лету" считают? Интересно...

(50) Давайте для начала вы дмвшкой sys.dm_tran_locks посмотрите...
Вот например пример ее использования http://catalog.mista.ru/1c/articles/707333/

(48) всегда так было, исправят