Доброго времени суток!
А можно ли изменить параметры другой сессии?
Т.е. например сделать SET TRANSACTION ISOLATION LEVEL ... в контексте другой сессии?

так понятно, что неправильно. Но вот есть закрытый клиент в нем только просмотровые функции, запросы зашиты. Работает он по идее через одну сессию, которую получает при логине, по умолчанию там рид коммитед. Кто то выберет диапазон дат с 2001 и начало хвоста блокировок. Клиент изменить нельза, как то существенно архитектуру тоже. Я нашел процедуру, которая в контексте данной сессии делает некие настройки при запуске клинта (лог на вход и т.д.) и попытался туда поместить set isolation transaction level но не смотря на то, что мой "set isolation transaction level" судя по трассе последний, выборка все расно показывает, что у сессии isolation_transaction_level=2.

Параметризованный запрос.

Как пример. Запрос с параметрами @begin_date и @end_date понятное дело таблица документов + связка с другими объектами хорошо если без ouer apply. В данном случае устроило бы и чтение незакоммиченных данных, но поскольку нет - на какойто из объектов наложена блокировка и ждем.

В виде разрастания темпдиби и возможности нарушения целостности? И я так понимаю после активации snapshot isolation по дефолту будет не read comitted а snapshot isolation?

Не совсем верно сформулировал. Первое на что наткнулся гугля возможные проблемы при включении RCSI - пример триггера на инсерт, который вставляет в дерево дочернюю запись с проверкой на существование родителя и эксепшеном при отсутствии. Там было показано, что при удалении этого самого родителя в другой сессии, до коммита транзакции другие сессии вполне могут вставлять дочерние. Я так понимаю возможно это только при отсутствии других способов обеспечения целостности.....