Esercizio - Ridimensionare le prestazioni del carico di lavoro

Completato

In questo esercizio si esaminerà il problema riscontrato nel primo esercizio e si miglioreranno le prestazioni ridimensionando più CPU per database SQL di Azure. Si userà il database distribuito nell'esercizio precedente.

È possibile trovare tutti gli script per questo esercizio nella cartella 04-Performance\monitor_and_scale nel repository GitHub clonato o nel file ZIP scaricato.

Aumentare le prestazioni di Azure SQL

Per ridimensionare le prestazioni per un problema che sembra essere relativo alla capacità della CPU, è necessario stabilire quali sono le opzioni e quindi procedere con il ridimensionamento delle CPU usando le interfacce fornite per Azure SQL.

1. Stabilire come ridimensionare le prestazioni. Poiché il carico di lavoro è associato alla CPU, un modo per migliorare le prestazioni consiste nell'aumentare la capacità o la velocità della CPU. Un utente SQL Server deve passare a un computer diverso o riconfigurare una VM per ottenere una maggiore capacità di CPU. In alcuni casi, anche un amministratore di SQL Server potrebbe non avere l'autorizzazione per apportare queste modifiche di ridimensionamento. Il processo può richiedere tempo e anche una migrazione del database.

   Per Azure è possibile usare ALTER DATABASE, l'interfaccia della riga di comando di Azure o il portale di Azure per aumentare la capacità della CPU senza migrazione del database da parte dell'utente.

2. Usando il portale di Azure, è possibile visualizzare le opzioni per il ridimensionamento al fine di aumentare le risorse della CPU. Nel riquadro Panoramica del database selezionare il piano tariffario per la distribuzione corrente. L'opzione Piano tariffario consente di modificare il livello di servizio e il numero di vCore.

   

3. Qui è possibile visualizzare le opzioni per la modifica o il ridimensionamento delle risorse di calcolo. Per il livello Utilizzo generico, è possibile ridimensionare facilmente fino a 8 vCore.

   

   È anche possibile usare un metodo diverso per ridimensionare il carico di lavoro.

4. Per questo esercizio, è necessario prima scaricare Query Store, in modo da poter vedere le differenze appropriate nei report. In SQL Server Management Studio (SSMS) selezionare il database AdventureWorks e usare il menu File Open File (File>Open>File). Aprire lo script flushhquerystore.sql in SSMS nel contesto del database AdventureWorks . La finestra dell'editor di query avrà un aspetto simile al testo seguente:

   EXEC sp_query_store_flush_db;
   

   Selezionare Esegui per eseguire questo batch T-SQL.

   Nota

   L'esecuzione della query precedente scarica la parte in memoria dei dati di Query Store su disco.

5. Aprire lo script get_service_objective.sql in SSMS. La finestra dell'editor di query avrà un aspetto simile al testo seguente:

   SELECT database_name,slo_name,cpu_limit,max_db_memory, max_db_max_size_in_mb, primary_max_log_rate,primary_group_max_io, volume_local_iops,volume_pfs_iops
   FROM sys.dm_user_db_resource_governance;
   GO
   SELECT DATABASEPROPERTYEX('AdventureWorks', 'ServiceObjective');
   GO
   

   Si tratta di un metodo per individuare il livello di servizio usando T-SQL. Il piano tariffario o il livello di servizio è noto anche come obiettivo di servizio. Selezionare Esegui per eseguire i batch T-SQL.

   Per la distribuzione corrente del database SQL di Azure, i risultati dovrebbero essere simili all'immagine seguente:

   

   Si noti che il termine slo_name viene usato anche per l'obiettivo di servizio. slo è l'acronimo di service level objective (obiettivo del livello di servizio).

   I vari slo_name valori non sono documentati, ma è possibile vedere dal valore stringa che questo database usa un livello di servizio per utilizzo generico con due vCore:

   Nota

   SQLDB_OP_... è la stringa usata per il livello business critical.

   Quando si visualizza la documentazione di ALTER DATABASE, notare la possibilità di selezionare la distribuzione di SQL Server di destinazione per ottenere le opzioni di sintassi corrette. Selezionare Database SQL singolo/pool elastico per visualizzare le opzioni per il database SQL di Azure. Per trovare la corrispondenza con la scalabilità di calcolo disponibile nel portale, è necessario l'obiettivo 'GP_Gen5_8'del servizio .

6. Modificare l'obiettivo di servizio per il database per ridimensionare più CPU. Aprire lo script modify_service_objective.sql in SSMS ed eseguire il batch T-SQL. La finestra dell'editor di query avrà un aspetto simile al testo seguente:

   ALTER DATABASE AdventureWorks MODIFY (SERVICE_OBJECTIVE = 'GP_Gen5_8');
   

   Questa istruzione restituisce immediatamente il risultato, ma il ridimensionamento delle risorse di calcolo avviene in background. Un ridimensionamento così ridotto richiede meno di un minuto e per un breve periodo di tempo il database sarà offline per rendere effettiva la modifica. È possibile monitorare lo stato di avanzamento dell'attività di ridimensionamento usando il portale di Azure.

   

7. In Esplora oggetti, nella cartella Database di sistema fare clic con il pulsante destro del mouse sul database master e scegliere Nuova query. Eseguire questa query nella finestra dell'editor di query di SSMS:

   SELECT * FROM sys.dm_operation_status;
   

   Si tratta di un altro modo per monitorare lo stato di avanzamento di una modifica per l'obiettivo di servizio per il database SQL di Azure. Questa DMV espone una cronologia delle modifiche apportate al database con ALTER DATABASE all'obiettivo di servizio. Mostra lo stato attivo della modifica.

   Di seguito è riportato un esempio di output di questa DMV in un formato di tabella dopo l'esecuzione dell'istruzione ALTER DATABASE precedente:

   Articolo	valore
   session_activity_id	97F9474C-0334-4FC5-BFD5-337CDD1F9A21
   resource_type	0
   resource_type_desc	Database
   major_resource_id	AdventureWorks
   minor_resource_id
   operation (operazione)	ALTER DATABASE
   state	1
   state_desc	IN_PROGRESS
   percent_complete	0
   error_code	0
   error_desc
   error_severity	0
   error_state	0
   start_time	[data ora]
   last_modify_time	[data ora]

   Durante una modifica per l'obiettivo di servizio, le query sul database sono consentite fino a quando non viene implementata la modifica finale. Un'applicazione non può connettersi per un periodo di tempo molto breve. Per Istanza gestita di SQL di Azure, una modifica del livello consente di eseguire query e connessioni, ma impedisce tutte le operazioni di database, ad esempio la creazione di nuovi database. In questi casi viene visualizzato il messaggio di errore seguente: "Impossibile completare l'operazione perché è in corso una modifica del livello di servizio per l'istanza gestita "[server]". Attendere il completamento dell'operazione in corso e riprovare."

8. Al termine, usare le query precedenti elencate da get_service_objective.sql in SSMS per verificare che sia stato applicato il nuovo obiettivo di servizio o il livello di servizio di 8 vCore.

Eseguire il carico di lavoro dopo il ridimensionamento

Ora che il database ha una maggiore capacità di CPU, verrà eseguito il carico di lavoro eseguito nell'esercizio precedente per verificare se esiste un miglioramento delle prestazioni.

1. Ora che il ridimensionamento è stato completato, controllare se la durata del carico di lavoro è più veloce e se le attese delle risorse della CPU sono diminuite. Eseguire di nuovo il carico di lavoro usando il comando sqlworkload.cmd eseguito nell'esercizio precedente.

2. Usando SSMS, eseguire la stessa query del primo esercizio di questo modulo per osservare i risultati dello script dmdbresourcestats.sql:

   SELECT * FROM sys.dm_db_resource_stats;
   

   Si noterà che l'utilizzo medio delle risorse della CPU è diminuito rispetto all'utilizzo quasi al 100% nell'esercizio precedente. In genere, sys.dm_db_resource_stats visualizza un'ora di attività. Il ridimensionamento del database causa sys.dm_db_resource_stats la reimpostazione.

3. Usando SSMS, eseguire la stessa query del primo esercizio di questo modulo per osservare i risultati dello script dmexecrequests.sql.

   SELECT er.session_id, er.status, er.command, er.wait_type, er.last_wait_type, er.wait_resource, er.wait_time
   FROM sys.dm_exec_requests er
   INNER JOIN sys.dm_exec_sessions es
   ON er.session_id = es.session_id
   AND es.is_user_process = 1;
   

   Si noterà che sono presenti più query con lo stato RUNNING. Ciò significa che i ruoli di lavoro hanno più capacità di CPU da eseguire.

4. Osservare la nuova durata del carico di lavoro. La durata del carico di lavoro di sqlworkload.cmd sarà ora molto inferiore, attorno ai 25-30 secondi circa.

Osservare i report di Query Store

Si osservino gli stessi report di Query Store come nell'esercizio precedente.

1. Usando le stesse tecniche del primo esercizio di questo modulo, esaminare il report Prime query per consumo di risorse da SSMS:

   

   Verranno ora visualizzate due query (query_id). Si tratta della stessa query, ma con valori query_id diversi in Query Store perché l'operazione di ridimensionamento ha richiesto un riavvio ed è stato necessario ricompilare la query. Nel report è possibile osservare che la durata complessiva e media è notevolmente inferiore.

2. Esaminare anche il report Query Wait Statistics (Statistiche di attesa query) e selezionare la barra di attesa della CPU. È possibile osservare che il tempo medio di attesa complessivo per la query è minore e corrisponde a una percentuale inferiore della durata complessiva. Si tratta di una buona indicazione che la CPU non rappresenta più un collo di bottiglia per le risorse rispetto a quando il database aveva un numero inferiore di vCore:

   

3. È possibile chiudere tutti i report e le finestre dell'editor di query. Lasciare connesso SSMS perché sarà necessario nell'esercizio successivo.

Osservare le modifiche dalle metriche di Azure

1. Passare al database AdventureWorks nel portale di Azure ed esaminare di nuovo la scheda Monitoraggio nel riquadro Panoramica per Utilizzo calcolo:

   

   Si noti che la durata è più breve per un utilizzo elevato della CPU, il che indica un calo generale delle risorse della CPU necessarie per eseguire il carico di lavoro.

2. Questo grafico può essere piuttosto fuorviante. Dal menu Monitoraggio usare Metriche, quindi impostare Metrica su Limite CPU. Il grafico di confronto della CPU è simile al seguente:

   

Suggerimento

Se si continua ad aumentare il numero di vCore per questo database, è possibile migliorare le prestazioni fino a una soglia in cui tutte le query dispongono di molte risorse della CPU. Ciò non significa che è necessario far corrispondere il numero di vCore al numero di utenti simultanei del carico di lavoro. È anche possibile modificare il piano tariffario per usare il livello di calcolo serverless anziché provisioning. In questo modo è possibile ottenere un approccio più basato sul ridimensionamento automatico per un carico di lavoro. Ad esempio, se si sceglie un valore vCore minimo pari a 2 per questo carico di lavoro e il valore vCore massimo pari a 8, il carico di lavoro verrà ridimensionato immediatamente a 8 vCore.

Nell'esercizio successivo si osserverà un problema di prestazioni e lo si risolve applicando le procedure consigliate per le prestazioni dell'applicazione.