練習 - 調整工作負載的效能

10 分鐘

在此練習中，您將使用第一個練習中遇到的問題，並為 Azure SQL Database 增加更多 CPU 來改善效能。您將使用您在上一個練習中部署的資料庫。

此練習中的所有指令碼都可在您複製的 GitHub 存放庫中的 04-Performance\monitor_and_scale 資料夾，或您下載的 ZIP 檔案中找到。

擴大 Azure SQL 效能

若要針對可能是 CPU 容量問題的問題調整效能，您應該決定自己的選項，然後使用為 Azure SQL 提供的介面調整 CPU。

決定如何調整效能。由於工作負載與 CPU「繫結」，因此改善效能的其中一種方式就是增加 CPU 容量或速度。 SQL Server 使用者必須移至不同的機器，或重新設定 VM 以取得更多 CPU 容量。在某些情況下，即使是 SQL Server 系統管理員都可能無權調整變更這些項目。此程序可能需要一些時間，甚至需要移轉資料庫。

在 Azure，您可使用 ALTER DATABASE、Azure CLI 或 Azure 入口網站來增加 CPU 容量，而無需使用者移轉任何資料庫。
使用 Azure 入口網站，您可看到可調整更多 CPU 資源的多個選項。在資料庫的 [概觀] 窗格中，選取目前部署的 [定價層]。 [定價層] 可供變更服務層和虛擬核心數目。
您可以在這裡看到變更或調整計算資源的選項。針對一般用途，您可輕鬆地進行擴大，例如擴大為 8 個虛擬核心。

您也可以使用不同的方法來縮放工作負載。
在本練習中，您必須先排清查詢存放區才能在報告中看到適當的差異。在 SQL Server Management Studio (SSMS) 中，選取 [AdventureWorks] 資料庫，然後使用 [檔案] > [開啟] > [檔案] 功能表。在 [AdventureWorks] 資料庫的內容中，於 SSMS 開啟指令碼 [flushhquerystore.sql]。您的 [查詢編輯器] 視窗看起來應類似下列文字：
```
EXEC sp_query_store_flush_db;
```
選取 [執行] 以執行此 T-SQL 批次。

注意

執行上述查詢會將查詢存放區資料記憶體內部部分排清到磁碟。
在 SSMS 中開啟 get_service_objective.sql指令碼。您的 [查詢編輯器] 視窗看起來應類似下列文字：
```
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
```
這是使用 T-SQL 來找出服務層級的方法。定價或服務層級也稱為「服務目標」。選取 [執行] 以執行 T-SQL 批次。

針對目前的 Azure SQL Database 部署，您的結果看起來應該會如下圖所示：

請注意，slo_name 一詞也會用於服務目標。 slo 代表「服務等級目標」。

不同的 slo_name 值並未記載，但您可從字串值中看到，此資料庫使用一般用途服務層級搭配兩個虛擬核心：

注意

SQLDB_OP_... 是用於業務關鍵的字串。

當檢視 ALTER DATABASE 文件時，請注意選取目標 SQL Server 部署以取得正確語法選項的功能。選取 [SQL Database 單一資料庫/彈性集區] 來查看 Azure SQL Database 的選項。若要和您在入口網站中找到的計算規模相符，您需要服務目標 'GP_Gen5_8'。
修改資料庫的服務目標，以調整更多 CPU。在 SSMS 中開啟 modify_service_objective.sql 指令碼，並執行 T-SQL 批次。您的 [查詢編輯器] 視窗看起來應類似下列文字：
```
ALTER DATABASE AdventureWorks MODIFY (SERVICE_OBJECTIVE = 'GP_Gen5_8');
```
此陳述式會立即返回，但計算資源的縮放會在背景中進行。此小型縮放應該用不到一分鐘，且在短時間內，資料庫將會離線，以讓變更生效。您可使用 Azure 入口網站來監視此縮放活動的進度。

在 [物件總管] 中，於 [系統資料庫] 資料夾下方，以滑鼠郵件按一下 master 資料庫，然後選取 [新增查詢]。在 SSMS 查詢編輯器視窗中執行此查詢：

SELECT * FROM sys.dm_operation_status;

這是另一種監視 Azure SQL Database 服務目標變更進度的方式。此動態管理檢視 (DMV) 會對服務目標使用 ALTER DATABASE 來公開資料庫的變更歷程記錄。其會顯示變更的進度。

以下是在執行上述 ALTER DATABASE 陳述式後，這個 DMV 輸出以資料表格式呈現的範例：

項目	值
session_activity_id	97F9474C-0334-4FC5-BFD5-337CDD1F9A21
resource_type	0
resource_type_desc	Database
major_resource_id	AdventureWorks
minor_resource_id
作業	ALTER DATABASE
state	1
state_desc	IN_PROGRESS
percent_complete	0
error_code	0
error_desc
error_severity	0
error_state	0
start_time	[date time]
last_modify_time	[date time]

在服務目標變更期間，您可對資料庫進行查詢，直到實作最後的變更為止。應用程式會有一小段時間無法連線。針對 Azure SQL 受控執行個體，變更層級會允許查詢和連線，但會防止所有資料庫作業 (例如建立新的資料庫)。您會收到下列錯誤訊息：「作業無法完成，因為正在針對受控執行個體 '[伺服器]' 進行服務層級變更。請等候正在進行的作業完成，並再試一次。」

完成這項作業時，請在 SSMS 中使用 get_service_objective.sql 中所列的上述查詢，以驗證新服務目標或 8 個虛擬核心的服務層級已生效。

在擴大之後執行工作負載

現在，資料庫已有更多的 CPU 容量，讓我們來執行前一個練習中所進行的工作負載，以觀察效能是否有改進。

現在已完成調整，請檢查工作負載的持續時間是否變快，以及 CPU 資源的等候是否已減少。請使用在上一個練習中執行的 sqlworkload.cmd 命令，再次執行工作負載。
使用 SSMS 來執行本課程模組第一個練習中 dmdbresourcestats.sql 指令碼內的相同查詢以觀察結果：
```
SELECT * FROM sys.dm_db_resource_stats;
```
您應該會看到平均 CPU 資源使用量已從先前練習中將近 100% 的使用量減少。一般而言，sys.dm_db_resource_stats 會顯示一個小時的活動。重設資料庫大小會導致 sys.dm_db_resource_stats 重設。
使用 SSMS 來執行此課程模組第一個練習中 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;
```
您將會看到有更多查詢的狀態為 RUNNING。這表示我們的背景工作角色有更多的 CPU 容量可執行。
觀察新的工作負載持續時間。 sqlworkload.cmd 的工作負載持續時間現在應該會減少，大約為 25 到 30 秒。

觀察查詢存放區報表

讓我們看一下先前練習中所做的相同查詢存放區報表。

使用與本課程模組中第一個練習相同的技術，從 SSMS 查看最高資源耗用查詢報表：

您現在將會看到兩個查詢 (query_id)。這些都是相同查詢，但會在查詢存放區中顯示不同的 query_id 值，因為縮放作業需要重新啟動及重新編譯查詢。您可以在報表中看到整體和平均持續時間明顯降低。
另請參閱 [查詢等候統計資料] 報告，然後選取 [CPU 等候] 列。您可看到查詢的整體平均等候時間變少，而整體持續時間的百分比變低。這是好現象，其表示資料庫已經沒有先前虛擬核心數較少時的資源瓶頸：
您可關閉所有報告和查詢編輯器視窗。讓 SSMS 保持連線，因為您在下一個練習中將會用到 SSMS。

觀察 Azure 計量的變更

前往 Azure 入口網站中的 [AdventureWorks] 資料庫，並在 [概觀] 窗格的 [監視] 索引標籤再次查看 [計算使用率]：

請注意，高 CPU 使用率的持續時間較短，這表示執行工作負載所需的 CPU 資源整體下降。
此圖表可能有點誤導。從 [監視] 功能表中，使用 [計量]，然後將 [計量] 設定為 [CPU 限制]。 CPU 比較圖表看起來會像下列圖表：

提示

如果繼續增加此資料庫的虛擬核心，則可將效能提升至閾值，其中所有查詢都有大量的 CPU 資源。這並不表示必須將虛擬核心數目與工作負載中的並行使用者數目進行比對。此外，您可將定價層變更為使用無伺服器的「計算層」，而不是「已佈建」。這可有助為工作負載實現更符合「自動調整」的方法。例如，針對此工作負載，如果選擇 2 做為虛擬核心數下限，而選擇 8 做為虛擬核心數上限，則此工作負載會立即調整為 8 個虛擬核心。

在下一個練習中，您將會在其中觀察效能問題，並套用應用程式效能的最佳做法來解決此問題。

練習 - 調整工作負載的效能

擴大 Azure SQL 效能

在擴大之後執行工作負載

觀察查詢存放區報表

觀察 Azure 計量的變更

意見反應