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

維護排程功能可將服務健康狀態計劃性維護通知、資源健康狀態檢查監視器和維護排程服務整合至 Azure Synapse Analytics 內的 Synapse SQL 集區 (資料倉儲)。

您應該使用維護排程來選擇時段，方便您接收新功能、升級與修補程式。 您需要選擇七天期間內的主要和次要維護時段，每個時段都必須在不同的日期範圍內。

例如，您可以將星期六 22:00 的主時段排程為星期日 01:00，然後將星期三 19:00 的次要時段排程為 22:00。 如果維護無法在主要維護時段執行，將在次要維護時段再次試著進行維護。 有時可能會在主要和次要時段進行服務維護。 為了確保能快速完成所有維護作業，DW400c 和較低的資料倉儲層級可在指定的維護時段以外完成維護。

所有新建立的資料倉儲執行個體在部署期間都會套用一個系統定義的維護排程。 一旦部署完畢，就可以編輯排程。

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

除非我們需要部署有時效性的更新，否則所有維護作業都應該在指定的維護時段內完成。 如果您的資料倉儲已在排程維護期間暫停，它將會在繼續作業期間更新。 您將在資料倉儲維護完成之後，立即收到通知。

注意

• 維護期間不適用於 DW400c 或較低的效能層級。 它們可以隨時進行維護。
• DW400c 和較低層級可能會在維護時段的不同時間遇到多個短暫的連線中斷。

警示和監視

Azure 提供有關雲端資源健康情況的全面見解，包括目前和即將出現的問題、服務影響事件、計劃性維護以及可能影響可用性的其他變更。

服務健康情況提供您使用的 Azure 服務和區域的個人化檢視，使其成為服務影響通訊的最佳來源，例如中斷、計劃性維護和其他健康情況公告。 藉由設定服務健康情況警示，您可以透過喜好的通訊通道，接收任何影響服務的問題或變更的相關通知。

若要設定計劃性維護的服務健康情況警示，請瀏覽 Azure 入口網站並存取服務健康情況區段。 選取警示索引標籤，並根據集區類型，將服務類型指定為 Azure Synapse Analytics 或 (及) SQL 資料倉儲，以建立新的警示。 選擇維護做為事件類型，根據您的喜好設定來定義範圍和通知設定，並儲存警示組態。 如需詳細的指令，請參閱下列資源：

• 服務健康情況警示。
• 如何建立服務健康情況警示。

備註：在設定過程中，您需要設定條件詳細資料以符合您使用的服務。

• 針對專用 SQL 集區 (先前稱為 SQL DW)，服務選項應當為 SQL 資料倉儲
  • 針對 Azure Synapse Analytics 工作區中的專用 SQL 集區，服務選項應當為 Azure Synapse Analytics

注意

所有維護事件都會提前 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 轉換，然後調整回低於或等於 DW400c 的 SLO (反之亦然)，則可能發生取消。 這是因為維護期間不適用於 DW400c 或較低的效能等級，而且可以隨時進行維護。
• 內部基礎結構因素，例如發行小組對計劃性維護排程的實際變更。
• 如果內部監視偵測到維護所花的時間超過預期，則可能取消或重新安排維護。 維護必須在客戶維護時段設定所定義的服務等級協定 (SLA) 內完成。

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

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

下一步

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