維護時間範圍

適用于:Azure SQL資料庫 Azure SQL 受控執行個體

維護時段功能可讓您設定 Azure SQL DatabaseAzure SQL 受控執行個體 資源的維護排程,讓具影響力的維護事件可預測,並且對您的工作負載減少干擾。

注意

維護時段功能只會防止來自升級或排程維護的規劃影響。 無法防止所有容錯移轉原因;在維護時段之外可能造成短暫連線中斷的例外狀況,包括硬體故障、叢集負載平衡,以及由於資料庫服務等級目標變更之類的事件而導致資料庫重新設定。

事先通知 (預覽) 適用於設定為使用非預設維護時間範圍的資料庫。 事先通知可讓客戶將通知設定為在任何計劃性事件前最多 24 小時傳送。

概觀

Azure 會定期執行 SQL Database 和 SQL 受控執行個體資源的計劃性維護。 在 Azure SQL 維護事件期間,資料庫完全可用,但是會受限於 SQL DatabaseSQL 受控執行個體各自可用性 SLA 內短暫的重新設定。

維護時段適用於不具資料庫或執行個體重新設定復原能力的生產工作負載,而且無法吸收由計劃性維護事件所造成的短暫連線中斷。 藉由選擇您偏好的維護時段,您可以將計劃性維護的影響降到最低,因為這會在您的尖峰上班時間以外發生。 復原工作負載和非生產工作負載可能會依賴 Azure SQL 的預設維護原則。

維護時段是免費的,而且可以在建立時或針對現有的 Azure SQL 資源進行設定。 您可以使用 Azure 入口網站、PowerShell、CLI 或 Azure API 來設定。

重要

設定維護時段是一項長時間執行的非同步作業,類似於變更 Azure SQL 資源的服務層級。 資源可在作業期間使用,但在作業結束時所發生的短暫重新設定除外,即使在中斷長時間執行的交易時,通常也會持續最多 8 秒的時間。 若要將重新設定的影響降到最低,您應該在尖峰時間以外的時間執行作業。

使用維護時段獲得更多可預測性

根據預設,Azure SQL 維護原則會在當地每天上午 8 點到下午 5 點期間封鎖大部分具影響力的更新,以避免在一般尖峰上班時間期間發生任何中斷。 本地時間取決於裝載資源的 Azure 區域位置,而且可能會根據當地時區定義來觀察日光節約時間。

您可以從兩個額外的維護時段位置選擇,以進一步將維護更新調整為適用於 Azure SQL 資源的時間:

  • 工作日時段:當地時間下午 10:00 到上午 6:00,週一 - 週四
  • 週末時段:當地時間下午 10:00 到上午 6:00,週五 - 週日

列出的維護時段天數表示每八小時維護時段的開始日期。 例如,「當地時間下午 10:00 到上午 6:00,週一 - 週四」表示維護時段從當地時間每天 (週一到週四) 下午 10:00 開始,並且在當地時間隔日 (週二到週五) 上午 6:00 完成。

一旦進行維護時段選取並完成服務設定,就只會在您選擇的時段期間進行計劃性維護。 雖然維護事件通常會在單一時段中完成,但其中有些可能會跨越兩個以上的相鄰時段。

重要

在非常罕見的情況下,任何延後的動作可能會造成嚴重的影響,例如套用重大安全性修補程式,可能會暫時覆寫已設定的維護時段。

進階通知

您可以設定維護通知,以警示您 Azure SQL Database 和 Azure SQL 受控執行個體即將推出的計劃性維護事件。 警示會提前 24 小時、在維護時間內,且在維護完成的時間到達。 如需詳細資訊,請參閱預先通知

功能可用性

支援的訂用帳戶類型

設定和使用維護時段適用於下列供應項目類型:隨用隨付、雲端解決方案提供者 (CSP)、Microsoft Enterprise 合約或 Microsoft 客戶合約。

僅限開發/測試使用的供應項目不符合 (例如隨用隨付開發/測試或 Enterprise 開發/測試)。

注意

Azure 供應項目是您擁有之 Azure 訂用帳戶的「類型」。 例如,採用隨用隨付費率的訂用帳戶Azure in OpenVisual Studio Enterprise 皆為 Azure 供應項目。 每個供應項目或方案各有不同的條款和權益。 您的供應項目或方案會顯示在訂用帳戶的概觀上。 如需將您的訂用帳戶切換至不同供應項目的詳細資訊,請參閱將 Azure 訂用帳戶變更為其他供應項目

支援的服務等級目標

選擇預設值以外的維護時段可以在所有 SLO 上使用,以下項目除外

  • 執行個體集區
  • 舊版第 4 代虛擬核心
  • 基本、S0 和 S1
  • DC、Fsv2、M 系列

Azure 區域支援

選擇預設值以外的維護時段目前可在下列區域使用:

Azure 區域 SQL 受控執行個體 SQL Database Azure 可用性區域中的 SQL Database
澳大利亞中部 1 Yes
澳大利亞中部 2 Yes
澳大利亞東部 Yes
澳大利亞東南部
巴西南部
巴西東南部 Yes
加拿大中部 Yes
加拿大東部
印度中部
美國中部
中國東部 2
中國北部 2
美國東部
美國東部 2 Yes
東亞
法國中部
法國南部
德國中西部
德國北部
日本東部
日本西部
南韓中部
南韓南部 Yes
美國中北部
北歐
挪威東部 Yes
挪威西部 Yes
南非北部
南非西部
美國中南部
印度南部
東南亞
瑞士北部
瑞士西部 Yes
阿拉伯聯合大公國中部 Yes
阿拉伯聯合大公國北部
英國南部
英國西部
US Gov 亞利桑那州 Yes
US Gov 德克薩斯州 Yes
US Gov 維吉尼亞州
美國中西部
西歐 Yes
印度西部 Yes
美國西部
美國西部 2 Yes
美國西部 3

閘道維護

若要從維護時段中獲得最大效益,請確定您的用戶端應用程式是使用重新導向連線原則。 重新導向是建議的連線原則,用戶端直接與裝載資料庫的節點建立連線,導致延遲降低和輸送量提高。

  • 在 Azure SQL Database 中,使用 Proxy 連線原則的任何連線,都可能會受到所選維護時段和閘道節點維護時段的影響。 不過,使用建議重新導向連線原則的用戶端連線不會受到閘道節點維護重新設定的影響。

  • 在 Azure SQL 受控執行個體中,閘道節點會裝載於虛擬叢集中,並具有與受控執行個體相同的維護時段,但仍建議使用重新導向連線原則,將維護事件期間的中斷次數降至最低。

如需 Azure SQL Database 中用戶端連線原則的詳細資訊,請參閱 Azure SQL Database 連線原則

如需 Azure SQL 受控執行個體中用戶端連線原則的詳細資訊,請參閱 Azure SQL 受控執行個體連線原則

Azure SQL 受控執行個體的考量

Azure SQL 受控執行個體包含服務元件,裝載在專用的隔離虛擬機器集合上,這些虛擬機器會在客戶的虛擬網路子網路內執行。 這些虛擬機器會形成虛擬叢集,可以裝載多個受控執行個體。 在一個子網路的執行個體上所設定的維護時段,可能會影響子網路內的虛擬叢集數目、虛擬叢集之間的執行個體分佈,以及虛擬叢集管理作業。 這可能需要考慮一些效果。

維護時段設定是一項長時間執行的作業

虛擬叢集中裝載的所有執行個體會共用維護時段。 根據預設,所有受控執行個體都裝載於具有預設維護時段的虛擬叢集中。 在建立或之後指定受控執行個體的其他維護時段,表示必須將其放在具對應維護時段的虛擬叢集中。 如果子網路中沒有此類的虛擬叢集,必須先建立新的叢集以容納該執行個體。 在現有的虛擬叢集中容納額外的執行個體可能需要調整叢集大小。 這兩項作業都會對設定受控執行個體維護時段的持續時間造成影響。 在受控執行個體上設定維護時段的預期持續時間,可以使用執行個體管理作業的預估持續時間來計算。

重要

在設定維護時段作業結束時,會進行短暫的重新設定,即使在中斷長時間執行的交易時,通常仍會持續最多 8 秒鐘。 若要將重新設定的影響降到最低,請在尖峰時間以外起始作業。

IP 位址空間需求

子網路中每個新虛擬叢集都需要根據虛擬叢集 IP 位址配置的其他 IP 位址。 變更現有受控執行個體的維護時段也需要暫時額外 IP 容量,就像針對對應服務層級調整虛擬核心案例一樣。

IP 位址變更

在子網路的 IP 位址範圍內,設定和變更維護時段會導致執行個體的 IP 位址變更。

重要

請確定 NSG 和防火牆規則不會在 IP 位址變更之後封鎖資料流量。

虛擬叢集管理作業的序列化

影響虛擬叢集的作業,例如服務升級和虛擬叢集調整大小 (新增節點或移除不必要的計算節點) 會進行序列化。 換句話說,在先前虛擬叢集管理作業完成之前,新的虛擬叢集管理作業無法啟動。 如果維護時段在進行中的服務升級或維護作業完成之前關閉,在該期間內提交的任何其他虛擬叢集管理作業都會暫停,直到下一個維護時段開啟,且服務升級或維護作業完成為止。 維護作業所花費的時間超過每個虛擬叢集單一時段的情形並不常見,但是如果維護作業非常複雜,還是有可能會發生。

虛擬叢集管理作業的序列化是一般行為,也適用於預設維護原則。 在已設定維護時段排程的情況下,兩個相鄰時段之間的期間可能是數天。 如果維護作業跨越兩個時段,提交的作業也會暫停數天。 這種情況很罕見,但是建立新執行個體或調整現有執行個體大小 (如果需要額外的計算節點) 可能會在這段期間遭到封鎖。

擷取維護事件清單

Azure Resource Graph 是一項 Azure 服務,其旨在延伸 Azure 資源管理。 Azure Resource Graph Explorer 會透過大規模查詢一組指定訂用帳戶的能力,提供有效率且高效能的資源探索,讓您可以有效地治理環境。

您可以使用 Azure Resource Graph Explorer 來查詢維護事件。 如需如何執行這些查詢的簡介,請參閱快速入門:使用 Azure Resource Graph Explorer 執行您的第一個 Resource Graph 查詢

若要檢查訂閱中所有 SQL 資料庫的維護事件,請在 Azure Resource Graph Explorer 中使用下列範例查詢:

servicehealthresources
| where type =~ 'Microsoft.ResourceHealth/events'
| extend impact = properties.Impact
| extend impactedService = parse_json(impact[0]).ImpactedService
| where  impactedService =~ 'SQL Database'
| extend eventType = properties.EventType, status = properties.Status, description = properties.Title, trackingId = properties.TrackingId, summary = properties.Summary, priority = properties.Priority, impactStartTime = todatetime(tolong(properties.ImpactStartTime)), impactMitigationTime = todatetime(tolong(properties.ImpactMitigationTime))
| where eventType == 'PlannedMaintenance'
| order by impactStartTime desc

若要檢查訂閱中所有 SQL 資料庫的維護事件,請在 Azure Resource Graph Explorer 中使用下列範例查詢:

servicehealthresources
| where type =~ 'Microsoft.ResourceHealth/events'
| extend impact = properties.Impact
| extend impactedService = parse_json(impact[0]).ImpactedService
| where  impactedService =~ 'SQL Managed Instance'
| extend eventType = properties.EventType, status = properties.Status, description = properties.Title, trackingId = properties.TrackingId, summary = properties.Summary, priority = properties.Priority, impactStartTime = todatetime(tolong(properties.ImpactStartTime)), impactMitigationTime = todatetime(tolong(properties.ImpactMitigationTime))
| where eventType == 'PlannedMaintenance'
| order by impactStartTime desc

如需範例查詢的完整參考,以及如何跨 PowerShell 或 Azure CLI 等工具加以使用,請瀏覽 Azure Resource Graph 的 Azure 服務健康情況範例查詢

後續步驟

深入了解