DBA 這個角色，在現在的企業裡已經不是只管資料庫了。精簡人力之後，你可能同時要兼資料工程師、分析師，搞不好連 BI 都要你碰。DP-300 就是在這個背景下設計的——它不從零教你 SQL，而是假設你有基礎，直接教你怎麼在 Azure 上管理資料庫。

SQL Server 不只是一顆引擎

很多人對 SQL Server 的印象還停留在「資料庫」，但從 2008 版開始它就不是了。現在的 SQL Server 是一個完整的資料平台，裡面包了四大服務：

服務 縮寫 功能 雲端對應
Database Engine SSDE 核心資料庫引擎 Azure SQL
Integration Services SSIS ETL 資料整合 Azure Data Factory
Analysis Services SSAS 資料分析（BI） Power BI
Reporting Services SSRS 報表服務 Power BI

新版還內建了 Machine Learning Services，可以直接對資料庫的資料跑機器學習。版本一路從 7.0 → 2000 → 2005（引擎大改版）→ 2008（平台化轉型）一路到現在的 2025。

精通 SQL Server 有個好處：轉其他資料庫產品的門檻會低很多。底層概念是通的。

PaaS 先行，IaaS 是備案

部署 Azure 上的 SQL Server 有兩條路：

Azure SQL Database（PaaS）：完全託管，技術門檻低，Azure 幫你處理 patch、備份、HA 那些。考試預設答案。

Azure VM 上自己裝（IaaS）：可控性最高，但你也要自己管所有東西。只有當 PaaS 滿足不了需求的時候才考慮。

考試遇到「該選什麼部署方式」的題目，先選 PaaS。只有題目明確提到需要完全控制作業系統、或是用了 PaaS 不支援的功能，才轉 IaaS。

IaC 部署

雲端 DBA 一定要會 Infrastructure as Code。三種方式：

方式 類型 特點
ARM Template（JSON） 聲明式 面向結果，自動化程度高，但 JSON 手寫很痛苦
Bicep 聲明式（高階） 簡化版 ARM，寫起來舒服多了，可以自動轉 JSON
Azure CLI / PowerShell 命令式 面向過程，可控制細節，但結果不可預測

講師建議優先學 Bicep。ARM Template 的 JSON 寫到你會懷疑人生。

五種 Azure 儲存類型

類型 本地對應 AWS 對應 說明
Azure Files NAS EFS 檔案共享
Blob Storage 物件儲存 S3 非結構化資料
Managed Disk SAN EBS VM 磁碟（DB 推薦用這個）
Table Storage — DynamoDB NoSQL 鍵值
Queue Storage — SQS 訊息佇列

資料庫場景優先用 Managed Disk。它由平台保障性能，計費按磁碟大小算。非託管磁碟（Page Blob）正在被淘汰，不要選。

SQL Server 從 2012 起就支援把資料檔跟日誌檔放在 Page Blob 上，也可以直接把備份檔丟到 Blob Storage。但有個關鍵限制：VM 跟 Blob 必須在同一 Region，延遲要低於 5ms，不然效能會爛掉。

SSD 分配的優先順序

這是核心考題：如果預算只夠一塊 SSD，該給誰？

優先級 檔案類型 原因
🥇 第一 TempDB Join、排序等操作頻繁使用，對延遲極敏感
🥈 第二（讀多） Data File Index 查詢受益最大
🥈 第二（寫多） Log File 寫入密集場景明顯獲益
🥉 最後 System DB 效能需求最低

在 Azure 上有個省錢技巧：部分 VM SKU 會送免費的 Temporary Disk，吐量很高，可以拿來放 TempDB（前提是容量夠）。

還有一個講師特別強調的禁忌：絕對不要在資料庫場景用 SSD/HDD 混合儲存陣列。那是儲存廠商的行銷話術，不適合 Database workload。雲端部署沒這個問題，因為你直接選 SSD 或 HDD 就好。

高可用性：Availability Set vs Zone

選項 SLA 範圍 寫入效能 適用場景
單一 VM 99.9% 單個 VM 最佳 可接受短暫停機
Availability Set 99.95% 同一 AZ 內 高（低延遲） 寫入密集型 DB
Availability Zone 99.99% 跨 AZ 較差（跨 AZ 延遲） 要求最高可用性
Scale Set — — — ❌ 不適合 SQL Server

Scale Set 不適合資料庫的原因很直白：資料庫不支援自動水平擴展。你沒辦法像 Web Server 一樣「再開十台自動 load balance」，所有主流資料庫都是這樣。

講師推薦的做法是混合部署：3 個節點裡面，2 個放 Availability Set（保效能），1 個放 Availability Zone（拉高可用性）。

有個容易忽略的細節：用 SSD 的時候，磁碟寫入延遲極低，這時候網路延遲的佔比就會急劇上升。Availability Zone 的跨 AZ 網路延遲，在 SSD 環境下影響比你想的大。機械盤時代額外幾毫秒沒感覺，SSD 時代那幾毫秒就是效能瓶頸。

四種 Azure SQL Database 部署模型

Single Database（單一資料庫）

以資料庫為單位部署，每個 DB 資源完全隔離。容量上限 4 TB。可選通用、商務關鍵、超大規模三種效能層。注意一點：無法跨資料庫查詢，這跟 VM 上自己裝的 SQL Server 不同。

Elastic Pool（彈性集區）

池子的容量固定（DTU 或 vCore），裡面的 DB 動態共享資源。適合你有 10 個以上小型低負載 DB 的情況。每個 DB 可以設上下限，池子容量也能隨時調。但不適合高效能持續負載，DB 太少（< 10 個）的話也沒必要用。

Hyperscale（超大規模）

雲原生設計，存算分離架構。容量上限 100 TB，是唯一支援水平擴展的模型。備份幾乎即時、還原超快。

但有個大坑：升級到 Hyperscale 後有 90 天觀察期，超過後不可回退。這是單向遷移，考試很愛出。

Serverless（無伺服器）

閒置時自動暫停，暫停期間不計費。聽起來很香，但單價比常規模式高，而且很多需要 DB 持續運行的功能不支援。適合開發環境、測試環境、或是極少使用的資料庫。

備份與 RPO/RTO

Azure SQL Database 的備份是自動執行的，不需要你設計備份策略，保留期最長 35 天。

兩個必考指標：

指標 白話解釋 VM 部署 PaaS 部署
RPO 最壞情況下會丟多長時間的資料 約 5 分鐘 ≈ 0（近乎無損）
RTO 從故障到恢復服務的最長容許時間 看 HA 配置 看服務層級

PaaS 的 RPO 近乎零，這也是它被推薦為首選的原因之一。

第一天考點速記

  1. PaaS 優先於 IaaS
  2. SSD 優先分配：TempDB → Data/Log → System
  3. 不要用 Hybrid Storage 做 DB 儲存
  4. Availability Set（效能）vs Zone（可用性）的權衡
  5. Hyperscale 超過 90 天不可回退
  6. Serverless 不適合持續負載
  7. RPO：VM ≈ 5 min / PaaS ≈ 0
  8. Scale Set 不適合資料庫

附帶一個 Lab 省次數的技巧：實驗平台每個 Lab 可以啟動 10 次、每次 1 小時。在超時之前手動 Cancel 就不扣次數，超時被自動關才會扣。

來源：DP-300 Azure Database Administrator Associate 課程筆記（講師：高山 Martin）