Övning – Konfigurera Azure SQL Database

  • 10 minuter

Nu har du sett Azure-portalen, SQL Server Management Studio (SSMS) och SQL-notebook-filer i Azure Data Studio. Andra verktyg är tillgängliga för att hantera Azure SQL. Två av de mest populära är Azure CLI och Azure PowerShell. De är liknande i funktioner. Den här aktiviteten fokuserar på Azure CLI.

För den här övningen kan du använda en PowerShell-notebook, vilket är samma koncept som en SQL-notebook-fil men där programmeringsspråket är PowerShell. Du kan använda PowerShell-notebook-filer för att dra nytta av Azure CLI eller Azure PowerShell. Den här artikeln fokuserar på Azure CLI-kommandon. Du kan också använda Azure Cloud Shell för båda dessa verktyg. Det är en interaktiv gränssnittsmiljö som du kan använda via webbläsaren i Azure-portalen.

I den här övningen använder vi Cloud Shell. Det innehåller redan moduler för Azure CLI och Azure PowerShell.

Ansluta med Azure Cloud Shell och Azure CLI

I exemplet nedan utforskar du svarstidseffekterna av att använda olika anslutningsprinciper i Azure SQL.

Kör alla kommandon med hjälp av Cloud Shell. Du kan enkelt kopiera dem och sedan välja Skift+Infoga för att klistra in i terminalen.

Kommentar

I PowerShell med hjälp av Azure Cloud Shell kan du använda PowerShell Az-modulen eller Azure CLI. I den här aktiviteten utforskar vi Azure CLI, men liknande kommandon är tillgängliga för PowerShell Az-modulen.

  1. Gå till shell.azure.com och logga in på ditt Azure-konto om du uppmanas att göra det.

  2. Konfigurera en standardresursgrupp och en logisk Azure SQL Database-standardserver så att du inte behöver ange dem i varje az-kommando. Kör följande kommandon för att ange några variabler. Ersätt <resource-group> och <your-server> med de värden som du använde när du skapade SQL-instansen i föregående övning.

    resourceGroup="<resource-group>"
logical_server="<your-server>"
databaseName="AdventureWorks"

  3. Ange standardvärdena i Cloud Shell för att ange din standardresursgrupp och logiska Azure SQL Database-server:

    az configure --defaults group=$resourceGroup sql-server=$logical_server

  4. Kör följande kommando för att bekräfta att standardvärdena har angetts:

    az configure --list-defaults

  5. Kör följande kommando för att visa alla databaser på den logiska Azure SQL Database-servern:

    az sql db list

  6. Listan med databaser innehåller mycket information. Kör följande kommando om du bara vill se detaljer för AdventureWorks databasen:

    az sql db show --name $databaseName

  7. Kör följande kommando för att fastställa databasens storlek och användning:

    az sql db list-usages --name $databaseName

I de här exemplen används kommandona az sql db . Det finns även kommandon relaterade till den logiska Azure SQL Database-servern. De faller under az sql server.

Det finns liknande kommandon för az sql mi och az sql midb. De är kommandon för databaser i en hanterad instans, som ibland kallas för hanterade databaser.

Detaljerade förklaringar av alla tillgängliga kommandon finns i Azure CLI-dokumentationen.

Hantera anslutningspolicyer via Azure CLI

En sak som du kan använda Azure CLI- eller Azure PowerShell-kommandon för är att uppdatera anslutningsprincipen. Den här uppdateringen är ett exempel på hur du kan hantera Azure SQL med hjälp av ett verktyg som Azure CLI. I det här exemplet tittar du på Azure SQL Database och dess kommandon för att hantera anslutningsprinciperna. Implementeringen är liknande i Azure SQL Managed Instance.

  1. Identifiera den aktuella principen med hjälp av Azure CLI.

    az sql server conn-policy show

    Resultatet visar att anslutningstypen är Default.

  2. Ställ in anslutningspolicyn som Proxy och fastställ den totala svarstiden.

    # update policy
az sql server conn-policy update --connection-type Proxy
# confirm update
az sql server conn-policy show

  3. Om du vill testa tur och retur-tid ansluter du med hjälp av SSMS. Öppna SSMS på enheten och anslut till din databas. Högerklicka på din databas och välj New Query (Ny fråga). Skapa en ny fråga med följande text och välj sedan Fråga>inkludera klientstatistik. I resultatet är Wait time on server replies (Väntetid för serversvar) den bästa indikatorn för svarstider i nätverket. Du kan köra den här frågan några gånger för att få ett bra genomsnitt.

    -- Proxy
SELECT * FROM SalesLT.Product
GO 10

    Efter 10 försök kan en genomsnittlig väntetid för serversvar vara ungefär 46.6000. Beroende på internetanslutningen kan resultatet variera. Anteckna tiden du ser.

  4. Hur ska du göra för att använda Redirect så att du kan korta ned svarstiderna?

    För allt som finns utanför Azure måste du tillåta inkommande och utgående kommunikation på portar mellan 11 000 och 11999. Det krävs att du öppnar dessa portar för anslutningsprincipen Redirect .

    Kommentar

    Det här är förmodligen redan konfigurerat på den lokala enheten. Om du stöter på fel i de kommande stegen kan du behöva aktivera de här portarna. Mer information finns i Portar utöver 1433 för ADO.NET 4.5.

    Uppdatera anslutningsprincipen och bekräfta uppdateringen med följande två kommandon.

    # update policy
az sql server conn-policy update --connection-type Redirect
# confirm update
az sql server conn-policy show

  5. Testa nätverksfördröjningen med policyn Redirect genom att ansluta till SSMS från den lokala enheten. Skapa en ny fråga med följande text och välj Include Client Statistics (Ta med klientstatistik) för resultatet. Jämför Wait time on server replies (Väntetid för serversvar) med din fråga för policyn Proxy.

    -- Redirect
SELECT * FROM SalesLT.Product
GO 10

    Efter 10 utvärderingsversioner kan en genomsnittlig väntetid på serverns svar ligga runt 25.8000, vilket är nästan hälften av principen för proxyanslutning. Exakta tidsinställningar varierar beroende på din anslutning. Tiden bör minskas avsevärt jämfört med ditt tidigare proxytest.

  6. Ställ in principen som standard för nästa övning med hjälp av följande kommandon:

    # update policy
az sql server conn-policy update --connection-type Default
# confirm update
az sql server conn-policy show

Omdirigeringen går snabbare eftersom du efter den första anslutningen kan kringgå gatewayen och gå direkt till databasen. Den här förbikopplingen innebär färre hopp, vilket resulterar i mindre svarstid. Kortare svarstid bidrar till att förhindra flaskhalsar, vilket är särskilt viktigt i trafikintensiva program. I prestandamodulen lär du dig mer om hur du förbättrar och optimerar prestanda.