Редактор SQL-запросов Azure и Management Studio

Question

Я довольно плохо знаком с лазурью и облачными вычислениями в целом и хотел бы попросить вас помочь разобраться в проблеме.

Проблема была впервые замечена, когда у нас была веб-страница, на которой истекло время ожидания из-за времени ожидания sql (30 секунд).

Первым делом я подключился к производственной базе данных с помощью MS SQL Management Studio 2014 (подключен к базе данных Azure Prod)

Запустил хранимую процедуру, используемую низкоэффективной страницей, но получил возврат менее 0 секунд. Это сбило меня с толку, потому что это может быть причиной проблемы.

Случайно я также попытался выполнить тот же запрос в редакторе SQL-запросов Azure, и был шокирован, что ему потребовалось 29 секунд.

Мой главный вопрос: почему есть разница между выполнением запроса в редакторе запросов SQL Azure и Management Studio? Это точно такая же база данных.

Использование DTU составляет 98%, и мне кажется, что существует проблема с производительностью хранимого процесса, но сначала нужно узнать, почему SQL-редактор работает с SP медленнее, чем Management Studio.

У текущей лазурной БД 50 dtu.

Answer 1

Две догадки (публикация планов запросов поможет вам получить ответ на подобные ситуации):

1. SQL Server имеет различные настройки уровня сеанса. Например, есть один, чтобы определить, следует ли вам использовать поведение ansi_nulls (по сравнению с предыдущими настройками из очень старых версий SQL Server). Существуют и другие способы определения идентификаторов в кавычках. По устаревшим причинам некоторые драйверы имеют разные настройки по умолчанию. Эти различные параметры могут влиять на то, какие планы запросов будут выбраны в пределе. Хотя они не всегда влияют на производительность, есть вероятность, что вы получите сканирование вместо поиска по интересующему вас запросу.

2. Другой основной возможный путь для объяснения такого рода проблем заключается в том, что у вас есть разница в измерении параметров. Оптимизатор SQL будет смотреть на значения параметров, используемые для выбора лучшего плана (надеясь, что это значение будет представлять собой средний вариант использования для будущих значений параметров). Oracle называет это связыванием приглядывания - SQL называет это анализом параметров. Вот пост, который я сделал по этому поводу некоторое время назад, и который содержит несколько примеров: https://blogs.msdn.microsoft.com/queryoptteam/2006/03/31/i-smell-a-parameter/

Я рекомендую вам провести эксперименты, а затем заглянуть в хранилище запросов, чтобы увидеть, выбираются ли другие запросы или разные планы. Вы можете узнать о хранилище запросов и пользовательском интерфейсе SSMS здесь: https://docs.microsoft.com/en-us/sql/relational-databases/performance/monitoring-performance-by-using-the-query-store?view=sql-server-2017

В этом конкретном случае обратите внимание, что хранилище запросов предоставляет эти различные настройки уровня сеанса, используя «настройки контекста». Каждая уникальная комбинация настроек контекста будет отображаться как отдельный идентификатор настроек контекста, и это будет информировать, как интерпретируются тексты запроса. На языке хранилища запросов один и тот же текст запроса может интерпретироваться по-разному при разных настройках контекста, поэтому две разные настройки контекста для одного и того же текста запроса означают два семантически разных запроса.

Надеюсь, что это поможет - удачи в вашей задаче