Частично в продолжение этого топика:
v8: Почему в 1С 8 в варианте SQL возможно грязное чтение?

Воспользовался вот "этим":
ALTER DATABASE база
SET ALLOW_SNAPSHOT_ISOLATION ON

ALTER DATABASE база
SET READ_COMMITTED_SNAPSHOT ON

Типовой ф-л на БУ базе у меня спокойно работает с 5-ю пользователями, тогда как в off - более 90% в dead lock ах.

Причем, платформа 8.2.16.362 и автоматический режим блокировок.

Какие подводные камни кроме нарушения лиц. соглаш. и возможного слёта после обновления? Правда, не совсем также понятно, ну и слетело в off после обновления, снова поставим в onn.

(0) Какие подводные камни кроме нарушения лиц. соглаш. и возможного слёта после обновления?

Никаких. И слетать по-идее не должно вообще.

>>автоматический режим блокировок
совсем сдурел?

Да и нарушения лицензинного соглашения нет.

(2) Типовая конфа

Режим версионирования ТОЛЬКО с управляемыми блокировками

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

(5) Задолбали косорылыми переводами.

(6) Еще один знаток.

(5) (6) Режим БД не зависит от режима работы приложения в ДАННОМ случае.

(9)да!
(2 и 5) И ребята я же Вам практику пишу - как есть.

у меня рабочая УПП. сейчас под 20 гб, в РАУЗе пашет, флага в УУ отражать не используем, т.е. избавились от части ненужных даже регистров.

Сейчас ты просто отключил блокировки и ничего не включил в замен

(7) какое слово ты не понял?

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

(12) в конце месяца - восстановил все требуемые последовательности, провел расчет с/с и закрыл период.

(14) ты знаешь для чего нужны блокировки???

(15)если период для всех закрыт, кроме 1-го человека, то не вижу никаких против.

(16) Просвети нас, а то мы не знаем.

(16) я понимаю, что ты бъёшься за целостность данных, но тогда поясни, где ты видишь "прорехи" в этом вопросе у версионности и в частности в моем случае?

(15)а если остаток или резерв в минус уйдут?

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

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

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

сейчас, мне sql админ привел пример: создал в sql таблицу и продемонстрировал запись в неё двумя разными способами - "версионный" и "блокировочник", естественно при работе 2-х пользователей. Результат был очевиден блокировочник отработал верно, тогда как версионник показал некорректные данные.

(23) >одновременное по своим организациям и читали и записывали

А если будут одновременно читать и записывать по 1 организации, то, я так понимаю, включение версионности вообще ничего не даст?

На что я ответил:
у тебя в твоей демонстрации были две одинаковые таблицы с одинаковыми измерениями - вот ты и получил такой результат, что в твоем случае так и должно быть. 1С таблицы устроены по другому. В частности для БУ базы у нас есть обязательное для всех измерение - Организация. В этом случае, таблица остатков будет полностью заблокирована, например, транзакцией организации1. Но, отбор из таблицы остатков по последней версии в любом случае будет сделан по нужной нам организации, тем самым мы верно прочитаем данные.
Коллеги, верно ли я мыслю?
(25) согласен, будет немного "грязным" чтение по данной организации.

(25) Версионность как раз дает читать не блокируя данные для записи. Так как можно прочитать создается срез БД на начало читающей транзакции. Она именно для того, что бы не было конфликта между чтением и записью. Хотя там есть

27 + http://msdn.microsoft.com/ru-ru/library/tcbchxcb(v=vs.110).aspx

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

Просто в (0) сценарий не типичный, когда сидят 5 бухов и тупо каждый по своей организации проводит доки.

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

Обычно всё же толпа народу одновременно работает с 1-2 организациями.

(29) Используй SERIALIZABLE, которая кстати действует в автоматических блокировках.
Если ты читаешь с последующей записью.

Версионники нужны для того, чтобы читающие транзакции с изоляцией READ_COMMITTED_SNAPSHOT не конфликтовали с SERIALIZABLE