Oefening: de schaal aanpassen voor de prestaties van uw workload

10 minuten

In deze oefening neemt u het probleem op dat u in de eerste oefening hebt aangetroffen en verbetert u de prestaties door meer CPU's voor Azure SQL Database te schalen. U gebruikt de database die u in de vorige oefening hebt geïmplementeerd.

U vindt alle scripts voor deze oefening in de map 04 Performance\monitor_and_scale in de GitHub-opslagplaats die u hebt gekloond of het zip-bestand dat u hebt gedownload.

Azure SQL-prestaties omhoog schalen

U kunt de prestaties omhoog schalen voor een probleem dat met de CPU-capaciteit te maken lijkt te hebben door te bepalen wat uw opties zijn en vervolgens de CPU's omhoog te schalen met behulp van de beschikbare interfaces voor Azure SQL.

Bepaal hoe u prestaties gaat schalen. Omdat de werkbelasting afhankelijk is van CPU, is een manier om de prestaties te verbeteren door de CPU-capaciteit of snelheid te verhogen. Een SQL Server-gebruiker moet dan overstappen op een andere machine of een virtuele machine opnieuw configureren om meer CPU-capaciteit te verkrijgen. In sommige gevallen is zelfs een SQL Server-beheerder mogelijk niet gemachtigd om deze schaalwijzigingen aan te brengen. Het proces kan enige tijd in beslag nemen en zelfs een databasemigratie vereisen.

Voor Azure kunt u de Azure CLI of Azure Portal gebruiken ALTER DATABASEom de CPU-capaciteit te vergroten zonder databasemigratie van de gebruiker.
In Azure Portal zijn er opties beschikbaar voor het schalen van meer CPU-resources. Selecteer in het deelvenster Overzicht van uw database de prijscategorie voor de huidige implementatie. Met de prijscategorie kunt u de servicelaag en het aantal vCores wijzigen.
Hier vindt u opties voor het wijzigen of schalen van berekeningsresources. Voor Algemeen gebruik kunt u eenvoudig omhoog schalen naar bijvoorbeeld 8 vCores.

U kunt ook een andere methode gebruiken om de workload te schalen.
Voor deze oefening moet u eerst de Query Store leegmaken, zodat de verschillen in rapporten goed zichtbaar zijn. Selecteer in SQL Server Management Studio (SSMS) de AdventureWorks-database en gebruik het menu Bestand>>openen. Open het script flushhquerystore.sql in SSMS in de context van de AdventureWorks-database . Het venster van de query-editor moet er als volgt uitzien:
```
EXEC sp_query_store_flush_db;
```
Selecteer Uitvoeren om deze T-SQL-batch uit te voeren.

Notitie

Als u de voorgaande query uitvoert, wordt het in-memory gedeelte van de Query Store-gegevens naar schijf leeggemaakt.
Open het script get_service_objective.sql in SSMS. Het venster van de query-editor moet er als volgt uitzien:
```
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
```
Dit is een methode om uw servicelaag te vinden met behulp van T-SQL. De prijscategorie of servicelaag wordt ook wel een servicedoelstelling genoemd. Selecteer Uitvoeren om de T-SQL-batches uit te voeren.

De resultaten van de huidige Azure SQL Database-implementatie moeten eruitzien als in de volgende afbeelding:

U ziet dat de term slo_name ook wordt gebruikt voor de servicedoelstelling. slo betekent service level objective.

De verschillende slo_name waarden worden niet gedocumenteerd, maar u kunt zien uit de tekenreekswaarde dat deze database gebruikmaakt van een servicelaag voor algemeen gebruik met twee vCores:

Notitie

SQLDB_OP_... is de tekenreeks die wordt gebruikt voor Bedrijfskritiek.

In de ALTER DATABASE-documentatie staat de mogelijkheid om uw doel-SQL Server-implementatie te selecteren om de juiste syntaxisopties op te halen. Selecteer de individuele database/elastische pool van SQL Database voor een overzicht van de opties voor Azure SQL Database. In overeenstemming met de berekeningsschaal die u in de portal hebt gevonden, hebt u de servicedoelstelling 'GP_Gen5_8' nodig.
Wijzig de servicedoelstelling voor de database om meer CPU's te schalen. Open het script modify_service_objective.sql in SSMS en voer de T-SQL-batch uit. Het venster van de query-editor moet er als volgt uitzien:
```
ALTER DATABASE AdventureWorks MODIFY (SERVICE_OBJECTIVE = 'GP_Gen5_8');
```
Deze instructie wordt direct weergegeven, maar het schalen van de berekeningsresources vindt plaats op de achtergrond. Een dergelijke schaalbewerking duurt doorgaans minder dan een minuut. De database is gedurende korte tijd offline om de wijziging door te voeren. U kunt de voortgang van deze schaalactiviteit bewaken met behulp van Azure Portal.

In Objectverkenner onder de map Systeemdatabases klikt u met de rechtermuisknop op de master-database en selecteert u Nieuwe query. Voer deze query uit in het query editor-venster van SSMS:

SELECT * FROM sys.dm_operation_status;

Dit is een andere manier om de voortgang van een wijziging van de servicedoelstelling voor Azure SQL Database te volgen. Deze DMV beschrijft een geschiedenis van wijzigingen in de database met ALTER DATABASE aan de servicedoelstelling. De actieve voortgang van de wijziging wordt weergegeven.

Hier volgt een voorbeeld van de uitvoer van deze DMV in een tabelindeling na het uitvoeren van de voorgaande ALTER DATABASE-instructie:

Item	Weergegeven als
session_activity_id	97F9474C-0334-4FC5-BFD5-337CDD1F9A21
resource_type	0
resource_type_desc	Database
major_resource_id	AdventureWorks
minor_resource_id
schakelapparatuur optimaliseren	DATABASE WIJZIGEN
staat	1
beschr_staat	WORDT_UITGEVOERD
procent_compleet	0
code_fout	0
beschr_fout
ernst_fout	0
status_fout	0
begintijd	[datum tijd]
laatst_bijgewerkt_tijd	[datum tijd]

Tijdens een wijziging van de servicedoelstelling zijn query's toegestaan voor de database tot de laatste wijziging wordt geïmplementeerd. Een toepassing kan een zeer korte periode geen verbinding maken. Voor Azure SQL Managed Instance kunnen met een wijziging van de laag query's en verbindingen worden uitgevoerd, maar worden alle databasebewerkingen voorkomen, zoals het maken van nieuwe databases. In deze gevallen ontvangt u het volgende foutbericht: 'De bewerking kan niet worden voltooid omdat er een wijziging in de servicelaag wordt uitgevoerd voor het beheerde exemplaar [server]'. Wacht totdat de bewerking is voltooid en probeer het opnieuw.'

Wanneer dit gebeurt, gebruikt u de voorgaande query's die worden vermeld uit get_service_objective.sql in SSMS om te controleren of de nieuwe servicedoelstelling of servicelaag van 8 vCores van kracht is geworden.

De workload uitvoeren na het omhoog schalen

Nu de database meer CPU-capaciteit heeft, gaan we de workload uitvoeren die we in de vorige oefening hebben gebruikt om te zien of er prestatieverbeteringen zijn.

Nu het schalen is voltooid, controleert u of de duur van de workload sneller is en of het wachten op de CPU-resources is afgenomen. Voer de workload opnieuw uit met behulp van de opdracht sqlworkload.cmd die u in de vorige oefening hebt uitgevoerd.
Met behulp van SSMS voert u dezelfde query uit voor de eerste oefening van deze module om de resultaten van het script dmdbresourcestats.sql te bekijken:
```
SELECT * FROM sys.dm_db_resource_stats;
```
U ziet dat het gemiddelde CPU-resourcegebruik is gedaald en minder is dan het gebruik van bijna 100% in de vorige oefening. Normaal gesproken sys.dm_db_resource_stats wordt één uur activiteit weergegeven. Als u het formaat van de database wijzigt, wordt sys.dm_db_resource_stats de database opnieuw ingesteld.
Met behulp van SSMS voert u dezelfde query uit voor de eerste oefening van deze module om de resultaten van het script dmexecrequests.sql te bekijken.
```
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;
```
U ziet dat er meer query's met de status ACTIEF zijn. Dit betekent dat onze werkrollen meer CPU-capaciteit hebben om uit te voeren.
Bekijk de nieuwe duur van de workload. De duur van de workload van sqlworkload.cmd moet nu veel minder zijn, en moet ongeveer 25-30 seconden zijn.

Query Store-rapporten bekijken

Laten we eens kijken naar dezelfde Query Store-rapporten als in de vorige oefening.

Als u dezelfde technieken gebruikt als voor de eerste oefening in deze module, kijkt u naar het rapport Query's die de meeste resources verbruiken van SSMS:

U ziet nu twee query's (query_id). Dit zijn dezelfde query's, maar worden als verschillende query_id-waarden weergegeven in Query Store, omdat de schaalbewerking vereist dat de query opnieuw wordt gecompileerd. U kunt in het rapport zien dat de algemene en de gemiddelde duur aanzienlijk minder zijn.
Bekijk ook het rapport QueryWachtstatistieken en selecteer de CPU-wachtbalk . U ziet dat de totale wachttijd voor de query minder is en een lager percentage van de totale duur. Dit is een goede indicatie dat de CPU geen groot knelpunt meer is wat betreft resources wanneer de database een lager aantal vCores heeft:
U kunt alle rapporten en de vensters van de query-editor sluiten. Laat SSMS verbonden, omdat u deze in de volgende oefening nodig hebt.

Wijzigingen van Metrische gegevens voor Azure bekijken

Ga naar de AdventureWorks-database in Azure Portal en bekijk het tabblad Bewaking in het deelvenster Overzicht opnieuw voor rekengebruik:

U ziet dat de duur korter is voor hoog CPU-gebruik, wat betekent dat het aantal CPU-resources die nodig zijn voor het uitvoeren van de workload sterk daalt.
Deze grafiek kan enigszins misleidend zijn. Gebruik metrische gegevens in het menu Bewaking en stel vervolgens de metrische waarde in op DE CPU-limiet. De CPU-vergelijkingsgrafiek ziet er ongeveer als volgt uit:

Tip

Als u doorgaat met het vergroten van het aantal vCores voor deze database, kunt u de prestaties verhogen tot een drempelwaarde waarbij alle query's over veel CPU-resources beschikken. Dit betekent niet dat het aantal vCores overeen moet komen met het aantal gelijktijdige gebruikers van uw workload. Daarnaast kunt u de prijscategorie wijzigen in het gebruik van de serverloze rekenlaag in plaats van Ingericht. Zo kunt u een meer automatisch geschaalde benadering van een workload bereiken. Als u bijvoorbeeld een minimale vCore-waarde van 2 hebt gekozen voor deze workload en de maximale vCore-waarde 8, wordt deze workload onmiddellijk geschaald naar 8 vCores.

In de volgende oefening ziet u een prestatieprobleem en lost u dit op door aanbevolen procedures voor toepassingsprestaties toe te passen.

Doorgaan

Azure SQL-prestaties omhoog schalen

De workload uitvoeren na het omhoog schalen

Query Store-rapporten bekijken

Wijzigingen van Metrische gegevens voor Azure bekijken

Feedback