Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 JOIN и NOLOCK  [new]
Testor1
Member

Откуда:
Сообщений: 679
Всем привет!

Есть запрос с join-ами, связывающие исторические данные и справочники. Выборка селектом делается за период, в который не вносятся изменения. На сколько корректно в этом случае добавлять подсказку WITH(NOLOCK) на все таблицы в данной выборке?
21 май 13, 22:34    [14329731]     Ответить | Цитировать Сообщить модератору
 Re: JOIN и NOLOCK  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37069
Зачем писать nolock, если в таблицы не вносятся изменения?
21 май 13, 22:47    [14329777]     Ответить | Цитировать Сообщить модератору
 Re: JOIN и NOLOCK  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
Гавриленко Сергей Алексеевич
Зачем писать nolock, если в таблицы не вносятся изменения?

минимизировать к-во ресурсов, затрачиваемых на блокировки?
21 май 13, 23:15    [14329850]     Ответить | Цитировать Сообщить модератору
 Re: JOIN и NOLOCK  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37069
locky
Гавриленко Сергей Алексеевич
Зачем писать nolock, если в таблицы не вносятся изменения?

минимизировать к-во ресурсов, затрачиваемых на блокировки?
Я не уверен, что это можно заметить вооруженным или невооруженным взглядом.
21 май 13, 23:20    [14329876]     Ответить | Цитировать Сообщить модератору
 Re: JOIN и NOLOCK  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
Гавриленко Сергей Алексеевич
locky
пропущено...

минимизировать к-во ресурсов, затрачиваемых на блокировки?
Я не уверен, что это можно заметить вооруженным или невооруженным взглядом.


зависит от
если приличных размеров таблицы, то пока там еще блокировки эскалируются до страниц - может быть порядком строчных блокировок, а это, опять таки, затраты памяти и камня....
21 май 13, 23:25    [14329890]     Ответить | Цитировать Сообщить модератору
 Re: JOIN и NOLOCK  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37069
locky
Гавриленко Сергей Алексеевич
пропущено...
Я не уверен, что это можно заметить вооруженным или невооруженным взглядом.


зависит от
если приличных размеров таблицы, то пока там еще блокировки эскалируются до страниц - может быть порядком строчных блокировок, а это, опять таки, затраты памяти и камня....
Если речь идет о read committed, который устанавливается по дефолту, и который имеет смысл сравнивать с uncommitted, то заблокированной будет максимум читаемая запись, или две страницы, или таблица. Т.е. две-три блокировки на объект (еще интент-блокировки всякие). Что копейки, в общем-то.

Сообщение было отредактировано: 21 май 13, 23:30
21 май 13, 23:30    [14329903]     Ответить | Цитировать Сообщить модератору
 Re: JOIN и NOLOCK  [new]
Testor1
Member

Откуда:
Сообщений: 679
Всем привет !

Есть историческая таблица - детализация операций.
В нее вносятся данные за текущий день (постоянно) и обновляются раз в сутки данные за предыдущий день.

Бизнес пользователь периодически просматривает детализацию из исторической таблицы. Для выборки допустимо, чтобы данные были не актуальными. Пользователь может сделать рефреш и увидеть обновленные данные.

Я предположил, что если добавить хинт NOLOCK в выборку, а ROWLOCK в операции INSERT и UPDATE, то тем самым смогу снизить нагрузка на скл сервер и таблицы.

Верно ли мое предположение?
22 май 13, 09:58    [14330838]     Ответить | Цитировать Сообщить модератору
 Re: JOIN и NOLOCK  [new]
Glory
Member

Откуда:
Сообщений: 104760
Testor1
то тем самым смогу снизить нагрузка на скл сервер и таблицы.

Верно ли мое предположение?

Нагрузка не снизится, а вот ожидание блокировок может.

Testor1
а ROWLOCK в операции INSERT и UPDATE

И чего вы ждете от такого хинта ?
22 май 13, 10:06    [14330870]     Ответить | Цитировать Сообщить модератору
 Re: JOIN и NOLOCK  [new]
Testor1
Member

Откуда:
Сообщений: 679
Glory
Testor1
то тем самым смогу снизить нагрузка на скл сервер и таблицы.

Верно ли мое предположение?

Нагрузка не снизится, а вот ожидание блокировок может.

Testor1
а ROWLOCK в операции INSERT и UPDATE

И чего вы ждете от такого хинта ?


Полагал, что уменьшиться ожидание блокировок и как следствие это должно сказать на производительности запросов (детализации и отчетов)
22 май 13, 10:21    [14330968]     Ответить | Цитировать Сообщить модератору
 Re: JOIN и NOLOCK  [new]
Glory
Member

Откуда:
Сообщений: 104760
Testor1
Полагал, что уменьшиться ожидание блокировок и как следствие это должно сказать на производительности запросов (детализации и отчетов)

Т.е. вы проанализировали текущие запросы и пришли к выводу, что все они ожидают снятия блокировок ?
22 май 13, 10:27    [14330994]     Ответить | Цитировать Сообщить модератору
 Re: JOIN и NOLOCK  [new]
Гость333
Member

Откуда:
Сообщений: 3683
locky
блокировки эскалируются до страниц

Блокировки никогда не эскалируются до страниц — либо до уровня таблицы целиком, либо до уровня секции.
http://msdn.microsoft.com/en-us/library/ms184286(v=sql.105).aspx
Lock Escalation (Database Engine)
The Database Engine does not escalate row or key-range locks to page locks, but escalates them directly to table locks. Similarly, page locks are always escalated to table locks. In SQL Server 2008, locking of partitioned tables can escalate to the HoBT level for the associated partition instead of to the table lock.

Страничные блокировки ("полноценные", а не intent) могут накладываться, например, при фуллскане или при сканировании диапазона, когда SQL Server заранее "понимает", что для запроса ему будут нужны все строки из какой-либо страницы. Блокировка при этом сразу будет наложена на страницу, без какой-либо "эскалации".
22 май 13, 10:29    [14331002]     Ответить | Цитировать Сообщить модератору
 Re: JOIN и NOLOCK  [new]
Testor1
Member

Откуда:
Сообщений: 679
Glory
Testor1
Полагал, что уменьшиться ожидание блокировок и как следствие это должно сказать на производительности запросов (детализации и отчетов)

Т.е. вы проанализировали текущие запросы и пришли к выводу, что все они ожидают снятия блокировок ?


Подстраховался на будущее
22 май 13, 10:40    [14331076]     Ответить | Цитировать Сообщить модератору
 Re: JOIN и NOLOCK  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37069
Testor1
а ROWLOCK в операции INSERT и UPDATE, то тем самым смогу снизить нагрузка на скл сервер и таблицы.
При вставке большого количества записей за один раз сервер предпочитает либо PAG-лок, либо TAB-лок. Последнее можно запретить на уровне индекса. А вот менять PAG-локи на ROW-локи я бы не советовал без веских причин -- как раз нагрузку-то вы этим и увеличите.
22 май 13, 10:46    [14331128]     Ответить | Цитировать Сообщить модератору
 Re: JOIN и NOLOCK  [new]
Glory
Member

Откуда:
Сообщений: 104760
Testor1
Подстраховался на будущее

Круто. Купите еще дисков, памяти и процессоров побольше.
22 май 13, 10:47    [14331133]     Ответить | Цитировать Сообщить модератору
 Re: JOIN и NOLOCK  [new]
Testor1
Member

Откуда:
Сообщений: 679
Гавриленко Сергей Алексеевич
Testor1
а ROWLOCK в операции INSERT и UPDATE, то тем самым смогу снизить нагрузка на скл сервер и таблицы.
При вставке большого количества записей за один раз сервер предпочитает либо PAG-лок, либо TAB-лок. Последнее можно запретить на уровне индекса. А вот менять PAG-локи на ROW-локи я бы не советовал без веских причин -- как раз нагрузку-то вы этим и увеличите.


То есть думаете вообще стоит отказаться от подсказок при вставке и удалении ? Оставить по дефолту?

В каких процессах нужны такого рода подсказки ?
22 май 13, 11:21    [14331360]     Ответить | Цитировать Сообщить модератору
 Re: JOIN и NOLOCK  [new]
Testor1
Member

Откуда:
Сообщений: 679
Glory
Testor1
Подстраховался на будущее

Круто. Купите еще дисков, памяти и процессоров побольше.


Я экономный и ставлю решение на интеловые сервера с малыми требованиями. Аналогичные решения запускают на сан серверах.
Учусь и пытаюсь там где возможно провести оптимизацию. Проще иногда изначально заложить оптимизацию там где это нужно, нежели потом искать решение.
22 май 13, 11:24    [14331378]     Ответить | Цитировать Сообщить модератору
 Re: JOIN и NOLOCK  [new]
Glory
Member

Откуда:
Сообщений: 104760
Testor1
Учусь и пытаюсь там где возможно провести оптимизацию.

Оптимизацию начинают с поиска узких мест.

Testor1
Проще иногда изначально заложить оптимизацию там где это нужно, нежели потом искать решение.

Вы грязные чтения называете "изначально заложить оптимизацию" ?
Надо такой код писать изначально, который делает нужное количество блокировок на минимальное время.
А не тот, который ждет "костыль" в виде разрешения грязных чтений
22 май 13, 11:32    [14331436]     Ответить | Цитировать Сообщить модератору
 Re: JOIN и NOLOCK  [new]
Testor1
Member

Откуда:
Сообщений: 679
Glory
А не тот, который ждет "костыль" в виде разрешения грязных чтений


Какая может быть проблема в процедуре на просмотр детализации? Аргументы и без эмоций.
22 май 13, 11:43    [14331543]     Ответить | Цитировать Сообщить модератору
 Re: JOIN и NOLOCK  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
Теоретические основы конкурентного доступа к данным
22 май 13, 11:48    [14331587]     Ответить | Цитировать Сообщить модератору
 Re: JOIN и NOLOCK  [new]
Glory
Member

Откуда:
Сообщений: 104760
Testor1
Какая может быть проблема в процедуре на просмотр детализации?

О возможности использования грязных данных принимает бизнесс, а не разработчик или оптимизатор.
Потому что ни второй ни третий эти данные не будут использовать.
22 май 13, 11:50    [14331611]     Ответить | Цитировать Сообщить модератору
 Re: JOIN и NOLOCK  [new]
Testor1
Member

Откуда:
Сообщений: 679
Maxx
Теоретические основы конкурентного доступа к данным


В тему. Буду читать
22 май 13, 13:26    [14332498]     Ответить | Цитировать Сообщить модератору
 Re: JOIN и NOLOCK  [new]
Testor1
Member

Откуда:
Сообщений: 679
Glory
Testor1
Какая может быть проблема в процедуре на просмотр детализации?

О возможности использования грязных данных принимает бизнесс, а не разработчик или оптимизатор.
Потому что ни второй ни третий эти данные не будут использовать.


Бизнес не знает что такое грязные и чистые данные. Ему все равно, главное чтобы был правильный результат. Так что все делается по старинке, то есть в большинстве случаев по дефолту.
22 май 13, 13:28    [14332518]     Ответить | Цитировать Сообщить модератору
 Re: JOIN и NOLOCK  [new]
Glory
Member

Откуда:
Сообщений: 104760
Testor1
Ему все равно, главное чтобы был правильный результат

Вот именно. А вы ему - результат такой, потому что мы подстраховались/оптимизировали заранее.
Как можно оптимизировать неизвестно что ?
22 май 13, 13:30    [14332557]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить