Oracle® Fusion Middleware

Oracle Fusion Middleware Infrastructureへのアップグレード

12c (12.2.1)

E69933-01(原本部品番号:E55681–02)

2015年12月

Oracle Fusion Middleware Infrastructure 12cへのアップグレードを希望するOracle Fusion Middleware管理者向けのドキュメント。

Oracle Fusion Middleware Oracle Fusion Middleware Infrastructureへのアップグレード, 12c (12.2.1)

E69933-01

Copyright © 2014, 2015, Oracle and/or its affiliatesAll rights reserved

原本著者: Lisa Jamen

協力者: Bill Norcott、Michael Rubino、Renga Rengarajan、Robert Donat、Rubis Chowallur、Sitaraman Swaminathan。

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- 関連ドキュメント

- 表記規則

このガイドで説明する新機能

- 12c (12.2.1)の新機能と変更された機能

- このガイドのその他の変更点

1 Oracle Fusion Middleware Infrastructureアップグレードの準備

- 1.1 Oracle Fusion Middleware Infrastructureアップグレードの開始点についての理解

- 1.1.1 Oracle Fusion Middleware Infrastructure 12cについて

- 1.1.2 Application Developer 11gとInfrastructure 12cの重要な違い

- 1.1.2.1 Infrastructure 12cにはOracle WebLogic Serverが含まれる

- 1.1.2.2 Infrastructure 12cは特定のデータベース・スキーマを必要とする

- 1.1.2.3 OIDベースのポリシー・ストアの使用

- 1.1.2.4 Infrastructure 12cドメインにOracle HTTP Serverを含めることができる

- 1.2 セキュリティ・ストアのアップグレード

- 1.3 Infrastructureにおける標準的なアップグレード・トポロジの理解

- 1.3.1 Fusion Middleware Infrastructureの標準アップグレード・トポロジ

- 1.3.2 Oracle HTTP Serverを含むFusion Middleware Infrastructureの標準アップグレード・トポロジ

- 1.4 Oracle Fusion Middleware 12cの追加新機能の理解

- 1.5 Oracle Fusion Middleware Infrastructureへのアップグレードのフロー・チャートおよびタスク・ロードマップ

- 1.5.1 Infrastructure標準アップグレード・トポロジのアップグレードのフロー・チャート

- 1.5.2 Infrastructure標準アップグレード・トポロジのアップグレードのタスク・ロードマップ

- 1.6 Oracle HTTP Serverのアップグレードについて

- 1.7 Oracle JDeveloper 12cを使用したカスタム・アプリケーションのアップグレード

2 アップグレード前チェックリスト

- 2.1 完全なバックアップの作成(必須)

- 2.2 本番環境のクローニング(推奨)

- 2.3 動作保証およびシステム要件の確認

- 2.3.1 環境が動作保証要件を満たしていることの確認

- 2.3.2 システム要件と仕様の確認

- 2.3.3 Oracle Fusion Middlewareをホストしているデータベースがでサポートされていることの確認。

- 2.3.4 このリリースのOracle Fusion MiddlewareでJDKが動作保証されていることの確認。

- 2.4 32ビットから64ビット・オペレーティング・システムへの移行

- 2.4.1 タスク1: アップグレードの64ビット・ソフトウェア要件をサポートするハードウェアを調達する。

- 2.4.2 タスク2: 管理サーバー、管理対象サーバーおよびノード・マネージャも含めて、すべてのプロセスを停止する。

- 2.4.3 タスク3: 32ビット・ホスト・マシンからすべてのファイルをバックアップする。

- 2.4.4 タスク4: 11gのホスト名およびIPアドレスを使用してターゲットの64ビット・マシンを設定する。

- 2.4.5 タスク5: 11gドメインのバックアップを32ビット・ホストから64ビット・ホストにリストアする。

- 2.4.6 タスク6: 12c (12.2.1)製品ディストリビューションをターゲット・マシンにインストールする。

- 2.4.7 タスク7: 標準的なアップグレード手順を使用してターゲットの64ビット環境をアップグレードする。

- 2.5 未使用データのパージ

- 2.6 アップグレード前の必要なスキーマの作成

- 2.7 ファイルベース・ポリシー・ストアのデータベース・ベース・ポリシー・ストアへの再関連付け(必須)

- 2.7.1 11g OPSSとIAUスキーマの作成

- 2.7.2 11gポリシー・ストアのデータベース・ベース・ポリシー・ストアとOPSSスキーマへの再関連付け

- 2.7.3 ポリシー・ストアの再関連付けが正常に行われたことの確認

- 2.8 OIDベースのセキュリティ・ストアのための12c OPSSスキーマの作成

- 2.9 セキュリティ・ストアの最新バージョンへのアップグレード

- 2.10 非SYSDBAユーザーの作成

- 2.11 強化された暗号化(AES 256)の使用

- 2.12 エディション・ベースの再定義のためのサーバー上でのエディションの作成(オプション)

- 2.13 カスタム・ドメイン環境設定のメンテナンス

- 2.14 12c Oracle Fusion Middleware製品ディストリビューションのダウンロードとインストール

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

- 2.16 コンポーネント固有のアップグレード・ドキュメントの検索

3 Infrastructureアップグレードの実行

- 3.1 Infrastructureの必要なアップグレード前タスクの完了

- 3.1.1 カスタムsetDomainEnv設定のメンテナンス(オプション)

- 3.1.2 OIDセキュリティ・ストアでの認証なしSSLモードの使用方法

- 3.1.3 OWSMポリシー・セットからのサーバー・インスタンス・スコープの削除

- 3.1.4 事前定義ドキュメントのクローニングおよびOWSMポリシー・アタッチメントの移行

- 3.2 APPHOSTへのOracle Fusion Middleware Infrastructureのインストール

- 3.3 Oracle HTTP Serverのインストール

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

- 3.5 スキーマ・バージョン・レジストリを使用した既存の11gスキーマの識別

- 3.6 アップグレード前の必要なスキーマの作成

- 3.6.1 作成するスキーマの決定

- 3.6.2 Repository Creation Utilityを使用した必要なスキーマの作成(RCU)

- 3.7 スキーマのアップグレードでのアップグレード・アシスタントの使用

- 3.8 Upgrade Assistantでアップグレードできるスキーマの識別

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

- 3.10 Upgrade Assistantを使用したスキーマのアップグレード

- 3.11 アップグレード・アシスタント画面

- 3.11.1 ようこそ

- 3.11.2 スキーマ

- .3.11.3 ドメインで使用されるすべてのスキーマ

- 3.11.4 ドメインによって使用されるすべての構成

- 3.11.5 スタンドアロン・コンポーネント

- 3.11.6 使用可能なコンポーネント

- 3.11.7 「すべてのスキーマ」のコンポーネント・リスト

- 3.11.8 WebLogic Serverコンポーネント・リスト

- 3.11.9 前提条件

- 3.11.10 エディションベースの再定義(EBR)のデータベースのアップグレード

- 3.11.11 スキーマ資格証明画面

- 3.11.12 インスタンス・ディレクトリ

- 3.11.13 ノード・マネージャ

- 3.11.14 OWSMポリシー・マネージャ

- 3.11.15 ユーザー・メッセージング・サービスの構成

- 3.11.16 調査

- 3.11.17 調査失敗

- 3.11.18 アップグレード・サマリー

- 3.11.19 アップグレードの進行状況

- 3.11.20 アップグレード成功

- 3.11.21 アップグレード失敗

- 3.11.22 アップグレードの取消

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

- 3.12.1 タスク1: 再構成ウィザードの起動

- 3.12.2 タスク2: ドメインの再構成

- 3.13 アップグレード・アシスタントを使用したドメイン・コンポーネント構成のアップグレード

- 3.13.1 タスク1: アップグレード・アシスタントの起動

- 3.13.2 タスク2: コンポーネント構成のアップグレード

- 3.14 Infrastructureアップグレードのトラブルシューティング

- 3.14.1 再構成ウィザード: WebLogic Serverドメインのアップグレード・プロセス

- 3.14.2 アップグレード・アシスタント: 認証失敗 - JSch例外: 認証失敗

- 3.14.3 アップグレード・アシスタント: UMS構成ファイルのコピー

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

4 前のリリースから12cへのアップグレード

- 4.1 アップグレード前に必要なタスクの実行

- 4.2 スキーマのアップグレードでのアップグレード・アシスタントの使用

- 4.3 Upgrade Assistantでアップグレードできるスキーマの識別

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

- 4.5 Upgrade Assistantを使用したスキーマのアップグレード

- 4.6 アップグレード・アシスタント画面

- 4.6.1 ようこそ

- 4.6.2 スキーマ

- 4.6.3 ドメインで使用されるすべてのスキーマ

- 4.6.4 ドメインによって使用されるすべての構成

- 4.6.5 スタンドアロン・コンポーネント

- 4.6.6 使用可能なコンポーネント

- 4.6.7 「すべてのスキーマ」のコンポーネント・リスト

- 4.6.8 WebLogic Serverコンポーネント・リスト

- 4.6.9 前提条件

- 4.6.10 エディションベースの再定義(EBR)のデータベースのアップグレード

- 4.6.11 スキーマ資格証明画面

- 4.6.12 インスタンス・ディレクトリ

- 4.6.13 ノード・マネージャ

- 4.6.14 OWSMポリシー・マネージャ

- 4.6.15 ユーザー・メッセージング・サービスの構成

- 4.6.16 調査

- 4.6.17 調査失敗

- 4.6.18 アップグレード・サマリー

- 4.6.19 アップグレードの進行状況

- 4.6.20 アップグレード成功

- 4.6.21 アップグレード失敗

- 4.6.22 アップグレードの取消

- 4.7 再構成ウィザードを使用した12cドメインのアップグレード

- 4.8 アップグレード・アシスタントを使用した12c構成のアップグレード

5 アップグレード後に実行するタスク

- 5.1 アップグレードの検証チェックリストの使用

- 5.2 サーバーの正しい順序での起動と停止

- 5.2.1 ノード・マネージャの起動

- 5.2.2 管理サーバーの起動

- 5.2.3 Web層(OHS Server)の起動

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

- 5.4 setDomainEnvへのカスタマイズの再適用

- 5.5 Oracle Fusion Middleware 12c監査データ・ストアの構成

- 5.6 古いJava EE Webサービス・アプリケーションのセキュリティ・ステータスのメンテナンス

- 5.7 Oracle Fusion Middleware 12cソフトウェアの管理のためのドキュメント・リソース

- 5.8 Oracle Fusion Middleware 12cでの11gアプリケーション・デプロイメントの使用

- 5.8.1 Oracle Application Development Framework (ADF) 12cについて

- 5.8.2 Oracle JDeveloper 12cについて

- 5.8.2.1 Oracle JDeveloper 12cのインストール

- 5.8.2.2 Oracle JDeveloper 12cを使用したアプリケーションの移行

- 5.8.2.3 Oracle JDeveloper 12cを使用した非同期Webサービスの移行について

はじめに

このガイドを使用して、スキーマ、ドメイン構成およびサポートされている11g Oracle Fusion MiddlewareテクノロジをOracle Fusion Middleware Infrastructure 12c (12.21)にアップグレードします。

また、このガイドには、Oracle Fusion Middleware Infrastructure 12c (12.1.2または12.1.3)から12c (12.2.1)にアップグレードするための情報も記載されています。

対象読者

このドキュメントは、Oracle Fusion Middlewareのインストール、アップグレードおよび管理タスクの知識がある管理者を対象としています。

関連ドキュメント

詳細は、Oracle Fusion Middleware 12c (12.2.1)ドキュメンテーション・セットの次のドキュメントを参照してください。

- Oracle Fusion Middlewareのアップグレードのプランニング

- Oracle Fusion Middleware Infrastructureのインストールと構成

- Oracle WebLogic Serverのアップグレード

- Oracle HTTP Serverのアップグレード

- Oracle Data Integratorのアップグレード

- Oracle SOA SuiteおよびBusiness Process Managementのアップグレード

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

このガイドで説明する新機能

この章では、Oracle Fusion Middlewareのアップグレード・ツールおよびプロセスの新機能と変更された機能を示します。

また、ここではこのマニュアルについての情報と、追加情報へのポインタも提供しています。

12c (12.2.1)での新機能と変更された機能

Oracle Fusion Middleware 12cには、次に示す新しいアップグレード処理とツール、さらには新しい一連のインストーラが導入されており、これらはディストリビューションと呼ばれます。

- リリース12c (12.1.2)より、Oracle Fusion Middleware Infrastructureと呼ばれる新しいディストリビューションがあります。このディストリビューションには、Oracle WebLogic ServerインストーラとApplication Developer 11gインストーラの機能を組み合せたインストーラが含まれています。
そのため、このディストリビューションには、JavaアプリケーションとOracle Application Development Framework (Oracle ADF)アプリケーションのデプロイおよび管理に使用できるOracle WebLogic Serverドメインを作成するために必要なすべてのものが含まれています。

詳細は、Oracle Fusion Middlewareの理解に関するドキュメントを参照してください。

- 12c (12.1.2)より、Oracle Fusion Middlewareデータベース・スキーマのアップグレード、およびコンポーネント構成の12cへのアップグレードには、改善された新しいOracle Fusion Middlewareアップグレード・アシスタントが使用されます。
詳細は、『Oracle Fusion Middlewareのアップグレードのプランニング』を参照してください。

- リリース12c (12.1.2)より、既存の11gドメインから12cへのアップグレードには、新しい再構成ウィザードが使用されます。
詳細は、『Oracle WebLogic Serverのアップグレード』を参照してください。

このガイドのその他の変更点

リリース12c (12.1.2)より、Oracle Fusion Middlewareドキュメント・ライブラリに新しいマニュアルが追加されます。ただし、以前、Oracle Fusion Middleware 11gバージョンのOracle Fusion Middleware SOA、WebCenterおよびADFアップグレード・ガイドに含まれていた、Oracle ADF用の内容と似た情報が含まれています。

Oracle Fusion Middleware 12cでは、JavaおよびOracle ADFカスタム・アプリケーションのデプロイメントと管理のためにApplication Developer 11g環境をインストールして構成したOracle Fusion Middleware 11gユーザー向けのアップグレード処理について説明した、別のガイドが必要でした。

1 Oracle Fusion Middleware Infrastructureアップグレードの準備

この項のトピックでは、アップグレードの準備で実行する必要がある手順の、高度な概要について説明します。

この章の内容は次のとおりです。

1.1 Oracle Fusion Middleware Infrastructureアップグレードの開始点についての理解

サポートされている次の開始点から、このバージョンのOracle Fusion Middleware Infrastructureにアップグレードできます。

- Oracle Fusion Middleware Application Developer 11g (11.1.1.6、11.1.1.7、11.1.1.8、11.1.1.9)

- Oracle Fusion Middleware Infrastructure 12c (12.1.2と12.1.3)。

このガイドのアップグレード手順では、既存のApplication Server 11gドメインおよびそのドメインのOracle Fusion Middlewareコンポーネント構成をOracle Fusion Middleware Infrastructure 12.2.1にアップグレードする方法を重点的に説明します。

注意:

既存のApplication Developer 11gドメインに関連付けてOracle HTTP Serverインスタンスをアップグレードしている場合、スタンドアロンOracle HTTP Serverのアップグレードの手順の詳細は、「Oracle HTTP Serverのアップグレードについて」を参照してください。

詳細は、以下のトピックを参照してください。

1.1.1 Oracle Fusion Middleware Infrastructure 12cについて

Oracle Fusion Middleware 12c (12.2.1)リリースの一部として使用可能なOracle Fusion Middleware Infrastructureディストリビューションは、11gのOracle WebLogic ServerおよびApplication Developerインストーラで用意されているものと同様の、一連のテクノロジおよびコンポーネントを備えています。

Oracle Fusion Middleware Infrastructureの詳細は、『相互運用性および互換性の理解』のOracle Application Server Infrastructure 12cに関する項を参照してください。

1.1.2 Application Developer 11gとInfrastructure 12cの重要な違い

Oracle Fusion Middleware Infrastructure 12cは11g Application Developerインストールと似ていますが、次の違いがあります。

- Infrastructure 12cにはOracle WebLogic Serverが含まれる

- Infrastructure 12cは特定のデータベース・スキーマを必要とする

- Infrastructure 12cドメインにOracle HTTP Serverを含めることができる

1.1.2.1 Infrastructure 12cにはOracle WebLogic Serverが含まれる

Application Developer 11gインストールには個別の2つのインストールが必要でした(Oracle WebLogic Serverと、その後、Oracle JRFライブラリとコンポーネントを追加するためのApplication Developer)。Oracle Fusion Middleware 12cでは、フレッシュ・インストールにはOracle WebLogic Serverと必要なJava Required Filesテクノロジの両方が含まれるOracle Fusion Middleware Infrastructureディストリビューションのみが必要です。

アップグレード手順では、新しいOracle Fusion Middleware 12cドメインの構成は必要ありません。かわりに、再構成ウィザードを使用してドメインをアップグレードします。詳細は、『Oracle Fusion Middlewareのアップグレードのプランニング』の「アップグレードおよび構成ツールの理解と入手」を参照してください。

1.1.2.2 Infrastructure 12cは特定のデータベース・スキーマを必要とする

Application Developer 11gインストールと異なり、Infrastructure 12cインストールでは、サポートされているデータベースで一連の必須スキーマを作成する必要があります。特に、Oracle Fusion Middleware Infrastructure 12cソフトウェアを構成する前に、12cのリポジトリ作成ユーティリティ(RCU)を使用して、必要なデータベース・スキーマを作成する必要があります。

Oracle Fusion Middleware Infrastructure 12cにアップグレードする前に、要件に応じて次のデータベース・スキーマを1つ以上インストールする必要があります。

- サービス表(STB)スキーマ: すべてのOracle Fusion Middleware Infrastructure 12cインストールに必要な新しいスキーマです。このスキーマによって、コンポーネント間ワイヤリングと呼ばれる新しいOracle Fusion Middleware 12c機能が有効になります。詳細は、『Oracle Fusion Middlewareの管理』のコンポーネント間ワイヤリングに関する項を参照してください。12c (12.1.3)へのアップグレード前にこのスキーマをインストールする必要があります。

- OPSSスキーマ: Oracle Platform Security Servicesにデータベースベースのポリシー・ストアを提供します。
表1-1に、11gで使用されるポリシー・ストアの概要およびアップグレード方法を示します。

表1-1 Oracle Fusion Middleware 11gポリシー・ストアのアップグレードの概要

使用しているコンソール

次のアクションを実行

詳細情報

11gのOracle Internet Directory (OID)ベースのポリシー・ストア

- アップグレード前に12cリポジトリ作成ユーティリティ(RCU)を使用して、新しい12c OPSSスキーマを作成します。

- アップグレード・アシスタントで、OPSSスキーマを選択します(アップグレード・アシスタントによってOIDベースのポリシー・ストアがアップグレードされます)。

- ドメインの再構成中に12cスキーマを参照するためにのみ、12c OPSSデータベース・スキーマは必要です。ドメインでは、アップグレード後にOIDベースのポリシー・ストアが引き続き使用されます。

- OIDベースのセキュリティ・ストアのアップグレード

データベースベースのポリシー・ストアおよびOPSSスキーマ

アップグレード・アシスタントを使用して、既存の11g OPSSスキーマを作成します。

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

- IAUスキーマ: OPSS監査機能に使用されます。
11gで監査データ・ストアを使用しているかどうかおよび使用している監査データ・ストアのタイプに応じて、IAU 12c (12.1.3)スキーマの作成が必要な場合があります。詳細については、表1-2 を参照してください。

表1-2 Oracle Fusion Middleware 11g監査ストアのアップグレードの概要

使用しているコンソール

次のアクションを実行

詳細情報

11gのファイルベースの監査ストア

- アップグレードの前に、新しい12c IAUスキーマを作成します。

- アップグレード前の必要なスキーマの作成

データベースベースの監査ストアおよびIAU 11gスキーマ

アップグレード・アシスタントを使用して既存の11g IAUスキーマをアップグレードした後、ドメインの再構成時にアップグレードした11gスキーマを参照します。

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

1.1.2.3 OIDベースのポリシー・ストアの使用

11gでOracle Internet Directory (OID)ベースのポリシー・ストアを使用している場合は、12cリポジトリ作成ユーティリティ(RCU)を使用して、新しい12c OPSSスキーマを作成します。アップグレード・アシスタントで、OPSSスキーマを選択します(アップグレード・アシスタントによってOIDベースのポリシー・ストアがアップグレードされます)。アップグレード前に、OIDベースのポリシー・ストアを再関連付けする必要はありません。

注意:

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

1.1.2.4 Infrastructure 12cドメインにOracle HTTP Serverを含めることができる

Oracle Fusion Middleware 11gでは、通常、Oracle HTTP Serverインスタンスは11g Middlewareホームとは別のOracleインスタンス・ディレクトリに構成されます。Oracle HTTP Server 11gインスタンスは、Oracle Process Manager and Notification Server (OPMN)管理ソフトウェアを使用して管理されます。必要に応じて、Oracle HTTP Server 11gインスタンスをWebLogicドメインと「関連付ける」こともできます。

Oracle Fusion Middleware 12cでは、Oracle Fusion Middleware構成ウィザードを使用して、Oracle HTTP ServerインスタンスをOracle WebLogic Serverドメインの一部として構成できます。Oracle Fusion Middleware Infrastructureドメインの一部として構成した場合、Oracle HTTP Serverインスタンスは、Oracle Enterprise Manager Fusion Middleware ControlとOracle WebLogic Scripting Tool (WLST)を使用して管理できます。Oracle Fusion Middleware 12cでは、ノード・マネージャ・エージェントが、OHSインスタンスへの管理リクエストの委任と実行を担当します。

Oracle Fusion Middleware 12cにおけるOracle HTTP Serverなどのシステム・コンポーネントの構成および管理方法に関する変更点と、Oracle Fusion Middleware 12cにおけるその他の重要な変更点の詳細は、「Oracle Fusion Middleware 12cの追加新機能の理解」を参照してください。

Oracle HTTP Serverのアップグレードの詳細は、Oracle HTTP Serverのアップグレードを参照してください。

1.2 セキュリティ・ストアのアップグレード

OPSSセキュリティ・ストアをアップグレードする前に、アップグレードに失敗した場合にリカバリできるようバックアップを作成してください。セキュリティ・ストアのバックアップの詳細は、「OPSSセキュリティ・ストアのバックアップとリカバリ」を参照してください。

アップグレード手順は、アップグレードされるセキュリティ・ストアのタイプに応じて異なります。アップグレード可能なセキュリティ・ストアは、ファイルベース、OIDベースまたはDBベースです。手順は、元の監査データ・ストアのタイプ(ファイルベースまたはDBベース)に応じて異なります。

- DBベースのセキュリティ・ストアのアップグレード

- OIDベースのセキュリティ・ストアのアップグレード

- 共有セキュリティ・ストアのアップグレード

- ファイルベースのセキュリティ・ストアのアップグレード

1.3 Infrastructureにおける標準的なアップグレード・トポロジの理解

Oracle Fusion Middleware Application Developer 11gソフトウェアを使用して、アプリケーション、組織およびアプリケーション・ユーザーのニーズに応じた様々な本番トポロジを作成できます。

そのため、考えられるすべてのApplication Developer 11gインストールに対して正確なアップグレード手順を示すことは困難です。この問題を解決するために、このアップグレード・ドキュメントでは、2つの一般的なApplication Developer構成をアップグレードする詳細な手順を説明しています。これらの一般的なトポロジを、Oracle Fusion Middleware 12の標準アップグレード・トポロジと呼びます。

このガイドでは、具体的には、Oracle JRFとOracle ADFアプリケーションのデプロイメントをサポートするように構成された2つの管理対象サーバーのクラスタが含まれるドメインを構成するために、Oracle WebLogic ServerとApplication Developer 11gソフトウェアを使用したと想定しています。

実際のトポロジは異なる場合がありますが、ここで説明するトポロジを、他の同様のApplication Developerトポロジをアップグレードする際の参考にしてください。

このガイドでは、2つの特定のアップグレード・トポロジをアップグレードする方法について順を追って説明しています。

- Fusion Middleware Infrastructureの標準アップグレード・トポロジ

- Oracle HTTP Serverを含むFusion Middleware Infrastructureの標準アップグレード・トポロジ

1.3.1 Fusion Middleware Infrastructureの標準アップグレード・トポロジ

図1-1に、Oracle Fusion Middleware 11g Application Developerの標準アップグレード・トポロジと、このガイドのアップグレード手順実行後のOracle Fusion Middleware 12c Infrastructureトポロジを示します。

図1-1 Infrastructureアップグレード・トポロジ

このトポロジ図のすべての要素を表1-3 に示します。

表1-3 Infrastructureの標準アップグレード・トポロジの要素の説明

要素

説明と追加ドキュメントへのリンク

11g Application Developerトポロジ

これは図1-1 の左側のラベルです。これは、Oracle Fusion Middleware 11g Application Developerインストーラを使用して作成された一般的な単一ホスト・トポロジを示します。

これは、2つの管理対象サーバーのクラスタと管理サーバーが含まれる単一ドメインで構成されます。また、スキーマとともにオプションのファイルベースのストアまたはデータベースが存在します。

このドキュメントでは、このトポロジを、Oracle Fusion Middleware 12c Infrastructureディストリビューションを使用して作成した同等のトポロジにアップグレードする方法について順を追って説明します。

12c Infrastructureの標準インストール・トポロジ

これは図の右側のラベルです。これは、Oracle Fusion Middleware 12c Infrastructureディストリビューションを使用して作成された一般的な単一ホスト・トポロジを示します。

Application Developer 11gトポロジと同様に、これも、2つの管理対象サーバーのクラスタと管理サーバーが含まれる単一ドメインで構成されます。

APPHOST

アプリケーション層をホストしているマシンを示す、Oracleドキュメントで使用される標準用語。

DBHOST

データベースをホストしているマシンを示す、Oracleドキュメントで使用される標準用語。

Application Developer 11gではデータベースは任意でしたが、Oracle Fusion Middleware Infrastructure 12ではデータベースが必要であることに注意してください。詳細は、「Infrastructure 12cは特定のデータベース・スキーマを必要とする」を参照してください。

ファイルベースのストア

XMLのファイルベースのセキュリティ・ストア11gでは、ファイルベースのセキュリティ・ストアまたはデータベースベースのセキュリティ・ストアを使用できました。

ただし、12cではファイルベースのストアは非推奨で、サポートされているデータベースでOracle Platform Security Services (OPSS)スキーマを使用する必要があります。再構成ウィザードは、ファイルベースのストアをDBベースのストアに再関連付けするプロセスを自動化します。

スキーマがあるデータベース

リポジトリ作成ユーティリティ(RCU)を使用してOracle Fusion Middlewareスキーマが作成された、サポートされているデータベースを表します。

WebLogicドメイン

論理的に関連するJavaコンポーネントのグループ(ここでは管理サーバー、管理対象サーバーおよびその他の関連するソフトウェアコンポーネント)。

詳細は、Oracle Fusion Middlewareの理解でOracle WebLogic Serverドメインに関する項を参照してください。

管理サーバー

ドメインの構成オブジェクトをメンテナンスし、管理対象サーバーへの構成変更を分散させる、ドメインの中央制御エンティティ。

詳細は、Oracle Fusion Middlewareの理解の管理サーバーの説明に関する項を参照してください。

Enterprise Manager

Oracle Enterprise Manager Fusion Middleware Control。ドメインを管理するために使用する主要ツール。

詳細は、Oracle Fusion Middlewareの理解のOracle Enterprise Manager Fusion Middleware Controlに関する項を参照してください。

クラスタ

同時に稼働し連携する、複数のWebLogic Serverインスタンスの集合。

詳細は、Oracle Fusion Middlewareの理解の管理対象サーバーと管理対象サーバー・クラスタの理解に関する項を参照してください。

マシン

1つまたは複数のWebLogic Serverインスタンス(サーバー)をホストするコンピュータを論理的に表現するもの。マシンは、ノード・マネージャを使用して管理対象サーバーを起動または停止するためにWebLogicの管理対象サーバーとノード・マネージャを論理的に結び付けるものでもあり、管理対象サーバーはマシンに関連付けされている必要があります。

管理対象サーバー

アプリケーション、アプリケーション・コンポーネント、Webサービスおよび関連リソースをホストします。

詳細は、Oracle Fusion Middlewareの理解の管理対象サーバーと管理対象サーバー・クラスタの理解に関する項を参照してください。

Oracle JRF

Oracle JRF (Java Required Files)は、Oracle WebLogic Serverインストールに含まれておらず、Oracleビジネス・アプリケーションおよびアプリケーション・フレームワークに共通の機能を提供するコンポーネントで構成されています。

JRFには、共通の場所にデプロイされる、いくつかの個別に開発されたライブラリおよびアプリケーションが含まれています。Java Required Filesに属すると見なされるコンポーネントには、Oracle Application Development Frameworkの共有ライブラリやODLロギング・ハンドラなどがあります。

インフラストラクチャ

次のものを含むサービスのコレクションを表すOracle Fusion Middleware 12cの用語(Oracle JRFと同様)。

- メタデータ・リポジトリ(MDS)
これにはOracle Application Developer Frameworkなどの、Oracle Fusion Middlewareコンポーネントのメタデータが含まれます。

詳細は、Oracle Fusion Middlewareの理解のメタデータ・リポジトリの概要に関する項を参照してください。

- Oracle Application Developer Framework (ADF)

- Oracle Web Services Manager(OWSM)

Application Developer 11gトポロジは、「Application Developer 11gとInfrastructure 12cの重要な違い」で説明する違いを除き、Oracle Fusion Middleware Infrastructure 12cトポロジと同様です。

1.3.2 Oracle HTTP Serverを含むFusion Middleware Infrastructureの標準アップグレード・トポロジ

図1-2 は、Oracle HTTP Serverを含むOracle Fusion Middleware 11g Application Developerの標準アップグレード・トポロジと、このガイドのアップグレード手順実行後のOracle Fusion Middleware 12c Infrastructureトポロジを示します。

図1-2 Oracle HTTP Serverを含むInfrastructureの標準アップグレード・トポロジ

このトポロジ図の大部分の要素を表1-3 に示します。

追加要素と図1-1 とは異なるものを表1-4 に示します。

表1-4 Oracle HTTP Serverを含むInfrastructureの標準アップグレード・トポロジの要素の説明

要素

説明と追加ドキュメントへのリンク

Oracle HTTP Serverを含む11g Application Developerトポロジ

これは図1-2 の左側のラベルです。これは、Oracle Fusion Middleware 11g Application Developerインストーラを使用して作成された一般的な単一ホスト・トポロジを示します。

これは、2つの管理対象サーバーのクラスタと管理サーバーが含まれる単一ドメインで構成されます。また、スキーマとともにオプションのファイルベースのストアまたはデータベースが存在します。

図1-2 には、11gドメインの一部としてのOracle HTTP Serverインスタンスも示します。

このドキュメントでは、このトポロジを、Oracle Fusion Middleware 12c Infrastructureディストリビューションを使用して作成した同等のトポロジにアップグレードする方法について順を追って説明します。

Oracle HTTP Serverを含む12c Infrastructureの標準インストール・トポロジ

これは図の右側のラベルです。これは、Oracle Fusion Middleware 12c Infrastructureディストリビューションを使用して作成された一般的な単一ホスト・トポロジを示します。

Application Developer 11gトポロジと同様に、これも、2つの管理対象サーバーのクラスタと管理サーバーが含まれる単一ドメインで構成されます。

図1-2 には、12cドメインの一部としてのOracle HTTP Serverインスタンスも示します。

「ドメインに関連付けられた」Oracle HTTP Server

Oracle WebLogic Serverドメインに「関連付ける」ように構成されているOracle HTTP Server 11gインスタンス。Oracle Fusion Middleware 11gでは、Oracle HTTP Serverなどのシステム・コンポーネント・インスタンスは、Oracle Universal Installerベースの構成ウィザードで構成され、Oracle Process Manager and Notification Serverを使用して管理されます。

Oracle HTTP Server

図の左側のOracle HTTP Server 11gインスタンスと異なり、12cトポロジに示すOracle HTTP Server 12cインスタンスは、Oracle Fusion Middleware構成ウィザードを使用してドメインの一部として構成されます。これは、Oracle Enterprise Manager Fusion Middleware Control、Oracle WebLogic Scripting Tool (WLST)およびOracle WebLogic Serverノード・マネージャ・ソフトウェアを使用して管理されます。

Oracle Fusion Middleware 12 Oracle WebLogic ServerドメインでOracle HTTP Serverインスタンスが作成および管理される方法が変更されていることに注意してください。詳細は、「Infrastructure 12cドメインにOracle HTTP Serverを含めることができる」を参照してください。

1.4 Oracle Fusion Middleware 12cの追加新機能の理解

Oracle Fusion Middleware Infrastructure 12cへのアップグレードを開始する前に、Oracle Fusion Middleware 12cで利用可能な新機能と変更点を確認してください。特に、Oracle Fusion Middlewareの理解の次の項を参照してください。

- 12c (12.1.3)の新機能と変更された機能

- 12c (12.1.3)の新しい用語と非推奨用語

- WebLogic Management Frameworkとは

1.5 Oracle Fusion Middleware Infrastructureへのアップグレードのフロー・チャートおよびタスク・ロードマップ

次の項では、Oracle Fusion Middlewareの標準アップグレード・トポロジをアップグレードする高度な手順の概要について説明します。

- Infrastructure標準アップグレード・トポロジのアップグレードのフロー・チャート

- Infrastructure標準アップグレード・トポロジのアップグレードのタスク・ロードマップ

1.5.1 Infrastructure標準アップグレード・トポロジのアップグレードのフロー・チャート

図1-3 に、標準Infrastructureアップグレードに関連する手順の概要を示します。

図1-3 Infrastructureのアップグレード手順のフロー・チャート

1.5.2 Infrastructure標準アップグレード・トポロジのアップグレードのタスク・ロードマップ

表1-5に、Fusion Middleware Infrastructure 12cにアップグレードするために実行する必要があるタスクを示します。

表1-5 Oracle Fusion Middleware Infrastructureアップグレード・ロードマップ

タスク

説明

詳細情報

新しい12cの概念を確認し、一般的なアップグレード・タスクを実行します。

アップグレードを計画する前に、12cの概念と一般的なアップグレード・タスクを確認する必要があります。

Oracle Fusion Middlewareのアップグレードのプランニング

Oracle Fusion Middleware Infrastructureアップグレードの開始点についての理解

Infrastructureにおける標準的なアップグレード・トポロジの理解。

既存の11g環境の完全バックアップを実行します。

アップグレード処理によって既存のドメイン・ディレクトリが再構成されるため、バックアップは重要です。

Infrastructureの必要なアップグレード前タスクの完了

新しいOracleホームにInfrastructure 12.2.1をインストールします。

Oracle Fusion Middleware Application Developer 11gをインストールしたホストの新しいOracleホームに、Oracle Fusion Middleware Infrastructure 12cをインストールします。

ドメインに関連付けられたOracle HTTP Serverインスタンスが11g環境に含まれる場合、Infrastructureと同じOracleホームにOracle HTTP Server 12cをインストールします。

APPHOSTへのOracle Fusion Middleware Infrastructureのインストール。

Oracle HTTP Serverのインストール

11g環境を停止します。

管理サーバーとすべての管理対象サーバーを停止します。

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

アップグレード・アシスタントを実行してデータベース・スキーマをアップグレードします。

アップグレード・アシスタントを実行して、既存の11gスキーマを12cにアップグレードします。

リポジトリ作成ユーティリティ(RCU)を実行して12cスキーマを作成します。(11gから12cへのアップグレードのみ。)

Oracle Fusion Middleware 11gと異なり、サポートされているデータベースに必要なスキーマをインストールしないと、Oracle Fusion Middleware 12cドメインを構成することはできません。

アップグレード前の必要なスキーマの作成。

11gドメインを再構成するために再構成ウィザードを実行し、必要に応じてノード・マネージャを実行します。

11gスキーマのアップグレード後に、再構成ウィザードを実行して、既存の11gドメインを再構成し、ノード・マネージャを実行する必要があります。

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

アップグレード・アシスタントを実行してドメイン構成をアップグレードします。

アップグレード・アシスタントを使用して、WebLogicコンポーネント構成をアップグレードします。

必要なアップグレード後のタスクを実行します。

アップグレードとデプロイ済のアプリケーションの検証など、必要なアップグレード後のタスクを実行します。

アップグレード後に実行するタスク

1.6 Oracle HTTP Serverのアップグレードについて

このガイドでは、Oracle WebLogic Serverドメインに「関連付けられる」ように構成されていたOracle HTTP Server 11gインスタンスをアップグレードする方法について説明します。このアップグレードは、Oracle HTTP Serverが関連付けられているドメインのアップグレード時に実行されます。

スタンドアロンOracle HTTP Serverインスタンス(11gドメインに関連付けられていないもの)をアップグレードするには、『Oracle HTTP Serverのアップグレード』を参照してください。

1.7 Oracle JDeveloper 12cを使用したカスタム・アプリケーションのアップグレード

カスタム・アプリケーションをOracle Fusion Middleware Application Developer 11gドメインにデプロイしていた場合、アップグレード手順の実行後、アプリケーションのデプロイメントはOracle Fusion Middleware 11gでの場合と同様に機能します。

ただし、新しいOracle Application Development Framework (Oracle ADF) 12cの機能を利用する場合は、Oracle JDeveloper 12cをダウンロードしてインストールします。詳細は、『Oracle JDeveloperのインストール』を参照してください。

Oracle Fusion Middleware Infrastructure 12へのアップグレードの準備のために11gアプリケーションをテストするには、既存のOracle JDeveloper 11gプロジェクトをOracle JDeveloper 12cで開きます。Oracle JDeveloperによってプロジェクトが12cに移行されます。その後、Oracle JDeveloper内から利用可能な埋込みアプリケーション・サーバーで、アプリケーションをテストできます。Oracle JDeveloper 12cでアプリケーションを確認して必要に応じて変更したら、Application Developer 11gドメインをOracle Fusion Middleware Infrastructure 12cにアップグレードして、アプリケーションを再デプロイします。

アプリケーションの移行の詳細は、『Oracle JDeveloperのインストール』の以前のバージョンからOracle JDeveloperへの移行に関する項を参照してください。

2 アップグレード前チェックリスト

このアップグレード前チェックリストのタスクの説明は、読者が『Oracle Fusion Middlewareのアップグレードのプランニング 12c』を熟読し、アップグレードの要件を理解していることを前提にしています。

アップグレード・プロセスを開始する前に、該当するタスクをすべて完了してください。

注意:

実行する手順は、既存のシステムの構成、アップグレードするコンポーネントおよびアップグレードと構成プロセスの最後に作成する環境によって異なります。

ここで説明する共通のアップグレード前手順に加えて、コンポーネント固有のタスクを実行する必要があります。その他の手順は、コンポーネント固有のアップグレード・ドキュメントを参照してください。

表2-1 Oracle Fusion Middleware 12cにアップグレードする前に実行するタスク

タスク

説明

ドキュメント

アップグレード前環境の完全なバックアップを作成します。

すべてのアップグレードで必須です。

アップグレードを開始する前に、アップグレードするスキーマが含まれているシステムに重要なファイルおよびデータベースのすべてをバックアップします。

アップグレードに失敗すると、アップグレード前の環境をリストアし、アップグレードをもう一度開始する必要があります。

完全なバックアップの作成(必須)

サポートされているハードウェアおよびソフトウェア構成上で、製品をインストールおよびアップグレードしていることを確認します。

アップグレード計画のプロセスの一部として、ハードウェアおよびソフトウェア構成が最新の動作保証および要件のドキュメントでサポートされていることを確認しています。

アップグレードを開始する前に、動作保証要件が変更されていないかどうか、この情報を再確認してください。

アップグレードの前に、コンポーネントに最新のパッチが適用されていることを確認します。

動作保証およびシステム要件の確認

アップグレードの前に、古い、または未使用のデータを削除します。

パフォーマンスの最適化のために、アップグレードされた環境で使用しないデータおよびオブジェクトをパージすることを検討してください。

未使用データのパージ

本番環境をクローニングします。

システム・ファイルの完全なバックアップの作成に加えて、本番環境をクローニングする必要もあります。この環境は、アップグレードをテストするために使用されます。

本番環境のクローニング(推奨)

64ビットのオペレーティング・システムが稼働していることを確認します。Oracle Fusion Middleware 12cのほとんどのコンポーネントは、64ビットのオペレーティング・システムで実行する必要があります。

現在32ビットのオペレーティング・システムを実行している場合にのみ必要です。

32ビットから64ビット・オペレーティング・システムへの移行

アップグレードの開始点によって、アップグレード前に、新しい12cスキーマを作成する必要があります。

Oracle Fusion Middleware 12cでは、既存の環境をアップグレードする前に、リポジトリ作成ユーティリティ(RCU)を使用して新しいスキーマを作成する必要があります。

アップグレード前の必要なスキーマの作成

ファイルベースのポリシー・ストアを使用している場合、それをデータベース・ベースのポリシー・ストアに再関連付けする必要があります。

以前の12cリリースからアップグレードする場合、この手順は必要ありません。

ファイルベース・ポリシー・ストアのデータベース・ベース・ポリシー・ストアへの再関連付け(必須)

OIDベースのセキュリティ・ストアを使用するときのスキーマの要件を理解します。

OIDベースのセキュリティ・ストアを使用している場合、アップグレード前に12c OPSSスキーマを作成する必要があります。

OIDベースのセキュリティ・ストアのための12c OPSSスキーマの作成

Fusion Middlewareのすべてのセキュリティ・ストアで最高位のセキュリティ・レベルを保持することをお薦めします。

アップグレード前に既存のセキュリティ・ストアをバックアップし、セキュリティ・ストア固有の手順に従いそれらをアップグレードします。

セキュリティ・ストアの最新バージョンへのアップグレード

Fusion Middleware 12cで使用されているセキュリティ・アルゴリズムには、JDK用の追加のポリシー・ファイルが必要になるものがあります。

強化した暗号化(AES 256など)の使用を計画している場合にのみ必要です。アップグレード前に、JDKに必要なポリシー・ファイルを適用することをお薦めします。

強化された暗号化(AES 256)の使用

新しい非SYSDBAユーザーを作成し、アップグレードをSYS/SYSDBAで実行することを回避します。

fmwという名前の非SYSDBAユーザーを作成し、アップグレード・アシスタントで必要な権限のみを付与してアップグレード・アシスタントを実行することをお薦めします。

非SYSDBAユーザーの作成

Oracle Databaseユーザーの場合: エディション・ベースの再定義(EBR)に対応したスキーマをアップグレードする前に、最初にデータベース・サーバーに接続して、12c (12.2.1)のデータベース・サーバーにエディションを作成する必要があります。

この手順は、エディション・ベースの再定義(EBR)データベースを使用している場合にのみ必要です。

エディション・ベースの再定義のためのサーバー上でのエディションの作成(オプション)

アップグレード前に、Oracleホームに新しい12c製品をダウンロードし、インストールする必要があります。

アップグレード前環境にすでに存在する製品の12c (12.2.1)バージョンをインストールします。12c (12.2.1)用にリリースされていない製品がありますが、将来のリリースで使用可能になる予定です。

12c Oracle Fusion Middleware製品ディストリビューションのダウンロードとインストール

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

実際のアップグレード・プロセスを開始する前に、アップグレード・アシスタントを-readinessモードで実行し、アップグレード前環境の分析を読取り専用で実行します。問題がある場合、アップグレード前にそれらを修正する必要があります。

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

アップグレードを完了するためのコンポーネント固有のアップグレード・ドキュメントを使用します。

ドキュメントでは、アップグレードで必要なコンポーネント固有のタスクについて説明します。これらのタスクには、アップグレード前に実行するものと、アップグレード後に実行するものがあります。常にOracle Fusion Middlewareのアップグレード・ドキュメントを参照し、正常にアップグレードされていることを確認します。

コンポーネント固有のアップグレード・ドキュメントの検索

2.1 完全なバックアップの作成(必須)

新しいリリース12cディストリビューションのインストールと、Oracle Fusion Middleware 11gまたは12cデプロイメントのアップグレードを始める前に、システムに重要なすべてのファイルをバックアップしたか確認します。これには、Oracle Fusion Middlewareスキーマをホストするすべてのデータベースが含まれます。

詳細は、環境のバックアップに関する項を参照してください。

2.2 本番環境のクローニング(推奨)

実際の本番環境の完全な作業用コピーを作成し、クローン環境をアップグレードし、アップグレードされたコンポーネントが予想どおりに動作することを確認してから(必ず確認した後で)、本番環境をアップグレードすることをお薦めします。

アップグレードの導入に使用するためのテスト環境の作成の詳細は、『Oracle Fusion Middlewareの管理』のテスト環境から本番環境への移動に関する項を参照してください。

アップグレードは元に戻せません。ほとんどの場合、エラーが発生したときには、アップグレードを中止してバックアップから環境全体をリストアし、アップグレード・プロセスを最初からやり直す必要があります。潜在的なアップグレードの問題を開発環境で特定しておくと、無駄な停止時間を排除できます。

注意:
準備状況チェックをクローン環境で実行すると、アップグレードで発生する可能性のある問題の特定に役立ちます。

アップグレード前にクローン環境でテストを実施することにより、本番のアップグレード計画全体に適用できる重要なデータが得られます。

本番環境のクローンでアップグレードを実行すると、次のようなメリットもあります。

- アップグレードに関する問題を明らかにし、修正します。

- エンドツーエンドのアップグレードを完了させる練習をします。

- アップグレードのパフォーマンスおよびパージ・スクリプトがどのように役立つかを理解します。

- アップグレードの完了までに必要な時間を理解します。

- データベース・リソースの使用(一時表領域、PGAなど)について理解します。

2.3 動作保証およびシステム要件の確認

ご使用の環境がインストールに必要な要件を満たしていることを確認するには、動作保証マトリックスおよびシステム要件のドキュメントを併せて使用する必要があります。

- 環境が動作保証要件を満たしていることの確認

- システム要件と仕様の確認

- Oracle Fusion Middlewareをホストしているデータベースがでサポートされていることの確認。

- このリリースのOracle Fusion MiddlewareでJDKが動作保証されていることの確認。

注意: 動作保証、システム要件および相互運用性情報をチェックする際に、32ビットまたは64ビット特有のシステム要件について確認してください。これは、明確に32ビットまたは64ビット環境専用に設計されたソフトウェアをダウンロードする場合に、重要です。

警告: アップグレードを開始する前に、現行の環境に必ず最新のパッチ・セットを適用してください。動作保証は、特に明記がないかぎり、パッチが完全に適用された環境に基づいています。

2.3.1 環境が動作保証要件を満たしていることの確認

製品をインストールする場合、サポートされているハードウェアまたはソフトウェア構成を使用します。詳細は、12c (12.2.1)の動作保証マトリックスに関する説明を参照してください。

Oracleは、動作保証されているすべてのシステムおよび環境で製品のパフォーマンスをテストおよび検証しており、新しい動作保証要件が確認されると、それらはすぐに適切な動作保証に関するドキュメントに追加されます。新しい動作保証要件は随時確認される場合があるため、動作保証に関するドキュメントはドキュメント・ライブラリの外部に置かれ、Oracle Technology Networkで提供されています。

2.3.2 システム要件と仕様の確認

Oracle Fusion Middlewareのシステム要件と仕様に関するドキュメントを使用して、動作保証要件を満たしていることを確認してください。たとえば、この動作保証に関するドキュメントに、ご使用の製品を64ビットOracle Linux 7上にインストールすることが動作保証されていると示されている場合、このドキュメントを使用して、Oracle Linux 7システムが最低限必要な仕様(ディスク領域、使用可能なメモリー、特定のプラットフォーム・パッケージとパッチおよびその他のオペレーティング・システム固有のアイテムなど)を満たしていることを確認します。このドキュメントは必要に応じて更新され、ドキュメント・ライブラリの外部に置かれています。最新バージョンは、Oracle Technology Networkから入手できます。

Oracle Fusion Middleware 12cをインストールおよびアップグレードするシステム要件の詳細は、「Oracle Fusion Middlewareのシステム要件と仕様」を参照してください。

注意: アップグレード準備の一環としてOracle Fusion Middlewareリリース12cソフトウェアをインストールする際は、Oracle Fusion Middleware 11gソフトウェアのインストールおよび構成に使用したものと同じユーザー・アカウントを使用する必要があります。UNIXオペレーティング・システムでは、これによって、正しい所有者とグループが新しいOracle Fusion Middleware 12cのファイルおよびディレクトリに確実に適用されます。

2.3.3 Oracle Fusion Middlewareをホストしているデータベースがでサポートされていることの確認。

アップグレードする場合のOracle Databaseの要件を理解し、Oracle Fusion Middlewareをホストするデータベースがサポートされており、アップグレードの実行に十分な領域が用意されていることを確認することが重要です。Fusion Middleware 12cを実行する前に、サポートされるOracleデータベースを必須のスキーマで構成しておく必要があります。

2.3.4 このリリースのOracle Fusion MiddlewareでJDKが動作保証されていることの確認。

汎用インストーラを使用してOracle Fusion Middleware製品をインストールするには、サポートされているJDKをシステムにダウンロードしてインストールする必要があります。

JDKは、Oracleホームの外部にインストールしてください。Oracle Universal Installerにより指定されたOracleホーム・ディレクトリが空であることが検証され、空のディレクトリが指定されていなければインストールは行われません。JDKをOracleホームにインストールした場合、今後の操作で問題が発生します。したがって、JDKのインストール場所は、/home/oracle/products/jdkディレクトリにすることをお薦めします。java -jarコマンドを使用して、インストーラJARファイルを実行できます。

汎用インストーラとプラットフォーム固有のインストーラの相違点の詳細は、Oracle Fusion Middlewareのダウンロード、インストールおよび構成のREADMEファイルの汎用とプラットフォーム固有の配布との相違点の理解に関する項を参照してください。

必要なJDKをダウンロードするには、ブラウザで次のURLにアクセスしてJava SE JDKをダウンロードします。

http://www.oracle.com/technetwork/java/javase/downloads/index.html

2.4 32ビットから64ビット・オペレーティング・システムへの移行

Oracle Fusion Middleware 12cのほとんどのコンポーネントは、64ビットのオペレーティング・システムで実行する必要があります。32ビットの環境を実行している場合は、アップグレード前に、32ビット環境を64ビット・ソフトウェア環境に移行する必要があります。

注意:
動作保証、システム要件および相互運用性情報をチェックする際に、32ビットまたは64ビット特有のシステム要件について確認してください。これは、明確に32ビットまたは64ビット環境専用に設計されたソフトウェアをダウンロードする場合に、重要です。

Oracle Fusion Middleware 11gソフトウェアがすべて適切に64ビット・マシンで動作することを確認してから、Oracle Fusion Middleware 12cへのアップグレードを実行してください。

これらのタスクでは、ホストは、32ビット・ソース・マシンを指し、ターゲットは、新しい64ビット・ターゲット・マシンを指します。

注意: これらの手順は、データベースが別のホスト上にあり、移動されないことを前提としています。

オペレーティング・システムのアップグレードには、通常、次の内容が含まれます。

- タスク1: アップグレードの64ビット・ソフトウェア要件をサポートするハードウェアを調達する。

- タスク2: 管理サーバー、管理対象サーバーおよびノード・マネージャも含めて、すべてのプロセスを停止する。

- タスク3: 32ビット・ホスト・マシンからすべてのファイルをバックアップする。

- タスク4: 11gのホスト名およびIPアドレスを使用してターゲットの64ビット・マシンを設定する。

- タスク5: 11gドメインのバックアップを32ビット・ホストから64ビット・ホストにリストアする。

- タスク6: 12c (12.2.1)製品ディストリビューションをターゲット・マシンにインストールする。

- タスク7: 標準的なアップグレード手順を使用してターゲットの64ビット環境をアップグレードする。

注意: 次の手順は、オペレーティング・システム・アップグレード・プロセスの例として説明されているため、特定のオペレーティング・システムを更新する場合に実行する必要がある手順がすべて含まれている場合と含まれていない場合があります。詳細は、使用しているオペレーティング・システムのアップグレード・ドキュメントを参照してください。

2.4.1 タスク1: アップグレードの64ビット・ソフトウェア要件をサポートするハードウェアを調達する。

アップグレード・プロセスを開始する前に、サポートされている適切なターゲット・ハードウェアが存在することを確認してください。

2.4.2 タスク2: 管理サーバー、管理対象サーバーおよびノード・マネージャも含めて、すべてのプロセスを停止する。

管理サーバー、管理対象サーバーおよびノード・マネージャがホスト上で起動している場合はこれらも含めて、すべてのプロセスを停止する必要があります。たとえば、管理サーバーを停止するには、次のように指定します。

DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]

2.4.3 タスク3: 32ビット・ホスト・マシンからすべてのファイルをバックアップする。

11gデプロイメント全体の完全バックアップを作成したことを確認してからアップグレード・プロセスを開始する必要があります。移行中に問題が発生した場合、これらのファイルを使用してプロセスを再度開始する必要があります。

同一のマシンで32ビットから64ビットへアップグレードする場合、アップグレードが失敗した場合、ソース環境が破損するリスクがあることに注意してください。

11gのファイルのバックアップの詳細は、『Oracle® Fusion Middleware管理者ガイド』の環境のバックアップに関する項を参照してください。

アップグレード時に、次のコンテンツにアクセスする必要があります。

- 11gドメイン・ホーム

- MW_HOME/wlserver_10.3/common/にある11g /nodemanagerディレクトリ

『Oracle® Fusion Middleware管理者ガイド』の環境のバックアップに関する項で説明されている一部のバックアップおよびリカバリ手順は、製品に固有です。完全バックアップを作成するまでアップグレードを続行しないでください。

2.4.4 タスク4: 11gのホスト名およびIPアドレスを使用してターゲットの64ビット・マシンを設定する。

ターゲット・マシンのホスト名およびIPアドレスはホストと同一にする必要があります。そのため、ソース・マシンのIPアドレスおよび名前を変更するか、ソース・マシンを停止してネットワークの干渉を回避する必要があります。

IPアドレスおよびホスト名を変更するプロセスは、オペレーティング・システムによって異なります。詳細は、オペレーティング・システムの管理ドキュメントを参照してください。

2.4.5 タスク5: 11gドメインのバックアップを32ビット・ホストから64ビット・ホストにリストアする。

11gで使用したのと同じディレクトリ構造を使用して、タスク3でバックアップしたファイルをリストアします。ターゲット・マシンのディレクトリ構造は、ホスト・マシンのディレクトリ構造と同じである必要があります。

64ビットターゲット・マシンに11gファイルをリストアする方法の詳細は、『Oracle® Fusion Middleware管理者ガイド』の環境のリカバリに関する項を参照してください。

2.4.6 タスク6: 12c (12.2.1)製品ディストリビューションをターゲット・マシンにインストールする。

詳細は、『Oracle Fusion Middlewareのインストールのプランニング』およびインストールするコンポーネントのコンポーネント固有のインストレーション・ガイドを参照してください。

2.4.7 タスク7: 標準的なアップグレード手順を使用してターゲットの64ビット環境をアップグレードする。

コンポーネントのアップグレードおよびアップグレード後のタスクの実行に関する詳細は、コンポーネント固有のアップグレード・ガイドを参照してください。詳細は、アップグレードしているコンポーネントのコンポーネント固有のアップグレード・ガイドを参照してください。

注意: ノード・マネージャ・アップグレード手順では、元のノード・マネージャ・ファイルにアクセスする必要があります。「タスク3: 32ビット・ホスト・マシンからすべてのファイルをバックアップする。」の一部としてソース・マシンからバックアップされた11gノード・マネージャ・ファイルを使用します。

2.5 未使用データのパージ

アップグレード前に未使用データをパージすると、アップグレード・プロセスを最適化できます。いくつかのコンポーネントでは、アップグレード前に実行できる自動パージ・スクリプトを提供します。パージ・スクリプトを使用している場合、パージが完了するまで待ってから、アップグレード・プロセスを開始してください。アップグレード・アシスタントを使用してスキーマをアップグレードするときに、パージ・スクリプトを実行していると、アップグレードは失敗します。

注意: 大量のデータをパージする必要がある場合は、表のパーティション化や、その他のデータ最適化戦略の採用について検討してください。大量のデータを削除するスクリプトを使用すると、パフォーマンスに影響を与えることがあります。

詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のパージおよびパーティション化の方法の開発に関する項およびデータベース成長管理戦略の開発に関する項を参照してください。

2.6 アップグレード前の必要なスキーマの作成

アップグレード前に、新しいスキーマの作成が12cデプロイメントで必要な場合があります。

12cに作成する必要があるその他のスキーマを確認するには、既存の環境にあるコンポーネント・スキーマとアップグレードに必要なスキーマを比較します。コンポーネント固有のアップグレード・ガイドで、コンポーネントに必要なスキーマを特定できます。

詳細は、「アップグレード・アシスタントでアップグレードできるスキーマの識別」を参照してください。

11gからアップグレードする場合は、次の点に注意してください。

- 12cでは、11gからアップグレードする前に作成する必要がある新しいスキーマがあります。新しいサービス表スキーマ(prefix_STB)には、ドメイン作成時に他のOracle Fusion Middlewareコンポーネントがアクセスして使用できる基本的なスキーマ構成情報が格納されます。詳細は、「サービス表スキーマの理解」を参照してください。

注意:
サービス表スキーマを作成していない場合、エラー・メッセージ「UPGAST-00328 : スキーマ・バージョンのレジストリ表はこのデータベースに存在しません。」が発生することがあります。これが発生した場合、アップグレード・アシスタントを実行するために、サービス表スキーマを作成する必要があります。

- 監査スキーマには、12cを実行する前に作成する必要がある2つのスキーマが追加されました。監査サービス(_IAU)をアップグレードする場合、_IAUに加えて、_IAU_APPENDおよび_IAU_VIEWERを必ず選択します。

2.7 ファイルベース・ポリシー・ストアのデータベース・ベース・ポリシー・ストアへの再関連付け(必須)

ポリシー・ストアは、ファイル・ベースではなく、データベース・ベースである必要があります。ファイルベースまたはOIDベースのポリシー・ストアを使用している場合、アップグレードの前に、ストアをデータベース・ベースのストアに再関連付けする必要があります。データベース・ベースのポリシー・ストアを使用している場合、これらのタスクを実行する必要はありません。

1. 11g OPSSとIAUスキーマの作成

2. 11gポリシー・ストアのデータベース・ベース・ポリシー・ストアとOPSSスキーマへの再関連付け

3. ポリシー・ストアの再関連付けが正常に行われたことの確認

2.7.1 11g OPSSとIAUスキーマの作成

11g Repository Creation Utilityを使用して、サポートされているDatabaseで新しい11g Oracle Platform Security Services (OPSS)および監査スキーマ(IAU)のスキーマを作成します。

11gスキーマの作成の詳細は、11gバージョンの『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』のリポジトリ作成ユーティリティの取得に関する項を参照してください。

2.7.2 11gポリシー・ストアのデータベース・ベース・ポリシー・ストアとOPSSスキーマへの再関連付け

11g環境でファイル・ベースのポリシー・ストアを使用している場合、ファイル・ベースのストアをデータベース・ベースのリポジトリおよびOPSSスキーマに再関連付けします。

11g OPSSスキーマをデータベース・ベース・リポジトリに再関連付ける方法の詳細は、「OPSSセキュリティ・ストアの再関連付け」を参照してください。

2.7.3 ポリシー・ストアの再関連付けが正常に行われたことの確認

ポリシー・ストアの再関連付けが正常に行われたことを確認するため、次の手順を実行します。

1. Enterprise Manager Fusion Middleware Controlにログインします。

2. 「ドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」に移動します。

3. 画面の「監査サービス」セクションの「構成」をクリックし、次の画面にアクセスします。

4. 表の「プロバイダ・タイプ」フィールドには、エントリ「Oracle Database」が表示されます。「プロバイダ・タイプ」に「ファイル」と表示されている場合、再関連付けは成功していません。

2.8 OIDベースのセキュリティ・ストアのための12c OPSSスキーマの作成

11gでOracle Internet Directory (OID)ベースのセキュリティ・ストアを使用している場合は、12cリポジトリ作成ユーティリティ(RCU)を使用して、新しい12c OPSSスキーマを作成します。アップグレード・アシスタントでOPSSスキーマを選択すると、アップグレード・アシスタントによってOIDベースのセキュリティ・ストアがアップグレードされます。アップグレード前に、OIDベースのセキュリティ・ストアを再関連付けする必要はありません。

注意:

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

2.9 セキュリティ・ストアの最新バージョンへのアップグレード

OPSSセキュリティ・ストアをアップグレードする前に、アップグレードに失敗した場合にリカバリできるようバックアップを作成してください。セキュリティ・ストアのバックアップの詳細は、「OPSSセキュリティ・ストアのバックアップとリカバリ」を参照してください。

セキュリティ・アップグレード手順は、アップグレードされるセキュリティ・ストアのタイプに応じて異なります。アップグレード可能なセキュリティ・ストアは、ファイルベース、OIDベースまたはDBベースです。手順は、元の監査データ・ストアのタイプ(ファイルベースまたはDBベース)に応じて異なります。

- DBベースのセキュリティ・ストアのアップグレード

- OIDベースのセキュリティ・ストアのアップグレード

- 共有セキュリティ・ストアのアップグレード

- ファイルベースのセキュリティ・ストアのアップグレード

2.10 非SYSDBAユーザーの作成

スキーマのアップグレードに必要な権限を持つユーザーを作成することをお薦めします。次に示す権限は、アップグレード・アシスタントを起動する前に付与する必要があります。

"FMW"は、アップグレード・アシスタントを起動するために作成できるユーザーです。次の例のwelcome1はパスワードです。権限を付与する際に、実際のパスワードを指定していることを確認します。

注意:
v$xatrans$表がまだない場合、次のスクリプトの行を削除します。

grant select on v$xatrans$ to FMW with grant option;

この表はデフォルトで作成されません。この表を作成するには、このユーザーを作成する前にXAVIEW.SQLスクリプトを実行します。

create user FMW identified by welcome1;

grant dba to FMW;

grant execute on DBMS_LOB to FMW with grant option;

grant execute on DBMS_OUTPUT to FMW with grant option;

grant execute on DBMS_STATS to FMW with grant option;

grant execute on sys.dbms_aqadm to FMW with grant option;

grant execute on sys.dbms_aqin to FMW with grant option;

grant execute on sys.dbms_aqjms to FMW with grant option;

grant execute on sys.dbms_aq to FMW with grant option;

grant execute on utl_file to FMW with grant option;

grant execute on dbms_lock to FMW with grant option;

grant select on sys.V_$INSTANCE to FMW with grant option;

grant select on sys.GV_$INSTANCE to FMW with grant option;

grant select on sys.V_$SESSION to FMW with grant option;

grant select on sys.GV_$SESSION to FMW with grant option;

grant select on dba_scheduler_jobs to FMW with grant option;

grant select on dba_scheduler_job_run_details to FMW with grant option;

grant select on dba_scheduler_running_jobs to FMW with grant option;

grant select on dba_aq_agents to FMW with grant option;

grant execute on sys.DBMS_SHARED_POOL to FMW with grant option;

grant select on dba_2pc_pending to FMW with grant option;

grant select on dba_pending_transactions to FMW with grant option;

grant execute on DBMS_FLASHBACK to FMW with grant option;

grant execute on dbms_crypto to FMW with grant option;

grant execute on DBMS_REPUTIL to FMW with grant option;

grant execute on dbms_job to FMW with grant option;

grant select on pending_trans$ to FMW with grant option;

grant select on dba_scheduler_job_classes to fmw with grant option;

grant select on SYS.DBA_DATA_FILES to FMW with grant option;

grant select on SYS.V_$ASM_DISKGROUP to FMW with grant option;

grant select on v$xatrans$ to FMW with grant option;

grant execute on sys.dbms_system to FMW with grant option;

grant execute on DBMS_SCHEDULER to FMW with grant option;

grant select on dba_data_files to FMW with grant option;

grant execute on UTL_RAW to FMW with grant option;

grant execute on DBMS_XMLDOM to FMW with grant option;

grant execute on DBMS_APPLICATION_INFO to FMW with grant option;

grant execute on DBMS_UTILITY to FMW with grant option;

grant execute on DBMS_SESSION to FMW with grant option;

grant execute on DBMS_METADATA to FMW with grant option;

grant execute on DBMS_XMLGEN to FMW with grant option;

grant execute on DBMS_DATAPUMP to FMW with grant option;

grant execute on DBMS_MVIEW to FMW with grant option;

grant select on ALL_ENCRYPTED_COLUMNS to FMW with grant option;

注意

Oracle Database 11.2.0.3データベース・ユーザーのみ: アップグレードを開始する前に、Oracleパッチ13036331を適用する必要があります。My Oracle Supportにアクセスしてパッチをダウンロードします。

このパッチを適用しない場合は、一部のスキーマで追加の権限を付与する必要があります。

2.11 強化された暗号化(AES 256)の使用

Javaプラットフォームでは、暗号化、公開鍵インフラストラクチャ、認証、安全な通信、アクセス制御など、主要なセキュリティ分野に渡る一連のAPIが定義されています。これらのAPIによって、開発者はアプリケーション・コードにセキュリティ・メカニズムを簡単に統合できます。

Fusion Middleware 12cで使用されているセキュリティ・アルゴリズムには、JDK用の追加のポリシー・ファイルが必要になるものがあります。強化された暗号化(AES 256など)を使用する予定がある場合は、アップグレードの前に、これらのポリシー・ファイルをJDKに適用することをお薦めします。詳細は、次を参照してください。

Java暗号化アーキテクチャのOracleプロバイダ・ドキュメント

アップグレードの開始前に、これらのポリシー・ファイルをJDKに適用していないと、アップグレードに失敗することがあります。その場合は、アップグレード前環境全体をリストアして、アップグレードを最初からやり直す必要があります。

2.12 エディション・ベースの再定義のためのサーバー上でのエディションの作成(オプション)

Oracle Databaseユーザーのみ:エディションベースの再定義を使用すると、アプリケーションの使用中にそのOracle Databaseコンポーネントをアップグレードでき、停止時間を最小化あるいは排除することができます。

エディション・ベースの再定義(EBR)に対応したスキーマをアップグレードする前に、最初にデータベース・サーバーに接続して、12c (12.2.1)のデータベース・サーバーにエディションを作成する必要があります。12.2.1の新しいエディションは、既存の11gまたは12cエディションの子である必要があります。

データベース・サーバーにエディションを作成するには、SYS (またはDBA権限のある別のOracleユーザー)としてログインし、次のコマンドを使用します。

SQL> create edition Oracle_FMW_12_2_1 as child of Oracle_FMW_11_1_1_7_0;
Edition created.

前述のコードの例Oracle_FMW_11_1_1_7_0は11.1.1.6または11.1.1.7スキーマを作成したときにRCU 11.1.1.6または11.1.1.7で指定するエディション名の例として使用します。エディションを作成する際は、実際に使用する名前を入力してください。

アップグレード手順の間、再構成ウィザードを実行して既存のドメインを再構成するよう要求されます。再構成ウィザードの実行前に、データベースのデフォルト・エディションを指定する必要があります。次のようなSQLを使用して、データベースのデフォルト・エディション名を手動で次のように設定します。

ALTER DATABASE DEFAULT EDITION = edition_name;

2.13 カスタム・ドメイン環境設定のメンテナンス

アップグレード前にsetDomainEnvスクリプト(または他の起動スクリプト)に加えられた変更は、ドメインの再構成プロセスで再生成されるスクリプトにより上書きされます。アップグレード前に、カスタムのsetDomainEnv設定の保持(オプション)に関する項の説明に従って、別個のファイルを作成してドメインのカスタマイズを保存しておくことを検討してください。

注意:

アップグレード前に、setUserOverridesスクリプトを作成できない場合は、「setDomainEnvへのカスタマイズの再適用」の説明に従って、設定を再適用する必要があります。

2.14 12c Oracle Fusion Middleware製品ディストリビューションのダウンロードとインストール

製品ディストリビューションは、Oracle Technology Network (OTN)またはOracle Software Delivery Cloudのいずれかからダウンロードできます。ディストリビューションを取得するためにアクセスする必要のあるサイトの詳細な情報は、「Oracle Fusion Middlewareダウンロード、インストールおよび構成のReadmeファイル」ページを参照してください。

必要なソフトウェアをダウンロードしたら、ソフトウェアのインストールおよびダウンロードに進みます。

インストールを開始するには、OTNのOracle Fusion Middleware 12c (12.2.1)のドキュメント・ライブラリのインストール、パッチおよびアップグレードに関する項の共通タスクのページを参照してください。

注意: Oracle Fusion Middleware Infrastructureディストリビューションは、コンポーネント固有のディストリビューションの前にインストールする必要があります。

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

アップグレード・アシスタントを-readinessモードで実行すると、読取り専用のアップグレード前チェックをドメインで実行できます。問題が検知された場合、実際のアップグレードを開始する前にそれらを修正できます。

注意:
準備状況チェックはシステムがオンラインの状態で実行され、チェック内容の包括性により、準備状況チェックが完了するまでに長時間実行されることがあります。

アップグレード前環境で準備状況チェックを実行するには、次に示すように、アップグレード・アシスタントを-readinessモードで起動する必要があります。

1. ディレクトリを、UNIXオペレーティング・システムではORACLE_HOME/oracle_common/upgrade/binに、Windowsオペレーティング・システムではORACLE_HOME\oracle_common\upgrade\binに変更します。

2. 次のコマンドを入力してアップグレード・アシスタントを起動します。
UNIXオペレーティング・システムの場合:

./ua -readiness

Windowsオペレーティング・システムの場合:

ua.bat -readiness

Upgrade Assistantの各画面で必要な情報を指定します。表示される画面は、選択するアップグレード・オプションによって異なります。次の項では、アップグレード・オプションおよび入力する必要がある情報を説明しています。

2.16 コンポーネント固有のアップグレード・ドキュメントの検索

これで、アップグレードを開始できます。次の表を使用して、12cのアップグレードに必要なアップグレード固有タスクを決定します。

表2-2 アップグレードを完了するためのドキュメント

製品領域

アップグレードする内容

使用するアップグレード・ドキュメント

Oracle WebLogic Server - スタンドアロン

既存のFusion Middleware 11gドメインによって管理されていない、または登録されていないOracle WebLogic Server。

Oracle WebLogic Serverのアップグレード

Oracle WebLogic Server (12cではInfrastructureと呼ばれる)を使用したカスタムOracle Application Developer Frameworkアプリケーション

カスタムOracle Application Developer Frameworkアプリケーションのセットを使用してデプロイされた管理対象11g WebLogic Serverドメイン。

Oracle Fusion Middleware Infrastructureへのアップグレード

Oracle HTTP Server - 管理対象またはスタンドアロン

管理機能のためにWebLogicドメインで機能するように構成されているOracle HTTP Serverは、管理対象サーバーです。

Oracle WebLogicドメインによって管理されていない、またはOracle WebLogicドメインに登録されていないOracle HTTP Serverは、スタンドアロン・サーバーです。

Oracle HTTP Serverのアップグレード

Oracle SOA SuiteおよびBPM

Business Process Management (BPM)、Oracle Service Bus (OSB)、Enterprise Security Services (ESS)、Managed File Transfer (MFT)、Business Activity Monitoring (BAM)およびワークフロー・インスタンス・データなどのSOA Suiteコンポーネント。

Oracle SOA SuiteおよびBusiness Process Managementのアップグレード

ユーザー・メッセージング・サービス

ユーザー・メッセージング・サービス

Oracle User Messaging Serviceの管理

Oracle Data Integrator

Data Integrator

Oracle Data Integratorのアップグレード

3 Infrastructureアップグレードの実行

この項のトピックは、Oracle Fusion Middleware 11g Application DeveloperインストールをOracle Fusion Middleware 12c (12.2.1) Infrastructureにアップグレードするエンドツーエンドの手順について説明します。

3.1 Infrastructureの必要なアップグレード前タスクの完了

Oracle Fusion Middleware 11g Application DeveloperインストールをOracle Fusion Middleware 12c Infrastructureにアップグレードする前に、環境に関連付けられたOracle Fusion Middlewareの標準アップグレード前タスクのすべてを完了する必要があります。アップグレード前タスクのほとんどは、Fusion Middlewareコンポーネントに必要ですが、Infrastructure固有のものもあります。

注意:

Infrastructureでの必要なアップグレード前タスクの完了に加えて、最初に、Oracle Fusion Middlewareの「アップグレード前チェックリスト」で説明する該当するすべてのアップグレード前タスクを完了する必要があります。

既存の環境をバックアップする必要があります。なんらかの理由でアップグレードに失敗した場合、ソース・バックアップからアップグレード・プロセスをやりなおす必要があります。

詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareのアップグレードのプランニング』のアップグレードのためのバックアップおよびリカバリ計画に関する項を参照してください。

Infrastructure固有のアップグレード前タスクの詳細は、次を参照してください。

- カスタムsetDomainEnv設定のメンテナンス(オプション)

- OIDセキュリティ・ストアでの認証なしSSLモードの使用方法

- OWSMポリシー・セットからのサーバー・インスタンス・スコープの削除

- 事前定義ドキュメントのクローニングおよびOWSMポリシー・アタッチメントの移行

3.1.1 カスタムsetDomainEnv設定のメンテナンス(オプション)

すべてのドメインには、動的に生成されたドメインおよびsetDomainEnvなどのサーバー起動スクリプトがあります。起動スクリプトに行った変更は、その後のドメインのアップグレード操作中に上書きされるため、これらの起動スクリプトを変更しないでください。

注意:

アップグレード前にsetDomainEnvスクリプト(または他の起動スクリプト)に加えられた変更は、ドメインの再構成プロセスで再生成されるスクリプトにより上書きされます。別のファイルを作成して、アップグレード前にカスタマイズしたドメイン設定を格納することを検討してください。

ドメインのすべてのサーバーに適用されるサーバー起動パラメータをカスタマイズする場合は、setUserOverrides.cmd (Windows)またはsetUserOverrides.sh (UNIX)という名前のファイルを作成することにより、たとえば、WebLogic Serverクラスパスにカスタム・ライブラリを追加する、サーバー実行用の追加のJavaコマンド行オプションを指定する、または追加の環境変数を指定する、などの構成が可能です。このファイルに追加されたカスタマイズはドメインのアップグレード操作中に保存され、packおよびunpackコマンドを使用する際にリモート・サーバーに継承されます。

サーバーの起動中にこのファイルが存在する場合は、起動順序に含められ、定義されたオーバーライドが有効になります。このファイルは、domain_home/binディレクトリに格納する必要があります。

ドメイン全体に適用されるカスタマイズされたパラメータをアップグレード後に保持するための、setUserOverridesファイルの作成に関する詳細は、「ドメイン全体に適用されるサーバー・パラメータのカスタマイズ」を参照してください。

注意:

アップグレード前に、setUserOverridesスクリプトを作成できない場合は、「setDomainEnvへのカスタマイズの再適用」の説明に従って、設定を再適用する必要があります。

3.1.2 OIDセキュリティ・ストアでの認証なしSSLモードの使用方法

12c Infrastructureにアップグレードし、セキュリティ・ポリシー・ストアのOIDをOracle WebLogic Serverで使用している場合、デフォルトのSSLモードを変更する必要があります。Oracle Internet Directory 11gでは、SSL相互運用性モードはデフォルトで有効です。ただし、Oracle Internet Directoryは、SSL相互運用性モードが無効であることを前提として、JDKのSSLに完全に準拠しています。

Oracle Internet Directory (OID)における認証なしSSLモードのデフォルト使用は、介在者(MITM)攻撃を受けやすくなるため、本番環境ではお薦めできません。

ただし、認証なしSSLが必要で、WebLogic Serverがクライアントの場合は、アップグレード前に次のシステム・プロパティをweblogic.propertiesファイルに適用する必要があります。

- -Dweblogic.security.SSL.AllowAnonymousCipher=true

- -Dweblogic.security.SSL.ignoreHostnameVerification=true

注意:

これらのプロパティを設定することにより、匿名暗号スイートが有効化され、ホスト名の検証チェックなしでクライアント接続が確立されるため、結果的にWLSは介在者攻撃を受けやすくなります。

WLS 12cでOIDを使用する場合は、サーバー認証またはクライアント/サーバーSSL認証の使用を強くお薦めします。

3.1.3 OWSMポリシー・セットからのサーバー・インスタンス・スコープの削除

ポリシー・セットのサーバー・インスタンス・スコープは、11g (11.1.1.7.0)では非推奨で、12cではサポートされていません。ただし、サーバー・スコープを使用するポリシー・セットがある場合、それらのポリシー・セットは12cへのアップグレード時に無効化されます。したがって、12cへのアップグレード前に、すべての11gポリシー・セットからサーバー・インスタンス・スコープを削除する必要があります。

詳細は、Oracle Fusion Middleware 11gリリース1 (11.1.1.7.0)のドキュメント・ライブラリのWebサービスのためのセキュリティおよび管理者ガイドのポリシー・セットの編集に関する項を参照してください。

3.1.4 事前定義ドキュメントのクローニングおよびOWSMポリシー・アタッチメントの移行

アップグレードの際、ご使用の環境向けにカスタマイズされていない事前定義ドキュメントは読取り専用バージョンで置き換えられ、新しい読取り専用の事前定義ドキュメントが追加される点に注意してください。ただし、カスタマイズされた既存の事前定義ドキュメント、およびリポジトリのユーザー作成のカスタム・ポリシーは上書きされません。

最新のポリシーを常にすべて取得できるように、変更した事前定義ドキュメントはクローニングし、ポリシー・アタッチメントは移行することをお薦めします。詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のOWSMリポジトリのアップグレードに関する項を参照してください。

3.2 APPHOSTへのOracle Fusion Middleware Infrastructure のインストール

Infrastructureディストリビューション・コンポーネントを、11gと同じホスト上の新しいOracleホームにインストールします。

注意:

Oracle Fusion Middleware Infrastructure 12cの構成に、構成ウィザードを使用しないでください。

表3-1 に示す指示に従い、Oracle Fusion Middleware Infrastructureをインストールします。

表3-1 Oracle Fusion Middleware Infrastructureインストール・ロードマップ

タスク

説明

詳細情報

12cのインストール用にシステムを準備します。

Infrastructure 12cをインストールする前に、システムおよびネットワークの最小要件が満たされていることを確認します。

『Oracle Fusion Middleware Infrastructureのインストールと構成』のシステム環境の確認ロードマップに関する項。

Infrastructureディストリビューションを入手します。

Oracle Fusion Middleware Infrastructureディストリビューション(wls_jrf_generic.jar)を入手します。

『Oracle Fusion Middleware Infrastructureのインストールと構成』のOracle Fusion Middleware Infrastructureディストリビューションの理解と入手に関する項。

Infrastructure 12cインストーラを起動します。

ダウンロードした場所からInfrastructureインストーラを起動します。

『Oracle Fusion Middleware Infrastructureのインストールと構成』のインストール・プログラムの起動に関する項。

インストーラ画面に従います。

インストーラを使用してInfrastructure 12cをインストールします。

『Oracle Fusion Middleware Infrastructureのインストールと構成』のインストール画面の操作に関する項。

3.3 Oracle HTTP Serverのインストール

ドメインに、そのドメインに関連付けられたOracle HTTP Serverインスタンスが含まれる場合は、次のマシンにOracle HTTP Serverをインストールする必要があります。

- Oracle HTTP Serverインスタンスが実行されているマシン

- 管理サーバーが実行されているマシン

Oracle HTTP Serverのインストールの詳細は、 Fusion Middleware Oracle Oracle HTTP Serverのインストールと構成に関するマニュアルのOracle HTTP Serverソフトウェアのインストールに関する項を参照してください。

Oracle HTTP Serverのアップグレードの詳細は、Oracle HTTP Serverのアップグレードを参照してください。

注意:

インストール中は、Oracle HTTP Serverを構成しないでください。HTTPサーバーは、アップグレードの再構成プロセスで構成します。

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

アップグレード・アシスタントを実行する前に、すべてのOracle Fusion Middleware管理対象サーバー、管理サーバーおよび更新するスキーマまたは構成を使用している可能性があるシステム・コンポーネント(OHSなど)を停止します。これを行わないと、結果としてアップグレードが不完全になったり、障害が発生する場合があります。

ノード・マネージャを実行している場合は、ノード・マネージャも停止する必要があります。これを行うには、ノード・マネージャが実行されているコンソール・ウィンドウを閉じるか、stopNodeManager WLSTコマンドを使用します。

Oracle Fusion Middleware環境を停止する手順は、『Oracle Fusion Middlewareの管理』のOracle Fusion Middleware環境の停止に関する項に記載されています。

3.5 スキーマ・バージョン・レジストリを使用した既存の11gスキーマの識別

Upgrade Assistantは、アップグレードできるスキーマを識別します。シングル・セッションのUpgrade Assistantの実行で、複数のスキーマをアップグレードできます。

データベースにスキーマが作成されると、RCUは、schema_version_registryという表を作成して維持します。この表には、バージョン番号、コンポーネント名とID、作成日と変更日およびカスタム接頭辞などのスキーマ情報が含まれています。

どの11gまたは12cスキーマが12.2.1にアップグレードできるかを判断するには、『Oracle Fusion Middleware Upgrade Assistantによるアップグレード』のアップグレード・アシスタントを使用してアップグレードできるスキーマの識別に関する項を参照してください。

3.6 アップグレード前の必要なスキーマの作成

アップグレードする前に、サポートされているデータベースに1つ以上のスキーマをインストールする必要があります。

- 作成するスキーマの決定

- Repository Creation Utilityを使用した必要なスキーマの作成(RCU)

3.6.1 作成するスキーマの決定

次のシナリオを参考にしてください。

- 11gでデータベースを使用していなかった場合、サポートされているデータベースをインストールして構成し、「Infrastructure 12cは特定のデータベース・スキーマを必要とする」の説明に従って、1つ以上のデータベース・スキーマを作成する必要があります。

- Application Developer 11gドメインのスキーマをホストするためにデータベースをすでに使用していた場合は、「スキーマ・バージョン・レジストリを使用した既存の11gスキーマの識別」の説明に従い、スキーマ・バージョン・レジストリを使用して、データベースですでに利用可能なOracle Fusion Middleware 11gスキーマのリストを表示します。
スキーマ・バージョン・レジストリに表示されるどのスキーマも作成しないでください(かわりに、後でOracle Fusion Middlewareアップグレード・アシスタントをアップグレード処理で使用して、11gスキーマをアップグレードできます)。

ただし、その場合も、「Infrastructure 12cは特定のデータベース・スキーマを必要とする」の説明に従って必要なスキーマを作成する必要があることに注意してください。

注意:

リリース12c (12.1.2.0)より、サービス表(_STB)スキーマは、すべてのInfrastructureインストールに必要です。サービス表は、インフラストラクチャをアップグレードするたびに、アップグレードする必要があります。新しいInfrastructureのインストールで、古いバージョンのスキーマは使用できません。

3.6.2 Repository Creation Utility (RCU)を使用した必要なスキーマの作成(RCU)

次の手順を実行して、必要なスキーマを作成します。

注意:

新しいスキーマを作成する場合、一意のスキーマ接頭辞を使用するようにしてください。この接頭辞によって、データベースにインストール済またはアップグレード済のスキーマと、Oracle Fusion Middleware 12c専用に作成したものとを区別できます。

1. 次の方法によるリポジトリ作成ユーティリティ(RCU)の起動

a. まだ設定していない場合は、JAVA_HOME変数を設定し、JAVA_HOME/binを$PATHに追加します。

b. 対象のシステムで、ORACLE_HOME/oracle_common/binディレクトリに移動します。

c. RCUを起動します。
(UNIX) ./rcu

(Windows) .\rcu.bat

2. RCU画面に従ってInfrastructureアップグレードに必要なスキーマを作成します。
詳細は、『Oracle Fusion Middleware Infrastructureのインストールと構成』のRCU画面でのスキーマの作成に関する項を参照してください。

注意:

エディションベースの再定義(EBR)を使用すると、1つのデータベース・スキーマの複数のバージョンを同一のデータベースで、同時にサポートできます。再定義のためのサーバーでのエディション作成の詳細は、『Oracle Fusion Middlewareのアップグレードのプランニング』のエディションベースの再定義のためのサーバーでのエディション作成に関する項を参照してください。

3.7 スキーマのアップグレードでのアップグレード・アシスタントの使用

アップグレード・アシスタントでは、アップグレード・スキーマの2つのオプションが使用できます。

- 個別に選択されたスキーマ
このオプションにより、アップグレードするコンポーネント・スキーマを選択できます。アップグレードしないコンポーネント・スキーマがドメイン内にある場合、このオプションを選択します。たとえば、ドメインの外部にあるRCUにスキーマを作成してアップグレード・アシスタントを試験的に実行する場合、アップグレード・アシスタントを使用してそれらをアップグレードします。

または

- ドメインで使用されるすべてのスキーマ
この新しいオプションにより、アップグレード・アシスタントは、指定されたドメイン内の使用可能なスキーマをすべて検知し、それらをアップグレードに含めることができます。

3.8 Upgrade Assistantでアップグレードできるスキーマの識別

Upgrade Assistantは、アップグレードできるすべてのスキーマを識別して、すべてのスキーマをアップグレードに含める、またはアップグレードするスキーマをユーザー側で選択できます。アップグレードを開始する前に、アップグレード可能なスキーマのリストを確認するには、スキーマ・バージョンのレジストリを検索します。

ヒント:

スキーマ・バージョンのレジストリから収集した情報と、スキーマを比較して、ドメイン内にアップグレード可能なスキーマがまだあるかどうかを判別します。

Oracleデータベースを使用している場合は、Oracle DBAロールを持つ任意のユーザーとしてデータベースに接続し、SQL*Plusから次の文を実行して現在のバージョン番号を取得します。SQLスクリプト(version.sqlなど)に保存されると、次のレポートが生成されます。

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の数値が11.1.1.6.0以上で、STATUS列が「VALID」であれば、そのスキーマはアップグレードでサポートされます。

あるスキーマではアップグレードの必要がないと判断した場合、schema_version_registry表には、12.2.1アップグレード後もアップグレード前のバージョンでそのスキーマが保持されます。

アップグレードが必要なスキーマに関する注意:

- ほとんどのコンポーネントで、更新できるスキーマ・バージョン開始点は、11gリリース1 (11.1.1.6、11.1.1.7、11.1.1.8または11.1.1.9)または12c (12.1.2または12.1.3)のみです。スキーマが、サポートされているバージョンでない場合、12c (12.2.1)のアップグレード手順を使用する前に、それらをアップグレードする必要があります。
Oracle Enterprise Data QualityやOracle Golden Gate Veridataなど、一部のコンポーネントでは、サポートされている標準的なOracle Fusion Middlewareバージョン以外のバージョンからのアップグレードがサポートされています。

- アップグレードに必要なスキーマに関する追加情報は、コンポーネント固有のインストールおよびアップグレードのドキュメントを参照してください。

- 11gでファイルベースのポリシー・ストアを使用していた場合、Upgrade Assistantを実行する前に、ファイルベースのポリシー・ストアをデータベースベースのセキュリティ・ストアに再度関連付ける必要があります。詳細は、「アップグレード前のファイルベースのポリシー・ストアの再関連付け」を参照してください。

- 11gでOIDベースのポリシー・ストアを使用していた場合は、アップグレード前に新しい12c OPSSスキーマが作成済であることを確認してください。

- Oracle Fusion Middleware 12c (12.2.1)リリースでアップグレード可能な製品のスキーマのみをアップグレードできます。まだ12c (12.2.1)へのアップグレードが可能になっていないコンポーネントを含むドメインをアップグレードしないでください。

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

アップグレード・アシスタントは、Oracle Universal Installer (OUI)により、Fusion Middleware Oracleホームのoracle_common/upgrade/binディレクトリにインストールされます。

グラフィカル・ユーザー・インタフェースを使用してUpgrade Assistantを起動するには、Middleware製品がインストールされているOracleホームのoracle_commonディレクトリに移動します。

他のドメインのアップグレードを開始する前に、単一のドメインのスキーマのアップグレードおよびコンポーネント構成を正常に完了させることをお薦めします。

注意:
アップグレード・アシスタントは、可能なかぎり、非SYSDBAユーザーにより実行する必要があります。非SYSDBAユーザーを作成する手順は、アップグレード前チェックリストで説明します。

1. ディレクトリを、UNIXオペレーティング・システムではORACLE_HOME/oracle_common/upgrade/binに、Windowsオペレーティング・システムではORACLE_HOME\oracle_common\upgrade\binに変更します。

2. 次のコマンドを入力してアップグレード・アシスタントを起動します。

UNIXオペレーティング・システムの場合:

./ua

Windowsオペレーティング・システムの場合:

ua.bat

Upgrade Assistantの各画面で必要な情報を指定します。表示される画面は、選択するアップグレードのタイプによって異なります。次の項では、アップグレード・オプションおよび入力する必要がある情報を説明します。

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

いずれかのスキーマを持つコンポーネントが含まれているOracleホームからUpgrade Assistantを実行する場合、「スキーマ」アップグレード・オプションが表示されます。Upgrade Assistantにより、スキーマのアップグレード候補のコンポーネントのみがリストされます。コンポーネント・リストからアップグレードするスキーマを選択できます。

アップグレード・アシスタントに次の画面が表示されます。

注意:

表示される画面は、選択するオプションによって異なります。

表4-2 Upgrade Assistant画面: スキーマのアップグレード

画面

画面が表示される状況

説明

ようこそ

常時。

この画面では、アップグレード・アシスタントの概要と、アップグレード前の重要なタスクについての情報が示されます。

スキーマ

常時。

この画面を使用して、実行するスキーマ・アップグレード操作を選択します。画面のオプションは、オブジェクトションごとに変化します。

- 個別に選択されたスキーマ

- ドメインで使用されるすべてのスキーマ

使用可能なコンポーネント

「個別に選択されたスキーマ」が選択されている時。

この画面では、アップグレード可能なスキーマがあるインストール済のOracle Fusion Middlewareコンポーネントのリストが提供されます。コンポーネントを選択すると、スキーマとすべての依存関係が自動的に選択されます。

「すべてのスキーマ」のコンポーネント・リスト

「ドメインで使用されるすべてのスキーマ」が選択されている時。

この画面は読取り専用で、指定されたドメイン・ディレクトリで検知され、アップグレードに含められるすべてのコンポーネントおよびスキーマが表示されます。

前提条件

常時。

この画面では、アップグレードを続行する前にすべての前提条件が満たされていることを確認する必要があります。続行する前にボックスを確認してください。

スキーマ資格証明画面

常時。

この画面を使用して、選択したスキーマとそのスキーマをホストするデータベースへの接続に必要な情報を入力します。

画面名は、選択したスキーマ・タイプによって変わります(例: MDSスキーマ)。

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

調査

常時。

この画面には、各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを検証するUpgrade Assistantのステータスが表示されます。

注意:
調査フェーズで検出されたエラーは修正可能で、バックアップからリストアする必要はありません。

アップグレード・サマリー

常時。

この画面を使用して、選択したオプションのサマリーをレビューし、アップグレード・プロセスを開始します。

アップグレードの進行状況

常時。

この画面には、アップグレード処理のステータスが表示されます。

アップグレード成功

または

アップグレード失敗

常時。

アップグレードが成功しました。新規インストールでコンポーネントを機能させるために手動で実行する必要のあるタスクが、アップグレード後のアクションのウィンドウに表示されます。

または

特定のコンポーネントのアップグレードが失敗したため、Upgrade Assistantを再起動する必要があります。

注意: UAのログは、<OH>/oracle_common/upgrade/logsに移入されます。

注意:
アップグレードに失敗した場合、アップグレード前の環境をバックアップからリストアし、問題を解決して、アップグレード・アシスタントを再度起動する必要があります。ファイルが変更されているため、単に問題を解決して、アップグレード・アシスタントを再起動することはできません。

SOA SuiteおよびBPMのアップグレードのみの場合:

クローズされているアクティブなSOAインスタンス・データの12c (12.2.1)へのアップグレードは、Upgrade AssistantでのSOAスキーマ・アップグレード・プロセスの一部として自動的に行われます。詳細は、「SOAインスタンス・データのアップグレードの管理と監視」を参照してください。

3.11 アップグレード・アシスタント画面

この項では、すべてのアップグレード・アシスタント画面について説明します。

注意:

Oracle Fusion Middlewareアップグレード・アシスタントの使用時に表示される画面は、アップグレードするOracle Fusion Middlewareソフトウェアのタイプにより異なります。すべての画面が表示されるのではありません。

3.11.1 ようこそ

Oracle Fusion Middlewareアップグレード・アシスタントを使用して、コンポーネント・スキーマ、コンポーネント構成およびスタンドアロン・システム・コンポーネント構成をFusion Middleware 11gおよび12cリリースからFusion Middleware 12cリリースにアップグレードします。

3.11.2 スキーマ

インストールされたコンポーネントで選択されたスキーマをアップグレードするには、「個別に選択されたスキーマ」を選択します。アップグレード・アシスタントによりスキーマ・アップグレードの候補になるコンポーネントが識別され、ユーザーはアップグレードに含めるスキーマを選択できます

注意: 12.2.1.0.0コンポーネントをサポートするために使用されるスキーマのみをアップグレードしてください。Oracle Fusion Middleware 12.2.1リリースに含まれていない11gまたは12cコンポーネントをサポートするために現在使用されているスキーマをアップグレードしないでください。

図4-1 個別に選択されたスキーマ

3.11.3 ドメインで使用されるすべてのスキーマ

リリース12.2.1では、Oracle Fusion Middlewareアップグレード・アシスタント(UA)は、特定のドメインで使用されるすべてのスキーマをアップグレードするオプションを提供します(ドメイン補助スキーマ・アップグレードまたはDASUと呼ばれることもあります)。「ドメインで使用されるすべてのスキーマ」が選択されている場合、アップグレード・アシスタントはアップグレード可能なスキーマがあるすべてのコンポーネントを検索し、選択します。加えて、可能なかぎり、アップグレード・アシスタントは接続情報をスキーマ入力画面に事前移入します。

3.11.4 ドメインによって使用されるすべての構成

管理対象WebLogic Serverドメインのコンポーネント構成をアップグレードするには、「ドメインによって使用されるすべての構成」オプションを選択します。「参照」をクリックし、ナビゲーション・ツリーを使用して有効なドメイン・ディレクトリを選択します。ドメイン・ディレクトリには、config.xmlファイルを含むconfigディレクトリが含まれます。

3.11.5 スタンドアロン・コンポーネント

Oracle HTTP Server (OHS)などのスタンドアロン・システム・コンポーネントをアップグレードする場合は、「スタンドアロン・システム・コンポーネント構成」オプションを選択します。

次のいずれかを選択するように求めるプロンプトが表示されます。

オプション

説明

新規ドメインの作成

12cでは、スタンドアロン・システム・コンポーネントには、個別のスタンドアロン・ドメインが作成されます。スタンドアロン・ドメインは、Oracle HTTP Serverなどのシステム・コンポーネントのコンテナです。このディレクトリ構造は、Oracle WebLogicドメインのディレクトリ構造と同様ですが、管理サーバーまたは管理対象サーバーを含みません。これは、Oracle HTTP Serverなど同じタイプのシステム・コンポーネントのインスタンスを1つ以上含めたり、異なるタイプを組み合せて含めることができます。

構成ウィザード、packおよびunpackコマンド、WLSTおよびノード・マネージャなどの管理ツールは、スタンドアロン・ドメイン上で実行できます。

既存のドメインの更新

システム・コンポーネントにスタンドアロン・ドメインが作成された後、このオプションを選択して、別のスタンドアロン・システム・コンポーネントにそのドメインを拡張できます。このオプションは、12.1.2または12.1.3.からアップグレードする場合も使用されます。

既存の12cドメインの場所を指定する必要があります。

3.11.6 使用可能なコンポーネント

「個別に選択されたスキーマ」オプションを前の画面で選択し、アップグレードするスキーマを個別に選択すると、ドメインで使用されるすべてのスキーマをアップグレードするかわりに、この画面にアップグレード可能なスキーマのコンポーネントが表示されます。他のスキーマが必要なコンポーネントを選択すると、アップグレード・アシスタントは自動的にこれらのスキーマを選択します。

図4-2 アップグレード可能な構成またはスキーマ(あるいはその両方)のコンポーネントのリスト

3.11.7 「すべてのスキーマ」の「コンポーネント・リスト」

「ドメインで使用されるすべてのスキーマ」を選択すると、この画面にWebLogicドメインのアップグレードに含められるスキーマのリストが表示されます。コンポーネントの名前は、ドメイン内にあるスキーマとともに表示されます。

リストを注意深くレビューして、正しいスキーマがアップグレードされることを確認してください。アップグレードする対象のコンポーネントまたはスキーマが表示されない場合、選択したドメインが正しくない可能性があります。別のドメインを指定するには「戻る」ボタンを使用します。

含めることを望まないコンポーネントまたはスキーマがリストにある場合、「すべてのスキーマ」画面に戻り、「ドメインで使用されるすべてのスキーマ」ではなく、「個別に選択されたスキーマ」を選択します。「個別に選択されたスキーマ」オプションを使用すると、アップグレードに含めるスキーマのみを選択できます。

図4-3「すべてのスキーマ」アップグレードの「コンポーネント・リスト」

3.11.8 WebLogic Serverコンポーネント・リスト

「ドメインによって使用されるすべての構成」がアップグレードで選択されている場合、ドメインのコンポーネントが読取り専用のこの画面に表示されます。続行する前に、コンポーネントのリストを確認してください。

図4-4 「WebLogicコンポーネント構成」の「コンポーネント・リスト」

3.11.9 前提条件

この画面では、アップグレードを続行する前にすべての前提条件が満たされていることを確認する必要があります。続行する前にボックスを確認してください。

警告:

Upgrade Assistantでは前提条件が満たされていることを確認できません。

図4-5 前提条件

3.11.10 エディションベースの再定義(EBR)のデータベースのアップグレード

この画面を使用して、エディションベースの再定義のデータベースのために、エディション・ドロップ・ダウン・リストから子エディションを選択します。アップグレードの開始前に、子エディションを作成する必要があります。

エディション・ベースの再定義のためにサーバー上にエディションを作成する方法の詳細は、『Oracle Fusion Middlewareのアップグレードのプランニング』のエディション・ベースの再定義のためにサーバー上にエディションを作成する方法に関する項を参照してください。

図4-6 EBRデータベースのアップグレード

3.11.11 スキーマ資格証明画面

この画面を使用して、選択したスキーマとそのスキーマをホストするデータベースへの接続に必要な情報を入力します。アップグレード対象のスキーマが前のFusion MiddlewareリリースのRCUによって作成された場合、下に示されているように、使用可能なスキーマ名がリストされているドロップダウン・メニューが表示されます。「接続」をクリックしてデータベースに接続してからアップグレードするスキーマを選択します。

注意: スキーマのほとんどで、この情報は事前移入されます。ただし、アップグレード・アシスタントで接続データを検知できない場合、下に示されているように、手動で入力する必要があります。

図4-7 スキーマの選択 - ドロップダウン・メニュー

図4-8 手動入力のスキーマ・データ

次の表で、この画面に表示される要素について説明します。

要素

説明

データベース・タイプ

ドロップダウン・メニューからデータベース・タイプを選択します。メニューで使用できるデータベースのタイプは、アップグレードしようとするスキーマによって異なります。

アップグレード用に選択されたデータベース・タイプは、RCUが最初にスキーマを作成したときに選択されたデータベース・タイプと同一である必要があります。

データベース・タイプとしてOracle Edition-Based Redefinition (EBR)を選択した場合は、アップグレードしているスキーマも、EBRデータベース・タイプを使用してRCUによって作成されている必要があります。特に、アップグレード・アシスタントでは、スキーマのデータベース・タイプが別のタイプに変換されることはありません。

データベース接続文字列

データベースの場所を入力します。

たとえば、Oracle Databaseを選択する場合は、次のURL形式を使用できます。

host:port/db_service_name

Microsoft SQL ServerまたはIBM DB2データベースを使用している場合は、ドロップダウン・メニューからデータベース・タイプを選択し、フィールドの下のテキストを確認してください。ここには、データベース・タイプごとに必要な構文が表示されます。

注意: Upgrade Assistantは、他の有効な形式の接続文字列を受け入れます。たとえば、Oracle Database TNSスタイルの接続文字列も使用できます。

DBAユーザー名

データベースへの接続に使用するデータベース・ユーザー名を入力します。

注意: DBAユーザーは、アップグレード・アシスタントを実行するのに十分な権限を付与されている必要がありますが、ユーザーはSYS/SYSDBA権限は必要ありません。現在、非SYSDBAユーザーを使用できます。

特定のデータベース・プラットフォーム上では、ユーザー名で大文字と小文字が区別され、DBAユーザー名が小文字で構成される場合があります。Upgrade Assistantは、ユーザーが入力した名前に接続します。ユーザー名を大文字に変換しません。

DBAパスワード

指定したDBAデータベース・ユーザーに対応するパスワードを入力します。

スキーマ・ユーザー名

ドロップダウン・リストからスキーマのユーザー名を選択するか、スキーマのユーザー名(DEV_MDSなど)を入力します。

すべてのデータベース・プラットフォーム上で、すべてのOracle Fusion Middlewareスキーマ名は大文字のみで構成されていることに注意してください。また、すべてのスキーマ名は、schema_version_registry表に大文字で格納されます。「スキーマ・ユーザー名」フィールドに小文字の文字が入力された場合、Upgrade Assistantは、その名前を大文字に変換します。

WebLogic Serverドメイン、UMSおよびVeridataスキーマの場合、11gスキーマのユーザー名およびパスワードを手動で入力する必要があります。

スキーマ・パスワード

特定のスキーマ・ユーザー名に関連付けられているパスワードを入力します。

エディション名

エディションベースの再定義に対応したOracle Databaseをデータベース・タイプとして選択する場合、既存のエディション名を指定する必要があります。

注意: EBR対応のスキーマをFusion Middleware 11gリリースから、または以前の12cリリースからアップグレードする前にまず、データベース・サーバーに接続し、12c (12.2.1)用にデータベース・サーバーでエディションを作成する必要があります。12.2.1用の新規エディションは、11.1.1.6.0、11.1.1.7.0、12.1.2または12.1.3エディションの子です。

エディション・ベースの再定義のためにサーバー上にエディションを作成する方法の詳細は、『Oracle Fusion Middlewareのアップグレードのプランニング』のエディション・ベースの再定義のためにサーバー上にエディションを作成する方法に関する項を参照してください。

3.11.12 インスタンス・ディレクトリ

OHSなどのシステム・コンポーネントをアップグレードする場合は、新しい12cコンポーネント・インスタンスを作成する開始点として使用する11gインスタンスのディレクトリの場所を指定する必要があります。

必要に応じて、「追加」ボタンを使用して、複数のインスタンスを含めます。

注意: Upgrade Assistantを使用してOracle 10gインスタンスをOracle 12cにアップグレードすることはできません。最初にOracle 10gインスタンスを11gにアップグレードする必要があります。10gから11gへの移行方法の詳細は、使用しているコンポーネントの11gのアップグレード・ドキュメントを参照してください。

図4-9 インスタンス・ディレクトリ

3.11.13 ノード・マネージャ

この画面を使用して、スタンドアロン・システム・コンポーネントのアップグレード時にドメインの作成に使用されるノード・マネージャの資格証明を指定します。

アップグレード時に、スクリーンショットに示されているフィールドが表示されない場合があることに注意してください。フィールドの表示をトリガーする条件は、次の表で説明します。

ユーザー名とパスワードは、ノード・マネージャとクライアントの間の接続の認証にのみ使用されます。これらは、サーバーの管理者IDおよびパスワードから独立しています。

図4-10 ノード・マネージャ

要素

説明

ユーザー名

ユーザー名はノード・マネージャへのアクセスに使用されます。

パスワード

ノード・マネージャへのアクセスに使用するパスワード。確認のためにパスワードを再入力する必要があります。

リスニング・アドレス

「リスニング・アドレス」フィールドには、ノード・マネージャがリスニングするDNS名またはIPアドレスを入力します。

リスニング・ポート

ノード・マネージャのリスニング・ポート番号。

3.11.14 OWSMポリシー・マネージャ

この画面を使用して、Oracle Web Services Manager (OWSM)ポリシー・マネージャをデプロイするWebLogic管理サーバー・ドメインの資格証明を入力します。

これはオプションの画面です。この画面は、クロス・ドメイン構成でOWSMがデプロイされている場合にのみ表示されます。

要素

説明

ホスト

ドメインの管理サーバーが実行されているホスト。

必ず完全なホスト名を指定します。次に例を示します。

fusionHost1.example.com

ポート

管理サーバーのリスニング・ポート。通常、管理サーバーはポート7001をリスニングします。

ユーザー名

管理サーバーへのログインに使用されるユーザー名。これは、ドメインの管理コンソールへのログインに使用するユーザー名と同じです。

パスワード

管理サーバーへのログインに使用される管理者アカウントのパスワード。これは、ドメインの管理コンソールへのログインに使用するパスワードと同じです。

図4-11 OWSMポリシー・マネージャ

3.11.15 ユーザー・メッセージング・サービスの構成

図4-12 ユーザー・メッセージング・サービスの構成

この画面を使用して、UMS 11g構成ファイルをホストするリモート管理対象サーバーのログイン資格証明を指定します。必要な前提条件をすべて満たし、次の表に説明されているように必要なログイン情報を指定した場合、アップグレード・アシスタントにより、リモート構成ファイルが自動的にコピーされます。

アップグレード実行中のマシン上でUMS構成ファイルにローカルにアクセスできない場合は、各管理対象サーバーのログイン資格証明を手動で入力する必要があります(ums_server1,ums_server2など)。

場合によっては、構成ファイルを、アップグレード実行中のマシン(多くの場合、AdminServerマシン)にコピーする必要があります。Upgrade Assistantはファイルをコピーしようとしますが、それらを見つけることができない場合、管理サーバーに手動でコピーする必要があります。

詳細は、『Oracle Fusion Middleware Infrastructureへのアップグレード』のUMS構成ファイルのコピーに関する項を参照してください。

ファイルを手動でコピーする必要があるのは、Upgrade Assistantが構成ファイルをコピーできないことを示すメッセージを受け取った場合のみです。ファイルをコピーしたら、Upgrade Assistantを再起動し、アップグレードを続行することができます。

要素

説明

ユーザー名

製品をインストールしたオペレーティング・システム・ユーザーを指定します。このユーザーは、リモート構成ファイルのフェッチに使用されます。

注意: このユーザーには、リモート管理対象サーバーがインストールされるノードにsshを介して接続する権限が必要です。

「ユーザー名」フィールドが表示されるのは、次のような場合です。

- 管理サーバーをホストしているローカル・マシン上または共有ディスク上に、管理対象サーバーの構成ファイルが見つからない

- UMSがターゲット指定されている12cドメイン内に複数の管理対象サーバーがある。

パスワード

このユーザーに関連付けられているパスワードを指定します。

管理対象サーバー

アップグレード・アシスタントが管理対象サーバーを自動的に検出できなかった場合、構成ファイルを含むリモート管理対象サーバーの名前を含むカンマ区切りリストを指定する必要があります。

例:

ums_server1、ums_server2

管理対象サーバー・アドレス

リモート管理対象サーバーを実行しているノードの完全なホスト名またはIPアドレスを含むカンマ区切りリストを指定します。このリストの順序は、上で指定された管理対象サーバー名のリストに対応する必要があります。

例:

fusionHost1.example.com,fusionHost2.example.com

説明:

fusionHost1.example.comはums_server1をホストし、fusionHost2.example.comはums_server2をホストします

3.11.16 調査

図4-13 調査

Upgrade Assistantは、アップグレード・プロセスを開始する前に各コンポーネントを調査し、最低基準を満たしていることを確認します。

この画面には、各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを検証するUpgrade Assistantのステータスが表示されます。

Upgrade Assistantは、アップグレード・プロセスを開始する前に各コンポーネントを調査し、最低基準を満たしていることを確認します。

この画面には、スキーマのスキーマ・ソース・バージョンが表示されます(情報がスキーマ・バージョン・レジストリ表にリストされている場合)。スキーマがRCUを使用して作成されたものではない場合、またはソース・バージョンが見つからない場合、ソース・バージョンは「使用不可」と表示されます。

注意:
調査フェーズで検出されたエラーは修正可能で、アップグレード・アシスタントを再起動できます。ただし、アップグレード・フェーズが開始されてからは、アップグレード前の環境をバックアップからリストアし、アップグレード・アシスタントをもう一度開始する必要があります。

コンポーネントの「ステータス」インジケータの説明は、次の表にあります。

ステータス

説明

進行中

Upgrade Assistantがコンポーネントのアップグレード項目を調査しています。

保留中

コンポーネントは、Upgrade Assistantが前のコンポーネントの処理を終了した後で調査されます。

失敗

アップグレード項目が欠落しているか、アップグレード基準を満たしていません。アップグレード・アシスタントは、問題が解決されるまでコンポーネントをアップグレードできません。「ログの表示」をクリックしてエラーのトラブルシューティングを行い、アップグレード・アシスタントを再起動します。

成功

アップグレード項目が検出され、アップグレードに対して有効です。

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

3.11.17 調査失敗

図4-14 調査失敗

このダイアログ・ボックスは、1つ以上のコンポーネントが調査フェーズに失敗し、アップグレードを継続することを選択した場合に表示されます。調査失敗が発生した場合、アップグレードを取り消して(「いいえ」をクリック)、ログ・ファイルを確認することを検討してください。アップグレードは開始されていないため、調査フェーズで検知された問題を解決して、バックアップからリストアせずにアップグレード・アシスタントを再起動することができます。

UMSアップグレードのみ:

構成アップグレードで、調査フェーズの最中にこのエラーが発生します。ユーザー・メッセージング・サービスでは、これをリカバリするには、UMS構成ファイルを手動でコピーし、アップグレード・アシスタントを再起動します。

エラーがアップグレード・フェーズ中に発生した場合、リカバリするには、バックアップをリストアし、構成ファイルを手動でコピーして、アップグレード・アシスタントを再起動します。

3.11.18 アップグレード・サマリー

図4-15 アップグレード・サマリー

アップグレード・サマリーの確認

ツリーを展開または縮小して、ウィザードの画面で提供されるデータの詳細(スキーマの詳細、Oracle WebLogic Server接続の詳細、Oracle WebLogicドメイン・ディレクトリ情報など)を表示または非表示にします。

サマリー画面には、アップグレードするスキーマのソース・バージョンとアップグレード後の結果のターゲット・バージョンも表示されます。アップグレードに進む前に、両方のバージョンが正しいことを確認してください。

アップグレード・プロセスの開始

「アップグレード」をクリックして、アップグレード・プロセスを開始します。

スキーマをアップグレードする場合は、そのスキーマをホストしているデータベースのバックアップがあることを確認してください。

レスポンス・ファイルの保存

「レスポンス・ファイルの保存」オプションにより、Upgrade Assistantへの入力として使用できるファイルが作成されます。このレスポンス・ファイルは、Upgrade Assistantのグラフィカル・ユーザー・インタフェース画面で入力したすべての情報を収集し、後でサイレント・アップグレードを実行することができます。サイレント・アップグレードは、Upgrade Assistantウィザードとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。

3.11.19 アップグレードの進行状況

図4-16 アップグレードの進行状況

この画面には、現在のアップグレード・プロセスの状況と、アップグレードが成功した後のコンポーネントの予測ターゲット・バージョンが表示されます。

進捗バーはアップグレードの残り時間を示す尺度ではないことに注意してください。進捗バーは、アップグレードされている各コンポーネントの完了したアップグレード・ステップを示す、変動するグラフ表示です。進捗バーが一定のペースで変動しない場合もあります。進捗バーの特定の部分が非常に速く変動することがあります。また、長い時間がかかるデータベース操作を実行している別のコンポーネントでは、非常に遅く変動したり、フリーズしたように見えることもあります。これは、アップグレードの進行状況が止まっていることを意味するのではなく、単に長い時間がかかる操作が実行されていることを示しているだけです。(特にスキーマ・アップグレードの間は)様々なアップグレード操作が異なるペースで実行されます。

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

各コンポーネントのアップグレードのステータスは、コンポーネント名の隣に表示される次のメッセージのいずれかで示されます。次の表で、各ステータス・メッセージを説明します。

ステータス

説明

進行中

Upgrade Assistantがコンポーネントのアップグレード項目をアップグレードしています。

保留中

コンポーネントは、Upgrade Assistantが先行するコンポーネントを終了してからアップグレードされます。

アップグレード不要

コンポーネントは以前にUpgrade Assistantでアップグレードされているか、コンポーネントはインストールされたばかりで、すでに最新バージョンになっています。このコンポーネントではアクションは実行されません。

スキップ済

コンポーネントは、ステータスが「失敗」の別のコンポーネントに依存しています。ステータスが「スキップ済」のコンポーネントに対するアップグレードは試行されません。

失敗

アップグレード項目が欠落しているか、アップグレード基準を満たしていません。コンポーネントをアップグレードできません。「ログの表示」をクリックすると、エラーのトラブルシューティングを行えます。

成功

アップグレード項目は正常にアップグレードされました。

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

3.11.20 アップグレード成功

図4-17 アップグレード成功

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

また、次の手順も実行してください。

- Oracleホームのpostupgrade.txtファイルを表示します。
UNIXシステムの場合:

ORACLE_HOME/oracle_common/upgrade/logs

Windowsシステムの場合:

ORACLE_HOME\oracle_common\upgrade\logs

- その他のアップグレード後のタスクの詳細は、ご使用のOracle Fusion Middleware環境に固有のアップグレードの項を参照してください。

3.11.21 アップグレード失敗

図4-18 アップグレード失敗

1つ以上のコンポーネントのアップグレードに失敗しました。今行った操作では、コンポーネントをアップグレードできません。「ログの表示」をクリックすると、エラーのトラブルシューティングを行えます。

アップグレード・アシスタントを起動する前に、アップグレード前環境の問題を修正する必要があります。バックアップからアップグレード前環境をリストアして(元のバックアップ・ファイルが別の場所に保存されていることを確認)、問題を修正し、アップグレード・アシスタントを再起動します。

3.11.22 アップグレードの取消

図4-19 アップグレードの取消

アップグレード・プラグインがアクティブに実行されている(つまり、アップグレード・ページが表示されていて、進捗バーが100%未満である)間に「取消」をクリックすると、前述の「取消の確認」画面が表示されます。

図4-20 アップグレードの取消

アクティブに実行されているアップグレード・プラグインがない場合、「取消」をクリックすると、前述の「取消の確認」画面が表示されます。

重要な注意: スキーマのアップグレードを取り消す場合は、スキーマとその環境(アップグレード前のディレクトリ構造)をホストするデータベースのバックアップをリストアする必要があります。

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

再構成ウィザードを使用して既存の11gドメインを再構成するには、この項の手順に従います。

- タスク1: 再構成ウィザードの起動

- タスク2: ドメインの再構成

3.12.1 タスク1: 再構成ウィザードの起動

次の手順を実行して、再構成ウィザードをグラフィカル・モードで起動します。

1. ドメインが存在するシステムにログインします。

2. コマンド・シェル(UNIXオペレーティング・システムの場合)またはコマンド・プロンプト・ウィンドウ(Windowsオペレーティング・システムの場合)を開きます。

3. エディション・ベースのデータベース・ユーザーのみ: スキーマがEBRデータベースを使用して構成されている場合、再構成ウィザードを実行する前に、手動でデフォルトのエディション名を設定する必要があります。

次のSQLコマンドを実行して、デフォルト・エディションを設定します。

ALTER DATABASE DEFAULT EDITION = edition_name;

ここで、edition_nameは、デフォルトのデータベース・エディション名の名前です。

4. 次のディレクトリに移動します。

(UNIX) ORACLE_HOME/oracle_common/common/bin

(Windows) ORACLE_HOME\oracle_common\common\bin

ORACLE_HOMEはOracleホーム・ディレクトリです。

5. 次のコマンドを実行します。

(UNIX) ./reconfig.sh -log=log_file
(Windows) reconfig.cmd -log=log_file

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

注意:

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

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

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

CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

3.12.2 タスク2: ドメインの再構成

再構成ウィザードには、表3-3に示すような一連の画面が表示されます。

選択するオプションによっては、表3-3に示されているすべての画面が表示されない場合もあります。一部の拡張構成では、追加の画面が表示されます。拡張構成の詳細は、オンライン・ヘルプを参照してください。

『Oracle WebLogic Serverのアップグレード』のWebLogicドメインの再構成に関する項に記載されている、完全な再構成プロセスを確認します。

表3-3 再構成ウィザードの画面

画面

説明および必要なアクション

ドメインの選択

既存の11gドメイン・ディレクトリの絶対パスを入力するか、「参照」をクリックしてドメイン・ディレクトリを選択します。

再構成セットアップの進行状況

再構成テンプレートのアプリケーションの進行状況を表示します。

ドメイン・モードおよびJDK

ドメイン・モードは変更できません。

ドメインで使用するJDKを選択するか、「参照」をクリックして使用するJDKに移動します。

Oracle Fusion Middleware 12cにはJava SE 7が必要であることに注意してください。詳細は、『Oracle Fusion Middlewareのインストールのプランニング』の動作保証とシステム要件の検証に関する項を参照してください。

JDBCデータ・ソース

この画面は、11gでデータベースベースのOPSSセキュリティ・ストアまたは監査データ・ストア用にカスタム・データ・ソースを作成していた場合に表示されます。

この画面では、ドメイン・ソースに定義されているJDBCデータ・ソースを確認します。

このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のJDBCデータ・ソースに関する項を参照してください。

JDBCデータ・ソース・テスト

「JDBCデータ・ソース」画面で構成したデータ・ソース接続をテストします。

このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のJDBCデータ・ソースのテストに関する項を参照してください。

データベース構成タイプ

前の画面でデータ・ソース接続の詳細を指定した場合は、データベース接続の詳細が自動的に入力されます。

この画面で情報が入力されない場合は、「RCUデータ」を選択してデータベース資格証明を指定して、ドメインに含まれているすべての12.1.2スキーマのスキーマ情報を取得します。このオプションを選択すると、この画面のフィールドがアクティブになります。Repository Creation Utility (RCU)のSTBコンポーネントに指定した接続情報を使用して、各フィールドに入力します。

接続情報を入力した後、「RCU構成の取得」をクリックしてスキーマ情報を取得します。

詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のデータベース構成タイプに関する項を参照してください。

JDBCコンポーネント・スキーマ

デフォルトでは、前の画面で「RCUデータの取得」を選択し、すべてのスキーマの所有者が同じ場合、スキーマ情報が表示されます。

画面に表示されたスキーマのデータ・ソース設定を変更する場合は、各スキーマ名の横のチェック・ボックスを選択します。画面の上部のフィールドで変更を行うと、下部で選択しているスキーマが更新されます。変更するスキーマのみを選択してください。

注意:

- 11gスキーマの詳細を指定する必要があります。

- このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のJDBCコンポーネント・スキーマに関する項を参照してください。

JDBCコンポーネント・スキーマ・テスト

前の画面でデータ・ソースに指定した構成をテストします。テストするスキーマ名の横のチェック・ボックスを選択し、「選択された接続のテスト(T)」をクリックします。

テストの結果は、「ステータス」列に表示されます。すべてのスキーマでテストに成功した場合、「次へ」をクリックします。

ノード・マネージャ

この画面は、再構成するドメインで、ドメインごとのデフォルトの場所のノード・マネージャが使用されている場合にのみ表示されます。

「既存の構成を移行」を選択して、ドメインごとのデフォルトの場所の場所を指定します。

「Oracle推奨デフォルトの適用」を有効にします。

「ノード・マネージャ資格証明」を指定します。これは、ノード・マネージャを管理するために作成される、新しい「ユーザー」です。ノード・マネージャにより処理されるコンポーネントには、起動時にパスワードが要求されます(OHSを含む)。

注意: ドメインをアップグレードしてホストごとのノード・マネージャ構成からドメインごとのノード・マネージャ構成に変更する際に、カスタム・スクリプトを使用してWebLogic Server環境を起動および停止する場合、手動でスクリプトを更新してノード・マネージャ・ホームの場所を新しいドメインベースの場所に変更する必要があります。

ノード・マネージャの構成の詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のデフォルトのノード・マネージャの構成に関する項を参照してください。

拡張構成

詳細構成を行うすべてのカテゴリ(存在する場合)を選択します。選択したカテゴリごとに、詳細構成を行うことができる適切な構成画面が表示されます。この画面で項目を選択しない場合は、「構成のサマリ」画面が次に表示されます。

次に表示される画面は、選択するカテゴリに応じて異なります。各画面の詳細は、オンライン・ヘルプを参照してください。

注意: ノード・マネージャが使用可能な場合に選択しないときは、『Oracle WebLogic Serverのアップグレード』のノード・マネージャ構成の実行に関する項の説明に従って、ノード・マネージャを手動で構成する必要があります。

ノード・マネージャの詳細オプションは、ホストごとのノード・マネージャ構成を使用中のドメインを再構成する場合にのみ使用できます。ドメインごとのノード・マネージャ構成に切り替えることも、すでに存在する既存のノード・マネージャの使用を続行することも可能です。

構成のサマリー

続行する前にドメインの詳細な構成設定を確認します。「表示」ドロップダウン・リストからフィルタ・オプションを選択することで、右端のパネルに表示されるアイテムを限定できます。

構成を変更する必要がある場合は、「戻る」をクリックして適切な画面に戻ります。

「再構成」をクリックしてドメインを再構成するか、構成を変更する場合は「戻る」をクリックします。

再構成の進行状況

再構成の進行状況を確認します。処理が完了したら「次へ」をクリックします。

再構成に成功しました

再構成処理の最終的なステータスを確認します。「終了(F)」をクリックして再構成ウィザードを終了します。

3.13 アップグレード・アシスタントを使用したドメイン・コンポーネント構成のアップグレード

アップグレード・アシスタントを使用して追加のドメイン・コンポーネント構成(OWSMポリシー・メタデータ構造およびアダプタ構成など)をアップグレードするには、この項の手順に従います。

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

- タスク2: コンポーネント構成のアップグレード

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

次の手順を実行して、管理サーバーが実行されているホストでアップグレード・アシスタントを起動します。

1. ディレクトリをORACLE_HOME/oracle_common/upgrade/bin (UNIXオペレーティング・システムの場合)またはORACLE_HOME\oracle_common\upgrade\bin (Windowsオペレーティング・システムの場合)に変更します。

2. 次のコマンドを入力してアップグレード・アシスタントを起動します。

(UNIX) ./ua

(Windows) .\ua.bat

3.13.2 タスク2: コンポーネント構成のアップグレード

WebLogicコンポーネント構成のアップグレード時、アップグレード・アシスタントでは表3-4 に示す一連の画面が表示されます。各画面でそれぞれの操作を実行します。

表3-4 アップグレード・アシスタント画面: WebLogicコンポーネント構成のアップグレード

画面

説明および必要なアクション

ようこそ

この画面では、アップグレード・アシスタントの概要と、アップグレード前の重要なタスクについての情報が示されます。

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

WebLogicコンポーネント

「WebLogicコンポーネント構成」を選択します。

管理対象WebLogic Serverドメインのコンポーネント構成をアップグレードするには、「WebLogicコンポーネント構成」オプションを選択します。アップグレードするドメインのドメイン・ディレクトリを入力してください。

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

コンポーネント・リスト

この画面では、ドメインのコンポーネント構成アップグレードに含められるコンポーネントのリストが提供されます。

前提条件

コンポーネント構成アップグレードの前提条件が満たされているかどうかを確認します。

UMS構成

この画面を使用して、UMS 11g構成ファイルをホストするリモート管理対象サーバーのログイン資格証明を指定します。必要な前提条件をすべて満たし、必要なログイン情報を指定した場合、アップグレード・アシスタントにより、リモート構成ファイルが自動的にコピーされます。

注意: UAにより管理対象サーバーまたは構成ファイルを特定できない場合は、手動でファイルをコピーしてからアップグレード・アシスタントを再起動する必要があります。詳細は、「アップグレード・アシスタント: UMS構成ファイルのコピーを参照してください。

調査

各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを検証するアップグレード・アシスタントのステータスを確認します。

アップグレード・サマリー

スキーマ・アップグレードのために選択したオプションのサマリーを確認します。

「アップグレード」をクリックしてスキーマをアップグレードするか、構成を変更する場合は「戻る」をクリックします。

アップグレードの進行状況

アップグレード処理のステータスを確認します。

アップグレードが完了したら「次へ」をクリックします。

アップグレード成功

アップグレードが成功していれば「閉じる」をクリックします。

アップグレードが失敗した場合または正常に完了する前にアップグレードを取り消した場合は、ログ・ファイルを確認してバックアップ環境をリストアし、アップグレード・アシスタントを再起動する必要があります。

3.14 Infrastructureアップグレードのトラブルシューティング

Infrastructureアップグレード時にエラーが発生した場合は、次の項目を参照してください。

- 再構成ウィザード: WebLogic Serverドメインのアップグレード・プロセス

- アップグレード・アシスタント: 認証失敗 - JSch例外: 認証失敗

- アップグレード・アシスタント: UMS構成ファイルのコピー

注意:

大半のFusion Middlewareエラーと同様、調査フェーズで検出されたエラーは修正可能であり、アップグレード・アシスタントの実行を継続できます。しかし、アップグレード・フェーズで発生したエラーは、リストア済のバックアップ・ファイルを使用して修正する必要があり、アップグレード・プロセスは最初からやりなおす必要があります。アップグレード・フェーズでエラーの発生したアップグレードを、再実行しないでください。その環境は不安定だとみなして、アップグレード前の状態にリストアする必要があります。

詳細は、『Oracle Fusion Middleware Upgrade Assistantによるアップグレード』の一般的なトラブルシューティングのガイドラインに関する項を参照してください。

3.14.1 再構成ウィザード: WebLogic Serverドメインのアップグレード・プロセス

ドメインの再構成時にエラーが発生した場合は、『Oracle WebLogic Serverのアップグレード』のドメインのアップグレード・プロセスに関する重要な注意事項に関する項を参照してください。

3.14.2 アップグレード・アシスタント: 認証失敗 - JSch例外: 認証失敗

アップグレード・アシスタントを実行してWeblogicコンポーネント構成をアップグレードする際に、UMSサーバーに不適切なログイン資格証明を指定した場合、UAのログ・ファイルに次のような例外が記載されます。

[upgrade.UCSUMS.UCSUMS_CONFIGURATION_PLUGIN] [tid: 110] [ecid:
88ab893d-a523-4a83-b5a6-f7b1cf8cb029-00000001,0] [[
com.jcraft.jsch.JSchException: Auth fail

このエラーの解決方法は、エラーが発生した時点に応じて異なります。

調査フェーズ (アップグレード・フェーズの前)でこのエラーが発生した場合: すべての管理対象サーバーおよびディレクトリに対して入力したユーザー名およびパスワードが有効であること、および指定したユーザー名にssh権限があることを確認します。エラーを修正した後、接続を再試行します。

アップグレード・フェーズでエラーが発生した場合、アップグレード操作は正常に行われておらず、バックアップからファイルをリストアして、アップグレードをやりなおす必要があります。要求に従って、適切なログイン資格証明を入力していることを確認してください。

注意:

アップグレード・フェーズで発生したエラーは非リエントラントであり、エラーを修正してアップグレードを続行することはできません。「アップグレード」をクリックした後でエラーが発生した場合は、アップグレード・プロセスをやりなおす前に、バックアップから環境をリストアする必要があります。

3.14.3 アップグレード・アシスタント: UMS構成ファイルのコピー

アップグレード・アシスタントでUMS構成ファイルの自動コピーに失敗した場合は、UMSをアップグレードする前に、アップグレードを停止して構成ファイルを手動でコピーする必要があります。

注意:

この手順は、アップグレード・アシスタントで構成ファイルの自動コピーが失敗した場合、または構成ファイルを手動でコピーした場合のみ必要です。

この項では、User Messaging Service (UMS)を11gから12cにアップグレードする際にリモートの管理対象サーバー・ノードから管理サーバーにコピーされる、UMS構成ファイルの場所について説明します。必要な前提条件をすべて満たし、必要なログイン情報を指定した場合、リモート構成ファイルは、アップグレード・アシスタントにより自動的にコピーされます。アップグレード・アシスタントによる構成ファイルのコピーに関する詳細は、『Oracle Fusion Middleware Upgrade Assistantによるアップグレード』を参照してください。

ただし、アップグレード・アシスタントでファイルの場所を特定できない場合は、リモートの管理対象サーバーからアップグレードを実行している管理サーバー上の同じ場所に、構成ファイルをコピーする必要があります。コピーする必要がある構成ファイルには、UMSサーバー構成ファイル(appconfig.xml)、ドライバの構成ファイル(driverconfig.xml)およびユーザー・プリファレンス・ファイル(businessterms.xml)などがあります。これらのファイルは、表3-5 に示されているように、各管理対象サーバーの/applicationsフォルダに置かれています。

管理対象サーバーから管理サーバーに構成ファイルを手動でコピーした後、「アップグレード・アシスタントを使用したドメイン・コンポーネント構成のアップグレード」に記載されている手順に従って、アップグレード・アシスタントを起動しなおす必要があります

表3-5 構成ファイルの場所

構成ファイル

場所

UMSサーバー(appconfig.xml)

<DOMAIN_HOME>/config/fmwconfig/servers/<MANAGED_SERVER_NAME>/applications/usermessagingserver/configuration/appconfig.xml

ドライバの構成(driverconfig.xml)

<DOMAIN_HOME>/config/fmwconfig/servers/<MANAGED_SERVER_NAME>/applications/usermessagingdriver-<DRIVER_NAME>/configuration/driverconfig.xml

ユーザー・プリファレンス(businessterms.xml)

<DOMAIN_HOME>/config/fmwconfig/servers/<MANAGED_SERVER_NAME>/applications/usermessagingserver/configuration/businessterms.xml

注意:

ドメイン内に複数のドライバがデプロイされている場合は、すべてのドライバの構成ファイルをコピーしていることを確認してください。<DRIVER_NAME>を、ドメインにデプロイされているすべてのドライバ名で置き換えて確認します。

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

Oracle Fusion Middleware 11g Application DeveloperをOracle Fusion Middleware 12c Infrastructureにアップグレードした後に、「アップグレード後に実行するタスク」の説明に従ってアップグレード後のタスクを完了する必要があります。

4 前のリリースから12cへのアップグレード

この章では、前のOracle Infrastructure 12cリリースからOracle Infrastructure 12c (12.2.1)へのアップグレードのプロセスについて説明します。

この章のトピックは、次のとおりです:

注意:

この章に記載されたタスクは、既存のInfrastructure 12cリリースからInfrastructure 12c (12.2.1)リリースにアップグレードする場合にのみ適用されます。11g環境を12c (12.2.1)にアップグレードする場合は、「Infrastructureアップグレードの実行」に記載されている手順を使用してください。

4.1 アップグレード前に必要なタスクの実行

Infrastructure 12cにアップグレードした場合は、「Infrastructureアップグレードの実行」で、アップグレード前の手順を、アップグレードの開始前に完了するよう指示されています。それらの手順を完了していることを確認してください。

アップグレード前の手順のほとんどは11gからのアップグレードに適用されますが、一部の手順(既存の環境のバックアップなど)はここでも適用され、アップグレードを正常に完了するためには不可欠な手順です。次のリストに、既存の12c Infrastructureをアップグレードする前に完了する必要のある、アップグレード前の手順を示しています。

- Infrastructureの必要なアップグレード前タスクの完了
アップグレードに取り掛かる前に、必ず現行の環境の完全バックアップを作成してください。アップグレードに関して問題が発生した場合、環境をリストアして、アップグレード・プロセスを最初からやりなおす必要がある場合があります。

- APPHOSTへのOracle Fusion Middleware Infrastructureのインストール
アップグレードを開始する前に、12c Infrastructureディストリビューションをインストールする必要があります。

- Oracle HTTP Serverのインストール
12cドメインに、そのドメインに関連付けられたOracle HTTP Serverインスタンスが含まれる場合、Oracle HTTP Server 12cにアップグレードする必要があります。

- サーバーとプロセスの停止
12cのアップグレードは、完全なオフラインで行います。アップグレードを開始する前に、すべての12cサーバーおよびプロセスが停止していること確認してください。

4.2 スキーマのアップグレードでのアップグレード・アシスタントの使用

アップグレード・アシスタントでは、アップグレード・スキーマの2つのオプションが使用できます。

- 個別に選択されたスキーマ
このオプションにより、アップグレードするコンポーネント・スキーマを選択できます。アップグレードしないコンポーネント・スキーマがドメイン内にある場合、このオプションを選択します。たとえば、ドメインの外部にあるRCUにスキーマを作成してアップグレード・アシスタントを試験的に実行する場合、アップグレード・アシスタントを使用してそれらをアップグレードします。

または

- ドメインで使用されるすべてのスキーマ
この新しいオプションにより、アップグレード・アシスタントは、指定されたドメイン内の使用可能なスキーマをすべて検知し、それらをアップグレードに含めることができます。

4.3 Upgrade Assistantでアップグレードできるスキーマの識別

Upgrade Assistantは、アップグレードできるすべてのスキーマを識別して、すべてのスキーマをアップグレードに含める、またはアップグレードするスキーマをユーザー側で選択できます。アップグレードを開始する前に、アップグレード可能なスキーマのリストを確認するには、スキーマ・バージョンのレジストリを検索します。

ヒント:

スキーマ・バージョンのレジストリから収集した情報と、スキーマを比較して、ドメイン内にアップグレード可能なスキーマがまだあるかどうかを判別します。

Oracleデータベースを使用している場合は、Oracle DBAロールを持つ任意のユーザーとしてデータベースに接続し、SQL*Plusから次の文を実行して現在のバージョン番号を取得します。SQLスクリプト(version.sqlなど)に保存されると、次のレポートが生成されます。

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の数値が11.1.1.6.0以上で、STATUS列が「VALID」であれば、そのスキーマはアップグレードでサポートされます。

あるスキーマではアップグレードの必要がないと判断した場合、schema_version_registry表には、12.2.1アップグレード後もアップグレード前のバージョンでそのスキーマが保持されます。

アップグレードが必要なスキーマに関する注意:

- ほとんどのコンポーネントで、更新できるスキーマ・バージョン開始点は、11gリリース1 (11.1.1.6、11.1.1.7、11.1.1.8または11.1.1.9)または12c (12.1.2または12.1.3)のみです。スキーマが、サポートされているバージョンでない場合、12c (12.2.1)のアップグレード手順を使用する前に、それらをアップグレードする必要があります。
Oracle Enterprise Data QualityやOracle Golden Gate Veridataなど、一部のコンポーネントでは、サポートされている標準的なOracle Fusion Middlewareバージョン以外のバージョンからのアップグレードがサポートされています。

- アップグレードに必要なスキーマに関する追加情報は、コンポーネント固有のインストールおよびアップグレードのドキュメントを参照してください。

- 11gでファイルベースのポリシー・ストアを使用していた場合、Upgrade Assistantを実行する前に、ファイルベースのポリシー・ストアをデータベースベースのセキュリティ・ストアに再度関連付ける必要があります。詳細は、「アップグレード前のファイルベースのポリシー・ストアの再関連付け」を参照してください。

- 11gでOIDベースのポリシー・ストアを使用していた場合は、アップグレード前に新しい12c OPSSスキーマが作成済であることを確認してください。

- Oracle Fusion Middleware 12c (12.2.1)リリースでアップグレード可能な製品のスキーマのみをアップグレードできます。まだ12c (12.2.1)へのアップグレードが可能になっていないコンポーネントを含むドメインをアップグレードしないでください。

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

アップグレード・アシスタントは、Oracle Universal Installer (OUI)により、Fusion Middleware Oracleホームのoracle_common/upgrade/binディレクトリにインストールされます。

グラフィカル・ユーザー・インタフェースを使用してUpgrade Assistantを起動するには、Middleware製品がインストールされているOracleホームのoracle_commonディレクトリに移動します。

他のドメインのアップグレードを開始する前に、単一のドメインのスキーマのアップグレードおよびコンポーネント構成を正常に完了させることをお薦めします。

注意:
アップグレード・アシスタントは、可能なかぎり、非SYSDBAユーザーにより実行する必要があります。非SYSDBAユーザーを作成する手順は、アップグレード前チェックリストで説明します。

1. ディレクトリを、UNIXオペレーティング・システムではORACLE_HOME/oracle_common/upgrade/binに、Windowsオペレーティング・システムではORACLE_HOME\oracle_common\upgrade\binに変更します。

2. 次のコマンドを入力してアップグレード・アシスタントを起動します。

UNIXオペレーティング・システムの場合:

./ua

Windowsオペレーティング・システムの場合:

ua.bat

Upgrade Assistantの各画面で必要な情報を指定します。表示される画面は、選択するアップグレードのタイプによって異なります。次の項では、アップグレード・オプションおよび入力する必要がある情報を説明します。

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

いずれかのスキーマを持つコンポーネントが含まれているOracleホームからUpgrade Assistantを実行する場合、「スキーマ」アップグレード・オプションが表示されます。Upgrade Assistantにより、スキーマのアップグレード候補のコンポーネントのみがリストされます。コンポーネント・リストからアップグレードするスキーマを選択できます。

アップグレード・アシスタントに次の画面が表示されます。

注意:

表示される画面は、選択するオプションによって異なります。

表4-2 Upgrade Assistant画面: スキーマのアップグレード

画面

画面が表示される状況

説明

ようこそ

常時。

この画面では、アップグレード・アシスタントの概要と、アップグレード前の重要なタスクについての情報が示されます。

スキーマ

常時。

この画面を使用して、実行するスキーマ・アップグレード操作を選択します。画面のオプションは、オブジェクトションごとに変化します。

- 個別に選択されたスキーマ

- ドメインで使用されるすべてのスキーマ

使用可能なコンポーネント

「個別に選択されたスキーマ」が選択されている時。

この画面では、アップグレード可能なスキーマがあるインストール済のOracle Fusion Middlewareコンポーネントのリストが提供されます。コンポーネントを選択すると、スキーマとすべての依存関係が自動的に選択されます。

「すべてのスキーマ」のコンポーネント・リスト

「ドメインで使用されるすべてのスキーマ」が選択されている時。

この画面は読取り専用で、指定されたドメイン・ディレクトリで検知され、アップグレードに含められるすべてのコンポーネントおよびスキーマが表示されます。

前提条件

常時。

この画面では、アップグレードを続行する前にすべての前提条件が満たされていることを確認する必要があります。続行する前にボックスを確認してください。

スキーマ資格証明画面

常時。

この画面を使用して、選択したスキーマとそのスキーマをホストするデータベースへの接続に必要な情報を入力します。

画面名は、選択したスキーマ・タイプによって変わります(例: MDSスキーマ)。

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

調査

常時。

この画面には、各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを検証するUpgrade Assistantのステータスが表示されます。

注意:
調査フェーズで検出されたエラーは修正可能で、バックアップからリストアする必要はありません。

アップグレード・サマリー

常時。

この画面を使用して、選択したオプションのサマリーをレビューし、アップグレード・プロセスを開始します。

アップグレードの進行状況

常時。

この画面には、アップグレード処理のステータスが表示されます。

アップグレード成功

または

アップグレード失敗

常時。

アップグレードが成功しました。新規インストールでコンポーネントを機能させるために手動で実行する必要のあるタスクが、アップグレード後のアクションのウィンドウに表示されます。

または

特定のコンポーネントのアップグレードが失敗したため、Upgrade Assistantを再起動する必要があります。

注意: UAのログは、<OH>/oracle_common/upgrade/logsに移入されます。

注意:
アップグレードに失敗した場合、アップグレード前の環境をバックアップからリストアし、問題を解決して、アップグレード・アシスタントを再度起動する必要があります。ファイルが変更されているため、単に問題を解決して、アップグレード・アシスタントを再起動することはできません。

SOA SuiteおよびBPMのアップグレードのみの場合:

クローズされているアクティブなSOAインスタンス・データの12c (12.2.1)へのアップグレードは、Upgrade AssistantでのSOAスキーマ・アップグレード・プロセスの一部として自動的に行われます。詳細は、「SOAインスタンス・データのアップグレードの管理と監視」を参照してください。

4.6 アップグレード・アシスタント画面

この項では、すべてのアップグレード・アシスタント画面について説明します。

注意:

Oracle Fusion Middlewareアップグレード・アシスタントの使用時に表示される画面は、アップグレードするOracle Fusion Middlewareソフトウェアのタイプにより異なります。すべての画面が表示されるのではありません。

4.6.1 ようこそ

Oracle Fusion Middlewareアップグレード・アシスタントを使用して、コンポーネント・スキーマ、コンポーネント構成およびスタンドアロン・システム・コンポーネント構成をFusion Middleware 11gおよび12cリリースからFusion Middleware 12cリリースにアップグレードします。

4.6.2 スキーマ

インストールされたコンポーネントで選択されたスキーマをアップグレードするには、「個別に選択されたスキーマ」を選択します。アップグレード・アシスタントによりスキーマ・アップグレードの候補になるコンポーネントが識別され、ユーザーはアップグレードに含めるスキーマを選択できます

注意: 12.2.1.0.0コンポーネントをサポートするために使用されるスキーマのみをアップグレードしてください。Oracle Fusion Middleware 12.2.1リリースに含まれていない11gまたは12cコンポーネントをサポートするために現在使用されているスキーマをアップグレードしないでください。

図4-1 個別に選択されたスキーマ

4.6.3 ドメインで使用されるすべてのスキーマ

リリース12.2.1では、Oracle Fusion Middlewareアップグレード・アシスタント(UA)は、特定のドメインで使用されるすべてのスキーマをアップグレードするオプションを提供します(ドメイン補助スキーマ・アップグレードまたはDASUと呼ばれることもあります)。「ドメインで使用されるすべてのスキーマ」が選択されている場合、アップグレード・アシスタントはアップグレード可能なスキーマがあるすべてのコンポーネントを検索し、選択します。加えて、可能なかぎり、アップグレード・アシスタントは接続情報をスキーマ入力画面に事前移入します。

4.6.4 ドメインによって使用されるすべての構成

管理対象WebLogic Serverドメインのコンポーネント構成をアップグレードするには、「ドメインによって使用されるすべての構成」オプションを選択します。「参照」をクリックし、ナビゲーション・ツリーを使用して有効なドメイン・ディレクトリを選択します。ドメイン・ディレクトリには、config.xmlファイルを含むconfigディレクトリが含まれます。

4.6.5 スタンドアロン・コンポーネント

Oracle HTTP Server (OHS)などのスタンドアロン・システム・コンポーネントをアップグレードする場合は、「スタンドアロン・システム・コンポーネント構成」オプションを選択します。

次のいずれかを選択するように求めるプロンプトが表示されます。

オプション

説明

新規ドメインの作成

12cでは、スタンドアロン・システム・コンポーネントには、個別のスタンドアロン・ドメインが作成されます。スタンドアロン・ドメインは、Oracle HTTP Serverなどのシステム・コンポーネントのコンテナです。このディレクトリ構造は、Oracle WebLogicドメインのディレクトリ構造と同様ですが、管理サーバーまたは管理対象サーバーを含みません。これは、Oracle HTTP Serverなど同じタイプのシステム・コンポーネントのインスタンスを1つ以上含めたり、異なるタイプを組み合せて含めることができます。

構成ウィザード、packおよびunpackコマンド、WLSTおよびノード・マネージャなどの管理ツールは、スタンドアロン・ドメイン上で実行できます。

既存のドメインの更新

システム・コンポーネントにスタンドアロン・ドメインが作成された後、このオプションを選択して、別のスタンドアロン・システム・コンポーネントにそのドメインを拡張できます。このオプションは、12.1.2または12.1.3.からアップグレードする場合も使用されます。

既存の12cドメインの場所を指定する必要があります。

4.6.6 使用可能なコンポーネント

「個別に選択されたスキーマ」オプションを前の画面で選択し、アップグレードするスキーマを個別に選択すると、ドメインで使用されるすべてのスキーマをアップグレードするかわりに、この画面にアップグレード可能なスキーマのコンポーネントが表示されます。他のスキーマが必要なコンポーネントを選択すると、アップグレード・アシスタントは自動的にこれらのスキーマを選択します。

図4-2 アップグレード可能な構成またはスキーマ(あるいはその両方)のコンポーネントのリスト

4.6.7 「すべてのスキーマ」のコンポーネント・リスト

「ドメインで使用されるすべてのスキーマ」を選択すると、この画面にWebLogicドメインのアップグレードに含められるスキーマのリストが表示されます。コンポーネントの名前は、ドメイン内にあるスキーマとともに表示されます。

リストを注意深くレビューして、正しいスキーマがアップグレードされることを確認してください。アップグレードする対象のコンポーネントまたはスキーマが表示されない場合、選択したドメインが正しくない可能性があります。別のドメインを指定するには「戻る」ボタンを使用します。

含めることを望まないコンポーネントまたはスキーマがリストにある場合、「すべてのスキーマ」画面に戻り、「ドメインで使用されるすべてのスキーマ」ではなく、「個別に選択されたスキーマ」を選択します。「個別に選択されたスキーマ」オプションを使用すると、アップグレードに含めるスキーマのみを選択できます。

図4-3「すべてのスキーマ」アップグレードの「コンポーネント・リスト」

4.6.8 WebLogic Serverコンポーネント・リスト

「ドメインによって使用されるすべての構成」がアップグレードで選択されている場合、ドメインのコンポーネントが読取り専用のこの画面に表示されます。続行する前に、コンポーネントのリストを確認してください。

図4-4 「WebLogicコンポーネント構成」の「コンポーネント・リスト」

4.6.9 前提条件

この画面では、アップグレードを続行する前にすべての前提条件が満たされていることを確認する必要があります。続行する前にボックスを確認してください。

警告:

Upgrade Assistantでは前提条件が満たされていることを確認できません。

図4-5 前提条件

4.6.10 エディションベースの再定義(EBR)のデータベースのアップグレード

この画面を使用して、エディションベースの再定義のデータベースのために、エディション・ドロップ・ダウン・リストから子エディションを選択します。アップグレードの開始前に、子エディションを作成する必要があります。

エディション・ベースの再定義のためにサーバー上にエディションを作成する方法の詳細は、『Oracle Fusion Middlewareのアップグレードのプランニング』のエディション・ベースの再定義のためにサーバー上にエディションを作成する方法に関する項を参照してください。

図4-6 EBRデータベースのアップグレード

4.6.11 スキーマ資格証明画面

この画面を使用して、選択したスキーマとそのスキーマをホストするデータベースへの接続に必要な情報を入力します。アップグレード対象のスキーマが前のFusion MiddlewareリリースのRCUによって作成された場合、下に示されているように、使用可能なスキーマ名がリストされているドロップダウン・メニューが表示されます。「接続」をクリックしてデータベースに接続してからアップグレードするスキーマを選択します。

注意: スキーマのほとんどで、この情報は事前移入されます。ただし、アップグレード・アシスタントで接続データを検知できない場合、下に示されているように、手動で入力する必要があります。

図4-7 スキーマの選択 - ドロップダウン・メニュー

図4-8 手動入力のスキーマ・データ

次の表で、この画面に表示される要素について説明します。

要素

説明

データベース・タイプ

ドロップダウン・メニューからデータベース・タイプを選択します。メニューで使用できるデータベースのタイプは、アップグレードしようとするスキーマによって異なります。

アップグレード用に選択されたデータベース・タイプは、RCUが最初にスキーマを作成したときに選択されたデータベース・タイプと同一である必要があります。

データベース・タイプとしてOracle Edition-Based Redefinition (EBR)を選択した場合は、アップグレードしているスキーマも、EBRデータベース・タイプを使用してRCUによって作成されている必要があります。特に、アップグレード・アシスタントでは、スキーマのデータベース・タイプが別のタイプに変換されることはありません。

データベース接続文字列

データベースの場所を入力します。

たとえば、Oracle Databaseを選択する場合は、次のURL形式を使用できます。

host:port/db_service_name

Microsoft SQL ServerまたはIBM DB2データベースを使用している場合は、ドロップダウン・メニューからデータベース・タイプを選択し、フィールドの下のテキストを確認してください。ここには、データベース・タイプごとに必要な構文が表示されます。

注意: Upgrade Assistantは、他の有効な形式の接続文字列を受け入れます。たとえば、Oracle Database TNSスタイルの接続文字列も使用できます。

DBAユーザー名

データベースへの接続に使用するデータベース・ユーザー名を入力します。

注意: DBAユーザーは、アップグレード・アシスタントを実行するのに十分な権限を付与されている必要がありますが、ユーザーはSYS/SYSDBA権限は必要ありません。現在、非SYSDBAユーザーを使用できます。

特定のデータベース・プラットフォーム上では、ユーザー名で大文字と小文字が区別され、DBAユーザー名が小文字で構成される場合があります。Upgrade Assistantは、ユーザーが入力した名前に接続します。ユーザー名を大文字に変換しません。

DBAパスワード

指定したDBAデータベース・ユーザーに対応するパスワードを入力します。

スキーマ・ユーザー名

ドロップダウン・リストからスキーマのユーザー名を選択するか、スキーマのユーザー名(DEV_MDSなど)を入力します。

すべてのデータベース・プラットフォーム上で、すべてのOracle Fusion Middlewareスキーマ名は大文字のみで構成されていることに注意してください。また、すべてのスキーマ名は、schema_version_registry表に大文字で格納されます。「スキーマ・ユーザー名」フィールドに小文字の文字が入力された場合、Upgrade Assistantは、その名前を大文字に変換します。

WebLogic Serverドメイン、UMSおよびVeridataスキーマの場合、11gスキーマのユーザー名およびパスワードを手動で入力する必要があります。

スキーマ・パスワード

特定のスキーマ・ユーザー名に関連付けられているパスワードを入力します。

エディション名

エディションベースの再定義に対応したOracle Databaseをデータベース・タイプとして選択する場合、既存のエディション名を指定する必要があります。

注意: EBR対応のスキーマをFusion Middleware 11gリリースから、または以前の12cリリースからアップグレードする前にまず、データベース・サーバーに接続し、12c (12.2.1)用にデータベース・サーバーでエディションを作成する必要があります。12.2.1用の新規エディションは、11.1.1.6.0、11.1.1.7.0、12.1.2または12.1.3エディションの子です。

エディション・ベースの再定義のためにサーバー上にエディションを作成する方法の詳細は、『Oracle Fusion Middlewareのアップグレードのプランニング』のエディション・ベースの再定義のためにサーバー上にエディションを作成する方法に関する項を参照してください。

4.6.12 インスタンス・ディレクトリ

OHSなどのシステム・コンポーネントをアップグレードする場合は、新しい12cコンポーネント・インスタンスを作成する開始点として使用する11gインスタンスのディレクトリの場所を指定する必要があります。

必要に応じて、「追加」ボタンを使用して、複数のインスタンスを含めます。

注意: Upgrade Assistantを使用してOracle 10gインスタンスをOracle 12cにアップグレードすることはできません。最初にOracle 10gインスタンスを11gにアップグレードする必要があります。10gから11gへの移行方法の詳細は、使用しているコンポーネントの11gのアップグレード・ドキュメントを参照してください。

図4-9 インスタンス・ディレクトリ

4.6.13 ノード・マネージャ

この画面を使用して、スタンドアロン・システム・コンポーネントのアップグレード時にドメインの作成に使用されるノード・マネージャの資格証明を指定します。

アップグレード時に、スクリーンショットに示されているフィールドが表示されない場合があることに注意してください。フィールドの表示をトリガーする条件は、次の表で説明します。

ユーザー名とパスワードは、ノード・マネージャとクライアントの間の接続の認証にのみ使用されます。これらは、サーバーの管理者IDおよびパスワードから独立しています。

図4-10 ノード・マネージャ

要素

説明

ユーザー名

ユーザー名はノード・マネージャへのアクセスに使用されます。

パスワード

ノード・マネージャへのアクセスに使用するパスワード。確認のためにパスワードを再入力する必要があります。

リスニング・アドレス

「リスニング・アドレス」フィールドには、ノード・マネージャがリスニングするDNS名またはIPアドレスを入力します。

リスニング・ポート

ノード・マネージャのリスニング・ポート番号。

4.6.14 OWSMポリシー・マネージャ

この画面を使用して、Oracle Web Services Manager (OWSM)ポリシー・マネージャをデプロイするWebLogic管理サーバー・ドメインの資格証明を入力します。

これはオプションの画面です。この画面は、クロス・ドメイン構成でOWSMがデプロイされている場合にのみ表示されます。

要素

説明

ホスト

ドメインの管理サーバーが実行されているホスト。

必ず完全なホスト名を指定します。次に例を示します。

fusionHost1.example.com

ポート

管理サーバーのリスニング・ポート。通常、管理サーバーはポート7001をリスニングします。

ユーザー名

管理サーバーへのログインに使用されるユーザー名。これは、ドメインの管理コンソールへのログインに使用するユーザー名と同じです。

パスワード

管理サーバーへのログインに使用される管理者アカウントのパスワード。これは、ドメインの管理コンソールへのログインに使用するパスワードと同じです。

図4-11 OWSMポリシー・マネージャ

4.6.15 ユーザー・メッセージング・サービスの構成

図4-12 ユーザー・メッセージング・サービスの構成

この画面を使用して、UMS 11g構成ファイルをホストするリモート管理対象サーバーのログイン資格証明を指定します。必要な前提条件をすべて満たし、次の表に説明されているように必要なログイン情報を指定した場合、アップグレード・アシスタントにより、リモート構成ファイルが自動的にコピーされます。

アップグレード実行中のマシン上でUMS構成ファイルにローカルにアクセスできない場合は、各管理対象サーバーのログイン資格証明を手動で入力する必要があります(ums_server1,ums_server2など)。

場合によっては、構成ファイルを、アップグレード実行中のマシン(多くの場合、AdminServerマシン)にコピーする必要があります。Upgrade Assistantはファイルをコピーしようとしますが、それらを見つけることができない場合、管理サーバーに手動でコピーする必要があります。

詳細は、『Oracle Fusion Middleware Infrastructureへのアップグレード』のUMS構成ファイルのコピーに関する項を参照してください。

ファイルを手動でコピーする必要があるのは、Upgrade Assistantが構成ファイルをコピーできないことを示すメッセージを受け取った場合のみです。ファイルをコピーしたら、Upgrade Assistantを再起動し、アップグレードを続行することができます。

要素

説明

ユーザー名

製品をインストールしたオペレーティング・システム・ユーザーを指定します。このユーザーは、リモート構成ファイルのフェッチに使用されます。

注意: このユーザーには、リモート管理対象サーバーがインストールされるノードにsshを介して接続する権限が必要です。

「ユーザー名」フィールドが表示されるのは、次のような場合です。

- 管理サーバーをホストしているローカル・マシン上または共有ディスク上に、管理対象サーバーの構成ファイルが見つからない

- UMSがターゲット指定されている12cドメイン内に複数の管理対象サーバーがある。

パスワード

このユーザーに関連付けられているパスワードを指定します。

管理対象サーバー

アップグレード・アシスタントが管理対象サーバーを自動的に検出できなかった場合、構成ファイルを含むリモート管理対象サーバーの名前を含むカンマ区切りリストを指定する必要があります。

例:

ums_server1、ums_server2

管理対象サーバー・アドレス

リモート管理対象サーバーを実行しているノードの完全なホスト名またはIPアドレスを含むカンマ区切りリストを指定します。このリストの順序は、上で指定された管理対象サーバー名のリストに対応する必要があります。

例:

fusionHost1.example.com,fusionHost2.example.com

説明:

fusionHost1.example.comはums_server1をホストし、fusionHost2.example.comはums_server2をホストします

4.6.16 調査

図4-13 調査

Upgrade Assistantは、アップグレード・プロセスを開始する前に各コンポーネントを調査し、最低基準を満たしていることを確認します。

この画面には、各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを検証するUpgrade Assistantのステータスが表示されます。

Upgrade Assistantは、アップグレード・プロセスを開始する前に各コンポーネントを調査し、最低基準を満たしていることを確認します。

この画面には、スキーマのスキーマ・ソース・バージョンが表示されます(情報がスキーマ・バージョン・レジストリ表にリストされている場合)。スキーマがRCUを使用して作成されたものではない場合、またはソース・バージョンが見つからない場合、ソース・バージョンは「使用不可」と表示されます。

注意:
調査フェーズで検出されたエラーは修正可能で、アップグレード・アシスタントを再起動できます。ただし、アップグレード・フェーズが開始されてからは、アップグレード前の環境をバックアップからリストアし、アップグレード・アシスタントをもう一度開始する必要があります。

コンポーネントの「ステータス」インジケータの説明は、次の表にあります。

ステータス

説明

進行中

Upgrade Assistantがコンポーネントのアップグレード項目を調査しています。

保留中

コンポーネントは、Upgrade Assistantが前のコンポーネントの処理を終了した後で調査されます。

失敗

アップグレード項目が欠落しているか、アップグレード基準を満たしていません。アップグレード・アシスタントは、問題が解決されるまでコンポーネントをアップグレードできません。「ログの表示」をクリックしてエラーのトラブルシューティングを行い、アップグレード・アシスタントを再起動します。

成功

アップグレード項目が検出され、アップグレードに対して有効です。

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

4.6.17 調査失敗

図4-14 調査失敗

このダイアログ・ボックスは、1つ以上のコンポーネントが調査フェーズに失敗し、アップグレードを継続することを選択した場合に表示されます。調査失敗が発生した場合、アップグレードを取り消して(「いいえ」をクリック)、ログ・ファイルを確認することを検討してください。アップグレードは開始されていないため、調査フェーズで検知された問題を解決して、バックアップからリストアせずにアップグレード・アシスタントを再起動することができます。

UMSアップグレードのみ:

構成アップグレードで、調査フェーズの最中にこのエラーが発生します。ユーザー・メッセージング・サービスでは、これをリカバリするには、UMS構成ファイルを手動でコピーし、アップグレード・アシスタントを再起動します。

エラーがアップグレード・フェーズ中に発生した場合、リカバリするには、バックアップをリストアし、構成ファイルを手動でコピーして、アップグレード・アシスタントを再起動します。

4.6.18 アップグレード・サマリー

図4-15 アップグレード・サマリー

アップグレード・サマリーの確認

ツリーを展開または縮小して、ウィザードの画面で提供されるデータの詳細(スキーマの詳細、Oracle WebLogic Server接続の詳細、Oracle WebLogicドメイン・ディレクトリ情報など)を表示または非表示にします。

サマリー画面には、アップグレードするスキーマのソース・バージョンとアップグレード後の結果のターゲット・バージョンも表示されます。アップグレードに進む前に、両方のバージョンが正しいことを確認してください。

アップグレード・プロセスの開始

「アップグレード」をクリックして、アップグレード・プロセスを開始します。

スキーマをアップグレードする場合は、そのスキーマをホストしているデータベースのバックアップがあることを確認してください。

レスポンス・ファイルの保存

「レスポンス・ファイルの保存」オプションにより、Upgrade Assistantへの入力として使用できるファイルが作成されます。このレスポンス・ファイルは、Upgrade Assistantのグラフィカル・ユーザー・インタフェース画面で入力したすべての情報を収集し、後でサイレント・アップグレードを実行することができます。サイレント・アップグレードは、Upgrade Assistantウィザードとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。

4.6.19 アップグレードの進行状況

図4-16 アップグレードの進行状況

この画面には、現在のアップグレード・プロセスの状況と、アップグレードが成功した後のコンポーネントの予測ターゲット・バージョンが表示されます。

進捗バーはアップグレードの残り時間を示す尺度ではないことに注意してください。進捗バーは、アップグレードされている各コンポーネントの完了したアップグレード・ステップを示す、変動するグラフ表示です。進捗バーが一定のペースで変動しない場合もあります。進捗バーの特定の部分が非常に速く変動することがあります。また、長い時間がかかるデータベース操作を実行している別のコンポーネントでは、非常に遅く変動したり、フリーズしたように見えることもあります。これは、アップグレードの進行状況が止まっていることを意味するのではなく、単に長い時間がかかる操作が実行されていることを示しているだけです。(特にスキーマ・アップグレードの間は)様々なアップグレード操作が異なるペースで実行されます。

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

各コンポーネントのアップグレードのステータスは、コンポーネント名の隣に表示される次のメッセージのいずれかで示されます。次の表で、各ステータス・メッセージを説明します。

ステータス

説明

進行中

Upgrade Assistantがコンポーネントのアップグレード項目をアップグレードしています。

保留中

コンポーネントは、Upgrade Assistantが先行するコンポーネントを終了してからアップグレードされます。

アップグレード不要

コンポーネントは以前にUpgrade Assistantでアップグレードされているか、コンポーネントはインストールされたばかりで、すでに最新バージョンになっています。このコンポーネントではアクションは実行されません。

スキップ済

コンポーネントは、ステータスが「失敗」の別のコンポーネントに依存しています。ステータスが「スキップ済」のコンポーネントに対するアップグレードは試行されません。

失敗

アップグレード項目が欠落しているか、アップグレード基準を満たしていません。コンポーネントをアップグレードできません。「ログの表示」をクリックすると、エラーのトラブルシューティングを行えます。

成功

アップグレード項目は正常にアップグレードされました。

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

4.6.20 アップグレード成功

図4-17 アップグレード成功

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

また、次の手順も実行してください。

- Oracleホームのpostupgrade.txtファイルを表示します。
UNIXシステムの場合:

ORACLE_HOME/oracle_common/upgrade/logs

Windowsシステムの場合:

ORACLE_HOME\oracle_common\upgrade\logs

- その他のアップグレード後のタスクの詳細は、ご使用のOracle Fusion Middleware環境に固有のアップグレードの項を参照してください。

4.6.21 アップグレード失敗

図4-18 アップグレード失敗

1つ以上のコンポーネントのアップグレードに失敗しました。今行った操作では、コンポーネントをアップグレードできません。「ログの表示」をクリックすると、エラーのトラブルシューティングを行えます。

アップグレード・アシスタントを起動する前に、アップグレード前環境の問題を修正する必要があります。バックアップからアップグレード前環境をリストアして(元のバックアップ・ファイルが別の場所に保存されていることを確認)、問題を修正し、アップグレード・アシスタントを再起動します。

4.6.22 アップグレードの取消し

図4-19 アップグレードの取消

アップグレード・プラグインがアクティブに実行されている(つまり、アップグレード・ページが表示されていて、進捗バーが100%未満である)間に「取消」をクリックすると、前述の「取消の確認」画面が表示されます。

図4-20 アップグレードの取消

アクティブに実行されているアップグレード・プラグインがない場合、「取消」をクリックすると、前述の「取消の確認」画面が表示されます。

重要な注意: スキーマのアップグレードを取り消す場合は、スキーマとその環境(アップグレード前のディレクトリ構造)をホストするデータベースのバックアップをリストアする必要があります。

4.7 再構成ウィザードを使用した12cドメインのアップグレード

再構成ウィザードを使用して、既存の12c ドメインを最新バージョンにアップグレードします。

UNIXオペレーティング・システムでは、次の12ディレクトリに移動し、再構成ウィザードを起動します。

ORACLE_HOME/oracle_common/common/bin/reconfig.sh

Windowsオペレーティング・システムの場合:

ORACLE_HOME\oracle_common\common\bin\reconfig.cmd

表4-2 再構成ウィザードの画面

再構成ウィザードの画面

説明および必要なアクション

ドメインの選択

既存の12cドメイン・ディレクトリの絶対パスを入力するか、「参照」をクリックしてドメイン・ディレクトリを選択します。

再構成セットアップの進行状況

再構成テンプレートのアプリケーションの進行状況を表示します。

ドメイン・モードおよびJDK

ドメイン・モードは変更できません。この設定は、構成ウィザードを使用してドメインが作成された際に、指定されたモードからインポートされます。

注意: 本番ドメインをアップグレードする前に、まず開発ドメインで試験的なアップグレードを実行することをお薦めします。アップグレードに関する問題やエラーは、本番環境をアップグレードする前に解決する必要があります。

ドメインで使用するJDKを選択するか、「参照」をクリックして使用するJDKに移動します。

Oracle Fusion Middleware 12cにはJava SE 7が必要であることに注意してください。詳細は、『Oracle Fusion Middlewareのインストールのプランニング』の動作保証とシステム要件の検証に関する項を参照してください。

JDBCデータ・ソース

この画面で、ドメイン・ソースに定義されているJDBCデータ・ソースの構成を確認する必要があります。自動的に構成されたOPSSデータ・ソースが、この画面に表示されます。

このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のJDBCデータ・ソースに関する項を参照してください。

JDBCデータ・ソース・テスト

「JDBCデータ・ソース」画面で構成したデータ・ソース接続をテストします。

このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のJDBCデータ・ソースのテストに関する項を参照してください。

データベース構成タイプ

前の画面でデータ・ソース接続の詳細を指定した場合は、データベース接続の詳細が自動的に入力されます。

この画面で情報が入力されない場合は、「RCUデータ」を選択してデータベース資格証明を指定して、ドメインに含まれているすべての12.1.xスキーマのスキーマ情報を取得します。このオプションを選択すると、この画面のフィールドがアクティブになります。Repository Creation Utility (RCU)のSTBコンポーネントに指定した接続情報を使用して、各フィールドに入力します。

接続情報を入力した後、「RCU構成の取得」をクリックしてスキーマ情報を取得します。

詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のデータベース構成タイプに関する項を参照してください。

JDBCコンポーネント・スキーマ

デフォルトでは、前の画面で「RCUデータの取得」を選択し、すべてのスキーマの所有者が同じ場合、スキーマ情報が表示されます。

画面に表示されたスキーマのデータ・ソース設定を変更する場合は、各スキーマ名の横のチェック・ボックスを選択します。画面の上部のフィールドで変更を行うと、下部で選択しているスキーマが更新されます。変更するスキーマのみを選択してください。

注意:

- このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のJDBCコンポーネント・スキーマに関する項を参照してください。

JDBCコンポーネント・スキーマ・テスト

前の画面でデータ・ソースに指定した構成をテストします。テストするスキーマ名の横のチェック・ボックスを選択し、「選択された接続のテスト(T)」をクリックします。

テストの結果は、「ステータス」列に表示されます。すべてのスキーマでテストに成功した場合、「次へ」をクリックします。

ノード・マネージャ

この画面は、再構成するドメインで、ドメインごとのデフォルトの場所のノード・マネージャが使用されている場合にのみ表示されます。

「既存の構成を移行」を選択して、ドメインごとのデフォルトの場所の場所を指定します。

「Oracle推奨デフォルトの適用」を有効にします。

「ノード・マネージャ資格証明」を指定します。これは、ノード・マネージャを管理するために作成される、新しい「ユーザー」です。ノード・マネージャにより処理されるコンポーネントには、起動時にパスワードが要求されます(OHSを含む)。

注意: ドメインをアップグレードしてホストごとのノード・マネージャ構成からドメインごとのノード・マネージャ構成に変更する際に、カスタム・スクリプトを使用してWebLogic Server環境を起動および停止する場合、手動でスクリプトを更新してノード・マネージャ・ホームの場所を新しいドメインベースの場所に変更する必要があります。

ノード・マネージャの構成の詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のデフォルトのノード・マネージャの構成に関する項を参照してください。

拡張構成

詳細構成を行うすべてのカテゴリ(存在する場合)を選択します。選択したカテゴリごとに、詳細構成を行うことができる適切な構成画面が表示されます。この画面で項目を選択しない場合は、「構成のサマリ」画面が次に表示されます。

注意: ノード・マネージャが使用可能な場合に選択しないときは、『Oracle WebLogic Serverのアップグレード』のノード・マネージャ構成の実行に関する項の説明に従って、ノード・マネージャを手動で構成する必要があります。

ノード・マネージャの詳細オプションは、ホストごとのノード・マネージャ構成を使用中のドメインを再構成する場合にのみ使用できます。ドメインごとのノード・マネージャ構成に切り替えることも、すでに存在する既存のノード・マネージャの使用を続行することも可能です。

管理対象サーバー

この画面で、既存の管理対象サーバー(ある場合)の設定を確認します。

クラスタ

この画面で、既存のクラスタ(ある場合)の設定を確認します。

Coherenceクラスタ

この画面は、WebLogic ServerインストールにCoherenceが含まれた場合にのみ表示されます。自動的にドメインに追加されるCoherenceクラスタがリストされます。

マシン

WebLogicドメインでは、マシン定義がハードウェアの物理単位を識別し、ホストするWebLogic Serverのインスタンスまたはシステム・コンポーネント(OHSサーバーなど)に関連付けられています。

この画面で、アップグレードの一部として再構成に含められる、既存のノード・マネージャの詳細のHost/Port設定を確認します。

実際のリスニング・アドレスが指定されていることを確認してください。ローカルホストは使用しないでください。

システム・コンポーネント

この画面で、関連付けられたアップグレード・プロセスで再構成される既存のOHSコンポーネントの現行の設定を確認します。アップグレード・エラーを防ぐために、この画面でOHS設定を変更しないでください。また、この画面で、システム・コンポーネントを追加または削除できます。

OHSサーバー

この画面で、再構成ウィザードにより各OHSドメインに対して適切なポートの詳細(ソース・インストールから取得されるもの)が取得されていることを確認します

注意: 複数のOHSインスタンスを含むドメインを再構成する場合は、画面の上部に「システム・コンポーネント」トグルが表示されます。再構成時はこのオプションを選択し、異なるインスタンス間で切り替えて構成の詳細を更新してください。

複数のOHSサーバーが同じホストの詳細を使用することはできますが、各サーバーには一意のポートの詳細が割り当てられる必要があります。この画面で異なるポートの詳細が表示されていない場合は、詳細を編集して異なる内容にする必要があります。

システム・コンポーネントのマシンへの割当

この画面で、定義したマシンへのシステム・コンポーネントの割当てを確認します。

注意: この画面には、ノード・マネージャに割り当てられているOHSコンポーネントが表示されます。これによってOHSインスタンスが再構成され、12cノード・マネージャに割り当てられます(この手順は、OHSインスタンスを起動または停止するために必要です)。

デプロイメント・ターゲット指定

ドメインを構成する製品に関連付けられるアプリケーションが、その製品のために作成した管理対象サーバーまたはその管理対象サーバーが割り当てられているクラスタに自動的にターゲット指定されます。この画面では、アプリケーションを追加のサーバーおよびクラスタに割り当てることができます。

この画面で、ドメインのデプロイメント・ターゲット指定を確認します。

サービス・ターゲット指定

ドメインを構成する製品に関連付けられるサービスが、その製品のために作成した管理対象サーバーまたはその管理対象サーバーが割り当てられているクラスタに自動的にターゲット指定されます。この画面では、サービスを追加のサーバーおよびクラスタにターゲット指定することができます。

この画面で、ドメインのサービス・ターゲット指定を確認します。

構成のサマリー

続行する前にドメインの詳細な構成設定を確認します。「表示」ドロップダウン・リストからフィルタ・オプションを選択することで、右端のパネルに表示されるアイテムを限定できます。

「再構成」をクリックしてドメインを再構成するか、構成を変更する場合は「戻る」をクリックします。

再構成の進行状況

再構成の進行状況を確認します。処理が完了したら「次へ」をクリックします。

再構成に成功しました

再構成処理の最終的なステータスを確認します。「終了(F)」をクリックして再構成ウィザードを終了します。

4.8 アップグレード・アシスタントを使用した12c構成のアップグレード

次の手順に従って、アップグレード・アシスタントを使用して、既存の12cドメイン構成をアップグレードします。

アップグレード・アシスタント(UA)を12c Oracleホームから実行して、コンポーネント構成をアップグレードします。

UNIXオペレーティング・システムの場合:

ORACLE_HOME/oracle_common/upgrade/bin/.ua

Windowsオペレーティング・システムの場合:

ORACLE_HOME\oracle_common\upgrade\bin\ua.bat

アップグレード・アシスタントの画面

説明および必要なアクション

ようこそ

この画面では、アップグレード・アシスタントの概要と、アップグレード前の重要なタスクについての情報が示されます。

olink:UAREF-GUID-8231A670-F92B-4A52-A5D5-21C7241E7086

「ドメインによって使用されるすべての構成」を選択します

使用可能なコンポーネント

この画面には、アップグレードされるドメイン構成を持つ、インストール済Oracle Fusion Middlewareコンポーネントのリストが表示されます。

前提条件

各ボックスで、スキーマ・アップグレードの前提条件が満たされているかどうかを確認します。アップグレード・アシスタントでは、これらの前提条件が満たされていることを検証できません。

調査

各コンポーネントについて、アップグレードが正常に完了したことを確認します。

アップグレード・サマリー

「アップグレード」をクリックする前にこの画面の情報を確認します。

アップグレードの進行状況

この画面には、アップグレードの進行状況が表示されます。

「アップグレードの進行状況」ステータス・バーには、完了したアップグレード・プロセスの数が表示されます。残りの時間を特定するわけではありません。

アップグレード・アシスタントにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。

アップグレード成功

この画面には、アップグレードの最終結果が表示されます。

5 アップグレード後に実行するタスク

この項のトピックでは、Oracle Fusion Middleware 12c Infrastructureへのアップグレード後に実行する必要がある場合があるタスクについて説明します。アップグレードした環境に当てはまる手順のみを実行してください。

- アップグレードの検証チェックリストの使用

- サーバーの正しい順序での起動と停止

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

- setDomainEnvへのカスタマイズの再適用

- Oracle Fusion Middleware 12c監査データ・ストアの構成

- 古いJava EE Webサービス・アプリケーションのセキュリティ・ステータスのメンテナンス

- Oracle Fusion Middleware 12cソフトウェアの管理のためのドキュメント・リソース

- Oracle Fusion Middleware 12cでの11gアプリケーション・デプロイメントの使用

5.1 アップグレードの検証チェックリストの使用

アップグレードの後、次の基本的な管理タスクを正常に完了してください。これらの各手順の実行方法の詳細は、この章のその他の項に記載されています。

注意:

次のサーバーを起動する順序は重要です。それらを正しい順序で起動(停止)しないと、デプロイメントに関する問題が発生する可能性があるからです。

詳細は、「サーバーの正しい順序での起動と停止」を参照してください。

1. ノード・マネージャを起動できることを確認します。

2. 管理サーバーおよび管理対象サーバー(ある場合)を、元のドメイン・ホームのbinディレクトリから起動できることを確認します。Windowsオペレーティング・システム・ユーザーの場合は、新しいコマンド・プロンプト(12cのアップグレード・アシスタントを起動したコマンド・プロンプトではなく)でサーバーを起動すると便利です。

注意: OHS自身の構成には、管理対象サーバーは必要ありません。

3. Web層(OHSサーバー)を起動できることを確認します。

4. 次のURLを使用して、管理コンソールおよびEnterprise Managerに接続できることを確認します。

- http://machinename.my_company_com:administration_port

- http://machinename.my_company_com:administration_port/em

5.2 サーバーの正しい順序での起動と停止

Infrastructureのアップグレード後は、ご使用の環境にあるすべての管理サーバーと管理対象サーバーを起動して、それらが予期したとおりに機能していることを確認する必要があります。

サーバーを起動する順序と停止する順序が重要であり、正しい順序で起動または停止していないと、デプロイメントで問題が発生することがあります。

注意:

管理サーバー、管理対象サーバーおよびコンポーネントを含めたOracle Fusion Middlewareの開始および停止の手順については、『Oracle Fusion Middlewareの管理』のOracle Fusion Middlewareの開始と停止に関する項を参照してください。

サーバーの起動順序:

1. ノード・マネージャ
関連項目: 「ノード・マネージャの起動」。

2. 管理サーバー
関連項目: 「管理サーバーの起動」

3. Web層(Oracle HTTP Serverを含む)
関連項目: 「Web層(OHS Server)の起動」

4. Oracle Web Services Manager (OWSM)の管理対象サーバー(インストールされている場合)

5. サービス指向アーキテクチャ(SOA)の管理対象サーバー(インストールされている場合)

6. Oracle Service Bus (OSB)の管理対象サーバー(インストールされている場合)

7. Business Activity Monitoring (BAM)の管理対象サーバー(インストールされている場合)

サーバーの停止順序:

1. Business Activity Monitoring (BAM)の管理対象サーバー(インストールされている場合)

2. Oracle Service Bus (OSB)の管理対象サーバー(インストールされている場合)

3. サービス指向アーキテクチャ(SOA)の管理対象サーバー(インストールされている場合)

4. Oracle Web Services Manager (OWSM)の管理対象サーバー(インストールされている場合)

5. Web層(Oracle HTTP Serverを含む)

6. 管理サーバー

7. ノード・マネージャ

サーバーの停止の詳細は、『Oracle Fusion Middlewareの管理』の「Oracle Fusion Middlewareの起動と停止」を参照してください。

5.2.1 ノード・マネージャの起動

ノード・マネージャを起動するには、DOMAIN_HOME/binディレクトリに移動します

UNIXオペレーティング・システムの場合は、次に示すように、nohupとサンプル出力ファイルnm.outを使用してノード・マネージャを起動します。

nohup ./startNodeManager.sh > nm.out&

Windowsオペレーティング・システムの場合は、次のコマンドを実行します。

startNodeManager.cmd

注意:

ホストごとのノード・マネージャ構成を使用するには、適切なノード・マネージャ・スクリプトでJAVA_OPTIONSに–Dohs.product.home=<MW_HOME>が設定されていることを確認してください。ノード・マネージャ・サービスを使用していない場合は、NodeManager.cmd/shコマンドを実行します。ノード・マネージャ・サービスを使用している場合は、installNodeMgrSvc.cmdコマンドを実行します。

使用するホストとポートは、アップグレードされた設定で使用するものと一致している必要があります。ファイルのホストまたはポートの値を編集して適切な詳細でノード・マネージャ・サービスをインストールする方法の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverノード・マネージャ管理者ガイド』の「Javaノード・マネージャの構成」を参照してください。

5.2.2 管理サーバーの起動

ディレクトリDOMAIN_HOME/bin (UNIXの場合)またはDOMAIN_HOME\bin (Windowsの場合)から次のコマンドを実行して、管理サーバーを起動します。

(UNIX) ./startWebLogic.sh

(Windows) startWebLogic.cmd

11gドメインが正しく再構成されたことを確認するには、次のURLを使用して管理コンソールにログインし、コンソールに表示されるバージョン番号が12.2.1かどうかを確認します。

http://administration_server_host:administration_server_port/console

管理サーバーの停止と起動の詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareの管理』の管理サーバーの起動と停止に関する項を参照してください。

5.2.3 Web層(OHS Server)の起動

ノード・マネージャと管理サーバーを起動した後は、Oracle HTTP (OHS) Serverを起動できます。DOMAIN_HOME/binディレクトリに移動して、次のコマンドを実行します。

UNIXオペレーティング・システムの場合:

DOMAIN_HOME/bin/startComponent.sh ohs_name

Windowsオペレーティング・システムの場合:

DOMAIN_HOME\bin\startComponent.cmd ohs_name

詳細は、『Oracle Fusion Middlewareの管理』のシステム・コンポーネントの起動と停止に関する説明を参照してください。

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

ドメイン・コンポーネント構成のアップグレードが成功したことを確認するには、次のURLを使用して管理コンソールおよびFusion Middleware Controlにログインし、各コンポーネントでアップグレードされたバージョン番号を確認します。

管理コンソールのURL: http://administration_server_host:administration_server_port/console

Fusion Middleware ControlのURL: http://administration_server_host:administration_server_port/em

注意:

アップグレード後、管理ツールは、前のOracleホームではなく新しい12cのOracleホームから実行する必要があります。

アップグレード・プロセス時に、一部のOWSMドキュメント(ポリシー・セット、ポリシーおよびアサーション・テンプレートなどの事前定義ドキュメント)のアップグレードが必要な場合があります。ポリシー・セットまたは事前定義ドキュメントがアップグレードされると、バージョン番号が1増分されます。

5.4 setDomainEnvへのカスタマイズの再適用

アプリケーション環境の12cへのアップグレードを完了するには、起動スクリプト(setDomainEnvなど)へのカスタマイズの再適用が必要な場合があります。これらのスクリプトは、アップグレード時に新しい12cバージョンで上書きされます。前のリリースで行ったカスタマイズは、再適用する必要があります。

詳細は、起動スクリプトへのカスタマイズの再適用に関する説明を参照してください。

注意:

今後のアップグレードにおいてカスタマイズの消失を防ぐには、「カスタムsetDomainEnv設定のメンテナンス(オプション)」を参照してください。

5.5 Oracle Fusion Middleware 12c監査データ・ストアの構成

Oracle Fusion Middleware11gでファイルベースの監査ストアを使用していた場合は、Oracle Fusion Middleware 12cへのアップグレード後に、データベースベースの監査データ・ストアへの監査データのロードを有効にする必要があります。

包括的なアップグレード処理の一環として、他のOracle Fusion Middlewareスキーマが存在するデータベースにIAUスキーマを作成しておく必要があります。監査データ・ストアの使用方法の詳細は、の監査データ・ストアの管理に関する項を参照してください。

5.6 古いJava EE Webサービス・アプリケーションのセキュリティ・ステータスのメンテナンス

12cにおいて、Java EE Webサービスおよびクライアントに対するグローバル・ポリシー・アタッチメントのサポートを導入すると、既存のJava EE Webサービスおよびクライアント(12.1.2およびそれ以前)の後方互換性に影響する場合があります。ポリシーの不在に依存しているJava EE Webサービスまたはクライアント・エンドポイントが、グローバル・ポリシー・アタッチメントのスコープに含まれる場合、グローバル・ポリシー・アタッチメントの存在によって、そのエンドポイントのセキュリティ動作が変更される場合があります。

注意:

Fusion Middleware 12.1.2およびそれ以前では、SOAP WebサービスおよびSOAP Webサービス・クライアントのサブジェクト・タイプのために定義されたグローバル・ポリシー・アタッチメントは、Oracle Infrastructure Webサービスおよびクライアントにのみ適用可能であり、Java EE Webサービスおよびクライアントからは無視されていました。12cへのアップグレード後は、これらのサブジェクト・タイプのために定義されたグローバル・ポリシー・アタッチメントは、Java EE Webサービスおよびクライアントにも適用され、既存のJava EE Webサービスおよびクライアントのセキュリティ動作に影響を与える場合があります。

後方互換性を維持するには、特定のサービスまたはクライアントにOWSM動作無効ポリシー(no_authentication_service_policy、no_authorization_service_policyまたはno_messageprotection_service_policy.など)をアタッチすることにより、それらのエンドポイントへのグローバル・ポリシー・アタッチメントを無効化できます。詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のグローバルにアタッチされたポリシーの無効化に関する項を参照してください。

注意:

WebLogic Wssp1.5-No-Op.xml動作無効ポリシーを使用できます。ただし、WebLogicセキュリティ・ポリシーは、プログラムでのみWebサービス・クライアントにアタッチできるため、コードの変更が必要です。詳細は、『Oracle WebLogic Server WebLogic Webサービスの保護』のグローバルにアタッチされたポリシーの無効化に関する項を参照してください

5.7 Oracle Fusion Middleware 12cソフトウェアの管理のためのドキュメント・リソース

表5-1に、Infrastructure 12cへのアップグレード後に実行することが多い一般的な管理タスクを示します。

表5-1 基本的な管理タスク

タスク

説明

詳細情報

Fusion Middleware管理ツールについての学習

環境の管理に使用できる各種ツールについて習熟します。

『Oracle Fusion Middlewareの管理』のOracle Fusion Middleware管理ツールの概要に関する項。

製品およびサーバーの起動と停止

Oracle Fusion Middleware(管理サーバー、管理対象サーバー、コンポーネントを含む)起動と停止の方法について学習します。

『Oracle Fusion Middlewareの管理』のOracle Fusion Middlewareの起動と停止に関する項。

Secure Sockets Layer (SSL)の構成

Oracle Fusion Middlewareコンポーネント間で、SSLを使用したセキュアな通信を設定する方法について学習します。

『Oracle Fusion Middlewareの管理』の"Oracle Fusion MiddlewareでのSSL構成に関する項。

Oracle Fusion Middlewareのモニタリング

Oracle Fusion Middlewareコンポーネントのステータスを追跡する方法を学習します。

『Oracle Fusion Middlewareの管理』のOracle Fusion Middlewareの監視に関する項。

バックアップとリカバリの手順の理解

Oracle Fusion Middlewareのバックアップとリカバリの推奨手順について学習します。

『Oracle Fusion Middlewareの管理』のバックアップとリカバリの概要に関する説明。

5.8 Oracle Fusion Middleware 12cでの11gアプリケーション・デプロイメントの使用

Oracle Fusion Middleware 12cへのアップグレード後、Oracle Fusion Middleware 11gにデプロイしていたカスタムJavaおよびOracle Application Development Framework (ADF)アプリケーションは、Oracle Fusion Middleware 11gと同じように動作します。

ただし、Oracle ADF 12cおよびOracle JDeveloper 12cで利用可能ないくつかの新機能があります。

次の項では、アプリケーションをOracle JDeveloper 12cに移行する方法についての追加情報を示します。

- Oracle Application Development Framework (ADF) 12cについて

- Oracle JDeveloper 12cについて

5.8.1 Oracle Application Development Framework (ADF) 12cについて

Oracle ADFの詳細は、次のOracle Fusion Middleware 12ドキュメント・リソースを参照してください。

- Oracle Application Development Frameworkの理解

- Oracle Fusion Middleware 12cドキュメント・ライブラリのOracle Application Development Framework (ADF)の共通のタスクに関するページ

5.8.2 Oracle JDeveloper 12cについて

この項では、次の情報について説明します。

- Oracle JDeveloper 12cのインストール

- Oracle JDeveloper 12cを使用したアプリケーションの移行

- Oracle JDeveloper 12cを使用した非同期Webサービスの移行について

5.8.2.1 Oracle JDeveloper 12cのインストール

Oracle JDeveloper 12cをインストールするには、『Oracle JDeveloperのインストール』を参照してください。

Oracle JDeveloperは、アプリケーションをローカルでテストするために使用できる埋込みバージョンのOracle WebLogic Serverを提供します。詳細は、『Oracle JDeveloperのインストール』のOracle JDeveloperで開発したアプリケーションのデプロイとテストに関する項を参照してください。

5.8.2.2 Oracle JDeveloper 12cを使用したアプリケーションの移行

Oracle JDeveloper 12cのインストール後、Oracle JDeveloper 12cでカスタム・アプリケーション・プロジェクトを開いて、Oracle JDeveloper 12cに自動的に移行できます。

詳細は、『Oracle JDeveloperのインストール』の以前のバージョンからOracle JDeveloper 12cへの移行に関する項を参照してください。

5.8.2.3 Oracle JDeveloper 12cを使用した非同期Webサービスの移行について

アプリケーションにADF BC非同期Webサービスが含まれている場合、Oracle JDeveloperまたはojdeployコマンド行ツールを使用してそれを再作成し、必要なデプロイメント・ディスクリプタをデプロイメント・アーカイブに生成します。

非同期Webサービスの開発の詳細は、『Oracle Infrastructure Webサービスの開発』の非同期Webサービスの開発に関する項を参照してください。

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2016, Oracle and/or its affiliates.All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティについて

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。