SQL Server NOLOCK для запросов, выполняемых для авторизации
Во время входа в наше приложение было выполнено несколько запросов, все вокруг проверки имени входа. Оценивая их, я заметил, что один из запросов выполняется без подсказки NOLOCK.
Кажется, что нет особой опасности грязного чтения, потому что данные вряд ли когда-либо изменятся.
Размышляя об этом из-за попытки типа DOS, предпринятой кем-то, кто снова и снова пытается выполнить неудачный вход в систему, я полагаю, что отсутствие NOLOCK снижает наш порог отказа.
Я полагаю, что это крайне маловероятный результат атаки DOS (я думаю, что веб-сервер пошел бы первым), но добавление NOLOCK должно сделать его от маловероятного до невозможного.
Итак, я чрезмерный или тривиальный?
5 ответов
Наличие NOLOCK или нет - это наименьшее из ваших беспокойств при попытке DoS на вашем сервере.
Я бы не стал потеть.
Если, как вы говорите, данные редко меняются, наличие там NOLOCK, вероятно, не повредит.
Да, вы чрезмерно тривиальны.
Если вы подвержены атакам DOS, NOLOCK при вызове авторизации SQL - это наименьшее из ваших беспокойств. Реализовать некоторое обнаружение DOS, отслеживание ошибок + газ, даже некоторые запланированные паузы, которые не влияют на пользователя, но замедляют атаку...
Вы бы защитили свою таблицу намного лучше, посмотрев на разрешения для нее. Таблица, подобная этой, не должна разрешать прямой доступ, весь доступ должен осуществляться из хранимых процедур и вместо них должны быть установлены разрешения.
Также очень редкий случай, но все же: как раз в тот момент, когда кто-то деактивирует пользователя, чтобы он не мог войти в систему, NOLOCK позволяет им войти. Может ли быть мошенником / хакером / сотрудником, которого необходимо немедленно заблокировать?
Вы должны быть обеспокоены этим конкретным сценарием, чтобы отказаться от преимущества производительности NOLOCK.
NOLOCK может потенциально улучшить вашу производительность, если вы часто вызываете этот запрос, особенно в более широких транзакциях.
Рассмотрите природу грязного чтения - действительно ли временное окно, в котором это может произойти, будет действительно критическим? например, где вы добавляете или удаляете кого-либо из авторизованной роли.
В сценарии добавления грязное чтение потерпит неудачу при этой попытке. (доступ закрыт)
В сценарии удаления грязное чтение будет работать на эту попытку. (доступ разрешен)
Если данные изменяются в результате ручного управления, например, при взаимодействии с человеком - их запас для "задержки" обычно намного выше / неопределяем, чем ваши базы данных!