メンテナンス スケジュールを使用してサービスの更新とメンテナンスを管理する
このメンテナンス スケジュール機能は、Service Health 計画メンテナンス通知、リソース ヘルス チェック モニター、Azure Synapse Analytics 内の Synapse SQL プール (データ ウェアハウス) のメンテナンス スケジューリング サービスを統合します。
メンテナンス スケジューリングは、新機能、アップグレード、および修正プログラムを受信するのに都合のよい時間枠を選択するために使用してください。 プライマリおよびセカンダリ メンテナンス ウィンドウを 7 日の期間内で選択する必要があり、各ウィンドウは別の曜日範囲内にある必要があります。
たとえば、土曜日の 22:00 から日曜日の 01:00 をプライマリ ウィンドウとしてスケジュールし、水曜日の 19:00 から 22:00 をセカンダリ ウィンドウとしてスケジュールできます。 プライマリ メンテナンス期間でメンテナンスを実行できなかった場合、セカンダリ メンテナンス期間で再度メンテナンスを試みます。 サービス メンテナンスは、プライマリ ウィンドウとセカンダリ ウィンドウの両方で発生する場合があります。 すべてのメンテナンス操作の迅速な完了を保証するために、DW400c 以下のデータ ウェアハウス層は指定されたメンテナンス ウィンドウ外にメンテナンスを完了する可能性があります。
新しく作成されたすべてのデータ ウェアハウス インスタンスには、デプロイ時にシステム定義のメンテナンス スケジュールが適用されます。 デプロイが完了するとすぐに、スケジュールを編集できます。
メンテナンス期間を決める場合は、開始時刻を選び、最長期間を設定する必要があります。 "メンテナンス期間の最長期間" によって、メンテナンス タスクを実行する時間枠が決まります。この時間枠は 3 時間から 8 時間で、最小要件としては 3 時間です。 この期間中は、専用のプールが一時停止/再開と同様のプロセスを使用してアップグレードされた容量に移動されるため、データ ウェアハウスは一時的にオフラインになります。 一般的な条件下ではこの操作は 30 分以内に完了しますが、それより長い時間がかかる場合もあることに注意することが重要です。 たとえば、メンテナンス開始時にアクティブなトランザクションがある場合、トランザクションは取り消されてロールバックされ、オンライン サービスの復元に遅延が発生する恐れがあります。 この状況を回避するには、メンテナンス期間の開始時に実行時間の長いトランザクションがアクティブにならないように注意することをお勧めします。
時間の制約がある更新プログラムをデプロイする必要がない限り、すべてのメンテナンス操作は指定されたメンテナンス ウィンドウ内に完了するはずです。 スケジュールされたメンテナンス中にデータ ウェアハウスが一時停止されると、再開操作中に更新されます。 データ ウェアハウスの保守が完了すると、すぐに通知が届きます。
Note
- メンテナンス期間は DW400c 以下のパフォーマンス レベルには適用されません。 いつでもメンテナンスを受けることができます。
- DW400c 以下では、メンテナンス ウィンドウ内のさまざまな時点で接続が複数回にわたり短期間失われることがあります。
アラートと監視
Azure から提供される情報には、サービスに影響するイベント、計画メンテナンス、可用性に影響する可能性のあるその他の変更など、現在および今後の問題を含むクラウド リソースの正常性に関する包括的な分析情報があります。
Service Health では、使用する Azure サービスとリージョンのパーソナライズされたビューが提供されるため、サービスに影響を与える通信 (停止、計画メンテナンス、その他の正常性アドバイザリなど) に最適なソースになります。 Service Health アラートを設定すると、サービスに影響を与える問題や変更について、優先する通信チャネルを介して通知を受け取ることができます。
計画メンテナンスの Service Health アラートを設定するには、Azure Portal に移動し、Service Health セクションにアクセスします。 [アラート] タブを選択し、プールの種類に基づいてサービスの種類を Azure Synapse Analytics または (および) SQL Data Warehouse として指定して、新しいアラートを作成します。 [メンテナンス] をイベントの種類に選択して、希望するスコープと通知の設定を定義し、アラート設定を保存します。 詳細な手順については、次のリソースを参照してください。
備考: 構成の一部として、使用しているサービスと一致するように条件の詳細を設定する必要があります。
- 専用 SQL プール (以前の SQL DW) の場合、サービスの選択は SQL Data Warehouse である必要があります
- Azure Synapse Analytics ワークスペース内の専用 SQL プールの場合、サービスの選択は Azure Synapse Analytics である必要があります
Note
すべてのメンテナンス イベントは、24 時間前の事前通知が行われます。 時間が重要な更新プログラムをデプロイする必要がある場合、高度な通知の時間が大幅に短縮されることがあります。 これは、更新プログラムの重大な特質により、指定のメンテナンス期間外に行われる場合があります。 メンテナンスが行われるという事前通知を受けても、通知にある期間中にメンテナンスを実行できない場合、キャンセル通知が届きます。 メンテナンスは、次の定期メンテナンス期間中に再開されます。 すべてのアクティブ メンテナンス イベントが [Service Health - Planned Maintenance](Service Health - 計画メンテナンス) セクションに表示されます。 Service Health の履歴には、過去のイベントの記録がすべて含まれます。 アクティブなイベント中に Azure Service Health チェック ポータル ダッシュボードを使用してメンテナンスを監視できます。
メンテナンス スケジュールの提供状況
選択したリージョンでメンテナンス スケジューリングが利用できない場合でも、メンテナンス スケジュールはいつでも表示および編集できます。 ご利用のリージョンでメンテナンス スケジューリングが利用可能になると、特定されたスケジュールはすぐにお使いの Synapse SQL プールでアクティブになります。
メンテナンス スケジュールを表示する
既定では、新しく作成されるすべてのデータ ウェアハウス インスタンスに対し、デプロイの間に、8 時間のプライマリおよびセカンダリ メンテナンス ウィンドウが適用されます。 上記の通り、ウィンドウはデプロイが完了するとすぐに変更できます。 指定されているメンテナンス ウィンドウの範囲外では、事前に通知することなく、メンテナンスは行われません。
Synapse SQL プールに適用されたメンテナンス スケジュールを表示するには、次の手順のようにします。
- Azure portal にサインインする
- 表示する Synapse SQL プールを選択します。
- 選択した Synapse SQL プールが、[概要] ブレードで開きます データ ウェアハウスに適用されているメンテナンス スケジュールが、 [Maintenance schedule](メンテナンス スケジュール) の下に表示されます。
![[概要] ブレード](media/maintenance-scheduling/clear-overview-blade.png)
メンテナンス スケジュールをスキップまたは変更する
最新のセキュリティ要件に準拠するために、これらの更新プログラムをスキップまたは遅延させる要求に対応することはできません。 ただし、状況に応じて、現在のサイクル内で DW500c 以上のデータ ウェアハウス層を使用している場合は、メンテナンス期間を調整するオプションがいくつかあります。
メンテナンスの保留中の通知を受け取り、ジョブの完了またはチームへの通知により多くの時間が必要な場合は、定義したメンテナンス期間の開始前に行う場合に限り、期間の開始時刻を変更できます。 これにより、サイクル内で期間が先へシフトされます。
"保留中" の通知を受け取ったサイクルの開始後に SQL 専用プールを一時停止して再開 (またはスケーリング) すると、メンテナンスを手動でトリガーできます。 週末のメンテナンス サイクルは土曜日の 00:00 UTC に開始され、週半ばのメンテナンス サイクルは火曜日の 12:00 UTC に開始されます。
必要とされる最小期間は 3 時間ですが、一般的な条件下であればこの操作は 30 分未満で完了します。 ただし、それより長い時間がかかる場合があることに注意することが重要です。 たとえば、メンテナンス開始時にアクティブなトランザクションがある場合、トランザクションは取り消されてロールバックされ、オンライン サービスの復元に遅延が発生する恐れがあります。 この状況を回避するには、メンテナンス期間の開始時に実行時間の長いトランザクションがアクティブにならないように注意することをお勧めします。
注意
- 期間の開始時刻を実際の現在時刻より前に変更すると、直ちにメンテナンスがトリガーされ、メンテナンス開始時にアクティブなトランザクションがある場合、トランザクションは中止されてロールバックされます。
- メンテナンスを開始するための一時停止と再開の操作が完了すると、メンテナンス完了を確認する通知を受け取る代わりに、取り消されたことが通知されます。
- DW400c 以下を使用している場合、メンテナンス スケジュールを変更することはできますが、パフォーマンス レベルが低いため、それに準拠しません。 前述のように、これらのデータ ウェアハウス レベルは、メンテナンス サイクル中のいつでもメンテナンスを受けることができます。
プライマリ ウィンドウとセカンダリ ウィンドウの指定
プライマリ ウィンドウとセカンダリ ウィンドウは別の曜日範囲にする必要があります。 たとえば、プライマリ ウィンドウを火曜日から木曜日にしたら、土曜日から日曜日をセカンダリ ウィンドウにします。 "Primary" と "Secondary" という用語は、それぞれ "期間 1" と "期間 2" と見なす必要があります。 つまり、メンテナンス アップグレードをデプロイするために、いずれかの期間を任意の順序で選択できます。
Synapse SQL プールに対するメンテナンス スケジュールを変更するには、次の手順のようにします。
Azure portal にサインインする
更新する Synapse SQL プールを選択します。 [概要] ブレードで、ページが開きます。 [概要] ブレードの [Maintenance Schedule](メンテナンス スケジュール) 概要リンクを選択して、メンテナンス スケジュール設定用のページを開きます。 または、左側にあるリソース メニューの [Maintenance Schedule](メンテナンス スケジュール) オプションを選択します。
ページ上部のオプションを使用して、プライマリ メンテナンス ウィンドウの優先日の範囲を指定できます。 この選択は、平日または週末にプライマリ ウィンドウが発生するかどうかを決定します。 選択した値に応じて、ドロップダウンの値が更新されます。 プレビュー中、一部のリージョンでは、利用可能な [Day](日) オプションのフルセットがまだサポートされていない可能性があります。
ドロップダウン リスト ボックスを使用して、優先されるプライマリとセカンダリのメンテナンス ウィンドウを選択します。
- [日] : 選択したウィンドウでメンテナンスを実行する優先日。
- [開始時刻] : メンテナンス ウィンドウに対する優先開始時刻。
- [時間枠] : 時間枠の優先時間数。
ブレードの下部にある [スケジュールの概要] 領域が、選択した値に基づいて更新されます。
[保存] を選択します。 新しいスケジュールがアクティブになったことを確認するメッセージが表示されます。
[日付]、[開始時刻]、[時間枠] (既定の 8 時間を含む) の選択は、いつでも更新できます。 メンテナンス スケジュールがサポートされていないリージョンにスケジュールを保存すると、次のメッセージが表示されます。 "Your settings are saved and become active when the feature becomes available in your selected region." (設定は保存されており、選択したリージョンで機能が使用可能になるとアクティブになります。)
よく寄せられる質問
メンテナンスの頻度はどれくらいが見込まれますか。
メンテナンスは 1 か月に 1 回以上行われる場合があります。メンテナンスには、OS の更新プログラム、セキュリティ パッチとドライバー、内部 Azure インフラストラクチャの更新プログラム、DW パッチと更新プログラムが含まれることがあるためです。 すべての顧客には週 2 回のスケジュールで、土曜日から日曜日、火曜日から木曜日の間のメンテナンス サイクルがあります。
専用 SQL プールのバージョンが変わらない場合、メンテナンスが完了した後に行われた変更は何ですか?
メンテナンスの更新終了後、SQL プールのバージョンが "変更されない場合があります"。 これは、メンテナンスには、OS の更新プログラム、セキュリティ パッチとドライバー、内部 Azure インフラストラクチャの更新プログラム、DW パッチと更新プログラムが含まれることがあるためです。 Synapse DW のパッチまたは更新プログラムがメンテナンスの中に含まれている場合にのみ、SQL 専用プールのバージョンが変更されます。
専用 SQL プールのバージョンをオンデマンドでアップグレードすることはできますか?
- 専用 SQL プールの管理を行う予定メンテナンスはありません。 ただし、状況によっては、サイクルの開始後にメンテナンスをトリガーするオプションがいくつかある場合があります。 「メンテナンス スケジュールをスキップまたは変更する」をご確認ください
- この専用 SQL プールは、サービスとしてのプラットフォーム (PaaS) 機能であることに注意するのが重要です。 これは、Microsoft Azure が、インフラストラクチャ、メンテナンス、更新、スケーラビリティなど、サービスに関連するすべての種類のタスクを処理することを意味します。 スケジュールされたメンテナンスは、アラート/通知を設定して追跡することができるため、近々実施されるメンテナンス アクティビティを把握することができます。
専用 SQL プールのメンテナンスが完了する前または後に、(もしあれば) どのような変更を行う必要がありますか?
- メンテナンス中は、一時停止、再開、またはスケール操作中に発生するのと同様に、ご利用のサービスが短時間オフラインになります。 通常、全体的なメンテナンス操作は 30 分未満で完了します。 ただし、メンテナンス期間中のデータベース アクティビティによっては、もう少し時間がかかる場合があります。 メンテナンスが通常より長くなることを回避するために、ETL、テーブルの更新、特にトランザクション操作を一時停止することをお勧めします。 次に例を示します。
- 計画した期間中にご利用のインスタンスが極端なビジー状態 (特に頻繁な更新と削除アクティビティで) になった場合、そのメンテナンス操作は通常よりも長く時間がかかる場合があります。 メンテナンス アクティビティが延びる危険を減らすために、可能であれば、アクティビティを主にデータベースへの読み取り専用クエリに制限し、特に実行時間の長いトランザクション クエリは避けることをお勧めします (次の項目をご参照ください)。
- メンテナンス開始時にアクティブなトランザクションがある場合、それらのトランザクションはキャンセルおよびロールバックされ、オンライン サービスの復元に遅延が発生することがあります。 この状況を回避するには、メンテナンス期間の開始時に実行時間の長いトランザクションがアクティブにならないように注意することをお勧めします。
追跡 ID 0000-000 を使用した専用 SQL プールの次回の予定メンテナンスに関する通知を受け取りましたが、その後メンテナンスはキャンセルまたは再スケジュールされました。 メンテナンスのキャンセル、または再スケジュールが行われたのはなぜですか?
スケジュールされたメンテナンスは、さまざまな要因でキャンセルされることがあります。それには、次のようなアクションが含まれます。
- サイクルの開始中に保留のメンテナンス通知を受信した後の、操作の一時停止またはスケーリング。
- メンテナンス サイクル中に、異なるサービス レベル目標 (SLO) をターゲットにしている場合 (DW400c より高い SLO からの移行で、DW400c 以下の SLO へのスケーリング バック、またはその逆など)、キャンセルが発生する場合があります。 これは、メンテナンス期間は DW400c 以下のパフォーマンス レベルには適用されず、いつでもメンテナンスを受けることができるためです。
- 内部インフラストラクチャの要因 (リリース チームによる計画メンテナンス スケジュールへの実際の変更など)。
- メンテナンスに予想以上の時間がかかっていることが内部監視で検出された場合、メンテナンスがキャンセルされる、またはスケジュール変更される場合があります。 メンテナンスは、顧客のメンテナンス期間設定で定義された、サービス レベル アグリーメント (SLA) 以内に完了する必要があります。
メンテナンス期間中に、ワークロードに対して考慮する必要があるベスト プラクティスはありますか?
- はい。可能であれば、オンライン サービスの復元でエラーや遅延が発生しないように、計画メンテナンス期間中はすべてのトランザクションおよび ETL のワークロードを一時停止してください。 実行時間の長いトランザクション操作は、次回のメンテナンス期間より前に完了する必要があります。
- ワークロードに、メンテナンス操作による中断への回復性を持たせるには、接続およびコマンド (クエリ) レベルの両方に再試行ロジックを使用し、より長い再試行間隔やより多くの再試行回数を適用して、場合によっては最大 30 分またはそれ以上に延びた接続の切断に耐えられるようにします。