このメンテナンス スケジュール機能は、Service Health 計画メンテナンス通知、リソース ヘルス チェック モニター、Azure Synapse Analytics 内の Synapse SQL プール (データ ウェアハウス) のメンテナンス スケジューリング サービスを統合します。
メンテナンス スケジューリングは、新機能、アップグレード、および修正プログラムを受信するのに都合のよい時間枠を選択するために使用してください。 プライマリとセカンダリのメンテナンス期間は 7 日以内に選択する必要があり、各期間は別々の日の範囲内である必要があります。
たとえば、土曜日の 22:00 から日曜日の 01:00 をプライマリ ウィンドウとしてスケジュールし、水曜日の 19:00 から 22:00 をセカンダリ ウィンドウとしてスケジュールできます。 プライマリ メンテナンス期間中にメンテナンスを実行できない場合は、セカンダリ メンテナンス期間中にメンテナンスが再試行されます。 サービス メンテナンスは、プライマリ ウィンドウとセカンダリ ウィンドウの両方で発生する場合があります。 すべてのメンテナンス操作の迅速な完了を保証するために、DW400c 以下のデータ ウェアハウス層は指定されたメンテナンス ウィンドウ外にメンテナンスを完了する可能性があります。
新しく作成されたすべてのデータ ウェアハウス インスタンスには、デプロイ中にシステム定義のメンテナンス スケジュールが適用されます。 デプロイが完了するとすぐに、スケジュールを編集できます。
メンテナンス期間を決める場合は、開始時刻を選び、最長期間を設定する必要があります。 "メンテナンス期間の最長期間" によって、メンテナンス タスクを実行する時間枠が決まります。この時間枠は 3 時間から 8 時間で、最小要件としては 3 時間です。 この期間中は、専用のプールが一時停止/再開と同様のプロセスを使用してアップグレードされた容量に移動されるため、データ ウェアハウスは一時的にオフラインになります。 一般的な条件下ではこの操作は 30 分以内に完了しますが、それより長い時間がかかる場合もあることに注意することが重要です。 たとえば、メンテナンス開始時にアクティブなトランザクションがある場合、トランザクションは取り消されてロールバックされ、オンライン サービスの復元に遅延が発生する恐れがあります。 この状況を回避するには、メンテナンス期間の開始時に実行時間の長いトランザクションがアクティブにならないように注意することをお勧めします。
時間の影響を受けやすい更新プログラムをデプロイする必要がない限り、すべてのメンテナンス操作は指定されたメンテナンス期間内に完了する必要があります。 スケジュールされたメンテナンス中にデータ ウェアハウスが一時停止されると、再開操作中に更新されます。 データ ウェアハウスの保守が完了すると、すぐに通知が届きます。
注意
- メンテナンス期間は DW400c 以下のパフォーマンス レベルには適用されません。 いつでもメンテナンスを受けることができます。
- DW400c 以下では、メンテナンス期間中のさまざまな時間に接続に複数の短時間の損失が発生する可能性があります。
アラートと監視
Azure では、現在および今後の問題、サービスに影響するイベント、計画メンテナンス、可用性に影響を与える可能性があるその他の変更など、クラウド リソースの正常性に関する包括的な分析情報が提供されます。
Service Health では、使用する Azure サービスとリージョンのパーソナライズされたビューが提供されるため、サービスに影響を与える通信 (停止、計画メンテナンス、その他の正常性アドバイザリなど) に最適なソースになります。 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 である必要があります
注意
すべてのメンテナンス イベントは、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](メンテナンス スケジュール) の下に表示されます。
メンテナンス スケジュールをスキップまたは変更する
最新のセキュリティ要件に確実に準拠するために、これらの更新プログラムをスキップまたは遅延する要求に対応することはできません。 ただし、状況に応じて、現在のサイクル内で DW500c 以上のデータ ウェアハウス層を使用している場合は、メンテナンス期間を調整するオプションがいくつかあります。
メンテナンスの保留中の通知を受け取り、ジョブの完了またはチームへの通知により多くの時間が必要な場合は、定義したメンテナンス期間の開始前に行う場合に限り、期間の開始時刻を変更できます。 これにより、サイクル内でウィンドウが時間を進めて移動します。
"保留中" の通知を受け取ったサイクルの開始後に SQL 専用プールを一時停止して再開 (またはスケーリング) すると、メンテナンスを手動でトリガーできます。 週末のメンテナンス サイクルは土曜日の 00:00 UTC に開始され、週半ばのメンテナンス サイクルは火曜日の 12:00 UTC に開始されます。
最小期間は 3 時間ですが、一般的な条件下では、この操作は 30 分以下で完了します。 ただし、それより長い時間がかかる場合があることに注意することが重要です。 たとえば、メンテナンスの開始時にアクティブなトランザクションがある場合、トランザクションは取り消されてロールバックされ、オンライン サービスの復元に遅延が発生する可能性があります。 この状況を回避するには、メンテナンス期間の開始時に実行時間の長いトランザクションがアクティブにならないように注意することをお勧めします。
注意
- 期間を実際の現在の時刻より前の開始時刻に変更すると、メンテナンスはすぐにトリガーされ、メンテナンスの開始時にアクティブなトランザクションがある場合は、中止され、ロールバックされます。
- メンテナンスを開始するための一時停止と再開の操作が完了すると、メンテナンスの完了を確認する通知を受け取る代わりに、取り消されたことを通知されます。
- DW400c 以下を使用している場合、メンテナンス スケジュールを変更することはできますが、パフォーマンス レベルが低いため、それに準拠しません。 前述のように、これらのデータ ウェアハウス レベルは、メンテナンス サイクル中のいつでもメンテナンスを受けることができます。
プライマリ ウィンドウとセカンダリ ウィンドウの指定
プライマリ ウィンドウとセカンダリ ウィンドウは別の曜日範囲にする必要があります。 たとえば、プライマリ ウィンドウを火曜日から木曜日にしたら、土曜日から日曜日をセカンダリ ウィンドウにします。 "Primary" と "Secondary" という用語は、それぞれ "ウィンドウ 1" と "ウィンドウ 2" として考慮されるべきです。 つまり、メンテナンス アップグレードをデプロイするために、ウィンドウのいずれかを自由な順序で選択可能です。
Synapse SQL プールに対するメンテナンス スケジュールを変更するには、次の手順のようにします。
Azure portal にサインインする
更新する Synapse SQL プールを選択します。 概要ウィンドウにページが開きます。 [概要] ウィンドウで [ メンテナンス スケジュールの概要 ] リンクを選択して、メンテナンス スケジュール設定のページを開きます。 または、左側にあるリソース メニューの [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 分またはそれ以上に延びた接続の切断に耐えられるようにします。