適用於:Azure SQL 資料庫
本文說明 Azure SQL Database 無伺服器運算層的自動暫停與自動恢復行為,以及它如何與 Azure SQL Database 的各種功能互動。
目前,通用服務層是唯一支援無伺服器自動暫停與自動繼續的服務層級。
要監控無伺服器資料庫狀態,請參閱 監控暫停與恢復狀態。
自動暫停
當自動暫停延遲期間符合以下所有條件時,自動暫停開始:
- 工作階段數量 = 0
- CPU = 0 適用於在使用者資源集區中執行的使用者工作負載
預設情況下,會有一 小時的自動暫停延遲。
防止自動暫停的功能
如果你使用以下任何功能,請關閉自動暫停。 無論資料庫多久不活躍,資料庫都會保持在線。 以下功能防止自動暫停,但支援自動縮放:
以下功能情境也防止自動暫停:
- SQL 資料同步 中使用的同步資料庫。與同步資料庫不同,樞紐與會員資料庫支援自動暫停。
- 在 彈性工作中,啟用自動暫停的無伺服器資料庫不被支援作為 工作資料庫。 彈性作業指定的無伺服器資料庫確實支援自動暫停。 工作連接將恢復資料庫。
- 在部署某些需要資料庫保持在線狀態的服務更新時,會暫時防止自動暫停功能。 在這種情況下,當服務更新完成後,就會再次允許自動暫停。
自動繼續
當以下任一條件成立時,自動恢復會開始:
| Feature | 自動繼續觸發 |
|---|---|
| 身份驗證與授權 | 登入嘗試 |
| 威脅偵測 | 在資料庫或伺服器層級啟用或停用威脅偵測設定。 修改資料庫或伺服器層級的威脅偵測設定。 |
| 資料探索與分類 | 新增、修改、刪除或檢視敏感度標籤 |
| 稽核 | 檢視稽核記錄。 更新或檢視稽核原則。 |
| 資料遮罩 | 新增、修改、刪除或檢視資料遮罩處理規則 |
| 透明資料加密 | 檢視透明資料加密的狀態 |
| 弱點評估 | 手動起始的掃描和定期掃描(如果啟用) |
| 查詢 (效能) 資料存放區 | 修改或檢視 查詢存放區 設定 |
| 效能建議 | 檢視或套用效能建議 |
| 自動微調 | 自動調校建議(例如自動建立索引)的套用與驗證 |
| 資料庫複製 | 以複製的方式建立資料庫。 匯出至 BACPAC 檔案。 |
| SQL 資料同步 | 根據可設定的排程執行或手動執行中樞與成員資料庫之間的同步化作業 |
| 修改特定資料庫中繼資料 | 在資料庫上新增或修改 Azure 標籤。 變更最大虛擬核心數、最小虛擬核心數或自動暫停延遲。 |
| SQL Server Management Studio (SSMS) | 在 18.1 之前的 SSMS 版本中,若為伺服器上任一資料庫開啟新查詢視窗,則同一伺服器中任何自動暫停的資料庫都會被恢復。 如果你使用 SSMS 18.1 或更新版本,則不會發生這種行為。 |
執行上述操作的監控、管理或其他解決方案會觸發自動恢復。 自動恢復也會在某些需要資料庫在線的服務更新部署期間開始。
自動恢復觸發識別
Azure 監視器 活動記錄會在 Started 和 Succeeded 事件之 JSON 中的 Caller 屬性下,顯示 Resume Databases 作業的自動繼續觸發程序。 欲了解更多資訊,請參閱 「監控無伺服器運算層」。
Latency
延遲通常約為一分鐘自動恢復,自動暫停則約一到十分鐘。 任一操作的延遲最低可達一秒左右。
由客戶管理的透明資料加密
金鑰刪除或撤銷
如果您使用 客戶受控透明資料加密(自備金鑰或 BYOK),且在發生金鑰刪除或撤銷時,無伺服器資料庫處於自動暫停狀態,則資料庫將維持在自動暫停狀態。 在這種情況下,資料庫在重啟後大約 10 分鐘內會變得無法存取。 一旦資料庫變成無法存取,復原程序就與已佈建的計算資料庫相同。 若無伺服器資料庫在金鑰刪除或撤銷時仍在線上,資料庫也會在約 10 分鐘內無法存取,類似配置計算資料庫的情況。
金鑰輪替
如果你使用 客戶管理金鑰的透明資料加密(BYOK)並啟用無伺服器自動暫停,則每當輪替金鑰時,資料庫都會自動重新啟動。 當自動暫停條件達成時,資料庫會自動暫停。
自動暫停疑難排解
自動重新連線的疑難排解
如果無伺服器的資料庫已暫停,則第一個連線嘗試會繼續執行資料庫並傳回錯誤 (錯誤碼 40613),指出該資料庫無法使用。 資料庫恢復後,重新嘗試連線。 資料庫通常在不到一分鐘內恢復。
所有雲端連接的應用程式都應該使用 連線重試邏輯的建議。 應用程式需要重試邏輯才能在短暫連線錯誤後成功。 重試邏輯對於無伺服器資料庫尤其重要,因為自動恢復導致的暫時連線錯誤是可預測的。
有關連線重試邏輯選項和建議的資訊,請參閱:
- SqlClient 中的連線重試邏輯
- SQL Database 中使用 Entity Framework Core 的連線重試邏輯
- SQL 資料庫使用 Entity Framework 6 的重試邏輯
- SQL Database 中使用 ADO.NET 的連接重試邏輯
- JDBC 中的連線韌性
- PHP 中的連線韌性
- ODBC 中的連線韌性
自動暫停故障排除
如果你啟用自動暫停且沒有使用阻擋自動暫停的功能,但資料庫在延遲期後不會自動暫停,可能是應用程式或使用者工作階段阻止了自動暫停。
要查看目前是否有任何應用程式或使用者會話連接到資料庫,請執行以下查詢:
SELECT session_id,
host_name,
program_name,
client_interface_name,
login_name,
status,
login_time,
last_request_start_time,
last_request_end_time
FROM sys.dm_exec_sessions AS s
INNER JOIN sys.dm_resource_governor_workload_groups AS wg
ON s.group_id = wg.group_id
WHERE s.session_id <> @@SPID
AND
(
(
wg.name like 'UserPrimaryGroup.DB%'
AND
TRY_CAST(RIGHT(wg.name, LEN(wg.name) - LEN('UserPrimaryGroup.DB') - 2) AS int) = DB_ID()
)
OR
wg.name = 'DACGroup'
);
Tip
執行查詢之後,請務必中斷與資料庫的連線。 否則,查詢使用的開啟會話將阻止自動暫停。
- 如果結果集不是空的,表示會話目前無法自動暫停。
- 如果結果集為空,仍有可能在先前的自動暫停延遲期間某個時點曾有工作階段開啟,而且可能只持續了短暫時間。 要檢查延遲期間的活動,請使用 Auditing for Azure SQL Database 和 Azure Synapse Analytics,並檢視相關期間的稽核資料。
Important
無伺服器資料庫不能如預期自動暫停的最常見原因,是存在已開啟的會話,不論使用者資源集區中是否同時使用 CPU。