Некоторые способы обходных путей и решений блокировочников по предложенной проблеме. Рассматривается Sybase ASA, который так же является блокировочником, как и MSSQL и во многом схож с ним:
1. есть возможность выставить низкую приоритетность для сессии
2. есть возможность выставления для сессии у оптимизатора запросов режима работы (OLTP или OLAP)
3. оптимизированны сами блокировки, т.е.:
- Для программиста все блокировки в ASA представлены как ROW-LEVEL LOCK (позаписные).
- Для вставок новых записей существуют Insert блокировки, не мешающие чтению существующих записей.
- Для удаленных записей существует опция управления их видимостью (ждать подтверждения их удаления или же при чтении считать, что они удалены и не учитывать их).
- Существует опция управления поведением сессий на блокировки (ждать снятия блокировки или выйти по ошибке из за блокированных записей).
- При чтении записей из таблицы блокируется только текущая на момент чтения запись. После того, как она прочитана, блокировка с нее снимается (для режимов изоляции READ UNCOMMITED / READ COMMITED).
- Есть оператор блокировки всей таблицы (LOCK TABLE), позволяющий на время работы транзакции наложить Table Lock.
- Использование индексов при чтении снижает кол-во блокировок, если изменяемые записи не затрагивают поля в индексе, т.е. не блокируют индекс.
- Существует куча опций управления оптимистичностью блокировок, управления проверками CONSTRAINTS (во время проведения операции или отложенные до COMMIT) и т.д.
4. отработан сам механизм проверок и блокировок: блокировка записей осуществляется параллейно с проверками и BEFORE триггерами, что гарантирует в случае обнаружения невозможности проведения изменения немедленное снятие блокировок и откат транзакции, без необходимости блокирования всего массива изменяемых записей.

К вышесказанному могу сказать, что особых проблем блокировки в ASA не создают, достаточно просто думать головой, выбирать правильный уровень изоляции в зависимости от поставленной задачи, пользоваться временными таблицами, которые никого не блокируют, существуют только внутри сессии (и кстати могут быть как NOT TRANSACTIONAL, что неплохо сказывается на скорости их работы), ну и естественно не держать COMMIT по сто лет. Ну а в отстальном я на 100% согласен с Glory - все решается учетом архитектуры сервера, правильной проектировкой БД и граммотным составлением запросов и тут уже без разницы, что используется - блокировочник или версионник. Имея немного фантазии и не зная основ работы можно тормознуть любой из них, лишь бы желание было :)