使用維護排程管理服務更新和維護

維護排程功能會整合 Azure Synapse Analytics 內 Synapse SQL 集區（數據倉儲）的服務健全狀況計劃性維護通知、資源健康狀態 檢查監視器和維護排程服務。

您應該使用維護排程來選擇一個時間範圍，以便接收新功能、升級和修補程式。 您必須在七天內選擇主要和次要維護期間，每個視窗都必須位於個別的日期範圍內。

例如，您可以排程星期六 22：00 到星期日 01：00 的主要視窗，然後排程星期三 19：00 到 22：00 的次要視窗。 如果無法在主要維護期間執行維護，它會在次要維護期間再次嘗試維護。 服務維護可能會在主要和次要時段期間發生。 為了確保所有維護作業的快速完成，DW400c 和較低的數據倉儲層可以在指定的維護期間之外完成維護。

所有新建立的數據倉儲實例都會在部署期間套用系統定義的維護排程。 只要部署完成，就可以編輯排程。

選擇維護期間時，您必須選取開始時間並設定最大持續時間。 「維護期間的最大持續時間」決定將執行維護工作的時間範圍。此時間範圍可以介於三（3）到八（8）小時之間，最低需求為三（3）小時。 在此期間，您的數據倉儲將會暫時離線，因為您的專用集區會使用類似於暫停/繼續的程式移至升級的容量。 在一般情況下，這項作業會在 30 分鐘內完成，但請務必注意，在某些情況下，可能需要較長的時間。 例如，如果在維護開始時有作用中的交易，它們將會取消並回復，這可能會導致還原在線服務的延遲。 為了避免這種情況發生，建議您務必確定在排定的維護時段開始時沒有任何使用中的長時間執行交易。

除非我們需要部署時間敏感性更新，否則所有維護作業都應該在指定的維護期間內完成。 如果您的數據倉儲在排程維護期間暫停，則會在繼續作業期間更新。 數據倉儲維護完成之後，系統會立即通知您。

注意

• 維護期間不適用於 DW400c 或較低的效能等級。 他們可以隨時進行維護。
• DW400c 和更低版本可能會在維護期間期間於各種時間發生多次短暫的連線損失。

警示和監視

與服務健康情況通知和 資源健康狀態 檢查監視器整合，可讓客戶隨時掌握即將進行的維護活動。 此自動化會利用 Azure 監視器。 您可以決定要如何收到即將發生維護事件的通知。 此外，您可以選擇哪些自動化流程可協助您管理停機時間，並將作業影響降到最低。

注意

24 小時的提前通知會在所有維護事件之前。 如果我們需要部署時間關鍵更新，進階通知時間可能會大幅減少。 這可能會因為更新的危急性質而發生在已識別的維護時段之外。

如果您收到將進行維護的預先通知，但在通知規定的時間內無法執行維護，您將收到取消通知。 然後將會在下一個排定的維護期間繼續該維護。

所有作用中的維護事件都會顯示在 [服務健康狀態 - 計劃性維護] 區段中。 服務健康情況歷程記錄包含過去事件的完整記錄。 您可以在作用中事件期間，透過 Azure 服務健康情況檢查入口網站儀錶板監視維護。

維護排程可用性

即使所選取區域中無法使用維護排程，您隨時都可以檢視和編輯維護排程。 當您的區域中有可用的維護排程時，所識別的排程會立即在您的 Synapse SQL 集區上變成作用中。

檢視維護排程

根據預設，所有新建立的數據倉儲實例在部署期間都會套用八小時的主要和次要維護期間。 如上所述，您可以在部署完成後立即變更視窗。 不會在指定的維護期間外進行維護，而不需事先通知。

若要檢視已套用至 Synapse SQL 集區的維護排程，請完成下列步驟：

1. 登入 Azure 入口網站。
2. 選取您想要檢視的 Synapse SQL 集區。
3. 選取的 Synapse SQL 集區會在 [概觀] 刀鋒視窗上開啟。 套用至數據倉儲的維護排程會顯示在維護排程下方。

略過或變更維護排程

為了確保符合最新的安全性需求，我們無法因應要求略過或延遲這些更新。 不過，如果您使用目前週期內的 DW500c 和更高數據倉儲層，視情況而定，您可能會有一些選項可以調整維護期間：

• 如果您收到擱置的維護通知，而且需要更多時間才能完成作業或通知小組，只要是在定義的維護時段開始之前，就可以變更時間範圍開始時間。 這會在週期內將時間範圍向前轉移。

• 您可以在收到「擱置」通知的週期開始之後暫停和繼續 SQL 專用集區，以手動觸發維護。 週末維護週期從星期六上午 00：00 UTC 開始；週中維護週期從星期二上午 12：00 UTC 開始。

• 雖然我們至少需要 3 小時的時間範圍，但在一般情況下，這項作業會在 30 分鐘內完成。 不過，請務必注意，某些情況可能會需要更長的時間。 例如，如果在維護開始時有作用中的交易，它們將會取消並回復，這可能會導致還原在線服務的延遲。 為了避免這種情況發生，建議您務必確定在排定的維護時段開始時沒有任何使用中的長時間執行交易。

注意

• 如果將時段變更為現在時間之前的開始時間，便會立即觸發維護，但若在維護開始時有使用中的交易，將會中止並回復程序。
• 完成暫停和繼續作業以起始維護之後，您不會收到確認維護完成的通知，而是會收到已取消的通知。
• 如果您正在使用 DW400c 或更低版本，雖然您能夠變更維護排程，但不會遵守，因其為較低的效能等級。 如先前所述，這些資料倉儲層可以在維護週期內隨時進行維護。

識別主要和次要視窗

主要和次要窗口必須有個別的日期範圍。 例如星期二至星期四的主要視窗，以及星期六至星期日的次要視窗。 「主要」和「次要」一詞應分別視為「視窗 1」和「視窗 2」。 這表示可以依任何順序挑選任一個視窗來部署維護升級。

若要變更 Synapse SQL 集區的維護排程，請完成下列步驟：

1. 登入 Azure 入口網站。

2. 選取您要更新的 Synapse SQL 集區。 頁面會在 [概觀] 刀鋒視窗上開啟。 選取 [概觀] 刀鋒視窗上的 [維護排程摘要] 連結，以開啟維護排程設定的頁面。 或者，選取左側資源功能表上的 [ 維護排程] 選項。

   

3. 使用頁面頂端的選項，識別主要維護時段的慣用日期範圍。 此選取項目會決定您的主要視窗是否會在工作日或周末發生。 您的選取專案將會更新下拉式清單值。 在預覽期間，某些區域可能尚不支援一組完整的可用 日期 選項。

   

4. 使用下拉式清單框選擇您慣用的主要和次要維護時段：

   • 日期：在選取的時段內執行維護的慣用日期。
   • 開始時間：維護時段的慣用開始時間。
   • 時間範圍：您時間範圍慣用的持續時間。

   刀鋒視窗底部的 [ 排程摘要 ] 區域會根據您選取的值來更新。

5. 選取 [儲存]。 此時會出現一則訊息，確認您的新排程目前為使用中狀態。

   您可以隨時更新 [日期]、[開始時間]、[時間範圍][包括預設的 8 小時時段] 選取專案。 如果您要將排程儲存在不支援維護排程的區域，則會出現下列訊息。 當您選取的區域提供此功能時，您的設定會儲存並變成作用中。

   

常見問題集

維護的預期頻率為何。

維護可能會每月發生一次以上，因為維護可以包含OS更新、安全性修補程式和驅動程式、內部 Azure 基礎結構更新，以及 DW 修補程式和更新。 每個客戶在週六到星期六和星期四之間都有每周兩次的維護週期排程。

完成維護之後，即使我的專用 SQL 集區版本保持不變，仍然做了哪些變更？

維護更新完成之後，SQL 集區版本可能會保持不變。 這是因為維護可能包含 OS 更新、安全性修補程式和驅動程式、內部 Azure 基礎結構更新，以及 DW 修補程式和更新。 只有在維護中包含 Synapse DW 修補程式或更新時，您才會看到 SQL 專用集區版本的變更。

是否可視需要升級專用 SQL 集區的版本？

• 否，已排程的維護會處理專用 SQL 集區的管理。 不過，視您的情況而定，您可能有一些選項可在週期啟動時觸發維護。 確認 略過或變更維護排程
• 請務必記住，專用SQL集區是平臺即服務 （PaaS） 功能。 這表示 Microsoft Azure 會處理與服務相關的各種工作，例如基礎結構、維護、更新和可擴縮性。 您可以藉由設定警示/通知來追蹤排程維護，讓您隨時知道即將進行的維護活動。

在專用 SQL 集區維護完成之前或之後，應該進行哪些變更？

• 在維護期間，您的服務會短暫離線，類似於暫停、繼續或調整作業期間發生的情況。 一般而言，整體維護作業會在30分鐘內完成。 不過，視維護期間的資料庫活動而定，可能需要更長的時間。 我們建議暫停 ETL、數據表更新，特別是交易式作業，以避免比正常維護更長的時間。 例如：
• 如果您的實例在計劃期間非常忙碌，特別是經常更新和刪除活動，維護作業可能需要比正常時間更長的時間。 若要減少擴充維護活動的機會，建議您盡可能將活動限製為大部分是針對資料庫的唯讀查詢，特別是避免長時間執行的交易式查詢（請參閱下一個專案）。
• 如果維護開始時有作用中的交易，則會取消並回復它們，這可能會導致還原在線服務的延遲。 為了避免這種情況發生，建議您務必確定在排定的維護時段開始時沒有任何使用中的長時間執行交易。

我們收到有關即將推出的專用 SQL 集區排程維護的通知，追蹤 ID 為 0000-000，但隨後已取消或重新排程。 是什麼促使取消或重新排定維護時程？

有各種因素可能導致取消排程維護，包括下列動作：

• 在起始週期時收到擱置的維護通知之後暫停或調整作業。
• 如果您在維護週期期間以不同的服務等級目標 （SLO） 為目標，例如從高於 DW400c 的任何 SLO 轉換，然後調整回 SLO 較低或等於 DW400c，反之亦然，可能會發生取消。 這是因為維護期間不適用於 DW400c 或較低的效能等級，而且可以隨時進行維護。
• 內部基礎結構因素，例如發行小組對計劃性維護排程的實際變更。
• 如果內部監視偵測到維護所花費的時間超過預期，可能會取消或重新排程維護。 維護必須在客戶維護時段設定所定義的服務等級協定 (SLA) 內完成。

在維護期間，是否有需要針對工作負載考慮的最佳做法？

• 是，可能的話，請在計劃性維護間隔期間暫停所有交易式和 ETL 工作負載，以避免還原在線服務時發生錯誤或延遲。 在即將到來的維護期間之前，應該先完成長時間執行的交易作業。
• 若要讓工作負載能夠復原維護作業所造成的中斷，請使用聯機和命令 （query） 層級的重試邏輯，套用較長的重試間隔和/或更多重試嘗試，以承受在某些情況下可延長至或大於 30 分鐘的擴充連線遺失。

下一步

• 深入瞭解 如何使用 Azure 監視器建立、檢視和管理警示。
• 深入了解 記錄警示規則的 Webhook 動作。
• 深入瞭解 建立和管理動作群組。
• 深入了解 Azure 服務健康狀態。