Esercizio - Configurare il database SQL di Azure

Completato

Finora sono stati illustrati il portale di Azure, SQL Server Management Studio (SSMS) e i notebook di SQL in Azure Data Studio, ma sono disponibili altri strumenti per la gestione di Azure SQL. Due dei più diffusi sono l'interfaccia della riga di comando di Azure e Azure PowerShell. Offrono funzionalità simili. Questa attività è incentrata sull'interfaccia della riga di comando di Azure.

Per completare questa attività, è possibile usare un notebook di PowerShell, che si basa sullo stesso concetto di un notebook di SQL, ma il linguaggio di codifica è PowerShell. È possibile usare i notebook di PowerShell per sfruttare l'interfaccia della riga di comando di Azure o Azure PowerShell, ma questo articolo si concentrerà sui comandi dell'interfaccia della riga di comando di Azure. Per entrambi questi strumenti, è anche possibile usare Azure Cloud Shell, ovvero un ambiente di shell interattivo che è possibile usare nel browser nel portale di Azure.

In questo esercizio si userà Cloud Shell. che include già l'interfaccia della riga di comando di Azure e i moduli di Azure PowerShell.

Connessione con Azure Cloud Shell e l'interfaccia della riga di comando di Azure

Nell'esempio seguente si esamineranno gli effetti della latenza dell'uso di criteri di connessione diversi in Azure SQL.

Tutti i comandi verranno eseguiti da Cloud Shell. È possibile copiarli facilmente e quindi premere MAIUSC+INS per incollarli nel terminale.

Nota

In PowerShell tramite Azure Cloud Shell è possibile usare il modulo Az di PowerShell o l'interfaccia della riga di comando di Azure. In questa attività verrà illustrata l'interfaccia della riga di comando di Azure, ma sono disponibili comandi simili per il modulo Az di PowerShell.

  1. Passare a shell.azure.com e accedere all'account Azure, se richiesto.

  2. Configurare un gruppo di risorse predefinito e un server logico del database SQL di Azure, in modo da non doverli specificare con ogni comando az. Eseguire i comandi seguenti per impostare alcune variabili. Sostituire <resource-group> e <your-server> con i valori usati durante la creazione dell'istanza di SQL nell'esercizio precedente.

    resourceGroup="<resource-group>"
    logical_server="<your-server>"
    databaseName="AdventureWorks"
    
  3. Configurare le impostazioni predefinite in Cloud Shell per specificare il gruppo di risorse predefinito e il server logico del database Azure SQL Azure:

    az configure --defaults group=$resourceGroup sql-server=$logical_server
    
  4. Eseguire il comando seguente per verificare che siano state configurate le impostazioni predefinite:

    az configure --list-defaults
    
  5. Eseguire il comando seguente per mostrare tutti i database nel server logico del database Azure SQL:

    az sql db list
    
  6. L'elenco dei database include numerose informazioni. Eseguire il comando seguente per visualizzare solo le specifiche per il database AdventureWorks:

    az sql db show --name $databaseName
    
  7. Eseguire il comando seguente per determinare le dimensioni e l'utilizzo del database:

    az sql db list-usages --name $databaseName
    

Questi esempi usano i comandi az sql db. Sono disponibili anche comandi correlati al server logico del database SQL di Azure, Rientrano in az sql server.

Sono disponibili comandi simili per az sql mi e az sql midb. Si tratta di comandi per i database all'interno di un'istanza gestita, talvolta denominati database gestiti.

Per una spiegazione dettagliata di tutti i comandi disponibili, vedere la documentazione dell'interfaccia della riga di comando di Azure.

Gestire i criteri di connessione con l'interfaccia della riga di comando di Azure

Un'operazione per cui è possibile usare l'interfaccia della riga di comando di Azure o i comandi di Azure PowerShell è l'aggiornamento dei criteri di connessione. Questo aggiornamento è un esempio di come sia possibile gestire Azure SQL usando uno strumento come l'interfaccia della riga di comando di Azure. In questo esempio si esamineranno il database SQL di Azure e i comandi per gestire i criteri di connessione, ma l'implementazione è molto simile in Istanza gestita di SQL di Azure.

  1. Stabilire il criterio corrente usando l'interfaccia della riga di comando di Azure.

    az sql server conn-policy show
    

    I risultati indicano che il tipo di connessione è Default.

  2. Impostare il criterio di connessione su Proxy e determinare il tempo di round trip.

    # update policy
    az sql server conn-policy update --connection-type Proxy
    # confirm update
    az sql server conn-policy show
    
  3. Per testare il tempo di round trip, connettersi usando SSMS. Nel dispositivo aprire SSMS e connettersi al database. Fare clic con il pulsante destro del mouse sul database e selezionare Nuova query. Creare una nuova query con il testo seguente e quindi selezionare Query>Includi statistiche client. Nei risultati Tempo di attesa delle risposte del server è l'indicatore migliore della latenza di rete. Questa operazione può essere eseguita alcune volte per ottenere una media corretta.

    -- Proxy
    SELECT * FROM SalesLT.Product
    GO 10
    

    Dopo 10 tentativi, un tempo medio di attesa delle risposte del server potrebbe essere, ad esempio, 46.6000. I risultati potrebbero variare a seconda della connessione Internet. Prendere nota del tempo registrato.

  4. Come si deve procedere per impostare tutto come Redirect per poter provare a ottenere una latenza ridotta?

    Per tutto ciò che si trova al di fuori di Azure, è necessario consentire la comunicazione in ingresso e in uscita sulle porte nell'intervallo compreso tra 11000 e 11999. L'apertura di queste porte è necessaria per i criteri di connessione Redirect.

    Nota

    che probabilmente è già configurato nel dispositivo locale. In caso di errori nei passaggi successivi, potrebbe essere necessario abilitare le porte citate in precedenza. Per altre informazioni, vedere Porte oltre la porta 1433 per ADO.NET 4.5.

    Aggiornare il criterio di connessione e confermare l'aggiornamento con i due comandi seguenti.

    # update policy
    az sql server conn-policy update --connection-type Redirect
    # confirm update
    az sql server conn-policy show
    
  5. Per testare la latenza di rete dal criterio Redirect, connettersi con SSMS nel dispositivo locale. Creare una nuova query usando il testo seguente e scegliere Includi statistiche client per i risultati. Confrontare Tempo di attesa delle risposte del server con la query per Proxy.

    -- Redirect
    SELECT * FROM SalesLT.Product
    GO 10
    

    Dopo 10 tentativi, un tempo medio di attesa delle risposte del server potrebbe essere circa 25.8000, quasi la metà di quello del criterio di connessione proxy. Le tempistiche esatte saranno diverse a seconda della connessione, ma rispetto al test del proxy precedente, dovrebbero essersi ridotte in modo significativo.

  6. Impostare di nuovo il criterio sul valore predefinito per l'esercizio successivo, usando i comandi seguenti:

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

Il reindirizzamento è più veloce perché, dopo la connessione iniziale, è possibile ignorare il gateway e passare direttamente al database. Ciò significa un minor numero di hop e quindi una latenza minore. Una latenza ridotta contribuisce a prevenire i colli di bottiglia, il che è particolarmente importante per le applicazioni di chat. Nel modulo sulle prestazioni verranno fornite altre informazioni su come migliorare e ottimizzare le prestazioni.