Oracle Database OPatchAutoでのOracle Real Application Clustersのメンテナンス, リリース23aiおよび以降のリリース

Oracle Real Application Clusters (Oracle RAC)およびOracle Grid Infrastructureをメンテナンスするには、OPatchAutoを使用します。

パッチ適用プロセスを簡略化するために、Oracle Fleet Patching and Provisioningを使用することをお薦めします。Oracle Fleet Patching and Provisioningを使用しない場合は、Oracle Real Application Clusters (Oracle RAC)にDBCAを使用することをお薦めします。OPatchAutoは、使用できる追加オプションです。

ノート:

メンテナンスを簡略化し、潜在的な問題を回避するためのベスト・プラクティスとして、新しいOracleホームおよびホーム外パッチ適用を使用してデータベース・メンテナンスを実行することをお薦めします。これは、パッチ適用操作に適したデプロイメントの選択肢です。

OPatchおよびOPatchAutoを使用するための確認と前提条件
パッチをダウンロードし、ソフトウェア・メンテナンスを実行する前に、計画されているデプロイメント・シナリオのガイドラインと前提条件を確認します。
システム要件の確認
OPatchを起動する前に、必要な環境依存関係があることを確認してください。
Gridホームでの個別パッチの競合の検出および解決
Oracle Real Application Clustersデータベース・ホームおよびOracle Grid Infrastructure GridホームでOPatchAutoを実行する前に、個別パッチの競合を検出して解決する必要があります。
OPatchシステム領域チェックの実行
適用するパッチについて、ORACLE_HOMEファイル・システムで十分な空き領域が使用可能かどうかを確認します。
OPatchAutoを使用したパッチのインストール・シナリオ
シナリオの手順を使用します。パッチの手順は、Oracle Grid InfrastructureおよびOracle RACデータベース・ホームによって異なります。
変更されたSQLファイルのデータベースへのロード
OPatchを使用してデータベース・メンテナンスを実行する場合は、datapatchツールを手動で実行して、変更されたSQLファイルをデータベースにロードできるようにする必要があります。
Oracle Recovery Managerカタログのアップグレード
Oracle Recovery Managerを使用している場合は、カタログをアップグレードする必要があります。
既知の問題
OPatchの実行中に発生した問題が既知の問題であるかどうかを確認する方法を学習します。
ドキュメントのアクセシビリティについて

OPatchおよびOPatchAutoを使用するための確認と前提条件

パッチをダウンロードし、ソフトウェア・メンテナンスを実行する前に、計画されているデプロイメント・シナリオのガイドラインと前提条件を確認します。

ノート:

メンテナンス・リリース更新または個別パッチの適用を開始する前に、Oracleホーム・バイナリ、Gridホーム・バイナリおよびセントラルOracleインベントリ(更新の影響を受ける可能性があるoraInventory)のバックアップを作成することをお薦めします。詳細は、次を参照してください。

ORACLE_HOMEバックアップの実行方法(ドキュメントID 565017.1)

パッチのダウンロードおよび解凍

最新リリースのOPatchバージョンをダウンロードして使用することをお薦めします。My Oracle Supportから最新のバージョンをダウンロードします。

My Oracle Supportパッチ6880880

パッチは、Oracleソフトウェア・バイナリの所有者として解凍します。これは、Oracle DatabaseおよびOracle Real Application Clusters (Oracle RAC)のOracleユーザーです。

Oracle Grid InfrastructureおよびOracle RACの場合は、OPatch、OPatchAutoおよびRUまたは個別パッチを共有の場所にダウンロードして、各ノードにパッチを適用するためにクラスタ内の任意のノードからアクセスできるようにすることをお薦めします。パッチを適用するOracle RACデータベース・ホームおよびOracle Grid Infrastructureホームごとに、それぞれのホーム所有者としてOPatchユーティリティを抽出します。次に例を示します。

ORACLE_HOME/OPatch

OPatchをインストールする正確な手順は、ツールのダウンロードに含まれるreadmeに従ってください。

システム要件の確認

OPatchを起動する前に、必要な環境依存関係があることを確認してください。

$PATH定義に次の実行可能ファイルがあることを確認します。

make
ar
ld
nm

これらの実行可能ファイルの場所は、オペレーティング・システムによって異なります。多くのオペレーティング・システムでは、これらは/usr/ccs/binにあります。パス環境に実行可能ファイルの場所が含まれていることを確認します。次に例を示します。

export PATH=$PATH:/usr/ccs/bin

親トピック: Oracle Real Application ClustersのOPatchAutoメンテナンス

Gridホームでの個別パッチの競合の検出および解決

Oracle Real Application Clustersデータベース・ホームおよびOracle Grid Infrastructure GridホームでOPatchAutoを実行する前に、個別パッチの競合を検出して解決する必要があります。

パッチ検索では、My Oracle Support検索結果ページの「パッチと更新版」タブの「パッチ推奨とパッチ計画」機能を使用することをお薦めします。これらの機能は、Oracleホームにリリース更新(RU)と競合する個別パッチがあるかどうかを判断し、必要な競合解決パッチを取得するための最も高速で簡単な方法です。「パッチ推奨とパッチ計画」機能は、My Oracle Support Configuration Managerと連携して動作します。これらの機能に関する録画されたトレーニング・セッションは、My Oracle Supportにあります。

My Oracle Supportハウツー・ビデオ・トレーニング・シリーズ(ドキュメントID 603505.2)

My Oracle Supportパッチ計画を使用しない場合は、My Oracle Support競合チェッカ・ツールを使用すると、OPatchインベントリをアップロードし、環境に適用するパッチに競合がないかチェックできます。

このツールの使用方法の詳細は、次を参照してください。

OPatchとともにインストールされるパッチ用My Oracle Support競合チェッカ・ツールの使用方法(ドキュメントID 1091294.1)

ツールを使用する手順は、次のとおりです。

My Oracle Supportからパッチをダウンロードします。パッチは、<patchnumber>_<version>_<platform>.zipという形式のzipアーカイブ・ファイル形式のファイルです。<patchnumber>はパッチの8桁の番号、<version>はパッチが提供されるOracleソフトウェアのリリース、<platform>はパッチを適用できるオペレーティング・システム・プラットフォームです。例: p12345678_23.0.0.0.0_Linux-x86-64。
パッチを解凍し、OPatchコマンドopatch prereq CheckConflictAgainstOHWithDetailを使用して、現在インストールされている個別パッチが、これからインストールするパッチと競合しないか確認します。たとえば、パッチがp12345678_23.0.0.0.0_Linux-x86-64の場合:
```
unzip p12345678_23.0.0.0.0_Linux-x86-64.zip
cd p12345678_23.0.0.0.0_Linux-x86-64
opatch prereq CheckConflictAgainstOHWithDetail -ph ./
```
レポートを確認します。競合がある場合、レポートには競合するパッチとスーパーセットであるパッチが示されます。
競合するパッチごとにパッチの競合を解決します。競合解決パッチがすでに使用可能かどうか、および新しい競合解決パッチをリクエストする必要があるかどうか、または競合を無視できるかどうかを判断します。追加の競合解決パッチが必要な場合は、パッチが使用可能になるまで待機してから続行する必要があります。

パッチの競合を解決するには、次のMy Oracle Supportドキュメントを使用します。

データベース・パッチ競合解決(ドキュメントID 1321267.1)

パッチの競合を解決するか、または個別の競合解決パッチを受け取ったら、Oracleソフトウェアの更新を続行できます。

例1-1 Oracle Grid Infrastructureの競合チェックの手動実行

競合チェックを手動で実行するには、インストールされているGridホーム・コンポーネントの個別パッチごとにprereqフラグを指定してopatchを実行する必要があります。たとえば、パッチ名がp12345678_23.0.0.0.0_Linux-x86-64で、解凍されたパッチの場所が/usr/home/oracle/OPatchであるとします。Gridホームのチェックは、次のようになります。

% $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /usr/home/oracle/patch/p12345678_23.0.0.0.0_Linux-x86-64/% ARU_Database_SubPatchTrackingBug %

% $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /usr/home/oracle/patch/p12345678_23.0.0.0.0_Linux-x86-64/% ARU_OCW_SubPatchTrackingBug %

% $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /usr/home/oracle/patch/p12345678_23.0.0.0.0_Linux-x86-64/% ARU_ACFS_SubPatchTrackingBug %

% $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /usr/home/oracle/patch/p12345678_23.0.0.0.0_Linux-x86-64/% ARU_RHP_SubPatchTrackingBug %

% $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /usr/home/oracle/patch/p12345678_23.0.0.0.0_Linux-x86-64/% ARU_TOMCAT_SubPatchTrackingBug %

% $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /usr/home/oracle/patch/p12345678_23.0.0.0.0_Linux-x86-64/% ARU_DBWLM_SubPatchTrackingBug %

ノート:

IBM System zプラットフォーム上のHP-UX ItaniumおよびLinuxの場合、前の例の最後の2つのチェックを行う必要はありません。

OracleまたはGridホームの場合、ソフトウェア・ホーム・ユーザーとして次を実行します。

% $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /usr/home/oracle/patch/p12345678_23.0.0.0.0_Linux-x86-64/% ARU_Database_SubPatchTrackingBug %
% $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /usr/home/oracle/patch/p12345678_23.0.0.0.0_Linux-x86-64/% ARU_OCW_SubPatchTrackingBug %

レポートには、パッチp12345678_23.0.0.0.0_Linux-x86-64と競合する個別パッチと、パッチp12345678_23.0.0.0.0_Linux-x86-64がスーパーセットである個別パッチが示されます。

親トピック: Oracle Real Application ClustersのOPatchAutoメンテナンス

OPatchシステム領域チェックの実行

ORACLE_HOMEファイル・システムで適用するパッチに十分な空き領域が使用可能かどうかを確認します。

アップグレードを確定するため、UPGRADE CATALOGコマンドは2回入力する必要があります。

次のコマンドを入力します。

Oracle Grid Infrastructureホーム(Gridホーム)の場合は、Gridユーザーとして次を実行します。

次の内容でファイル/tmp/patch_list_gihome.txtを作成します(この例では、パッチの場所は/usr/home/oracle/patch/OPatchです)。

% cat /tmp/patch_list_gihome.txt

/usr/home/oracle/patch/OPatch/p12345678_23.0.0.0.0_Linux-x86-64/% ARU_Database_SubPatchTrackingBug %
/usr/home/oracle/patch/OPatch/p12345678_23.0.0.0.0_Linux-x86-64/% ARU_OCW_SubPatchTrackingBug %
/usr/home/oracle/patch/OPatch/p12345678_23.0.0.0.0_Linux-x86-64/% ARU_ACFS_SubPatchTrackingBug %
/usr/home/oracle/patch/OPatch/p12345678_23.0.0.0.0_Linux-x86-64/% ARU_RHP_SubPatchTrackingBug %
/usr/home/oracle/patch/OPatch/p12345678_23.0.0.0.0_Linux-x86-64/% ARU_TOMCAT_SubPatchTrackingBug %
/usr/home/oracle/patch/OPatch/p12345678_23.0.0.0.0_Linux-x86-64/% ARU_DBWLM_SubPatchTrackingBug %

ノート:

IBM System zプラットフォーム上のHP-UX ItaniumおよびLinuxの場合は、前の例の最後の2行をpatch_list_gihome.txtファイルに追加しないでください。

OPatchコマンドを実行して、Gridホームで十分な空き領域が使用可能かどうかを確認します。
```
% $ORACLE_HOME/OPatch/opatch prereq CheckSystemSpace -phBaseFile /tmp/patch_list_gihome.txt
```

Oracleソフトウェア・ホームで、ソフトウェア・ホーム・ユーザーとして次を実行します。
1. パッチを解凍した場所にパッチの内容を含むファイル/tmp/patch_list_dbhome.txtを作成します。たとえば、パッチがp12345678_23.0.0.0.0_Linux-x86-64の場合:
```
% cat /tmp/patch_list_dbhome.txt
<patch-location>/p12345678_23.0.0.0.0_Linux-x86-64/% ARU_Database_SubPatchTrackingBug %
<Patch-location>/p12345678_23.0.0.0.0_Linux-x86-64/% ARU_OCW_SubPatchTrackingBug %
```
2. OPatchコマンドを実行して、Oracleホームで十分な空き領域が使用可能かどうかを確認します。
```
% $ORACLE_HOME/OPatch/opatch prereq CheckSystemSpace -phBaseFile /tmp/patch_list_dbhome.txt
```

コマンド出力には、システム領域の可用性に応じて、合格と不合格のメッセージがレポートされます。

OPatchでPrereq "checkSystemSpace" failedがレポートされた場合は、必要な領域が使用できないため、システム上の領域を解放する必要があります。
OPatchでPrereq "checkSystemSpace" passedがレポートされた場合、処置は必要ありません。パッチのインストールに進みます。

親トピック: Oracle Real Application ClustersのOPatchAutoメンテナンス

OPatchAutoを使用したパッチのインストール・シナリオ

シナリオの手順を使用します。パッチの手順は、Oracle Grid InfrastructureおよびOracle RACデータベース・ホームによって異なります。

次に示すその他の構成については、次を参照してください。

補足Readme - Grid Infrastructureリリース更新12.2.0.1.x / 18c /19c (ドキュメントID 2246888.1):

Gridホームは共有されていません。Oracleホームは共有されていません。Oracle Advanced Cluster File System (ACFS)を使用できます。
Oracle RACデータベース・ホームにパッチを適用します。
Gridホームにのみパッチを適用します。
Oracle RAC One Nodeおよびクラスタウェア管理単一インスタンス・データベースとともにGridホームにパッチを適用します。
Oracle Restartホームにパッチを適用します。
ソフトウェアのみのGridホーム・インストール、またはGridホームの構成前にパッチを適用します。

ケース1: Oracle ACFSを使用しない非共有Oracle RACおよびGridホーム
このシナリオでは、GridホームとOracleホームが共有されておらず、Oracle ACFSファイル・システムが構成されていないOracle RACにパッチを適用します。
ケース2: Oracle ACFSを使用する共有Oracle RACホームおよび非共有Gridホーム
このシナリオでは、Gridホームが共有されておらず、Oracle RACホームが共有されており、Oracle ACFSが使用可能なOracle RACにパッチを適用します。

親トピック: Oracle Real Application ClustersのOPatchAutoメンテナンス

ケース1: Oracle ACFSを使用しない非共有Oracle RACおよびGridホーム

このシナリオでは、GridホームとOracleホームが共有されておらず、Oracle ACFSファイル・システムが構成されていないOracle RACにパッチを適用します。

Oracleソフトウェア・リリースに最新のOPatchAutoversionを使用することをお薦めします。

パッチを適用するシステムがOracle Data Guardスタンバイ・データベースで構成されている場合は、「Data Guardフィジカル・スタンバイ構成でパッチセット、PSUまたはCPUを適用する方法(ドキュメントID 278641.1)」の説明に従って、プライマリ・パッチとフィジカル・スタンバイ・データベースの両方にこのパッチをインストールする必要があります。

パッチを適用するシステムがOracle Real Application Clustersで構成されている場合は、「ローリング・パッチ- RACに対するOPatchサポート」(ドキュメントID 244241.1)の説明に従って、プライマリ・パッチとフィジカル・スタンバイ・データベースの両方にこのパッチをインストールする必要があります。

次の手順を実行します。

rootユーザーとして、次のコマンド構文を使用して、クラスタの各ノードでパッチを実行します。ここで、<GI_HOME>はOracle Grid Infrastructureホーム(Gridホーム)、<UNZIPPED_PATCH_LOCATION>はパッチの解凍場所、<ARU_TrackingBug>はパッチです。
```
# <GI_HOME>/OPatch/opatchauto apply <UNZIPPED_PATCH_LOCATION>/<ARU_TrackingBug> -logLevel FINEST
```
次に例を示します。
```
/u01/app/grid/OPatch/opatchauto apply /usr/home/oracle/patch/p12345678_23.0.0.0.0_Linux-x86-64/ -logLevel FINEST
```

パッチのインストール後、次の手順を実行します。

「変更されたSQLファイルのデータベースへのロード」の説明に従って、変更されたSQLファイルをデータベースにロードします。
「Oracle Recovery Managerカタログのアップグレード」の説明に従って、Oracle Recovery Managerカタログをアップグレードします。
「データベース・リリース更新でのDBMS_OPTIM_BUNDLEを使用したインストール済だが無効化されたバグ修正の管理」(ドキュメントID 2147007.1)の説明に従って、既存のオプティマイザ実行計画を変更する可能性があるバグ修正を確認します

エラーがある場合は、「既知の問題」を参照してください。

親トピック: OPatchAutoを使用したパッチのインストール・シナリオ

ケース2: Oracle ACFSを使用する共有Oracle RACホームおよび非共有Gridホーム

このシナリオでは、Gridホームが共有されておらず、Oracle RACホームが共有されており、Oracle ACFSが使用可能なOracle RACにパッチを適用します。

Oracleソフトウェア・リリースに最新のOPatchAutoversionを使用することをお薦めします。

パッチを適用するシステムがOracle Data Guardスタンバイ・データベースで構成されている場合は、次の説明に従って、プライマリ・パッチとフィジカル・スタンバイ・データベースの両方にこのパッチをインストールする必要があります:

Data Guardフィジカル・スタンバイ構成でパッチセット、PSUまたはCPUを適用する方法(ドキュメントID 278641.1)。

パッチを適用するシステムがOracle Real Application Clustersで構成されている場合は、次の説明に従って、プライマリ・パッチとフィジカル・スタンバイ・データベースの両方にこのパッチをインストールする必要があります:

ローリング・パッチ- RACに対するOPatchサポート(ドキュメントID 244241.1)。

次の手順を実行します。

Oracle RACホームから、次のコマンドを使用して、すべてのノードで実行されているOracle RACデータベースを停止します。ここで、<RAC_HOME>はOracle RACホーム、<db_unique_name>はOracle RACデータベースの一意のデータベース名です。
```
$ <RAC_HOME>/bin/srvctl stop database -d <db-unique-name>
```
最初のノードで、Oracle Advanced Cluster File System (ACFS)をアンマウントします。このタスクの完了方法の詳細は、次を参照してください:

GIパッチの適用中にACFSファイル・システムをマウントまたはアンマウントする方法(ドキュメントID 1494652.1)。
最初のノードで、opatchautoコマンドを使用してGridホームにパッチを適用します。rootユーザーとして、次のコマンドを実行します。
```
# <GI_HOME>/OPatch/opatchauto apply <UNZIPPED_PATCH_LOCATION>/% ARU_TrackingBug % -oh <GI_HOME> -logLevel FINEST
```
「ACFSを使用する前にシステムの再起動をお薦めします」というメッセージが表示された場合は、続行する前にシステムを再起動する必要があります。そうしないと、パッチが適用されていないACFS\ADVM\OKSドライバで実行されます。
最初のノードで、Oracle ACFSファイル・システムを再マウントします。手順については、次を参照してください:

GIパッチの適用中にACFSファイル・システムをマウントまたはアンマウントする方法(ドキュメントID 1494652.1)。
最初のノードで、opatchautoコマンドを使用してOracleホームにパッチを適用します。Oracleホームは共有されているため、この操作はクラスタ全体でOracleホームにパッチを適用します。Universal Storage Managerパッチ(USMのみのパッチ)はOracleホームに適用できないことに注意してください。rootユーザーとして、次のコマンドを実行します。
```
# <RAC_HOME>/OPatch/opatchauto apply <UNZIPPED_PATCH_LOCATION>/% ARU_TrackingBug % -oh <ORACLE_HOME> -logLevel FINEST -nonrolling
```
最初のノードでのみ、srvctl start instanceを使用して、ステップ1で以前に停止したOracleインスタンスを再起動します。
```
$ <ORACLE_HOME>/bin/srvctl start instance –d <db-unique-name> -n <nodename>
```
2番目の(次の)ノードで、Oracle ACFSファイル・システムをアンマウントします。手順については、次を参照してください:

GIパッチの適用中にACFSファイル・システムをマウントまたはアンマウントする方法(ドキュメントID 1494652.1)。
2番目のノードで、opatchautoコマンドを使用してGridホームにパッチを適用します。rootユーザーとして、次のコマンドを実行します。
```
# <GI_HOME>/OPatch/opatchauto apply <UNZIPPED_PATCH_LOCATION>/% ARU_TrackingBug % -oh <GI_HOME> -logLevel FINEST
```
「ACFSを使用する前にシステムの再起動をお薦めします」というメッセージが表示された場合は、続行する前にシステムを再起動する必要があります。システムの再起動に失敗すると、パッチが適用されていないACFS\ADVM\OKSドライバで実行されます。
2番目のノードで、ステップ9でopatchautoコマンドを実行すると、スタックが再起動されます。
2番目のノードで、Oracle ACFSファイル・システムを再マウントします。手順については、次を参照してください:

GIパッチの適用中にACFSファイル・システムをマウントまたはアンマウントする方法(ドキュメントID 1494652.1)。
2番目のノードでのみ、ステップ1で以前に停止したOracleインスタンスを再起動します。Oracleホーム所有者として次を実行します。
```
$ <ORACLE_HOME>/bin/srvctl start instance –d <db-unique-name> -n <nodename>
```
クラスタの残りのすべてのメンバーに対して、ステップ8から13を繰り返します。

必要なパッチをインストールしたら、次の手順を実行します。

「変更されたSQLファイルのデータベースへのロード」の説明に従って、変更されたSQLファイルをデータベースにロードします。
「Oracle Recovery Managerカタログのアップグレード」の説明に従って、Oracle Recovery Managerカタログをアップグレードします。
「データベース・リリース更新でのDBMS_OPTIM_BUNDLEを使用したインストール済だが無効化されたバグ修正の管理」(ドキュメントID 2147007.1)の説明に従って、既存のオプティマイザ実行計画を変更する可能性があるバグ修正を確認します。

エラーがある場合は、「既知の問題」を参照してください

親トピック: OPatchAutoを使用したパッチのインストール・シナリオ

変更されたSQLファイルのデータベースへのロード

OPatchを使用してデータベース・メンテナンスを実行する場合は、datapatchツールを手動で実行して、変更されたSQLファイルをデータベースにロードできるようにする必要があります。

Datapatchは、変更されたSQLファイルをデータベース・レジストリにロードするスクリプトの実行など、RDBMSパッチのパッチ適用後のSQLアクションを完了するパッチ適用ツールです。Datapatchは、データベースの更新後に必要なインストール後のステップを識別し、必要に応じてデータベース内のSQL変更を適用、削除またはロールバックします。新しいバイナリ・パッチのインストール後にパッチ後のアクションを完了するためにDatapatchを自動的にコールし、データベースを再起動するOPatchAutoを使用したメンテナンス操作とは異なり、DatapatchはOPatchの実行後に手動で実行する必要があります。

Datapatchの詳細は、次を参照してください。

Datapatch: データベース12c以降、パッチ後のSQL自動化(ドキュメントID 1585822.1)
Datapatch User Guide (ドキュメントID 2680521.1)

パッチを適用するマルチテナント環境の同じOracleホームで実行されているデータベースに対して、datapatchツールを実行します。この例では、-sanity_checksオプションを指定してdatapatchを実行します。
```
% sqlplus /nolog
SQL> Connect / as sysdba
SQL> startup
SQL> alter pluggable database all open; 
SQL> quit
% cd $ORACLE_HOME/OPatch
% ./datapatch -sanity_checks
% ./datapatch -verbose
```
-sanity_checksオプションを指定してdatapatchを実行することをお薦めします。このオプションを使用して開始すると、datapatchは環境とデータベースの一連のチェックを実行して、パッチ適用に最適な条件かどうかを検証します。結果が画面に表示され、重要度と、実行可能な推奨アクションが示されます。この機能の詳細は、次を参照してください。

Datapatch User Guide (ドキュメントID 2680521.1)

また、マルチテナント環境のすべてのプラガブル・データベース(PDB)でdatapatchを同時に実行することをお薦めします。ただし、個々のプラガブル・データベースでdatapatchを実行することを選択できます。これを行うことを選択した場合、datapatchは、マルチテナント・コンテナ・データベース(CDB)およびオープンされたプラガブル・データベース(PDB)でのみ実行されます。その後、alter pluggable database文を使用して、この時点で更新されていないPDBを更新し、後でdatapatchツールを再度実行して、それらのPDBに対するパッチ適用後のSQLアクションを完了する必要があります。次を参照してください。

マルチテナントの切断/接続のベスト・プラクティス(ドキュメントID 1935365.1)

datapatchユーティリティは、適用スクリプトを実行して、変更されたSQLファイルをデータベースにロードします。dba_registry_sqlpatchビューにエントリが追加され、パッチの適用が記録されます。
dba_registry_sqlpatchビューで、APPLYの「ステータス」がSUCCESSであることを確認します。その他のステータスについては、次を参照してください。

トラブルシューティング・アシスタント:12c Datapatchの問題(ドキュメントID 2335899.2)
datapatchの完了後、出力をチェックして、エラーがレポートされたかどうかを確認します。datapatchの出力には、インストールされているパッチのログ・ファイルの場所が含まれます。その特定のdatapatchプロセスの関連ログ・ファイルはすべて、sqlpatch_invocation.logと同じディレクトリにあります。出力の最初の行にある「Log file for this invocation:」を確認してください。

関連トピック

PDBに異なるコンポーネントがある場合、datapatchは何を行いますか。

親トピック: Oracle Real Application ClustersのOPatchAutoメンテナンス

Oracle Recovery Managerカタログのアップグレード

Oracle Recovery Managerを使用している場合は、カタログをアップグレードする必要があります。

アップグレードを確定するため、UPGRADE CATALOGコマンドは2回入力する必要があります。

次のコマンドを入力します。

$ rman catalog username/password@alias
RMAN> UPGRADE CATALOG;
RMAN> UPGRADE CATALOG;
RMAN> EXIT;

親トピック: Oracle Real Application ClustersのOPatchAutoメンテナンス

既知の問題

OPatchの実行中に発生した問題が既知の問題であるかどうかを確認する方法を学習します。

OPatchの既知の問題の詳細は、次を参照してください。

OPatchのプライマリ・ノート(ドキュメントID 293369.1)

インストールしたリリース更新(RU)またはパッチ・バージョンのリリース後に記載された問題については、インストールしたリリース更新(RU)またはパッチ・バージョンのREADMEを確認してください。

親トピック: Oracle Real Application ClustersのOPatchAutoメンテナンス

ドキュメントのアクセシビリティについて

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracleサポート・サービスへのアクセス

お客様のOracleサポート・サービスへのアクセスおよびご利用は、該当するサービスの注文時に指定された利用条件に従うものとします。

親トピック: Oracle Real Application ClustersのOPatchAutoメンテナンス

タイトルと著作権情報

Oracle Database OPatchAutoでのOracle Real Application Clustersのメンテナンス, リリース23aiおよび以降のリリース

G17379-01

Oracle and/or its affiliates.