Microsoft Azure — настройка Azure SQL с помощью Azure CLI
В этой статье мы подробно рассмотрим, как можно настроить что-то вроде подключения с помощью Azure CLI. Что у нас здесь, так это то, что мы находимся в Azure Data Studio и, как и в блокноте SQL, на самом деле используем блокнот PowerShell . Это просто означает, что все наши ячейки кода будут запускать PowerShell , и мы просто подключаемся к локальному хосту .
Теперь следует отметить, что мы можем использовать Azure CLI или эти команды az , чтобы в основном выполнять различные задачи со всеми нашими ресурсами Azure, не обязательно только с базой данных SQL Azure или управляемым экземпляром Azure SQL. Мы также можем использовать это в Cloud Shell. Или мы можем использовать Azure CLI и что-то вроде PowerShell, как мы делаем здесь.
В этом примере мы рассмотрим, как настроить подключение к Azure SQL, и кратко рассмотрим, как это влияет на производительность.
Во-первых, мы используем приведенную ниже команду, чтобы получить текущую политику подключения к нашему логическому серверу базы данных SQL Azure.
az sql server conn-policy show
Как вы видите, у нас есть ответ по умолчанию. Этот ответ по умолчанию означает, что для служб в Azure мы будем использовать метод перенаправления, а для служб за пределами Azure — метод прокси.
Теперь для этого небольшого теста, который мы собираемся выполнить, мы собираемся обновить политику подключения к прокси . Итак, в основном мы хотим, чтобы все шло к шлюзу, а затем к базе данных. Здесь мы использовали обновление политики подключения к SQL-серверу AZ, а затем указываем тип политики прокси-сервера, а затем мы просто распечатываем этот тип подключения, чтобы убедиться, что он работает.
Теперь, когда это сработало, мы можем провести неофициальный тест, чтобы увидеть, как это влияет на производительность. Итак, в SSMS мы просто создадим новый запрос, в котором выберем все из SalesLT.Product и включим статистику клиента. Затем мы собираемся запустить это 10 раз, а затем мы можем получить хорошее среднее значение, чтобы увидеть, какова наша сетевая задержка.
Теперь, когда он запущен, мы можем зайти в «Статистика клиента» и внизу, мы можем увидеть время ожидания ответов сервера. Теперь, если мы прокрутим до упора вправо, мы увидим, что среднее время ожидания ответов сервера составляет около 192,78 миллисекунд.
По сути, это означает, что это может указывать на задержку в сети, которую мы наблюдаем.
Теперь, если мы вернемся к Azure Data Studio и запомним это число в 50 миллисекунд, мы собираемся обновить политику для перенаправления. Помните, что при перенаправлении мы собираемся перейти к шлюзу в первый раз, но затем мы собираемся перейти непосредственно к базе данных после этого. Итак, что я сделал, так это использовал ту же команду, чтобы просто обновить политику подключения для перенаправления, а затем мы просто распечатали тип подключения, чтобы подтвердить, что это сработало.
Опять же, теперь мы собираемся сделать то же самое в SSMS, за исключением того, что мы собираемся сделать это с перенаправлением и посмотреть, есть ли изменения. Итак, мы включим клиентскую статистику и запустим ее примерно 10 раз. Теперь, когда это сделано, мы можем снова проверить клиентскую статистику и посмотреть на время ожидания ответов сервера, которое указывает на задержку, и то, что мы видим, составляет около 125 миллисекунд для времени ожидания ответов сервера.
С перенаправлением мы смогли получить 67 миллисекунд сетевой задержки, что значительно меньше, чем 192 миллисекунды, которые мы видели для прокси-соединения. Теперь это изменится в вашей сети, вашем интернет-соединении и множестве других вещей, но вы увидите сокращение этой задержки с помощью метода перенаправления. Итак, в этой демонстрации вы увидели, как использовать Azure CLI для настройки различных вещей, в данном случае подключения SQL.