1. SOA SuiteおよびBusiness Process Managementのアップグレード
  2. Oracle Fusion Middlewareのアップグレード前タスク

2 Oracle Fusion Middlewareのアップグレード前タスク

アップグレード・プロセスを開始する前に、必ず、ご使用のコンポーネントおよび環境に必要なアップグレード前タスクを完了てください。

アップグレードを開始する前に、必要なアップグレード前タスクを完了しておく必要があります。必要なタスクを完了しないと、アップグレードが失敗したり、システムの停止時間が長引いたりする可能性があります。各自のデプロイメントに該当するタスクのみを完了してください。

ノート:

アップグレードするOracle SOA製品によっては、追加のアップグレード前タスクを実行する必要がある場合があります。Oracle Service Busやユーザー・メッセージング・サービスなどの製品には、アップグレード前およびアップグレード後の追加構成タスクが必要になることがあります。

Oracle Fusion Middlewareのアップグレード前チェックリスト

アップグレードを成功させて停止時間を少なくするために、アップグレードを開始する前に、このチェックリスト内の作業を実行します。

アップグレードはサーバーが停止している間に実行されます。このチェックリストでは、重要で、多くの場合時間のかかるアップグレード前タスクのうち、停止時間を限度内にとどめるためにアップグレード前に実行できるタスクを特定します。アップグレード・プロセスの開始前に行える準備が多いほど、オフラインでかかる時間が少なくなります。

ノート:

実行するアップグレード前手順は、既存のシステムの構成、アップグレードするコンポーネント、およびアップグレードと構成プロセスの最後に作成する環境によって異なります。各自の構成やユースケースに該当するタスクのみを完了してください。

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

タスク 説明

必須

既存の環境の完全なバックアップを作成します。

アップグレードしようとしているスキーマを含めて、システムに重要なファイルとデータベースをすべてバックアップします。アップグレードに失敗した場合、アップグレード前の環境をリストアして、アップグレードを再度開始する必要があります。

「完全なバックアップの作成」を参照してください。

オプション

オンライン・リカバリ操作用の追加のバックアップ・ファイルを作成します。

アップグレードが失敗し、オンライン・リカバリを実行する必要がある場合は、リカバリを容易にするために追加のバックアップ・ファイルを生成することをお薦めします。

オプション

使用する本番環境を、アップグレードのテスト用プラットフォームとしてクローンします。

システム・ファイルの完全なバックアップを作成するだけでなく、本番環境をクローニングしておくことも強くお薦めします。この環境は、アップグレードをテストするために使用されます。

「本番環境のテスト用クローニング」を参照してください

必須

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

注意:

サポートされている最新のオペレーティング・システムを使用できない場合はアップグレードしないでください。サポート対象のすべての構成と同様、こうした要件を守れない場合は、アップグレードが失敗する可能性があります。

(オペレーティング・システムを含む)ハードウェアとソフトウェアの構成が最新の動作保証および要件のドキュメントでサポートされていることを確認します。また、12c製品のディストリビューションをインストールする前に、サポート対象バージョンのJDKを使用していることを確認してください。

動作保証の要件は頻繁に更新されるため、アップグレードの開始直前にこの情報を確認することをお薦めします。

ノート:

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

動作保証とシステム要件の確認に関する項を参照してください。

32ビット・オペレーティング・システムのみで必要

アップグレードの前に、64ビット・オペレーティング・システムに移行します。

これは、現在サポート対象外の32ビット・オペレーティング・システムを実行している場合にのみ必要になります。

「32ビットから64ビット・オペレーティング・システムへの移行」を参照してください。

オプション

強化された暗号化(AES 256)を使用している場合は、セキュリティ・ポリシー・ファイルを更新します。

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

強化された暗号化(AES 256など)を使用する予定がある場合は、アップグレードする前に、最新の必要なポリシー・ファイルをJDKに適用することをお薦めします。

「強化された暗号化(AES 256)を使用する際のポリシー・ファイルの更新」を参照してください。

オプション

アップグレードする前に、期限切れまたは未使用のデータをパージします。

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

「未使用データのパージ」を参照してください。

Oracle Databaseユーザーのみ必要

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

エディション・ベースの再定義(EBR)データベースを使用している場合、アップグレードの開始前にエディションを作成する必要があります。

「エディション・ベースの再定義のためのサーバー上でのエディションの作成」を参照してください。

オプション

Upgrade Assistantを実行するために非SYSDBAユーザーを作成します。

Upgrade Assistantを実行するには、FMWユーザーを作成することをお薦めします。ユーザーFMWは、システム管理権限なしでUpgrade Assistantを実行できます。

「Upgrade Assistantを実行するための非SYSDBAユーザーの作成」を参照してください。

親トピック: Oracle Fusion Middlewareのアップグレード前タスク

完全なバックアップの作成

アップグレードを開始する前に、Oracle Fusion Middlewareスキーマをホストするすべてのデータベースを含め、システムに重要なファイルをすべてバックアップします。

アップグレードが失敗した場合にコンテンツをそのアップグレード前の状態にリストアできるよう、バックアップにはSYSTEM.SCHEMA_VERSION_REGISTRY$表が含まれている必要があります。

実際のアップグレードに進む前に、Upgrade Assistantの「前提条件」画面に、バックアップを実行してあることの確認を求めるメッセージが表示されます。ただし、Upgrade Assistantではバックアップが作成されていることは確認しないため注意してください。

関連項目:
  • スキーマ・バージョン・レジストリ表のバックアップ
    システム・バックアップには、SYSTEM.SCHEMA_VERSION_REGISTRY$表またはFMWREGISTRY.SCHEMA_VERSION_REGISTRY$表を含める必要があります。
  • カスタマイズされたドメイン設定および環境設定のメンテナンス
    アップグレード前の環境において、ドメインで生成されたスクリプト、サーバー起動スクリプトまたは構成ファイルを変更した場合は、これらの変更内容がインストール、ドメイン・アップグレードおよび再構成の操作中に上書きされることに注意する必要があります。アップグレード後に継続して使用できるように、カスタマイズされたファイルを共有ライブラリの場所に保存してください。

親トピック: Oracle Fusion Middlewareのアップグレード前タスク

スキーマ・バージョン・レジストリ表のバックアップ

システム・バックアップには、SYSTEM.SCHEMA_VERSION_REGISTRY$表またはFMWREGISTRY.SCHEMA_VERSION_REGISTRY$表を含める必要があります。

SYSTEM.SCHEMA_VERSION_REGISTRY$表に、各Fusion Middlewareスキーマに対応する行があります。Upgrade Assistantを実行して既存のスキーマを更新する際、正常に更新できなかった場合は、元のスキーマをリストアしてからやりなおす必要があります。アップグレード・アシスタントを実行する前に、既存のデータベース・スキーマおよびスキーマ・バージョン・レジストリを必ずバックアップします。

ノート:

アップグレード・アシスタントを使用してスキーマをアップグレードする前に、完全なデータベースのバックアップを実行する必要があります。アップグレード中に、バックアップが実行されていることを確認する必要があります。

親トピック: 完全なバックアップの作成

カスタマイズされたドメインおよび環境設定の保持

アップグレード前環境で、ドメインで生成されたスクリプト、サーバー起動スクリプトまたは構成ファイルを変更した場合、これらの変更内容がインストール、ドメイン・アップグレードおよび再構成の操作中に上書きされることに注意することが重要です。アップグレード後に継続して使用できるように、カスタマイズされたファイルを共有ライブラリの場所に保存してください。

すべてのドメイン・インストールには、動的に生成されたドメイン、およびsetDomainEnvなどのサーバー起動スクリプトが含まれています。これらのファイルは、インストールおよびアップグレード・プロセスの間に新しいバージョンに置き換えられます。カスタムのドメインレベルの環境設定を保持するには、スクリプトを直接変更するのではなく、アップグレードする前に別のファイルを作成してカスタムのドメイン情報を格納することをお薦めします。

たとえば、ドメイン内のすべてのサーバーに適用されるサーバー起動パラメータをカスタマイズする場合は、setUserOverrides.cmd (Windows)またはsetUserOverrides.sh (UNIX)という名前のファイルを作成することにより、WebLogic Serverクラスパスにカスタム・ライブラリを追加する、サーバー実行用の追加のコマンドライン・オプションを指定する、または追加の環境変数を指定するなどの構成が可能です。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ファイルは、EXISTING_DOMAIN_HOME/binディレクトリに格納する必要があります。

ノート:

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

親トピック: 完全なバックアップの作成

オンライン・バックアップおよびリカバリに関する特別な考慮事項

環境に複数のミドルウェア・ホームが含まれ、アップグレードの障害後の完全データベース・リストアの実行が望ましいオプションでない場合は、これらの追加のバックアップを実行します。

完全データベース・リストアの影響を理解する

バックアップおよびリカバリ計画を作成する場合、完全データベース・リストアの影響を理解することが重要です。アップグレードが失敗した場合は、完全データベース・リストアの実行が必要な場合があります。しかし、これが可能でない場合や、望ましくない場合もあります。

  • 単一のFMWホームがアップグレードされるときにオンラインのままになる必要がある、本番環境によって共有されているデータベースであるか。

  • 失敗したアップグレードからリカバリするときにデータベースはオンラインのままになる必要があるか。

  • 完全データベース・リストアの実行は、失敗したアップグレードからリカバリするための望ましくない解決策か。

次のいずれかの質問に対する答えが「はい」の場合は、開始する前に、これらの追加のアップグレード前タスクを完了します。

親トピック: Oracle Fusion Middlewareのアップグレード前タスク

SYSが所有するオブジェクトに対する権限の保存

アップグレードが失敗した場合、SYSが所有するオブジェクトに対するすべての権限は、スキーマが削除されたときに失われます。必要に応じて権限の再適用に使用できるスクリプトを作成することをお薦めします。

このスクリプトの作成方法の例を次に示します。 生成されたSQLスクリプトについては次の点に注意してください。 
  • スプールされた出力をSQLPlusによって実行する前に編集する必要があり、SQL問合せのテキストと"spool off"コマンドをスプールされたファイルから削除する必要があります。
  • 一部の権限は、スキーマの削除/インポート後に適用される場合にエラーを返すことがあります。 これが致命的なエラーとならない例を次にいくつか示します。
    - 権限がすでに存在する
    - 権限オブジェクトの名前がスキーマの作成時に動的に生成される。たとえば、詳細なキューイング・ビューの名前はQTnnnnnnnn_BUFFERです。
権限を再適用するスクリプトを作成するためのサンプルSQLPlusコマンド:
# The schema prefix in this example is "DEV"
$ORACLE_HOME/bin/sqlplus username/password
exec dbms_metadata.set_transform_param(dbms_metadata.SESSION_TRANSFORM,'SQLTERMINATOR',TRUE); 
set long 100000
set longchunksize 100000
set lines 1000
set termout off echo off newp 0 spa 0 pages 0 feed off head off trims on tab off
spool /tmp/create-grants.sql
select dbms_metadata.get_granted_ddl ('OBJECT_GRANT',username) from all_users where username in ('DEV_MDS', 'DEV_IAU', 'DEV_IAU_APPEND', 'DEV_IAU_VIEWER', 'DEV_OPSS', 'DEV_UMS', 'DEV_WLS', 'DEV_SOAINFRA', 'DEV_STB', 'DEV_ESS')
union all
select dbms_metadata.get_granted_ddl ('SYSTEM_GRANT',username) from all_users where username in ('DEV_MDS', 'DEV_IAU', 'DEV_IAU_APPEND', 'DEV_IAU_VIEWER', 'DEV_OPSS', 'DEV_UMS', 'DEV_WLS', 'DEV_SOAINFRA', 'DEV_STB', 'DEV_ESS')
union all
select dbms_metadata.get_granted_ddl ('DEFAULT_ROLE',username) from all_users where username in ('DEV_MDS', 'DEV_IAU', 'DEV_IAU_APPEND', 'DEV_IAU_VIEWER', 'DEV_OPSS', 'DEV_UMS', 'DEV_WLS', 'DEV_SOAINFRA', 'DEV_STB', 'DEV_ESS');
spool off

親トピック: オンライン・バックアップおよびリカバリに関する特別な考慮事項

アップグレード前のスキーマのエクスポート

データ・ポンプ・エクスポートを使用して、アップグレードされるスキーマをバックアップします。

データ・ポンプの使用方法の詳細は、『Oracle Databaseユーティリティ』のOracle Data Pumpに関する項を参照してください。
次の例はエクスポートのサンプルです。
# The schema prefix in this example is "DEV"
# The schemas being exported are for the SOA, BPM and ESS environments
$ORACLE_HOME/bin/sqlplus username/password
create directory data_pump_directory as '/scratch/db12cr2/export';
 
expdp username/password schemas=DEV_STB,DEV_SOAINFRA,DEV_IAU_VIEWER,DEV_MDS,DEV_IAU_APPEND,DEV_WLS,DEV_UMS,DEV_OPSS,DEV_IAU,DEV_ESS directory=data_pump_directory dumpfile=export.dmp compression=ALL

親トピック: オンライン・バックアップおよびリカバリに関する特別な考慮事項

アップグレードの前のキューの状態の識別

アップグレードが失敗した場合は、キューを手動で再起動する必要があります。これらのキューのインベントリを取得して、その再起動を支援します。

単一スキーマのリストアでは、インポートされるキューは再起動されません。有効になっているキューをすべて再起動する必要があります。次の例は、アップグレードが失敗した場合に再起動する必要のあるキューのリストの生成に使用できるSQLコマンドを示しています。各スキーマ所有者に適切なスキーマ接頭辞を提供します。
set pagesize 20;
set linesize 200;
COLUMN OWNER FORMAT A50
COLUMN NAME FORMAT A50
select owner,name,enqueue_enabled,dequeue_enabled from dba_queues where owner='DEV_SOAINFRA';

親トピック: オンライン・バックアップおよびリカバリに関する特別な考慮事項

テストのための本番環境のクローニング

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

テスト用に本番環境をクローニングすることをお薦めしますが、必須ではありません。

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

ノート:

このドキュメントでは、すべてのコンポーネントおよびオペレーティング・システムのクローニング手順を記載していません。クローニング手順は、コンポーネントおよびオペレーティング・システムに固有です。大まかに言えば、コンポーネント・ドメインのアップグレード前バージョンをテスト・マシンにインストールし、リポジトリ作成ユーティリティ(RCU)を使用して必要なスキーマを作成して、アップグレードを実行します。
本番環境のクローンでアップグレードを実行すると、次のようなメリットもあります。

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

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

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

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

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

ノート:

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

親トピック: Oracle Fusion Middlewareのアップグレード前タスク

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

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

ノート:

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

警告:

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

親トピック: Oracle Fusion Middlewareのアップグレード前タスク

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

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

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

親トピック: 動作保証およびシステム要件の確認

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

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

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

ノート:

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

32ビット環境を実行している場合は、さらに一連のステップを実行する必要があります。

親トピック: 動作保証およびシステム要件の確認

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

32ビットのオペレーティング・システムを使用している場合は、アップグレード前に、32ビット環境を64ビット・ソフトウェア環境に移行する必要があります。

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

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

ノート:

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

注意:

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

親トピック: システム要件と仕様の確認

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

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

すべてのプロセスを停止する

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

管理対象サーバーを停止します

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

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

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

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

管理サーバーを停止します

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

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

  • (UNIX) EXISTING_DOMAIN_HOME/bin/stopWebLogic.sh

  • (Windows) EXISTING_DOMAIN_HOME\bin\stopWebLogic.cmd

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

ノード・マネージャの停止

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

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

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

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

ノート:

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

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

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

  • 12c_DOMAIN_HOME

  • 12c_ORACLE_HOME/wlserver/common/にある12c/nodemanagerディレクトリ

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

12c (12.2.1.2.0)のホスト名およびIPアドレスを使用してターゲットの64ビット・マシンを設定する

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

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

12c (12.2.1.2.0)のバックアップを32ビット・ホストから64ビット・ホストにリストアする

12c (12.2.1.2.0)で使用したものと同じディレクトリ構造を使用して、32ビット・ホストからバックアップしたファイルをリストアします。ターゲット・マシンのディレクトリ構造は、ホスト・マシンのディレクトリ構造と同じである必要があります。

詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のリカバリに関する項を参照してください。

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

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

インストールするコンポーネントの詳細は、コンポーネント固有のインストール・ガイドを参照してください。

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

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

追加のコンポーネントをアップグレードする場合、コンポーネント固有のアップグレード・ガイドを参照してください。

ノート:

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

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

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

アップグレードを開始する前にFusion Middlewareデータベース要件を確認し、Oracle Fusion Middlewareをホストするデータベースがサポートされており、アップグレードを実行するための十分なスペースがあることを確認します。12c (12.2.1.3.0)の動作保証マトリックスに関する説明を参照してください。

ノート:

ご使用のデータベース・バージョンがサポート対象外だった場合は、アップグレードを開始する前に、サポート対象のバージョンにアップグレードする必要があります。『Oracle Fusion Middlewareのアップグレードのプランニング』の「12c (12.2.1.3.0)のためのOracle Databaseのアップグレードおよび準備」を参照してください。

親トピック: 動作保証およびシステム要件の確認

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

このマニュアルの発行時点で、12c (12.2.1.3.0)の動作保証済JDKは、1.8.0_131です。

Oracle Technology Network (OTN)で、Oracle Fusion Middlewareのサポート対象システム構成 に関する情報を参照して、現在使用しているJDKがサポートされていることを確認します。

ご使用のJDKがサポートされていないか、JDKをインストールしていない場合は、次のWebサイトから、必要なJava SE JDKをダウンロードする必要があります。
http://www.oracle.com/technetwork/java/javase/downloads/index.html

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

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

親トピック: 動作保証およびシステム要件の確認

強化された暗号化(AES 256)の使用時のポリシー・ファイルの更新

アップグレードされる環境で強化された暗号化(Advanced Encryption Standard (AES) 256など)を使用する予定の場合は、アップグレードする前に、最新の必要なポリシー・ファイルをJDKに適用することをお薦めします。

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

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

ノート:

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

親トピック: Oracle Fusion Middlewareのアップグレード前タスク

未使用データのパージ

アップグレード前に未使用データをパージしてパージ方法を管理すると、アップグレード・プロセスを最適化できます。

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

親トピック: Oracle Fusion Middlewareのアップグレード前タスク

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

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

エディションベースの再定義を使用すると、アプリケーションの使用中にアプリケーションのデータベース・オブジェクトをアップグレードできるため、停止時間を最小限に抑えることや解消することが可能です。これは、エディションと呼ばれるプライベート環境でデータベース・オブジェクトを変更(再定義)することにより実行します。すべての変更が実行およびテストされている場合のみ、アプリケーションの新バージョンをユーザーが使用できるようにしてください。

ノート:

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

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

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

create edition Oracle_FMW_12_2_1_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_1;

親トピック: Oracle Fusion Middlewareのアップグレード前タスク

Upgrade Assistantを実行するための非SYSDBAユーザーの作成

Upgrade Assistantを実行するために、FMWという名前の非SYSDBAを作成することをお薦めします。このユーザーには、スキーマの変更に必要な権限はありますが、完全な管理者権限はありません。

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

ノート:

SYSDBAではないユーザーFMWは、アップグレード・アシスタントを実行するためにのみ作成されます。このステップが完了したら、このFMWユーザーを削除してください。アップグレード・アシスタントを実行するために必要な権限は、リリースごとに異なる可能性があります。
デフォルトでは、v$xatrans$表は存在しません。ユーザーを作成する前に、XAVIEW.SQLスクリプトを実行して、この表を作成する必要があります。さらに、v$xatrans$表のgrant select権限は、Oracle Identity Governanceでのみ必要です。構成にOracle Identity Governanceが必要ない場合、またはv$xatrans$表が存在しない場合は、次の行をスクリプトから削除します。 
   grant select on v$xatrans$ to FMW with grant option;
次の例では、passwordはFMWユーザーに対して設定されたパスワードです。権限を付与する際は、必ず実際のパスワードを指定してください。
create user FMW identified by password;
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_TABLESPACE_USAGE_METRICS 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;
grant select on dba_subscr_registrations to FMW with grant option;
grant manage scheduler to FMW;

Oracle Identity Manager (OIM)スキーマをアップグレードする場合は、FMWユーザーに次の追加の権限が付与されていることを確認します。

grant execute on SYS.DBMS_FLASHBACK to fmw with grant option;
grant execute on sys.DBMS_SHARED_POOL to fmw with grant option;
grant execute on SYS.DBMS_XMLGEN to FMW with grant option;
grant execute on SYS.DBMS_DB_VERSION to FMW with grant option;
grant execute on SYS.DBMS_SCHEDULER to FMW with grant option;
grant execute on SYS.DBMS_SQL to FMW with grant option;
grant execute on SYS.DBMS_UTILITY to FMW with grant option;
grant ctxapp to FMW with admin option;
grant execute on SYS.DBMS_FLASHBACK TO FMW with grant option;
grant create MATERIALIZED VIEW to FMW with admin option;
grant all on SCHEMA_VERSION_REGISTRY TO FMW with grant option;
grant create SYNONYM to FMW with admin option;
grant execute on CTXSYS.CTX_ADM to FMW with grant option;
grant execute on CTXSYS.CTX_CLS TO FMW with grant option;
grant execute on CTXSYS.CTX_DDL TO FMW with grant option;
grant execute on CTXSYS.CTX_DOC TO FMW with grant option;
grant execute on CTXSYS.CTX_OUTPUT TO FMW with grant option;
grant execute on CTXSYS.CTX_QUERY TO FMW with grant option;
grant execute on CTXSYS.CTX_REPORT TO FMW with grant option;
grant execute on CTXSYS.CTX_THES TO FMW with grant option;
grant execute on CTXSYS.CTX_ULEXER TO FMW with grant option;
grant create JOB to FMW with admin option;

親トピック: Oracle Fusion Middlewareのアップグレード前タスク

SOA固有のアップグレード前タスクの実行

アップグレード前の環境によっては、Oracle Fusion Middlewareアップグレード前の要件に加えて、SOA固有の追加アップグレード・タスクを完了しておく必要がある場合もあります。

SOA、Business Process Managementおよび統合製品に適用されるアップグレード前のタスクを確認します。各自の環境に当てはまるタスクのみを実行してください。

注意:

アップグレードの準備を適切に行わないことが、リカバリ不能なエラーやアップグレードの失敗につながります。アップグレードの開始前に、該当するすべてのアップグレード前タスクが完了していることを確認してください。

アップグレード前タスク 詳細情報

必須

環境がOracle SOA SuiteおよびBPM 12c (12.2.1.3.0)へのアップグレードのOracle Database要件を満たしていることを確認します

SOA SuiteアップグレードのためのFusion Middleware Databaseのアップグレードと準備

必須

表領域のサイズが適切に設定されていることを確認します(不十分なサイズに設定すると、アップグレードは失敗します)。

SOAINFRAおよびIAS_TEMP表領域へのデータ・ファイルの追加
SOA Composerユーザーのみ: コミットされていない変更はアップグレード後には使用できないことに注意してください。 アップグレード前のSOA Composerの変更のコミット
以前の12cリリースからアップグレードする場合にのみ必要です。

アップグレード前に、ドメインから既存のcloudsdkデプロイメントを削除します。

 以前の12cリリースからのアップグレード時のcloudsdkアプリケーションの削除

ユーザー・メッセージング・サービス(UMS)をアップグレードする場合にのみ必要です

SOA Suiteのアップグレードの一部としてUMSをアップグレードする場合は、ユーザー・メッセージング・サービス(UMS)に必要なアップグレード前タスクを実行します。

ユーザー・メッセージング・サービス(UMS)に必要なアップグレード前タスクの実行

Oracle Service Bus (OSB)をアップグレードする場合にのみ必要です

SOA Suiteのアップグレードの一部としてOracle Service Bus (OSB)をアップグレードする場合は、OSBに必要なアップグレード前タスクを実行します。

Oracle Service Bus (OSB)のアップグレード前タスクの実行

オプション

スタンドアロンOracle HTTP Serverをアップグレードします。これは、アップグレードの前でも後でも実行できます。

スタンドアロンOracle HTTP Serverのアップグレード

親トピック: Oracle Fusion Middlewareのアップグレード前タスク

SOA SuiteアップグレードのためのFusion Middleware Databaseのアップグレードと準備

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

Oracle SOA SuiteおよびBPM 12c (12.2.1.3.0)にアップグレードする場合のOracle Databaseの要件を理解し、Oracle Fusion Middlewareをホストするデータベースがサポートされており、アップグレードの実行に十分な領域が用意されていることを確認することが重要です。Fusion Middleware 12c (12.2.1.3.0)を実行する前に、サポートされるデータベースを必須のスキーマで構成しておく必要があります。最新の情報については、常に最新のデータベースの動作保証マトリックスを参照してください。

Fusion Middlewareアップグレード前プロセスの一部として、データベースがサポートされていることを確認しました。しかし、Oracle SOA Suiteで使用するデータベースをインストールまたは確認する場合は、データベースのサイズおよびプロファイル、多数のOracle SOA Suiteコンポジット・アプリケーションのデータを格納する能力など、追加の考慮事項があります。詳細は、次のリソースを参照してください。

親トピック: SOA固有のアップグレード前タスクの実行

SOAINFRAおよびIAS_TEMP表領域へのデータファイルの追加

アップグレードの失敗を防止するために、既存のSOAデータベース表領域に、データ・ファイルをさらに追加することをお薦めします。

すべての表領域にとって重要なことですが、11g SOAINFRA表領域とIAS_TEMP表領域のサイズをアップグレードが成功するように設定することが特に重要です。

ノート:

サイズ設定のエラーが原因でデータベース・スキーマのアップグレードに失敗すると、ディスク領域を追加するだけではアップグレードを再試行できません。スキーマが不整合な状態になり、「INVALID」としてマークされた可能性があります。元の、アップグレード前の環境をバックアップからリストアしないと、このエラーからはリカバリできません。

2つのサンプル・コマンドを次に示します。自分のユース・ケース・シナリオに合せて、ファイルのサイズを設定してください。

SOAINFRA表領域にデータファイルを追加するには:

sysdbaとしてデータベースに接続して、次のコマンドを実行します。 

alter tablespace <PREFIX>_SOAINFRA add datafile '<DB_HOME>/oradata/orcl/<New_SoaInfra_DBF_FileName>' size 1000M autoextend on next 30M maxsize unlimited;
commit;

IAS_TEMP表領域に一時ファイルを追加するには:

sysdbaとしてデータベースに接続して、次のコマンドを実行します。

alter tablespace PREFIX_IAS_TEMP add tempfile '<DB_HOME>/oradata/orcl/<New_iastemp_dbf_filename>' size 1000M autoextend on next 30M maxsize unlimited;
commit;

アップグレード前の表領域のサイズ設定の詳細は、データ・ファイルの作成および表領域への追加に関する項を参照してください。

アップグレード前のSOA Composerの変更のコミット

アップグレードする前にSOA Composerサンドボックスへの変更をコミットまたはロールバックしない場合、変更が新しい環境に伝播されないことがあります。

アップグレードを開始する前に、アップグレードされた環境に伝播するすべての変更をコミットし、伝播したくない変更をロールバックしていることを確認します。

親トピック: SOA固有のアップグレード前タスクの実行

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

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

新しいOracle 12c機能を利用するには、Oracle SOA SuiteまたはOracle Business Process ManagementのQuick Start for Developersをダウンロードしてインストールします。

Quick Start for Developersディストリビューションには、Oracle JDeveloper 12cユーザーに、Oracle SOA SuiteおよびOracle Business Process Managementのアプリケーションを開発するために必要な拡張機能を提供します。

詳細は、「Oracle SOA Suite Quick Start for Developersのインストール」を参照してください。

ノート:

新しいOracle SOA 12c機能を使用するには、Oracle QuickStartが必要です。

親トピック: SOA固有のアップグレード前タスクの実行

以前の12cリリースからのアップグレード時のcloudsdkアプリケーションの削除

アップグレード前の環境にcloudsdkをインストールした場合は、アップグレードの開始前にそれを削除する必要があります。

このステップは、以前の12cリリースでcloudsdkがデプロイされた場合にのみ必要です。

cloudsdkの12c (12.2.1.3.0)バージョンは自動的にサーバーにデプロイされ、ネーミング規則の変更によって、以前にデプロイされたアプリケーションと競合する可能性があります。
  1. Oracle WebLogicコンソールにログインします。
    WebブラウザにURLを入力します。たとえば:

    http://host1.example.com:7001/em

    Oracle Fusion Middleware管理者のユーザー名とパスワードを入力して、「ログイン」をクリックします。

  2. コンソールの「ドメイン構成」パネルから、「デプロイメント」をクリックします。
    (オプション)必要に応じて、ステップの結果を入力します。明白な結果は記述しないでください。タスクはできるかぎり正確にする必要があります。
  3. 「制御」タブをクリックします。
  4. 「cloudsdk」を選択し、「停止」→「ただちに強制停止」をクリックします。
  5. 「構成」をクリックします。
  6. 「cloudsdk」を選択し、「削除」を選択します。
  7. 「構成の解放」をクリックします。

親トピック: SOA固有のアップグレード前タスクの実行

ユーザー・メッセージング・サービス(UMS)に必要なアップグレード前タスクの実行

SOA Suiteのアップグレードの一部としてUMSをアップグレードする場合は、ユーザー・メッセージング・サービス(UMS)に必要なアップグレード前タスクを実行します。

ユーザー・メッセージング・サービスを11gから12cにアップグレードする場合は、追加のアップグレード前タスク(構成ファイルを手動で管理対象サーバーから管理サーバーにコピーするなど)を実行する必要がある場合があります。以前の12cリリースからUMSをアップグレードする場合、このタスクをもう一度実行する必要はありません。

詳細は、「ユーザー・メッセージング・サービスのアップグレード」を参照してください。

親トピック: SOA固有のアップグレード前タスクの実行

Oracle Service Bus (OSB)のアップグレード前タスクの実行

SOA Suiteのアップグレードの一部としてOracle Service Bus (OSB)をアップグレードする場合は、OSBに必要なアップグレード前タスクを実行する必要があります。

Oracle Service Busを含むSOAドメインをアップグレードする場合は、必須のアップグレード前タスクをいくつか実行する必要があります。「Oracle Service Bus (OSB)のアップグレード前タスクの実行」を参照してください。

親トピック: SOA固有のアップグレード前タスクの実行

スタンドアロンOracle HTTP Serverのアップグレード

スタンドアロンのOracle HTTP Serverをアップグレードする場合は、「Oracle HTTP Serverのアップグレード」の説明に従ってください。

このオプションのステップは、アップグレードの前でも後でも実行できます。

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

ノート:

既存のドメインに関連付けられた管理対象Oracle HTTP Serverは、Infrastructureのアップグレード・プロセス中に自動的にアップグレードされます。管理対象HTTP Serverを個別にアップグレードする必要はありません。

親トピック: SOA固有のアップグレード前タスクの実行

SOAコンポジットの移行後にワイヤがない

11gからのアップグレード後に、サービスとリファレンスを接続するワイヤがコンポジットからなくなることがあります。この問題を解決するにはパッチを適用する必要があります。

11gからのアップグレード後に、サービスとリファレンスを接続するワイヤがコンポジットからなくなっていることに気づく場合があります。この問題は、SCAプロジェクト・マイグレータの11g JDevバージョンが新しい12cバージョンよりも高いことが原因です。これを解決するには、パッチを適用して11g SCAプロジェクト・マイグレータのバージョンを変更する必要があります。

パッチを適用するには、https://support.oracle.comに移動し、Doc ID 2356254.1を探します。

ノート:

ほとんどの場合、11g SCAプロジェクト・マイグレータは新規にインストールした12cマイグレータよりもバージョン番号が低く、この問題は発生しません。

親トピック: SOA固有のアップグレード前タスクの実行