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

OPatchAutoを使用して、Oracle Data GuardとともにデプロイされたOracle Databaseを更新できます。

パッチ適用プロセスを簡略化するために、Oracleでは、Oracle Data Guardとともにデプロイされたデータベースに対してOracle Fleet Patching and Provisioningを使用することをお薦めします。Oracle Fleet Patching and Provisioningを使用しない場合、DBCAも使用可能な適切な選択肢です。かわりに、OPatchAutoを使用することもできます。

ノート:

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

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

OPatchおよびOPatchAutoを使用するためのチェックおよび前提条件

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

ノート:

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

「How to Perform ORACLE_HOME Backup?」(ドキュメント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 Data GuardのOPatchAutoメンテナンス」

グリッド・ホームでの個別パッチの競合の検出および解決

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

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

「My Oracle Support How-to Video Training Series」(ドキュメントID 603505.2)

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

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

「How to Use the My Oracle Support Conflict Checker Tool for Patches Installed with OPatch」(ドキュメント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の競合チェックの手動実行

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

% $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プラットフォーム上のLinuxおよびHP-UX Itaniumの場合、前の例の最後の2つのチェックを行う必要はありません。

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

% $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 Data GuardのOPatchAutoメンテナンス」

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

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

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

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

Oracle Grid Infrastructureホーム(グリッド・ホーム)の場合は、グリッド・ユーザーとして次の手順を実行します:

次の内容でファイル/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プラットフォーム上のLinuxおよびHP-UX Itaniumの場合、前の例の最後の2行をpatch_list_gihome.txtファイルに追加しないでください。

OPatchコマンドを実行して、グリッド・ホームに十分な空き領域があるかどうかを確認します:
```
% $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
```

コマンド出力に、システム領域の可用性に応じてfailedまたはpassedのメッセージが表示されます:

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

親トピック: 「Oracle Data GuardのOPatchAutoメンテナンス」

Oracle Data Guardを使用したデータベースでのOPatchAutoによるソフトウェアの更新

パッチの競合が解決されたら、OPatchAutoを使用してソフトウェアの手動更新を続行できます。

Oracleでは、Oracleソフトウェア・リリースに最新のOPatchおよびOPatchAutoバージョンを使用することをお薦めしています。

次の重要な制限事項に注意してください:

データベースRUは、OPatchを使用してData Guardスタンバイに適用する必要があります。
パッチの適用後、datapatchを実行して、Data Guardスタンバイ環境のデータベースRUにパッチ後SQLアクションを適用しないでください。datapatchをプライマリではなくスタンバイで実行すると、datapatchによるSYS.DBMS_QOPATCHインタフェースへのコールでエラーが発生します。このエラーの詳細は、My Oracle Supportドキュメント1599479.1を参照してください。
Datapatchの実行が必要になるのはプライマリ・データベースのみです。また、すべてのデータベース(Data Guardプライマリおよびスタンバイ)にパッチが適用された後にのみ、データベースRUのパッチ・デプロイメントが設定用に完了した状態で実行する必要があります。

Oracle Data GuardとともにデプロイされたOracle Database環境で、次のステップに従います:

プライマリ・データベースのREDO転送を停止します。

Data Guard Brokerが設定されている場合は、DGMGRLを使用する必要があります。例:

DGMGRL> connect /
Connected.
DGMGRL> show database verbose plb_prm
Database
Name: plb_prm
Role: PRIMARY
Enabled: YES
Intended State: ONLINE
Instance(s):
plb
Properties:
InitialConnectIdentifier = 'plb_prm_dgmgrl'
..
.
Current status for "plb_prm":
SUCCESS
 
DGMGRL> edit database plb_prm set state='LOG-TRANSPORT-OFF';
Succeeded.

Data Guard Brokerを使用していない場合は、SQL alter system setを使用します。例:
```
SQL> alter system set log_archive_dest_state_X=defer scope=both sid='*'
```

スタンバイ・データベース、すべてのリスナー、およびOracleホーム・スタンバイ・サイトに関連付けられているすべてのプロセスを停止します。例:

$ lsnrctl stop lsnrplb

LSNRCTL for Linux: Version 10.2.0.4.0 - Production on 04-FEB-2010 08:41:29
Copyright (c) 1991, 2007, Oracle. All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=<host>)(PORT=1666)))
The command completed successfully

$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.4.0 - Production on Thu Feb 4 08:42:02 2010
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> shutdown immediate

ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.

現在のディレクトリをパッチが存在するディレクトリに設定し、次のコマンドを入力してOPatchAutoユーティリティを実行します。ここで、<patchnumber>はパッチの8桁の番号、<version>はパッチが提供されるOracleソフトウェアのリリース、<platform>はパッチを適用できるオペレーティング・システム・プラットフォームです。
```
unzip p<patchnumber>_<version>_<platform>.zip
cd p<patchnumber>_<version>_<platform>
opatch apply
```
例:
```
unzip p12345678_23.0.0.0.0_Linux-x86-64.zip
cd p12345678_23.0.0.0.0_Linux-x86-64
opatch apply
```
パッチの更新が正常に終了するのを待ちます。パッチの更新が完了したら、スタンバイ・サイトを起動してリスナーのみをマウントおよび再起動します。管理リカバリは再起動しないでください。

ノート:
スタンバイがOracle RAC環境の場合は、すべてのノードでパッチ適用を繰り返します。

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

ノート:
スタンバイOracleホームには、アップグレード後変更を適用しないでください。これらの変更は、後でスタンバイRDBMS自体に対してREDO転送(catchpatch.sqlなど)を実行して適用する必要があります。
プライマリ・サイトを起動し、スタンバイへのログ送信を再度有効にします。
スタンバイ・サイトで、MRP (管理リカバリ)を起動します。プライマリ・サイトに実装されたRDBMS変更が、catpatch、catbundleおよびcatcpuを介してスタンバイに適用されました。

注意:
このステップは、スタンバイ・データベースでOracle Databaseバイナリをアップグレードした直後に実行する必要があります。このステップにより、データ・ディクショナリ(CATPROC)のバージョンがデータベース・バイナリのバージョンと一致することが保証されます。データ・ディクショナリが一致しない場合(たとえば、スタンバイ・データベースを最初にアップグレードし、プライマリをアップグレードする前にスタンバイでロール変更を実行した場合)、重大な問題に陥る可能性があります。詳細は、「Mixed Oracle Version support with Data Guard Redo Transport Services」(ドキュメントID 785347.1)を参照してください。
現在のディレクトリをパッチ・ストレージが存在するディレクトリに設定し、次のコマンドを入力してOPatchユーティリティを実行します。ここで、<patchnumber>はパッチの8桁の番号、<version>はパッチが提供されるOracleソフトウェアのリリース、<platform>はパッチを適用できるオペレーティング・システム・プラットフォームです。
```
unzip p<patchnumber>_<version>_<platform>.zip
cd p<patchnumber>_<version>_<platform>
opatch apply
```
例:
```
unzip p12345678_23.0.0.0.0_Linux-x86-64.zip
cd p12345678_23.0.0.0.0_Linux-x86-64
opatch apply
```
パッチの更新が正常に終了するのを待ちます。

エラーがある場合は、「既知の問題」を参照してください。
Data Guard BrokerをOracle Data Guardとともに使用している場合、Data Guard BrokerでMRPが自動的に起動されないようにするため、状態をstate=APPLY-OFFに変更します。例:
```
DGMGRL> EDIT DATABASE 'plb_prm' SET STATE='APPLY-OFF';
```

プライマリ・データベース、すべてのリスナー、およびOracleホーム・スタンバイ・サイトに関連付けられているすべてのプロセスを停止します。例:

$ lsnrctl stop lsnrplb

LSNRCTL for Linux: Version 10.2.0.4.0 - Production on 04-FEB-2010 08:41:29
Copyright (c) 1991, 2007, Oracle. All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=<host>)(PORT=1666)))
The command completed successfully

$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.4.0 - Production on Thu Feb 4 08:42:02 2010
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> shutdown immediate

ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.

Oracle RACプライマリの場合:

$ srvctl stop listener -n <host> -l lsnrplb_<host>
$ srvctl stop listener -n <host> -l lsnrplb_<host>
$ srvctl stop database -d plb

パッチをプライマリ・データベースのパッチ・ストレージの場所に解凍します。

現在のディレクトリをパッチが存在するディレクトリに設定し、次のコマンドを入力してOPatchユーティリティを実行します。ここで、<patchnumber>はパッチの8桁の番号、<version>はパッチが提供されるOracleソフトウェアのリリース、<platform>はパッチを適用できるオペレーティング・システム・プラットフォームです。
```
unzip p<patchnumber>_<version>_<platform>.zip
cd p<patchnumber>_<version>_<platform>
opatch apply
```
例:
```
unzip p12345678_23.0.0.0.0_Linux-x86-64.zip
cd p12345678_23.0.0.0.0_Linux-x86-64
opatch apply
```
パッチの更新が正常に終了するのを待ちます。

エラーがある場合は、「既知の問題」を参照してください。
RDBMSおよびディクショナリ・オブジェクトをアップグレードしてパッチを適用します。

Oracle RAC環境では、このタスクは1つのインスタンスからのみ実行し、他のインスタンスは停止して非稼働の状態にしておきます。
パッチが正常にインストールされた後、パッチ競合をチェックして取得したパッチ競合解決個別パッチ(ある場合)を適用します。
プライマリ・サイトでOracle Data Guard環境を再確立するには、リスナーを起動します。

Oracle RAC環境では、プライマリ・サイトの1つのインスタンスでのみOracle Data Guardを再確立し、他のクラスタ・インスタンスは停止して非稼働の状態にしておきます。
プライマリ・サイトのサービスを強制的にリスナーに登録します:
```
$ sqlplus / as sysdba
SQL> alter system register;
```
スタンバイでOracle Data Guardを再度有効にします。
1. 単一インスタンスのOracle Data Guardデプロイメントでは、制限付きセッションを無効にしてエンド・ユーザー接続を許可します。
```
SQL> alter system disable restricted session;
```
2. Oracle RAC Oracle Data Guardデプロイメントでは、プライマリ・サイトとそのすべてのインスタンスを再起動します:
```
$ srvctl stop database -d plb
$ srvctl start database -d plb
```
  データベースの接続に使用される追加のOracle RACサービスがある場合は、それらのサービスを再起動します。例:
```
$ srvctl start service -d plb
```
スタンバイ・サイトへのログ送信を再度有効にします。

スタンバイへのログ送信を再度有効にすると、catupgradeの実行によってRDBMSが変更されます。catbundleおよびcatcpuをスタンバイに適用できます。
1. Data Guard Brokerを使用している場合は、接続して状態をstate=ONLINEに更新します。例:
```
DGMGRL> edit database plb_prm set state='ONLINE';
```

必要なパッチをインストールしたら、次のステップを実行します:

「変更されたSQLファイルのデータベースへのロード」の説明に従って、変更されたSQLファイルをデータベースにロードします。
「Oracle Recovery Managerカタログのアップグレード」の説明に従って、Oracle Recovery Managerカタログをアップグレードします。
「Managing "installed but disabled" bug fixes in Database Release Updates using DBMS_OPTIM_BUNDLE」(ドキュメントID 2147007.1)の説明に従って、既存のオプティマイザ実行計画を変更する可能性があるバグ修正を確認します。

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

親トピック: 「Oracle Data GuardのOPatchAutoメンテナンス」

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

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

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

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

「Datapatch: Database 12c or later Post Patch SQL Automation」(ドキュメント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)

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

「Multitenant Unplug/Plug Best Practices」(ドキュメントID 1935365.1)

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

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

関連トピック

「What does datapatch do when you have different components in PDBs?」

親トピック: 「Oracle Data GuardのOPatchAutoメンテナンス」

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

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

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

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

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

親トピック: 「Oracle Data GuardのOPatchAutoメンテナンス」

既知の問題

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

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

「Primary Note For OPatch」(ドキュメントID 293369.1)

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

親トピック: 「Oracle Data GuardのOPatchAutoメンテナンス」

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

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

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

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

親トピック: 「Oracle Data GuardのOPatchAutoメンテナンス」

タイトルと著作権情報

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

G17382-01

Oracle and/or its affiliates.