Собственно интересует сабж - опыт использования.
Плюсы вообщем-то понятны, не блокирующее чтение со всеми вытекающими.
Понятно что в результате таких действий читаются грязные данные
и можно пролететь в случае каких-то важных изменений в момент чтения данных.
Я выполняю запросы (чтение и запись) из 1С к внешней базе MS SQL через ADO.
Во внешнем источнике перегружены сильно две основные таблицы (такая структура бд - изменить нельзя),
в них ведется постоянная запись и чтение (в том числе и из 1С) из-за чего периодически
возникают блокировки (блокировки каждый день 1 раз как минимум)
Решили все выборки переделать с nolock (в запросах из 1С и во внешней базе).
Собственно вопрос: не выльется это в какую-то проблему с еще большими тормозами, есть тут подводные камни?

(0) а разве не очевидно? будешь получать не закоммиченные записи в 1С.

(0) первым делом попробовать навести красоту в индексах во внешней базе. там все красиво?

>Во внешнем источнике перегружены сильно две основные таблицы (такая структура бд - изменить нельзя),
в них ведется постоянная запись и чтение (в том числе и из 1С) из-за чего периодически

точить некогда, пилить надо

(1) Это пока не пугает. Почти все, что я получаю - я же и пишу, в пределах одного сеанса. Но каждый сеанс пишет свои данные (грубо говоря каждый работает со своим документом)

(2) Ну если верить DBA базы - то да.

(3) Над БД MS SQL существует своя логика (клиент), который имеет определенные ограничения и требования к структуре БД.

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

(7) Однозначный ответ даст анализ планов выполнения типичных запросов

(7) нет здесь однозначного ответа. кто знает чего там у вас понаделано. лучше сначала посмотреть насколько эффективно используются индексы, нет ли избыточных индексов. провести ревизию запросов. поискать тормозные места и попробовать оптимизировать.

может быть как то можно разнести время работы программ с таблицей. что бы не пересекались.

(0) Можно вместо ожидания получить:
"Could not continue scan with NOLOCK due to data movement"
Если при чтении сервер наступит на записи которые прямо сейчас модифицируются

(7) Про тормоза не понятно, на первый взгляд выглядит как полный бред.

(10) работаю над этим, но это немного разгрузит базу со стороны 1С только.
(11) Это хуже. Я думал при использовании nolock по боку, что там и куда пишется...

(12)такое сообщение можно получить, при поврежденных данных - лечится DBCC CHECKDB. Либо если скуль старый, это сообщение было признано ошибко и был выпущен фикс еше на 2000-м скуле.

Тормоза при отсутствии NOLOCK это объективная реальность.

Можно внешнюю базу перевести в режим RCSI и тогда не нужно будет никаких NOLOCK и тормозов не будет.

(13) RCSI - не подходит, при этом режиме будет каша в базе.
NOLOCK позволяет более тонкий подход (т.е. только там где надо)
Интереснее еще в этом плане выглядит режим версионности, но боюсь наши сервера тупо по ресурсам не потянут :)

(14) "при этом режиме будет каша в базе" - а почему?

(15) Не везде нужен NOLOCK по умолчанию. Гарантированные данные тоже востребованы.

(16) а что у вас там за блокировки такие? вообще блокировки это нормальное явление. и возникают они гораздо чаще чем один раз в день ))