4 Oracle Access Manager高可用性環境のアップグレード
Oracle Access Manager高可用性環境の11gリリース2 (11.1.2.3.0)から12c (12.2.1.3.0)へのアップグレード・プロセスについて説明します。
トピック
- Oracle Access Managerマルチノードのアップグレード・プロセスについて
Oracle Access Manager高可用性環境のアップグレード・プロセスの概要に関するトポロジおよびロードマップを確認します。 - Oracle Access Managerのアップグレード前のタスクの完了
Oracle Access Managerをアップグレードする前に、この項で説明しているアップグレード前のタスクを完了します。 - OAMHOST1およびOAMHOST2上での12c Oracleホーム・フォルダの作成
OAMHOST1とOAMHOST2の両方に12c Oracleホームのためのフォルダを作成します。 - OAMHOST1およびOAMHOST2への製品ディストリビューションのインストール
12cバイナリをOAMHOST1およびOAMHOST2にインストールするか、または両方からアクセスできる共有ストレージにインストールする必要があります。冗長なバイナリを使用している場合は、必ず冗長な場所それぞれにインストールしてください - 最新のスタック・パッチ・バンドルのインストール
製品ディストリビューションをインストールした後、アップグレード・プロセスを続行する前に最新のIDMスタック・パッチ・バンドル(SPB) 12.2.1.3.0を適用することを強くお薦めします。Opatchツールを使用してパッチを適用できます。SPBを適用すると、アップグレードの問題や回避策の大部分が除去されます。 - OAMHOST1におけるスキーマのアップグレード
Upgrade Assistantを使用してOAMHOST1上のOracle Access Managerに必要なすべてのスキーマをアップグレードします。 - OAMHOST1におけるドメインの再構成
OAMHOST1上で再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.3.0)に再構成します。 - 各OAMHOST上でのドメイン構成のレプリケーション
OAMHOST2上でドメイン構成をレプリケートします。これには、OAMHOST1でのアップグレード済ドメインのパック実行およびOAMHOST2でのパックの解凍が含まれます。 - OAMHOST1およびOAMHOST2におけるドメイン・コンポーネント構成のアップグレード
ドメインの再構成後に、Upgrade Assistantを使用して、ドメイン内のドメイン・コンポーネント構成を、更新されたドメイン構成に一致するようにアップグレードします。 - OAMHOST1およびOAMHOST2上のサーバーの起動
OAMHOST1とOAMHOST2の両方でOracle Access Managerをアップグレードした後、サーバーを起動します。 - アップグレード後のタスクの実行
Oracle Access Managerを12c (12.2.1.3)にアップグレードした後、必要に応じてこの項にまとめられたタスクを完了する必要があります。 - パッチ後のインストール・ステップの実行
アップグレードが完了した後、パッチ後のインストール・ステップを実行する必要があります。
Oracle Access Managerマルチノードのアップグレード・プロセスについて
Oracle Access Manager高可用性環境のアップグレード・プロセスの概要に関するトポロジおよびロードマップを確認します。
既存のドメインをアップグレードするために実行するステップは、ドメインがどのように構成されているか、およびどのコンポーネントをアップグレードするかによって異なります。各自のデプロイメントに該当するステップにのみ従ってください。
アップグレード・トポロジ
次のトポロジは、この章で説明している手順に従うことにより12c (12.2.1.3.0)にアップグレード可能なOracle Access Managerクラスタ設定を示しています。
-
Oracle Access Management Access ManagerインスタンスがWLS_OAM1管理対象サーバーにインストールされています。
-
WebLogic管理サーバーがインストールされています。通常の運用時は、これがアクティブ管理サーバーになります。
OAMHOST2では、次のインストールが実行されています。
-
Oracle Access Management Access ManagerインスタンスがWLS_OAM2管理対象サーバーにインストールされています。
-
WebLogic管理サーバーがインストールされています。通常の運用時は、これがパッシブ管理サーバーになります。OAMHOST1の管理サーバーが使用できなくなった場合は、この管理サーバーをアクティブにします。
OAMHOST1およびOAMHOST2ホスト上のWLS_OAM1およびWLS_OAM2管理対象サーバーのインスタンスは、OAM_CLUSTERという名前のクラスタで構成されています。
表4-1 Oracle Access Manager高可用性環境のアップグレードのためのタスク
| タスク | 説明 |
|---|---|
|
必須 このガイドの概要に関するトピックを再確認して、アップグレード前のタスクを完了します(まだ実行していない場合)。 |
関連項目:
|
|
必須 Oracle Access Managerに固有の必要なアップグレード前タスクを完了します。 |
「Oracle Access Managerのアップグレード前のタスクの完了」を参照してください。 |
|
必須 製品ディストリビューションをインストールするための場所を使用できるようにするために、OAMHOST1およびOAMHOST2の両方に12c Oracleホーム・フォルダを作成します。 |
|
|
必須 新規Oracleホームに、Oracle Access Manager 12c (12.2.1.3.0)をインストールします。 |
|
|
必須 最新のバンドル・パッチを適用します |
「最新のスタック・パッチ・バンドルのインストール」を参照してください。 |
|
必須 OAMHOST1上の必要なスキーマをアップグレードします。 |
「OAMHOST1におけるスキーマのアップグレード」を参照してください。 |
|
必須 OAMHOST1上のOracle Access Managerドメインを再構成します。 |
「OAMHOST1におけるドメインの再構成」を参照してください。 |
|
必須 OAMHOST2上でOracle Access Managerドメイン構成をレプリケートします。 |
これには、OAMHOST1でのドメインのパック実行およびOAMHOST2でのパックの解凍が含まれます。 「各OAMHOST上でのドメイン構成のレプリケーション」を参照してください。 |
|
必須 OAMHOST1とOAMHOST2の両方でドメイン・コンポーネント構成をアップグレードします。 |
Upgrade Assistantは、再構成したドメインのコンポーネント構成を更新するために使用します。 |
|
必須 OAMHOST1およびOAMHSOT2でサーバーを起動します。 |
「サーバーの起動」を参照してください。 |
|
必須 アップグレード後に必要なタスクを完了します。 |
このタスクは任意で実行します。「アップグレード後タスクの実行」を参照 |
|
必須 パッチ後のインストール・ステップを完了します。 |
「パッチ後のインストール・ステップの実行」を参照してください。 |
Oracle Access Managerのアップグレード前のタスクの完了
Oracle Access Managerをアップグレードする前に、この項で説明しているアップグレード前のタスクを完了します。
- Oracle Access Managerのアップグレードでサポートされている開始ポイントのチェック
アップグレードにサポートされるOracle Access Managerバージョンは、11gリリース2 (11.1.2.3.0)です。 - OAMがOAAMおよびOIMに対して別のドメインにあるかどうかのチェック
Oracle Access Manager (OAM)、Oracle Adaptive Access Management (OAAM)およびOracle Identity Manager (OIM)が統合された設定で、OAMとOAAMが同じドメイン、OIMが別のドメインにある場合、ソース・ドメイン内のOAAMおよびOIMと連係するようにOAMドメインをクローンする必要があります。 - IAMSuiteAgentデプロイメントの削除
IAMSuiteAgentデプロイメントは12cではサポートされません。そのため、アップグレードを進める前にIAMSuiteAgentをアンデプロイします。 - Java JSEポリシーのアップグレード
必要に応じて、Java JSEポリシーをアップグレードします。 - OAMで非推奨のサービスの無効化
Mobile and Social、Security Token Service、Mobile Security ServiceおよびMSASプロキシ・ユーザーにのみ適用されます。
Oracle Access Managerのアップグレードでサポートされている開始ポイントのチェック
アップグレードにサポートされるOracle Access Managerバージョンは、11gリリース2 (11.1.2.3.0)です。
11gリリース2 (11.1.2.3.0)にアップグレードしてから、12cにアップグレードする必要があります。
OAMがOAAMおよびOIMに対して別のドメインにあるかどうかのチェック
Oracle Access Manager (OAM)、Oracle Adaptive Access Management (OAAM)およびOracle Identity Manager (OIM)が統合された設定で、OAMとOAAMが同じドメイン、OIMが別のドメインにある場合、ソース・ドメイン内のOAAMおよびOIMと連係するようにOAMドメインをクローンする必要があります。
ノート:
Oracle Access ManagerとOracle Identity Managerが異なるドメインにあることを確認します。同じドメインにある場合は、複数のドメインに分ける必要があります。詳細は、「Oracle Identity Managementアプリケーションの複数のドメインへの分離」を参照してください。OAMおよびOAAMドメインを分離するには、次のようにします。
OIMが別のドメインにインストールされていて、OAMおよびOAAMと統合されている場合は、次のようにします。
-
次のOracle Identity Managerプロパティを更新して新しいOAAMホストの詳細を追加します。
OIM.ChangePasswordURLOIM.ChallengeQuestionModificationURL
OAAM用のOracle Identity Managerの設定の詳細は、11gリリース2 (11.1.2.3.0)の『Oracle Identity Management Suite統合ガイド』のOracle Adaptive Access Manager用のOracle Identity Managerの設定に関する項を参照してください。
-
Oracle Identity Managerサーバーを再起動します。
ノート:
ドメインの分離後、管理対象サービスが実行状態にあるOAMドメインをアップグレードする必要があります。
たとえば、この項のステップに従った場合、マシン1上に存在するOAMを12cにアップグレードする必要があります。
IAMSuiteAgentデプロイメントの削除
IAMSuiteAgentデプロイメントは12cではサポートされません。そのため、アップグレードを進める前にIAMSuiteAgentをアンデプロイします。
OAMコンソールからのIAMSuiteAgentの削除
ノート:
OAMコンソールからIAMSuiteAgentを削除する前に、次のタスクを完了します:
IAMSuiteAgentを11g WebGateで置換します。「IAMSuiteAgentの11g Webゲートによる置換」を参照してください。IAMSuiteAgentを11g WebGateで置換せずに削除すると、11gサーバーのOAM機能が失われる可能性があります。- OAM構成をバックアップします。
- OAMコンソールにログインします。
- 「アプリケーション・セキュリティ」タブに移動し、「エージェント」、管理対象シングル・サインオン・エージェントの順にクリックします。
- SSOエージェントのリストから
IAMSuiteAgentを選択し、「削除」をクリックします。 - 削除を確定します。
Java JSEポリシーのアップグレード
必要に応じて、Java JSEポリシーをアップグレードします。
ノート:
これは、データ・センターのOracle Access Management (OAM)、Oracle Identity Manager (OIM)、Oracle Adaptive Access Manager (OAAM)またはOracle Access Manager Webgatesといった、いずれかのIdentity Managementコンポーネントが12c (12.2.1.3.0)にまだアップグレードされていない場合に必要です。これは12c (12.2.1.3.0)に段階的に移行するためのものです。
マルチデータ・センターの設定では、これはいずれかのデータ・センターに12c (12.2.1.2.0)のコンポーネント(OAM、OIM、OAAM、OAM Webgates)が存在する場合に必要です。
jarファイルlocal_policy.jarおよびUS_export_policy.jarは、ディレクトリ$JAVA_HOME/jre/lib/securityに存在します。これらのjarファイルを指定されたバージョンで上書きすることにより、Java JSEポリシーをアップグレードできます。これを行うには、次のステップを実行します:
OAMで非推奨のサービスの無効化
Mobile and Social、Security Token Service、Mobile Security ServiceおよびMSASプロキシ・ユーザーにのみ適用されます。
Mobile and Social、Security Token Service、Mobile SecurityおよびMSASプロキシ・サービスは、OAM 12c (12.2.1.3.0)では使用できません。現在のインストールでこれらのサービスを使用している場合は、このアップグレードを実行する前に無効にする必要があります。アップグレード中にこれらのいずれかのサービスがアクティブになっていると、アップグレードは失敗し、「アップグレードを実行できません」というエラー・メッセージが表示されます。これらの機能の詳細は、サポート・ドキュメントOracle Mobile Security Suiteに関する指示書を参照してください。
OAMHOST1およびOAMHOST2上での12c Oracleホーム・フォルダの作成
OAMHOST1とOAMHOST2の両方に12c Oracleホームのためのフォルダを作成します。
たとえば:
/home/Oracle/product/ORACLE_HOME
OAMHOST1およびOAMHOST2への製品ディストリビューションのインストール
12cバイナリをOAMHOST1およびOAMHOST2にインストールするか、または両方からアクセスできる共有ストレージにインストールする必要があります。冗長なバイナリを使用している場合は、必ず冗長な場所それぞれにインストールしてください
-
Oracle Fusion Middleware Infrastructure 12c (12.2.1.3.0)
-
Oracle Access Manager 12c (12.2.1.3.0)
-
アップグレード前の環境用の追加のディストリビューション
12cバイナリをインストールする手順は、「製品ディストリビューションのインストール」を参照してください。
ノート:
Oracle_Homeのインストールを冗長にしている場合は、冗長な場所それぞれにバイナリをインストールする必要があります。
- 製品ディストリビューションのインストール
アップグレードの開始前に、Oracle Fusion Middleware InfrastructureおよびOracle Access Manager 12c (12.2.1.3.0)のディストリビューションをターゲット・システムにダウンロードし、Oracle Universal Installerを使用してインストールします。
製品ディストリビューションのインストール
アップグレードの開始前に、Oracle Fusion Middleware InfrastructureおよびOracle Access Manager 12c (12.2.1.3.0)のディストリビューションをターゲット・システムにダウンロードし、Oracle Universal Installerを使用してインストールします。
ノート:
- 12cバイナリは、以前の11gバイナリとは異なる場所にインストールされます。12cバイナリは、アップグレードの計画停止時間の前にインストールできます。
- 冗長なバイナリの場所を使用している場合は、必ず冗長な場所それぞれにソフトウェアをインストールしてください。
ノート:
- 11.1.2.3.0設定がライフ・サイクル管理(LCM)ツールを使用してデプロイされた場合は、12c MiddlewareホームにOracle HTTP Server 12c (12.2.1.3.0)をインストールする必要があります。『Oracle HTTP Serverのインストールと構成』のOracle HTTP Serverのインストールおよび構成の準備に関する項を参照してください。
- opatchツールを使用して、Oracleサポートから最新の推奨パッチセットを適用します。アップグレード・プロセスの完了後、パッチセットのバイナリ・インストールのみを完了し、パッチ適用後のステップに従います。これにより、アップグレード・プロセスの最新の既知の修正があれば提供されます。
最新のスタック・パッチ・バンドルのインストール
製品ディストリビューションをインストールした後、アップグレード・プロセスを続行する前に最新のIDMスタック・パッチ・バンドル(SPB) 12.2.1.3.0を適用することを強くお薦めします。Opatchツールを使用してパッチを適用できます。SPBを適用すると、アップグレードの問題や回避策の大部分が除去されます。
- 初期準備: このフェーズでは、ソフトウェアのステージング、
README.txtファイルの読取り、Opatchツールの検証または適切なバージョンへの更新(あるいはその両方)を行います。 - 分析フェーズ: このフェーズでは、
README.txtファイルの変数を使用してprestopコマンドを実行し、システムがパッチ適用の準備を完了しているかどうかを判断します。 - パッチ適用フェーズ: このフェーズでは、MW_HOMEおよびDOMAIN_HOMEをバックアップし、
README.txtファイルの変数を使用してOIGのdowntimeコマンドを実行してから、一時ファイルをクリアします。
ノート:
この時点では、サーバーは再起動しません。現在、スキーマ、ローカル構成および新規ビット間のリンクはありません。パッチ適用プロセスの残りの部分は、ブートストラップ後に実行されます。com.oracle.cie.comdev_7.8.2.0およびcom.oracle.cie.xmldh_3.4.2.0ライブラリのconfig.xmlの次のエントリを更新します:<name>com.oracle.cie.comdev#3.0.0.0@7.8.2.0</name>
com.oracle.cie.comdev_7.8.2.0.jar<name>com.oracle.cie.xmldh#2.0.0.0@3.4.2.0</name>
com.oracle.cie.xmldh_3.4.2.0.jar<library>
<name>com.oracle.cie.comdev#3.0.0.0@7.8.2.0</name>
<target>oim_cluster</target>
<source-path><MW_HOME>/oracle_common/modules/com.oracle.cie.comdev_7.8.2.0.jar
</source-path>
<deployment-order>511</deployment-order>
<security-dd-model>DDOnly</security-dd-model>
<staging-mode>nostage</staging-mode>
</library>
<library>
<name>com.oracle.cie.xmldh#2.0.0.0@3.4.2.0</name>
<target>oim_cluster</target>
<source-path><MW_HOME>/oracle_common/modules/com.oracle.cie.xmldh_3.4.2.0.jar<
/source-path>
<deployment-order>511</deployment-order>
<security-dd-model>DDOnly</security-dd-model>
<staging-mode>nostage</staging-mode>
</library><library>
<name>com.oracle.cie.comdev#3.0.0.0@7.8.4.0</name>
<target>oim_cluster</target>
<source-path><MW_HOME>/oracle_common/modules/com.oracle.cie.comdev_7.8.4.0.jar
</source-path>
<deployment-order>511</deployment-order>
<security-dd-model>DDOnly</security-dd-model>
<staging-mode>nostage</staging-mode>
</library>
<library>
<name>com.oracle.cie.xmldh#2.0.0.0@3.4.4.0</name>
<target>oim_cluster</target>
<source-path><MW_HOME>/oracle_common/modules/com.oracle.cie.xmldh_3.4.4.0.jar<
/source-path>
<deployment-order>511</deployment-order>
<security-dd-model>DDOnly</security-dd-model>
<staging-mode>nostage</staging-mode>
</library>config.xmlファイルのこの更新により、ライブラリ名および各ライブラリのjarファイルのバージョンが、パッチ適用プロセスの後に使用されるものに変更されます。両方のノードが同じ設定であることを確認してください。
パッチ適用プロセスの詳細は、ドキュメントID 2657920.1を参照してください。
ノート:
WindowsまたはSolaris OSを使用している場合は、ドキュメントID 2457034.1から個々のバンドル・パッチ(BP)をダウンロードします。アップグレードが完了した後、パッチ後のインストール・ステップを実行する必要があります。「パッチ後のインストール・ステップの実行」を参照してください。
OAMHOST1におけるスキーマのアップグレード
Upgrade Assistantを使用してOAMHOST1上のOracle Access Managerに必要なすべてのスキーマをアップグレードします。
- 製品スキーマのアップグレード
サーバーとプロセスの停止後に、Upgrade Assistantを使用して、サポートされている製品スキーマをOracle Fusion Middlewareの現在のリリースにアップグレードします。
製品スキーマのアップグレード
サーバーおよびプロセスを停止した後、アップグレード・アシスタントを使用して、サポートされている製品スキーマを現在のリリースのOracle Fusion Middlewareにアップグレードします。
Upgrade Assistantを使用すると、個別に選択したスキーマまたはドメインに関連付けられているすべてのスキーマをアップグレードできます。選択したオプションによって、表示されるUpgrade Assistantの画面は異なります。
- アップグレードに対応可能な既存のスキーマの特定
このオプションの作業では、スキーマ・バージョン・レジストリを問い合せることで、アップグレードの開始前に、使用可能スキーマのリストを確認できます。レジストリには、バージョン番号、コンポーネント名およびID、作成日と変更日、カスタム接頭辞などのスキーマ情報が含まれます。 - Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.3.0)にアップグレードします。一度に1つのドメインのアップグレードを完了して、アップグレード・アシスタントを非SYSDBAユーザーとして実行することをお薦めします。 - Upgrade Assistantを使用したOracle Access Managerスキーマのアップグレード
Upgrade Assistantの各画面を移動して、製品スキーマをアップグレードします。 - スキーマのアップグレードの確認
すべてのアップグレード・ステップを完了したら、schema_version_registryのスキーマ・バージョンが適切に更新されていることをチェックして、アップグレードの成功を検証します。
親トピック: OAMHOST1におけるスキーマのアップグレード
アップグレードに対応可能な既存のスキーマの特定
このオプションの作業では、スキーマ・バージョン・レジストリを問い合せることで、アップグレードの開始前に、使用可能スキーマのリストを確認できます。レジストリには、バージョン番号、コンポーネント名および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スキーマの作成時に、同じ接頭辞を使用することになります。
ノート:
-
11gでOIDベースのポリシー・ストアを使用していた場合は、アップグレードを実行する前に新しいOPSSスキーマを必ず作成してください。アップグレード後も、OPSSスキーマはLDAPベース・ストアのままです。
-
Oracle Fusion Middlewareリリース12c (12.2.1.3.0)でアップグレード可能な製品のスキーマのみをアップグレードできます。まだ12c (12.2.1.3.0)へのアップグレードが未対応のコンポーネントを含むドメインはアップグレードしないでください。
親トピック: 製品スキーマのアップグレード
Upgrade Assistantの起動
Upgrade Assistantを実行して、製品のスキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.3.0)にアップグレードします。一度に1つのドメインのアップグレードを完了して、アップグレード・アシスタントを非SYSDBAユーザーとして実行することをお薦めします。
ノート:
Upgrade Assistantを起動する前に、Upgrade Assistantが実行されるプラットフォームのJVM文字コードが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)
- Upgrade Assistantの起動:
- (UNIX) ./ua
- (Windows) ua.bat
ノート:
前述のコマンドで、ORACLE_HOMEは12c (12.2.1.3.0) Oracleホームを示しています。
ロギング・パラメータなど、コマンド・ラインで指定できるその他のパラメータの詳細は、次を参照してください。
Upgrade Assistantのパラメータ
コマンドラインからUpgrade Assistantを起動するときに、追加のパラメータを指定できます。
表4-2 Upgrade Assistantコマンドライン・パラメータ
| パラメータ | 必須またはオプション | 説明 |
|---|---|---|
|
|
準備状況チェックの場合は必須
ノート: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。 |
実際のアップグレードを実行せずに、アップグレードの準備状況チェックを実行します。 スキーマと構成がチェックされます。
|
|
|
オプション |
スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を特定します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。 |
|
|
サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須 |
Upgrade AssistantがGUIモードで実行されているときに入力したデータから生成されるレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、Upgrade Assistantはサイレント・モード(Upgrade Assistantの画面表示なし)で実行されます。 |
|
|
オプション |
調査フェーズを実行しますが、実際のアップグレードは実行しません。
|
|
|
オプション |
次のいずれかの属性を指定して、ログイン・レベルを設定します。
デフォルトのロギング・レベルは
|
|
|
オプション |
アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。 デフォルトの場所は次のとおりです。 (UNIX)
(Windows)
|
|
|
オプション |
すべてのコマンドライン・オプションを表示します。 |
親トピック: Upgrade Assistantの起動
Upgrade Assistantを使用したOracle Access Managerスキーマのアップグレード
アップグレード・アシスタントの各画面を移動して、製品スキーマをアップグレードします。
注意:
RCUを使用してスキーマをすでにアップグレードしている場合は、このステップをスキップできます。ノート:
-
アップグレード前の環境に監査スキーマ(IAU)が存在する場合、「選択したスキーマ」画面の「個別に選択されたスキーマ」オプションを使用し、Oracle監査サービススキーマを選択して、最初に監査スキーマのみをアップグレードする必要があります。使用可能なIAUスキーマのリストから適切なIAUスキーマを選択していることを確認します。Upgrade Assistantでは、指定されたドメインのディレクトリ内で対応するIAUスキーマは自動的に検出されません。このため、手動で選択する必要があります。IAUスキーマがアップグレードされたら、Upgrade Assistantを再度実行し、「選択したスキーマ」画面の「ドメインで使用されるすべてのスキーマ」オプションを使用して残りのスキーマをアップグレードします。
-
アップグレード前の環境にいずれの監査スキーマ(IAU)も存在しない場合は、「選択したスキーマ」画面の「ドメインで使用されるすべてのスキーマ」オプションを使用して続行します。
-
アップグレード前の環境にIAUスキーマが存在するかどうか確認するには、sysdba権限を持つユーザーを使用して次のSQLコマンドを実行します。
select username from dba_users where username like '%IAU%';このコマンドでは、構成したデータベースで使用可能なIAUスキーマがリストされます。
親トピック: 製品スキーマのアップグレード
スキーマのアップグレードの確認
すべてのアップグレード・ステップを完了したら、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.3.0であることを確認します。ノート:
ただし、すべてのスキーマ・バージョンが更新されるわけではありません。一部のスキーマは、このリリースにアップグレードする必要がなく、アップグレード前のバージョン番号のままになります。
-
STATUSフィールドは、スキーマのパッチ適用処理中はUPGRADINGまたはUPGRADEDのどちらかになり、その処理が完了するとVALIDになります。 -
ステータスが
「INVALID」と表示された場合は、ステータスの更新が失敗しています。ログ・ファイルを調べて、失敗した理由を判定する必要があります。 -
IAU_APPENDとIAU_VIEWERが所有するシノニム・オブジェクトは、INVALIDと表示されますが、失敗を意味するものではありません。これらは、シノニムの作成後にターゲット・オブジェクトが変更されるため無効になります。シノニム・オブジェクトは、アクセスされるときに有効になります。これに該当する
INVALIDオブジェクトは、無視しても問題ありません。
ノート:
アップグレードの準備時に行った非SSLポートの変更や非SYSDBAユーザーを元に戻します。親トピック: 製品スキーマのアップグレード
OAMHOST1におけるドメインの再構成
OAMHOST1上で再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.3.0)に再構成します。
- ドメインの再構成について
再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.3.0)にあわせて再構成します。
ドメインの再構成について
再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.3.0)にあわせて再構成します。
WebLogic Serverドメインを再構成すると、ドメイン内のアプリケーションに応じて、次の項目が自動的に更新されます。
-
WebLogic Serverコア・インフラストラクチャ
-
ドメイン・バージョン
ノート:
ドメインの再構成を開始する前に、次の制限事項に注意してください。
-
再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。
-
アップグレード・プロセス中に、非動的クラスタ・ドメインを動的クラスタ・ドメインに変換することはサポートされていません。
動的クラスタ機能は、再構成ウィザードの実行中に使用できますが、サポートされているアップグレードは非動的クラスタのアップグレードのみで、その後で動的クラスタを追加することになります。アップグレード・プロセス中に動的クラスタを追加することはできません。
-
ドメインの
config.xmlファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンに更新されます。 -
すべてのインストール済Oracle製品の再構成テンプレートは、自動的に選択されてドメインに適用されます。これらのテンプレートは、WebLogicドメインが現在のWebLogic Serverバージョンと互換性を持つために必要な再構成タスクを定義します。
-
起動スクリプトが更新されます。
変更済の起動スクリプトを維持する場合は、そのスクリプトをバックアップしてから、再構成ウィザードを開始してください。
ノート:
ドメイン再構成プロセスが開始されると、そこで行われた変更は元に戻せません。再構成ウィザードを実行する前に、アップグレード前のチェックリストに示されているようにドメインのバックアップを作成したことを確認します。再構成ウィザードの実行中にエラーまたは他の割込みが発生した場合、バックアップ場所から元のドメイン・ディレクトリにファイルとディレクトリをコピーすることによって、ドメインをリストアする必要があります。これは、再構成前にドメインを確実に元の状態に戻す唯一の方法です。- ドメインのバックアップ
- 再構成ウィザードの起動
- Oracle Access Managerドメインの再構成
再構成ウィザードの各画面を通じて、既存の11gドメインを再構成します。
親トピック: OAMHOST1におけるドメインの再構成
ドメインのバックアップ
再構成ウィザードの実行前に、ドメイン・ディレクトリのバックアップ・コピーを作成します。
管理サーバーのドメイン・ディレクトリのバックアップを作成するには:
親トピック: ドメインの再構成について
再構成ウィザードの起動
ノート:
再構成プロセスを開始する前に、管理サーバーおよびすべてのコロケート管理対象サーバーを停止します。「サーバーとプロセスの停止」を参照再構成ウィザードをグラフィカル・モードで起動するには:
親トピック: ドメインの再構成について
Oracle Access Managerドメインの再構成
再構成ウィザードの各画面を通じて、既存の11gドメインを再構成します。
ノート:
ソースがクラスタ化環境の場合、プライマリ・ノードでのみ再構成ウィザードを実行します。ここで、プライマリ・ノードは管理サーバーです。圧縮/解凍ユーティリティを使用して、ドメイン内の他のクラスタ・メンバーに変更を適用します。親トピック: ドメインの再構成について
各OAMHOST上でのドメイン構成のレプリケーション
OAMHOST2上でドメイン構成をレプリケートします。これには、OAMHOST1でのアップグレード済ドメインのパック実行およびOAMHOST2でのパックの解凍が含まれます。
- OAMHOST1で、次のコマンドを
$ORACLE_HOME/oracle_common/common/binから実行して、アップグレード済のドメインをパックします:- UNIXの場合:
sh pack.sh -domain=<Location_of_OAM_domain> -template=<Location_where_domain_configuration_jar_to_be_created> -template_name="OAM Domain" -managed=true - Windowsの場合:
pack.cmd -domain=<Location_of_OAM_domain> -template=<Location_where_domain_configuration_jar_to_be_created> -template_name="OAM Domain" -managed=true
- UNIXの場合:
- OAMHOST1上でpackコマンドにより作成されたドメイン構成jarファイルを、OAMHOST2上の任意のアクセス可能な場所にコピーします。
- OAMHOST2で、次のコマンドを
$ORACLE_HOME/oracle_common/common/binから実行して、ドメインを解凍します:- UNIXの場合:
sh unpack.sh -domain=<Location_of_OAM_domain> -template=<absolute_path_to the_location_of_domain_configuration_jar_file> -overwrite_domain=true - Windowsの場合:
unpack.cmd -domain=<Location_of_OAM_domain> -template=<absolute_path_to the_location_of_domain_configuration_jar_file> -overwrite_domain=true
- UNIXの場合:
- 他のOAMHOSTがある場合は、それらのホストでステップ2からステップ3までを繰り返します。
ノート:
EDGの方法に従っている場合は、OAMHOST1上のOAM管理対象サーバーの場所でドメインをパックおよび解凍する必要もあります。OAMHOST1およびOAMHOST2におけるドメイン・コンポーネント構成のアップグレード
ドメインの再構成後に、Upgrade Assistantを使用して、ドメイン内のドメイン・コンポーネント構成を、更新されたドメイン構成に一致するようにアップグレードします。
- ドメイン・コンポーネント構成のアップグレード
ドメインを再構成した後、Upgrade Assistantを使用して、更新したドメイン構成と一致するようドメイン内のドメイン・コンポーネント構成をアップグレードします。
ドメイン・コンポーネント構成のアップグレード
ドメインを再構成した後、Upgrade Assistantを使用して、更新したドメイン構成と一致するようドメイン内のドメイン・コンポーネント構成をアップグレードします。
- Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.3.0)にアップグレードします。一度に1つのドメインのアップグレードを完了して、アップグレード・アシスタントを非SYSDBAユーザーとして実行することをお薦めします。 - Oracle Access Managerドメイン・コンポーネント構成のアップグレード
Upgrade Assistantの各画面を通じて、WebLogicドメインのコンポーネント構成をアップグレードします。 - ドメインからのOracle Mobile Security Managerサーバーの削除
Oracle Mobile Security Manager (MSM)サーバーは12c (12.2.1.3.0)ではサポートされないため、アップグレードしたドメインから削除します。
Upgrade Assistantの起動
Upgrade Assistantを実行して、製品のスキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.3.0)にアップグレードします。一度に1つのドメインのアップグレードを完了して、アップグレード・アシスタントを非SYSDBAユーザーとして実行することをお薦めします。
ノート:
Upgrade Assistantを起動する前に、Upgrade Assistantが実行されるプラットフォームのJVM文字コードが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)
- Upgrade Assistantの起動:
- (UNIX) ./ua
- (Windows) ua.bat
ノート:
前述のコマンドで、ORACLE_HOMEは12c (12.2.1.3.0) Oracleホームを示しています。
ロギング・パラメータなど、コマンド・ラインで指定できるその他のパラメータの詳細は、次を参照してください。
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の起動
Oracle Access Managerドメイン・コンポーネント構成のアップグレード
Upgrade Assistantの各画面を通じて、WebLogicドメインのコンポーネント構成をアップグレードします。
再構成ウィザードを実行してWebLogicドメインを12c (12.2.1.3.0)に再構成した後に、アップグレード・アシスタントを実行して、ドメイン・コンポーネント構成を、更新されたドメイン構成に一致するようにアップグレードする必要があります。
親トピック: ドメイン・コンポーネント構成のアップグレード
ドメインからのOracle Mobile Security Managerサーバーの削除
Oracle Mobile Security Manager (MSM)サーバーは12c (12.2.1.3.0)ではサポートされないため、アップグレードしたドメインから削除します。
親トピック: ドメイン・コンポーネント構成のアップグレード
OAMHOST1およびOAMHOST2上のサーバーの起動
OAMHOST1とOAMHOST2の両方でOracle Access Managerをアップグレードした後、サーバーを起動します。
-
OAMHOST1とOAMHOST2の両方でノード・マネージャを起動します。
-
OAMHOST1上で管理サーバーを起動します。
-
OAMHOST1上でOracle Access Manager管理対象サーバーを起動します。
-
OAMHOST2上でOracle Access Manager管理対象サーバーを起動します。
- サーバーとプロセスの起動
アップグレードが成功した後、管理サーバーおよび管理対象サーバーを含め、すべてのプロセスおよびサーバーを起動します。 - OIMおよびSOA管理対象サーバーのフロントエンドに使用できるようにするためのOracle HTTP Serverの構成
- ドメイン固有コンポーネント構成のアップグレードの確認
ドメイン固有コンポーネント構成のアップグレードが成功したことを確認するには、管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlにサインインし、各コンポーネントのバージョン番号が12.2.1.3.0であることを確認します。
サーバーおよびプロセスの起動
アップグレードが成功した後、管理サーバーおよび管理対象サーバーを含め、すべてのプロセスおよびサーバーを起動します。
コンポーネントは相互に依存していることがあるため、適切な順序で起動する必要があります。
ノート:
この項の手順では、WLSTコマンドラインまたはスクリプトを使用してサーバーとプロセスを起動する方法について説明します。Oracle Fusion Middleware ControlおよびOracle WebLogic Server管理コンソールを使用することもできます。Oracle Fusion Middlewareの管理の管理サーバー、管理対象サーバーおよびノード・マネージャの起動と停止を参照してください。Fusion Middleware環境を起動するには、次に示すステップを実行します。
ステップ1: ノード・マネージャを起動する
管理サーバー・ドメイン・ホームでノード・マネージャを起動します。
WLS_HOME/server/binディレクトリに移動し、次のコマンドを実行します:
WLS_HOMEは、WebLogic Serverのインストール先の最上位ディレクトリです。
-
(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などのプロセスも起動します。
nohup DOMAIN_HOME/bin/startWeblogic.sh &cd ORACLE_COMMON_HOME/common/bin
./wlst.sh
wlst offline> nmConnect('nodemanager_username','nodemanager_password',
'ADMINVHN','5556','domain_name',
'DOMAIN_HOME')
nmStart('AdminServer')ステップ3: 管理対象サーバーを起動する
ノート:
HA環境では、コンソールまたはノード・マネージャを使用してサーバーを起動することをお薦めします。weblogic管理者としてWeblogicコンソールにログインします。- 「サーバー」 > 「制御」タブに移動します。
- 必要な管理対象サーバーを選択します。
- 「起動」をクリックします。
親トピック: OAMHOST1およびOAMHOST2上のサーバーの起動
OIMおよびSOA管理対象サーバーのフロントエンドに使用できるようにするためのOracle HTTP Serverの構成
次のステップを実行します。
親トピック: OAMHOST1およびOAMHOST2上のサーバーの起動
ドメイン固有コンポーネント構成のアップグレードの確認
ドメイン固有コンポーネント構成のアップグレードが成功したことを確認するには、管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlにサインインし、各コンポーネントのバージョン番号が12.2.1.3.0になっていることを確認します。
管理コンソールにサインインするには、次に移動します。http://administration_server_host:administration_server_port/console
EDGデプロイメントで管理コンソールにサインインするには、仮想サーバー構成とコンソールへのアクセスの検証に関する項を参照してください。
Oracle Enterprise Manager Fusion Middleware Control Consoleにサインインするには、次に移動します。http://administration_server_host:administration_server_port/em
ノート:
- アップグレード後、管理ツールは、前のOracleホーム・ディレクトリではなく、必ず新しい12cのOracleホーム・ディレクトリから実行してください。
- アップグレード・プロセス時に、一部のOWSMドキュメント(ポリシー・セット、ポリシーおよびアサーション・テンプレートなどの事前定義ドキュメント)のアップグレードが必要な場合があります。ポリシー・セットまたは事前定義ドキュメントがアップグレードされると、バージョン番号が1増分されます。
- サイト固有の構成では、URLを使用して(直接URLまたはプロキシURLを介して)、WebLogicコンソールおよびEMコンソールにアクセスできる必要があります。
親トピック: OAMHOST1およびOAMHOST2上のサーバーの起動
アップグレード後のタスクの実行
Oracle Access Managerを12c (12.2.1.3)にアップグレードした後、必要に応じてこの項にまとめられたタスクを完了する必要があります。
この項では、次のタスクを取り上げます:
- 認証中にWebGates構成が失敗する
globalHMACEnabledがtrueに設定されていない環境で、hmacEnabled=trueで構成されたWebGatesは、認証中に失敗します。 - java.securityファイルの更新
複数のOracle Identity and Access Managementコンポーネント(Oracle Access Manager、Oracle Identity Manager、WebGatesなど)をデプロイしている場合、すべてのコンポーネントを12c (12.2.1.3.0)にアップグレードするまで、この項で説明している変更を行ってjava.securityファイルを更新する必要があります。
認証中にWebGates構成が失敗する
globalHMACEnabledがtrueに設定されていない環境で、hmacEnabled=trueで構成されたWebGatesは、認証中に失敗します。
詳細は、「OHS/OTD 12c WebGateへのアップグレード」を参照してください。
親トピック: アップグレード後のタスクの実行
java.securityファイルの更新
複数のOracle Identity and Access Managementコンポーネント(Oracle Access Manager、Oracle Identity Manager、WebGatesなど)をデプロイしている場合、すべてのコンポーネントを12c (12.2.1.3.0)にアップグレードするまで、この項で説明している変更を行ってjava.securityファイルを更新する必要があります。
親トピック: アップグレード後のタスクの実行
パッチ後のインストール・ステップの実行
アップグレードが完了した後、パッチ後のインストール・ステップを実行する必要があります。
パッチ後のインストール・ステップは次で構成されます:
poststartコマンドの実行によるバイナリ・パッチ適用の成功の確認
poststartコマンドを実行します:
$ ./spbat.sh -type oig -phase poststart -mw_home /<INSTALLATION_DIRECTORY>/IAM12c -spb_download_dir /<DOWNLOAD_LOCATION>/IDM_SPB_12.2.1.4.200714 -log_dir /<DOWNLOAD_LOCATION>/OIGlogs詳細は、ドキュメントID 2657920.1を参照してください。
親トピック: パッチ後のインストール・ステップの実行
サーバーのクリーン再起動の実行
すべてのサーバー(管理サーバーおよび管理対象サーバーを含む)を再起動します。「サーバーとプロセスの起動」を参照してください。
親トピック: パッチ後のインストール・ステップの実行