プライマリ・コンテンツに移動
Oracle® Fusion Middleware SOA SuiteおよびBusiness Process Managementのアップグレード
12c (12.2.1)
E72522-01
目次へ移動
目次

前
次

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

アップグレード・プロセスを開始する前に、該当するタスクをすべて完了してください。これを行わないと、アップグレードが失敗する場合があります。

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

注意:

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

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

表3-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)データベースを使用している場合にのみ必要です。

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

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

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

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

アップグレードを開始する前に、本番環境で準備状況チェックを実行します。 Upgrade Assistantを-readinessモードで実行して、正常なアップグレードの障害になりかねない問題を検出することができます。 アップグレード前の準備状況チェックの実行

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

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

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

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

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

詳細は、Oracle Fusion Middleware環境のバックアップに関する項および「12cのためのOracle Databaseのアップグレードおよび準備」を参照してください

3.2 本番環境のテスト用クローニング(推奨)

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

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

本番環境のクローンでアップグレードを実行すると、次のようなメリットもあります。
  • アップグレードに関する問題を明らかにし、修正します。

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

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

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

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

注意:

クローン本番環境でアップグレード前の準備状況チェックを実行して、データに関して発生する可能性のあるアップグレードの問題点の識別の助けにすることはできますが、アップグレードの成功を確実にするには、クローン環境で完全なテスト・アップグレードを実行する必要があります。

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

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

注意:

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

警告:

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

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

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

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

3.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のファイルおよびディレクトリに確実に適用されます。

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

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

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

3.3.4 Oracle Fusion Middlewareのこのリリースに対してJDKが動作保証されているかどうかの確認。

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

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

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

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

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

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

注意:

これらの手順は、データベースが別のホスト上にあり、移動されないことを前提としています。
オペレーティング・システムのアップグレードには、通常、次の内容が含まれます。

注意:

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

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

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

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

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

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

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

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

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

注意:

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

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

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

  • 11gドメイン・ホーム

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

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

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

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

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

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

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

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

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

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

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

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

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

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

注意:

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

3.5 未使用データのパージ

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

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

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

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

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

注意:

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

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

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

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

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

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

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

    注意:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

再関連付けすると、ドメイン構成ファイル(DOMAIN_HOME/config/fmwconfig/jps-config.xml)が変更されます。古いストア・プロバイダの構成がすべて削除され、新しいストア・プロバイダの構成が追加されます。それにより、ポリシーと資格証明に関する情報が移行元ストアから移行先ストアに移動します。

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

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

3.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>

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

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

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

注意:

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

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

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

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

schema_name
システムに存在するOPSSスキーマのバージョンを確認するには、データベースで次の問合せを実行します。
SELECT VERSION, STATUS, UPGRADED
FROM SCHEMA_VERSION_REGISTRY
WHERE OWNER=’schema_name’;

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

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

3.10 SYSDBA以外のユーザーの作成

SYSDBA以外のユーザーを作成してUpgrade Assistantを実行することをお薦めします。この手順を使用して作成されたユーザーは、アップグレードを完了するために必要な権限を持っています。

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

注意:

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にアクセスしてパッチをダウンロードします。

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

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

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

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

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

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

エディション・ベースの再定義を使用すると、アプリケーションの使用中にそのOracle Databaseコンポーネント(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;

3.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スクリプトを作成できない場合は、「起動スクリプトへのカスタマイズの再適用」の説明に従って、設定を再適用する必要があります。

3.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ディストリビューションをインストールする必要があります。

3.15 Upgrade Assistantを使用したアップグレード前の準備状況チェックの実行

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

システムがオンラインの状態で準備状況チェックを実行できます。チェック内容の包括度により異なりますが、準備状況チェックが完了するまでに長時間かかることがあります。オフピーク時にチェックを実行することを検討してください。
アップグレード前環境で準備状況チェックを実行するには、Upgrade Assistantを-readinessモードで起動します。
  1. ディレクトリを、UNIXオペレーティング・システムの場合はORACLE_HOME/oracle_common/upgrade/binに、Windowsオペレーティング・システムの場合はORACLE_HOME\oracle_common\upgrade\binに変更します。
  2. UNIXオペレーティング・システム上でUpgrade Assistantを開始するには:
    ./ua -readiness
  3. Windowsオペレーティング・システム上でUpgrade Assistantを開始するには:
    ua.bat -readiness
  4. Upgrade Assistantの各画面で必要な情報を指定します。

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

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

コンポーネント固有のアップグレード・ドキュメントには、Oracle WebLogic Server、Oracle Fusion Middleware Infrastructure、Oracle HTTP Server、Oracle SOA SuiteとOracle Business Process Management、Oracle Webcenter、ユーザー・メッセージング・サービスおよびOracle Data Integratorなど、個々のコンポーネントすべてに関するアップグレードの手順や情報が記載されています。

次の表を参考に、12cのアップグレードに必要なアップグレード固有のタスクを決定してください。

表3-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のアップグレード

User Messaging Service

User Messaging Service。

Oracle User Messaging Serviceの管理

Oracle Data Integrator

Data Integrator。

Oracle Data Integratorのアップグレード

Oracle WebCenter Content、PortalおよびSitesなどのWebCenter Suiteコンポーネント。 Oracle WebCenterのアップグレード
Oracle Business Intelligence BI Enterprise Edition、BI PublisherおよびEssbaseなどのOracle Business Intelligence。 Oracle Business Intelligenceのアップグレード
Oracle Forms Oracle Forms。 Oracle Formsのアップグレード