6 以前の12cリリースからのOracle SOA SuiteおよびBusiness Process Managementのアップグレード

以前の12cリリースからアップグレードする場合、次のステップを使用してこのリリースにアップグレードします。

これらの手順を使用して、既存のSOA SuiteおよびBusiness Process Management 12c (12.1.3または12.2.1.x)ドメインを12c (12.2.1.3.0)にアップグレードします

ノート:

以前の12cリリースからアップグレードする場合、最新の12cにアップグレードするには、これらすべてのタスクを完了する必要があります。最新の12cディストリビューションを同じOracleホームにインストールすることで既存のドメインをアップデートしようとしないでください。ドメインを最新の12cリリースにアップグレードすることは、パッチ・セット・インストールではありません。

• 以前の12cリリースからのアップグレードの理解
  以前の12c リリースからのアップグレードには、11gからのアップグレード時に使用される一連の様々なアップグレード手順が含まれますが、まだフル・アップグレードが必要になります。
• Oracle SOA SuiteおよびBusiness Process Managementの12c (12.2.1.3.0)製品ディストリビューションのインストール
  アップグレードを開始する前に、Oracle Universal Installerを使用してOracle Fusion Middleware Infrastrucutreディストリビューション、Oracle SOA SuiteおよびBusiness Process Management 12c (12.2.1.3.0)ディストリビューション、およびその他のSOA Suite製品をターゲット・システムにインストールします。
• アップグレード前の準備状況チェックの実行
  アップグレードにかかわる潜在的な問題を特定するために、アップグレード・プロセスの開始前に、準備状況チェックの実行をお薦めします。準備状況チェックではアップグレードに関する潜在的なすべての問題を検出できるわけではない可能性があることに注意してください。準備状況チェックで成功とレポートされた場合でも、アップグレードが失敗する可能性があります。
• サーバーとプロセスの停止
  Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、すべてのアップグレード前のプロセス、および管理サーバーや管理対象サーバーを含めたすべてのサーバーを停止する必要があります。
• 製品スキーマのアップグレード
  サーバーとプロセスの停止後に、Upgrade Assistantを使用して、サポートされている製品スキーマをOracle Fusion Middlewareの現在のリリースにアップグレードします。
• ドメインの再構成について
  再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.3.0)にあわせて再構成します。
• ドメイン・コンポーネント構成のアップグレード
  ドメインを再構成した後、Upgrade Assistantを使用して、更新したドメイン構成と一致するようドメイン内のドメイン・コンポーネント構成をアップグレードします。

以前の12cリリースからのアップグレードの理解

以前の12c リリースからのアップグレードには、11gからのアップグレード時に使用される一連の様々なアップグレード手順が含まれますが、まだフル・アップグレードが必要になります。

12.1.2、12.1.3、12.2.1.0、12.2.1.1または12.2.1.2など、以前の12cリリースからのアップグレード時は、12c (12.2.1.3.0)に到達するようフル・アップグレードを実行します。

Oracle SOA SuiteおよびBusiness Process Managementの12c (12.2.1.3.0)製品ディストリビューションのインストール

アップグレードを開始する前に、Oracle Universal Installerを使用してOracle Fusion Middleware Infrastrucutreディストリビューション、Oracle SOA SuiteおよびBusiness Process Management 12c (12.2.1.3.0)ディストリビューション、およびその他のSOA Suite製品をターゲット・システムにインストールします。

ノート:

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

開始する前に、次の点に注意してください。

• 以前の12cリリースからアップグレードする場合は、12c (12.2.1.3.0)ディストリビューションを新しいOracleホームにインストールする必要があります。このアップグレードのために既存のOracleホームを再使用しようとしないでください。12c (12.2.1.3.0)へのアップグレードは、パッチ・リリースではありません。

• Oracle SOA Suiteには、Oracle Fusion Middleware Infrastructure (Oracle WebLogic ServerおよびJRF)が必要です。

  Fusion Middlewareインフラストラクチャをインストールすると、Oracleホーム・ディレクトリが作成され、その他のFusion Middleware製品をインストールするためのサポート・ソフトウェアが配置されます。

• SOAドメインにOracle Service Bus、Managed File TransferまたはOracle B2Bなどのその他のSOA統合コンポーネントがある場合は、それらのディストリビューションを同じ新しいOracleホームにインストールする必要があります。Oracle Business Activity MonitoringおよびBusiness Process Managementは、SOAディストリビューションsoa_generic.jarの一部です。

Oracle SOA Suiteコンポーネント・ディストリビューションをインストールするには:

1. ターゲットのシステムにサインインします。
2. Oracle Technology NetworkまたはOracle Software Delivery Cloudからターゲット・システムに次のディストリビューションをダウンロードします。
   • Fusion Middleware Infrastructureディストリビューション(fmw_12.2.1.3.0_infrastructure_generic.jar)
   • Fusion Middleware SOA SuiteおよびBusiness Process Managementディストリビューション(fmw_12.2.1.3.0_soa_generic.jar)
   • Managed File Transfer、Oracle Service BusまたはOracle B2Bを実行している場合は、Managed File Transferディストリビューション(fmw_12.2.1.3.0_mft_generic.jar)、Oracle Service Bus (fmw_12.2.1.3.0_osb_generic.jar)およびOracle B2B (fmw_12.2.1.3.0_b2b_generic.jar)をダウンロードします。
3. 12c (12.2.1.3.0)製品ディストリビューションをダウンロードしたディレクトリに移動します。
4. Oracle Fusion Middleware Infrastructureのインストール・プログラムを起動します。
   • (UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.3.0_infrastructure_generic.jar
   • (Windows) JDK_HOME\bin\java -jar fmw_12.2.1.3.0_infrastructure_generic.jar
5. UNIXオペレーティング・システムでは、このホストにOracle製品を初めてインストールする場合に、「インストール・インベントリの設定」画面が表示されます。
   中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システム・グループ名に対して中央インベントリの場所への書込み権限が付与されていることを確認し、「次へ」をクリックします。

   ノート:

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

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

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

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

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

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

12. 「インストールの進行状況」画面で、進行状況バーに100%と表示されたら、「終了」をクリックしてインストーラを終了するか、「次へ」をクリックしてサマリーを表示します。
13. 「インストール完了」画面に、インストールの場所とインストールされた機能セットが表示されます。情報を確認し、「終了」をクリックしてインストーラを閉じます。
14. Infrastructureをインストールしたら、ステップ3から13までを繰り返してその他の製品ディストリビューションをインストールします。

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

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

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

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

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

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

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

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

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

ノート:

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

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

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

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

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

   ノート:

   GUIモードが使用可能になるようDISPLAY環境変数が正しく設定されていない場合は、次のエラーが発生する可能性があります。

   Xlib: connection to ":1.0" refused by server
   Xlib: No protocol specified 

   この問題を解決するには、DISPLAY環境変数をローカル・ワークステーションのシステム名またはIPアドレスに設定して、Upgrade Assistantを再実行します。

   DISPLAYを設定してもこれらのエラーが発生し続ける場合は、vncconfigなど、他のGUIツールの起動を試みてください。同じエラーが表示される場合は、DISPLAY環境変数がまだ正しく設定されていない可能性があります。

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

• アップグレード・アシスタントのパラメータ
  

アップグレード・アシスタントのパラメータ

アップグレード・アシスタントをコマンド・ラインから起動する際に、追加パラメータを指定できます。

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

パラメータ	必須またはオプション	説明
-readiness	準備状況チェックに必要 ノート: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。	実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。 スキーマおよび構成がチェックされます。 -examineパラメータを指定した場合は、このパラメータを使用しないでください。
-threads	オプション	スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。
-response	サイレント・アップグレードまたはサイレント準備状況チェックに必要	GUIモードでの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) NEW_ORACLE_HOME/oracle_common/upgrade/logs NEW_ORACLE_HOME/oracle_common/upgrade/temp (Windows) NEW_ORACLE_HOME/oracle_common/upgrade/logs NEW_ORACLE_HOME/oracle_common/upgrade/temp
-help	オプション	すべてのコマンドライン・オプションを表示します。

Upgrade Assistantでの準備状況チェックの実行

Upgrade Assistantで複数の画面をナビゲートし、アップグレード前の準備状況チェックを完了します。

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

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

1. 「ようこそ」画面で、準備状況チェックに関する情報を確認します。「次へ」をクリックします。
2. 「準備状況チェック・タイプ」画面で、実行する準備状況チェックを選択します。
   • 「個別に選択されたスキーマ」を使用すると、アップグレード前の確認のために個々のスキーマを選択できます。準備状況チェックにより、スキーマがアップグレードのサポート対象かどうか、またはアップグレードが必要な場所がレポートされます。

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

   • 「ドメイン・ベース」を使用すると、Upgrade Assistantで、「ドメイン・ディレクトリ」フィールドで指定したドメイン内の、アップグレードに適格なすべてのスキーマまたはコンポーネント構成を検出および選択できます。

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

     Upgrade Assistantですべてのスキーマおよびコンポーネント構成を同時にチェックする場合はデフォルトの選択内容のままにします。そうでない場合は、次の特定のオプションを選択します。

     • アップグレード可能なスキーマがあるすべてのコンポーネントを検出および確認するには、「すべてのスキーマのチェックを含める」。

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

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

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

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

   • ドメイン・ディレクトリを指定します。

   • スキーマ資格証明を指定して、選択したスキーマに接続します(「データベース・タイプ」、「DBAユーザー名」および「DBAパスワード」)。次に、「接続」をクリックします。

     ノート:

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

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

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

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

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

準備状況レポートの理解

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

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

readiness<timestamp>.txt

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

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

表6-2 準備状況レポートの要素

レポートの情報	説明	必要なアクション
全体的な準備状況ステータス: 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 March 30 11:15:52 EDT 2019
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: [e-mail]
     VERSION Schema DEV11_MDS is currently at version 12.2.1.4.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 12c Enterprise Edition Release 12.2.1.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
   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 (12.2.1.3.0)で作成されていた場合は発生しません。

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

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

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

ノート:

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

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

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

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

• (UNIX) EXISTING_DOMAIN_HOME/bin/stopComponent.sh component_name

• (Windows) EXISTING_DOMAIN_HOME\bin\stopComponent.cmd component_name

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

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

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

• (UNIX) EXISTING_DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url

• (Windows) EXISTING_DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url

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

ステップ3: Oracle Identity Managementコンポーネントの停止

Oracle Identity Managementのコンポーネント(Oracle Internet Directoryなど)を停止します。

• (UNIX) EXISTING_DOMAIN_HOME/bin/stopComponent.sh component_name

• (Windows) EXISTING_DOMAIN_HOME\bin\stopComponent.cmd component_name

ステップ4: 管理サーバーの停止

管理サーバーを停止するときには、WebLogic Server管理コンソールおよびFusion Middleware Controlなど、管理サーバーで実行されているプロセスも停止します。

管理サーバーを停止するには、stopWebLogicスクリプトを使用します。

• (UNIX) EXISTING_DOMAIN_HOME/bin/stopWebLogic.sh

• (Windows) EXISTING_DOMAIN_HOME\bin\stopWebLogic.cmd

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

ステップ5: ノード・マネージャの停止

ノード・マネージャを停止するには、それが実行されているコマンド・シェルを閉じます。

またはnodemanager.propertiesの属性QuitEnabledをtrueに設定した後(デフォルトはfalseです)、WLSTを使用して、ノード・マネージャに接続して停止できます。WebLogic Server WLSTコマンド・リファレンスのstopNodeManagerを参照してください。

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

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

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

• Upgrade Assistantの起動
  Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.3.0)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。
• Upgrade Assistantの使用によるSOAスキーマのアップグレード
  Upgrade Assistantの各画面を通じて、製品スキーマをアップグレードします。
• スキーマのアップグレードの確認
  すべてのアップグレード・ステップを完了したら、schema_version_registryのスキーマ・バージョンが適切に更新されていることをチェックして、アップグレードの成功を検証します。

アップグレード・アシスタントの起動

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

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

ノート:

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

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

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

• アップグレード・アシスタントのパラメータ
  

アップグレード・アシスタントのパラメータ

アップグレード・アシスタントをコマンド・ラインから起動する際に、追加パラメータを指定できます。

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

パラメータ	必須またはオプション	説明
-readiness	準備状況チェックに必要 ノート: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。	実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。 スキーマおよび構成がチェックされます。 -examineパラメータを指定した場合は、このパラメータを使用しないでください。
-threads	オプション	スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。
-response	サイレント・アップグレードまたはサイレント準備状況チェックに必要	GUIモードでの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) NEW_ORACLE_HOME/oracle_common/upgrade/logs NEW_ORACLE_HOME/oracle_common/upgrade/temp (Windows) NEW_ORACLE_HOME/oracle_common/upgrade/logs NEW_ORACLE_HOME/oracle_common/upgrade/temp
-help	オプション	すべてのコマンドライン・オプションを表示します。

アップグレード・アシスタントを使用したSOAスキーマのアップグレード

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

注意:

パージ・スクリプトまたはスケジュールされたデータベース・ジョブの実行中は、アップグレード・アシスタントを起動しないでください。

パージまたはアップグレードが完了するまで待ってから、アップグレード・プロセスを開始してください。アップグレード・アシスタントを使用してスキーマをアップグレードするときに、パージ・スクリプトまたはインスタンスのアップグレード・ジョブを実行していると、アップグレードは失敗します。

アップグレード・アシスタントを起動する必要がある場合は、「バックグラウンド制御ジョブの有効化と無効化(オプション6)」で説明しているように、パージを停止してスケジュールされたジョブを無効にしてください。

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

1. 「ようこそ」画面で、Upgrade Assistantの概要、および重要なアップグレード前作業に関する情報を確認します。「次へ」をクリックします。

   ノート:

   Upgrade Assistantの画面の詳細は、その画面上のヘルプをクリックしてください。
2. 「選択したスキーマ」画面で、実行するスキーマ・アップグレード操作を選択します。
   • 「ドメインで使用されるすべてのスキーマ」を使用すると、Upgrade Assistantは、ドメイン内でアップグレードに対応可能な「ドメイン・ディレクトリ」フィールドで指定されたスキーマを持つコンポーネントをすべて検出して選択します。これは、ドメイン支援のスキーマ・アップグレードとも呼ばれています。さらに、Upgrade Assistantはスキーマの入力画面に接続情報を事前に移入します。

     ノート:

     すべての必要なスキーマがアップグレードに含まれていることを確認するためにほとんどのアップグレードに「ドメインで使用されるすべてのスキーマ」を選択することをお薦めします。
   • 「個別に選択されたスキーマ」: ドメインで使用されるスキーマをすべてアップグレードするのではなく、アップグレードするスキーマを個別に選択する場合のオプションです。

     注意:

     12c (12.2.1.3.0)コンポーネントをサポートするために使用されるスキーマのみをアップグレードしてください。Oracle Fusion Middleware 12c (12.2.1.3.0)に含まれないコンポーネントをサポートするために現在使用されているスキーマは、アップグレードしないでください。

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

3. 「個別に選択されたスキーマ」を選択した場合: 「使用可能なコンポーネント」画面で、スキーマをアップグレードするコンポーネントを選択します。コンポーネントを選択すると、スキーマとすべての依存関係が自動的に選択されます。
4. 「使用可能なコンポーネント」画面でOracle Platform Security ServicesまたはOracle Audit Servicesが選択されている場合は、「ドメイン・ディレクトリ」画面が表示されます。既存のWebLogicドメイン・ディレクトリの絶対パスを入力するか、「参照」をクリックして、アップグレードするドメイン・ディレクトリに移動して選択します
5. 「前提条件」画面で、すべてのチェック・ボックスを選択することで、前提条件を満たしていることを認めます。「次へ」をクリックします。

   ノート:

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

   要素	説明
   データベース・タイプ	アップグレード用に選択されたデータベース・タイプは、RCUが最初にスキーマを作成したときに選択されたデータベース・タイプと同一である必要があります。 データベース・タイプとしてOracle Edition-Based Redefinition (EBR)を選択した場合は、アップグレードしているスキーマも、EBRデータベース・タイプとしてRCUによって作成されている必要があります。特に、アップグレード・アシスタントでは、スキーマのデータベース・タイプが別のタイプに変換されることはありません。 オプションは、次のとおりです。 Oracle Database Microsoft SQL Server IDM DB2 MySQL Java DB エディション・ベースの再定義に対応したOracle Database
   エディション名	データベース・タイプ「エディション・ベースの再定義に対応したOracle Database」(EBRデータベース)の場合、「エディション名」要素フィールドに既存のエディションの名前を入力する必要があります。データベース・スキーマのアップグレードは、選択したエディションで行われます。
   データベース接続文字列	データベースの場所を入力します。 たとえば、Oracle Databaseを選択する場合は、次のURL形式を使用できます。 host:port/db_service_name Microsoft SQL ServerまたはIBM DB2データベースを使用している場合は、ドロップダウン・メニューからデータベース・タイプを選択し、各データベース・タイプに対して使用できる構文の例を確認してください。
   DBAユーザー名	データベースへの接続に使用するデータベース・ユーザー名を入力します。 Oracle Databaseユーザーのみ: SSL認証が使用されている場合、「DBAユーザー名」フィールドはオプションになることがあります。DBAユーザー名を指定すると、その情報がデータベース認証中に使用されます。 Oracle Databaseユーザーで、SYSまたはSYSDBAとして操作を実行していない場合、アップグレード・アシスタントのユーザーはFMWユーザー・アカウントで付与されるすべての権限を持っている必要があります。 sysdba以外のユーザーを作成してアップグレード・アシスタントを実行する方法の詳細は、コンポーネント固有のアップグレード・ドキュメントを参照してください。
   DBAパスワード	指定したDBAデータベース・ユーザーに対応するパスワードを入力します。 Oracle Databaseユーザーのみ: SSL認証が使用されている場合、「DBAパスワード」フィールドはオプションになることがあります。DBAユーザー名およびパスワードを指定すると、その情報がデータベース認証中に使用されます。
   スキーマ・ユーザー名	「スキーマ・ユーザー名」ドロップダウン・メニューからアップグレードするスキーマを選択し、スキーマのパスワードを入力します。アップグレードするスキーマに対して正しいスキーマ接頭辞を使用してください。 前の12cリリースからのアップグレード: リリース12.1.2.0.0以降、UCSUMSスキーマのスキーマ名は変更されました。新しい名前は、アップグレードの開始点に応じて、prefix_ORASDPMまたはprefix_UMSのどちらかとなります。Upgrade Assistantが自動的に使用可能なスキーマを認識せず、ドロップダウン・リストに表示できない場合、テキスト・フィールドに名前を手動で入力する必要があります。 11gから12cへのアップグレードのみ: UCSUMSスキーマは、自動移入されません。ユーザーとしてprefix_ORASDPMを入力します。アップグレード環境ではスキーマ名としてprefix_ORASDPMが使用されますが、12c環境ではこれは_UMSと見なされます。
   スキーマ・パスワード	特定のスキーマ・ユーザー名に関連付けられているパスワードを入力します。
7. 「スキーマの作成」画面で、Upgrade Assistantが欠落スキーマを作成するかどうかを指定します。デフォルトでは、指定されたドメインの欠落スキーマの作成オプションが有効です。アップグレード・アシスタントは、指定されたデータベース接続詳細とスキーマ所有者名を使用して、ドメインの欠落スキーマの作成を試行します。Upgrade Assistantは、デフォルトの表領域設定を使用してスキーマを作成します。
   同じパスワードをすべてのスキーマに使用する場合、「すべてのスキーマに同じパスワードを使用」を選択します。表のパスワードを入力して確認します。パスワードを指定する必要があるのは1回のみです。

   ノート:

   スキーマにカスタマイズされたオプションが必要な場合、Upgrade Assistantによるスキーマの作成を許可しないでください。デフォルトのリポジトリ作成ユーティリティ(RCU)設定を使用して、スキーマが作成されます。たとえば、スキーマに追加の表領域が必要な場合、RCUを使用してスキーマを作成する必要があります。

   Upgrade Assistantでこれらのスキーマを作成しない場合、指定されたドメインの欠落スキーマの作成オプションを選択解除し、「次」をクリックします。リポジトリ作成ユーティリティを使用してスキーマを作成する必要があります。

8. 指定されたドメインの欠落スキーマの作成オプションを選択した場合、スキーマのデフォルト値の作成画面が表示されます。各コンポーネント・スキーマと補助スキーマのデフォルトのデータファイル・サイズがリストされます。表領域データファイルのサイズを変更するか、デフォルトのスキーマ設定にその他の変更を加える必要がある場合は、リポジトリ作成ユーティリティを使用してスキーマを作成します。アップグレード・アシスタントから表領域設定を変更することはできません。
9. 「調査」画面で、各スキーマを調査したUpgrade Assistantのステータスを確認して、スキーマのアップグレードの準備が整っていることを検証します。ステータスが「調査が終了しました。」の場合は、「次」をクリックします。
   調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、共通するアップグレード・エラーの解決に関する情報を『Oracle Fusion Middleware Upgrade Assistantによるアップグレード』のアップグレードのトラブルシューティングに関する項で参照します。

   ノート:

   • 調査フェーズの間に、アップグレードを続行せずに検出された問題を解決した場合は、バックアップからリストアすることなしに、アップグレード・アシスタントを再起動できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックして続行した場合は、Upgrade Assistantを再度開始する前に、バックアップからアップグレード前の環境をリストアする必要があります。

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

10. 「アップグレード・サマリー」画面で、アップグレードまたは作成、あるいはその両方が行われるスキーマのサマリーを確認します。
    アップグレード対象の各スキーマについて、正しいソース・バージョンとターゲット・バージョンがリストされていることを確認します。
    これらのオプションをレスポンス・ファイルに保存して、後で再度レスポンス(またはサイレント)モードでUpgrade Assistantを実行する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を提供します。サイレント・アップグレードでは、Upgrade Assistantとまったく同じ機能が実行されますが、データを手動で再入力する必要はありません。
    「次」をクリックします
11. 「アップグレードの進行状況」画面で、アップグレードのステータスを監視します。

    注意:

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

    ノート:

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

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

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

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

    ノート:

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

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

すべてのアップグレード・ステップが完了したら、schema_version_registry内のスキーマ・バージョンが正しく更新されていることを確認することで、アップグレードの成功を確認します。

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

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

問合せ結果について:

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

  ノート:

  ただし、すべてのスキーマ・バージョンが更新されるわけではありません。一部のスキーマは、このリリースにアップグレードする必要がなく、アップグレード前のバージョン番号のままになります。

• STATUSフィールドは、スキーマのパッチ適用処理中はUPGRADINGまたはUPGRADEDのどちらかになり、その処理が完了するとVALIDになります。

• ステータスが「INVALID」と表示された場合は、ステータスの更新が失敗しています。ログ・ファイルを調べて、失敗した理由を判定する必要があります。

• IAU_APPENDおよびIAU_VIEWERに所有されているシノニム・オブジェクトは、INVALIDと表示されますが、失敗を示しているわけではありません。

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

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

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

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

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

• ドメイン・バージョン

ノート:

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

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

• アップグレード・プロセスの間の非動的クラスタ・ドメインから動的クラスタ・ドメインへの変換はサポートされていません。

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

• アップグレードするインストールでOracle Access Management (OAM)が使用されない場合は、2つのファイルを編集して、再構成ウィザードが、存在しないOAMインフラストラクチャ・スキーマの更新(アップグレードが失敗する)を試みないようにする必要があります。

  $DOMAIN/init-info/domain-info.xmlに次の例のような行をコメント・アウトします。

  <!--extention-template-ref name="Oracle Identity Navigator" 
    version="11.1.1.3.0" 
    location="/u01/app/oracle/product/fmw/iam111130/common/templates/applications/yourcomany.oinav_11.1.1.3.0_template.jar" 
    symbol=""/-->
  
  <!--install-comp-ref name="oracle.idm.oinav" version="11.1.1.3.0" 
    symbol="yourcompany.idm.oinav_11.1.1.3.0_iam111130_ORACLE_HOME" 
    product_home="/u01/app/oracle/product/fmw/iam111130"/-->

  また、同様に、$DOMAIN/config/config.xmlに次の例のような行をコメント・アウトします。

  <!--app-deployment> 
    <name>oinav#11.1.1.3.0</name>
    <target>AdminServer</target>
    <module-type>ear</module-type>
  
    <source-path>/u01/app/oracle/product/fmw/iam111130/oinav/modules/oinav.ear_11.1.1.3.0/oinav.ear</source-path>
    <deployment-order>500</deployment-order>
    <security-dd-model>DDOnly</security-dd-model>
    <staging-mode>nostage</staging-mode>
  </app-deployment-->
  

具体的には、ドメインを再構成すると、次のようになります。

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

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

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

  変更した起動スクリプトを保持する必要がある場合は、再構成ウィザードを開始する前にそれらをバックアップするようにしてください。

ノート:

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

再構成ウィザードを使用して既存のドメインを変更するには、次の説明に従ってください。Oracle WebLogic ServerのアップグレードのWebLogicドメインの再構成を参照してください。

• ドメインのバックアップ
  
• 再構成ウィザードの起動
  
• 再構成ウィザードを使用したSOAドメインの再構成
  Upgrade Assistantを実行する前に、再構成ウィザードを使用して、まず既存のドメインを再構成する必要があります。

ドメインのバックアップ

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

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

1. コンテンツを保持するには、ソース・ドメインを別の場所にコピーします。
   (Windows) copy C:\domains\mydomain to C:\domains\mydomain_backup。
   (UNIX) cp mydomain /domains/mydomain_backup
2. 各リモート管理対象サーバー上でドメインを更新する前に、各リモート・マシン上のドメイン・ディレクトリのバックアップ・コピーを作成します。
3. ドメインのバックアップしたバージョンが完全であることを確認します。

ドメインの再構成がなんらかの理由で失敗した場合は、すべてのファイルおよびディレクトリをバックアップ・ディレクトリから元のドメイン・ディレクトリにコピーして、ドメインを再構成前の元の状態に完全に戻す必要があります。

再構成ウィザードの起動

ノート:

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

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

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

   ALTER DATABASE DEFAULT EDITION = edition_name;

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

4. oracle_common/common/binディレクトリに移動します。
   • (UNIX) NEW_ORACLE_HOME/oracle_common/common/bin
   • (Windows) NEW_ORACLE_HOME\oracle_common\commom\bin
5. 再構成ウィザードを次のロギング・オプションを指定して起動します。
   • (UNIX) ./reconfig.sh -log=log_file -log_priority=ALL
   • (Windows) reconfig.cmd -log=log_file -log_priority=ALL

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

   パラメータ-log_priority=ALLを指定すると、ログが詳細モードで記録されます。

   ノート:

   このコマンドを実行すると、デフォルトのキャッシュ・ディレクトリが無効であることを示す次のエラー・メッセージが表示される場合があります。

   *sys-package-mgr*: can't create package cache dir
   

   環境変数CONFIG_JVM_ARGSを設定することでキャッシュ・ディレクトリを変更できます。たとえば:

   CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

再構成ウィザードを使用したSOAドメインの再構成

Upgrade Assistantを実行する前に、再構成ウィザードを使用して、まず既存のドメインを再構成する必要があります。

ノート:

ソースがクラスタ環境である場合は、再構成ウィザードをプライマリ・ノードでのみ実行します。圧縮/解凍ユーティリティを使用して、ドメイン内の他のクラスタ・メンバーに変更を適用します。

ドメインを再構成するには:

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データ」を選択してServer Table (_STB)スキーマに接続します。
   RCUサービス表(_STB)スキーマ資格証明を使用してデータベース接続の詳細を入力し、「RCU構成の取得」をクリックします。
   再構成ウィザードは、この接続を使用して、ドメインのコンポーネントに必要なデータソースを自動的に構成します。

   ノート:

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

   ノート:

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

   ノート:

   11gからアップグレードし、データベースに_OPSSまたは_IAU 11gデータベース・スキーマが含まれる場合、それらのスキーマに手動でデータベース接続詳細を入力する必要があります。これらのスキーマは11gで不要であり、手動で作成する必要がありました。ユーザーは任意の名前をこれらのスキーマに割り当てることができるため、再構成ウィザードでは認識されません。_IAUの接続情報を指定する場合、IAU_APPENDユーザー情報を使用します。
5. 「JDBCコンポーネント・スキーマ」画面で、各コンポーネント・スキーマのDBMS/サービスおよびホスト名が正しいことを確認し、「次へ」をクリックします。
6. 「JDBCコンポーネント・スキーマ・テスト」画面で、すべてのコンポーネント・スキーマを選択して「選択された接続のテスト」をクリックし、各スキーマの接続をテストします。テストの結果は、「ステータス」列に表示されます。
   チェックが完了したら、「次へ」をクリックします。
7. 「拡張構成」画面で、拡張構成を実行するすべてのカテゴリを選択できます。選択したカテゴリごとに、詳細構成を行うことができる適切な構成画面が表示されます。

   ノート:

   「拡張構成」画面に表示されるオプション・カテゴリは、ドメインのために選択したテンプレートで定義されているリソースによって異なります。一般的な一部のカテゴリを次に示します。
   「拡張構成」>「管理対象サーバー」:

   ドメインの各管理対象サーバーに対し、リスニング・アドレスの実際のホスト名を指定する必要があります。

   デフォルトのlocalhostまたは All Local Addressesオプションは使用しないでください。

   実際のホスト名を、hostname.yourcompany.comのように指定する必要があります

   「管理対象サーバー」>サーバー・グループのターゲット指定

   ノート:

   • 11gから12cリリースにアップグレードする場合は、OSB管理対象サーバーをターゲット指定するために次のサーバー・グループを選択してください。
     • OSB-MGD-SVRS-ONLY – Oracle Service BusサービスとOracle Web Services Manager (OWSM)サービスを別々の管理対象サーバーにターゲット指定する場合は、このサーバー・グループを選択します。
     • OSB-MGD-SVRS - OSBサービスとOWSMサービスを同じ管理対象サーバーにターゲット指定する場合は、このサーバー・グループを選択します。このオプションは、CloudSDKをOSB管理対象サーバーにターゲット指定しません。必要に応じて、CloudSDKを手動でターゲット指定したり、さらにOSB-MGD-SVRS-COMBINEDサーバー・グループを選択したり、OSB管理対象サーバーをターゲット指定することもできます。
   • 以前の12cリリース(たとえば12.1.3)で作成されたドメインをアップグレードする場合、アップグレードのドメイン再構成フェーズで、サーバーを正しいサーバー・グループにターゲット指定する必要があります。これらのサーバーのターゲット指定に失敗すると、アップグレードの失敗や不要なダウンタイムの発生につながることがあります。

   1. 「管理対象サーバー」画面で「サーバー・グループ」ドロップダウン・メニューから正しいグループ名を選択して、各サーバーを正しいサーバー・グループにターゲット指定します。
      
      図recon_managed.pngの説明
      

   2. 各サーバーが正しいサーバー・グループにターゲット指定され、「未指定」と表示されていないことを確認します。

      コンポーネントとサーバー	サーバー・グループ
      SOA (soa_server1)	SOA-MGD-SVRS-ONLY
      Oracle Service Bus - OSB (osb_server1)	OSB-MGD-SVRS-ONLY
      Business Activity Monitoring - BAM (bam_server1)	BAM-MGD-SVRS-ONLY
      Managed File Transfer - MFT (mft_server1)	MFT-MGD-SVRS-ONLY

   「拡張構成」>「サーバーのマシンへの割当」

   アップグレード・プロセスの一部としてサーバーを作成した場合は、「サーバー」リスト・ボックスでサーバー名を選択して、適切なノード・マネージャ・マシンにターゲット設定します。

   そうでない場合は、ドメインのアップグレード時または再構成時にこの画面で操作は必要ありません。

   「拡張構成」>「サーバーのクラスタへの割当」

   クラスタのアップグレードのみ: クラスタをアップグレードする場合は、この画面を使用して管理対象サーバーをクラスタに割り当てます。

   「サーバー」リスト・ボックスには管理対象サーバーのみが表示されます。管理サーバーは、クラスタに割り当てることができないので、リストに表示されません。

   ノート:

   OWSMPMがそれ固有のクラスタ内にあり、SOAまたはOSBクラスタの一部ではない場合:

   • SOA-MGD-SVRS-ONLYユーザー拡張可能サーバー・グループのみをSOAクラスタのターゲットに指定します

   • OSB-MGD-SVRS-ONLYのみをOSBクラスタのターゲットに指定します
   • WSMPM-MAN-SVERサーバー・グループをOWSMのターゲットに指定します
   • 12.1.3.0を12.2.1.3.0,にアップグレードする場合、BAM-MGD-SVRS-ONLYをBAMクラスタのターゲットに指定する必要もあります。
8. 「構成のサマリー」画面で、ドメインの詳細な構成設定を確認してから続行します。
   「表示」ドロップダウン・リストからフィルタ・オプションを選択すると、右側のパネルに表示される項目を制限できます。
   構成を変更するには、「戻る」をクリックして適切な画面に戻ります。ドメインを再構成するには、「再構成」をクリックします。

   ノート:

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

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

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

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

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

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

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

アップグレード・アシスタントの起動

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

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

ノート:

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

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

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

• アップグレード・アシスタントのパラメータ
  

アップグレード・アシスタントのパラメータ

アップグレード・アシスタントをコマンド・ラインから起動する際に、追加パラメータを指定できます。

表6-4 Upgrade Assistantコマンドライン・パラメータ

パラメータ	必須またはオプション	説明
-readiness	準備状況チェックに必要 ノート: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。	実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。 スキーマおよび構成がチェックされます。 -examineパラメータを指定した場合は、このパラメータを使用しないでください。
-threads	オプション	スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。
-response	サイレント・アップグレードまたはサイレント準備状況チェックに必要	GUIモードでの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) NEW_ORACLE_HOME/oracle_common/upgrade/logs NEW_ORACLE_HOME/oracle_common/upgrade/temp (Windows) NEW_ORACLE_HOME/oracle_common/upgrade/logs NEW_ORACLE_HOME/oracle_common/upgrade/temp
-help	オプション	すべてのコマンドライン・オプションを表示します。

Upgrade Assistantの使用によるドメイン・コンポーネントのアップグレード

Upgrade Assistantで複数の画面をナビゲートし、WebLogicドメイン内のコンポーネント構成をアップグレードします。

再構成ウィザードを実行してWebLogicドメインを12c (12.2.1.3.0)に再構成した後、Upgrade Assistantを実行して、更新したドメイン構成と一致するようドメイン・コンポーネント構成をアップグレードします。

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

1. 「ようこそ」画面で、Upgrade Assistantの概要、および重要なアップグレード前作業に関する情報を確認します。「次へ」をクリックします。

   ノート:

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

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

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

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

3. アップグレード前の環境に複数のWebLogicドメインがあるが、Oracle Web Services Manager (OWSM)ポリシー・マネージャが1つのドメインのみにあり、OWSMエージェントが他のドメインにある場合: OWSMポリシー・マネージャ画面で、Oracle Web Services Manager (OWSM)ポリシー・マネージャがデプロイされているWebLogic管理サーバー・ドメインの資格証明を提供します。
4. 「コンポーネント・リスト」画面で、構成をアップグレードするすべてのコンポーネントを含んだリストを確認し、「次」をクリックします。
   アップグレード対象のコンポーネントが表示されていない場合は、「戻る」をクリックして前の画面に戻り、別のドメインを指定します。
5. 「前提条件」画面で、すべてのチェック・ボックスを選択することで、前提条件を満たしていることを認めます。「次へ」をクリックします。

   ノート:

   アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。
6. ユーザー・メッセージング・サービス(UMS)構成ファイルをホストするリモート管理対象サーバーがある場合: UMS構成画面で、Upgrade Assistantが構成ファイルにアクセスできるよう、これらのサーバーへの資格証明を提供します。

   ノート:

   Upgrade AssistantでUMS構成ファイルが見つからない場合は、それらのファイルを手動でコピーする必要があります。ユーザー・メッセージング・サービス(UMS)構成ファイルのコピー中のエラーを参照してください。
7. Upgrade Assistantで各コンポーネントを調査したら、「調査」画面で、Upgrade Assistantのステータスを確認し、コンポーネント構成のアップグレード準備が整っていることを確かめます。ステータスが「調査が終了しました。」の場合は、「次」をクリックします。
   調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、共通するアップグレード・エラーの解決に関する情報を『Oracle Fusion Middleware Upgrade Assistantによるアップグレード』のアップグレードのトラブルシューティングに関する項で参照します。

   ノート:

   • 調査フェーズの間に、アップグレードを続行せずに検出された問題を解決した場合は、バックアップからリストアすることなしに、アップグレード・アシスタントを再起動できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックして続行した場合は、Upgrade Assistantを再度開始する前に、バックアップからアップグレード前の環境をリストアする必要があります。

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

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

   注意:

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

   ノート:

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

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

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

    ノート:

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