4 Oracle Identity Manager高可用性環境のアップグレード
Oracle Identity Manager高可用性環境の12c (12.2.1.3.0)からOracle Identity Governance 12c (12.2.1.4.0)へのアップグレード・プロセスについて説明します。
ノート:
- ローリング・アップグレード・プロセスを使用して、高可用性環境を12c (12.2.1.3)から12 (12.2.1.4)に停止時間なしでアップグレードできます。
- このガイドでは、Oracle Identity Manager製品は、Oracle Identity Manager (OIM)およびOracle Identity Governance (OIG)とほぼ同じ意味で使用されます。
トピック
- Oracle Identity Managerマルチノードのアップグレード・プロセスについて
Oracle Identity Manager高可用性環境のアップグレード・プロセスの概要に関するトポロジおよびロードマップを確認します。 - Oracle Identity Managerのアップグレード前のタスクの完了
Oracle Identity Managerをアップグレードする前にこの項で説明しているアップグレード前のタスクを完了します。 - OIMHOST1でのサーバーとプロセスの停止
スキーマと構成をアップグレードする前に、すべてのアップグレード前のプロセスとサーバー(アップグレードするOracleホームの外部で実行されているOIMHOST1上の管理サーバー、ノード・マネージャおよび管理対象サーバーを含む)を停止する必要があります。 - OIMHOST上の12c (12.2.1.3.0) Oracle Homeフォルダのバックアップ
OIMHOST1とOIMHOST2の両方で、12c (12.2.1.3.0) Oracleホームをバックアップします。 - OIMHOST1でのソフトウェアのアンインストール
この項の手順に従い、アンインストール・ウィザードを起動してソフトウェアを削除します。 - OIMHOST1への製品ディストリビューションのインストール
12c (12.2.1.3) Oracleホームからソフトウェアをアンインストールした後、12c (12.2.1.4)バイナリを同じOracleホームにインストールします。 - OIMHOST1でのJDKの場所の更新
12c (12.2.1.3.0)から12c (12.2.1.4.0)へのアップグレードの際に、再構成ウィザードは使用されません。そのため、ドメイン・ホーム内で最新のJDKバージョンが自動更新されることはありません。 - アップグレード前の準備状況チェックの実行
アップグレードにかかわる潜在的な問題を特定するために、アップグレード・プロセスの開始前に、準備状況チェックの実行をお薦めします。準備状況チェックによって、アップグレードにかかわる潜在的な問題をすべて検出できるわけではない点に注意してください。準備状況チェックのレポートが成功を示していても、アップグレードが失敗することもあります。 - OIMHOST1からのスキーマのアップグレード
Upgrade Assistantを使用して、OIMHOST1からOracle Identity Managerに必要なすべてのスキーマをアップグレードします。 - OIMHOST1におけるドメイン・コンポーネント構成のアップグレード
Upgrade Assistantを使用して、ドメイン内のドメイン・コンポーネントの構成を、更新されたドメイン構成と一致するようにアップグレードします。 - ドメイン固有コンポーネント構成のアップグレードの確認
ドメイン固有コンポーネント構成のアップグレードが成功したことを確認するには、管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlにサインインし、各コンポーネントのバージョン番号が12.2.1.4.0であることを確認します。 - setDomainEnv.shファイルの更新
Oracle Identity Governance (OIG)を12c (12.2.1.3.0)から12c (12.2.1.4.0)にアップグレードするためには、setDomainEnv.sh
ファイル内のプロパティを削除する必要があります。 - OIMHOST1でのOIMブートストラップの実行
OIMHOST1でOracle Identity Managerをアップグレードした後、サーバーを再起動します。 - カスタム・アプリケーションの処理
- OIMHOST1でのドメイン構成のパック
OIMHOST1でドメイン・コンポーネント構成をアップグレードした後、アップグレードしたドメインをOIMHOST1でパックします。これは、後からOIMHOST2で解凍する必要があります。 - サーバーおよびプロセスの起動
アップグレードが成功したら、手動で起動した可能性のあるサーバーを停止し、管理サーバーと管理対象サーバーを含め、すべてのプロセスおよびサーバーを再起動します。 - OIMHOST2でのサーバーとプロセスの停止
スキーマと構成をアップグレードする前に、すべてのアップグレード前のプロセスとサーバー(OIMHOST2上の管理サーバー、ノード・マネージャおよび管理対象サーバーを含む)を停止する必要があります。 - OIMHOST2でのバイナリのアップグレード
これらのステップは、OIMHOST2がOIMHOST1とは異なるバイナリの場所を使用している場合にのみ実行する必要があります。 - 各OIMHOST上でのドメイン構成のレプリケーション
OIMHOST2上でドメイン構成をレプリケートします。これには、OIMHOST1でパックされたアップグレード済みのドメインをOIMHOST2で解凍する操作が含まれます。 - 12c (12.2.1.4.0) Oracleホームへのoracle.iam.ui.custom-dev-starter-pack.warのコピー
アップグレード後タスクの一部として、構成アップグレードのためにUpgrade Assistantを実行した後、12.2.1.3.0 Oracleホームのバックアップからのoracle.iam.ui.custom-dev-starter-pack.war
ファイルを手動で12c (12.2.1.4.0) Oracleホームにコピーします。 - OIMHOST2上でのサーバーの起動
OIMHOST2でOracle Identity Managerをアップグレードした後、サーバーを再起動します。 - アップグレード後タスク
Oracle Access Managerを12c (12.2.1.4)にアップグレードした後、必要に応じてこの項にまとめられたタスクを完了する必要があります。
Oracle Identity Managerマルチノードのアップグレード・プロセスについて
Oracle Identity Manager高可用性環境のアップグレード・プロセスの概要に関するトポロジおよびロードマップを確認します。
既存のドメインをアップグレードするために実行するステップは、ドメインがどのように構成されているか、およびどのコンポーネントをアップグレードするかによって異なります。各自のデプロイメントに該当するステップにのみ従ってください。
トポロジのアップグレード
次のトポロジに、この章で説明している手順に従って12c (12.2.1.4.0)にアップグレード可能なOracle Identity Managerクラスタを示します。
-
Oracle Identity ManagerインスタンスはWLS_OIM1管理対象サーバーにインストールされており、SOAインスタンスはWLS_SOA1管理対象サーバーにインストールされています。
-
WebLogic管理サーバーがインストールされています。通常の運用時は、これがアクティブ管理サーバーになります。
OIMHOST2では、次のインストールが実行されています。
-
Oracle Identity ManagerインスタンスはWLS_OIM2管理対象サーバーにインストールされており、SOAインスタンスはWLS_SOA2管理対象サーバーにインストールされています。
-
WebLogic管理サーバーがインストールされています。通常の運用時は、これがパッシブ管理サーバーになります。OIMHOST1の管理サーバーが使用できなくなった場合は、この管理サーバーをアクティブにします。
OIMHOST1およびOIMHOST2上のWLS_OIM1およびWLS_OIM2管理対象サーバーのインスタンスは、OIM_CLUSTERクラスタとして構成されています。
OIMHOST1およびOIMHOST2上のWLS_SOA1およびWLS_SOA2管理対象サーバーのインスタンスは、SOA_CLUSTERクラスタとして構成されています。
ローリング・アップグレードの実行
- トポロジ内の各ホストでローカル・バイナリ・インストールが使用されている場合。
- 共有記憶域で複数の冗長バイナリ・インストールを使用する場合。
前述のいずれかの条件に該当する場合は、各バイナリ・インストールに関連付けられたホストを個別にアップグレードできます。つまり、いくつかの管理対象サーバーでOracle Identity Manager 12c (12.2.1.3)を実行し、他のサーバーではOracle Identity Manager 12c (12.2.1.4)を使用できます。
ノート:
この方法に従っている場合は、クラスタのすべてのメンバーが同じバージョンで実行されるようになるまで、OIMシステム管理コンソールを使用しないでください。ローリング・アップグレードに関する考慮事項:
アップグレード前に、OIMアプリケーション・セッションをreplicated_if_clusteredモードからmemoryモードに移行します。この設定では、一方のノードのフェイルオーバーはもう一方のノードによって処理されません。ノードがクラッシュした場合、そのノード上のすべてのユーザー・セッションが失われます。ログインして、ノードがクラッシュしたときに進行中であった操作を再実行する必要があります。
- バイナリ・インストールOracleホーム12c (12.2.1.3.0)で、次のファイルについて、セッション記述子をreplicated_if_clusteredからmemoryに変更します:
<12c_oracle_home>/idm/server/apps/oim.ear/xlWebApp.war/WEB-INF/weblogic.xml
-
<12c_oracle_home>/idm/server/apps/oim.ear/iam-consoles-faces.war/WEB-INF/weblogic.xml
たとえば: 変更前
変更後<session-descriptor> <persistent-store-type>replicated_if_clustered</persistent-store-type> <cookie-name>oimjsessionid</cookie-name> <url-rewriting-enabled>false</url-rewriting-enabled> </session-descriptor>
<session-descriptor> <persistent-store-type>memory</persistent-store-type> <cookie-name>oimjsessionid</cookie-name> <url-rewriting-enabled>false</url-rewriting-enabled> </session-descriptor>
- ステップ1で変更したすべての管理対象サーバーを再起動します。
- ノード1で、12c (12.2.1.4.0)バイナリをインストールした後、ファイル
<12c_oracle_home>/idm/server/apps/oim.ear/iam-consoles-faces.war/WEB-INF/weblogic.xml
について、セッション記述子をreplicated_if_clusteredからmemoryに変更します。ノート:
xlWebAppは、12c (12.2.1.4.0)バイナリに存在しません。 - WebLogic管理サーバーのアップグレードを進めた後、アップグレードするOracle_Homeから実行されている各管理対象サーバーのアップグレードを行います。
完了したら、他のOracle_Homeインストールに関連付けられている管理対象サーバーのアップグレードを続行します。
ノート:
この場合、Oracle_Homeは、アップグレードに使用するOracleバイナリのインストールを指します。ローカル・バイナリ・インストールを使用している場合はノードを一度にアップグレードし、冗長な共有記憶域インストールを使用している場合は共有記憶域バイナリ・インストールに関連付けられているすべてのノードをアップグレードします。 - すべてのノードを12c (12.2.1.4.0)にアップグレードした後で、再度
replicated_if_clustered
モードに切り替えることができます。
表4-1 Oracle Identity Manager高可用性環境のアップグレードのためのロードマップ
タスク | 説明 |
---|---|
必須 このガイドの概要に関するトピックを再確認して、アップグレード前のタスクを完了します(まだ実行していない場合)。 |
参照: |
必須 Oracle Identity Managerに固有の必要なアップグレード前のタスクを完了します。 |
|
OIMHOST1で必須 アップグレードするOracleホームから実行されている12cサーバーを停止します。これには管理サーバー、管理対象サーバー、ノード・マネージャ、およびOracle HTTP Serverなどのシステム・コンポーネントが含まれます。 アップグレード中、データベースが稼働していることを確認してください。 |
警告: アップグレード中にサーバーを停止しないと、データが破壊される可能性があります。 |
必須 OIMHOST上の既存の12c (12.2.1.3.0) Oracleホーム・フォルダのバックアップを作成します |
「OIMHOST上の12c (12.2.1.3.0) Oracleホーム・フォルダのバックアップ」を参照してください。 ノート: 12c (12.2.1.3.0)で行われたUIのカスタマイズ(oracle.iam.ui.custom-dev-starter-pack.war ファイル)をバックアップします。
|
OIMHOST1で必須 OIMHOST1で、既存のOracleホームのOracle Fusion Middleware InfrastructureおよびOracle Identity Manager 12c (12.2.1.3.0)をアンインストールします。 |
「OIMHOST1でのソフトウェアのアンインストール」を参照してください。 |
OIMHOST1で必須 OIMHOST1で、OracleホームにInfrastructure (JRF) 12c (12.2.1.4.0)、Oracle SOA Suite 12c (12.2.1.4.0)およびOracle Identity Manager 12c (12.2.1.4.0)をインストールします。 |
「OIMHOSTへの製品ディストリビューションのインストール」を参照してください。 |
OIMHOST1で必須 JDKの場所を更新します |
「OIMHOST1でのJDKの場所の更新」を参照してください。 |
省略可能 アップグレード前の準備状況チェックを実行します。 |
「アップグレード前の準備状況チェックの実行」を参照してください。 |
OIMHOST1で必須 OIMHOST1上の必要なスキーマをアップグレードします。 |
「OIMHOST1におけるスキーマのアップグレード」を参照してください。 |
OIMHOST1で必須 Upgrade Assistantを使用して、OIMHOST1上のOracle Identity Manager構成をアップグレードします。 |
Upgrade Assistantは、ドメインのコンポーネント構成を更新するために使用します。 「ドメイン・コンポーネント構成のアップグレード」を参照してください。 ノート: jce は、無制限強度の暗号化ポリシーを使用する必要があります。
|
必須 ドメイン固有コンポーネント構成が正常に完了したことを確認します。 |
「ドメイン固有コンポーネント構成のアップグレードの確認」を参照してください。 |
OIMHOST1で必須
|
「setDomainEnv.shファイルの更新」を参照してください。 |
OIMHOST1で必須 アップグレード後にブートストラップを実行します。 |
「OIMHOST1でのOIMブートストラップの実行」を参照してください |
OIMHOST1で必須 カスタム・アプリケーションを処理します。 |
「カスタム・アプリケーションの処理」を参照してください。 |
OIMHOST1で必須 OIMHOST1でのドメインのパック |
「OIMHOST1でのドメイン構成のパック」を参照してください。 |
OIMHOST1で必須 アップグレードが成功したら、すべてのプロセスおよびサーバーを再起動します。 |
「サーバーとプロセスの起動」を参照してください。 |
OIMHOST2で必須 他のクラスタ・ノード上にサーバーが存在する場合は、それらを停止します。これには、SOAサーバー、OIMサーバーおよびノード・マネージャが含まれます。 アップグレード中、データベースが稼働していることを確認してください。 |
警告: アップグレード中にサーバーを停止しないと、データが破壊される可能性があります。 「OIMHOST2でのサーバーとプロセスの停止」を参照してください。 |
省略可能 OIMHOST2でバイナリをアップグレードします。 |
「OIMHOST2でのバイナリのアップグレード」を参照してください。 |
OIMHOST2で必須 OIMHOST2上、およびアップグレードするOracleホームがサービスを提供する各ホスト上に、ドメイン構成をレプリケートします。 |
これには、OIMHOST2でのドメインの解凍も含まれます。 「各OIMHOST上でのドメイン構成のレプリケーション」を参照してください。 |
すべてのホストで必須 すべてのホスト上で、 |
「12c (12.2.1.4.0) Oracleホームへのoracle.iam.ui.custom-dev-starter-pack.warのコピー」を参照してください。 |
OIMHOST2で必須 推奨される順序でサーバーを起動します。また、次のサーバーを起動する前に、各サーバーが起動されて稼働していることを確認してください。 |
「OIMHOST2でのサーバーの起動」を参照してください。 |
省略可能 アップグレード後のタスクを実行します。 |
「アップグレード後のタスク」を参照してください。 |
ノート:
HA環境の他のノードで、OIMHOST2で実行したすべてのステップを繰り返します。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に関するメモリーの問題を回避するため、要件に従ってメモリー設定が更新されていることを確認します。
root
ユーザーとして次を実行します:
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が破損する可能性があります。
OIMHOST1でのサーバーとプロセスの停止
スキーマと構成をアップグレードする前に、すべてのアップグレード前のプロセスとサーバー(アップグレードするOracleホームの外部で実行されているOIMHOST1上の管理サーバー、ノード・マネージャおよび管理対象サーバーを含む)を停止する必要があります。
Oracle Fusion Middleware環境は、Oracle WebLogic Serverドメイン、管理サーバー、複数の管理対象サーバー、Javaコンポーネント、アイデンティティ管理コンポーネントなどのシステム・コンポーネント、およびメタデータのリポジトリに使用されるデータベースで構成できます。コンポーネントは相互に依存していることがあるため、適切な順序で停止する必要があります。
ノート:
- この項の手順では、WLSTコマンドライン・ユーティリティまたはスクリプトを使用して、既存のアップグレード前のサーバーとプロセスを停止する方法について説明します。Oracle Fusion Middleware ControlおよびOracle WebLogic Server管理コンソールを使用することもできます。「管理サーバー、管理対象サーバーおよびノード・マネージャの起動と停止」を参照してください。
- データベース以外、デプロイメントにあるすべてのサーバーを停止します。アップグレード・プロセス中、データベースが稼働している必要があります。
アップグレード前のFusion Middleware環境を停止するには、アップグレード前のドメインに移動して次のステップを実行します。
ステップ1: 管理対象サーバーを停止する
管理対象サーバーの起動方法に応じて、次のいずれかの方法に従ってWebLogic管理対象サーバーを停止します:
-
(UNIX)
DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url
-
(Windows)
DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url
プロンプトが表示されたらユーザー名とパスワードを入力します。
weblogic
管理者としてWeblogicコンソールにログインします。- 「サーバー」 > 「制御」タブに移動します。
- 必要な管理対象サーバーを選択します。
- 「停止」をクリックします。
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など)も停止します。
次のいずれかの方法に従って、管理サーバーを停止します:
-
(UNIX)
DOMAIN_HOME/bin/stopWebLogic.sh
-
(Windows)
DOMAIN_HOME\bin\stopWebLogic.cmd
プロンプトが表示されたら、管理サーバーのユーザー名とパスワード、およびURLを入力します。
weblogic
管理者としてWeblogicコンソールにログインします。- 「サーバー」 > 「制御」タブに移動します。
- 必要な管理サーバーを選択します。
- 「停止」をクリックします。
wls:/offline>nmConnect('nodemanager_username','nodemanager_password',
'AdminServerHostName','5556','domain_name',
'DOMAIN_HOME','nodemanager_type')
wls:/offline>nmKill('AdminServer')
ステップ3: ノード・マネージャを停止する
ノード・マネージャを停止するには、次のコマンドを実行します:
<DOMAIN_HOME>/bin/stopNodeManager.sh
OIMHOST上の12c (12.2.1.3.0) Oracleホーム・フォルダのバックアップ
OIMHOST1とOIMHOST2の両方で、12c (12.2.1.3.0) Oracleホームをバックアップします。
たとえば:
/u01/app/fmw/ORACLE_HOME
を/u01/app/fmw/ORACLE_HOME_old
にします
ノート:
カスタム構成は必ずバックアップしてください。これらの構成は、アップグレード後にリストアします。OIMHOST1でのソフトウェアのアンインストール
この項の手順に従ってアンインストール・ウィザードを起動し、ソフトウェアを削除します。
サイレント(コマンドライン)・モードの製品のアンインストールを実行する場合は、『Oracle Universal Installerによるソフトウェアのインストール』のサイレント・アンインストールのためのOracle Universal Installerの実行に関する項を参照してください。
ソフトウェアをアンインストールするには、これらのステップに従います:
アンインストールする製品の選択
Oracleホームには複数の製品が存在するため、各製品をアンインストールするようにしてください。この場所に最新の製品ディストリビューションをインストールします。インストーラでは、ディレクトリを空にする必要があります。
アンインストール・ウィザードの起動時に、「アンインストールする配布」画面が開きます。
ドロップダウン・メニューからOracle Fusion Middleware 12c (12.2.1.4.0) Identity and Access Management 12.2.1.3.0製品を選択し、「アンインストール」をクリックします。
アンインストールが完了したら、すべての製品が削除されるまで、Oracleホームの追加製品ごとにアンインストール・プロセスを再実行します。
アンインストール・プログラムには、「アンインストール・ウィザード画面のナビゲート」に示されている画面が表示されます。
親トピック: OIMHOST1でのソフトウェアのアンインストール
「アンインストール・ウィザード」画面のナビゲート
アンインストール・ウィザードには、ソフトウェアの削除を確認する一連の画面が表示されます。
次の表に示した画面についてのヘルプが必要な場合には、画面上の「ヘルプ」をクリックしてください。
表4-2 アンインストール・ウィザード画面および説明
画面 | 説明 |
---|---|
ようこそ |
製品のアンインストール・ウィザードに案内します。 |
アンインストールのサマリー |
アンインストールされるOracleホーム・ディレクトリとその内容を示します。これが正しいディレクトリであることを確認してください。 これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を入力します。後でレスポンス・ファイルを使用して、サイレント(コマンドライン)・モードで製品をアンインストールできます。『Oracle Universal Installerによるソフトウェアのインストール』のサイレント・アンインストール用のOracle Universal Installerの実行に関する項を参照してください。 「アンインストール」, をクリックしてソフトウェアの削除を開始します。 |
アンインストールの進行状況 |
アンインストールの進行状況を表示します。 |
アンインストールの完了 |
アンインストールが完了すると表示されます。この画面の情報を確認してから、「終了」をクリックしてアンインストール・ウィザードを閉じます。 |
ノート:
インストールでuser_projects
ドメイン・ホーム情報がORACLE_HOMEディレクトリにある場合: user_projects
ディレクトリとdomain-registry.xml
ファイルを除き、<OIM_HOME>の下のすべてのファイルとディレクトリを削除します。
インストールでuser_projects
ドメイン・ホーム情報がORACLE_HOME以外のディレクトリにある場合: domain-registry.xml
ファイルを除き、<OIM_HOME>の下にあるすべてのファイルとディレクトリを削除します。
製品をアンインストールした後、ORACLE_HOMEおよび残りのファイルを手動で削除します。ディレクトリを空にしないと、インストールを続行できません。
親トピック: OIMHOST1でのソフトウェアのアンインストール
OIMHOST1への製品ディストリビューションのインストール
12c (12.2.1.3) Oracleホームからソフトウェアをアンインストールした後、12c (12.2.1.4)バイナリを同じOracleホームにインストールします。
OIMHOST1に次の製品をインストールします:
-
Oracle Fusion Middleware Infrastructure 12c (12.2.1.4.0)
-
Oracle SOA Suite 12c (12.2.1.4.0)
-
Oracle Identity Manager 12c (12.2.1.4.0)
ノート:
共有記憶域から製品をアンインストールした場合は、共有記憶域および冗長な場所に再インストールする必要があります。各OIMホストから製品をアンインストールした場合は、各OIMホストに再インストールする必要があります。- 製品ディストリビューションのインストール
アップグレードの開始前に、Oracle Fusion Middleware Infrastructure、Oracle SOA SuiteおよびOracle Identity Manager 12c (12.2.1.4.0)のディストリビューションをターゲット・システムにダウンロードし、次のコマンドを使用して既存の12c (12.2.1.3.0) Oracleホームにインストールします。
製品ディストリビューションのインストール
アップグレードの開始前に、Oracle Fusion Middleware Infrastructure、Oracle SOA SuiteおよびOracle Identity Manager 12c (12.2.1.4.0)のディストリビューションをターゲット・システムにダウンロードし、次のコマンドを使用して既存の12c (12.2.1.3.0) Oracleホームにインストールします。
ノート:
- Oracle Identity ManagerをホストしているすべてのノードにJava Development Kit (JDK) 1.8.0_211以降がインストールされていることを確認します。
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.
ノート:
アップグレードに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))を個別にインストールすることもできます。これを行うには、次のステップを実行します:
ノート:
他のOIMノードでも製品のインストールを実行するには、次の手順に従います。Oracle Identity Manager 12c (12.2.1.4.0)のインストールの詳細は、『Oracle Identity and Access Managementのインストールおよび構成』のOracle Identity and Access Managementソフトウェアのインストールに関する項を参照してください。
OIMHOST1でのJDKの場所の更新
12c (12.2.1.3.0)から12c (12.2.1.4.0)へのアップグレードの際に、再構成ウィザードは使用されません。そのため、ドメイン・ホーム内で最新のJDKバージョンが自動更新されることはありません。
12c (12.2.1.4.0)にアップグレードした後、ドメイン・ホームで現在の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のパラメータ
コマンドラインからUpgrade Assistantを起動するときに、追加のパラメータを指定できます。
表4-3 アップグレード・アシスタントのコマンドライン・パラメータ
パラメータ | 必須またはオプション | 説明 |
---|---|---|
|
準備状況チェックの場合は必須
ノート: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。 |
アップグレードの準備状況チェックを実行します(実際のアップグレードは実行しません)。 スキーマと構成がチェックされます。
|
|
オプション |
スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を特定します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。 |
|
サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須 |
Upgrade AssistantがGUIモードで実行されているときに入力したデータから生成されるレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、Upgrade Assistantはサイレント・モード(Upgrade Assistantの画面表示なし)で実行されます。 |
|
オプション |
調査フェーズを実行しますが、実際のアップグレードは実行しません。
|
|
オプション |
次のいずれかの属性を指定して、ログイン・レベルを設定します。
デフォルトのロギング・レベルは
|
|
オプション |
アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。 デフォルトの場所は次のとおりです。 (UNIX)
(Windows)
|
|
オプション |
すべてのコマンドライン・オプションを表示します。 |
Upgrade Assistantを使用した準備状況チェックの実行
Upgrade Assistantの各画面を通じて、アップグレード前の準備状況チェックを完了します。
親トピック: アップグレード前の準備状況チェックの実行
準備状況レポートの理解
ドメインの準備状況チェックを実行した後、レポートを確認してアップグレードを成功させるためのアクションをとる必要があるかどうかを判断します。
準備状況レポート・ファイルの形式は、次のとおりです。
readiness<timestamp>.txt
timestamp
は、準備状況チェックが実行された日時を示します。
準備状況レポートには、次の情報が含まれています。
表4-4 準備状況レポートの要素
レポートの情報 | 説明 | 必要なアクション |
---|---|---|
全体的な準備状況ステータス: SUCCESSまたはFAILURE | レポートの上部に、準備状況チェックが合格したか1つ以上のエラーで完了したかが示されます。 | 1つ以上のエラーが発生してレポートが完了した場合、アップグレードを試みる前に、FAILを検索し、障害の原因となった問題を修正します。準備状況チェックは、アップグレードする前に必要に応じて何度でも再実行できます。 |
タイムスタンプ |
レポートが生成された日付と時刻です。 |
必要なアクションはありません。 |
ログ・ファイルの場所
|
生成されたログ・ファイルのディレクトリの場所です。 |
必要なアクションはありません。 |
ドメイン・ディレクトリ | ドメインの場所が表示されます | 必要なアクションはありません。 |
準備状況レポートの場所
|
生成された準備状況レポートのディレクトリの場所です。 |
必要なアクションはありません。 |
チェックされたコンポーネントの名前 |
チェックに含まれるコンポーネントの名前およびバージョンとステータス。 |
ドメインに、このリリースにアップグレードできない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.
親トピック: アップグレード前の準備状況チェックの実行
OIMHOST1からの製品スキーマのアップグレード
Upgrade Assistantを使用して、OIMHOST1からOracle Identity Managerに必要なすべてのスキーマをアップグレードします。
- 製品スキーマのアップグレード
サーバーとプロセスの停止後に、Upgrade Assistantを使用して、サポートされている製品スキーマをOracle Fusion Middlewareの現在のリリースにアップグレードします。
製品スキーマのアップグレード
サーバーとプロセスの停止後に、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='*';
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
のスキーマ・バージョンが適切に更新されていることをチェックして、アップグレードの成功を検証します。
親トピック: OIMHOST1からの製品スキーマのアップグレード
アップグレードに対応可能な既存のスキーマの特定
このオプションの作業では、スキーマ・バージョン・レジストリを問い合せることで、アップグレードの開始前に、使用可能スキーマのリストを確認できます。レジストリには、バージョン番号、コンポーネント名および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を起動する前に、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
- (UNIX)
- JVMエンコーディング要件を含むようにUpgrade Assistantのパラメータを設定します:
- (UNIX)
export UA_PROPERTIES="-Dfile.encoding=UTF-8"
- (Windows)
set UA_PROPERTIES="-Dfile.encoding=UTF-8"
- (UNIX)
- Upgrade Assistantを起動します。
- (UNIX) ./ua
- (Windows) ua.bat
ノート:
前述のコマンドで、ORACLE_HOME
は12c (12.2.1.4.0) Oracleホームを示しています。
コマンドラインに指定可能なその他のパラメータ(ロギングのパラメータなど)の詳細は、次を参照してください。
Upgrade Assistantのパラメータ
コマンドラインからUpgrade Assistantを起動するときに、追加のパラメータを指定できます。
表4-5 アップグレード・アシスタントのコマンドライン・パラメータ
パラメータ | 必須またはオプション | 説明 |
---|---|---|
|
準備状況チェックの場合は必須
ノート: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。 |
アップグレードの準備状況チェックを実行します(実際のアップグレードは実行しません)。 スキーマと構成がチェックされます。
|
|
オプション |
スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を特定します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。 |
|
サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須 |
Upgrade AssistantがGUIモードで実行されているときに入力したデータから生成されるレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、Upgrade Assistantはサイレント・モード(Upgrade Assistantの画面表示なし)で実行されます。 |
|
オプション |
調査フェーズを実行しますが、実際のアップグレードは実行しません。
|
|
オプション |
次のいずれかの属性を指定して、ログイン・レベルを設定します。
デフォルトのロギング・レベルは
|
|
オプション |
アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。 デフォルトの場所は次のとおりです。 (UNIX)
(Windows)
|
|
オプション |
すべてのコマンドライン・オプションを表示します。 |
親トピック: Upgrade Assistantの起動
Upgrade Assistantを使用したOracle Identity Managerスキーマのアップグレード
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ユーザーを元に戻します。親トピック: 製品スキーマのアップグレード
OIMHOST1におけるドメイン・コンポーネント構成のアップグレード
Upgrade Assistantを使用して、ドメイン内のドメイン・コンポーネント構成を、更新されたドメイン構成に一致するようにアップグレードします。
ノート:
この手順は、OIMHOST1でのみ実行します。- ドメイン・コンポーネント構成のアップグレード
Upgrade Assistantを使用して、ドメイン内のドメイン・コンポーネント構成を、更新されたドメイン構成と一致するようにアップグレードします。
ドメイン・コンポーネント構成のアップグレード
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を実行して、製品のスキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.4.0)にアップグレードします。一度に1つのドメインのアップグレードを完了して、Upgrade Assistantを非SYSDBAユーザーとして実行することをお薦めします。
ノート:
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
- (UNIX)
- JVMエンコーディング要件を含むようにUpgrade Assistantのパラメータを設定します:
- (UNIX)
export UA_PROPERTIES="-Dfile.encoding=UTF-8"
- (Windows)
set UA_PROPERTIES="-Dfile.encoding=UTF-8"
- (UNIX)
- Upgrade Assistantを起動します。
- (UNIX) ./ua
- (Windows) ua.bat
ノート:
前述のコマンドで、ORACLE_HOME
は12c (12.2.1.4.0) Oracleホームを示しています。
コマンドラインに指定可能なその他のパラメータ(ロギングのパラメータなど)の詳細は、次を参照してください。
親トピック: ドメイン・コンポーネント構成のアップグレード
Oracle Identity Managerドメイン・コンポーネント構成のアップグレード
Upgrade Assistantの各画面を通じて、WebLogicドメインのコンポーネント構成をアップグレードします。
Upgrade Assistantを実行して、ドメイン・コンポーネント構成を、更新されたドメイン構成に一致するようにアップグレードします。
親トピック: ドメイン・コンポーネント構成のアップグレード
ドメイン固有コンポーネント構成のアップグレードの確認
ドメイン固有コンポーネント構成のアップグレードが成功したことを確認するには、管理コンソールおよび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
setDomainEnv.shファイルの更新
Oracle Identity Governance (OIG)を12c (12.2.1.3.0)から12c (12.2.1.4.0)にアップグレードするためには、setDomainEnv.sh
ファイル内のプロパティを削除する必要があります。
次のステップを実行します。
Oracle_Home/domains/<domain name>/bin/
にあるsetDomainEnv.sh
ファイルを開きます。- 次のように開始する行から次のパラメータを削除します:
EXTRA_JAVA_PROPERTIES="-Djavax.net.ssl.trustStore=${WL_HOME}/server/lib/DemoTrust.jks
パラメータは次のとおりです:
-Doracle.xdkjava.compatibility.version=11.1.1
setDomainEnv.sh
ファイルを保存して閉じます。
ノート:
- SOAの場合、
EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES}
で始まる行のsetSOADomainEnv.sh
ファイルに、引数として次のエントリを追加する必要があります。-Doracle.xdkjava.compatibility.version=11.1.1
- すべてのOIMホスト・マシンで、これらのステップを繰り返します。
OIMHOST1でのOIMブートストラップの実行
OIMHOST1でOracle Identity Managerをアップグレードした後、サーバーを再起動します。
ノート:
管理サーバーと管理対象サーバーが異なるディレクトリにあるエンタープライズ・デプロイメントを使用している場合は、管理サーバー・ディレクトリからサーバーを再起動して、ブートストラップ・プロセスを完了できるようにします。サーバーおよびプロセスの停止の詳細は、「サーバーとプロセスの停止」を参照してください。
カスタム・アプリケーションの処理
OIM 11gのデプロイメントにカスタム・アプリケーションおよびライブラリが存在する場合、OIM 12c (12.2.1.4)へのアップグレード後にそれらを手動で更新することをお薦めします。
OIMHOST1でのドメイン構成のパック
OIMHOST1でドメイン・コンポーネント構成をアップグレードした後、アップグレードしたドメインをOIMHOST1でパックします。これは、後からOIMHOST2で解凍する必要があります。
- OIMHOST1で、次のコマンドを
$ORACLE_HOME/oracle_common/common/bin
から実行して、アップグレード済のドメインをパックします:- UNIXの場合:
sh pack.sh -domain=<Location_of_OIM_domain> -template=<Location_where_domain_configuration_jar_to_be_created> -template_name="OIM Domain" -managed=true
- Windowsの場合:
pack.cmd -domain=<Location_of_OIM_domain> -template=<Location_where_domain_configuration_jar_to_be_created> -template_name="OIM Domain" -managed=true
- UNIXの場合:
- OIMHOST1でpackコマンドにより作成されたドメイン構成jarファイルを、アクセス可能な任意の場所にコピーします。
ノート:
エンタープライズ・デプロイメントをアップグレードする場合は、構成を管理対象サーバー・ディレクトリに抽出する必要があります。「各OIMHOST上でのドメイン構成のレプリケーション」を参照してください。サーバーとプロセスの起動
アップグレードが成功したら、手動で起動した可能性のあるサーバーを停止し、管理サーバーと管理対象サーバーを含め、すべてのプロセスおよびサーバーを再起動します。
コンポーネントは相互に依存していることがあるため、適切な順序で起動する必要があります。
ノート:
この項の手順では、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: 管理対象サーバーを起動する
オプション1
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
プロンプトが表示されたらユーザー名とパスワードを入力します。
ノート:
HA環境では、コンソールまたはノード・マネージャを使用してサーバーを起動することをお薦めします。オプション2
weblogic
管理者としてWeblogicコンソールにログインします。- 「サーバー」 > 「制御」タブに移動します。
- 必要な管理対象サーバーを選択します。
- 「起動」をクリックします。
ノート:
- 通常、管理対象サーバーを起動すると、そのサーバーにデプロイされているアプリケーションが開始されます。したがって、管理対象サーバーの起動後にアプリケーションを手動で開始する必要はありません。
- 12cでは、モバイル・セキュリティ・マネージャ(MSM)サーバーはサポートされていません。サーバーの再起動後に、MSMサーバーの11g構成(
omsm_server1
やWLS_MSM1
など)が残る場合があります。これらの構成は無視してください。MSMサーバーを再起動しないでください。
ステップ4: システム・コンポーネントを起動する
必要な場合、startComponent
スクリプトを使用して、Oracle HTTP Serverなどのシステム・コンポーネントを起動します:
-
(UNIX)
OHS_INSTANCE_HOME/bin/startComponent.sh ohs1
-
(Windows)
OHS_INSTANCE_HOME\bin\startComponent.sh ohs1
システム・コンポーネントは任意の順序で起動できます。
OIMHOST2でのサーバーとプロセスの停止
スキーマと構成をアップグレードする前に、すべてのアップグレード前のプロセスとサーバー(OIMHOST2上の管理サーバー、ノード・マネージャおよび管理対象サーバーを含む)を停止する必要があります。
Oracle Fusion Middleware環境は、Oracle WebLogic Serverドメイン、管理サーバー、複数の管理対象サーバー、Javaコンポーネント、アイデンティティ管理コンポーネントなどのシステム・コンポーネント、およびメタデータのリポジトリに使用されるデータベースで構成できます。コンポーネントは相互に依存していることがあるため、適切な順序で停止する必要があります。
OIMHOST1でサーバーおよびプロセスを停止するときに使用した同じプロセスに従います。「OIMHOST1でのサーバーとプロセスの停止」を参照してください。
OIMHOST2でのバイナリのアップグレード
これらのステップは、OIMHOST2がOIMHOST1とは異なるバイナリの場所を使用している場合にのみ実行する必要があります。
- OIMHOST2でのソフトウェアのアンインストール
アンインストール・ウィザードを使用して、既存のORACLE_HOMEからソフトウェアを削除します。このディレクトリに新しいソフトウェアを再インストールします。 - OIMHOST2への製品ディストリビューションのインストール
12c (12.2.1.3) Oracleホームからソフトウェアをアンインストールした後、12c (12.2.1.4)バイナリを同じOracleホームにインストールします。 - OIMHOST2でのJDKの場所の更新
12c (12.2.1.3.0)から12c (12.2.1.4.0)へのアップグレードの際に、再構成ウィザードは使用されません。そのため、ドメイン・ホーム内で最新のJDKバージョンが自動更新されることはありません。
OIMHOST2でのソフトウェアのアンインストール
アンインストール・ウィザードを使用して、既存のORACLE_HOMEからソフトウェアを削除します。このディレクトリに新しいソフトウェアを再インストールします。
ノート:
このステップは、OIMHOST2がOIMHOST1とは異なるバイナリ・セットを使用している場合にのみ必要です。サイレント(コマンドライン)・モードの製品のアンインストールを実行する場合は、『Oracle Universal Installerによるソフトウェアのインストール』のサイレント・アンインストールのためのOracle Universal Installerの実行に関する項を参照してください。
親トピック: OIMHOST2でのバイナリのアップグレード
OIMHOST2への製品ディストリビューションのインストール
12c (12.2.1.3) Oracleホームからソフトウェアをアンインストールした後、12c (12.2.1.4)バイナリを同じOracleホームにインストールします。
OIMHOST2に次の製品をインストールします:
-
Oracle Fusion Middleware Infrastructure 12c (12.2.1.4.0)
-
Oracle SOA Suite 12c (12.2.1.4.0)
-
Oracle Identity Manager 12c (12.2.1.4.0)
OIMHOST1でソフトウェアをインストールするときに使用した同じプロセスに従います。「製品ディストリビューションのインストール」を参照してください。
ノート:
Oracle_Home
のインストールを冗長にしている場合は、冗長な場所それぞれにバイナリをインストールします。
親トピック: OIMHOST2でのバイナリのアップグレード
OIMHOST2でのJDKの場所の更新
12c (12.2.1.3.0)から12c (12.2.1.4.0)へのアップグレードの際に、再構成ウィザードは使用されません。そのため、ドメイン・ホーム内で最新のJDKバージョンが自動更新されることはありません。
12c (12.2.1.4.0)にアップグレードした後、ドメイン・ホームで現在の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の場所の更新」を参照してください。
親トピック: OIMHOST2でのバイナリのアップグレード
各OIMHOST上でのドメイン構成のレプリケーション
OIMHOST2上でドメイン構成をレプリケートします。これには、OIMHOST1でパックされたアップグレード済みのドメインをOIMHOST2で解凍する操作が含まれます。
ノート:
EDGの方法に従っている場合は、OIMHOST1上のOIM管理対象サーバーの場所でドメインをパックおよび解凍する必要もあります。12c (12.2.1.4.0) Oracleホームへのoracle.iam.ui.custom-dev-starter-pack.war
のコピー
アップグレード後タスクの一部として、構成アップグレードのためにUpgrade Assistantを実行した後、12.2.1.3.0 Oracleホームのバックアップからのoracle.iam.ui.custom-dev-starter-pack.war
ファイルを手動で12c (12.2.1.4.0) Oracleホームにコピーします。
次のステップを実行します。
- 12.2.1.3.0バックアップ・フォルダから、
ORACLE_HOME/idm/server/apps/
に移動します - ファイル
oracle.iam.ui.custom-dev-starter-pack.war
をコピーします - 12c (12.2.1.4.0)リリースの場合、
ORACLE_HOME/idm/server/apps/
に移動して、コピーした.war
ファイルを貼り付けます。
ノート:
すべてのOIMホスト・マシンで、このステップを繰り返します。OIMHOST2でのサーバーの起動
OIMHOST2でOracle Identity Managerをアップグレードした後、サーバーを再起動します。
サーバーとプロセスの停止の詳細は、「サーバーとプロセスの停止」を参照してください。
アップグレード後タスク
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永続ストアの変更
カスタム構成のコピー
12c (12.2.1.3.0) Oracleホーム内にカスタム構成を設定した場合は、12c (12.2.1.3.0) Oracleホームのバックアップに存在するカスタム構成を12c (12.2.1.4.0) Oracleホームにコピーする必要があります。
例: 12c (12.2.1.3.0) Oracleホームのバックアップにある標準ディレクトリ(XLIntegrations
やconnectorResources
など)のすべての内容を、12c (12.2.1.4.0) Oracleホームの対応するディレクトリにコピーします。
同様に、スケジュール・ジョブ・パラメータが12c (12.2.1.3.0) Oracleホームのものを参照している場合、それを12c (12.2.1.3.0) Oracleホームのバックアップから12c (12.2.1.4.0) Oracleホームの対応するディレクトリにコピーします。
ノート:
「OIMHOST上の12c (12.2.1.3.0) Oracleホーム・フォルダのバックアップ」で作成したカスタム構成のバックアップは、このステップでリストアされます。親トピック: アップグレード後タスク
カスタム・アプリケーションの処理
OIM 11gのデプロイメントにカスタム・アプリケーションおよびライブラリが存在する場合、OIM 12c (12.2.1.4)へのアップグレード後にそれらを手動で更新することをお薦めします。
親トピック: アップグレード後タスク
ADF DI Excelプラグインの再インストール
Oracle Identity Managerを12c (12.2.1.4.0)にアップグレードした後、ADF DI Excelプラグインをアンインストールした後再インストールしてから、Excelを再ダウンロードします。
親トピック: アップグレード後タスク
パッチ適用アクティビティの完了
サーバーの再起動後、パッチ適用アクティビティを完了する必要があります。これらのアクティビティでは、サーバーが稼働している必要があります。起動後フェーズを完了するには、Oracle Identity Management製品のスタック・パッチ・バンドル(ドキュメントID 2657920.1)を参照してください。
起動後フェーズでは、post start
コマンドを使用して、インストール後のステップを完了します。この手順では、professionalization
ファイルを手動で更新し、patch_oim_wls.sh
スクリプトを実行する必要があります。
ノート:
スタック・パッチ・バンドルを更新するかわりに手動パッチ適用を実行した場合は、バンドル・パッチに含まれるREADME.txt
ファイルを使用して、システムの再起動後に実行される構成後のステップを完了します。この手順では、professionalization
ファイルを手動で更新し、patch_oim_wls.sh
スクリプトを実行する必要があります。
親トピック: アップグレード後タスク
LDAPSyncを使用する場合のOIDコネクタへの移行
11gデプロイメントのLDAPSync設定でコンテナ・ルールを使用している場合、変換および事前移入アダプタの一部としてLDAPContainersRule.xml
ファイルに定義されたルールを再実装するか、アクセス・ポリシーを活用できます。
- 『Oracle Identity Governanceでのセルフ・サービス・タスクの実行』のプロビジョニング属性とリコンシリエーション属性の検証と変換に関する項。
- 『Oracle Identity Governanceのためのアプリケーションの開発とカスタマイズ』の事前移入アダプタに関する項。
- 『Oracle Identity Governanceでのセルフ・サービス・タスクの実行』のアクセス・ポリシーの管理に関する項。
親トピック: アップグレード後タスク
レガシー・コネクタのシステム・プロパティの定義
tcITResourceInstanceOperationsBean.getITResourceInstanceParameters
メソッドを使用するリソース・アクセス制御ファシリティ(RACF)などのレガシー・コネクタの場合、次の2つのシステム・プロパティを作成し、その値をTrue
に更新する必要があります:
- サービス・アカウント暗号化パラメータ値
- サービス・アカウント・パラメータ値ストア
これらのシステム・プロパティの詳細は、『Oracle Identity Governanceの管理』のOracle Identity Governanceのデフォルト以外のシステム・プロパティに関する項の表18-2を参照してください。
レガシー・コネクタまたは古いカスタム・コードにレガシー動作が必要な場合にのみ、これらのシステム・プロパティを作成することをお薦めします。
親トピック: アップグレード後タスク
WebLogic Serverセッション・レプリケーションの最大メッセージ・サイズの増加
最大メッセージ・サイズをデフォルト値の10MBから100MBに変更することをお薦めします。この値は、ノード間でセッション・データをレプリケートするために使用されます。すべての管理対象サーバーおよび管理サーバーに対してこのステップを実行する必要があります。
- WebLogic Server管理コンソールにログインします。
- 「サーバー」に移動し、「プロトコル」を選択して、「一般」をクリックします。
- 「最大メッセージ・サイズ」の値を100MBに設定します。
親トピック: アップグレード後タスク
アップグレード後のJMSおよびTLOG永続ストアの変更
JMSおよびTLOG永続ストアは、Oracle Identity Manager 12c (12.2.1.4.0)へのアップグレード後も同じままです。つまり、永続ストアがアップグレード前にファイルベースである場合は、アップグレード後もファイルベースになります。
永続ストアをファイルベースのシステムからデータベースベースのシステムに変更する場合は、ステップを手動で実行する必要があります。「エンタープライズ・デプロイメントでのTLOGおよびJMSに対する永続ストアの使用」を参照してください。
親トピック: アップグレード後タスク