1. Oracle Access Managerのアップグレード
  2. Oracle Access Managerのインプレース・アップグレード
  3. Oracle Access Manager単一ノード環境のアップグレード

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

Oracle Access Managerをリリース11gリリース2 (11.1.2.3.0)からOracle Access Manager 12c (12.2.1.3.0)にアップグレードできます。

次の各項のステップを完了して、アップグレードを実行します。

  • Oracle Access Manager単一ノードのアップグレード・プロセスについて
    Oracle Access Manager単一ノード・デプロイメントのアップグレード・プロセスの概要に関するロードマップを確認します。
  • Oracle Access Managerのアップグレード前のタスクの完了
    Oracle Access Managerをアップグレードする前に、この項で説明しているアップグレード前のタスクを完了します。
  • 製品ディストリビューションのインストール
    アップグレードの開始前に、Oracle Fusion Middleware InfrastructureおよびOracle Access Manager 12c (12.2.1.3.0)のディストリビューションをターゲット・システムにダウンロードし、Oracle Universal Installerを使用してインストールします。
  • 最新のスタック・パッチ・バンドルのインストール
    製品ディストリビューションをインストールした後、アップグレード・プロセスを続行する前に最新のIDMスタック・パッチ・バンドル(SPB) 12.2.1.3.0を適用することを強くお薦めします。Opatchツールを使用してパッチを適用できます。SPBを適用すると、アップグレードの問題や回避策の大部分が除去されます。
  • RCUを使用した必要な12cスキーマの作成
    11gからアップグレードする場合、12cに必要な追加のスキーマを作成する必要があります。設定で非SSLポートが開いている場合、Upgrade Assistantを使用して、デフォルトのスキーマ設定を利用してスキーマを作成できます。SSLが有効な設定の場合、リポジトリ作成ユーティリティ(RCU)を使用して、カスタマイズされたスキーマを作成できます。この手順では、RCUを使用してスキーマを作成する方法について説明します。アップグレード・アシスタントを使用してスキーマを作成する方法については、アップグレード手順で説明しています。
  • アクセス・フェデレーションとBI Publisherの統合
    BI PublisherでOracle Access Managerの監査情報をシームレスに統合および表示するために、必要なパッチまたは最新のパッチに更新します。
  • アップグレード前の準備状況チェックの実行
    アップグレードにかかわる潜在的な問題を特定するために、アップグレード・プロセスの開始前に、準備状況チェックの実行をお薦めします。準備状況チェックで、アップグレードの潜在的な問題をすべて検出できない場合があることに注意してください。準備状況チェックで成功が報告されても、アップグレードが失敗する場合があります。
  • サーバーとプロセスの停止
    Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、すべてのアップグレード前のプロセス、および管理サーバー、ノード・マネージャ、管理対象サーバーを含めたすべてのサーバーを停止する必要があります。
  • 製品スキーマのアップグレード
    サーバーとプロセスの停止後に、Upgrade Assistantを使用して、サポートされている製品スキーマをOracle Fusion Middlewareの現在のリリースにアップグレードします。
  • ドメインの再構成について
    再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.3.0)にあわせて再構成します。
  • ドメイン・コンポーネント構成のアップグレード
    ドメインを再構成した後、Upgrade Assistantを使用して、更新したドメイン構成と一致するようドメイン内のドメイン・コンポーネント構成をアップグレードします。
  • アップグレード後のタスクの実行
    Oracle Access Managerを12c (12.2.1.3)にアップグレードした後、必要に応じてこの項にまとめられたタスクを完了する必要があります。
  • パッチ後のインストール・ステップの実行
    アップグレードが完了した後、パッチ後のインストール・ステップを実行する必要があります。

親トピック: Oracle Access Managerのインプレース・アップグレード

Oracle Access Manager単一ノードのアップグレード・プロセスについて

Oracle Access Manager単一ノード・デプロイメントのアップグレード・プロセスの概要に関するロードマップを確認します。

既存のドメインをアップグレードするために必要なステップは、ドメインがどのように構成されているか、およびどのコンポーネントをアップグレードするかによって異なります。

表3-1 単一ノードのOracle Access Managerデプロイメントをアップグレードするためのタスク

タスク 説明

オプション

このガイドの概要に関するトピックを再確認して、アップグレード前のタスクを完了します(まだ実行していない場合)。

関連項目:

必須

Oracle Access Managerに固有の必要なアップグレード前タスクを完了します。

「Oracle Access Managerのアップグレード前のタスクの完了」を参照してください。

必須

新規Oracleホームに、Fusion Middleware InfrastructureおよびOracle Access Manager 12c (12.2.1.3.0)をインストールします。

アップグレードを開始する前に、Fusion Middleware InfrastructureおよびOracle Access Managerを11g本番デプロイメントと同じホスト上にある新規のOracleホームにインストールします。12cでは、11g Middlewareホームを表現するために、Oracleホームを使用します。

「製品ディストリビューションのインストール」を参照してください。

必須

最新のバンドル・パッチを適用します。

「最新のスタック・パッチ・バンドルのインストール」を参照してください。

必須

リポジトリ作成ユーティリティ(RCU)を起動して、必要な12cデータベース・スキーマを作成します。

作成するスキーマは、既存のスキーマ構成によって異なります。

「RCUを使用した必要な12cスキーマの作成」を参照してください。

必須

アップグレード前の準備状況チェックを実行します。

「アップグレード前の準備状況チェックの実行」を参照してください。

必須

11g環境を停止します(すべての管理サーバーと管理対象サーバーを停止します)。

アップグレード中、データベースが稼働していることを確認してください。

警告: アップグレード中にサーバーを停止しないと、データが破壊される可能性があります。

「サーバーとプロセスの停止」を参照

必須

アップグレード・アシスタントを起動して、11gのデータベース・スキーマをアップグレードし、すべてのアクティブ(進行中の)インスタンス・データを移行します。

「製品スキーマのアップグレード」を参照してください。

ノート: アクティブ・インスタンス・データのアップグレードは、Upgrade Assistantの実行中に自動で開始されます。データが正常に新しい12c (12.2.1.3.0)環境にアップグレードされたら、アップグレード・アシスタントを終了してもかまいません。クローズされたインスタンスのアップグレードは、バックグランド・プロセスで継続されます。

必須

再構成ウィザードを起動してドメインを再構成します。

アップグレード中に、構成ウィザードを再構成モードで実行し、新しくインストールしたソフトウェアを使用するよう既存のドメインをアップグレードします。

「再構成ウィザードを使用したドメインの再構成」を参照

必須

Upgrade Assistantを(再度)起動して、Oracle Access Managerドメイン・コンポーネント構成をアップグレードします。

Upgrade Assistantは、再構成したドメインのコンポーネント構成を更新するために使用します。

「ドメイン・コンポーネント構成のアップグレード」を参照してください。

必須

アップグレード後に必要なタスクを完了します。

このタスクは任意で実行します。「アップグレード後タスクの実行」を参照

必須

パッチ後のインストール・ステップを実行します。

「パッチ後のインストール・ステップの実行」を参照してください。

親トピック: Oracle Access Manager単一ノード環境のアップグレード

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

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

親トピック: Oracle Access Manager単一ノード環境のアップグレード

Oracle Access Managerのアップグレードでサポートされている開始ポイントのチェック

アップグレードにサポートされるOracle Access Managerバージョンは、11gリリース2 (11.1.2.3.0)です。

以前のバージョンのOracle Access Managerを使用している場合は、最初にOracle Access Manager 11gリリース2 (11.1.2.3.0)にアップグレードしてから、12cにアップグレードする必要があります。

親トピック: Oracle Access Managerのアップグレード前のタスクの完了

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ドメインを分離するには、次のようにします。

  1. マシン2で11.1.2.3.0 OAM-OAAM環境を形成するように、OAMとOAAMが同じドメイン内にあるソース環境(マシン1)のテストから本番への移行を実行します。このマシン2が本番マシンとして機能します。
  2. マシン1で、DOMAIN_HOME/config/fmwconfig/oam-config.xmlファイルをテキスト・エディタで開き、パラメータHOST_ALIAS_1を検索します。
  3. 本番マシンの名前を反映するようにserverhostパラメータを更新します。これにより、OAAM認証ページをレンダリングするために指定される必要があるターゲット(OAAM)マシンが認識されます。
  4. パラメータVersionを検索し、その値を1つずつ増分します。
  5. ソース・マシン(マシン1)の管理サーバーおよびOAMサーバーのみを再起動し、変更を反映します。
    ソース・マシンのoaam_admin_server1およびoaam_server_server1が停止していることを確認します。
  6. 本番マシンのoaam_admin_server1およびoaam_server_server1(マシン2)を起動します。T2P後、本番マシン上の管理サーバーはRunning状態になります。
  7. マシン1のtapscheme保護リソースにアクセスします。マシン2のリクエストがOAAMサーバーにリダイレクトされ、後続のtaspschemeログインが成功したことを確認します。

    ノート:

    ソースと本番マシン上の日時が同期していることを確認します。そうでない場合、認証に失敗します。

OIMが別のドメインにインストールされていて、OAMおよびOAAMと統合されている場合は、次のようにします。

  1. 次のOracle Identity Managerプロパティを更新して新しいOAAMホストの詳細を追加します。

    • OIM.ChangePasswordURL
    • OIM.ChallengeQuestionModificationURL

    OAAM用のOracle Identity Managerの設定の詳細は、11gリリース2 (11.1.2.3.0)の『Oracle Identity Management Suite統合ガイド』のOracle Adaptive Access Manager用のOracle Identity Managerの設定に関する項を参照してください。

  2. Oracle Identity Managerサーバーを再起動します。

ノート:

ドメインの分離後、管理対象サービスが実行状態にあるOAMドメインをアップグレードする必要があります。

たとえば、この項のステップに従った場合、マシン1上に存在するOAMを12cにアップグレードする必要があります。

親トピック: Oracle Access Managerのアップグレード前のタスクの完了

IAMSuiteAgentデプロイメントの削除

IAMSuiteAgentデプロイメントは12cではサポートされません。そのため、アップグレードを進める前にIAMSuiteAgentをアンデプロイします。

親トピック: Oracle Access Managerのアップグレード前のタスクの完了

WebLogic管理コンソールからのIAMSuiteAgentの削除
  1. 次のURLを使用してWebLogic管理コンソールにログインします。
    http://hostname:port/console

    ここで、hostnameは管理サーバーのDNS名またはIPアドレスで、portは管理サーバーでリクエストがリスニングされるリスニング・ポート(デフォルトでは7001)です。ドメイン全体の管理ポートを構成している場合は、そのポート番号を使用します。Secure Socket Layer (SSL)を使用するように管理サーバーが構成されている場合は、次のようにhttpの後にsを付加する必要があります。 

    https://hostname:port/console

    ノート:

    ドメイン全体の管理ポートでは常にSSLを使用します。
  2. 「セキュリティ・レルム」をクリックします。
  3. 「myrealm」をクリックします。
  4. 「プロバイダ」をクリックし、IAMSuiteAgentを選択します。
  5. 「削除」をクリックします。
  6. サーバーを再起動します。
OAMコンソールからのIAMSuiteAgentの削除

ノート:

OAMコンソールからIAMSuiteAgentを削除する前に、次のタスクを完了します:

  • IAMSuiteAgentを11g WebGateで置換します。「IAMSuiteAgentの11g Webゲートによる置換」を参照してください。IAMSuiteAgentを11g WebGateで置換せずに削除すると、11gサーバーのOAM機能が失われる可能性があります。
  • OAM構成をバックアップします。
  1. OAMコンソールにログインします。
  2. 「アプリケーション・セキュリティ」タブに移動し、「エージェント」、管理対象シングル・サインオン・エージェントの順にクリックします。
  3. SSOエージェントのリストからIAMSuiteAgentを選択し、「削除」をクリックします。
  4. 削除を確定します。

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ポリシーをアップグレードできます。これを行うには、次のステップを実行します:

  1. local_policy.jarおよびUS_export_policy.jarファイルを次の場所からダウンロードします。
  2. jarファイルを$JAVA_HOME/jre/lib/securityにコピーします。これにより既存のファイルが上書きされます。
これでJava JSEポリシーのアップグレードが完了します。

親トピック: Oracle Access Managerのアップグレード前のタスクの完了

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

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

ノート:

  • 12cバイナリは、以前の11gバイナリとは異なる場所にインストールされます。12cバイナリは、アップグレードの計画停止時間の前にインストールできます。
  • 冗長なバイナリの場所を使用している場合は、必ず冗長な場所それぞれにソフトウェアをインストールしてください。
12c (12.2.1.3.0)ディストリビューションをインストールするには:
  1. ターゲットのシステムにサインインします。
  2. Oracle Technical ResourcesまたはOracle Software Delivery Cloudから次のものをターゲット・システムにダウンロードします:
    • Oracle Fusion Middlewareインフラストラクチャ (fmw_12.2.1.3.0_infrastructure_generic.jar)
    • Oracle Access Manager (fmw_12.2.1.3.0_idm_generic.jar)
    • アップグレード前の環境用の追加のディストリビューション

    ノート:

    ライフ・サイクル管理(LCM)ツールを使用して設定された、Oracle Access Manager、Oracle Identity ManagerおよびWebゲートを含む統合環境をアップグレードする場合、それぞれの12c Web Server (Oracle HTTP ServerまたはOracle Traffic Director)バイナリを同じOracleホームにインストールする必要があります。

  3. 12c (12.2.1.3.0)製品のディストリビューションをダウンロードしたディレクトリに移動します。
  4. Oracle Fusion Middleware Infrastructureのインストール・プログラムを開始します。
    • (UNIX) JAVA_HOME/bin/java -jar fmw_12.2.1.3.0_infrastructure_generic.jar
    • (Windows) JAVA_HOME\bin\java -jar fmw_12.2.1.3.0_infrastructure_generic.jar
  5. UNIXオペレーティング・システムでは、このホストにOracle製品を初めてインストールする場合に、「インストール・インベントリの設定」画面が表示されます。
    中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システム・グループ名に中央インベントリの場所への書込み権限があることを確認し、「次へ」をクリックします。

    ノート:

    「インストール・インベントリの設定」画面は、Windowsオペレーティング・システムでは表示されません。
  6. 「ようこそ」画面で、情報をレビューしてすべての前提条件を満たしていることを確認します。「次」をクリックします。
  7. 「自動更新」画面で、オプションを1つ選択します。

    • この時点でソフトウェアの更新をシステムで確認しないようにする場合は、「自動更新をスキップ」を選択します。

    • パッチ・ファイルをダウンロードした場合は、「ディレクトリからパッチを選択」を選択して、ローカル・ディレクトリに移動します。

    • My Oracle Supportアカウントを持っている場合にソフトウェアの更新を自動でダウンロードするには、「My Oracle Supportで更新を検索」を選択します。Oracle Supportの資格証明を入力して、「検索」をクリックします。インストーラがMy Oracle Supportにアクセスするようにプロキシ・サーバーを構成するには、「プロキシ設定」をクリックします。「接続のテスト」をクリックして接続をテストします。

    「次」をクリックします。
  8. 「インストールの場所」画面でOracleホーム・ディレクトリの場所を指定し、「次へ」をクリックします。
    Oracle Fusion Middlewareディレクトリ構造の詳細は、『Oracle Fusion Middlewareのインストールのプランニング』のインストールおよび構成のためのディレクトリに関する項を参照してください。
  9. 「インストール・タイプ」画面で、次に示す項目を選択します。
    • インフラストラクチャの場合は、「Fusion Middlewareインフラストラクチャ」を選択します。
    • Oracle Access Managerの場合、同じ場所に配置されたOracle Identity and Access Managerを選択します。
    「次」をクリックします。
  10. 「前提条件チェック」画面では、ホスト・コンピュータを分析して、特定のオペレーティング・システムの前提条件を満たしているか確認します。
    確認されたタスクのリストを表示するには、「正常なタスクの表示」を選択します。ログの詳細を表示するには、「ログの表示」を選択します。前提条件のチェックが失敗すると、エラー・メッセージが画面の下方に表示されます。エラーを修正し、「再実行」をクリックして再試行します。エラー・メッセージや警告メッセージを無視してインストールを続けるには、「スキップ」をクリックします(非推奨)。
  11. 「インストールの概要」画面で、選択したインストール・オプションを確認します。
    これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を入力します。レスポンス・ファイルには、入力したすべての情報が収集して格納され、後で(コマンドラインから)サイレント・インストールを実行するために使用できます。

    「インストール」をクリックしてインストールを開始します。

  12. 「インストールの進行状況」画面で、プログレス・バーが100%完了になったら、「終了」をクリックしてインストーラを閉じるか、「次へ」をクリックしてサマリーを表示します。
  13. 「インストール完了」画面に、インストールの場所とインストールされた機能セットが表示されます。情報を確認し、「終了」をクリックしてインストーラを閉じます。
  14. Oracle Fusion Middleware Infrastructureのインストール後に、次のコマンドを入力して、製品ディストリビューションのインストーラを起動し、前述のステップを繰り返してインストーラの各画面を移動します。
    (UNIX) JAVA_HOME/bin/java -jar fmw_12.2.1.3.0_idm_generic.jar
    (Windows) JAVA_HOME\bin\java -jar fmw_12.2.1.3.0_idm_generic.jar

ノート:

  • 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サポートから最新の推奨パッチセットを適用します。アップグレード・プロセスの完了後、パッチセットのバイナリ・インストールのみを完了し、パッチ適用後のステップに従います。これにより、アップグレード・プロセスの最新の既知の修正があれば提供されます。

親トピック: Oracle Access Manager単一ノード環境のアップグレード

最新のスタック・パッチ・バンドルのインストール

製品ディストリビューションをインストールした後、アップグレード・プロセスを続行する前に最新の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)をダウンロードします。

アップグレードが完了した後、パッチ後のインストール・ステップを実行する必要があります。「パッチ後のインストール・ステップの実行」を参照してください。

親トピック: Oracle Access Manager単一ノード環境のアップグレード

RCUを使用した必要な12cスキーマの作成

11gからアップグレードする場合、12cに必要な追加のスキーマを作成する必要があります。設定で非SSLポートが開いている場合、Upgrade Assistantを使用して、デフォルトのスキーマ設定を利用してスキーマを作成できます。SSLが有効な設定の場合、リポジトリ作成ユーティリティ(RCU)を使用して、カスタマイズされたスキーマを作成できます。この手順では、RCUを使用してスキーマを作成する方法について説明します。アップグレード・アシスタントを使用してスキーマを作成する方法については、アップグレード手順で説明しています。

ノート:

12cスキーマを作成するには、12cリポジトリ作成ユーティリティ(RCU)を使用する必要があります。12c RCUはORACLE_HOME/oracle_common/binディレクトリにあります。ここで、ORACLE_HOMEは12cのOracleホームです。
12c RCUを使用して次のスキーマを作成する必要があります。

  • 共通インフラストラクチャ・サービス・サービス表(prefix_STB)

  • WebLogicサービス(prefix_WLS)

  • ユーザー・メッセージング・サービス(prefix_UMS)

Oracle Access Manager (OAM)、Oracle Platform Security Services (OPSS)などの既存のスキーマがアップグレードされるため、新規のものを作成する必要はありません。

12cにアップグレードする前に、次のスキーマが存在している必要があります。11gからアップグレードし、現在使用しているスキーマがわからない場合、次のステップを参照して、ドメインの既存のスキーマを識別します。これらのスキーマがすでに存在している場合、再作成する必要はありません。

  • サービス表スキーマ(prefix_STB)。このスキーマは12cで新規のものであり、ドメインベースのアップグレードに必要になります。基本的なスキーマ構成情報(スキーマ接頭辞やパスワードなど)が格納され、他のOracle Fusion Middlewareコンポーネントはドメイン作成中にこれにアクセスして使用できます。このスキーマはリポジトリ作成ユーティリティ(RCU)を実行するときに自動的に作成され、ここで他の11gスキーマに使用した既存のスキーマ所有者接頭辞を指定します。

    ノート:

    サービス表スキーマが存在しない場合、UPGAST-00328: スキーマ・バージョンのレジストリ表はこのデータベースに存在しません。その場合、Upgrade Assistantを実行するためにはサービス表スキーマを作成する必要があります。というエラー・メッセージが表示されることがあります。

  • Oracle Platform Security Services (OPSS)スキーマ(prefix_OPSS)。このスキーマは、11gでOIDベースのセキュリティ・ストアを使用している場合に必要です。このスキーマは、リポジトリ作成ユーティリティ(RCU)の実行時に自動的に作成されます。LDAPベースのOPSSセキュリティ・ストアでサポートされているのは、Oracle Internet Directory (OID)のみです。LDAPベースのポリシー・ストアは、通常、本番環境で使用します。アップグレード前に、OIDベースのセキュリティ・ストアを再関連付けする必要はありません。Upgrade Assistantの実行中に、OPSSスキーマを選択できます。Upgrade Assistantは、OIDベースのセキュリティ・ストアを自動的にアップグレードします。

    ノート:

    12c OPSSデータベース・スキーマが必要なのは、ドメインの再構成時に12cスキーマを参照するためです。ドメインでは、アップグレード完了後にOIDベースのセキュリティ・ストアが引き続き使用されます。

RCUを使用して12cスキーマを作成するには:
  1. (オプション) 11gからアップグレードする場合に、既存のドメインに存在するスキーマを確認するには、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 ;
  2. コマンドラインからjava -versionを実行して、動作保証されたJDKがすでにシステムにあることを確認します。12c (12.2.1.3.0)の場合、動作保証済JDKは1.8.0_131以降です。
    JAVA_HOME環境変数が、動作保証されたJDKの場所に設定されていることを確認します。たとえば:
    • (UNIX) setenv JAVA_HOME=/home/Oracle/Java/jdk1.8.0_131
    • (Windows) set JAVA_HOME=C:\home\Oracle\Java\jdk1.8.0_131
    Add $JAVA_HOME/bin to $PATH.
  3. oracle_common/binディレクトリに移動します。
    • (UNIX) ORACLE_HOME/oracle_common/bin
    • (Windows) ORACLE_HOME\oracle_common\bin
  4. RCUを起動します:
    • (UNIX) ./rcu
    • (Windows) rcu.bat
  5. 「ようこそ」画面で「次へ」をクリックします。
  6. 「リポジトリの作成」画面で「リポジトリの作成」を選択し、「システム・ロードおよび製品ロード」を選択します。
    DBA権限を持っていない場合は、「システム・ロードに対するスクリプトの準備」を選択します。これによって、RCUが選択されたコンポーネントに対してアクションを実行した場合にコールされるSQL文およびブロックと同じものを、すべて含むSQLスクリプトが生成されます。

    スクリプトが生成されると、「Upgrade Assistantを実行するための非SYSDBAユーザーの作成」で前に作成したユーザーが、必要なSYSまたはSYSDBA権限でスクリプトを実行してシステム・ロード・フェーズを完了できます。

    「次」をクリックします。

  7. 「データベース接続の詳細」画面で、「データベース・タイプ」を選択し、11gスキーマをホストするデータベースの接続情報を入力します。次の該当する表を参照してください。

    表3-2 Oracle Databaseと、エディションベースで再定義されるOracle Databaseに対する接続資格証明

    オプション 説明および例
    ホスト名

    データベースが実行されるサーバーの名前を、次の書式で指定します。

    examplehost.exampledomain.com

    Oracle RACデータベースの場合は、このフィールドにSCAN名またはいずれかのノード名を指定します。
    ポート

    データベースのポート番号を指定します。Oracleデータベースのデフォルトのポート番号は、1521です。

    サービス名

    データベースのサービス名を指定します。通常、サービス名はグローバル・データベース名と同じです。

    Oracle RACデータベースの場合、このフィールドにいずれかのノードのサービス名を指定します。たとえば:

    examplehost.exampledomain.com
    ユーザー名 データベースのユーザー名を入力します。デフォルトのユーザー名はSYSです。
    パスワード データベース・ユーザーのパスワードを入力します。
    ロール

    ドロップダウン・リストからデータベース・ユーザーのロールを選択します。

    「標準」または「SYSDBA」

    表3-3 MySQLデータベースに対する接続資格証明

    オプション 説明および例
    ホスト名

    データベースが稼働しているサーバーのホスト名、IPアドレスまたは詳細なサーバー名を、host\server形式で指定します。

    ポート

    データベースのポート番号を指定します。
    データベース名

    データベースの名前を指定します。
    ユーザー名 管理者権限を持つユーザーの名前を指定します。
    パスワード データベース・ユーザーのパスワードを入力します。

    表3-4 Microsoft SQL Serverデータベースに対する接続資格証明

    オプション 説明および例
    Unicodeのサポート

    ドロップダウン・リストから「はい」または「いいえ」を選択します。

    サーバー名 データベースが稼働しているサーバーのホスト名、IPアドレスまたは詳細なサーバー名を、host\server形式で指定します。

    MSSQL名前付きインスタンス: 名前付きインスタンスは、コンピュータのネットワーク名およびインストール時に指定したインスタンス名によって識別されます。クライアントは、接続時に、サーバー名とインスタンス名を両方とも指定する必要があります。
    ポート

    データベースのポート番号を指定します。
    データベース名

    データベースの名前を指定します。
    ユーザー名 管理者権限を持つユーザーの名前を指定します。
    パスワード データベース・ユーザーのパスワードを入力します。

    表3-5 IBM DB2データベースに対する接続資格証明

    オプション 説明および例
    サーバー名 データベースが稼働しているサーバーのホスト名、IPアドレスまたは詳細なサーバー名を、host\server形式で指定します。
    ポート

    データベースのポート番号を指定します。
    データベース名

    データベースの名前を指定します。
    ユーザー名 DB所有者の権限が付与されているユーザーの名前を指定します。IBM DB2データベースのデフォルトのユーザー名はdb2adminです。
    パスワード データベース・ユーザーのパスワードを入力します。
    前提条件のチェックに成功したら、「OK」をクリックして次の画面に進みます。チェックが失敗した場合は、入力した詳細を確認して再試行します。
  8. 「コンポーネントの選択」画面で、「既存の接頭辞の選択」を選択し、ドロップダウン・メニューから既存の11gスキーマの作成に使用した接頭辞(たとえば、DEV11G)を選択します。この接頭辞は、スキーマをこのドメインで使用するために論理的にまとめてグループ化するために使用されます。次のスキーマを選択します。
    1. 共通インフラストラクチャ・サービス・サービス表(prefix_STB)
    2. WebLogicサービス(prefix_WLS)
    3. ユーザー・メッセージング・サービス(prefix_UMS)

    ノート:

    デフォルトで、Common Infrastructure Services (prefix_STB)およびOracle Platform Security Services (prefix_OPSS)スキーマが選択されます(まだそれらが作成されていない場合)。

    インストールするコンポーネントの接頭辞とスキーマ名をノートにとります。インストールの構成時にこの情報が必要になります。「次」をクリックします。
  9. 「前提条件チェック」ダイアログで、前提条件チェックが正常であることを確認し、「OK」をクリックします。
  10. 「スキーマ・パスワード」画面で、スキーマの所有者のパスワードを入力します。
    この画面で入力したパスワードをノートにとってください。製品インストールの構成中に必要となります。
  11. 「表領域のマップ」画面で、作成するスキーマに必要な表領域マッピングを構成します。
    「次へ」をクリックして、確認ダイアログで「OK」をクリックします。進行状況ダイアログに表領域の作成が完了したことが示されたら、「OK」をクリックします。
    RCUの起動時にTransparent Data Encryption (TDE)がデータベース(OracleまたはOracle EBR)内で有効化されている場合にのみ、「表領域の暗号化」チェック・ボックスが表示されます。RCUにより作成されるすべての新しい表領域を暗号化するために、「表領域のマップ」画面で「表領域の暗号化」チェック・ボックスを選択します。
  12. 「サマリー」画面で情報を確認し、「作成」をクリックしてスキーマの作成を開始します。
    この画面には、このRCU操作で作成されたログ・ファイルに関する情報が表示されます。特定のログ・ファイルの名前をクリックして、そのファイルの内容を表示します。
  13. 「完了サマリー」画面の情報を確認し、操作が正常に完了したことを確かめます。「閉じる」をクリックして、スキーマの作成を完了します。

親トピック: Oracle Access Manager単一ノード環境のアップグレード

アクセス・フェデレーションとBI Publisherの統合

BI PublisherでOracle Access Managerの監査情報をシームレスに統合および表示するために、必要なパッチまたは最新のパッチに更新します。

次のタスクを実行します。

タスク1: アクセス監査とOPSSストアの統合[IAUスキーマ]

Oracle Access Manager 12c (12.2.1.3.0)の最新のパッチを適用するか、12c (12.2.1.4)にアップグレードします。

タスク2: アクセス監査とBI Publisherの統合

Oracle Platform Security Services (OPSS)の場合は、パッチ12.2.1.3.181016以降を適用します。

タスク3: アクセス・フェデレーション監査の統合

Oracle Platform Security Services (OPSS)の場合は、パッチ12.2.1.3.201013以降を適用します。

親トピック: Oracle Access Manager単一ノード環境のアップグレード

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

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

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

親トピック: Oracle Access Manager単一ノード環境のアップグレード

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

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

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

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

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

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

ノート:

パフォーマンスが影響されることを回避するために、オフピーク時に準備状況チェックを実行することをお薦めします。

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

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

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

アップグレード・アシスタントを使用して、アップグレード前の環境に対して準備状況チェックを実行するには:
  1. oracle_common/upgrade/binディレクトリに移動します。
    • (UNIX) ORACLE_HOME/oracle_common/upgrade/bin
    • (Windows) ORACLE_HOME\oracle_common\upgrade\bin

    ORACLE_HOMEは、12c Oracleホームです。

  2. 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を起動するときに、追加のパラメータを指定できます。

表3-6 アップグレード・アシスタントのコマンドライン・パラメータ

パラメータ 必須またはオプション 説明

-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を使用した準備状況チェックの実行

アップグレード・アシスタントの各画面を移動して、アップグレード前の準備状況チェックを完了します。

準備状況チェックは、サポートされるアップグレードの開始点にあるスキーマまたはコンポーネント構成に対してのみ実行されます。
準備状況チェックを実行するには:
  1. 「ようこそ」画面で、準備状況チェックに関する情報を確認します。「次」をクリックします。
  2. 「準備状況チェック・タイプ」画面で、実行する準備状況チェックを選択します。
    • 「個別に選択されたスキーマ」: アップグレード前に確認するスキーマを個別に選択できます。準備状況チェックは、スキーマがアップグレードに対応しているかどうか、またはアップグレードが必要かどうかをレポートします。

      このオプションを選択すると、画面名が「選択したスキーマ」に変更されます。

    • 「ドメイン・ベース」: Upgrade Assistantは、「ドメイン・ディレクトリ」フィールドで指定されたドメイン内で、アップグレード可能なスキーマまたはコンポーネントのすべてを検出して選択するようになります。

      このオプションを選択すると、画面名が「スキーマおよび構成」に変更されます。

      Upgrade Assistantですべてのスキーマとコンポーネント構成をチェックする場合は、デフォルトの選択を変更しないで使用します。それ以外の場合は、次に示す特定のオプションを選択します。

      • 「すべてのスキーマのチェックを含める」: アップグレードに対応したコンポーネントをすべて検出して確認します。

      • 「すべての構成のチェックを含める」: 管理対象WebLogic Serverドメインのコンポーネント構成を確認します。

    「次」をクリックします。

  3. 「個別に選択されたスキーマ」を選択した場合: 「使用可能なコンポーネント」画面で、アップグレードに対応可能なスキーマを持つコンポーネントを選択して、準備状況チェックの実行対象にします。
    「ドメイン・ベース」を選択した場合: 「コンポーネント・リスト」画面で、準備状況チェックを実行するドメインに存在するコンポーネントのリストを確認します。
    依存コンポーネントのあるコンポーネントを選択すると、該当するコンポーネントが自動的に選択されます。たとえば、Oracle Platform Security Servicesを選択すると、Oracle Audit Servicesが自動的に選択されます。

    選択したコンポーネントによっては、追加の画面が表示されることがあります。たとえば、次のような作業が必要になることがあります。

    • 管理サーバーのドメイン・ディレクトリを指定します。

      必ず、11.1.2.3.0管理者サーバー・ドメイン・ディレクトリを指定します。

    • 選択したスキーマに接続するために、次のスキーマ資格証明を指定します: 「データベース・タイプ」、「DBAユーザー名」および「DBAパスワード」。アップグレード前の要件の一部として、必要なユーザーをすでに作成しました。「Upgrade Assistantを実行するための非SYSDBAユーザーの作成」を参照してください。

      次に、「接続」をクリックします。

      ノート:

      Oracleデータベースは、デフォルトのデータベース・タイプです。データベース・タイプに間違いがないことを確認してから続行してください。間違ったデータベースを選択していることに気付いた場合でも、正しいタイプに変更するために、この画面に戻らないでください。そのかわりに、Upgrade Assistantを終了してから、正しいデータベース・タイプを選択した状態で準備状況チェックを再開し、すべてのスキーマに正しいデータベース・タイプが適用されるようにします。

    • 「スキーマ・ユーザー名」オプションを選択して、「スキーマ・パスワード」を指定します。

    「次」をクリックして、準備状況チェックを開始します。
  4. 「準備状況サマリー」画面で、選択内容に基づいて実行される準備状況チェックのサマリーを確認します。
    選択内容を保存して、今後、レスポンス(サイレンス)モードでUpgrade Assistantを再実行する場合は、「レスポンス・ファイルの保存」をクリックして、レスポンス・ファイルの場所と名前を指定します。サイレント・アップグレードは、Upgrade Assistantとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。
    詳細レポートを表示するには、「ログの表示」をクリックします。
    「次」をクリックします。
  5. 「準備状況チェック」画面で、準備状況チェックのステータスを確認します。このプロセスには、数分かかることがあります。
    複数のコンポーネントをチェックしている場合、それぞれのコンポーネントの進行状況は、それぞれ専用のプログレス・バーで同時に表示されます。
    準備状況チェックが完了したら、「続行」をクリックします。
  6. 「準備状況の終了」画面で、準備状況チェックの結果(「準備状況成功」または「準備状況失敗」)を確認します。

    • 準備状況チェックが成功した場合は、「準備状況レポートの表示」をクリックして完全なレポートを確認します。準備状況チェックが成功した場合でも、実際のアップグレードを実行する前に、準備状況レポートを確認するようにしてください。「検索」オプションは、レポート内の特定の語句を検索する際に使用します。また、このレポートには、完成した準備状況チェック・レポート・ファイルが格納されている場所も示されます。

    • 準備状況チェックで問題またはエラーが発生した場合、「ログの表示」をクリックして、ログ・ファイルを確認して問題を特定し、問題を修正してから、準備状況チェックを再開してください。ログ・ファイルは、設定したコマンドライン・オプションにより管理されます。

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

準備状況レポートの理解

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

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

readiness_timestamp.txt

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

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

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

レポートの情報 説明 必要なアクション
全体的な準備状況ステータス: SUCCESSまたはFAILURE レポートの上部に、準備状況チェックが合格したか1つ以上のエラーで完了したかが示されます。 1つ以上のエラーが発生してレポートが完了した場合、アップグレードを試みる前に、FAILを検索し、障害の原因となった問題を修正します。準備状況チェックは、アップグレードする前に必要に応じて何度でも再実行できます。

タイムスタンプ

レポートが生成された日付と時刻です。

アクションは必要ありません。

ログ・ファイルの場所

ORACLE_HOME/oracle_common/upgrade/logs

生成されたログ・ファイルのディレクトリの場所です。

アクションは必要ありません。

準備状況レポートの場所

ORACLE_HOME/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 Tue May 30 11:15:52 EDT 2016
Log file is located at: ORACLE_HOME/oracle_common/upgrade/logs/ua2016-05-30-11-14-06AM.log
Readiness Check Report File: ORACLE_HOME/oracle_common/upgrade/logs/readiness2016-05-30-11-15-52AM.txt

Starting readiness check of components.

Oracle Metadata Services
   Starting readiness check of Oracle Metadata Services.
     Schema User Name: DEV11_MDS
     Database Type: Oracle Database
     Database Connect String: machinename@yourcompany.com
     VERSION Schema DEV11_MDS is currently at version 12.1.1.1.0.  Readiness checks will now be performed.
   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_REQUIRED_PROCEDURES  Test that the schema contains all the required stored procedures
     EXCEPTION     Schema is missing a required procedure: GETREPOSITORYFEATURES
   Completed schema test: TEST_REQUIRED_PROCEDURES --> Test that the schema contains all the required stored procedures +++ FAIL
   Starting schema test:  TEST_REQUIRED_VIEWS  Test that the schema contains all the required database views
   Completed schema test: TEST_REQUIRED_VIEWS --> Test that the schema contains all the required database views +++ PASS
   Starting index test for table MDS_ATTRIBUTES:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
   Completed index test for table MDS_ATTRIBUTES: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
   Starting index test for table MDS_COMPONENTS:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
   Completed index test for table MDS_TXN_LOCKS: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
   Starting schema test:  TEST_REQUIRED_TRIGGERS  Test that the schema has all the required triggers
   Completed schema test: TEST_REQUIRED_TRIGGERS --> Test that the schema has all the required triggers +++ 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_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_UNEXPECTED_PROCEDURES  Test that the schema does not contain any unexpected stored procedures
   Completed schema test: TEST_UNEXPECTED_PROCEDURES --> Test that the schema does not contain any unexpected stored procedures +++ PASS
   Starting schema test:  TEST_UNEXPECTED_VIEWS  Test that the schema does not contain any unexpected views
   Completed schema test: TEST_UNEXPECTED_VIEWS --> Test that the schema does not contain any unexpected views +++ PASS
   Starting index test for table MDS_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
   Completed index test for table MDS_ATTRIBUTES: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
   Completed index test for table MDS_LABELS: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
   Starting index test for table MDS_LARGE_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
   Starting schema test:  TEST_UNEXPECTED_TRIGGERS  Test that the schema does not contain any unexpected triggers
   Completed schema test: TEST_UNEXPECTED_TRIGGERS --> Test that the schema does not contain any unexpected triggers +++ 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 MDS_ATTRIBUTES:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
   Completed datatype test for table MDS_ATTRIBUTES: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
   Starting datatype test for table MDS_COMPONENTS:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
   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_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 schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
     INFO   Database product version: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
   Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
   Finished readiness check of Oracle Metadata Services with status: FAILURE.

12.1.3.0バージョンのOracle Fusion Middleware IAU Schemasを実行しており、それらのスキーマが11g (11.1.1.7以上)または12c (12.1.2.0)からアップグレードされた場合、準備状況チェックが次のエラーで失敗する場合があります。 

Starting index test for table IAU_COMMON:  TEST_REQUIRED_INDEXES --> Test 
that the table contains all the required indexes 
     INFO Audit schema index DYN_EVENT_CATEGORY_INDEX in table IAU_COMMON is 
missing the required columns or index itself is missing. This maybe caused by 
a known issue, anyway, this missing index will be added in 12.2.2 upgrade. 
     INFO Audit schema index DYN_EVENT_TYPE_INDEX in table IAU_COMMON is 
missing the required columns or index itself is missing. This maybe caused by 
a known issue, anyway, this missing index will be added in 12.2.2 upgrade. 
     INFO Audit schema index DYN_TENANT_INDEX in table IAU_COMMON is missing 
the required columns or index itself is missing. This maybe caused by a known 
issue, anyway, this missing index will be added in 12.2.2 upgrade. 
     INFO Audit schema index DYN_USER_INDEX in table IAU_COMMON is missing 
the required columns or index itself is missing. This maybe caused by a known 
issue, anyway, this missing index will be added in 12.2.2 upgrade. 
     INFO Audit schema index DYN_COMPONENT_TYPE_INDEX in table IAU_COMMON is 
missing the required columns or index itself is missing. This maybe caused by 
a known issue, anyway, this missing index will be added in 12.2.2 upgrade. 
     INFO Audit schema index DYN_USER_TENANT_INDEX in table IAU_COMMON is 
missing the required columns or index itself is missing. This maybe caused by 
a known issue, anyway, this missing index will be added in 12.2.2 upgrade. 
   Completed index test for table IAU_COMMON: TEST_REQUIRED_INDEXES --> Test 
that the table contains all the required indexes +++ FAIL

ノート:

準備状況レポートの索引欠落エラーは無視できます。これは既知の問題です。該当の欠落している索引は、スキーマ・アップグレード操作中に追加されます。アップグレードするスキーマがRCUを使用して12cで作成された場合、このエラーは発生しません。

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

OAM構成のアップグレード準備状況チェック

Upgrade Assistant (UA)は、準備状況モードで実行されると、いくつかの構成アップグレード検証チェックを実行します。アップグレード・プロセスを続行する前に、これらの各検証チェックが成功していることを確認してください。

ノート:

UAで後述の構成アップグレード準備状況チェックを実行するには、バグ32081498の修正を含む最新のバンドル・パッチを適用してください。

UAは次の検証チェックを実行します:

  • OPSSおよびOAMキーストアの検証(チェック名: OAM_OPSS_KEYSTORE_CHECK)

    UAは、OPSSキーストアとOAMキーストアの両方から資格証明ストア・フレームワーク(CSF)キーを抽出してそれらを比較します。これらのいずれかのキーストアが破損した場合、読取り操作は失敗し、結果として準備状況チェックも失敗します。CSFキーの読取りが成功するには、それらが同一である必要があります。それ以外の場合、準備状況チェックは失敗します。

    準備状況チェックの失敗理由とそれらの解決方法の提案:

    • jks keyまたはkeystore-csf-keyがCSFに存在しない(OAMキーストア検証が失敗した)ために準備状況チェックが失敗した場合は、キーストア・パスワードを変更または追加します。ドキュメントID 2710662.1またはドキュメントID 2642638.1を参照してください。
    • jks keyとkeystore-csf-keyの値が等しくないために準備状況チェックが失敗した場合は、keystore-csf-key値がjks key値と同じになるように修正します。ドキュメントID 2710664.1またはドキュメントID 2642638.1を参照してください。
    • OAMキーストア・ファイル(.oamkeystore)が存在しないために準備状況チェックが失敗した場合は、バックアップからファイルをリストアし、OAM管理サーバーと管理対象サーバーを再起動して、.oamkeystoreファイルを再作成します。ドキュメントID 2710664.1を参照してください。
    • 準備状況チェックがoam-config.xmlファイルにあるsslGlobalPassphraseの復号化に失敗した場合は、ドキュメントID 2710716.1を参照してください。
  • OAM構成バージョンの一貫性の検証(チェック名: OAM_CONFIG_VERSION_CHECK)

    UAは、oam-config.xmlファイル・システムに設定されているOAM構成バージョンが、データベースに設定されているバージョンと一致していることを確認します。UAは、スキーマ資格証明およびデータベース接続の詳細を抽出して、データベースからoam-configバージョンをフェッチします。次に、ファイル・システムのoam-config.xmlのバージョンを読み取り、そのバージョンをデータベースからフェッチしたoam-configバージョンと比較します。2つのバージョンが一致すると、準備状況チェックは成功し、一致しない場合は失敗します。

    OAMが不正なデータソース名を使用すると、バージョンの不一致が発生します。正しいOAMデータソースを構成して問題を解決してください。ドキュメントID 2492188.1を参照してください。

  • デフォルト・キーストア・ファイルの検証(チェック名: OAM_DEFAULT_KEYSTORE_CHECK)

    UAは、デフォルト・キーストア・ファイルdefault-keystore.jksの存在および有効性をチェックします。アップグレード前にファイルが存在しない場合、準備状況チェックは失敗します。OAMサーバーを再起動してdefault-keystore.jksファイルを生成します。

    ファイルは存在するが、CSFキーを使用してオープンできない場合、無効とみなされます。ファイルが無効であると、準備状況チェックは失敗します。この失敗は、oam-config.xmlに存在するsslGlobalPassphraseの復号化の失敗として表示されます。

    無効なdefault-keystore.jksファイルは、OAMキー(oamKey)が破損している可能性があります。この問題を解決するには、.oamkeystoreファイルのバックアップを取得し、それを<domain_home>/config/fmwconfigから削除し、バックアップからファイルをリストアしてから、OAM管理サーバーと管理対象サーバーを再起動して.oamkeystoreファイルを再作成します。ドキュメントID 2710664.1を参照してください。

  • サポートされていないエージェントの存在のチェック(チェック名: OBSOLETE_AGENT_CHECK)
    UAは、環境内の次のエージェントの存在をチェックします:
    • 10g OSSOエージェント
    • OpenSSOエージェント
    • OAM 10g WebGateエージェント
    • 共存エージェント

    これらのエージェントのいずれかが存在する場合、準備状況チェックの要件は満たされません。サポートされていないエージェントの説明は、『Oracle Identity Managementリリース・ノート』のAccess Manager 12.2.1.3.0でサポートされていない機能に関する項を参照してください。

    アップグレードを開始する前に、サポートされていないエージェントを削除してください。

  • Coherenceキーストアの検証(チェック名: COHERENCE_KEYSTORE_CHECK)

    UAは、キーストアからCSFキーを抽出し、Coherenceキーストアをロードします。次に、Coherenceキーストアにキー別名adminおよび証明書別名assertion-certが存在するかどうかをチェックします。両方のキー値がキーストアに存在する必要があります。この準備状況チェックは、Coherenceキーストアが正しくロードされ、両方のキーがそれに存在する場合に成功します。それ以外の場合、チェックに失敗します。

    チェックに失敗した場合は、欠落しているキーおよび値をCoherenceキーストアに作成してから、キーストアを検証します。ドキュメントID 1986560.1を参照してください。

準備状況レポート・ファイルのサンプルを次に示します。このレポートには、OAMスキーマおよび構成アップグレードの準備状況チェックに関連する部分が表示されます: 

Upgrade readiness check completed with one or more errors.
 
This readiness check report was created on Wed Sep 16 15:50:33 PDT 2020
Log file is located at: /scratch/idmqa/tmp/ua2020-09-16-15-40-18PM.log
Readiness Check Report File: /scratch/idmqa/tmp/readiness2020-09-16-15-50-33PM.txt
Domain Directory: /scratch/idmqa/work/mw35/user_projects/domains/WLS_IDM
 
Starting readiness check of components.
 
...
 
Oracle Access Management Suite (Schema Upgrade)
   Starting readiness check of Oracle Access Management Suite.
     Schema User Name: UPG_OAM
     Database Type: Oracle Database
     Database Connect String: slc11ykm.us.oracle.com:1521:db6844
   Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
     INFO   Database product version: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining 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:  OAM_CONFIG_VERSION_CHECK  Test to check OAM Config version in Database and XML file are equal or not
     INFO OAM Config version from Database: 105
     INFO OAM Config version from XML: 105
     INFO OAM Config version in Database and oam-config.xml are equal
   Completed schema test: OAM_CONFIG_VERSION_CHECK --> Test to check OAM Config version in Database and XML file are equal or not +++ PASS
   Finished readiness check of Oracle Access Management Suite with status: SUCCESS.
 
...
 
Oracle Access Management Suite (Config Upgrade)
   Starting readiness check of Oracle Access Management Suite.
   Starting config test:  CUSTOM_AUTH_PROVIDER_CHECK  Check that custom auth provider exist.
   Completed config test: CUSTOM_AUTH_PROVIDER_CHECK --> Check that custom auth provider exist. +++ PASS
   Starting config test:  SOURCE_CONFIG_CHECK  Test that OAM System configuration is valid.
   Completed config test: SOURCE_CONFIG_CHECK --> Test that OAM System configuration is valid. +++ PASS
   Starting config test:  OAM_OPSS_KEYSTORE_CHECK.  Test that OAM and OPSS keys are valid.
   Completed config test: OAM_OPSS_KEYSTORE_CHECK. --> Test that OAM and OPSS keys are valid. +++ PASS
   Starting config test:  OAM_DEFAULT_KEYSTORE_CHECK  Check that the default keystore is present and valid
     INFO Checking default keystore file: /scratch/idmqa/work/mw35/user_projects/domains/WLS_IDM/config/fmwconfig//default-keystore.jks
     INFO Default keystore file exists and is valid
   Completed config test: OAM_DEFAULT_KEYSTORE_CHECK --> Check that the default keystore is present and valid +++ PASS
   Starting config test:  POLICY_PROVIDER_CHECK  Check that policy provider is valid
   Completed config test: POLICY_PROVIDER_CHECK --> Check that policy provider is valid +++ PASS
   Starting config test:  OBSOLETE_AGENT_CHECK  Check that no obsolete agent exist in oam-config.xml.
     INFO OAM agent co-existence setting is disabled.
     INFO No OpenSSO agent instance exist.
     INFO No OSSO agent instance exist.
     WARNING Please remove following 10G webgate agent before upgrade: IAMSuiteAgent.
   Completed config test: OBSOLETE_AGENT_CHECK --> Check that no obsolete agent exist in oam-config.xml. +++ FAIL
   Finished readiness check of Oracle Access Management Suite with status: FAILURE.
 
...
 
Finished readiness check of components.

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

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

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

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

ノート:

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

ノート:

データベース以外、デプロイメントにあるすべてのサーバーを停止します。アップグレード・プロセス中、データベースが稼働している必要があります。

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

ステップ1: システム・コンポーネントの停止

Oracle HTTP Serverなどの11gシステム・コンポーネントを停止するには、opmnctlスクリプトを使用します:

ノート:

Oracle HTTP Serverが他のサービスと共有されている場合は、Oracle HTTP Serverを停止しないように選択できます。

  • (UNIX) OHS_INSTANCE_HOME/bin/opmnctl stopall

  • (Windows) OHS_INSTANCE_HOME\bin\opmnctl stopall

どの順序でもシステム・コンポーネントを停止できます。

ステップ2: 管理対象サーバーの停止

管理対象サーバーの起動方法に応じて、次のいずれかの方法に従って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')

wls:/offline>nmKill('ManagedServerName')

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

管理サーバーを停止するときに、管理サーバーで稼働しているプロセス(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')

wls:/offline>nmKill('AdminServer')

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

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

kill $(ps -ef | grep nodemanager | awk '{print $2}')

親トピック: Oracle Access Manager単一ノード環境のアップグレード

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

サーバーおよびプロセスを停止した後、アップグレード・アシスタントを使用して、サポートされている製品スキーマを現在のリリースの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のスキーマ・バージョンが適切に更新されていることをチェックして、アップグレードの成功を検証します。

親トピック: Oracle Access Manager単一ノード環境のアップグレード

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

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

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

  1. 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;

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

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

  3. 既存のスキーマに使用していたスキーマ接頭辞名ノートにとっておきます。新しい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を起動する前に、Upgrade Assistantが実行されるプラットフォームのJVM文字コードがUTF-8に設定されていることを確認します。文字エンコーディングがUTF-8に設定されていない場合、名前にUnicode文字が含まれるファイルをダウンロードできません。そのため、アップグレードが失敗する可能性があります。

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

  1. oracle_common/upgrade/binディレクトリに移動します。
    • (UNIX) ORACLE_HOME/oracle_common/upgrade/bin
    • (Windows) ORACLE_HOME\oracle_common\upgrade\bin
  2. Upgrade Assistantの起動:
    • (UNIX) ./ua
    • (Windows) ua.bat

ノート:

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

ロギング・パラメータなど、コマンド・ラインで指定できるその他のパラメータの詳細は、次を参照してください。

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

Upgrade Assistantのパラメータ

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

表3-8 アップグレード・アシスタントのコマンドライン・パラメータ

パラメータ 必須またはオプション 説明

-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 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スキーマがリストされます。

アップグレード・アシスタントを使用して製品スキーマをアップグレードするには:
  1. 「ようこそ」画面には、Upgrade Assistantの概要と、アップグレード前のいくつかの重要なタスクについての情報が表示されます。「次」をクリックします。

    ノート:

    Upgrade Assistantの画面の詳細は、画面上の「ヘルプ」をクリックしてください。
  2. 「選択したスキーマ」画面で、実行するスキーマ・アップグレード操作を選択します。
    • 個別に選択されたスキーマ。アップグレード用のスキーマを個別に選択する場合で、ドメインで使用されるすべてのスキーマをアップグレードしない場合。

      注意:

      12c (12.2.1.3.0)コンポーネントをサポートするために使用されるスキーマのみをアップグレードしてください。Oracle Fusion Middleware 12c (12.2.1.3.0)に含まれていないコンポーネントをサポートするために現在使用されているスキーマをアップグレードしないでください。
    • ドメインで使用されるすべてのスキーマ。アップグレード・アシスタントは、「ドメイン・ディレクトリ」シールドに指定されているドメイン内のアップグレード可能なスキーマがあるすべてのコンポーネントを検索し、選択できます。これは、ドメイン支援のスキーマ・アップグレードとも呼ばれています。さらに、Upgrade Assistantはスキーマの入力画面に接続情報を事前に移入します。

      ノート:

      必要なすべてのスキーマがアップグレードに確実に含まれるようにするため、ほとんどのアップグレードについて「ドメインで使用されるすべてのスキーマ」を選択することをお薦めします。

    ノート:

    11gドメインにOracle Identity Navigatorが含まれている場合、「個別に選択されたスキーマ」を選択し、Oracle Access Manager (OAM)およびOAM関連スキーマのみを選択します。

    Oracle Identity Navigatorは12cではサポートされないため、Oracle Identity Navigator (OIN)およびOIN関連スキーマは選択しないでください。

    「次」をクリックします。

  3. 「個別に選択されたスキーマ」を選択した場合: 「使用可能なコンポーネント」画面で、スキーマをアップグレードするコンポーネントを選択します。コンポーネントを選択すると、スキーマとすべての依存関係が自動的に選択されます。

    「ドメインで使用されるすべてのスキーマ」を選択した場合は、「スキーマの作成」画面で、必要なデータベースの詳細を入力します。これにより、ドメイン内のすべてのスキーマが取得されます。

    「次」をクリックします。

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

    ノート:

    Upgrade Assistantでは前提条件が満たされているかどうかを確認できません。
  5. スキーマ資格証明画面で、アップグレードする各スキーマのデータベース接続詳細を指定します(選択したスキーマに応じて画面名が変更されます)。

    • 「Database Type」ドロップダウン・メニューからデータベース・タイプを選択します。

    • データベース接続の詳細を入力して、「接続」をクリックします。

    • 「スキーマ・ユーザー名」ドロップダウン・メニューからアップグレードするスキーマを選択し、スキーマのパスワードを入力します。アップグレードするスキーマに対して正しいスキーマ接頭辞を使用してください。

      ノート:

      リリース12.1.2のUCSUMSスキーマでは、コンポーネントIDまたはスキーマ名が変わるため、アップグレード・アシスタントは、使用可能なスキーマを自動的に認識し、それらをドロップダウン・リストに表示することはありません。テキスト・フィールドに手動で名前を入力する必要があります。名前はアップグレードの開始ポイントに応じて、prefix_ORASDPMまたはprefix_UMSのいずれかになります。

      UCSUMSスキーマは自動移入されません。ユーザーとしてprefix_ORASDPMを入力します。アップグレード環境ではスキーマ名に_ORASDPMが使用されますが、12c環境ではこれは_UMSと見なされます。

  6. 「調査」画面で、各スキーマを調査したUpgrade Assistantのステータスを確認して、スキーマのアップグレードの準備が整っていることを検証します。ステータスが「調査が終了しました。」になっている場合は、「次」をクリックします。
    調査フェーズが失敗した場合は、「調査失敗」ダイアログで「いいえ」をクリックして、アップグレードを取り消すことをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、一般的なアップグレード・エラーの解決の詳細をUpgrade Assistantによるアップグレード のアップグレードのトラブルシューティングで参照してください。

    ノート:

    • 確認フェーズ中に検出された問題を、アップグレードを進めずに解決した場合は、バックアップからリストアを再び行わずにUpgrade Assistantを開始できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックしてアップグレードを続行していた場合は、Upgrade Assistantを再開する前に、バックアップからアップグレード前の環境をリストアする必要があります。

    • 調査プロセスを取り消してもスキーマまたは構成データに影響はありませんが、将来のアップグレード・セッションでは、Upgrade Assistantが収集した情報を再収集する必要があります。

  7. 「アップグレード・サマリー」画面で、スキーマのアップグレードに選択したオプションのサマリーを確認します。
    アップグレード対象のスキーマごとに、正しいソース・バージョンとターゲット・バージョンがリストされていることを確認します。
    これらのオプションを保存して、今後、レスポンス(サイレンス)モードでUpgrade Assistantを再実行する場合は、「レスポンス・ファイルの保存」をクリックして、レスポンス・ファイルの場所と名前を指定します。サイレント・アップグレードは、Upgrade Assistantとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。
    「アップグレード」をクリックして、アップグレード・プロセスを開始します。
  8. 「アップグレードの進行状況」画面で、アップグレードのステータスを監視します。

    注意:

    Upgrade Assistantにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。これを行うと、環境が不安定になる可能性があります。
    正しくアップグレードされていないスキーマがある場合は、Upgrade Assistantのログ・ファイルで情報を確認します。

    ノート:

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

    「次」をクリックします。

  9. アップグレードが成功した場合: 「アップグレード成功」画面で、「閉じる」をクリックし、アップグレードを完了してウィザードを閉じます。

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

    ノート:

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

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

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

すべてのアップグレード・ステップを完了したら、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ユーザーを元に戻します。

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

ドメインの再構成について

再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.3.0)にあわせて再構成します。

WebLogic Serverドメインを再構成すると、ドメイン内のアプリケーションに応じて、次の項目が自動的に更新されます。

  • WebLogic Serverコア・インフラストラクチャ

  • ドメイン・バージョン

ノート:

ドメインの再構成を開始する前に、次の制限事項に注意してください。

  • 再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。

  • アップグレード・プロセス中に、非動的クラスタ・ドメインを動的クラスタ・ドメインに変換することはサポートされていません。

    動的クラスタ機能は、再構成ウィザードの実行中に使用できますが、サポートされているアップグレードは非動的クラスタのアップグレードのみで、その後で動的クラスタを追加することになります。アップグレード・プロセス中に動的クラスタを追加することはできません。

具体的には、ドメインを再構成する場合、次のことが発生します。

  • ドメインのconfig.xmlファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンに更新されます。

  • すべてのインストール済Oracle製品の再構成テンプレートは、自動的に選択されてドメインに適用されます。これらのテンプレートは、WebLogicドメインが現在のWebLogic Serverバージョンと互換性を持つために必要な再構成タスクを定義します。

  • 起動スクリプトが更新されます。

    変更済の起動スクリプトを維持する場合は、そのスクリプトをバックアップしてから、再構成ウィザードを開始してください。

ノート:

ドメイン再構成プロセスが開始されると、そこで行われた変更は元に戻せません。再構成ウィザードを実行する前に、アップグレード前のチェックリストに示されているようにドメインのバックアップを作成したことを確認します。再構成ウィザードの実行中にエラーまたは他の割込みが発生した場合、バックアップ場所から元のドメイン・ディレクトリにファイルとディレクトリをコピーすることによって、ドメインをリストアする必要があります。これは、再構成前にドメインを確実に元の状態に戻す唯一の方法です。

再構成ウィザードを使用して既存のドメインを再構成する手順に従います。Oracle WebLogic ServerのアップグレードのWebLogicドメインの再構成を参照してください。

親トピック: Oracle Access Manager単一ノード環境のアップグレード

ドメインのバックアップ

再構成ウィザードの実行前に、ドメイン・ディレクトリのバックアップ・コピーを作成します。

管理サーバーのドメイン・ディレクトリのバックアップを作成するには:

  1. コンテンツを保持するには、ソース・ドメインを別の場所にコピーします。

    (Windows) copy /home/Oracle/config/domains to /home/Oracle/config/domains_backup。

    (UNIX) cp -rf domains domains_backup

  2. HA環境では、各リモート管理対象サーバーのドメインを更新する前に、各リモート・マシンのドメイン・ディレクトリのバックアップ・コピーを作成します。
  3. ドメインのバックアップしたバージョンが完全であることを確認します。
なんらかの理由でドメインの再構成が失敗した場合は、すべてのファイルおよびディレクトリをバックアップ・ディレクトリから元のドメイン・ディレクトリにリストアしてドメインを完全に再構成前の元の状態に戻す必要があります。

親トピック: ドメインの再構成について

再構成ウィザードの起動

ノート:

再構成プロセスを開始する前に、管理サーバーおよびすべてのコロケート管理対象サーバーを停止します。「サーバーとプロセスの停止」を参照

再構成ウィザードをグラフィカル・モードで起動するには:

  1. コマンド・シェル(UNIXオペレーティング・システムの場合)またはコマンド・プロンプト・ウィンドウ(Windowsオペレーティング・システムの場合)を開きます。
  2. エディション・ベースのデータベース・ユーザーのみ: スキーマがEBRデータベースを使用して構成されている場合、再構成ウィザードを実行する前に、手動でデフォルトのエディション名を設定する必要があります。
    次のSQLコマンドを実行して、デフォルト・エディションを設定します。

    ALTER DATABASE DEFAULT EDITION = edition_name;

    ここで、edition_nameは、子エディションの名前です。

  3. oracle_common/common/binディレクトリに移動します。
    • (UNIX) ORACLE_HOME/oracle_common/common/bin
    • (Windows) ORACLE_HOME\oracle_common\commom\bin

    ORACLE_HOMEは、12c Oracleホームです。

  4. 再構成ウィザードを起動します。
    ./reconfig.shコマンドによって、デフォルトのキャッシュ・ディレクトリが有効でないことを示す次のエラーが表示される場合があります:
    *sys-package-mgr*: can't create package cache dir

    そのため、最初に環境変数CONFIG_JVM_ARGSを設定することでキャッシュ・ディレクトリを変更します。

    例: CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

    次に示すロギングオプションを指定して、再構成ウィザードを開始します。
    • (UNIX) ./reconfig.sh -log=log_file -log_priority=ALL
    • (Windows) reconfig.cmd -log=log_file -log_priority=ALL

    log_fileは、ドメイン再構成セッション用に作成するログ・ファイルの絶対パスです。これは、再構成処理をトラブルシューティングする必要がある場合に役立つことがあります。

    パラメータ-log_priority=ALLは、ログを詳細モードで出力します。

親トピック: ドメインの再構成について

Oracle Access Managerドメインの再構成

再構成ウィザードの各画面を通じて、既存の11gドメインを再構成します。

ノート:

ソースがクラスタ化環境の場合、プライマリ・ノードでのみ再構成ウィザードを実行します。ここで、プライマリ・ノードは管理サーバーです。圧縮/解凍ユーティリティを使用して、ドメイン内の他のクラスタ・メンバーに変更を適用します。
再構成ウィザードを使用してドメインを再構成するには:
  1. 「ドメインの選択」画面で、アップグレードするドメインの場所を指定するか、「参照」をクリックしてナビゲートし、ドメインのディレクトリを選択します。「次」をクリックします。
  2. 「再構成セットアップの進行状況」画面で、セットアップ・プロセスの進行状況を確認します。完了したら、「次へ」をクリックします。
    このプロセス中に:

    • Fusion Middleware製品を含む、インストール済製品の再構成テンプレートが自動的に適用されます。これにより、config.xml、config-groups.xml、security.xmlなどの様々なドメイン構成ファイルが更新されます。

    • Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

    • ドメイン・アップグレードが検証されます。

  3. 「ドメイン・モードおよびJDK」画面で、ドメインで使用するJDKを選択するか、「参照」をクリックして、使用するJDKにナビゲートします。12c (12.2.1.3.0)に対してサポートされているJDKバージョンは、1.8.0_131以降です。「次」をクリックします。

    ノート:

    このステージでは、「ドメイン・モード」を変更することはできません。
    特定のプラットフォームでサポートされているJDKのリストは、Oracle Fusion Middlewareでサポートされているシステム構成の説明を参照してください。
  4. 「データベース構成タイプ」画面で、「RCUデータ」を選択して、サーバー表(_STB)スキーマに接続します。
    RCUサービス表(_STB)スキーマ資格証明を使用してデータベース接続の詳細を入力して、「RCU構成の取得」をクリックします。
    再構成ウィザードは、この接続を使用して、ドメインのコンポーネントに必要なデータソースを自動的に構成します。

    ノート:

    デフォルトでは、Oracleのサービス接続用ドライバ(Thin)、バージョン: 任意のドライバが選択されています。接続の詳細で、サービス名ではなくインスタンス名を指定した場合は、Oracleのプール済インスタンス接続用ドライバ(Thin)、バージョン: 任意を選択する必要があります。ドライバ・タイプを変更しないと、接続に失敗します。

    HA環境でRACデータベースのグリッド・リンクを選択する方法の詳細は、Access Managerの高可用性アーキテクチャに関する項を参照してください。

    ノート:

    既存の11gデータ・ソースの場合、再構成では既存の値が保持されます。スキーマがRCUで12c用に作成されている新しいデータ・ソースの場合、デフォルトの接続データは_STBスキーマから取得されます。特定のスキーマの接続データが_STBスキーマにない場合は、デフォルトの接続データが使用されます。
    チェックが成功した場合は、「次へ」をクリックします。チェックが失敗した場合は、接続の正しい詳細を再入力し、再試行します。

    ノート:

    データベースに_OPSSまたは_IAU 11gデータベース・スキーマがある場合は、それらのスキーマに対してデータベース接続の詳細を手動で入力する必要があります。これらのスキーマは、11gでは必要なかったため、手動で作成する必要がありました。ユーザーはこれらのスキーマに名前を割り当てることができるため、再構成ウィザードでは識別しません。_IAUの接続情報を提供する場合、IAU_APPENDユーザー情報を使用します。
  5. 「JDBCコンポーネント・スキーマ」画面で、次のコンポーネント・スキーマのDBMS/サービスおよびホスト名が正しいことを確認します。
    • OPSS監査スキーマ
    • OPSS監査ビューア・スキーマ
    • OPSSスキーマ

    RACデータベースに接続している場合は、更新する各スキーマを選択し、「グリッド・リンクに変換」をクリックします。「次」をクリックして、サービス名、スキーマ・パスワード、SCAN、ホスト名/ポート、ONSホスト/ポートを更新します。

    「次」をクリックします。

  6. 「JDBCコンポーネント・スキーマ・テスト」画面で、すべてのコンポーネント・スキーマを選択して、「選択された接続のテスト」をクリックして各スキーマの接続をテストします。テストの結果は、「ステータス」列に表示されます。
    チェックが完了したら、「次へ」をクリックします。
  7. 「ノード・マネージャ」画面で、要件に基づいて適切な「ノード・マネージャ・タイプ」選択し、「次」をクリックします。

    ノート:

    ノード・マネージャには2つのタイプがあります。ドメインごとに異なるバージョンのノード・マネージャを使用できるように、ドメインベースのノード・マネージャを使用することをお薦めします。
  8. 「拡張構成」画面で、「管理サーバー」、「トポロジ」および「デプロイメントとサービス」を選択します。必要に応じて「ドメイン・フロントエンド・ホストのキャプチャ」を選択します。
    選択した各カテゴリの適切な構成画面が表示され、詳細な構成を実行できます。

    ノート:

    使用するoam_server1またはOAM管理対象サーバー名をサーバー・グループOAM-MDG-SVRSに、oam_policy_mgr1をサーバー・グループOAM-POLICY-MANAGED-SERVERに割り当ててください。
  9. 「構成のサマリー」画面で、ドメインの詳細な構成設定を確認してから続行します。
    「表示」ドロップダウン・リストからフィルタ・オプションを選択すると、右側のパネルに表示される項目を制限できます。
    構成を変更するには、「戻る」をクリックして適切な画面に戻ります。ドメインを再構成するには、「再構成」をクリックします。

    ノート:

    ドメインを再構成しても、その場所は変更されません。
  10. 「再構成の進行状況」画面には、再構成プロセスの進行状況が表示されます。
    このプロセス中に:

    • ドメイン情報が抽出、保存および更新されます。

    • Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

    進捗バーが100%になったら、「次へ」をクリックします。
  11. 「構成の終了」画面に、再構成プロセスが成功して完了したか、または失敗したかどうかが示されます。管理サーバーURL(リスニング・ポートを含む)とともに再構成されたドメインの場所も表示します。再構成が成功した場合は、「Oracle Weblogic Serverの再構成に成功しました」と表示されます。
    再構成プロセスが正常に完了しなかった場合は、その理由を示すエラー・メッセージが表示されます。問題を解決するための適切な措置を講じます。問題を解決できない場合は、My Oracle Supportに連絡してください。
    以後の操作のためにドメインの場所と管理サーバーURLをメモします。

親トピック: ドメインの再構成について

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

ドメインを再構成した後、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 (OMSM)アプリケーションを使用しており、Oracle Access Manager 12c (12.2.1.3.0)にアップグレードされたOracle Access Manager 11g (OAM 11.1.23.x)環境にのみ適用されます。
  • サーバーとプロセスの起動
    アップグレードが成功した後、管理サーバーおよび管理対象サーバーを含め、すべてのプロセスおよびサーバーを起動します。
  • ドメイン固有コンポーネント構成のアップグレードの確認
    ドメイン固有コンポーネント構成のアップグレードが成功したことを確認するには、管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlにサインインし、各コンポーネントのバージョン番号が12.2.1.3.0であることを確認します。

親トピック: Oracle Access Manager単一ノード環境のアップグレード

Upgrade Assistantの起動

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

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

ノート:

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

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

  1. oracle_common/upgrade/binディレクトリに移動します。
    • (UNIX) ORACLE_HOME/oracle_common/upgrade/bin
    • (Windows) ORACLE_HOME\oracle_common\upgrade\bin
  2. Upgrade Assistantの起動:
    • (UNIX) ./ua
    • (Windows) ua.bat

ノート:

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

ロギング・パラメータなど、コマンド・ラインで指定できるその他のパラメータの詳細は、次を参照してください。

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

Upgrade Assistantのパラメータ

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

表3-9 アップグレード・アシスタントのコマンドライン・パラメータ

パラメータ 必須またはオプション 説明

-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の起動

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

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

再構成ウィザードを実行してWebLogicドメインを12c (12.2.1.3.0)に再構成した後に、アップグレード・アシスタントを実行して、ドメイン・コンポーネント構成を、更新されたドメイン構成に一致するようにアップグレードする必要があります。

Upgrade Assistantでドメイン・コンポーネント構成をアップグレードするには:
  1. 「ようこそ」画面には、Upgrade Assistantの概要と、アップグレード前のいくつかの重要なタスクについての情報が表示されます。「次」をクリックします。

    ノート:

    Upgrade Assistantの画面の詳細は、画面上の「ヘルプ」をクリックしてください。
  2. 次の画面で、次を実行します。

    • 「ドメインによって使用されるすべての構成」を選択します。画面名が「WebLogicコンポーネント」に変更されます。

    • 「ドメイン・ディレクトリ」フィールドで、11.1.2.3.0のドメイン・ディレクトリのパスを入力します。

    「次」をクリックします。

  3. 「コンポーネント・リスト」画面で、構成をアップグレードするコンポーネントがリストにすべて含まれていることを確認し、「次」をクリックします。
    アップグレードするコンポーネントが表示されない場合は、「戻る」をクリックして前の画面に移動し、異なるドメインを指定します。
  4. 「前提条件」画面で、すべてのチェック・ボックスを選択して、前提条件を満たしていることを確認します。「次」をクリックします。

    ノート:

    Upgrade Assistantでは前提条件が満たされているかどうかを確認できません。
  5. 「調査」画面で、各コンポーネントを調査したUpgrade Assistantのステータスを確認して、コンポーネント構成のアップグレードの準備が整っていることを検証します。ステータスが「調査が終了しました。」になっている場合は、「次」をクリックします。
    調査フェーズが失敗した場合は、「調査失敗」ダイアログで「いいえ」をクリックして、アップグレードを取り消すことをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、一般的なアップグレード・エラーの解決の詳細をUpgrade Assistantによるアップグレード のアップグレードのトラブルシューティングで参照してください。

    ノート:

    • 確認フェーズ中に検出された問題を、アップグレードを進めずに解決した場合は、バックアップからリストアを再び行わずにUpgrade Assistantを開始できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックしてアップグレードを続行していた場合は、Upgrade Assistantを再開する前に、バックアップからアップグレード前の環境をリストアする必要があります。

    • 調査プロセスを取り消しても構成データに影響はありませんが、将来のアップグレード・セッションでは、Upgrade Assistantが収集した情報の再収集が必要になります。

  6. 「アップグレード・サマリー」画面で、コンポーネント構成のアップグレードに選択したオプションのサマリーを確認します。
    レスポンス・ファイルには、入力したすべての情報が収集および格納されます。このファイルにより、その後のサイレント・アップグレードの実行が可能になります。サイレント・アップグレードは、Upgrade Assistantとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。
    「アップグレード」をクリックして、アップグレード・プロセスを開始します。
  7. 「アップグレードの進行状況」画面で、アップグレードのステータスを監視します。

    注意:

    Upgrade Assistantにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。これを行うと、環境が不安定になる可能性があります。
    正しくアップグレードされていないコンポーネントがある場合は、Upgrade Assistantのログ・ファイルで情報を確認します。

    Upgrade Assistantのログ・ファイルの場所:

    • (UNIX) ORACLE_HOME/oracle_common/upgrade/logs/ua<timestamp>.log
    • (Windows) ORACLE_HOME\oracle_common\upgrade\logs\ua<timestamp>.log

    ノート:

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

    「次」をクリックします。

  8. アップグレードが正常に終了した場合: 「アップグレード成功」画面で、「閉じる」をクリックしてアップグレードを完了しウィザードを閉じます。新規インストールでコンポーネントを機能させるために手動で実行する必要のある作業が、アップグレード後のアクションウィンドウに表示されます。このウィンドウは、コンポーネントにアップグレード後のステップがある場合のみ表示されます。
    アップグレードが失敗した場合: 「アップグレード失敗」画面で「ログの表示」をクリックして、エラーを確認し、トラブルシューティングします。ログは、ORACLE_HOME/oracle_common/upgrade/logsにあります。

    ノート:

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

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

Oracle Mobile Security Managerサーバーのフットプリントの削除

このアクティビティは、Oracle Mobile Security Manager (OMSM)アプリケーションを使用しており、Oracle Access Manager 12c (12.2.1.3.0)にアップグレードされたOracle Access Manager 11g (OAM 11.1.23.x)環境にのみ適用されます。

Oracle Mobile Security Manager (OMSM)アプリケーションは、OAM 12c (12.2.1.3.0)ではサポートされていません。したがって、OMSMのすべてのコンポーネントを削除することをお薦めします。すべてのコンポーネントを削除すると、OMSMアプリケーションを実行するWebLogic Server管理対象サーバーを誤って起動した場合の潜在的な問題が回避されます。

OMSMコンポーネントを次の領域から削除する必要があります:
  • WebLogic Server管理対象サーバー
  • 製品のディレクトリ構造
  • データベース・スキーマ

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

ドメインからのWebLogic Server OMSM管理対象サーバーの削除
ドメインからWebLogic Server OMSM管理対象サーバーを削除するには:
  1. WebLogic Server管理サーバーのみが実行されていることを確認します。
  2. WebLogic Serverコンソールにアクセスしてログインします。
  3. 「環境」をクリックし、「クラスタ」、「Coherenceクラスタ」の順に選択します。
  4. OMSMサーバーを含むメンバーの名前を含むクラスタ名を選択します。
  5. 「メンバー」タブをクリックし、OMSMサーバーの選択を解除して「保存」をクリックします。
  6. 「環境」をクリックし、「サーバー」を選択します。
  7. OMSMサーバーを選択して「削除」をクリックします。
  8. WebLogic Serverタイプ(本番または開発)に応じて、追加ステップを実行して変更をアクティブ化します。
    これで、WebLogic Server管理対象OMSMサーバーは存在しなくなります。
  9. WebLogic Server管理アプリケーションからログアウトします。
ディレクトリ構造からのWebLogic Server OMSM管理対象サーバーの削除
ディレクトリ構造からWebLogic Server OMSM管理対象サーバーを削除するには:
  1. WebLogic Server管理サーバーおよび管理対象サーバーが停止していることを確認します。
  2. ターミナル・プロンプトから、DOMAIN_HOME/serversの場所に移動します。
  3. lsコマンドを実行します。

    サーバー名のリストが表示されます。OMSMサーバーの名前を書き留めます。

    たとえば:

    wls_msm1, wls_msm2, and so on.
  4. 次のコマンドを実行して、OMSMサーバーを削除します:
    rm -rf MSM_Server

    前述のコマンドで、MSM_ServerはOracle Mobile Security Manager (OMSM)サーバーの名前です。たとえば: 

    rm -rf wls_msm1

    追加のOMSMサーバーに対して、必要に応じてこのステップを繰り返します。

    これで、OMSMサーバーのディレクトリ構造は存在しなくなります:
    m wls_msm1
データベースからのOMSMサーバー・スキーマ・オブジェクトの削除

Oracle Mobile Security Manager (MSM)スキーマ・オブジェクトを削除するには:

  1. WebLogic Server管理サーバーおよび管理対象サーバーが停止していることを確認します。
  2. 任意のツールを使用して、データベース・システム・スキーマに接続し、次の問合せを実行します:
    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;

    問合せ結果に、OMSMとしてCOMP_IDが表示されます。OWNERに注意してください。

  3. 11.1.1.9.0リポジトリ作成ユーティリティ(RCU)を使用して、OMSMスキーマを削除します。
    1. 次のコマンドを実行して、RCUアプリケーションを起動します:

      /rcu

    2. 「ようこそ」画面で、「次へ」をクリックします。
    3. 「リポジトリの作成」画面で、「リポジトリの削除」を選択し、「次」をクリックします。
    4. 次の表の説明に従って、データベース接続資格証明を指定します:

      表3-10 データベース接続の詳細

      オプション 説明および例

      ホスト名

      データベースが実行されるサーバーの名前を、次の書式で指定します:

      <FQDN>

      Oracle RACデータベースの場合、いずれかのノードのVIP名または名前を指定します。

      ポート

      データベースのポート番号を指定します。Oracleデータベースのデフォルトのポート番号は、1521です。

      サービス名

      データベースのサービス名を指定します。通常、サービス名はグローバル・データベース名と同じです。

      Oracle RACデータベースの場合、いずれかのノードのサービス名を指定します。例: <INSTANCE_NAME_FQDN>

      ユーザー名

      データベースのユーザー名を指定します。デフォルトのユーザー名はSYSです。

      パスワード

      データベース・ユーザーのパスワードを指定します。

      ロール

      ドロップダウン・リストからデータベース・ユーザーのロール(「標準」または「SYSDBA」)を選択します。

      「次」をクリックします。

      別のダイアログ・ウィンドウが開き、接続、およびデータベースの前提条件がチェックされます。エラーなしでデータベースのチェックをパスしたら、「OK」をクリックしてこのダイアログ・ウィンドウを閉じ、次の画面に進みます。

    5. 「サマリー」画面で情報を確認し、「削除」をクリックしてスキーマを削除します。
    6. 「完了サマリー」画面でログ・ファイルの場所を確認し、「閉じる」をクリックして画面を終了します。
  4. ステップ1を繰り返して、次の問合せを実行します:
    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;

    これで、問合せ結果にCOMP_ID OMSMが表示されなくなります。

  5. WebLogic Server管理サーバーおよび管理対象サーバーを起動します。

サーバーおよびプロセスの起動

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

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

ノート:

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

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

ステップ1: ノード・マネージャを起動する

管理サーバー・ドメイン・ホームでのノード・マネージャの起動:

  • (UNIX) nohup ./startNodeManager.sh > DOMAIN_HOME/nodemanager/nodemanager.out 2>&1 &

  • (Windows) nohup .\startNodeManager.sh > DOMAIN_HOME\nodemanager\nodemanager.out 2>&1 &

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

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

管理サーバーを起動するには、startWebLogicスクリプトを使用します。

  • (UNIX) DOMAIN_HOME/bin/startWebLogic.sh

  • (Windows) DOMAIN_HOME\bin\startWebLogic.cmd

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

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

方法1: Weblogicコンソールを使用して、WebLogic Server管理対象サーバーを起動します:
  • weblogic管理者としてWeblogicコンソールにログインします。
  • 「サーバー」 > 「制御」タブに移動します。
  • 必要な管理対象サーバーを選択します。
  • 「起動」をクリックします。

方法2: startManagedWebLogicスクリプトを使用して、WebLogic Server管理対象サーバーを起動します:

  • (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.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コンソールにアクセスできる必要があります。

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

アップグレード後のタスクの実行

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ファイルを更新する必要があります。

親トピック: Oracle Access Manager単一ノード環境のアップグレード

認証中にWebGates構成が失敗する

globalHMACEnabledがtrueに設定されていない環境で、hmacEnabled=trueで構成されたWebGatesは、認証中に失敗します。

この問題を解決するには、パッチ12.2.1.3.181016以降を適用します。

詳細は、「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ファイルを更新する必要があります。

これを行うには:
  1. JAVA_HOME/jre/lib/security/にあるjava.securityファイルをテキスト・エディタで開きます。
  2. TLSv1、TLSv1.1、MD5withRSAを次のキーから削除します。
    key - jdk.tls.disabledAlgorithms
  3. MD5を次のキーから削除します。
    key - jdk.certpath.disabledAlgorithms
考えられるアップグレード・シナリオの詳細は、「アップグレード時のセキュリティ・ポリシーの問題のトラブルシューティング」を参照してください。

親トピック: アップグレード後のタスクの実行

パッチ後のインストール・ステップの実行

アップグレードが完了した後、パッチ後のインストール・ステップを実行する必要があります。

パッチ後のインストール・ステップは次で構成されます:

親トピック: Oracle Access Manager単一ノード環境のアップグレード

poststartコマンドの実行によるバイナリ・パッチ適用の成功の確認

次に示すように、変数およびスタック・バッチ・バンドルのREADME.txtファイルの手順を使用して、製品の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を参照してください。

親トピック: パッチ後のインストール・ステップの実行

サーバーのクリーン再起動の実行

すべてのサーバー(管理サーバーおよび管理対象サーバーを含む)を再起動します。「サーバーとプロセスの起動」を参照してください。

親トピック: パッチ後のインストール・ステップの実行