Можно ли отклонить чрезмерно большие запросы к определенным представлениям?

Я работаю с MS-SQL Server, и у нас есть несколько представлений, которые потенциально могут возвращать огромные объемы обработанных данных, достаточных для того, чтобы наши серверы использовали 100% ресурсов в течение 30 минут подряд с помощью одного запроса (при безответственном запросе) .

Не существует абсолютно никакого бизнес-кейса, в котором такие огромные объемы данных должны были бы быть возвращены из этих представлений, поэтому мы хотели бы заблокировать их, чтобы гарантировать, что никто не сможет DoS-атаки на наши SQL-серверы (преднамеренно или иным образом), просто запрашивая эти конкретные данные. представления без правильных предложений where и т. д.

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

Или мы можем настроить сервер так, чтобы он отклонял заданные планы выполнения на основе предполагаемого времени выполнения и т. д.?


sql sql-server tsql denial-of-service
person Giffyguy    schedule 14.06.2015    source источник
comment
Пишут ли конечные пользователи специальные SQL-запросы? Или вы беспокоитесь о разработчиках, которые пишут плохой код?   -  person James L.    schedule 14.06.2015
comment
@Джеймс Л. Последний. :) Глючный код, в частности.   -  person Giffyguy    schedule 14.06.2015
comment
Похоже, вам следует сосредоточиться на своих процессах контроля качества, чтобы гарантировать, что плохой код не повлияет на вашу базу данных, вместо того, чтобы пытаться создать анализатор предварительного запроса для блокировки запросов, которые могут быть законными, но могут иметь более длительное расчетное время выполнения, потому что статистика устаревшие (например). Проблема не ограничивается запросом представлений, разработчики могут написать плохой запрос к таблицам, которые также плохо работают, или, что еще хуже, к декартову произведению. Кажется, вы решаете не ту проблему. Лучшее место для обнаружения плохого кода и проблем с производительностью — цикл разработки/контроля качества.   -  person James L.    schedule 14.06.2015
comment
Стоит ли менять рассматриваемое представление на функцию?   -  person uh_big_mike_boi    schedule 14.06.2015
comment
@Джеймс Л. Конечно, это тоже в работе, но, к сожалению, нам нужно убедить многих людей на разных уровнях власти улучшить процессы контроля качества для своих команд, а этого просто не произойдет в ближайшее время. Мы хотели бы изучить возможность защиты баз данных непосредственно в промежуточный период в качестве дополнительной меры безопасности.   -  person Giffyguy    schedule 14.06.2015
comment
@Mikey На самом деле это неплохая идея. Позвольте мне провести некоторое тестирование и поговорить об этом с несколькими моими коллегами, и я посмотрю, сможем ли мы прийти к консенсусу.   -  person Giffyguy    schedule 14.06.2015
comment
@Giffyguy: убедитесь, что эти функции имеют встроенное табличное значение, иначе вы создадите еще большие проблемы. Я также рекомендую перейти на dba.stackexchange.com'.   -  person Pieter Geerkens    schedule 14.06.2015

Ответы (3)


arrow_upward
4
arrow_downward

Одним из возможных способов снижения общей стоимости определенных запросов, исходящих от определенной группы людей, является использование регулятора ресурсов. Вы можете регулировать, сколько ЦП и/или памяти используется конкретным пользователем/группой. Это эффективно, если у вас есть среда типа «дикий запад», где некоторые пользователи отправляют неправильные запросы, которые съедают ваши ресурсы заживо. См. здесь.

Еще одна вещь, которую следует учитывать, - это установить MAXDOP (максимальную степень параллелизма), чтобы предотвратить использование одним запросом всех доступных потоков ЦП. То есть, если MAXDOP равен 1, то для обработки любого запроса может потребоваться только 2 потока ЦП. Это полезно, чтобы предотвратить обработку больших запросов меньшими быстрыми запросами. См. здесь.

person CDC    schedule 14.06.2015
comment
О да большая помощь. Замедлите его, чтобы он держал замки дольше. - person paparazzo; 14.06.2015
comment
У вас есть конструктивная обратная связь для меня? Эти методы улучшили проблемы других людей в подобных обстоятельствах. Я не видел, чтобы у OP были проблемы с блокировкой блокировки. Он говорил о 100% использовании ресурсов. Я на самом деле думаю, что это очень полезные функции. - person CDC; 14.06.2015
comment
Блокировка никогда не вызывает проблем с ресурсами? Замедление процессов, чтобы ускорить их, редко бывает хорошей стратегией. Это конструктивная обратная связь. Вы действительно думаете, что 30-минутные запросы - это именно так? Конфликт за блокировку не происходит? - person paparazzo; 14.06.2015
comment
Конечно, блокировки вызывают конфликты. Выбранные запросы вызывают блокировки на уровне общего доступа. Они совместимы с другими блокировками общего доступа. Когда вы получаете типы ожидания CXPACKET и планировщика SOS, ничего не проходит. Это глобальное изменение, которое многие считают хорошей практикой (MAXDOP). Если просмотры вызывают тревогу, я обычно настраиваю наиболее болезненные/самые низко висящие плоды. Если есть системные проблемы, то общесистемные изменения не обязательно плохи. - person CDC; 15.06.2015
comment
Но ОП не спрашивает ни о настройке конкретного представления, ни о блокировании одного запроса другим. ОП беспокоится об общей нагрузке. Регулирование с помощью регулятора ресурсов или MAXDOP не снижает общую нагрузку. Все, что он делает, это удерживает запрос дольше, и это никогда не бывает хорошо по сравнению с общей нагрузкой. Если оптимизатор запросов хочет использовать весь ЦП и всю память, чтобы выполнить это, то это правильно. Если сервер простаивает, позвольте оптимизатору запросов сделать все необходимое. Если он загружен, пусть оптимизатор запросов регулирует (уровень нагрузки). - person paparazzo; 15.06.2015

arrow_upward
3
arrow_downward

Немного хакерски, но ставь крестик в каждом представлении.

Вы не можете применить его на стороне SQL, но для размера приложения они могут использовать TimeOut. Но если им не хватает контроля качества, им, вероятно, не хватает дисциплины для TimeOut. Если у вас есть некоторые запросы, длящиеся 30 минут, они, вероятно, устанавливают значение больше, чем значение по умолчанию.

person paparazzo    schedule 14.06.2015
comment
Мне нравится эта идея, я думаю, мне просто нужно найти способ уведомить запрашивающего через какое-то сообщение/предупреждение. Жаль, что после выбора нельзя написать триггеры. Возможно, если бы мы преобразовали представления во встроенные функции с табличным значением, мы могли бы обрабатывать там уведомления, хотя на самом деле это не является «встроенной» операцией как таковой. - person Giffyguy; 14.06.2015

arrow_upward
1
arrow_downward

Я не уверен в том, что у Блэма есть X в каждом представлении. Без соответствующего предложения ORDER BY данные будут возвращены в неопределенном порядке. В предложении CDC MAXDOP могут быть преимущества. Не столько для себя, сколько для других запросов, которые хотят выполняться одновременно.

Я был бы склонен рассмотреть возможность перехода к хранимым процедурам. Затем вы можете запросить входные параметры и оценить их, прежде чем запрос будет запущен всерьез. Если, например, диапазон дат слишком велик, вы можете ограничить его. Вы также должны выяснить, кто выполняет дорогостоящий запрос и что им действительно нужно. Похоже, они могут извлечь выгоду из некоторого ETL. Просто некоторые идеи.

person DatumPoint    schedule 19.06.2015