パッチおよびメンテナンス・ウィンドウ情報の表示、パッチ・レベルの設定

このページのスクリプトはナビゲーション用で、内容を変更するものではありません。

Autonomous Databaseは、事前定義のメンテナンス・ウィンドウを使用してデータベースに自動的にパッチを適用します。メンテナンスおよびパッチの情報を表示して、Autonomous Databaseメンテナンス履歴の詳細を確認できます。

スケジュールされたメンテナンスおよびパッチ適用について
すべてのAutonomous Databaseインスタンスは、メンテナンス・ウィンドウに自動的に割り当てられ、異なるインスタンスは異なるメンテナンス・ウィンドウを持つことができます。
メンテナンス・イベント履歴の表示
Autonomous Databaseメンテナンス・イベント履歴を表示して、タイトル、状態、開始時間および停止時間などの過去のメンテナンス・イベントの詳細を確認できます。
パッチ・レベルおよびパッチの詳細の表示
解決された問題およびコンポーネントのリストを含むAutonomous Databaseパッチ情報を表示できます。
パッチ・レベルの設定
Autonomous Databaseインスタンスをプロビジョニングまたはクローニングする際には、今後のパッチに適用するパッチ・レベルを選択できます。 Autonomous Databaseインスタンスのプロビジョニング後にパッチ・レベルを編集することもできます。パッチ・レベルのオプションは2つあります: 標準および早期。
メンテナンス・ステータス通知の表示
DB_NOTIFICATIONSビューには、Autonomous Databaseインスタンスのメンテナンス・ステータス通知に関する情報が格納されます。
メンテナンスWindows中にアプリケーションの可用性を維持するためのベスト・プラクティス
アプリケーションの可用性を維持し、スケジュール済メンテナンス・ウィンドウ中のアプリケーションの中断を最小限に抑えるためのベスト・プラクティスに関する情報を提供します。

親トピック: メンテナンスWindows、パッチ適用オプション、作業リクエストおよび顧客連絡先の管理および表示

スケジュール済メンテナンスおよびパッチ適用について

すべてのAutonomous Databaseインスタンスはメンテナンス・ウィンドウに自動的に割り当てられ、異なるインスタンスには異なるメンテナンス・ウィンドウを設定できます。

Autonomous Databaseは、これらのメンテナンス・ウィンドウを使用して、データベース・ソフトウェア、データベース・ディクショナリ、オペレーティング・システム、Exadataストレージ、ファームウェアなど、データベースの実行に使用されるスタック全体にパッチを適用します。

パッチには、バグ修正、セキュリティ修正および新機能が含まれます。クリティカルなセキュリティ修正は、使用可能な直後に常に適用されます。パッチはすべてのデータベースに均一にデプロイされるため、個別パッチを追跡する必要はありません。問題の修正(1つのデータベースに見られる問題など)が実装されると、修正はすべてのAutonomous Databaseインスタンスにデプロイされます。

すべてのパッチは、継続的インテグレーションおよび開発パイプラインの一部である厳格なテストおよび検証プロセスを受けます。修正は、早期パッチ・レベルおよびAlways Freeデータベースにデプロイされる前に、複数のステージおよび環境で検証され、その後に通常パッチ・レベルのデータベースが続きます。このパイプラインを使用すると、パッチがすべてのデータベースにデプロイされる前に、回帰を捕捉して修正できます。パッチ適用で回帰が発生する可能性が低い場合、Oracleには、次のようなアクションを含め、問題を軽減するプロセスがあります:

パッチのサブセットまたはパッチ全体をロールバックします。
データベース・パラメータを設定して、回帰を導入したパッチを無効化します。
ダウンタイムや接続を中断することなく、問題を解決するためのオンライン・パッチの適用。

autonomous-database-continuous-integration.epsの説明は以下のとおりです

図autonomous-database-continuous-integration.epsの説明

「自動回帰検出」 for Autonomous Database⁇は、プロアクティブな回帰処理を提供し、自動化された問題検出、診断および緩和を可能にします。⁇これは、手動で問題およびファイル・サービス・リクエストを調査する必要性を減らすか、または排除できます。⁇自動回帰検出は、両方のデータベースで、すべてのデータベースをモニターします早期および定期パッチ・レベルですが、「早期」⁇パッチ・レベル・データベースでワークロードをテストする場合に特に役立ちます。⁇自動回帰検出で問題が見つかり、回帰が識別されると、問題を診断するための詳細情報とともに自動的に報告します。継続的デリバリ・パッチ適用サイクルの一環として、この自動レポートにより、Oracleは、変更が本番データベース(「標準」⁇patchレベルのデータベース)に到達する前に問題を軽減または修正できます。自動回帰検出では、すべての問題を見つけることができない場合があります。問題に自分が表示されている場合は、サービス・リクエストを提出できます。

自動回帰検出には次のものが含まれます:

自動回帰検出は、データベースをモニターし、インシデントが発生した場合、インシデントのバグを自動ワークロード・リポジトリから抽出された詳細な診断情報とともに報告します。
インシデント・レポート・システムは、Oracle Automatic Incident Monitoringを使用して、Oracle Cloud Infrastructureオペレーションおよび開発チームに通知を生成します。
問題は、自動回帰検出アラートを分析することによって軽減されます。
学習と改善は、自動回帰検出に対して継続的に行われます。

Autonomous Databaseの詳細ページには、「パッチ・レベル」フィールドと、今後のメンテナンス・ウィンドウの日時を含む「次回のメンテナンス」フィールドが表示されます。日付は、次のメンテナンス・ウィンドウがスケジュールされると自動的に更新されます。「履歴を表示」リンクには、過去のメンテナンスの詳細が表示されます。「ターゲット・コンポーネント」フィールドには、次のメンテナンス・ウィンドウで更新するコンポーネントが表示されます。

「図adb_patch_level.pngの説明」

Autonomous Data Guardが有効な場合、コンソールにはローカル・スタンバイ・データベースのメンテナンス情報も表示されます。

「メンテナンス」領域には次の情報が含まれます:

メンテナンス・フィールド	説明
パッチ・レベル	インスタンスのパッチ・レベルを表示します。パッチ・レベルのオプションは2つあります: 標準および早期。パッチ・レベル設定を管理するには、「編集」をクリックします。詳細については、「パッチ・レベルの設定」を参照してください。
次回のメンテナンス	次回のスケジュール済メンテナンス・ウィンドウの期間を指定します。過去のメンテナンスの詳細を表示するには、「履歴を表示」をクリックします。詳細については、「メンテナンス・イベント履歴の表示」を参照してください。
ターゲット・コンポーネント	次回のメンテナンス・ウィンドウのターゲット・コンポーネントをリストします。使用可能な値は次のとおりです。データベース: パッチがデータベース・ホームおよび実行可能ファイルに適用される場合。辞書: パッチがデータ・ディクショナリおよびOracle APEXに適用される場合。インフラストラクチャ: パッチがExadataハードウェアまたはGrid Infrastructureに適用される場合。
次回のメンテナンス(ローカル・ピア)	ローカルAutonomous Data Guardスタンバイの次のスケジュール済メンテナンス・ウィンドウの期間を指定します。過去のメンテナンスの詳細を表示するには、「履歴を表示」をクリックします。
ターゲット・コンポーネント(ローカル・ピア)	Autonomous Data Guardの今後のメンテナンス・ウィンドウのターゲット・コンポーネントをリストします。使用可能な値は次のとおりです。データベース: パッチがデータベース・ホームおよび実行可能ファイルに適用される場合。辞書: パッチがデータ・ディクショナリおよびOracle APEXに適用される場合。インフラストラクチャ: パッチがExadataハードウェアまたはGrid Infrastructureに適用される場合。
顧客の連絡先	顧客担当者が設定されると、Oracleは、Autonomous Databaseサービス関連の問題について、指定された電子メール・アドレスに通知を送信します。詳細については、「運用上の問題およびお知らせの顧客担当者の表示および管理」を参照してください。

スケジュールされたメンテナンスおよびパッチ適用に関するノート:

Autonomous Database操作チームは、指定した期間、サービス・リクエストを介して明示的に権限を付与しないかぎり、データにアクセスすることはありません。
メンテナンス・ウィンドウ中にデータベースが停止状態の場合、データベースの起動時にパッチからのデータベース変更が適用されます。
メンテナンス・ウィンドウ中、データベースは使用可能なままです。データベースへの新しい接続は常に成功します。パッチを適用するコンポーネントによっては、既存のデータベース接続が短時間切断される場合がありますが、すぐに再接続してデータベースの使用を続行できます:
- データベース・パッチの場合、パッチ適用開始後のドレイン時間より長く実行されている既存の接続は切断されることがあります。
- インフラストラクチャ・パッチの場合、パッチ適用開始後のドレイン時間より長く実行されていると、既存の接続が切断される可能性があります。
- ディクショナリ・パッチの場合、パッチを適用するディクショナリ・オブジェクトのロックを保持している既存の接続は切断されることがあります。そうしないと、既存の接続は影響を受けません。たとえば、パッチ適用中にアプリケーションがDBMS_CLOUDパッケージのプロシージャを実行していて、パッケージにパッチを適用する必要がある場合、そのパッケージを使用するセッションは切断されることがあります。
  
  詳細については、SESSION_EXIT_ON_PACKAGE_STATE_ERRORを参照してください。
「Oracle Cloud Infrastructureイベント」を使用して、メンテナンスの開始および終了時に通知できます。詳細については、「Autonomous Databaseの情報イベント」を参照してください。
割り当てられたメンテナンス・ウィンドウを、リージョンのローカル・タイム・ゾーンの土曜日または日曜日の別の2時間ウィンドウに変更する場合は、「Oracle Cloudサポート」にサービス・リクエストを提出します。

リージョンのローカル・タイム・ゾーンの土曜日または日曜日のメンテナンス・ウィンドウに特定の期間が必要な場合は、同じサービス・リクエストで期間をリクエストできます。メンテナンス・ウィンドウに特定の期間をリクエストした場合、変更できるのは、リクエストした期間がデータベースで使用可能な場合のみです。
データベースに割り当てられているストレージが384 TBの場合、「Oracle Cloudサポート」でサービス・リクエストを送信することで、カスタムの2時間ウィンドウを選択できます(つまり、メンテナンス・ウィンドウのリージョンのローカル・タイム・ゾーンの土曜日または日曜日のいずれかで特定の日および期間をリクエストするサービス・リクエストを提出できます)。

本番データベースからワークロードを取得し、ターゲットの早期パッチ・レベルのリフレッシュ可能クローンでワークロードをリプレイする方法の詳細は、「次回のパッチに対するワークロードのテスト」を参照してください。

Autonomous Databaseのゼロ回帰SLOの詳細は、「ゼロ回帰サービス・レベル目標」を参照してください。

親トピック: パッチおよびメンテナンス・ウィンドウ情報の表示、パッチ・レベルの設定

メンテナンス・イベント履歴の表示

タイトル、状態、開始時間および停止時間などの過去のメンテナンス・イベントの詳細は、Autonomous Databaseメンテナンス・イベント履歴を表示できます。

必要に応じて、次の前提条件ステップを実行します:

「クラウド」の横にあるをクリックして、Oracle Cloud Infrastructureコンソールを開きます。
Oracle Cloud Infrastructureの左側のナビゲーション・メニューから、Oracle Databaseをクリックし、Autonomous Database をクリックします。
Autonomous Databasesページで、「表示名」列の下のリンクからAutonomous Databaseを選択します。

メンテナンス履歴を表示するには、次の手順を実行します:

Autonomous Databaseの詳細ページの「次のメンテナンス」で、「履歴を表示」をクリックします。
Oracle Cloud Infrastructureコンソールに「メンテナンス履歴」ページが表示されます。
(オプション)「検索とフィルタ」セレクタを使用して、状態別にイベントをフィルタします。

たとえば、「成功」を選択すると、「メンテナンス履歴」ページに成功状態のメンテナンス・イベントのみが表示されます。

「図adb_maintenance_history.pngの説明」

「メンテナンス履歴」ページには、次のような各メンテナンス・イベントの詳細が表示されます:

フィールド	説明
タイトル	メンテナンス・イベントの名前。
メンテナンス・タイプ	計画済または未計画。
ターゲット・コンポーネント	メンテナンス・イベントが発生するリソースのタイプ: データベース、ディクショナリまたはインフラストラクチャ。
状態	成功、失敗または進行中。
開始時間	メンテナンス開始時間
終了時間	メンテナンス終了時間

ノート:

メンテナンス・イベント履歴は、2021年2月以降にメンテナンス・イベントを使用して開始できます。

親トピック: パッチおよびメンテナンス・ウィンドウ情報の表示、パッチ・レベルの設定

パッチ・レベルおよびパッチの詳細の表示

解決済の問題およびコンポーネントのリストを含むAutonomous Databaseパッチ情報を表示できます。

Autonomous Databaseインスタンスのパッチ・レベルの表示

Oracle Cloud InfrastructureコンソールのAutonomous Database詳細ページから、インスタンスのパッチ・レベルを表示できます。

Autonomous Database情報タブでは、「メンテナンス」領域にインスタンスのパッチ・レベルが表示されます。選択肢は次のとおりです: 定期と早期。
パッチ・レベルを変更する場合は、「編集」をクリックします。

詳細については、「パッチ・レベルの設定」を参照してください。

DBA_CLOUD_PATCH_INFOビューは、報告されたバグに関連するパッチ情報を提供します(これは顧客が報告するバグのリストです)。この情報を使用して、報告されたバグが修正されたかどうかを判断し、その修正がAutonomous Databaseインスタンスに適用されたパッチ・バージョンを判断できます。パッチに顧客のバグがない場合、DBA_CLOUD_PATCH_INFOにはそのパッチの行は含まれません。

特定のパッチのパッチ情報を表示するには、次の手順を実行します:

表示するAutonomous Databaseパッチを選択します。 Oracle Cloud Infrastructureコンソールの「メンテナンス履歴」ページには、「タイトル」列の下にパッチのリストが表示されます。
選択したパッチについて、DBA_CLOUD_PATCH_INFOビューを問い合せて追加の詳細を検索します。
たとえば、パッチADBS-25.4.4.2の場合は、次の問合せを使用します:
```
SELECT * FROM DBA_CLOUD_PATCH_INFO WHERE PATCH_VERSION = 'ADBS-25.4.4.2';
```
関心のある問題については、ビューを問い合せて問題の詳細を取得します:
```
SELECT * FROM DBA_CLOUD_PATCH_INFO WHERE PATCH_VERSION = 'ADBS-25.4.4.2' and BUG_NUM = bug_number;
```

使用可能なすべてのパッチのパッチ情報を表示するには:

SELECT * FROM DBA_CLOUD_PATCH_INFO;

パッチ情報を表示するノート:

ビューDBA_CLOUD_PATCH_INFOはADMINユーザーが使用できます。
解決された問題に関するパッチ情報および詳細は、ADBS-21.7.1.1以降(2021年7月開始)から入手できます。
ビューDBA_CLOUD_PATCH_INFOには次の列があります:
```
BUG_NUM, BUG_TITLE, COMPONENT_NAME, PATCH_VERSION
```

メンテナンス中に適用されたパッチの詳細は、「メンテナンス・ステータス通知の表示」を参照してください。

親トピック: パッチおよびメンテナンス・ウィンドウ情報の表示、パッチ・レベルの設定

パッチ・レベルの設定

Autonomous Databaseインスタンスをプロビジョニングまたはクローニングする場合、今後のパッチに適用するパッチ・レベルを選択できます。 Autonomous Databaseインスタンスのプロビジョニング後にパッチ・レベルを編集することもできます。パッチ・レベルのオプションは2つあります: 標準および早期。

パッチ・レベル「早期」を選択すると、「標準」スケジュール済パッチの1週間前にAutonomous Databaseインスタンスにパッチが適用されます。 Oracle Cloud Infrastructureコンソールの「次回のメンテナンス」フィールドには、パッチ・レベルに基づいてメンテナンス・ウィンドウの日時が反映されます。

Autonomous Databaseインスタンスをプロビジョニングするためのデフォルトのパッチ・レベルは、「標準」です。クローニングのデフォルト・パッチ・レベルは、ソース・データベースに指定されたパッチ・レベルです。

インスタンスをプロビジョニングまたはクローニングし、パッチ・レベルを「早期」に設定すると、今後のパッチをすべてのシステムに適用する前に使用し、テストできます。 Oracleでは、パッチが本番環境に到達する前に今後のパッチをテストする場合は、開発およびテスト・データベースの「早期」パッチ・レベルを選択することをお薦めします。 Oracle Real Application Testingを使用してワークロードをテストし、本番システム上のワークロードを取得して、「早期」パッチ・レベルでリプレイすることもできます。詳細については、「Oracle Real Application Testingを使用したワークロードのテスト」を参照してください。

ノート:

パッチ・レベルの設定は、ECPUコンピュート・モデルを使用するAutonomous Databaseインスタンスでのみ使用できます。

インスタンスのプロビジョニングまたはクローニング中にパッチ・レベルを設定するには、次を実行します:

新しいインスタンスをプロビジョニングする場合は、プロビジョニング手順に従い、パッチ・レベル(「標準」または「早期」)を選択します。詳細については、「Autonomous Databaseインスタンスのプロビジョニング」を参照してください。
インスタンスをクローニングする場合は、クローニング手順に従い、パッチ・レベル(「標準」または「早期」)を選択します。詳細については、「Autonomous Databaseインスタンスのクローンを作成」を参照してください。

既存のAutonomous Databaseのパッチ・レベルを変更するには、次の手順を実行します:

Autonomous Database詳細ページの「メンテナンス」の「パッチ・レベル」フィールドで、「編集」をクリックします。
ノート:
「編集」ボタンは、次の状況で無効にできます:
- データベース・バージョンのリージョンで早期パッチ・レベルが使用できない場合。
- データベースでAutonomous Data Guardが有効になっている場合。
- データベースが早期パッチ・レベルで、通常のパッチ・レベルに移動できない場合。この場合、次のメンテナンス・ウィンドウの後で再試行してください。
パッチ・レベル(「標準」または「早期」)を選択し、「送信」をクリックします。
パッチ・レベルの変更にかかる時間は、データベースのサイズによって異なります。この時間中、短い接続が低下する可能性があります。

Oracle Supportへのパッチ問題の報告

「早期」パッチ・レベル・データベースの問題を報告すると、Oracle Supportは、問題が「標準」パッチ・レベル・データベースに伝播されないようにするために必要なアクションを実行します。可能なアクションの例をいくつか示します:

問題の原因となったパッチは、通常のパッチ・レベルのデータベースにパッチが適用される前に削除されます。
問題の原因となったパッチは、通常のパッチ・レベルのデータベースに適用されているときに、データベース・パラメータを使用して無効化されます。
通常のパッチ・レベル・データベースのパッチ適用は、修正アクションが実行されるまで一時停止されます。

レポートに問題がある場合は、「Oracle Cloudサポート」でサービス・リクエストを提出するか、サポート担当に連絡してください。

Oracleは、本番データベースでゼロのサービス・レベル目標を提供します。詳細については、「ゼロ回帰サービス・レベル目標」を参照してください。

パッチ適用レベルのノート:

パッチ・レベルを設定するオプションは、各リージョンでは使用できません。一部のリージョンでは、すべてのAutonomous Databaseインスタンスが「標準」パッチ・レベルでプロビジョニングまたはクローニングされます。
Autonomous Data Guardは、パッチ・レベル「標準」のインスタンスでのみ使用できます。パッチ・レベル「早期」でAutonomous Databaseインスタンスを構成する場合、Autonomous Data Guardを有効にできません。
Always Free Autonomous Databaseインスタンスは、「早期」パッチ・レベル・オプションを提供しません。
ソースのAutonomous Databaseインスタンスのパッチ・レベルが「標準」の場合、「早期」パッチ・レベルをサポートするリージョンで、クローンのパッチ・レベルを「早期」に設定できます。

親トピック: パッチおよびメンテナンス・ウィンドウ情報の表示、パッチ・レベルの設定

メンテナンス・ステータス通知の表示

DB_NOTIFICATIONSビューには、Autonomous Databaseインスタンスのメンテナンス・ステータス通知に関する情報が格納されます。

通知情報を表示するには:

Autonomous Databaseインスタンスに接続します。
次の問合せを使用して、メンテナンス(パッチ適用)情報を表示します。
```
SELECT * FROM DB_NOTIFICATIONS WHERE TYPE = 'MAINTENANCE';
```

次に、DESCRIPTIONフィールド値の詳細を示します。

メンテナンス実行が終了しました: メンテナンスが完了したことを指定します。 MAINTENANCE_STATUSは、ACTUAL_START_DATEおよびACTUAL_END_DATEで完了したメンテナンスの開始タイムスタンプと終了タイムスタンプを持つ値COMPLETEDを示します。
インスタンスのメンテナンス実行がスケジュールされています: 新しいメンテナンスがスケジュールされていることを指定します。 MAINTENANCE_STATUSは、SCHEDULEDの値と、EXPECTED_START_DATEおよびEXPECTED_END_DATEのスケジュールされたメンテナンスの開始タイムスタンプと終了タイムスタンプを示します。
メンテナンス実行が開始されました: メンテナンスが進行中であることを指定し、アクティブ・メンテナンスの開始タイムスタンプを指定します。 MAINTENANCE_STATUSは値IN_PROGRESSを示し、ACTUAL_START_DATEは開始タイムスタンプを格納します。

次の表に、DB_NOTIFICATIONS列およびデータ型を示します。

列	データ型	説明
`TYPE`	`VARCHAR2(128)`	通知のタイプを指定します。有効な値: `MAINTENANCE`。
`TIME`	`TIMESTAMP(6) WITH TIME ZONE`	通知エントリが追加された時間。
`EXPECTED_START_DATE`	`TIMESTAMP(6) WITH TIME ZONE`	スケジュール済メンテナンス開始時間。
`EXPECTED_END_DATE`	`TIMESTAMP(6) WITH TIME ZONE`	スケジュール済メンテナンス終了時間。
`ACTUAL_START_DATE`	`TIMESTAMP(6) WITH TIME ZONE`	実際のメンテナンス開始時間。
`ACTUAL_END_DATE`	`TIMESTAMP(6) WITH TIME ZONE`	実績メンテナンス終了時間。
`MAINTENANCE_PRODUCT`	`VARCHAR2(128)`	メンテナンスがスケジュールされている製品/コンポーネント。
`MAINTENANCE_STATUS`	`VARCHAR2(128)`	メンテナンスの現在のステータス。
`DESCRIPTION`	`VARCHAR2(128)`	通知メッセージの詳細。
`PATCH_ID`	`VARCHAR2(128)`	パッチのバージョン

親トピック: パッチおよびメンテナンス・ウィンドウ情報の表示、パッチ・レベルの設定

メンテナンスWindows中にアプリケーションの可用性を維持するためのベスト・プラクティス

アプリケーションの可用性を維持し、スケジュール済メンテナンス・ウィンドウ中のアプリケーションの中断を最小限に抑えるためのベスト・プラクティスに関する情報を提供します。

Autonomous Databaseパッチは、スケジュール済メンテナンス・ウィンドウ中にローリング・パッチとして適用されます。ローリング・パッチを使用すると、実行中の元のノードでパッチ適用が開始される前に、新しいクラスタ・ノードでAutonomous Databaseインスタンスが使用可能になります。新しいクラスタ・ノードでデータベースが使用可能になると、すべての新しい接続が新しいノードに転送されます。つまり、データベースはオンラインのままであり、メンテナンス中も使用可能であり、メンテナンス・ウィンドウ中に新しいデータベース接続リクエストが成功します。

元のノードの既存のデータベース接続は、5分間の「^足1」のドレインの対象となります。排出期間中、データベースはクライアントが既存の接続を解放するのを待機します。排出期間後、元のノードにデータベース接続が残っている場合、残りの接続は切断され、パッチ適用が開始されます。次のベスト・プラクティスは、排出期間中にデータベース接続が排出され、新しいノードに再接続されるため、アプリケーションがメンテナンス・ウィンドウ中に中断されないようにするのに役立ちます。

接続プールを使用し、プールに接続を返す

アプリケーションからスケジュール済メンテナンスを非表示にするには、接続プールを使用することをお薦めします。アプリケーションが次のことを行う場合、メンテナンス・ウィンドウ中にアプリケーションを実行しても、アプリケーションには影響しません:

推奨設定で接続プールを使用します。
接続プールから接続をチェックアウトします。
排水時間(5分)未満の接続を使用します。
接続プールへの接続を返します。

接続プールを使用するアプリケーションのベスト・プラクティスは、次のステップに従うことです。アプリケーションは接続をチェックアウトし、データベース処理のために接続を使用し、作業が完了するとすぐに接続プールに接続を解放します(これにより、他のスレッドで接続を使用できるようになります)。

排出期間が開始されると、接続プールでは、新しい接続が新しく使用可能なノードに接続されるように、接続プール内の使用可能な接続の再確立が処理されます。アプリケーションが新しい接続をチェックアウトしても、中断は発生しません(新しい接続は新しいノードを使用します)。ただし、メンテナンス開始前またはドレイン時間中に接続がチェックアウトされ、ドレイン時間を超えて継続する処理が実行されると、接続は切断されます。この場合、中断を回避するために、メンテナンス開始前にそのような長時間実行操作を停止し、メンテナンス終了時に再起動できます。次の項「情報イベントのサブスクライブ」で説明するように、長時間実行操作を停止するタイミングと再起動するタイミングを把握するために、イベントをサブスクライブできます。

次の表に、共通接続プール・タイプの一部と、推奨されるバージョンおよび設定を示します。

接続プール	バージョン	Oracle JDBCドライバのバージョン	推奨設定
ユニバーサル接続プール(UCP)	23ai	23ai	デフォルト設定を使用します。
ユニバーサル接続プール(UCP)	19.12以上	19.13以上	`ValidateConnectionOnBorrow=true` JDBCドライバの接続プロパティに`oracle.jdbc.defaultConnectionValidation=LOCAL`を追加します。
Weblogic	14.1.1以上	19.13以上	`test-connections-on reserve=true` `test-table-name=SQL ISVALID` `seconds-to-trust-an-idle-pool-connection=0` バグ35731335のパッチを適用します。詳細については、「パッチ35731335」を参照してください。
光	6.0.0以上	19.21以上	`com.zaxxer.hikari.aliveBypassWindowMs`を -1に設定します。 JDBCプロパティで`oracle.jdbc.defaultConnectionValidation`を`SOCKET`に設定します。 `com.zaxxer.hikari.enableRequestBoundaries`を`true`に設定します。
Tomcat	9.0, 10.0, または 11.0	任意のバージョン	UCPでTomcatを使用している場合は、上記のUCP推奨に従ってください。 JDBCドライバでTomcatを使用している場合は、Oracle JDBCドレインAPIをコール: `isValid()`, `isUsable()`, `pingDatabase()`または`endRequest()`。 JDBCプロパティで`oracle.jdbc.defaultConnectionValidation`を`SOCKET`に設定します。

接続プールを使用できない場合、JDBCドライバでの接続テストの使用

接続プールを使用できない場合、Oracleクライアント・ドライバ19.13(またはそれ以降)は、アプリケーションが中断を確認しないように接続を排出できます。接続が正しく排出されるように、任意のOracle JDBCドレインAPIをコールできます: isValid(), isUsable(), pingDatabase()またはendRequest()。

情報イベントのサブスクライブ

アプリケーションで長時間実行されているデータベース操作がドレイン時間(5分)より長い場合、プールまたはJDBCドライバはドレイン時間の終了前に解放されないため、接続をドレインできません。このような長時間実行操作では、中断を回避するために、メンテナンス・ウィンドウ中またはメンテナンス・ウィンドウ直前にプロセスおよびジョブを開始しないでください。

Autonomous Databaseは、情報イベントを「OCIイベント」サービスに公開して、次の情報イベント(イベント・カテゴリ「保守」を含む)を含むメンテナンス・ウィンドウについて通知します:

新しいメンテナンス・ウィンドウがスケジュールされている場合
パッチ適用開始の24時間前
パッチ適用開始の60分前
パッチ適用の開始時
パッチ適用の終了時

Autonomous Database情報イベントをサブスクライブし、オプションでイベント・カテゴリのメンテナンスを指定し、通知を受信して、メンテナンス・イベントに受信する通知を制限できます。その後、定義した通知およびルールに基づいて、長時間実行操作を停止し、メンテナンス終了後に再起動するアクションを実行できます。発表されたメンテナンス・ウィンドウは通常2時間ですが、実際のパッチ適用は、そのウィンドウ中に5分から10分で行われます。これらのイベントおよび長時間実行操作の知識を使用して、長時間実行操作を停止するタイミングおよび再起動するタイミングを決定できます。

詳細については、「Autonomous Databaseイベントの使用」を参照してください。

アプリケーションでPL/SQLを使用している場合のPL/SQLセッション・ステートの処理

データベース・パラメータSESSION_EXIT_ON_PACKAGE_STATE_ERRORは、セッションで実行されているステートフルPL/SQLパッケージの処理を指定します。このようなパッケージが変更された場合(Oracle提供オブジェクトの計画メンテナンス中など)、パッケージをアクティブにインスタンス化しているセッションは、パッケージを実行しようとすると次のエラーを受け取ります: ORA-04068: existing state of packages has been discarded.。ただし、ORA-4068エラーを受信するアプリケーション・コードでは、このエラーを再試行ロジックで処理できない場合があります。

SESSION_EXIT_ON_PACKAGE_STATE_ERRORをTRUEに設定すると、このケースの処理が異なります。 SESSION_EXIT_ON_PACKAGE_STATE_ERRORがTRUEの場合、パッケージの状態が破棄されたときにORA-4068エラーを呼び出すのではなく、セッションはすぐに終了します。これは、多くのアプリケーションが接続を自動的に透過的に再確立することでセッション終了を処理できるため、利点があります。

詳細については、SESSION_EXIT_ON_PACKAGE_STATE_ERRORを参照してください。

親トピック: パッチおよびメンテナンス・ウィンドウ情報の表示、パッチ・レベルの設定

脚注の凡例

脚注1: このドレイン時間は、将来のリリースで変更される可能性があることに注意してください。