黯雲端記事錄

說明

挑選適合的 SQL 資料庫服務

在開始介紹計費模式和定價層之前，不免俗的要說明一下在 Azure 上面要使用 SQL 資料庫，基本上會有三個主要可以選擇的方案：

• SQL Database
• SQL 受控執行個體 (SQL Managed Instance，SQL MI)
• SQL Server VM

以上三個服務以相容性來看，SQL Server VM 當然是最符合原本地端的 SQL Server 也是所有功能都可以使用的方案，但是相對的管理成本也是最高，因為除了 SQL Server 管理之外，還有 VM 需要管理，包含作業系統和 SQL Server 版本升級或更新上都是需要專職的人員來管理，其他更細部的差異和比較可以參考官方的三篇文章，有分別的比較。

• 功能比較：Azure SQL Database 和 Azure SQL 受控執行個體
• Azure SQL Database 與 SQL Server 差異
• Azure SQL 受控執行個體與 SQL Server 差異

但這邊就一些大方向的選擇依據，我簡單整理成下表，可以初步的判斷適合哪一個服務。其中特別把比較常被問到的功能跟限制拿出來說明，一個就是使用 Linked Server 來跨資料庫存取和 DB Mail 在 SQL Database 是不支援的，但是是可以透過其他功能或服務來使用，跨資料庫存取可以使用彈性查詢來支援，但是在設定和使用上就沒有 Linked Server 來的方便，而 DB Mail 就可以使用 SendGrid 這類型第三方發信的服務來使用，就得配合去修改程式來支援了。而在管理 DB 上面會針對各種細節去調整效能，比如說硬碟 IO 等，又有專職的 DBA，那就會推薦 SQL Server VM 了，如果要兼具 PAAS 的方便管理又不會用到接觸底層硬體的 SQL 語法，就可以使用 SQL MI 了，而如果比較單純的 CRUD 或關連等，就很推薦 SQL Database 了。

	SQL Database	SQL 受控執行個體	SQL Server VM
相容性	中高	高	最高
管理成本	低	中	高
跨資料庫存取 (linked servers)	否	支援	支援
DB Mail	不支援	支援	支援

此外微軟也提供 Data Migration Assistant 這一個工具可以協助評估和搬遷資料庫，可以參考官方的文件來使用，就不多做說明了。

定價模型

評估且確認可以使用 SQL Database 之後，第一個要面對的問題就是選擇定價模型，定價模型上面有 DTU 和 vCore 這兩種定價模型，而官方說明和適用的對象可以參考如下：

可能看完官方這樣說明還是不知道要選擇哪一個或是有什麼差異，這時候在配合官方這張圖來解釋就會比較清楚了。

DTU 是微軟定義出來的資料庫交易單位，它包含了計算、儲存體和I/O 資源，而他定價方式和資源就如同下圖左邊顯示，是呈現線性的，也就是運算能力需要越高，儲存體也會相對的提昇，選擇這一個模型比較像是公司業務成長，資料也會相對的變多，也就需要更多運算資源來處理資料，就可以簡單的選擇這一個定價模型。

而 vCore 則是想更有彈性的設定需要的儲存空間、運算資源就可以選擇這一個，因為有可能資料量不大，但是會需要較大的運算資源，相對 DTU 來說就有機會設定出較低成本的組合，而不是得直接線性的成本提昇，加上 vCore 可以配合原有的 SQL Server SA 授權就可以使用 Azure Hybrid Benefit，就可以把原本授權帶上雲端使用，也可以節省成本，未來 vCore 還可以購買 RI 來達到節省成本。vCore 在評估跟設定上會有底下的幾個要素：

• 服務層級
• 硬體組態
• 計算資源 (虛擬核心數目與記憶體數量)
• 保留的資料庫儲存體
• 實際備份儲存體

小結一下，初期還不知道要選擇哪一個的時候，可以先選擇 DTU，就可以不用考慮太多，之後比較服務比較穩定之後，就比較好評估選擇 vCore 需要多少核心數跟多大的儲存體空間來存放資料，而兩種模型中間是可以切換的，所以可以針對需求隨時調整到合適的定價模型。

模型和定價層調整或多或少都會有服務中斷的時間

彈性集區

接下來要介紹的是彈性集區，不管是 DTU 或是 vCore 都有支援彈性集區，在有多個資料庫的情形下我們是可以透過彈性集區來共用資源的，但是也不是說 2 個以上就一定選擇彈性集區就可以節省到費用，還是需要評估資源使用的情形的。

以官方給的範例和圖片來說明一下：

這是單一資料庫的資源使用情形，我們可以看到在部分時段 DTU 使用率是高於 50 DTU 的，最高甚至到 90 DTU，如果為了讓服務在每一個時段可以正常運作，那我們就得選擇 100 DTU (S3) 定價層，當我們有多個這樣使用情形的資料庫，如下圖所示有 4 個資料庫，如果每一個資料庫都要為了可以在任何時段都可以正常運作的話，就會需要 100 DTU * 4 的價錢，但是我們選擇彈性集區的話，只需要 1 個 100 eDTU (彈性集區計費單位) 的彈性集區就可以了，雖然費用上同規格 DTU 和彈性集區價格比是 1.5 倍，但是我們還是可以省下不少費用。

同規格 vCore 彈性集區價格相同，同規格 DTU 彈性集區則為 1.5 倍。

但是這邊會需要特別提一個地雷，就是 eDTU 基本定價層，單一資料庫 eDTU 上限是 5 eDTU，也就是說前面說的最高 eDTU 的共用資源的好處就沒有了，所以如果是 DTU 定價模型要使用彈性集區的話，請考慮標準或進階定價層。

而在官方文件也列出底下幾個步驟來決定是否適合使用以及該挑選怎樣規格的定價層：

1. 估計集區所需的 eDTU 或虛擬核心：
   • 針對以 DTU 為基礎的購買模型：
     • MAX(<DB 總數 × 每個 DB 平均 DTU 使用量>、<同時處於尖峰的 DB 數目 × 每個 DB 尖峰 DTP 使用量>)
   • 針對以虛擬核心為基礎的購買模型：
     • MAX(<DB 總數 × 每個 DB 平均虛擬核心使用量>、<同時處於尖峰的 DB 數目 × 每個 DB 尖峰虛擬核心使用量>)
2. 加總集區中所有資料庫所需的資料大小，以估計集區所需的總儲存空間。 針對 DTU 購買模型，決定提供此儲存空間量的 eDTU 集區大小。
3. 針對以 DTU 為基礎的購買模型，採用步驟 1 和步驟 2 中較大的 eDTU 估計值。 針對以虛擬核心為基礎的購買模型，採用步驟 1 中的虛擬核心估計值。
4. 請參閱 SQL Database 價格頁面並尋找大於步驟 3 估計值的最小集區大小。
5. 將步驟 4 的集區價格與單一資料庫中使用適當計算大小的價格相比較。

簡單來說不管 DTU 或是 vCore 都先考慮最高 DTU 或 vCore 數， DTU 則需要額外考慮所有資料庫的儲存空間加總，因為 DTU 儲存空間上限是隨著 DTU 而有所不同， vCore 因為儲存空間則沒有此限制，就不需要列入考慮。

DTU 定價模型

挑選 DTU 定價模型的定價層，基本上就是看資源使用量和儲存空間去判斷需要的 DTU 數，然後不同福無層級之間的差異，就用官方的表來比較，挑選上要另外注意的點就是在 DTU 定價模型下每一個 DTU 定價層有固定的儲存空間，以及可以加購的儲存空間也有上限，其他就是服務層級功能跟限制上的細微差別了。

vCore 定價模型

vCore 定價模型要考慮的因素跟定價層就複雜多了，首先計算資源就先分為：

• 無伺服器 (Serverless)
• 已佈建 (Provisioned)

無伺服器比較特別，它可以設定自動暫停時間，最低為一小時，也就是一小時內都沒有使用到運算資源，服務就會在暫停狀態，此時是不需要收費的，在設定上也可以設定一個 vCore 範圍，就會根據資料庫負載動態調整使用的 vCore ，最低是 0.5 vCore 最高是 80 vCore，而無伺服器也不支援彈性集區，資料庫從暫停狀態恢復到可使用狀態也會需要幾分鐘的時間，選擇無伺服器的情境，大概就是資料庫大部分時間是閒置的，可能一天固定一個時段才會需要用到資料庫，或是一個月跑一次資料時候才會用到，就很適合使用無伺服器，每個月固定費用就是儲存空間以及有使用到運算資源的費用。

官方中文翻譯有誤，底下最高跟最低 vCore 是相反的

而已佈建就是我們一般的使用，無中斷服務的運算資源，挑選上就是 vCore 個數和儲存體大小，其他就是服務層級上面的功能差異，挑選的細節就可以參考官方文件說明，官方有針對適合的情境說明，我就不一一貼過來了。

此外 vCore 按照 CPU 還有分為：

• 標準系列 (第 5 代)
  標準系列 (第 5 代) 邏輯 CPU 以 Intel E5-2673 v4 為基礎，(Broadwell) 2.3 GHz、Intel SP8160 (Skylake)、Intel Xeon Platinum 8272CL 2.5 GHz (Cascade Lake) 和 Intel(R) Xeon 可擴充 2.8 GHz 處理器 (Ice Lake) 處理器。在標準系列 (Gen 5) 中，1 個 vCore = 1 個超執行緒。標準系列 (第 5 代) 邏輯 CPU 對大多數關聯式資料庫伺服器而言非常適用。
• DC 系列
  DC 系列邏輯 CPU 搭載 Intel XEON E-2288G 處理器，並配備 Software Guard Extensions (Intel SGX) 技術。在 DC 系列中，1 個 vCore = 1 個實體核心。DC 系列支援具有安全記憶體的 Always Encrypted，而且專為處理敏感性資料並要求機密查詢處理功能的工作負載所設計。
• Fsv2 系列
  Fsv2 系列邏輯 CPU 採用 Intel Xeon® Platinum 8168 (SkyLake) 處理器。在 Fsv2 系列，1 個 vCore = 1 個超執行緒。Fsv2 系列最適用於每個 vCore 需要更高 CPU 效能的工作負載。
• M 系列
  M 系列的邏輯 CPU 採用 Intel Xeon® E7-8890 v3 2.5 GHz (Haswell) 與 Intel Xeon Platinum 8280M 2.7 GHz (Cascade Lake) 處理器。在 M 系列，1 個 vCore = 1 個超執行緒。M 系列已針對記憶體密集型工作負載進行最佳化。
• 進階系列
  進階系列邏輯 CPU 是以最新的 Intel(R) Xeon 為基礎 (Ice Lake) 和 AMD EPYCTM 7763v (Milan) 晶片組為基礎，1 個 vCore = 1 個超執行緒。進階系列邏輯 CPU 非常適合資料庫工作負載，這些工作負載需要更快的計算和記憶體效能，以及標準系列硬體供應專案的改進 IO 和網路體驗。
• 進階系列，記憶體最佳化
  進階系列記憶體最佳化邏輯 CPU 是以最新的 Intel(R) Xeon (Ice Lake) 和 AMD EPYCTM 7763v (Milan) 晶片組為基礎，1 個 vCore = 1 個超執行緒。此記憶體最佳化版本提供每個 vCore 幾乎兩倍的記憶體，適合需要比標準系列更好之記憶體效能的資料庫工作負載。

而不同服務層級可以選擇的系列略有不同，整理成下表：

	一般用途 (General purpose)	業務關鍵 (Business critical)	超大規模資料庫 (Hyperscale)
標準系列 (第 5 代)	有	有	有
DC 系列	有	有	無
Fsv2 系列	有	無	無
M 系列	無	有	無
進階系列	無	無	有
進階系列，記憶體最佳化	無	無	有

目前僅有標準系列才可以購買保留 (RI)，未來要節省成本需要購買保留的時候就要注意這一點。

從 DTU 轉移到 vCore

在一開始需要的資源比較少的時候或是還不確定使用資源情境下可以先選擇 DTU，但是隨著資料庫越來越大，所需的資源也越來越大，就會建議可以評估是否轉換到 vCore，未來也才可以配合買 RI 或是 Azure Hybrid Benefit 來節省成本，而在轉移 DTU 到 vCore 的時候，官方也有提供一段 T-SQL 語法可以在要執行轉移的資料庫去執行，就會回傳參考的 vCore 和記憶體等數據，方便我們對應和挑選合適的 vCore 定價層，更多說明跟挑選範例可以參考官方文件說明。

WITH dtu_vcore_map AS
(
SELECT rg.slo_name,
       CAST(DATABASEPROPERTYEX(DB_NAME(), 'Edition') AS nvarchar(40)) COLLATE DATABASE_DEFAULT AS dtu_service_tier,
       CASE WHEN slo.slo_name LIKE '%SQLG4%' THEN 'Gen4'
            WHEN slo.slo_name LIKE '%SQLGZ%' THEN 'Gen4'
            WHEN slo.slo_name LIKE '%SQLG5%' THEN 'standard_series'
            WHEN slo.slo_name LIKE '%SQLG6%' THEN 'standard_series'
            WHEN slo.slo_name LIKE '%SQLG7%' THEN 'standard_series'
            WHEN slo.slo_name LIKE '%GPGEN8%' THEN 'standard_series'
       END COLLATE DATABASE_DEFAULT AS dtu_hardware_gen,
       s.scheduler_count * CAST(rg.instance_cap_cpu/100. AS decimal(3,2)) AS dtu_logical_cpus,
       CAST((jo.process_memory_limit_mb / s.scheduler_count) / 1024. AS decimal(4,2)) AS dtu_memory_per_core_gb
FROM sys.dm_user_db_resource_governance AS rg
CROSS JOIN (SELECT COUNT(1) AS scheduler_count FROM sys.dm_os_schedulers WHERE status COLLATE DATABASE_DEFAULT = 'VISIBLE ONLINE') AS s
CROSS JOIN sys.dm_os_job_object AS jo
CROSS APPLY (
            SELECT UPPER(rg.slo_name) COLLATE DATABASE_DEFAULT AS slo_name
            ) slo
WHERE rg.dtu_limit > 0
      AND
      DB_NAME() COLLATE DATABASE_DEFAULT <> 'master'
      AND
      rg.database_id = DB_ID()
)
SELECT dtu_logical_cpus,
       dtu_memory_per_core_gb,
       dtu_service_tier,
       CASE WHEN dtu_service_tier = 'Basic' THEN 'General Purpose'
            WHEN dtu_service_tier = 'Standard' THEN 'General Purpose or Hyperscale'
            WHEN dtu_service_tier = 'Premium' THEN 'Business Critical or Hyperscale'
       END AS vcore_service_tier,
       CASE WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus
            WHEN dtu_hardware_gen = 'standard_series' THEN dtu_logical_cpus * 0.7
       END AS Gen4_vcores,
       7 AS Gen4_memory_per_core_gb,
       CASE WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus * 1.7
            WHEN dtu_hardware_gen = 'standard_series' THEN dtu_logical_cpus
       END AS standard_series_vcores,
       5.05 AS standard_series_memory_per_core_gb,
       CASE WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus
            WHEN dtu_hardware_gen = 'standard_series' THEN dtu_logical_cpus * 0.8
       END AS Fsv2_vcores,
       1.89 AS Fsv2_memory_per_core_gb,
       CASE WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus * 1.4
            WHEN dtu_hardware_gen = 'standard_series' THEN dtu_logical_cpus * 0.9
       END AS M_vcores,
       29.4 AS M_memory_per_core_gb
FROM dtu_vcore_map;

以彈性集區標準 200 eDTU 執行的結果會如下：

就可以得到建議的 vCore 服務層級是一般用途或超大規模，標準(第五代) vCore (顯示是 4 代，但是現在新建立的都會是 5 代) 約需 4.2 vCore 和記憶體 7GB，就可以去找接近的定價層，就可以找出合適的 vCore 該用那一個定價層了。

結論

整個整理下來會發現 SQL Database 在挑選定價層上有非常多要考慮的因素，我也僅針對比較大方向來整理出來，還有很多細節的考量，不可能一一的說明，但是大家可以從參考資料去看更詳細的細節，不過基本上的使用從這些大方向去挑選定價層已經很足夠了，其他考量的細節除非用到比較進階的資料庫功能，可能僅有在特定服務層級才有提供，不然是可以暫時先不針對細節去評估。

最後總結一下挑選的步驟和評估點：

1. 選擇 DTU 或是 vCore 定價模型：還不確定使用的資源或是資源用量較小可以先選擇 DTU，有 SQL Server SA 授權可以帶上雲端可以優先考慮 vCore。
2. vCore 定價模型選擇無伺服器或已佈建：如果資料庫並不需要 24 小時運作可以選擇無伺服器。
3. 彈性集區：資料庫大於 1 個以上且有數據可以判斷哪些時段資源使用較大的時候可以考慮是否使用彈性集區。
4. 購買保留：業務上資源使用已穩定，可以考慮購買一年或三年保留來節省費用。

參考資料

• 功能比較：Azure SQL Database 和 Azure SQL 受控執行個體
• Azure SQL Database 與 SQL Server 差異
• Azure SQL 受控執行個體與 SQL Server 差異
• Azure SQL Database 彈性查詢
• 使用 Data Migration Assistant 來執行 SQL Server 移轉評估
• 比較 Azure SQL Database 以虛擬核心為基礎的購買模型和以 DTU 為基礎的購買模型
• 將 Azure SQL Database 從以 DTU 為基礎的模型移轉到以虛擬核心為基礎的模型
• 彈性集區可協助您管理及調整 Azure SQL Database 中的多個資料庫
• 以 DTU 為基礎的購買模型概觀
• 虛擬核心購買模型