Я про
Snapshot isolation also means that SQL Server will use row versioning on the primary node. You may not be able to use optimistic isolation levels programmatically when they are not enabled; nevertheless, SQL Server will use row versioning internally. The databases on the primary and secondary nodes are the same, and it is impossible to use row versioning only on the secondary nodes.

Нет, это на мой взгляд ошибка с его стороны.

Нет там версионности, базы не одинаковы и всё что он говорит - чушь

мне очень жаль, что я привел его статью в качестве примера

а все нашел это в apress.com  
Я просто не понял вначале откуда этот абзац

В итого:
Включение RCSI  на primary  бессмысленно, так как на secondary RCSI  используется и без этой настройки.
Убрать блокировки схемы с secondary , когда пользователи читают - мы не можем, только если не будем использовать snapshot db  например.
Вы со мной согласны коллега?

Sir yes sir!

Благодарю вас за продуктивную дискуссию.

в такой вежливый, что прям выматериться от радости хочется

да не вопрос, я тоже по матери умею :)

отличие сопромата от мата. Знают единицы, говорят, что знают многие. Маёвская шутка.

У Короткевича кстати тоже именно SNAPSHOT написано

As you will remember from Chapter 6, this behavior will introduce additional tempdb
load to support the version store. It may also increase index fragmentation due to the
14-byte pointers appended to the data rows during data modifications. However, it also
leads to another phenomenon. Long-running SNAPSHOT transactions on secondary nodes
may defer ghost and version-store cleanup on the primary node. SQL Server cannot
remove deleted rows and reuse the space, because of the possibility that a SNAPSHOT
transaction on the secondary node will need to access the old versions of the rows.

Ну и пример в книге конечно есть

Можно напрямую у Дмитрия спросить

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

На секондари начинаем транзакцию(а потом просто select * from t1), потом на Праймари delete drom T2 и он физически долго не может удалить эти строки потому что он думает, что это может понадобится в долгой транзакции которая началась раньше на секондари, вроде как в RCSI согласованность нужна на момент каждого стейтмента, а не на начало транзакции и тогда он смело может удалить эти записи. Вроде как логично, если что поправьте.

Всё верно на мой взгляд. Немного иначе я бы мотивировал неудаление данных. там работает механизм синхронизации "low water mark for ghosts". Т.е. праймари не работает в принципе в снэпшотной изоляции, а просто притормаживает удаление. но суть неизменна от этого

Да он их просто помечает

Как сделать bulk update на чистом sql? Обновить несколько записей за 1 запрос