Хинт (nolock) и ошибка 601

ВладимирМ

MS SQL 2000. Сервер Win2003. Oколо 120...150 одновременно работающих пользователей. Таблицы по несколько миллионов записей.Мне требуется сформировать ряд статистических отчетов за месяц. Чтобы ускорить формирование отчетов я использую в запросах хинт (nolock), поскольку актуальность данных не столь важна.Проблема в том, что при использовании этого хинта есть вероятность получить ошибку 601 (правда небольшая, поскольку удаление - это достаточно редкая операция).Есть ли возможность обойти эту ошибку при использовании хинта (nolock)? Насколько вообще использование хинта (nolock) ускоряет получение выборки?
8 ответов

ВладимирМ

Есть один оч интересный способ - отчеты строить с NOLOCK , но за "закрытые" периоды. При этом в триггерах (лучше INSTEAD!) не девать модифицировать эти самые закрытые периоды. Тогда сиквел не будет париться установкой блокировок, что не то, чтобы будет быстрее, но будет легче для сервера. В итоге, под нагрузкой, естественно, быстрее.


ВладимирМ

Программа написана под "толстого" клиента (AXAPTA 2.5, если кто в курсе). Вмешательство в логику приложения и структуру базы данных не приветствуется. Все явные транзакции устанавливаются с клиента. Триггеров на сервере вообще нет.


ВладимирМ

Может лучше для отчетов использовать OLAP ?- от самого примитивного т.е. каких-то иаблиц с итоговыми суммами, которые обновляются скажем раз в сутки- до действительных OLAP серверов ?


ВладимирМ

Насчет OLAP я не уверен. Просто всерьез не разбирался с этой технологией. Поставлю в планы на будущее :)А по собственно (nolock) есть какие-нибудь мысли?


ВладимирМ

This error aborts the query. Either resubmit the query or remove the NOLOCK locking hint.
Поэтому наверно только так:
WHILE ...
BEGIN
 ...
 <запрос с NOLOCK>
 ...
 IF @@ERROR = <b>601</b> CONTINUE
 ...
 <запрос с NOLOCK>
 ...
 IF @@ERROR = <b>601</b> CONTINUE
 ...
END
Ну или убрать-таки NOLOCK :)


ВладимирМ

Просто всерьез не разбирался с этой технологиейНу так самы примитивный OLAP - это сформировать тут же свои промежуточные таблицы с какими-то итогами в разрезе там периодов, клиентов и тд. И апдейтить их по расписанию.А по собственно (nolock) есть какие-нибудь мысли?Думаю, что Раз (1) прав. Ошибка ведь есть последствие использования хинта. Поэтому проще ее перехватить и поступить в соответствии с желаемой логикой - перезапустить так перезапустить, прервать так прервать


ВладимирМ

Понятно. Т.е. лучше Nolock вообще не использовать. Ладно, пусть будет чуть помедленнее.PS: В принципе уже есть копия рабочей базы (копируется каждый день). Так что можно делать запросы в ней. Но там Nolock вообще не имеет смысла, поскольку обычно эта копия не модифицируется. Создана специально для отчетов.


ВладимирМ

...уже есть копия рабочей базы (копируется каждый день). Так что можно делать запросы в ней. Но там Nolock вообще не имеет смысла, поскольку обычно эта копия не модифицируется. Создана специально для отчетов.
Она у Вас в режиме ReadOnly ? Если нет, то Nolock все-таки имеет смыслставить, сервер ведь не знает, что она только для чтения, если ему нерастолковать, посему будет ставить блокировки, а оно Вам надо ?