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 AS SYSDBAとして実行することを回避します。	fmwという名前の非SYSDBAユーザーを作成し、アップグレード・アシスタントで必要な権限のみを付与してアップグレード・アシスタントを実行することをお薦めします。	SYSDBA以外のユーザーの作成
Oracle Databaseユーザーの場合: エディション・ベースの再定義(EBR)に対応したスキーマをアップグレードする前に、最初にデータベース・サーバーに接続して、12c (12.2.1)のデータベース・サーバーにエディションを作成する必要があります。	この手順は、エディション・ベースの再定義(EBR)データベースを使用している場合にのみ必要です。	エディション・ベースの再定義のためのサーバー上でのエディションの作成(オプション)
アップグレード前に、新しい12c製品をダウンロードして、新しいOracleホームにインストールします。	アップグレード前の環境内にすでに存在する製品の12c (12.2.1)バージョンをインストールします。12c (12.2.1)用にリリースされていない製品がありますが、将来のリリースで使用可能になる予定です。	12c Oracle Fusion Middleware製品ディストリビューションのダウンロードおよびインストール
製品環境に対する準備状況チェックは、アップグレード前に実行してください。	アップグレード・アシスタントを -readinessモードで実行すると、正常なアップグレードの妨げとなる問題の可能性が検出されます。	アップグレード前の準備状況チェックの実行
アップグレードを完了するためのコンポーネント固有のアップグレード・ドキュメントを使用します。	ドキュメントでは、アップグレードで必要なコンポーネント固有のタスクについて説明します。これらのタスクには、アップグレード前に実行するものと、アップグレード後に実行するものがあります。常にOracle Fusion Middlewareのアップグレード・ドキュメントを参照し、正常にアップグレードされていることを確認します。	コンポーネント固有のアップグレード・ドキュメントの検索

• 完全なバックアップの作成(必須)
  新しい12cディストリビューションのインストールと、Oracle Fusion Middleware 11gまたは12cデプロイメントのアップグレードを始める前に、Oracle Fusion Middlewareスキーマをホストしているデータベースすべてを含めて、システムに重要なすべてのファイルを必ずバックアップしてください。
• テストのための本番環境のクローニング (推奨)
  実際の本番環境の完全な作業用コピーを作成し、クローン環境をアップグレードし、アップグレードされたコンポーネントが予想どおりに動作することを確認してから(必ず確認した後で)、本番環境をアップグレードすることを強くお薦めします。
• 動作保証およびシステム要件の確認
  ご使用の環境がインストールに必要な要件を満たしていることを確認するには、動作保証マトリックスおよびシステム要件のドキュメントをあわせて使用する必要があります。
• 32ビットから64ビット・オペレーティング・システムへの移行
  Oracle Fusion Middleware 12cのほとんどのコンポーネントは、64ビットのオペレーティング・システムが必要です。32ビットの環境を実行している場合は、アップグレード前に、32ビット環境を64ビット・ソフトウェア環境に移行する必要があります。
• 未使用データのパージ
  アップグレード前に未使用データをパージすると、アップグレード・プロセスを最適化できます。一部のコンポーネントについては、自動パージ・スクリプトを使用でき、アップグレード前に実行して、使用されていないデータや古いデータをパージすることができます。
• アップグレード前の必要なスキーマの作成
  アップグレードする前に、12cデプロイメント用の新しいスキーマを作成する必要がある場合があります。12c用として作成する必要がある追加のスキーマを確認するには、既存の環境にあるコンポーネント・スキーマとアップグレードに必要なスキーマを比較します。
• ファイルベース・ポリシー・ストアのデータベース・ベース・ポリシー・ストアへの再関連付け(必須)
  Oracle Fusion Middleware 12cでは、データベース・ベースのポリシー・ストアを使用します。データベース・ベースのポリシー・ストアは、本番環境で推奨されます。ファイルベースまたはOIDベースのポリシー・ストアを使用している場合、アップグレードの前に、ストアをデータベース・ベースのストアに再関連付けする必要があります。
• OIDベースのセキュリティ・ストアのための12c OPSSスキーマの作成
  LDAPベースのOPSSセキュリティ・ストアでサポートされているのは、Oracle Internet Directory (OID)のみです。LDAPベースのポリシー・ストアは、通常、本番環境で使用します。11gでOIDベースのセキュリティ・ストアを使用している場合、リポジトリ作成ユーティリティ(RCU)を使用して、新しい12cスキーマを作成する必要があります。
• セキュリティ・ストアの最新バージョンへのアップグレード
  最新バージョンのOPSSセキュリティ・ストアにアップグレードすると、強化された機能と修正を利用できます。OPSSセキュリティ・ストアは、Oracle Fusion Middleware製品インストールの一部なので、アップグレード・アシスタントを使用して直接、OPSSスキーマをアップグレードできます。
• 非SYSDBAユーザーの作成
  アップグレード・アシスタントを実行するには、非SYSDBAを作成することをお薦めします。この手順で作成したユーザーには、アップグレードの完了に必要な権限が付与されます。
• 強化された暗号化(AES 256)の使用
  Javaプラットフォームでは、暗号化、公開鍵インフラストラクチャ、認証、安全な通信、アクセス制御など、主要なセキュリティ分野に渡る一連のAPIが定義されています。このAPIを使用すると、開発者はセキュリティ・メカニズムを簡単にアプリケーション・コードに組み込むことができます。強化された暗号化(AES 256など)を使用する予定がある場合は、アップグレードの前に、これらのポリシー・ファイルをJDKに適用することをお薦めします。
• エディション・ベースの再定義のためのサーバー上でのエディションの作成(オプション)
  エディション・ベースの再定義を使用すると、アプリケーションの使用中にそのOracleデータベース・コンポーネント、たとえばPL/SQLオブジェクトやビュー、シノニムをアップグレードでき、停止時間を最小化あるいは排除することができます。
• カスタム・ドメイン環境設定のメンテナンス
  各ドメインには、動的に生成されるドメインおよびサーバーの起動スクリプト(setDomainEnvなど)が含まれます。起動スクリプトに行った変更は、その後のドメインのアップグレードおよび再構成操作中に上書きされるため、これらの起動スクリプトを変更しないでください。
• 12c Oracle Fusion Middleware製品ディストリビューションのダウンロードおよびインストール
  Oracle Fusion Middleware製品ディストリビューションは、Oracle Technology Network (OTN)とOracle Software Delivery Cloudでダウンロードできます。
• アップグレード前の準備状況チェックの実行
  Upgrade Assistantを-readinessモードで実行すると、読取り専用のアップグレード前チェックをドメインで実行できます。問題が検出された場合は、実際にアップグレードを開始する前にそれらを修正できます。
• コンポーネント固有のアップグレード・ドキュメントの検索
  コンポーネント固有のアップグレード・ドキュメントには、Oracle WebLogic Server、Oracle Fusion Middleware Infrastructure、Oracle HTTP Server、Oracle SOA Suite and Oracle Business Process Management、Oracle Webcenter、User Messaging Service、Oracle Data Integratorなど個々のコンポーネントごとのアップグレード手順と情報が記載されています。

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

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

詳細は、「Oracle Fusion Middleware環境のバックアップ」と「12c用のOracleデータベースのアップグレードと準備」を参照してください

2.2 テストのための本番環境のクローニング(推奨)

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

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

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

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

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

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

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

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

注意:

クローニングした本番環境でアップグレード前の準備状況チェックを実行すれば、データで発生しうるアップグレード時の問題は特定できますが、正常なアップグレードの万全を期すためには、クローニングした環境で完全なテスト・アップグレードを実行する必要があります。

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

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

注意:

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

警告:

アップグレードを開始する前に、現在の環境に最新のパッチが適用されていることを確認してください。動作保証は、特に指定がないかぎり、完全にパッチが適用された環境に基づいています。

• 環境が動作保証要件を満たしていることの確認
  Oracleでは、動作保証済のすべてのシステムおよび環境で製品のパフォーマンスをテストおよび検証しています。製品をインストールする場合、サポートされているハードウェアまたはソフトウェア構成を使用します。
• システム要件と仕様の確認
  ディスク領域、使用可能なメモリー、特定のプラットフォーム・パッケージおよびパッチ、その他のオペレーティング・システム固有の項目などのシステム要件が満たされていることを確認することが重要です。
• Oracle Fusion Middlewareをホストするデータベースがサポートされているかどうかの確認
  Fusion Middleware 12cを実行する前に、サポートされるOracleデータベースを必須のスキーマで構成しておく必要があります。
• このリリースのOracle Fusion MiddlewareでJDKが動作保証されていることの確認。
  汎用インストーラを使用してOracle Fusion Middleware製品をインストールするには、サポートされているJDKをシステムにダウンロードしてインストールする必要があります。

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

Oracleでは、動作保証済のすべてのシステムおよび環境で製品のパフォーマンスをテストおよび検証しています。製品をインストールする場合、サポートされているハードウェアまたはソフトウェア構成を使用します。

新しい動作保証情報が発表された場合は、適切な動作保証ドキュメントにすぐに追加されます。新しい動作保証要件は随時確認される場合があるため、動作保証に関するドキュメントはドキュメント・ライブラリの外部に置かれ、Oracle Technology Networkで提供されています。詳細は、12c (12.2.1)の動作保証マトリックスに関する説明を参照してください。

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

ディスク領域、使用可能なメモリー、特定のプラットフォーム・パッケージおよびパッチ、その他のオペレーティング・システム固有の項目などのシステム要件が満たされていることを確認することが重要です。

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

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

注意:

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

2.3.3 Oracle Fusion Middlewareをホストするデータベースがサポートされているかどうかの確認。

Fusion Middleware 12cを実行する前に、サポートされるOracleデータベースを必須のスキーマで構成しておく必要があります。

アップグレード時のOracle Databaseの要件を理解し、Oracle Fusion Middlewareをホストするデータベースがサポートされており、アップグレードの実行に十分な領域が用意されていることを確認しているものとします。

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ビット・ターゲット・マシンを指します。

注意:

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

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

注意:

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

• アップグレードの64ビット・ソフトウェア要件をサポートするハードウェアを調達する
  アップグレード・プロセスを開始する前に、サポートされている適切なターゲット・ハードウェアが存在することを確認してください。
• 管理サーバー、管理対象サーバー、ノード・マネージャなどすべてのプロセスの停止
  管理サーバー、管理対象サーバーおよびノード・マネージャがホスト上で起動している場合はこれらも含めて、すべてのプロセスを停止する必要があります。
• 32ビット・ホスト・マシンからすべてのファイルをバックアップする
  11gデプロイメント全体の完全バックアップを作成したことを確認してからアップグレード・プロセスを開始する必要があります。移行中に問題が発生した場合、これらのファイルを使用してプロセスを再度開始する必要があります。
• 11gのホスト名およびIPアドレスを使用してターゲットの64ビット・マシンを設定する
  ターゲット・マシンのホスト名およびIPアドレスはホストと同一にする必要があります。そのため、ソース・マシンのIPアドレスおよび名前を変更するか、ソース・マシンを停止してネットワークの干渉を回避する必要があります。
• 11gバックアップを32ビット・ホストから64ビット・ホストにリストアする
  11gで使用したものと同じディレクトリ構造を使用して、タスク3でバックアップしたファイルをリストアします。ターゲット・マシンのディレクトリ構造は、ホスト・マシンのディレクトリ構造と同じである必要があります。
• 12c製品ディストリビューションをターゲット・マシンにインストールする
  アップグレードはホーム外で実行することをお薦めします。したがって、12c製品ディストリビューションは、ターゲット・マシン上の新しいOracleホームでインストールする必要があります。
• 標準的なアップグレード手順を使用してターゲットの64ビット環境をアップグレードする
  ターゲット・マシンに製品をインストールしたら、コンポーネント固有のアップグレード・ガイドで指定されたアップグレード・ユーティリティを使用して各コンポーネントを個々にアップグレードし、アップグレード後のタスクを実行する必要があります。

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

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

2.4.2 管理サーバー、管理対象サーバー、ノード・マネージャなどすべてのプロセスの停止

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

たとえば、管理サーバーを停止するには、次のコマンドを入力します。

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

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

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

注意:

同一のマシンで32ビットから64ビットへアップグレードする場合、アップグレードが失敗した場合、ソース環境が破損するリスクがあります。

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

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

• 11gドメイン・ホーム

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

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

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

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

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

2.4.5 11gのバックアップを32ビット・ホストから64ビット・ホストにリストアする

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

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

2.4.6 12c製品ディストリビューションをターゲット・マシンにインストールする

アップグレードには、ホーム外のアプローチをお薦めします。したがって、12c製品ディストリビューションは、ターゲット・マシン上の新しいOracleホームでインストールする必要があります。

12cディストリビューションの入手、インストール・ユーザーの指定、インストールと構成のディレクトリ構造の理解などについては、『Oracle Fusion Middlewareのインストールのプランニング』を参照してください。インストールするコンポーネントの詳細は、コンポーネント固有のインストール・ガイドを参照してください。

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

ターゲット・マシンに製品をインストールしたら、コンポーネント固有のアップグレード・ガイドで指定されたアップグレード・ユーティリティを使用して各コンポーネントを個々にアップグレードし、アップグレード後のタスクを実行する必要があります。

詳細なアップグレード手順は、アップグレードするコンポーネントのコンポーネント固有のアップグレード・ガイドを参照してください。

注意:

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

2.5 未使用データのパージ

アップグレード前に未使用データをパージすると、アップグレード・プロセスを最適化できます。一部のコンポーネントについては、自動パージ・スクリプトを使用でき、アップグレード前に実行して、使用されていないデータや古いデータをパージすることができます。

Oracle Data Integrator (ODI)コンポーネントの場合

次の手順で作業リポジトリのエクスポート/インポートの一部として過剰なデータがエクスポートおよびインポートされないように、実行ログをパージします。「ログのパージ」を参照してください

SOA Suiteコンポーネントの場合

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

注意:

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

「パージおよびパーティショニング方法の開発」と「データベース増分管理戦略の策定」を参照してください

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

アップグレードする前に、12cデプロイメント用の新しいスキーマを作成する必要がある場合があります。12c用として作成する必要がある追加のスキーマを確認するには、既存の環境にあるコンポーネント・スキーマとアップグレードに必要なスキーマを比較します。

コンポーネントに必要なスキーマを特定するには、コンポーネント固有のアップグレード・ガイドを参照してください。アップグレード・アシスタントは、アップグレードできるすべてのスキーマを識別し、アップグレードにすべてのスキーマを含めます。アップグレードが必要なスキーマを選択することもできます。詳細は、「アップグレード・アシスタントでアップグレードできるスキーマの識別」を参照してください。

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

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

  注意:

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

• 11g環境でまだOPSSスキーマを使用していない場合にも、12cでOPSSスキーマが必要です。

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

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

Oracle Fusion Middleware 12cでは、データベース・ベースのポリシー・ストアを使用します。データベース・ベースのポリシー・ストアは、本番環境で推奨されます。ファイルベースまたはOIDベースのポリシー・ストアを使用している場合、アップグレードの前に、ストアをデータベース・ベースのストアに再関連付けする必要があります。

ファイルベースのポリシー・ストアをデータベース・ベースのポリシー・ストアに再関連付けるには、データベースでOPSSスキーマを作成し、WebLogicサーバーにデータ・ソースを作成する必要があります。

データベース・ベースのポリシー・ストアを使用している場合、これらのタスクを実行する必要はありません。

• 11g OPSSおよびIAUスキーマの作成
  Oracle Platform Security Services (OPSS)セキュリティ・ストアにデータベース・リポジトリを使用するには、まずOracle Fusion Middleware Repository Creation Utility (RCU)を使用して必要なスキーマを作成し、一部の初期データをシードする必要があります。この設定は、OPSSセキュリティ・ストアをDBベースのセキュリティ・ストアに再関連付けする前にも必要です。
• 11gポリシー・ストアとデータベース・ベースのポリシー・ストアおよびOPSSスキーマの再関連付け
  OPSSセキュリティ・ストアは、システムやアプリケーションに固有のポリシー、証明資格、キーおよび監査サービスが格納されるリポジトリです。OPSSは、WebLogicサーバーで構成されているアイデンティティ・プロバイダにアイデンティティ・ストア・サービスを委譲します。追加設定なしですぐに使用できるOPSSセキュリティ・ストアはファイルベースです。データベース・ベースのセキュリティ・ストアに再関連付けする必要があります。
• ポリシー・ストアの再関連付けの成功の確認
  再関連付けによって、ドメイン構成ファイルDOMAIN_HOME/config/fmwconfig/jps-config.xmlが変更されます。古いストア・プロバイダの構成は削除され、新しいストア・プロバイダの構成が挿入されて、ポリシーと資格証明情報は、ソースからターゲットのストアに移動されます。

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

Oracle Platform Security Services (OPSS)セキュリティ・ストアにデータベース・リポジトリを使用するには、まずOracle Fusion Middleware Repository Creation Utility (RCU)を使用して必要なスキーマを作成し、一部の初期データをシードする必要があります。この設定は、OPSSセキュリティ・ストアをDBベースのセキュリティ・ストアに再関連付けする前にも必要です。

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スキーマへの再関連付け

OPSSセキュリティ・ストアは、システムやアプリケーションに固有のポリシー、証明資格、キーおよび監査サービスが格納されるリポジトリです。OPSSは、WebLogicサーバーで構成されているアイデンティティ・プロバイダにアイデンティティ・ストア・サービスを委譲します。追加設定なしですぐに使用できるOPSSセキュリティ・ストアはファイルベースです。データベース・ベースのセキュリティ・ストアに再関連付けする必要があります。

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

2.7.3 ポリシー・ストアの再関連付けの成功の確認

再関連付けによって、ドメイン構成ファイルDOMAIN_HOME/config/fmwconfig/jps-config.xmlが変更されます。古いストア・プロバイダの構成は削除され、新しいストア・プロバイダの構成が挿入されて、ポリシーと資格証明情報は、ソースからターゲットのストアに移動されます。

ポリシー・ストアの再関連付けの成功を確認する手順:

1. Enterprise Manager Fusion Middleware Controlにログインします。
2. 「ドメイン」→ 「セキュリティ」→「セキュリティ・プロバイダ構成」に移動します。
3. 「監査サービス」→「構成」をクリックします。
4. 「プロバイダ・タイプ」が「Oracle Database」に設定されていることを確認します。「プロバイダ・タイプ」に「ファイル」と表示されている場合、再関連付けは成功していません。
   

2.7.3.1

あるいは、jps-config.xmlファイルを確認する方法もあります。credstore.db、policystore.db、keystore.dbの各サービス・インスタンスは、props.db.1プロパティを介してデータベースを参照します。

再関連付け後、jps-config.xmlファイルには次のように表示される必要があります。

<jpsContext name="default"
<serviceInstanceRef ref="credstore.db"/>
<serviceInstanceRef ref="keystore.db"/>
<serviceInstanceRef ref="policystore.db"/>
<serviceInstanceRef ref="audit"/>
<serviceInstanceRef ref="idstore.ldap"/>
<serviceInstanceRef ref="trust"/>
<serviceInstanceRef ref="pdp.service"/>
</jpsContext>

<serviceInstance provider="policystore.provider" name="policystore.db"
 <property value="DB_ORACLE" name="policystore.type"/>
 <propertySetRef ref="props.db.1"/>
</serviceInstance>

<propertySet name="props.db.1">
  <property value="cn=soa_domain" name="oracle.security.jps.farm.name"/>
  <property value="cn=jpsroot" name="oracle.security.jps.ldap.root.name"/>
  <property value="jdbc/opss" name="datasource.jndi.name"/>
</propertySet>

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

LDAPベースのOPSSセキュリティ・ストアでサポートされているのは、Oracle Internet Directory (OID)のみです。LDAPベースのポリシー・ストアは、通常、本番環境で使用します。11gでOIDベースのセキュリティ・ストアを使用している場合、リポジトリ作成ユーティリティ(RCU)を使用して、新しい12cスキーマを作成する必要があります。

アップグレード前に、OIDベースのセキュリティ・ストアを再関連付けする必要はありません。アップグレード・アシスタントの実行中に、OPSSスキーマを選択します。アップグレード・アシスタントは、OIDベースのセキュリティ・ストアを自動的にアップグレードします。

注意:

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

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

最新バージョンのOPSSセキュリティ・ストアにアップグレードすると、強化された機能と修正を利用できます。OPSSセキュリティ・ストアは、Oracle Fusion Middleware製品インストールの一部なので、アップグレード・アシスタントを使用して直接、OPSSスキーマをアップグレードできます。

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

schema_name

システムに存在するOPSSスキーマのバージョンを確認するには、データベースに対して次の問合せを実行します。

SELECT VERSION, STATUS, UPGRADED
FROM SCHEMA_VERSION_REGISTRY
WHERE OWNER=’schema_name’;

ここで、schema_nameはOPSSスキーマの名前です。たとえば、DEV_OPSSなどです。

アップグレード・アシスタントを使用してOPSSスキーマをアップグレードする手順:

1. 次のコマンドを入力してアップグレード・アシスタントを起動します。
   cd oracle_common/upgrade/bin
   ./ua
2. 左ペインで「スキーマ」を選択し、「次」をクリックします。
3. 「スキーマ」ページで「スキーマ」を選択し、「次」をクリックします。
4. 「使用可能なコンポーネント」ページで「Oracle Platform Security Services」を選択し、「次」をクリックします。
5. 「前提条件」ページで、リストされているすべての前提条件が満たされていることを確認します。次にすべてのチェック・ボックスをチェックし、「次」をクリックします。
6. 正しいIAUおよびOPSSスキーマの詳細を慎重に入力します。
7. 左ペインで「アップグレード・サマリー」をクリックします。「アップグレード・サマリー」ページに、アップグレードするスキーマが表示されます。
8. 「アップグレード」をクリックします。「アップグレードの進行状況」ページに、アップグレードの進行状況と最終的なステータスが表示されます。
   アップグレードが完了したら、「終了」をクリックしてインストーラを終了します。
   すでにドメインを作成している場合は、「アップグレード・アシスタントによるスキーマのアップグレード」のトピックで使用できる手順に従ってください。

2.10 非SYSDBAユーザーの作成

アップグレード・アシスタントを実行するには、非SYSDBAを作成することをお薦めします。この手順で作成したユーザーには、アップグレードの完了に必要な権限が付与されます。

SYSDBAはデータベースの作成、起動、停止、バックアップまたはリカバリなどの高度な管理操作を実行するために必要な管理権限です。SYSDBAシステム権限は、完全な権限を持つデータベース管理者が使用します。SYSDBA権限で接続すると、通常はユーザー名に関連付けられているスキーマではなく、デフォルトのスキーマで接続が確立されます。SYSDBAの場合、このスキーマはSYSです。デフォルト・スキーマへのアクセスは非常に強力な権限となる場合があります。たとえば、ユーザーSYSとして接続する場合、データ・ディクショナリの表における権限は無制限となります。したがって、スキーマをアップグレードするには、非SYSDBAユーザーを作成することをお薦めします。アップグレード・アシスタントを起動する前に、このトピックにリストされている権限を付与する必要があります。

注意:

v$xatrans$表は、デフォルトでは存在しません。ユーザーを作成する前に、XAVIEW.SQLスクリプトを実行して、この表を作成する必要があります。また、v$xatrans$表に対する権限付与が必要なのはOracle Identity Managerの場合のみです。構成にOracle Identity Managerが必要ない場合、またはv$xatrans$表が存在しない場合は、次の行をスクリプトから削除します。

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

次の例では、welcome1がパスワードです。権限を付与する際に、実際のパスワードを指定していることを確認します。

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;
grant select on dba_queue_subscribers to FMW with grant option; 
grant execute on SYS.DBMS_ASSERT to FMW with grant option;

注意:

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

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

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

Javaプラットフォームでは、暗号化、公開鍵インフラストラクチャ、認証、安全な通信、アクセス制御など、主要なセキュリティ分野に渡る一連のAPIが定義されています。このAPIを使用すると、開発者はセキュリティ・メカニズムを簡単にアプリケーション・コードに組み込むことができます。強化された暗号化(AES 256など)を使用する予定がある場合は、アップグレードの前に、これらのポリシー・ファイルをJDKに適用することをお薦めします。

Fusion Middleware 12cで使用されているセキュリティ・アルゴリズムには、JDK用の追加のポリシー・ファイルが必要になるものがあります。詳細は、Java暗号化アーキテクチャOracleプロバイダのドキュメントを参照してください。

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

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

エディション・ベースの再定義を使用すると、アプリケーションの使用中にそのOracleデータベース・コンポーネント、たとえばPL/SQLオブジェクトやビュー、シノニムをアップグレードでき、停止時間を最小化あるいは排除することができます。

注意:

このタスクは、DBA権限を持つOracle Databaseユーザーのみが実行する必要があります。

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

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

create edition Oracle_FMW_12_2_1 as child of Oracle_FMW_11_1_1_7_0;

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

エディションが正常に作成されると、次のメッセージが表示されます。

エディションが作成されました。

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

ALTER DATABASE DEFAULT EDITION = Oracle_FMW_12_2_1;

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

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

カスタム・ドメイン・レベルの環境設定を維持するには、アップグレードの前に、カスタム・ドメイン情報を格納するファイルを別途作成してください。

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

setUserOverridesファイルにおける起動のカスタマイズの例を次に示します。

# add custom libraries to the WebLogic Server system claspath
  if [ "${POST_CLASSPATH}" != "" ] ; then
    POST_CLASSPATH="${POST_CLASSPATH}${CLASSPATHSEP}${HOME}/foo/fooBar.jar"
    export POST_CLASSPATH
  else
    POST_CLASSPATH="${HOME}/foo/fooBar.jar"
    export POST_CLASSPATH
  fi
 
# specify additional java command line options for servers
JAVA_OPTIONS="${JAVA_OPTIONS}  -Dcustom.property.key=custom.value"

サーバーの起動中にsetUserOverridesファイルが存在する場合、このファイルが起動シーケンスに含まれ、このファイルにオーバーライドがあれば、有効になります。setUserOverridesファイルは、domain_home/binディレクトリに格納する必要があります。

注意:

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

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

Oracle Fusion Middleware製品ディストリビューションは、Oracle Technology Network (OTN)とOracle Software Delivery Cloudでダウンロードできます。

ディストリビューションを取得するためにアクセスする必要のあるサイトの詳細な情報は、「Oracle Fusion Middlewareダウンロード、インストールおよび構成のReadmeファイル」ページを参照してください。

必要なソフトウェアをダウンロードしたら、ソフトウェアのインストールと構成を続行できます。

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

注意:

コンポーネント固有のディストリビューションをインストールする前に、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 コンポーネント固有のアップグレード・ドキュメントの検索

コンポーネント固有のアップグレード・ドキュメントには、Oracle WebLogic Server、Oracle Fusion Middleware Infrastructure、Oracle HTTP Server、Oracle SOA Suite and Oracle Business Process Management、Oracle Webcenter、User Messaging Service、Oracle Data Integratorなど個々のコンポーネントごとのアップグレード手順と情報が記載されています。

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のアップグレード
Oracle WebCenter	WebCenterスイート・コンポーネントには、コンテンツ、ポータル、サイトが含まれています。	Oracle WebCenterのアップグレード
Oracle Business Intelligence	Oracle Business Intelligenceには、BI Enterprise Edition、BI Publisher、Essbaseが含まれています。	Oracle Business Intelligenceのアップグレード
Oracle Forms	Oracle Forms。	Oracle Formsのアップグレード