Oracle Identity Manager単一ノード環境のアップグレード

Oracle Identity Managerのアップグレード前のタスクの完了

Oracle Identity Managerをアップグレードする前に、この項で説明しているアップグレード前のタスクを完了します。

メモリー設定の確認
Oracle Identity Managerに関するメモリーの問題を回避するため、要件に従ってメモリー設定が更新されていることを確認します。
SSL有効設定のための非SSLポートのオープン
SSL有効設定と非SSL無効設定がある場合、Oracle Identity Managerのアップグレードを続行する前に、データベースのための非SSLポートをオープンする必要があります。
一時フォルダのクリーニング
すべてのOracle Identity Governanceホスト・マシンの/tmpをクリーニングします。
metadata.marファイルの手動バックアップ

メモリー設定の確認

Oracle Identity Managerに関するメモリーの問題を回避するため、要件に従ってメモリー設定が更新されていることを確認します。

Linuxで、rootユーザーとして次を実行します:

/etc/security/limits.confまたは/etc/security/limits.dファイルの次のパラメータに対して、指定した値が設定されていることを確認します:
```
FUSION_USER_ACCOUNT soft nofile 32767
FUSION_USER_ACCOUNT hard nofile 327679
```
/etc/ssh/sshd_configファイルで、UsePAMがYesに設定されていることを確認します。
sshdを再起動します。
maxprocの制限を確認し、必要に応じて16384以上に増やします。制限を増やすと、メモリーの問題が発生しなくなります。
次のコマンドを使用して、制限をチェックします:

ulimit -u

16384未満の場合は、次のコマンドを使用して、開いているファイルの制限を増やします:

ulimit -u 16384

ノート:
コマンドulimit -uを再発行すると、制限が正しく設定されたことを確認できます。
再起動時に設定が保持されるようにするには、/etc/security/limits.confファイルまたは /etc/security/limits.dファイルに次の行を追加します:
```
oracle hard nproc 16384
```
ここで、oracleはインストール・ユーザーです。
システムをログアウト(または再起動)し、再度ログインします。

SSL有効設定のための非SSLポートのオープン

SSL有効設定と非SSL無効設定がある場合、Oracle Identity Managerのアップグレードを続行する前に、データベースのための非SSLポートをオープンする必要があります。

データベース・リスナーが、Upgrade Assistantにパラメータとして指定したデータベース・サーバーのTCPポートと同じTCPポートでリスニングしていることを確認します。詳細は、「Oracle Identity Governance DBのSSLの有効化」を参照してください。

一時フォルダのクリーニング

すべてのOracle Identity Governanceホスト・マシンの/tmpをクリーニングします。

/tmpディレクトリはJVM java.io.tmpdirプロパティに対して設定されているため、/tmpフォルダ内の不要なファイルがOIGのアップグレード・プロセスに干渉し、結果としてMDSが破損する可能性があります。

`metadata.mar`ファイルの手動バックアップ

既存のOracleホームに12c (12.2.1.4.0)バイナリをインストールしたら、アップグレードの前に12c (12.2.1.4.0)_ORACLE_HOME>/idm/server/apps/oim.ear/metadata.marファイルのバックアップを取得します。

サーバーとプロセスの停止

Upgrade Assistantを実行してスキーマと構成をアップグレードする前に、すべてのアップグレード前のプロセスとサーバー(管理サーバー、ノード・マネージャ(ノード・マネージャを構成した場合)および管理対象サーバーを含む)を停止する必要があります。

Oracle Fusion Middleware環境は、Oracle WebLogic Serverドメイン、管理サーバー、複数の管理対象サーバー、Javaコンポーネント、アイデンティティ管理コンポーネントなどのシステム・コンポーネント、およびメタデータのリポジトリに使用されるデータベースで構成できます。コンポーネントは相互に依存していることがあるため、適切な順序で停止する必要があります。

ノート:

この項の手順では、WLSTコマンドライン・ユーティリティまたはスクリプトを使用して、既存のアップグレード前のサーバーとプロセスを停止する方法について説明します。Oracle Fusion Middleware ControlおよびOracle WebLogic Server管理コンソールを使用することもできます。「管理サーバー、管理対象サーバーおよびノード・マネージャの起動と停止」を参照してください。
データベースを除く、デプロイメント内のすべてのサーバーを停止します。アップグレード・プロセス中、データベースが稼働している必要があります。

アップグレード前のFusion Middleware環境を停止するには、アップグレード前のドメインに移動して次のステップを実行します。

ステップ1: 管理対象サーバーを停止する

管理対象サーバーの起動方法に応じて、次のいずれかの方法に従ってWebLogic管理対象サーバーを停止します:

方法1: ノード・マネージャによって管理されていないWebLogic Server管理対象サーバーを停止するには:

(UNIX) DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url
(Windows) DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url

プロンプトが表示されたらユーザー名とパスワードを入力します。

方法2: Weblogicコンソールを使用してWebLogic Server管理対象サーバーを停止するには:

weblogic管理者としてWeblogicコンソールにログインします。
「サーバー」 > 「制御」タブに移動します。
必要な管理対象サーバーを選択します。
「停止」をクリックします。

方法3: ノード・マネージャを使用してWebLogic Server管理対象サーバーを停止するには、次のコマンドを実行します:

wls:/offline>nmConnect('nodemanager_username','nodemanager_password',
            'AdminServerHostName','5556','domain_name',
            'DOMAIN_HOME','nodemanager_type')

wls:/offline>nmKill('ManagedServerName')

ステップ2: 管理サーバーを停止する

管理サーバーを停止するときに、管理サーバーで稼働しているプロセス(WebLogic Server管理コンソールやFusion Middleware Controlなど)も停止します。

次のいずれかの方法に従って、管理サーバーを停止します:

方法1: ノード・マネージャによって管理されていない管理サーバーを停止するには:

(UNIX) DOMAIN_HOME/bin/stopWebLogic.sh
(Windows) DOMAIN_HOME\bin\stopWebLogic.cmd

プロンプトが表示されたら、管理サーバーのユーザー名とパスワード、およびURLを入力します。

方法2: Weblogicコンソールを使用して管理サーバーを停止するには:

weblogic管理者としてWeblogicコンソールにログインします。
「サーバー」 > 「制御」タブに移動します。
必要な管理サーバーを選択します。
「停止」をクリックします。

方法3: ノード・マネージャを使用してWebLogic Server管理対象サーバーを停止するには、次のコマンドを実行します:

wls:/offline>nmConnect('nodemanager_username','nodemanager_password',
            'AdminServerHostName','5556','domain_name',
            'DOMAIN_HOME','nodemanager_type')

wls:/offline>nmKill('AdminServer')

ステップ4: ノード・マネージャを停止する

ノード・マネージャを停止するには、次のコマンドを実行します:

<DOMAIN_HOME>/bin/stopNodeManager.sh

OIMHOST上の12c (12.2.1.3.0) Oracleホーム・フォルダのバックアップ

OIMHOST上の12c (12.2.1.3.0) Oracleホームをバックアップします。

バックアップとして、OIMHOST上で12.2.1.3.0 Oracleホーム・フォルダをコピーして名前を変更します。

たとえば:

/u01/app/fmw/ORACLE_HOMEを/u01/app/fmw/ORACLE_HOME_oldにします

ノート:

カスタム構成は必ずバックアップしてください。これらの構成は、アップグレード後にリストアします。

ソフトウェアのアンインストール

この項の手順に従ってアンインストール・ウィザードを起動し、ソフトウェアを削除します。

サイレント(コマンドライン)・モードの製品のアンインストールを実行する場合は、『Oracle Universal Installerによるソフトウェアのインストール』のサイレント・アンインストールのためのOracle Universal Installerの実行に関する項を参照してください。

「アンインストール・ウィザード」の起動

アンインストール・ウィザードを起動します。

次のディレクトリを変更します。
(UNIX) ORACLE_HOME/oui/bin

(Windows) ORACLE_HOME\oui\bin
次のコマンドを入力します。
(UNIX) ./deinstall.sh

(Windows) deinstall.cmd

親トピック: ソフトウェアのアンインストール

アンインストールする製品の選択

Oracleホームには複数の製品が存在するため、適切な製品をアンインストールするようにしてください。

アンインストール・ウィザードの実行後、「アンインストールする配布」画面が開きます。

ドロップダウン・メニューからOracle Fusion Middleware 12c (12.2.1.4.0) Identity and Access Management製品を選択し、「アンインストール」をクリックします。

ノート:

アンインストール・ウィザードに「アンインストールする配布」画面が表示されるのは、ウィザードを開始したOracleホームで複数の製品ディストリビューションが検出された場合のみです。Oracle Fusion Middleware 12c (12.2.1.4.0) Identity and Access Management製品ディストリビューションのみが使用可能な場合、アンインストール・ウィザードには「アンインストール・サマリー」画面が表示されます。

ノート:

「Weblogic Server for FMW 12.2.1.3.0」を選択しないでください。

アンインストール・プログラムには、「アンインストール・ウィザード画面のナビゲート」に示されている画面が表示されます。

ノート:

OIMまたはOAMソフトウェアをアンインストールした後、アンインストール・ウィザードを再度実行することにより、Oracle Fusion Middleware Infrastructureをアンインストールできます。Infrastructureが削除されると、Infrastructureを使用する他の製品が機能しなくなるため、削除する前に、そのような製品がないことを確認してください。Oracle Fusion Middleware Infrastructureに依存するソフトウェアが他にない場合は、「アンインストールする配布」画面は表示されません。『Oracle Fusion Middleware Infrastructureのインストールと構成』のOracle Fusion Middleware Infrastructureのアンインストールに関する項を参照してください

親トピック: ソフトウェアのアンインストール

「アンインストール・ウィザード」画面のナビゲート

アンインストール・ウィザードには、ソフトウェアの削除を確認する一連の画面が表示されます。

次の表に示した画面についてのヘルプが必要な場合には、画面上の「ヘルプ」をクリックしてください。

表 3-2 アンインストール・ウィザード画面および説明

画面	説明
ようこそ	製品のアンインストール・ウィザードに案内します。
アンインストールのサマリー	アンインストールされるOracleホーム・ディレクトリとその内容を示します。これが正しいディレクトリであることを確認してください。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を入力します。後でレスポンス・ファイルを使用して、サイレント(コマンドライン)・モードで製品をアンインストールできます。『Oracle Universal Installerによるソフトウェアのインストール』のサイレント・アンインストール用のOracle Universal Installerの実行に関する項を参照してください。「アンインストール」, をクリックしてソフトウェアの削除を開始します。
アンインストールの進行状況	アンインストールの進行状況を表示します。
アンインストールの完了	アンインストールが完了すると表示されます。この画面の情報を確認してから、「終了」をクリックしてアンインストール・ウィザードを閉じます。

ノート:

FMW 12.2.1.3.0用のWebLogic Serverをアンインストールするための、これらのステップを繰り返します。
Oracleバイナリを同じ場所に再インストールすることになります。ORACLE_HOMEの場所に残っているファイルがある場合、インストールは失敗します。インストールに失敗した場合は、新しいバイナリをインストールする前に、ORACLE_HOMEの場所から残っているファイルを手動で削除します。
インストールでuser_projectsドメイン・ホーム情報がORACLE_HOMEディレクトリにある場合: user_projectsディレクトリとdomain-registry.xmlファイルを除き、OIM_HOMEの下のすべてのファイルとディレクトリを削除します。
インストールでuser_projectsドメイン・ホーム情報がORACLE_HOME以外のディレクトリにある場合: domain-registry.xmlファイルを除き、OIM_HOMEの下にあるすべてのファイルとディレクトリを削除します。

親トピック: ソフトウェアのアンインストール

製品ディストリビューションのインストール

アップグレードの開始前に、Oracle Fusion Middleware Infrastructure、Oracle SOA SuiteおよびOracle Identity Manager 12c (12.2.1.4.0)のディストリビューションをターゲット・システムにダウンロードし、次のコマンドを使用して既存の12c (12.2.1.3.0) Oracleホームにインストールします。

また、Java Development Kit (JDK) 1.8.0_211以降がインストールされていることを確認します。

ノート:

アップグレードにInfrastructureが必要な場合は、他のFusion Middleware製品をインストールする前に、最初にOracle Fusion Middlewareディストリビューションをインストールする必要があります。

前述の製品のインストールでは、クイックスタート・インストーラ(fmw_12.2.1.4.0_idmquickstart.jar)を使用する簡易インストール・プロセスを使用することをお薦めします。クイック・スタート・インストーラでは、Infrastructure、Oracle SOA SuiteおよびOracle Identity Manager 12c (12.2.1.4.0)が一度にインストールされます。

ノート:

冗長なバイナリの場所を使用している場合は、必ず冗長な場所それぞれにソフトウェアをインストールしてください。

『Oracle Identity and Access Managementのインストールおよび構成』のクイックスタート・インストーラを使用したOracle Identity Governanceのインストールに関する項を参照してください。

もう1つのオプションとして、必要な製品ディストリビューション(Infrastructure、Oracle SOA SuiteおよびOracle Identity Manager 12c (12.2.1.4.0))を個別にインストールすることもできます。これを行うには、次のステップを実行します:

ターゲット・システムにサインインします。
Oracle Technology NetworkまたはOracle Software Delivery Cloudから次のものをターゲット・システムにダウンロードします。
- Oracle Fusion Middleware Infrastructureをまだインストールしていない場合は、Oracle Fusion Middleware Infrastructure (fmw_12.2.1.4.0_infrastructure.jar)をダウンロードします
- Oracle SOA Suite (fmw_12.2.1.4.0_soa.jar)
- OTNから、またはOracle Software Delivery CloudのOracle Fusion Middleware 12c (12.2.1.4.0) Identity and Access Managementからの、Oracle Identity and Access Management 12cPS4 (fmw_12.2.1.4.0_idm.jarが含まれるfmw_12.2.1.4.0_idm_Disk1_1of1.zip)。
ノート:
ORACLE_HOMEフォルダが存在し、そこにファイルまたはフォルダが含まれていないことを確認します。ORACLE_HOMEフォルダにファイルまたはフォルダが残っている場合は、それらを削除します。
12c (12.2.1.4.0)製品のディストリビューションをダウンロードしたディレクトリに移動します。
Oracle Fusion Middleware Infrastructure (fmw_12.2.1.4.0_infrastructure.jar)がすでにインストールされている場合は、ステップ15に進みます。
新しいJDKを指すOracle Fusion Middleware Infrastructureのインストール・プログラムを起動します。新しいJDKの場所を指すと、アップグレード・プロセスの後半でステップをスキップできます。
次のコマンドを実行します:
- (UNIX) NEW_JDK_HOME/bin/java -jar fmw_12.2.1.4.0_infrastructure.jar
- (Windows) NEW_JDK_HOME\bin\java -jar fmw_12.2.1.4.0_infrastructure.jar
ノート:

user_projectsディレクトリおよびdomain-registry.xmlファイルがORACLE_HOMEに残っている場合は、インストールの失敗を回避するために-novalidationフラグを使用する必要があります。
次に失敗メッセージの例を示します:
```
Verifying data......
[VALIDATION] [ERROR]:INST-07319: Validation of Oracle Home location failed. The location specified already exists and is a nonempty directory and not a valid Oracle Home
[VALIDATION] [SUGGESTION]:Provide an empty or nonexistent directory location, or a valid existing Oracle Home
installation Failed. Exiting installation due to data validation failure.
he Oracle Universal Installer failed. Exiting.
```
UNIXオペレーティング・システムでは、このホストにOracle製品を初めてインストールする場合に、「インストール・インベントリの設定」画面が表示されます。
中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システム・グループ名に対して中央インベントリの場所への書込み権限が付与されていることを確認し、「次」をクリックします。

ノート:
「インストール・インベントリの設定」画面は、Windowsオペレーティング・システムでは表示されません。
「ようこそ」画面で、情報をレビューしてすべての前提条件を満たしていることを確認します。「次」をクリックします。
「自動更新」画面で、オプションを選択します。
- この時点でソフトウェアの更新をシステムで確認しないようにする場合は、「自動更新をスキップ」を選択します。
- パッチ・ファイルをダウンロードした場合は、「ディレクトリからパッチを選択」を選択して、ローカル・ディレクトリに移動します。
- My Oracle Supportアカウントを持っている場合にソフトウェアの更新を自動でダウンロードするには、「My Oracle Supportで更新を検索」を選択します。Oracle Supportの資格証明を入力して、「検索」をクリックします。インストーラがMy Oracle Supportにアクセスするようにプロキシ・サーバーを構成するには、「プロキシ設定」をクリックします。「接続のテスト」をクリックして接続をテストします。
「次」をクリックします。
「インストールの場所」画面で、既存の12c (12.2.1.3.0) Oracleホーム・ディレクトリの場所を指定し、「次へ」をクリックします。
たとえば: 12c (12.2.1.3.0) Oracle_homeが/u01/app/fmwにある場合は、まず12c (12.2.1.3.0)をアンインストールし、ディレクトリをクリーン・アップして、12c (12.2.1.4.0)を/u01/app/fmwにインストールします。

Oracle Fusion Middlewareディレクトリ構造の詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareのインストールのプランニング』のインストールおよび構成のためのディレクトリの理解に関する項を参照してください。
「インストール・タイプ」画面で、「Fusion Middlewareインフラストラクチャ」を選択します。
「次」をクリックします。
「前提条件チェック」画面では、ホスト・コンピュータを分析して、特定のオペレーティング・システムの前提条件を満たしているか確認します。
確認されたタスクのリストを表示するには、「正常なタスクの表示」を選択します。ログの詳細を表示するには、「ログの表示」を選択します。前提条件のチェックが失敗すると、エラー・メッセージが画面の下方に表示されます。エラーを修正し、「再実行」をクリックして再試行します。エラー・メッセージや警告メッセージを無視してインストールを続けるには、「スキップ」をクリックします(非推奨)。
「インストールの概要」画面で、選択したインストール・オプションを確認します。
これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を入力します。レスポンス・ファイルには、入力したすべての情報が収集して格納され、後で(コマンドラインから)サイレント・インストールを実行するために使用できます。
「インストール」をクリックしてインストールを開始します。
「インストールの進行状況」画面で、プログレス・バーが100%完了になったら、「終了」をクリックしてインストーラを閉じるか、「次へ」をクリックしてサマリーを表示します。
「インストール完了」画面に、インストールの場所とインストールされた機能セットが表示されます。情報を確認し、「終了」をクリックしてインストーラを閉じます。
Oracle Fusion Middleware Infrastructureのインストール後に、次のコマンドを入力して、製品ディストリビューションのインストーラを起動し、前述のステップを繰り返してインストーラの各画面を移動します。
Oracle SOA Suite 12c (12.2.1.4.0)をインストールする場合は、次のインストーラを実行します。

ノート:
「インストール・タイプ」画面で、Oracle SOA Suiteの場合は「Oracle SOA Suite」を選択します。
- (UNIX) NEW_JDK_HOME/bin/java -jar fmw_12.2.1.4.0_soa.jar
- (Windows) NEW_JDK_HOME\bin\java -jar fmw_12.2.1.4.0_soa.jar
Oracle Identity Manager 12c (12.2.1.4.0)をインストールする場合は、次のインストーラを実行します:

ノート:
「インストール・タイプ」画面で、Oracle Identity Managerの場合は、同じ場所に配置されたOracle Identity and Access Managerを選択します。
- (UNIX) NEW_JDK_HOME/bin/java -jar fmw_12.2.1.4.0_idm.jar
- (Windows) NEW_JDK_HOME\bin\java -jar fmw_12.2.1.4.0_idm.jar
ノート:
opatchツールを使用して、Oracleサポートから最新の推奨バンドル・パッチを適用します。ドキュメントID 2657920.1を参照し、アップグレード・プロセスの完了後にパッチ適用後のステップに従います。これにより、アップグレード・プロセスの最新の既知の修正があれば提供されます。
既存の12c (12.2.1.3.0) DOMAIN_HOMEが12c (12.2.1.3.0)のOracleホーム・ディレクトリ内に存在する場合は、次のようにします:
1. 12c (12.2.1.3.0)のOracleホームのバックアップ場所に移動します。
  たとえば: /u01/app/fmw/ORACLE_HOME_old/
2. user_projectsフォルダをコピーします。
3. 新しくインストールされた12c (12.2.1.4.0)のOracleホームの場所に移動します。
  たとえば: /u01/app/fmw/ORACLE_HOME/
4. コピーしたuser_projectsフォルダを貼り付けます。
OPatchを使用して、最新のスタック・パッチ・バンドル(SPB)を12c (12.2.1.4)バイナリに適用します。ドキュメントID 2657920.1を参照してください。

Oracle Identity Manager 12c (12.2.1.4.0)のインストールの詳細は、『Oracle Identity and Access Managementのインストールおよび構成』のOracle Identity and Access Managementソフトウェアのインストールに関する項を参照してください。

JDKの場所の更新

12c (12.2.1.3.0)から12c (12.2.1.4.0)へのアップグレードの際に、再構成ウィザードは使用されません。そのため、ドメイン・ホーム内で最新のJDKバージョンが自動更新されることはありません。

12c (12.2.1.4.0)にアップグレードした後、ドメイン・ホームで現在のJDKへの参照を検索し、それらのインスタンスを新しいJDKの場所で置換する必要があります。

ドメイン・ホーム内の現在のJDKへの参照を手動で検索し、これらのインスタンスを新しいJDKの場所で置換する必要があります。

次のステップを実行して、JDKインスタンスを手動で検索して置換します:

ディレクトリをDOMAIN_HOMEに変更します。
grepコマンドを使用して、DOMAIN_HOMEで古いJDKバージョンを含むファイルを検索します。
次の例では、.logで終わるログ、.outファイル、.txtファイルおよび.csvファイルを除外しています。

$ grep -rl <OLD_JDK_VERSION> * | grep -v "\.log" | grep -v "\.txt" | grep -v "\.csv" | grep -v "\.out"

JDKの場所の更新の詳細は、「既存のドメイン・ホームにおけるJDKの場所の更新」を参照してください。

アップグレード前の準備状況チェックの実行

アップグレードにかかわる潜在的な問題を特定するために、アップグレード・プロセスの開始前に、準備状況チェックの実行をお薦めします。準備状況チェックによって、アップグレードにかかわる潜在的な問題をすべて検出できるわけではない点に注意してください。準備状況チェックのレポートが成功を示していても、アップグレードが失敗することもあります。

アップグレード前の準備状況チェックの実行について
Upgrade Assistantを-readinessモードで実行することで、実際のアップグレードを実行する前に問題を検出できます。Upgrade Assistantを使用すると、準備状況チェックはGUIモードで実行できます。また、レスポンス・ファイルを使用するとサイレント・モードで実行できます。
準備状況モードでのUpgrade Assistantの起動
-readinessパラメータを使用して、Upgrade Assistantを準備状況モードで起動します。
Upgrade Assistantでの準備状況チェックの実行
Upgrade Assistantの各画面を通じて、アップグレード前の準備状況チェックを完了します。
準備状況レポートの理解
ドメインの準備状況チェックを実行した後、レポートを確認してアップグレードを成功させるためのアクションをとる必要があるかどうかを判断します。

アップグレード前の準備状況チェックの実行について

Upgrade Assistantを-readinessモードで実行することで、実際のアップグレードを実行する前に問題を検出できます。Upgrade Assistantを使用すると、準備状況チェックはGUIモードで実行できます。また、レスポンス・ファイルを使用するとサイレント・モードで実行できます。

Upgrade Assistantの準備状況チェックは、サポート対象の開始ポイントにあるFusion MiddlewareのスキーマとWebLogicドメインの構成について、読取り専用のアップグレード前確認を実行します。この確認は、読取り専用の操作です。

準備状況チェックでは、フォーマットされ、タイムスタンプの付けられた準備状況レポートが生成され、実際のアップグレードを試みる前に潜在的な問題に対処できます。問題が検出されない場合は、アップグレード・プロセスを開始できます。アップグレードを実行する前に、このレポートを詳細に確認することをお薦めします。

準備状況チェックは、既存のOracle Fusion Middlewareドメインがオンライン(他のユーザーがアクティブに使用している間)またはオフラインである間に実行できます。

準備状況チェックは、実際のアップグレードの実行前に、何度でも実行できます。ただし、アップグレードの実行後には、準備状況チェックを実行しないでください。これは、レポート結果が、アップグレード前の準備状況チェックと異なることがあるためです。

ノート:

パフォーマンスへの影響を避けるため、準備状況チェックはピーク時以外に実行するようにしてください。

準備状況モードでのUpgrade Assistantの起動

-readinessパラメータを使用して、Upgrade Assistantを準備状況モードで起動します。

Upgrade Assistantを使用して、アップグレード前の環境に対する準備状況チェックを実行するには:

oracle_common/upgrade/binディレクトリに移動します。
- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin
- (Windows) ORACLE_HOME\oracle_common\upgrade\bin
ORACLE_HOMEは、12c (12.2.1.4.0) Oracleホームです。
Upgrade Assistantを起動します。
- (UNIX) ./ua -readiness
- (Windows) ua.bat -readiness
ノート:
DISPLAY環境変数がGUIモードを有効にするように適切に設定されていないと、次に示すエラーが発生することがあります。
```
Xlib: connection to ":1.0" refused by server
Xlib: No protocol specified 
```
この問題を解決するには、DISPLAY変数を、有効なX環境が動作しているホストおよびデスクトップに設定する必要があります。

たとえば、デスクトップ6のローカル・ホストでVNC内部のX環境を実行している場合は、DISPLAY=:6を設定します。デスクトップ1のリモート・ホストでXを実行している場合は、これをDISPLAY=remoteHost:1に設定します。
その他のコマンドラインに指定可能なパラメータの詳細は、次の項を参照してください。

Upgrade Assistantのパラメータ

Upgrade Assistantのパラメータ

コマンドラインからUpgrade Assistantを起動するときに、追加のパラメータを指定できます。

表3-3 Upgrade Assistantのコマンドライン・パラメータ

パラメータ	必須またはオプション	説明
`-readiness`	準備状況チェックの場合は必須ノート: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。	アップグレードの準備状況チェックを実行します(実際のアップグレードは実行しません)。スキーマと構成がチェックされます。 `-examine`パラメータを指定した場合は、このパラメータを指定しないでください。
`-threads`	オプション	スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を特定します。値は、1 - 8の正の整数である必要があります。デフォルトは4です。
`-response`	サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須	Upgrade AssistantがGUIモードで実行されているときに入力したデータから生成されるレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、Upgrade Assistantはサイレント・モード(Upgrade Assistantの画面表示なし)で実行されます。
`-examine`	オプション	調査フェーズを実行しますが、実際のアップグレードは実行しません。 `-readiness`パラメータを指定した場合、このパラメータを指定しないでください。
`-logLevel attribute`	オプション	次のいずれかの属性を指定して、ログイン・レベルを設定します。 `TRACE` `NOTIFICATION` `WARNING` `ERROR` `INCIDENT_ERROR` デフォルトのロギング・レベルは`NOTIFICATION`です。 `-logLevel TRACE`属性を設定して、より多くのログが記録されるようにすることを検討してください。これは、アップグレードの失敗をトラブルシューティングする際に役立ちます。`-logLevel TRACE`が使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。
`-logDir location`	オプション	アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。デフォルトの場所は次のとおりです。 (UNIX) `ORACLE_HOME/oracle_common/upgrade/logs` `ORACLE_HOME/oracle_common/upgrade/temp` (Windows) `ORACLE_HOME/oracle_common/upgrade/logs` `ORACLE_HOME/oracle_common/upgrade/temp`
`-help`	オプション	すべてのコマンドライン・オプションを表示します。

親トピック: 準備状況モードでのUpgrade Assistantの起動

Upgrade Assistantを使用した準備状況チェックの実行

Upgrade Assistantの各画面を通じて、アップグレード前の準備状況チェックを完了します。

準備状況チェックは、サポートされるアップグレードの開始点にあるスキーマまたはコンポーネント構成に対してのみ実行されます。

準備状況チェックを完了するには:

「ようこそ」画面で、準備状況チェックに関する情報を確認します。「次」をクリックします。
「準備状況チェック・タイプ」画面で、実行する準備状況チェックを選択します。
- 「個別に選択されたスキーマ」: アップグレード前に確認するスキーマを個別に選択できます。準備状況チェックは、スキーマがアップグレードに対応しているかどうか、またはアップグレードが必要かどうかをレポートします。
  このオプションを選択すると、画面名が「選択したスキーマ」に変更されます。
- 「ドメイン・ベース」: Upgrade Assistantは、「ドメイン・ディレクトリ」フィールドで指定されたドメイン内で、アップグレード可能なスキーマまたはコンポーネントのすべてを検出して選択するようになります。
  このオプションを選択すると、画面名が「スキーマおよび構成」に変更されます。
  Upgrade Assistantですべてのスキーマとコンポーネント構成をチェックする場合は、デフォルトの選択を変更しないで使用します。それ以外の場合は、次に示す特定のオプションを選択します。
  - 「すべてのスキーマのチェックを含める」: アップグレードに対応したコンポーネントをすべて検出して確認します。
  - 「すべての構成のチェックを含める」: 管理対象WebLogic Serverドメインのコンポーネント構成を確認します。
ノート:
エンタープライズ・タイプのデプロイメントを実行している場合、ドメイン・ディレクトリは管理サーバーが実行されているディレクトリになります。

「次」をクリックします。
「個別に選択されたスキーマ」を選択した場合: 「使用可能なコンポーネント」画面で、アップグレードに対応可能なスキーマを持つコンポーネントを選択して、準備状況チェックの実行対象にします。
「ドメイン・ベース」を選択した場合: 「コンポーネント・リスト」画面で、準備状況チェックを実行するドメインに存在するコンポーネントのリストを確認してください。

依存コンポーネントのあるコンポーネントを選択すると、該当するコンポーネントが自動的に選択されます。たとえば、Oracle Platform Security Servicesを選択すると、Oracle Audit Servicesが自動的に選択されます。
選択したコンポーネントによっては、追加の画面が表示されることがあります。たとえば、次のような作業が必要になることがあります。
- 管理サーバーのドメイン・ディレクトリを指定します。
  
  必ず、12c (12.2.1.3.0)管理者サーバー・ドメイン・ディレクトリを指定します。
- 選択したスキーマに接続するために、次のスキーマ資格証明を指定します: 「データベース・タイプ」、「DBAユーザー名」および「DBAパスワード」。アップグレード前の要件の一部として、必要なユーザーをすでに作成しました。「Upgrade Assistantを実行するための非SYSDBAユーザーの作成」を参照してください。
  
  次に、「接続」をクリックします。
  
  ノート:
  Oracleデータベースは、デフォルトのデータベース・タイプです。データベース・タイプに間違いがないことを確認してから続行してください。間違ったデータベースを選択していることに気付いた場合でも、正しいタイプに変更するために、この画面に戻らないでください。そのかわりに、Upgrade Assistantを終了してから、正しいデータベース・タイプを選択した状態で準備状況チェックを再開し、すべてのスキーマに正しいデータベース・タイプが適用されるようにします。
- 「スキーマ・ユーザー名」オプションを選択して、「スキーマ・パスワード」を指定します。
  
  ノート:
  Upgrade Assistantでは、デフォルトの資格証明が自動的に有効になります。接続できない場合、スキーマの資格証明を手動で入力し、続行します。
「次」をクリックして、準備状況チェックを開始します。
「準備状況サマリー」画面で、選択内容に基づいて実行される準備状況チェックのサマリーを確認します。
選択内容を保存して、今後、レスポンス(サイレンス)モードでUpgrade Assistantを再実行する場合は、「レスポンス・ファイルの保存」をクリックして、レスポンス・ファイルの場所と名前を指定します。サイレント・アップグレードは、Upgrade Assistantとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。

詳細レポートを表示するには、「ログの表示」をクリックします。

「次」をクリックします。
「準備状況チェック」画面で、準備状況チェックのステータスを確認します。このプロセスには、数分かかることがあります。
複数のコンポーネントをチェックしている場合、それぞれのコンポーネントの進行状況は、それぞれ専用のプログレス・バーで同時に表示されます。

準備状況チェックが完了したら、「続行」をクリックします。
次のコンポーネントはアップグレードされていませんが、アップグレードの準備ができていますとマークされます。次のコンポーネントに対するアップグレードの準備ができていますというメッセージは、無視してください。
- Oracle JRF
- 共通インフラストラクチャ・サービス
- Oracle Web Services Manager。
「準備状況の終了」画面で、準備状況チェックの結果(「準備状況成功」または「準備状況失敗」)を確認します。
- 準備状況チェックが成功した場合は、「準備状況レポートの表示」をクリックして完全なレポートを確認します。準備状況チェックが成功した場合でも、実際のアップグレードを実行する前に、準備状況レポートを確認するようにしてください。「検索」オプションは、レポート内の特定の語句を検索する際に使用します。また、このレポートには、完成した準備状況チェック・レポート・ファイルが格納されている場所も示されます。
- 準備状況チェックで問題またはエラーが発生した場合、「ログの表示」をクリックして、ログ・ファイルを確認して問題を特定し、問題を修正してから、準備状況チェックを再開してください。ログ・ファイルは、設定したコマンドライン・オプションにより管理されます。

準備状況レポートの理解

ドメインの準備状況チェックを実行した後、レポートを確認してアップグレードを成功させるためのアクションをとる必要があるかどうかを判断します。

準備状況レポート・ファイルの形式は、次のとおりです。

readiness<timestamp>.txt

timestampは、準備状況チェックが実行された日時を示します。

準備状況レポートには、次の情報が含まれています。

表3-4 準備状況レポートの要素

レポートの情報	説明	必要なアクション
全体的な準備状況ステータス: SUCCESSまたはFAILURE	レポートの上部に、準備状況チェックが合格したか1つ以上のエラーで完了したかが示されます。	1つ以上のエラーが発生してレポートが完了した場合、アップグレードを試みる前に、FAILを検索し、障害の原因となった問題を修正します。準備状況チェックは、アップグレードする前に必要に応じて何度でも再実行できます。
タイムスタンプ	レポートが生成された日付と時刻です。	必要なアクションはありません。
ログ・ファイルの場所 `/oracle_common/upgrade/logs`	生成されたログ・ファイルのディレクトリの場所です。	必要なアクションはありません。
ドメイン・ディレクトリ	ドメインの場所が表示されます	必要なアクションはありません。
準備状況レポートの場所 `/oracle_common/upgrade/logs`	生成された準備状況レポートのディレクトリの場所です。	必要なアクションはありません。
チェックされたコンポーネントの名前	チェックに含まれるコンポーネントの名前およびバージョンとステータス。	ドメインに、このリリースにアップグレードできないSOAコア拡張機能などのコンポーネントが含まれる場合は、アップグレードを試行しないでください。
チェックされたスキーマの名前	チェックに含まれるスキーマの名前および現在のバージョンとステータス。	スキーマのバージョン番号をレビューします。ドメインに、このリリースにアップグレードできないスキーマが含まれる場合は、アップグレードを試行しないでください。
個別のオブジェクトのテスト・ステータス: FAIL	準備状況チェックのテストで、特定のオブジェクトに問題が検出されています。	失敗した問題がすべて解決されるまではアップグレードしないでください。
個別のオブジェクトのテスト・ステータス: PASS	準備状況チェックのテストでは、特定のオブジェクトに問題が検出されませんでした。	準備状況チェック・レポートに「成功」ステータスのみが表示されている場合は、環境をアップグレードできます。ただし、準備状況チェックでは、ハードウェアやアップグレード時の接続性などの外部環境に関する問題を検出することはできません。アップグレードの進捗を常に監視する必要があります。
<オブジェクト>の準備状況チェックの完了ステータス: FAILURE	準備状況チェックで、スキーマ、索引またはデータ型などの特定のオブジェクトに対して解決する必要がある1つ以上のエラーが検出されました。	失敗した問題がすべて解決されるまではアップグレードしないでください。
<オブジェクト>の準備状況チェックの完了ステータス: SUCCESS	準備状況チェック・テストによって問題が検出されませんでした。	必要なアクションはありません。

準備状況レポート・ファイルのサンプルを次に示します。レポートにはこれらのチェックのすべてが含まれない場合があります。

Upgrade readiness check completed with one or more errors.

This readiness check report was created on Fri Aug 16 13:29:41 PDT 2019
Log file is located at: /oracle/work/middleware_latest/oracle_common/upgrade/logs/ua2019-08-16-13-23-36PM.log
Readiness Check Report File: /oracle/work/middleware_latest/oracle_common/upgrade/logs/readiness2019-08-16-13-29-41PM.txt
Domain Directory: /oracle/work/middleware_1212/user_projects/domains/jrf_domain

Starting readiness check of components.

Oracle Platform Security Services
   Starting readiness check of Oracle Platform Security Services.
     Schema User Name: DEV3_OPSS
     Database Type: Oracle Database
     Database Connect String: 
     VERSION Schema DEV3_OPSS is currently at version 12.1.2.0.0.  Readiness checks will now be performed.
   Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
     INFO   Database product version: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
   Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
   Starting schema test:  TEST_REQUIRED_TABLES  Test that the schema contains all the required tables
   Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS
   Starting schema test:  Test that the schema does not contain any unexpected tables  TEST_UNEXPECTED_TABLES
   Completed schema test: Test that the schema does not contain any unexpected tables --> TEST_UNEXPECTED_TABLES +++ Test that the schema does not contain any unexpected tables
   Starting schema test:  TEST_ENOUGH_TABLESPACE  Test that the schema tablespaces automatically extend if full
   Completed schema test: TEST_ENOUGH_TABLESPACE --> Test that the schema tablespaces automatically extend if full +++ PASS
   Starting schema test:  TEST_USER_TABLESPACE_QUOTA  Test that tablespace quota for this user is sufficient to perform the upgrade
   Completed schema test: TEST_USER_TABLESPACE_QUOTA --> Test that tablespace quota for this user is sufficient to perform the upgrade +++ PASS
   Starting schema test:  TEST_ONLINE_TABLESPACE  Test that schema tablespaces are online
   Completed schema test: TEST_ONLINE_TABLESPACE --> Test that schema tablespaces are online +++ PASS
   Starting permissions test:  TEST_DBA_TABLE_GRANTS  Test that DBA user has privilege to view all user tables
   Completed permissions test: TEST_DBA_TABLE_GRANTS --> Test that DBA user has privilege to view all user tables +++ PASS
   Starting schema test:  SEQUENCE_TEST  Test that the Oracle Platform Security Services schema sequence and its properties are valid
   Completed schema test: SEQUENCE_TEST --> Test that the Oracle Platform Security Services schema sequence and its properties are valid +++ PASS
   Finished readiness check of Oracle Platform Security Services with status: SUCCESS.

Oracle Audit Services
   Starting readiness check of Oracle Audit Services.
     Schema User Name: DEV3_IAU
     Database Type: Oracle Database
     Database Connect String: 
     VERSION Schema DEV3_IAU is currently at version 12.1.2.0.0.  Readiness checks will now be performed.
   Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
     INFO   Database product version: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
   Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
   Starting schema test:  TEST_REQUIRED_TABLES  Test that the schema contains all the required tables
   Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS
   Starting schema test:  TEST_UNEXPECTED_TABLES  Test that the schema does not contain any unexpected tables
   Completed schema test: TEST_UNEXPECTED_TABLES --> Test that the schema does not contain any unexpected tables +++ PASS
   Starting schema test:  TEST_ENOUGH_TABLESPACE  Test that the schema tablespaces automatically extend if full
   Completed schema test: TEST_ENOUGH_TABLESPACE --> Test that the schema tablespaces automatically extend if full +++ PASS
   Starting schema test:  TEST_USER_TABLESPACE_QUOTA  Test that tablespace quota for this user is sufficient to perform the upgrade
   Completed schema test: TEST_USER_TABLESPACE_QUOTA --> Test that tablespace quota for this user is sufficient to perform the upgrade +++ PASS
   Starting schema test:  TEST_ONLINE_TABLESPACE  Test that schema tablespaces are online
   Completed schema test: TEST_ONLINE_TABLESPACE --> Test that schema tablespaces are online +++ PASS
   Starting permissions test:  TEST_DBA_TABLE_GRANTS  Test that DBA user has privilege to view all user tables
   Completed permissions test: TEST_DBA_TABLE_GRANTS --> Test that DBA user has privilege to view all user tables +++ PASS
   Starting schema test:  TEST_MISSING_COLUMNS  Test that tables and views are not missing any required columns
   Completed schema test: TEST_MISSING_COLUMNS --> Test that tables and views are not missing any required columns +++ PASS
   Starting schema test:  TEST_UNEXPECTED_COLUMNS  Test that tables and views do not contain any unexpected columns
   Completed schema test: TEST_UNEXPECTED_COLUMNS --> Test that tables and views do not contain any unexpected columns +++ PASS
   Starting datatype test for table OIDCOMPONENT:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
   Completed datatype test for table OIDCOMPONENT: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
   Starting datatype test for table IAU_CUSTOM_01:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
   Completed datatype test for table IAU_CUSTOM_01: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
   Starting datatype test for table IAU_BASE:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
   Completed datatype test for table IAU_BASE: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
   Starting datatype test for table WS_POLICYATTACHMENT:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
   Completed datatype test for table WS_POLICYATTACHMENT: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
   Starting datatype test for table OWSM_PM_EJB:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
   Completed datatype test for table OWSM_PM_EJB: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
   Starting datatype test for table XMLPSERVER:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
   Completed datatype test for table XMLPSERVER: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
   Starting datatype test for table SOA_HCFP:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
   Completed datatype test for table SOA_HCFP: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
   Starting schema test:  SEQUENCE_TEST  Test that the audit schema sequence and its properties are valid
   Completed schema test: SEQUENCE_TEST --> Test that the audit schema sequence and its properties are valid +++ PASS
   Starting schema test:  SYNONYMS_TEST  Test that the audit schema required synonyms are present
   Completed schema test: SYNONYMS_TEST --> Test that the audit schema required synonyms are present +++ PASS
   Finished readiness check of Oracle Audit Services with status: FAILURE.

Common Infrastructure Services
   Starting readiness check of Common Infrastructure Services.
     Schema User Name: DEV3_STB
     Database Type: Oracle Database
     Database Connect String: 
   Starting schema test:  TEST_REQUIRED_TABLES  Test that the schema contains all the required tables
   Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS
   Completed schema test: ALL_TABLES --> TEST_REQUIRED_TABLES +++ Test that the schema contains all the required tables
   Starting schema test:  TEST_UNEXPECTED_TABLES  Test that the schema does not contain any unexpected tables
   Completed schema test: ALL_TABLES --> TEST_UNEXPECTED_TABLES +++ Test that the schema does not contain any unexpected tables
   Starting schema test:  TEST_REQUIRED_VIEWS  Test that the schema contains all the required database views
   Completed schema test: ALL_TABLES --> TEST_REQUIRED_VIEWS +++ Test that the schema contains all the required database views
   Starting schema test:  TEST_MISSING_COLUMNS  Test that tables and views are not missing any required columns
   Completed schema test: ALL_TABLES --> TEST_MISSING_COLUMNS +++ Test that tables and views are not missing any required columns
   Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
   Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
     INFO   Database product version: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
   Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
   Completed schema test: ALL_TABLES --> TEST_DATABASE_VERSION +++ Test that the database server version number is supported for upgrade
   Finished readiness check of Common Infrastructure Services with status: SUCCESS.

Oracle JRF
   Starting readiness check of Oracle JRF.
   Finished readiness check of Oracle JRF with status: SUCCESS.

System Components Infrastructure
   Starting readiness check of System Components Infrastructure.
   Starting config test:  TEST_SOURCE_CONFIG  Checking the source configuration.
     INFO /oracle/work/middleware_1212/user_projects/domains/jrf_domain/opmn/topology.xml was not found. No upgrade is needed.
   Completed config test: TEST_SOURCE_CONFIG --> Checking the source configuration. +++ PASS
   Finished readiness check of System Components Infrastructure with status: ALREADY_UPGRADED.

Common Infrastructure Services
   Starting readiness check of Common Infrastructure Services.
   Starting config test:  CIEConfigPlugin.readiness.test  This tests the readiness of the domain from CIE side.
   Completed config test: CIEConfigPlugin.readiness.test --> This tests the readiness of the domain from CIE side. +++ PASS
   Finished readiness check of Common Infrastructure Services with status: SUCCESS.

Finished readiness check of components.

Oracle Identity Managerに対するデータベース・パラメータのチューニング

スキーマのアップグレード前に、Oracle Identity Managerに対してデータベース・パラメータをチューニングする必要があります。

Oracle Identity Manager (OIM)パフォーマンス・チューニング・ガイドラインおよび診断取集(ドキュメントID 1539554.1)を参照してください。

製品スキーマのアップグレード

サーバーとプロセスの停止後に、Upgrade Assistantを使用して、サポートされている製品スキーマをOracle Fusion Middlewareの現在のリリースにアップグレードします。

Upgrade Assistantを使用すると、個別に選択したスキーマまたはドメインに関連付けられているすべてのスキーマをアップグレードできます。選択したオプションによって、表示されるUpgrade Assistantの画面は異なります。

ノート:

12.2 RAC環境でデータポンプ・ワーカー(DW)プロセスの'ライブラリ・キャッシュ・ロック' (サイクル)<='ライブラリ・キャッシュ・ロック'が原因で、長い待機時間およびパフォーマンスの低下が見られる場合があります。この問題を解決するには、次のコマンドを使用してS最適化を無効にする必要があります:

ALTER SYSTEM SET "_lm_share_lock_opt"=FALSE SCOPE=SPFILE SID='*';

前述のコマンドの実行後、すべてのRACインスタンスを再起動します。アップグレードの完了後、次のコマンドを使用してパラメータをリセットできます:

alter system reset "_lm_share_lock_opt" scope=spfile sid='*';

アップグレードに対応可能な既存のスキーマの特定
このオプションの作業では、スキーマ・バージョン・レジストリを問い合せることで、アップグレードの開始前に、使用可能スキーマのリストを確認できます。レジストリには、バージョン番号、コンポーネント名およびID、作成日と変更日、カスタム接頭辞などのスキーマ情報が含まれます。
Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.4.0)にアップグレードします。一度に1つのドメインのアップグレードを完了して、Upgrade Assistantを非SYSDBAユーザーとして実行することをお薦めします。
Upgrade Assistantを使用したOracle Identity Managerスキーマのアップグレード
Upgrade Assistantの各画面を通じて、製品スキーマをアップグレードします。
スキーマのアップグレードの確認
すべてのアップグレード・ステップを完了したら、schema_version_registryのスキーマ・バージョンが適切に更新されていることをチェックして、アップグレードの成功を検証します。

アップグレードに対応可能な既存のスキーマの特定

このオプションの作業では、スキーマ・バージョン・レジストリを問い合せることで、アップグレードの開始前に、使用可能スキーマのリストを確認できます。レジストリには、バージョン番号、コンポーネント名およびID、作成日と変更日、カスタム接頭辞などのスキーマ情報が含まれます。

Upgrade Assistantでドメイン内のすべてのスキーマをアップグレードすることも、アップグレードするスキーマを個別に選択することもできます。この判断には、次に示すステップを実行して、アップグレードに対応可能なすべてのスキーマのリストを表示することが役立ちます。

Oracleデータベースを使用している場合、Oracle DBA権限を持つアカウントを使用してデータベースに接続し、SQL*Plusから次を実行します。

SET LINE 120
COLUMN MRC_NAME FORMAT A14
COLUMN COMP_ID FORMAT A20
COLUMN VERSION FORMAT A12
COLUMN STATUS FORMAT A9
COLUMN UPGRADED FORMAT A8
SELECT MRC_NAME, COMP_ID, OWNER, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY ORDER BY MRC_NAME, COMP_ID;

生成されたレポートを調査します。

アップグレードの必要がないスキーマがある場合は、そのスキーマのアップグレード前のバージョンがschema_version_registry表に維持されます。

ノート:

既存のスキーマが、サポートされているバージョンからのものでない場合、12c (12.2.1.4.0)のアップグレード手順を使用する前に、それらをサポートされているバージョンにアップグレードする必要があります。詳細は、アップグレード前のバージョンのドキュメントを参照してください。
以前のバージョンでOIDベースのポリシー・ストアを使用していた場合、アップグレードを実行する前に新しいOPSSスキーマを必ず作成します。アップグレード後も、OPSSスキーマはLDAPベース・ストアのままです。
Oracle Fusion Middlewareリリース12c (12.2.1.4.0)でアップグレード可能な製品のスキーマのみをアップグレードできます。まだ12c (12.2.1.4.0)へのアップグレードが可能になっていないコンポーネントを含むドメインをアップグレードしないでください。

親トピック: 製品スキーマのアップグレード

Upgrade Assistantの起動

Upgrade Assistantを実行して、製品のスキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.4.0)にアップグレードします。一度に1つのドメインのアップグレードを完了して、Upgrade Assistantを非SYSDBAユーザーとして実行することをお薦めします。

Upgrade Assistantを起動するには、次の手順に従います。

ノート:

Upgrade Assistantを起動する前に、JVMの文字エンコーディングが、Upgrade Assistantが実行されるプラットフォームでUTF-8に設定されていることを確認してください。文字エンコーディングがUTF-8に設定されていないと、名前にUnicode文字を含むファイルをダウンロードできません。これにより、アップグレードに失敗する可能性があります。

UTF-8がJVMによって使用されていることを確認するには、JVMオプション-Dfile.encoding=UTF-8を使用します。

oracle_common/upgrade/binディレクトリに移動します。
- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin
- (Windows) ORACLE_HOME\oracle_common\upgrade\bin
JVMエンコーディング要件を含むようにUpgrade Assistantのパラメータを設定します:
- (UNIX) export UA_PROPERTIES="-Dfile.encoding=UTF-8"
- (Windows) set UA_PROPERTIES="-Dfile.encoding=UTF-8"
Upgrade Assistantを起動します。
- (UNIX) ./ua
- (Windows) ua.bat

ノート:

前述のコマンドで、ORACLE_HOMEは12c (12.2.1.4.0) Oracleホームを示しています。

コマンドラインに指定可能なその他のパラメータ(ロギングのパラメータなど)の詳細は、次を参照してください。

Upgrade Assistantのパラメータ

親トピック: 製品スキーマのアップグレード

Upgrade Assistantのパラメータ

コマンドラインからUpgrade Assistantを起動するときに、追加のパラメータを指定できます。

表3-5 Upgrade Assistantのコマンドライン・パラメータ

パラメータ	必須またはオプション	説明
`-readiness`	準備状況チェックの場合は必須ノート: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。	アップグレードの準備状況チェックを実行します(実際のアップグレードは実行しません)。スキーマと構成がチェックされます。 `-examine`パラメータを指定した場合は、このパラメータを指定しないでください。
`-threads`	オプション	スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を特定します。値は、1 - 8の正の整数である必要があります。デフォルトは4です。
`-response`	サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須	Upgrade AssistantがGUIモードで実行されているときに入力したデータから生成されるレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、Upgrade Assistantはサイレント・モード(Upgrade Assistantの画面表示なし)で実行されます。
`-examine`	オプション	調査フェーズを実行しますが、実際のアップグレードは実行しません。 `-readiness`パラメータを指定した場合、このパラメータを指定しないでください。
`-logLevel attribute`	オプション	次のいずれかの属性を指定して、ログイン・レベルを設定します。 `TRACE` `NOTIFICATION` `WARNING` `ERROR` `INCIDENT_ERROR` デフォルトのロギング・レベルは`NOTIFICATION`です。 `-logLevel TRACE`属性を設定して、より多くのログが記録されるようにすることを検討してください。これは、アップグレードの失敗をトラブルシューティングする際に役立ちます。`-logLevel TRACE`が使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。
`-logDir location`	オプション	アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。デフォルトの場所は次のとおりです。 (UNIX) `ORACLE_HOME/oracle_common/upgrade/logs` `ORACLE_HOME/oracle_common/upgrade/temp` (Windows) `ORACLE_HOME/oracle_common/upgrade/logs` `ORACLE_HOME/oracle_common/upgrade/temp`
`-help`	オプション	すべてのコマンドライン・オプションを表示します。

親トピック: Upgrade Assistantの起動

Upgrade Assistantを使用したOracle Identity Managerスキーマのアップグレード

Upgrade Assistantの各画面を通じて、製品スキーマをアップグレードします。

Upgrade Assistantを使用して、製品スキーマをアップグレードするには:

「ようこそ」画面には、Upgrade Assistantの概要と、アップグレード前のいくつかの重要なタスクについての情報が表示されます。「次」をクリックします。

ノート:
Upgrade Assistantの画面の詳細は、画面上の「ヘルプ」をクリックしてください。
「アップグレード・タイプ」画面で、実行するスキーマ・アップグレード操作を選択します:
- 「個別に選択されたスキーマ」: ドメインで使用されるスキーマをすべてアップグレードするのではなく、アップグレードするスキーマを個別に選択する場合のオプションです。
  
  注意:
  12c (12.2.1.4.0)コンポーネントをサポートするために使用されるスキーマのみをアップグレードしてください。Oracle Fusion Middleware 12c (12.2.1.4.0)に含まれていないコンポーネントをサポートするために現在使用されているスキーマをアップグレードしないでください。
- 「ドメインで使用されるすべてのスキーマ」を使用すると、Upgrade Assistantは、ドメイン内でアップグレードに対応可能な「ドメイン・ディレクトリ」フィールドで指定されたスキーマを持つコンポーネントをすべて検出して選択します。これは、ドメイン支援のスキーマ・アップグレードとも呼ばれています。さらに、Upgrade Assistantはスキーマの入力画面に接続情報を事前に移入します。
  
  ノート:
  ほとんどのアップグレードでは、「ドメインで使用されるすべてのスキーマ」を選択して、必要なすべてのスキーマがアップグレードに含まれるようにすることをお薦めします。
ノート:

SSL有効Oracle Identity Manager設定をアップグレードする場合は、「個別に選択されたスキーマ」オプションを選択し、Oracle Identity Managerスキーマのみを選択します。これにより、依存スキーマが自動的に選択されます。SSL有効設定をアップグレードする場合は、「スキーマ資格証明」画面で非SSLデータベース接続の詳細を入力する必要があります。
「個別に選択されたスキーマ」を選択した場合: 「使用可能なコンポーネント」画面で、スキーマをアップグレードするコンポーネントを選択します。コンポーネントを選択すると、スキーマとすべての依存関係が自動的に選択されます。
ノート:
- 個別のスキーマ・オプションの場合、ドメイン構成はアクセスされないため、パスワード値は前の画面からのものがそのまま使用されます。接続に失敗する場合は、原因を調べ、修正してください。
- Upgrade Assistantユーティリティで正しいUMSスキーマを使用するには、_UMSを接尾辞として追加して、UMSスキーマを手動で編集します。たとえば、SOAアップグレードを成功させるには、DEVをDEV_UMSに編集します。
「画面」名で、ドメイン・フォルダを選択します。

「次」をクリックします。
「コンポーネント・リスト」画面に、スキーマがアップグレードされるコンポーネントのリストが表示されます。

「次」をクリックします。
「前提条件」画面で、すべてのチェック・ボックスを選択して、前提条件を満たしていることを確認します。「次」をクリックします。

ノート:
Upgrade Assistantでは前提条件が満たされているかどうかを確認できません。
スキーマ資格証明の画面で、アップグレードするスキーマごとにデータベース接続の詳細を指定します(この画面名は、選択したスキーマに応じて変化します)。
- 「データベース・タイプ」ドロップダウン・メニューからデータベース・タイプを選択します。
- データベース接続の詳細を入力して、「接続」をクリックします。
- 「スキーマ・ユーザー名」ドロップダウン・メニューからアップグレードするスキーマを選択し、スキーマのパスワードを入力します。アップグレードするスキーマに対して正しいスキーマ接頭辞を使用してください。
「次」をクリックします。
「調査」画面で、各スキーマを調査したUpgrade Assistantのステータスを確認して、スキーマのアップグレードの準備が整っていることを検証します。ステータスが「調査が終了しました。」になっている場合は、「次」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログで「いいえ」をクリックして、アップグレードを取り消すことをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、一般的なアップグレード・エラーの解決の詳細をUpgrade Assistantによるアップグレードのアップグレードのトラブルシューティングで参照してください。
ノート:
- 確認フェーズ中に検出された問題を、アップグレードを進めずに解決した場合は、バックアップからリストアを再び行わずにUpgrade Assistantを開始できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックしてアップグレードを続行していた場合は、Upgrade Assistantを再開する前に、バックアップからアップグレード前の環境をリストアする必要があります。
- 調査プロセスを取り消してもスキーマまたは構成データに影響はありませんが、将来のアップグレード・セッションでは、Upgrade Assistantが収集した情報を再収集する必要があります。
「アップグレード・サマリー」画面で、スキーマのアップグレードに選択したオプションのサマリーを確認します。
アップグレード対象のスキーマごとに、正しいソース・バージョンとターゲット・バージョンがリストされていることを確認します。

これらのオプションを保存して、今後、レスポンス(サイレンス)モードでUpgrade Assistantを再実行する場合は、「レスポンス・ファイルの保存」をクリックして、レスポンス・ファイルの場所と名前を指定します。サイレント・アップグレードは、Upgrade Assistantとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。
「アップグレードの進行状況」画面で、アップグレードのステータスを監視します。

注意:
Upgrade Assistantにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。これを行うと、環境が不安定になる可能性があります。

正しくアップグレードされていないスキーマがある場合は、Upgrade Assistantのログ・ファイルで情報を確認します。

ノート:
この画面のプログレス・バーには、現在のアップグレード手順の進行状況が表示されます。アップグレードの残り時間を示すものではありません。

「次」をクリックします。
アップグレードが正常に完了すると、Upgrade Assistantによりアップグレード・ステータスが示され、アップグレード・プロセスの後続のステップがリストされます。Upgrade Assistantの「アップグレード成功」画面に示された情報を基にして、次に実行するステップを判断してください。ウィザードには次の情報が表示されます:
```
Upgrade Succeeded.

Log File: /u01/oracle/products/12c/identity/oracle_common/upgrade/logs/ua2020-09-15-18-27-29PM.txt
Post Upgrade Text file: /u01/oracle/products/12c/identity/oracle_common/upgrade/logs/postupgrade2020-09-15-18-27-29PM.txt
Next Steps

Oracle SOA
1. The Upgrade Assistant has successfully upgraded all active instances. You can now close the Upgrade Assistant.
2. The automated upgrade of closed instances will continue in the background after the Upgrade Assistant is exited and until the SOA server is started,at which point the upgrade will stop. You can schedule the upgrade of any remaining closed instances for a time when the SOA server is less busy.
   Close the Upgrade Assistant and use the instance data administration scripts to administer and monitor the overall progress of this automated upgrade. For more information see "Administering and Monitoring the Upgrade of SOA Instance Data" in Upgrading SOA Suite and Business Process Management.
```
「閉じる」をクリックすると、アップグレードが完了しウィザードが終了します。
アップグレードが失敗した場合: 「アップグレード失敗」画面で「ログの表示」をクリックして、エラーを確認し、トラブルシューティングします。ログは、ORACLE_HOME/oracle_common/upgrade/logsにあります。

ノート:
アップグレードが失敗した場合は、バックアップからアップグレード前の環境をリストアし、問題を修正してから、Upgrade Assistantを再起動する必要があります。

親トピック: 製品スキーマのアップグレード

スキーマのアップグレードの確認

すべてのアップグレード・ステップを完了したら、schema_version_registryのスキーマ・バージョンが適切に更新されていることをチェックして、アップグレードの成功を検証します。

Oracle Databaseを使用する場合、Oracle DBAを持つユーザーとしてデータベースに接続し、SQL*Plusから次を実行して現行のバージョン番号を取得します。

SET LINE 120
COLUMN MRC_NAME FORMAT A14
COLUMN COMP_ID FORMAT A20
COLUMN VERSION FORMAT A12
COLUMN STATUS FORMAT A9
COLUMN UPGRADED FORMAT A8
SELECT MRC_NAME, COMP_ID, OWNER, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY ORDER BY MRC_NAME, COMP_ID ;

問合せ結果について:

VERSION列の数値が、そのスキーマの最新のバージョン番号に一致していることを確認します。たとえば、スキーマ・バージョン番号が12.2.1.4.0であることを確認します。

ノート:

ただし、すべてのスキーマ・バージョンが更新されるわけではありません。一部のスキーマではこのリリースへのアップグレードが必要なく、アップグレード前のバージョン番号が保持されます。
STATUSフィールドは、スキーマのパッチ適用操作中はUPGRADINGまたはUPGRADEDのどちらかになり、パッチ適用操作が完了するとVALIDになります。
ステータスが「INVALID」と表示された場合は、ステータスの更新が失敗しています。ログ・ファイルを調べて、失敗した理由を判定する必要があります。
IAU_APPENDとIAU_VIEWERが所有するシノニム・オブジェクトは、INVALIDと表示されますが、失敗を意味するものではありません。

これらは、シノニムの作成後にターゲット・オブジェクトが変更されるため無効になります。シノニム・オブジェクトは、アクセスされるときに有効になります。これに該当するINVALIDオブジェクトは、無視しても問題ありません。

ノート:

アップグレードの準備時に行った非SSLポートの変更や非SYSDBAユーザーを元に戻します。

親トピック: 製品スキーマのアップグレード

ドメイン・コンポーネント構成のアップグレード

Upgrade Assistantを使用して、ドメイン内のドメイン・コンポーネント構成を、更新されたドメイン構成に一致するようにアップグレードします。

Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.4.0)にアップグレードします。一度に1つのドメインのアップグレードを完了して、Upgrade Assistantを非SYSDBAユーザーとして実行することをお薦めします。
Oracle Identity Managerドメイン・コンポーネント構成のアップグレード
Upgrade Assistantの各画面を通じて、WebLogicドメインのコンポーネント構成をアップグレードします。

Upgrade Assistantの起動

Upgrade Assistantを起動するには、次の手順に従います。

ノート:

UTF-8がJVMによって使用されていることを確認するには、JVMオプション-Dfile.encoding=UTF-8を使用します。

oracle_common/upgrade/binディレクトリに移動します。
- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin
- (Windows) ORACLE_HOME\oracle_common\upgrade\bin
JVMエンコーディング要件を含むようにUpgrade Assistantのパラメータを設定します:
- (UNIX) export UA_PROPERTIES="-Dfile.encoding=UTF-8"
- (Windows) set UA_PROPERTIES="-Dfile.encoding=UTF-8"
Upgrade Assistantを起動します。
- (UNIX) ./ua
- (Windows) ua.bat

ノート:

前述のコマンドで、ORACLE_HOMEは12c (12.2.1.4.0) Oracleホームを示しています。

コマンドラインに指定可能なその他のパラメータ(ロギングのパラメータなど)の詳細は、次を参照してください。

親トピック: ドメイン・コンポーネント構成のアップグレード

Oracle Identity Managerドメイン・コンポーネント構成のアップグレード

Upgrade Assistantの各画面を通じて、WebLogicドメインのコンポーネント構成をアップグレードします。

Upgrade Assistantを実行して、ドメイン・コンポーネント構成を、更新されたドメイン構成に一致するようにアップグレードします。

Upgrade Assistantを使用して、ドメイン・コンポーネント構成をアップグレードするには:

「ようこそ」画面には、Upgrade Assistantの概要と、アップグレード前のいくつかの重要なタスクについての情報が表示されます。「次」をクリックします。

ノート:
Upgrade Assistantの画面の詳細は、画面上の「ヘルプ」をクリックしてください。
次の画面で、次を実行します。
- 「ドメインによって使用されるすべての構成」を選択します。画面名が「WebLogicコンポーネント」に変更されます。
- 「ドメイン・ディレクトリ」フィールドで、OIMドメイン・ディレクトリを指定します。
  
  「ドメイン・ディレクトリ」は、管理サーバー・ドメイン・ディレクトリです。
「次」をクリックします。
「コンポーネント・リスト」画面で、構成をアップグレードするコンポーネントがリストにすべて含まれていることを確認し、「次」をクリックします。
アップグレードするコンポーネントが表示されない場合は、「戻る」をクリックして前の画面に移動し、異なるドメインを指定します。
「前提条件」画面で、すべてのチェック・ボックスを選択して、前提条件を満たしていることを確認します。「次」をクリックします。

ノート:
Upgrade Assistantでは前提条件が満たされているかどうかを確認できません。
「調査」画面で、各コンポーネントを調査したUpgrade Assistantのステータスを確認して、コンポーネント構成のアップグレードの準備が整っていることを検証します。ステータスが「調査が終了しました。」になっている場合は、「次」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログで「いいえ」をクリックして、アップグレードを取り消すことをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、一般的なアップグレード・エラーの解決の詳細をUpgrade Assistantによるアップグレードのアップグレードのトラブルシューティングで参照してください。
ノート:
- 確認フェーズ中に検出された問題を、アップグレードを進めずに解決した場合は、バックアップからリストアを再び行わずにUpgrade Assistantを開始できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックしてアップグレードを続行していた場合は、Upgrade Assistantを再開する前に、バックアップからアップグレード前の環境をリストアする必要があります。
- 調査プロセスを取り消しても構成データに影響はありませんが、将来のアップグレード・セッションでは、Upgrade Assistantが収集した情報の再収集が必要になります。
「アップグレード・サマリー」画面で、コンポーネント構成のアップグレードに選択したオプションのサマリーを確認します。
レスポンス・ファイルには、入力したすべての情報が収集および格納されます。このファイルにより、その後のサイレント・アップグレードの実行が可能になります。サイレント・アップグレードは、Upgrade Assistantとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。
「アップグレードの進行状況」画面で、アップグレードのステータスを監視します。

注意:
Upgrade Assistantにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。これを行うと、環境が不安定になる可能性があります。

正しくアップグレードされていないコンポーネントがある場合は、Upgrade Assistantのログ・ファイルで情報を確認します。

ノート:
この画面のプログレス・バーには、現在のアップグレード手順の進行状況が表示されます。アップグレードの残り時間を示すものではありません。

「次」をクリックします。
アップグレードが成功した場合: 「アップグレード成功」画面で、「閉じる」をクリックし、アップグレードを完了してウィザードを閉じます。新規インストールでコンポーネントを機能させるために手動で実行する必要のあるタスクが、アップグレード後のアクションのウィンドウに表示されます。このウィンドウは、コンポーネントにアップグレード後のステップがある場合にのみ表示されます。

アップグレードが失敗した場合: 「アップグレード失敗」画面で「ログの表示」をクリックして、エラーを確認し、トラブルシューティングします。ログは、ORACLE_HOME/oracle_common/upgrade/logsにあります。

ノート:
アップグレードが失敗した場合は、アップグレード前の環境をバックアップからリストアし、問題を修正してから、Upgrade Assistantを再起動する必要があります。

親トピック: ドメイン・コンポーネント構成のアップグレード

ユーザー・インタフェースに対するアプリケーション・モジュールのチューニング

Oracle Identity Manager中間層のアップグレードに成功したら、アプリケーション・モジュール(AM)をチューニングします。

パラメータjbo.ampool.maxavailablesizeは、OIMにアクセスすると予想される同時ユーザーの数をOIMに知らせるために使用されます。デフォルト値を確認するには、$DOMAIN_HOME/setDomainEnv.shに移動し、パラメータjbo.ampool.maxavailablesizeを検索します。

設定されている値が予想される同時ユーザーの数と一致しない場合は、setUserOverridesLate.shファイルでその値を更新する必要があります。setDomainEnv.shファイルは直接変更しないでください。将来の更新時に変更が失われる可能性があります。setUserOverridesLate.shに対する変更はアップグレード後も保持されるため、ユーザーが定義する値はすべてこのファイルで設定する必要があります。

パラメータjbo.ampool.maxavailablesizeの推奨値は、予想される同時ユーザー数+ 20%です。

推奨アプリケーション・モジュール設定を追加するには、次を実行します:

テキスト・エディタでファイル$DOMAIN_HOME/bin/setUserOverridesLate.shを開きます。

setUserOverridesLate.shファイルを編集して、次の行を追加します:

JAVA_OPTIONS="${JAVA_OPTIONS} -Djbo.ampool.maxavailablesize = <# of concurrent users + 20%>

setUserOverridesLate.shファイルを保存して閉じます。

ノート:

setUserOverridesLate.shファイルが存在しない場合は、作成する必要があります。

12c Oracleホームからのoracle.iam.ui.custom-dev-starter-pack.warのコピー

oracle.iam.ui.custom-dev-starter-pack.warファイルを、12c (12.2.1.3.0) Oracleホームのバックアップから、12c (12.2.1.4.0) Oracleホーム(ORACLE_HOME/idm/server/apps/)に手動でコピーする必要があります。

サーバーの起動

Oracle Identity Managerのアップグレード後、サーバーを起動します。

サーバーは次の順序で起動してください。

管理サーバーを起動します。ノード・マネージャが構成されている場合は、ノード・マネージャを起動しないでください。
管理サーバーURLを使用してOracle SOA Suite管理対象サーバーを起動します。たとえば:
./startManagedWebLogic.sh <soa_managed_server_name> t3://weblogic_admin_host:weblogic_admin_port

ノート:
SSL環境では、管理対象サーバーをブートストラップのために初めて起動するときに、管理サーバーの非SSLポート番号を指定します。
SOAサーバーが実行中の状態になり、soa-infraアプリケーションがACTIVEステータスになったら、管理サーバーURLを使用してOracle Identity Manager管理対象サーバーを起動します。たとえば:
/startManagedWebLogic.sh <oim_managed_server_name> t3://weblogic_admin_host:weblogic_admin_port
ノート:
- ステップ2で行ったように、管理サーバーの非SSLポート番号を指定します。
- OIM管理対象サーバーは、ブートストラップ・タスクを実行するときにsoa-infraアプリケーションをコールします。soa-infraアプリケーションがACTIVEステータスでない場合、OIMブートストラップは次のエラーで失敗します:
```
<Error> <oracle.iam.OIMPostConfigManager> <BEA-000000> <Shutting down the
BootStrap Process. Please fix the problem and start the OIM Managed server
again to complete OIM BootStrap. OR, If you want to skip the feature which
has failed, mark the feature as complete using sql 'update oimbootstate set
state='COMPLETE' where featurename='FAILED_FEATURE_NAME' and start the
Managed Server again. In the latter case, you will have to manually perform
the task being done by the failed feature. Refer to the Install
documentations for the same>
java.lang.RuntimeException: None of the SOA servers are in RUNNING state!
at
oracle.iam.platform.mbeans.impl.util.SOAIntegrationUtil.getSOAServerURLs(SOAIn
tegrationUtil.java:358)
at
oracle.iam.OIMPostConfigManager.config.OIMConfigManager.updateOIMCONFIGXML(OIM
ConfigManager.java:2939)
```
アップグレード後の初めてのOIMサーバーの起動時に、12c (12.2.1.4.0)ブートストラップが自動的に起動し、サーバーは停止しません。

サーバーおよびプロセスの停止の詳細は、「サーバーとプロセスの停止」を参照してください。

サーバーとプロセスの起動
アップグレードが成功した後、管理サーバーおよび管理対象サーバーを含め、すべてのプロセスおよびサーバーを起動します。

サーバーとプロセスの起動

アップグレードが成功した後、管理サーバーおよび管理対象サーバーを含め、すべてのプロセスおよびサーバーを起動します。

コンポーネントは相互に依存していることがあるため、適切な順序で起動する必要があります。

ノート:

この項の手順では、WLSTコマンドラインまたはスクリプトを使用してサーバーとプロセスを起動する方法について説明します。Oracle Fusion Middleware ControlおよびOracle WebLogic Server管理コンソールを使用することもできます。『Oracle Fusion Middlewareの管理』の管理サーバーと管理対象サーバーおよびノード・マネージャの起動と停止に関する項を参照してください。

Fusion Middleware環境を起動するには、次に示すステップを実行します。

ステップ1: ノード・マネージャを起動する(構成されている場合)

管理サーバー<DOMAIN_HOME>/binの場所からノード・マネージャを起動します:

(UNIX) nohup ./startNodeManager.sh > <DOMAIN_HOME>/nodemanager/nodemanager.out 2>&1 &
(Windows) nohup .\startNodeManager.sh > <DOMAIN_HOME>\nodemanager\nodemanager.out 2>&1 &

ここで、<DOMAIN_HOME>は管理サーバーのドメイン・ホームです。

ステップ2: 管理サーバーの起動

管理サーバーを起動する場合、管理サーバーで稼働しているWebLogic Server管理コンソールやFusion Middleware Controlなどのプロセスも起動します。

管理サーバーを起動するためにnodemanagerを使用しない場合は、startWebLogicスクリプトを使用します:

(UNIX) DOMAIN_HOME/bin/startWebLogic.sh
(Windows) DOMAIN_HOME\bin\startWebLogic.cmd

プロンプトが表示されたら、管理サーバーのユーザー名とパスワード、およびURLを入力します。

ステップ3: 管理対象サーバーを起動する

WebLogic Server管理対象サーバーを起動するには、startManagedWebLogicスクリプトを使用します。

(UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
(Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url

プロンプトが表示されたらユーザー名とパスワードを入力します。

ノート:

通常、管理対象サーバーを起動すると、そのサーバーにデプロイされているアプリケーションが開始されます。したがって、管理対象サーバーの起動後にアプリケーションを手動で開始する必要はありません。
12cでは、モバイル・セキュリティ・マネージャ(MSM)サーバーはサポートされていません。サーバーの再起動後に、MSMサーバーの11g構成(omsm_server1やWLS_MSM1など)が残る場合があります。これらの構成は無視してください。MSMサーバーを再起動しないでください。

親トピック: サーバーの起動

ドメイン固有コンポーネント構成のアップグレードの確認

ドメイン固有コンポーネント構成のアップグレードが成功したことを確認するには、管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlにサインインし、各コンポーネントのバージョン番号が12.2.1.4.0になっていることを確認します。

管理コンソールにサインインするには、次に移動します。http://administration_server_host:administration_server_port/console

Oracle Enterprise Manager Fusion Middleware Control Consoleにサインインするには、次に移動します。http://administration_server_host:administration_server_port/em

Oracle Identity Manager Design Consoleのアップグレード

Oracle Identity Manager (OIM)ドメイン・コンポーネント構成をアップグレードした後、Oracle Identity Manager Design Consoleをアップグレードします。

Oracle Identity Manager Design Consoleをアップグレードするには、次のステップを完了します。

12c (12.2.1.4.0) designconsole/config/xlconfig.xmlを12c (12.2.1.3.0) designconsole/config/xlconfig.xmlファイルで置換します。
以前のバージョンでDesign Consoleが構成されていない場合、Design Consoleを起動すると、OIM管理対象サーバーのホスト名とポート値がデフォルト変数に変更されます。デザイン・コンソールの起動ウィンドウで、URLをインストールに適した値に更新します。

アップグレード後タスク

Oracle Access Managerを12c (12.2.1.4)にアップグレードした後、必要に応じてこの項にまとめられたタスクを完了する必要があります。

この項には次のトピックが含まれます:

カスタム構成のコピー
カスタム・アプリケーションの処理
ADF DI Excelプラグインの再インストール
Oracle Identity Managerを12c (12.2.1.4.0)にアップグレードした後、ADF DI Excelプラグインをアンインストールした後再インストールしてから、Excelを再ダウンロードします。
パッチ適用アクティビティの完了
LDAPSyncを使用する場合のOIDコネクタへの移行
レガシー・コネクタのシステム・プロパティの定義
WebLogic Serverセッション・レプリケーションの最大メッセージ・サイズの増加
setDomainEnv.shのmaxdepth値を増やす
アップグレード後のJMSおよびTLOG永続ストアの変更