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

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

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

ノート:

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

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

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

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

ノート:

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

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

タスク	説明
必須 既存の環境の完全なバックアップを作成します。	アップグレードしようとしているスキーマを含めて、システムに重要なファイルとデータベースをすべてバックアップします。アップグレードに失敗した場合、アップグレード前の環境をリストアして、アップグレードを再度開始する必要があります。 「完全なバックアップの作成」を参照してください。 必ずバックアップにスキーマ・バージョン・レジストリ表が含まれるようにしてください。スキーマ・バージョン・レジストリ表のバックアップを参照してください。 既存のドメイン内の起動スクリプトのいずれかを変更した場合、アップグレード中にそれらを(既存ドメインの外部にある)一時ディレクトリの場所にコピーし、アップグレード後に再デプロイする必要があります。「カスタマイズされたドメインおよび環境設定の保持」を参照してください。
オプション オンライン・リカバリ操作用の追加のバックアップ・ファイルを作成します。	アップグレードが失敗し、オンライン・リカバリを実行する必要がある場合は、リカバリを容易にするために追加のバックアップ・ファイルを生成することをお薦めします。
オプション 使用する本番環境を、アップグレードのテスト用プラットフォームとしてクローンします。	システム・ファイルの完全なバックアップを作成するだけでなく、本番環境をクローニングしておくことも強くお薦めします。この環境は、アップグレードをテストするために使用されます。 「テストのためのソース環境のクローニング」を参照してください。
必須 サポートされているハードウェアおよびソフトウェア構成上で、製品をインストールおよびアップグレードしていることを確認します。 注意: サポートされている最新のオペレーティング・システムを使用できない場合はアップグレードしないでください。サポート対象のすべての構成と同様、こうした要件を守れない場合は、アップグレードが失敗する可能性があります。	(オペレーティング・システムを含む)ハードウェアとソフトウェアの構成が最新の動作保証および要件のドキュメントでサポートされていることを確認します。また、14c (14.1.2.0.0)製品のディストリビューションをインストールする前に、サポート対象バージョンのJDKを使用していることを確認してください。 動作保証の要件は頻繁に更新されるため、アップグレードの開始直前にこの情報を確認することをお薦めします。 ノート: アップグレードの前に、コンポーネントに最新のパッチが適用されていることを確認します。 動作保証とシステム要件の確認に関する項を参照してください。
オプション 強化された暗号化(AES 256)を使用している場合は、セキュリティ・ポリシー・ファイルを更新します。	Fusion Middleware 14c (14.1.2.0.0)で使用されているセキュリティ・アルゴリズムには、JDK用の追加のポリシー・ファイルが必要になるものがあります。 強化された暗号化(AES 256など)を使用する予定がある場合は、アップグレードする前に、最新の必要なポリシー・ファイルをJDKに適用することをお薦めします。 「強化された暗号化(AES 256)を使用する際のポリシー・ファイルの更新」を参照してください。
オプション Upgrade Assistantを実行するために非SYSDBAユーザーを作成します。	Upgrade Assistantを実行するには、FMWユーザーを作成することをお薦めします。ユーザーFMWは、システム管理権限なしでUpgrade Assistantを実行できます。 「Upgrade Assistantを実行するための非SYSDBAユーザーの作成」を参照してください。

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

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

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

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

関連項目:

• Oracle Fusion Middlewareの管理の環境のバックアップ

• Oracle Fusion Middlewareのアップグレードのプランニングの14c (14.1.2.0.0)のためのOracleデータベースのアップグレードおよび準備

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

システム・バックアップには、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 WebLogic Serverのアップグレードの起動スクリプトへのカスタマイズの再適用の説明に従って、設定を再適用する必要があります。

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

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

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

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

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

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

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

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

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';

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

ご使用の環境がインストールに必要な要件を満たしていることを確認するには、動作保証マトリックスおよびシステム要件のドキュメントをレビューする必要があります。オペレーティング・システム、ハードウェアまたはその他のソフトウェア・パッケージのアップグレードが必要になる場合があります。

ノート:

動作保証、システム要件および相互運用性情報を確認する際には必ず、特にオペレーティング・システム要件について確認してください。明示的にご使用のオペレーティング・システム環境専用に設計されたソフトウェアをダウンロードすることが重要です。

警告:

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

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

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

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

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

「システム要件と仕様の確認」のドキュメントとOracle Fusion Middlewareの動作保証マトリックスの両方を使用して、ディスク領域、使用可能なメモリー、特定のプラットフォーム・パッケージおよびパッチ、その他のオペレーティング・システム固有の項目などのシステム要件が満たされていることを確認することが重要です。

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

ノート:

最小システム要件を満たせない場合は、アップグレードを試行しないでください。

具体的には、Oracle Fusion Middlewareのシステム要件と仕様のドキュメントを使用して、次のことを検証できます。

• プロセッサ要件
• Java Development Kit (JDK)の要件
• 一般的なメモリーおよびディスク領域の要件
• 製品固有のメモリーおよびディスク領域の要件
•  ネットワーク要件
• UNIXオペレーティング・システムの要件
• Windowsオペレーティング・システムの要件
• 仮想化の要件
• データベース要件

使用しているオペレーティング・システムがサポートされていない場合はどうなりますか。

サポートされていないオペレーティング・システムで環境を実行している場合は、アップグレードを開始する前に、サポートされる環境を作成する必要があります。サポートされていないオペレーティング・システムでアップグレードを試行しないでください。

環境の移行ステップを使用します。

サポートされていないオペレーティング・システムからの管理対象ドメインの移行

現在、サポートされていないオペレーティング・システムで管理対象の、またはコロケートされたOracle Fusion Middlewareドメインを実行している場合は、アップグレードする前に、既存の環境をサポートされているオペレーティング・システムに移行する必要があります。

移行後、既存のOracle Fusion Middleware 12c (12.2.1.4.0)ソフトウェアがすべて正常に機能することを検証し、必ずその後でOracle Fusion Middleware 14c (14.1.2.0.0)へのアップグレードを実行します。

次のタスクでは、ホストは、サポートされていない既存のソース・マシンを指し、ターゲットは、サポートされている新しいターゲット・マシンを指します。

ノート:

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

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

注意:

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

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

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

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

ノート:

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

リリース14c (14.1.2.0.0)以降、WebLogic Server管理コンソールは削除されました。同等の機能を使用するには、WebLogicリモート・コンソールを使用する必要があります。詳細は、Oracle WebLogicリモート・コンソールを参照してください。

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

ノート:

次のサーバーを正しい順序で停止することが重要です。

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

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

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

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

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

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

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

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

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

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

SOAサーバーおよびプロセスは、次の順番で停止してください。

1. Business Activity Monitoring (BAM)管理対象サーバー

2. Oracle Service Bus (OSB)管理対象サーバー

3. サービス指向アーキテクチャ(SOA)管理対象サーバー

4. Oracle Web Services Manager (OWSM)管理対象サーバー

ステップ3: 管理サーバーを停止する

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

• (UNIX) EXISTING_DOMAIN_HOME/bin/stopWebLogic.sh

• (Windows) EXISTING_DOMAIN_HOME\bin\stopWebLogic.cmd

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

ステップ4: ノード・マネージャを停止する

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

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

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

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

ノート:

同一のマシンでオペレーティング・システムがアップグレードされる場合、アップグレードが失敗した場合にソース環境が破損するリスクがあります。

既存の環境の完全バックアップの作成に関する一般情報は、『Oracle Fusion Middleware管理者ガイド』の環境のバックアップに関する項を参照してください。

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

• 12c_DOMAIN_HOME

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

次の手順では、packコマンドを使用してドメイン・テンプレートのjarファイルを作成する方法について説明します。これは、バックアップの作成に使用できる唯一の方法です。独自のバックアップおよびリカバリ計画を参照して、デプロイメントに最適なバックアップ方法を選択します。

1. 次のように、packコマンドを使用して、サポートされていないホストで作成されたドメインをパックします。

   cd ORACLE_HOME/oracle_common/common/bin/

   ./pack.sh -domain=/scratch/username/<product>_12214/user_projects/domains/base_domain -template=/scratch/<product>.jar - template_author=<user_name> -template_name=<product>_domain

2. 作成したドメイン・テンプレートjarファイルを、サポートされている新しいホストにコピーします。

   jarファイルを解凍しないでください。この段階では、ドメインを新しい14.1.2 Oracle Homeに解凍するまで、ファイルを新しいホストの一時的な場所にコピーするだけです。解凍プロセスを簡略化するには、12.2.1.4ドメインで使用していたディレクトリ構造とまったく同じディレクトリ構造を再作成することを検討してください。こうすると、ファイルは上書きされなくなります。

ノート:

完全バックアップを作成するまでアップグレードを続行しないでください。

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

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

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

ドメイン・テンプレートの内容を新しいターゲット・ホストにコピーする

ターゲット・ホストで生成されたドメイン・テンプレートjarファイルの内容を解凍します。ターゲット・マシンのディレクトリ構造は、ホスト・マシンのディレクトリ構造と同じである必要があります。

1. ターゲット・マシンで、新しいOracleホームに移動します。

   cd 1412_ORACLE_HOME/oracle_common/common/bin/

2. 次のように、unpackコマンドを使用してファイルを新しいターゲットにコピーします。

   ./unpack.sh -domain=/scratch/<username>/<product>_12214/user_projects/domains/base_domain -template=/scratch/<product>.jar -user_name=weblogic -password=<enter your password>

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

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

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

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

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

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

ノート:

ノード・マネージャ・アップグレード手順では、元のノード・マネージャ・ファイルにアクセスする必要があります。ソース・マシンからバックアップした12c (12.2.1.4.0)のノード・マネージャ・ファイルを使用します。

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

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

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

ノート:

ご使用のデータベース・バージョンがサポート対象外だった場合は、アップグレードを開始する前に、サポート対象のバージョンにアップグレードする必要があります。

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

ご使用のJDKがサポートされていない場合、またはJDKをインストールしていない場合は、開始前に必要なJava SE JDKをダウンロードする必要があります。

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ディレクトリにインストールすることをお薦めします。

WLSSchemaDataSourceデータ・ソースのデータベース・ユーザーの確認

既存のドメインにWLSSchemaDataSourceデータ・ソースがある場合は、このステップが必要です。

ドメインにWLSSchemaDataSourceデータ・ソースがある場合は、どのデータベース・ユーザーがそれに割り当てられているかを確認する必要があります。<PREFIX>_WLS_RUNTIMEが割り当てられている場合は、それを<PREFIX>_WLSに変更する必要があります。

これは、次の変更が行われたために必要です:

• 14c (14.1.2.0.0) Upgrade Assistantは、ドメインベースのスキーマ・アップグレードの実行時に、WLSSchemaDataSourceデータ・ソースの情報を使用します。<PREFIX>_WLSデータベース・ユーザーがWLSSchemaDataSourceに割り当てられていない場合、またはUpgrade AssistantのWLSスキーマ・ページの「スキーマ・ユーザー名」に<PREFIX>_WLSが入力されていない場合、そのアップグレードは失敗します。
• 12c Oracle WebLogic管理コンソールを使用して、WLSSchemaDataSourceデータ・ソースのデータベース・ユーザーを<PREFIX>_WLSに変更することをお薦めします。こうすると、Upgrade Assistantの失敗を回避でき、また再構成ウィザードでフィールドに正しい値が事前移入されます。
• <PREFIX>_WLS_RUNTIMEデータベース・ユーザーは、14c (14.1.2.0.0)で導入された新しいWLSRuntimeSchemaDataSourceで使用するために予約されています。この新しいWLSRuntimeSchemaDataSourceは、14c (14.1.2.0.0)の再構成ウィザード(reconfig.sh)を使用してドメインをアップグレードするときに作成されます。

Oracle WebLogic 12c管理コンソールを使用して、WLSSchemaDataSourceのユーザーを<PREFIX>_WLS_RUNTIME から<PREFIX>_WLSに変更できます。

1. 12c (12.2.1.4.0)管理コンソールにログインします。
2. 管理コンソールの「ドメイン構造」で、「サービス」を展開します(横にある「+」をクリックします)。次に、「データ・ソース」をクリックします。
3. 「プロパティ」フィールドのユーザーに<PREFIX>_WLS_RUNTIME が含まれる場合は、<PREFIX>_WLSに変更します。
4. 変更内容を保存します。
5. ドメインが本番モードで実行されている場合は、チェンジ・センターを使用して変更をコミットします。

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

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

テストのためにソース環境のクローンを作成することをお薦めします。ただし、必須ではありません。

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

ノート:

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

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

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

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

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

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

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

ノート:

クローン環境でアップグレード前の準備状況チェックを実行して、データに関する潜在的なアップグレードの問題を識別できますが、アップグレードを確実に成功させるには、クローン環境で完全なテスト・アップグレードを実行する必要があります。

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

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

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

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

ノート:

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

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

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

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

ノート:

SYSDBAではないユーザーFMWは、アップグレード・アシスタントを実行するためにのみ作成されます。このステップが完了したら、このFMWユーザーを削除してください。アップグレード・アシスタントを実行するために必要な権限は、リリースごとに異なる可能性があります。

ノート:

この例では、SYSDBA以外の管理者にFMWという名前を使用しています。FMWは、ご自分の管理者名に置き換えてください。

権限を付与する際には、必ず、ドメイン内のスキーマの実際のユーザー名およびパスワードを指定します。

CREATE USER FMW IDENTIFIED BY "<FMW password>";
GRANT pdb_dba TO FMW;
GRANT MANAGE SCHEDULER TO FMW;
GRANT USE ON EDITION ORA$BASE TO FMW WITH GRANT OPTION;
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_aq 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 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_job 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 EXECUTE ON SYS.DBMS_ASSERT 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 dba_objects TO FMW WITH GRANT OPTION;
GRANT SELECT ON dba_queue_subscribers TO FMW WITH GRANT OPTION;
GRANT SELECT ON dba_subscr_registrations TO FMW WITH GRANT OPTION;
GRANT EXECUTE ON DBMS_RLS TO FMW WITH GRANT OPTION;
GRANT READ ON CTXSYS.CTX_PENDING TO FMW WITH GRANT OPTION;
GRANT SELECT ON SYS.V_$PARAMETER TO FMW WITH GRANT OPTION;
GRANT CREATE PROCEDURE TO FMW;
GRANT SELECT ON dba_users TO FMW WITH GRANT OPTION;
GRANT ALL ON sys.v_$parameter TO FMW WITH GRANT OPTION;

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

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

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

注意:

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

アップグレード前タスク	詳細情報
必須 環境がOracle SOA SuiteおよびBPM 14c (14.1.2.0.0)へのアップグレードのOracle Database要件を満たしていることを確認します	SOA SuiteアップグレードのためのFusion Middleware Databaseのアップグレードと準備
SOA Composerユーザーのみ: コミットされていない変更はアップグレード後には使用できないことに注意してください。	アップグレード前のSOA Composerの変更のコミット
以前の12cリリースからアップグレードする場合にのみ必要です。 アップグレード前に、ドメインから既存のcloudsdkデプロイメントを削除します。	以前の12cリリースからのアップグレード時のcloudsdkアプリケーションの削除
オプション スタンドアロンOracle HTTP Serverをアップグレードします。これは、アップグレードの前でも後でも実行できます。	スタンドアロンOracle HTTP Serverのアップグレード

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

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

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

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

• 『Oracle SOA SuiteおよびBusiness Process Managementのインストールと構成』のデータベース・プロファイルのカスタム変数に関する項

• Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理のSOAコンポジット・アプリケーションの概要に関する項およびデータベースのプロファイルまたはサイズの確認に関する項

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

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

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

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

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

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

cloudsdkの14c (14.1.2.0.0)バージョンは自動的にサーバーにデプロイされ、ネーミング規則の変更によって、以前にデプロイされたアプリケーションと競合する可能性があります。

1. Oracle Enterprise Manager (EM)コンソールにログインします。
   WebブラウザにURLを入力します。たとえば:

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

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

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

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

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

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

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

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

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

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

ノート:

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