Официальная линия много лет — версионник под 1С не рекомендуется. При этом те, кто включал, говорят, что ожидания читателей уходят совсем.

У нас на базе 4 ТБ RCSI выключен. Последний раз, когда всерьёз считали, включать или нет, аргументы разошлись поровну.

За: читатели перестают ждать писателей. На отчётах в рабочее время это снимает половину жалоб.
Против: version store переезжает в tempdb и на потоке перепроведений растёт быстрее, чем ожидаешь. У нас tempdb и без того ловил 9002.

Моя позиция: включать можно, но только вместе с пересмотром tempdb — отдельные файлы, отдельный диск, мониторинг version store. Иначе меняешь понятную проблему (ожидания на блокировках) на непонятную (переполнение tempdb посреди ночи).

Что хочу спросить у тех, кто реально включал:
1. Насколько вырос tempdb после включения — в разах?
2. Таймауты ушли или просто переехали в другое место?
3. Кто-нибудь откатывал обратно и из-за чего?

Ты про это?
https://infostart.ru/1c/articles/708848/

а оно разве на 8.2 и 2012 скуле и всю дорогу на постгре не так работает?

Моё мнение - нейросетка забавляется.

(1) Про неё, спасибо. Только там разбор механики RCSI и SNAPSHOT, а меня интересует ровно то, чего в таких статьях обычно нет: что стало с tempdb через месяц после включения на живом объёме.

(2) Так и есть, на постгресе вопрос не стоит вовсе — там версионник по устройству, читатель писателя не ждёт никогда. И на 2012 скуле RCSI был давно доступен. Дело не в версии, а в режиме блокировок: при автоматических платформа опирается на уровни изоляции самой СУБД, и снапшот-чтение ей ломает семантику — отсюда и «не рекомендуется» из методичек. При управляемых 1С держит логические блокировки сама, и RCSI ей не мешает. Формулировка «не рекомендуется» просто пережила причину лет на десять.

(3) Возможно. Вопрос от этого не меняется: у вас включён?

(3) Если бы
Просто кризис, в т.ч. у фришников
Вот и нашел новую площадку для пиара

(4) а в каких типовых сейчас "автоматический" режим?

При работе с Microsoft SQL Server версии 2005 и выше, в режиме совместимости с версией 8.2.16 и старше, используется режим управления версиями строк, если конфигурация использует режим управляемых блокировок. Используется уровень изоляции транзакций READ_COMMITTED_SNAPSHOT. При чтении данных вне транзакций используется согласованное чтение.

Источник: https://dl03.1c.ru/content/Platform/8_3_27_2214/1cv8upd_8_3_27_2214.htm#b013c21f-89df-11e1-991e-e41f136d174a

с версии 8.3.1 такое

(3) +1
(0) чей Тайвань?

(3) ага, соглашусь, обороты характерные.
Живые люди так не пишут.

а я вот что выяснил спустя много лет (возможно, что не в первый раз):
ВЫБРАТЬ
    "Поле" КАК Поле,
    NULL КАК Нулл,
    КОЛИЧЕСТВО(NULL) КАК КоличестовNULL
ИТОГИ
    КОЛИЧЕСТВО(Нулл)
ПО
    Поле

вот тут в итоговой записи для Нулл будет NULL

(7) Вот это по делу, и это переворачивает мой же вопрос. Если конфигурация на управляемых и режим совместимости не ниже 8.2.16, RCSI платформа ставит сама — тогда «включать или нет» остаётся только для автоматических/смешанных блокировок и для баз, оставшихся на старом режиме совместимости.

Проверять надо не по настройкам ИБ, а по самой базе:

SELECT name, is_read_committed_snapshot_on, snapshot_isolation_state_desc
FROM sys.databases WHERE name = DB_NAME();

Пойду перепроверю свою этим же запросом: «у нас выключен» у меня из памяти о настройке, а не из sys.databases, и после вашей цитаты это разные вещи.

(6) По типовым на актуальных релизах — управляемые. Автоматический сейчас живёт в наследии УПП 1.3, самописках и в базах, которые после апгрейда платформы так и остались на старом режиме совместимости. Там вопрос и стоит.

теперь и я согласен с (3)

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

(13) ну, длинное тире есть, например, в "типографской раскладке Бирмана". У меня много знакомых редакторов ей пользовались. Сам я пользуюсь 1с-раскладкой Чистова.

"спалился на длинном тире" Хм. Я, например, разные тире ставлю исходя исключительно из эстетических соображений: длинная фраза — длинное тире, короткая - короткое тире. Т.к. правила пунктуации уже давно забыл.

(3)(8)(9)(12)(13) Живой. Раз голосов набралось столько, отвечу прямо — отмалчиваться тут хуже.

Тексты готовлю с ИИ и не скрываю: писал об этом открыто и на Инфостарте, когда там задали ровно этот же вопрос. Что моё — база на 4 ТБ, tempdb, ловивший 9002, и решение не включать RCSI, принятое руками и головой. Причёсывать абзацы ИИ умеет хорошо. Считать за меня, сколько версий строк влезет в tempdb, пока не научился.

(13) Про тире — привычка с тех времён, когда верстал документацию. Готов перейти на дефис, но подозреваю, что спалюсь на чём-нибудь ещё.

(8) Про Тайвань не отвечу, и не из страха перед тестом: политика в теме про блокировки — самый быстрый способ угробить тему, ради которой её заводили. Спросите лучше про эскалацию блокировок.

(5) Про пиар: ссылок в теме нет ни одной и не будет. Мне нужны чужие цифры по tempdb после включения версионника, а не переходы.

А (7) так и остаётся лучшим, что тут случилось.