1. Oracle HTTP Serverのアップグレード
  2. Oracle HTTP Serverのアップグレードの準備

2 Oracle HTTP Serverのアップグレードの準備

アップグレードは、サーバーがダウンしている間に実行されます。アップグレード前タスクには、時間を要するものが多くあります。少ないダウンタイムでアップグレードを成功させるため、これらのアップグレード前タスクを実行して、アップグレード向けに環境の計画と準備を行うことをお薦めします。

次のチェックリストを使用して、アップグレード前タスクを確実に完了します。

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

アップグレード前のチェックリストは、正常なアップグレードと限られた停止時間を保証するために、アップグレードを開始する前に実行するタスクを示しています。

アップグレードは、サーバーがダウンしている間に実行されます。このチェックリストは、ダウンタイムを少なくするため、時間がかかることが多い重要なアップグレード前タスクのうち、アップグレード前に実行できるものを識別することを目的としています。アップグレード・プロセスを開始する前の準備を十分行うほど、オフライン時間を減らすことができます。

ノート:

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

この表は、アップグレード前のチェックリストを示します。すべての必要なコンポーネントをリストし、それらについて詳細に説明します。

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

タスク 説明

必須

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

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

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

  • スキーマ・バージョン・レジストリ表がバックアップに含まれていることを確認します。「スキーマ・バージョン・レジストリ表のバックアップ」を参照してください。

  • 既存のドメインの起動スクリプトまたは構成ファイルを変更またはカスタマイズした場合(たとえば、cookie-pathプロパティの値を設定するなど)、アップグレード中はそれらを一時ディレクトリ(既存のドメイン以外)の場所にコピーし、アップグレード後に再デプロイする必要があります。

オプション

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

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

必須

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

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

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

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

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

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

オプション

必要な権限でアップグレード・アシスタントを実行するための非SYSDBAユーザーを作成します。

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

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

必須

auto_loginウォレットを使用している場合は、ウォレット・ファイルを更新する必要があります。

auto_login_onlyウォレットは、14c (14.1.2.0.0)でサポートされている唯一のウォレットです。14c (14.1.2.0.0)にアップグレードする前に、convert_to_auto_login_only.plを使用して、既存のすべての12c (12.2.1.4.0) auto_loginウォレットをauto_login_onlyに更新する必要があります。

「auto_loginウォレットのauto_login_onlyへの変換」を参照してください。

必須

LinuxおよびUNIXオペレーティング・システムのユーザーは、Fusion Middlewareツールを起動する前に、DISPLAY環境変数を設定する必要があります。

DISPLAY環境変数の設定

DISPLAY環境変数がGUIモードを使用できるように正しく設定されていない場合、エラーが発生することがあります。

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

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

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

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

関連項目:

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

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

ノート:

このステップが必要なのは、管理対象ドメインまたはコロケート・ドメインの場合のみです。スタンドアロン・ドメインに、この表は含まれません。

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

ノート:

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

テストのための移行元環境のクローニング

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

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

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

ノート:

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

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

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

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

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

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

ノート:

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

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

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

ノート:

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

警告:

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

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

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

新しい動作保証要件が確認されると、その要件はすぐに該当する動作保証に関するドキュメントに追加されます。新しい動作保証要件は随時確認される場合があるため、動作保証に関するドキュメントはドキュメント・ライブラリの外部に置かれ、オラクルの技術リソースで提供されています。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オペレーティング・システムの要件
  • 仮想化の要件
  • データベース要件

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

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

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

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

スタンドアロン・ドメインが、サポートされていないオペレーティング・システムにインストールされている場合は、サポートされているオペレーティング・システムを実行しているマシンでアウトオブプレース・アップグレードを実行する必要があります。

既存のデプロイメントが、サポートされているオペレーティング・システムで実行されていない場合、14c (14.1.2.0.0)へのアップグレードは実行できません。アップグレードを開始する前に、サポートされているオペレーティング・システムに既存のデプロイメントを移行する必要があります。

ノート:

このプロセスでは、既存のOracleホームおよびドメイン・ホームがOracle Linux 7マシンにデプロイされ、同じディレクトリ構造が新しいマシンにレプリケートされることを前提としています。これらのステップでは、Oracle Linux 8にアップグレードすることを前提としていますが、サポートされているオペレーティング・システムの完全なリストは、14c (14.1.2.0.0)の動作保証マトリックスを参照してください。

  1. Oracle Linux 7ホストでpack.shを使用して、Oracle HTTP Server 12c (12.2.1.4)ドメインをパックします。次のコード例を変更して、実際のディレクトリ構造、ファイル名、ユーザー名およびパスワードを反映します。
    cd 12214_ORACLE_HOME/oracle_common/common/bin/
    ./pack.sh -domain=../user_projects/domains/base_domain -template=/scratch/OHS12214.jar -template_author=<user_name> -template_name=OHS_domain
  2. パックされたjarをOracle Linux 8ホストにコピーします。

    ノート:

    jarファイルを解凍しないでください。この段階では、ドメインを新しい14c (14.1.2.0.0) Oracle Homeに解凍するまで、ファイルを新しいOracle Linux 8ホストの一時的な場所にコピーするだけです。

  3. Oracle Linux 7ホストで使用されたのと同じディレクトリ構造を使用して、Oracle Linux 8ホストにOracle HTTP Server 14c (14.1.2.0.0)をインストールします。スタンドアロンOracle HTTP Serverのインストールを参照してください。

    ノート:

    Oracle Linux 7マシンで使用されるOracleホームおよびドメイン・ホーム・パスは、Oracle Linux 8マシンで使用可能である必要があります。
  4. ステップ1でパックしたjarファイルを使用して、unpack.shスクリプトを起動します。これにより、Oracle Linux 8マシン上に12.2.1.4.0ドメインが再作成されます。

    次のコード例を変更して、実際のディレクトリ構造、ファイル名、ユーザー名およびパスワードを反映します。

    cd 1412_ORACLE_HOME/oracle_common/common/bin/
    ./unpack.sh -domain=../user_projects/domains/base_domain -template=/scratch/OHS12214.jar -user_name=weblogic -password=<enter your password>
  5. 「再構成ウィザードを使用した既存のドメインの再構成」の説明に従って、Oracle Linux 8 Oracle Homeから14c (14.1.2.0.0)再構成ウィザードを実行します。プロンプトが表示されたら、Oracle Linux 8マシンで開梱された12.2.1.4.0ドメインの場所を必ず指定してください。
  6. 「Upgrade Assistantを使用したスタンドアロン・システム・コンポーネント構成のアップグレード」の説明にしたがって、Oracle Linux 8 Oracleホームから14c (14.1.2.0.0) Upgrade Assistantを実行します。プロンプトが表示されたら、Oracle Linux 8マシンで開梱された12.2.1.4.0ドメインの場所を必ず指定してください。
サポートされていないオペレーティング・システムからの管理対象ドメインの移行

サポートされていないオペレーティング・システムで管理対象またはコロケートされた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

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

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

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

  • (UNIX) EXISTING_DOMAIN_HOME/bin/stopWebLogic.sh

  • (Windows) EXISTING_DOMAIN_HOME\bin\stopWebLogic.cmd

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

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

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

またはnodemanager.propertiesのQuitEnabledの属性をtrueに設定した後(デフォルトはfalseです)、WLSTを使用して、ノード・マネージャに接続して停止できます。『Oracle 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ホームにインストールした場合、今後の操作で問題が発生することがあります。このため、/home/oracle/products/jdkディレクトリに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. ドメインが本番モードで実行されている場合、チェンジ・センターを使用して変更をコミットします。

強化された暗号化(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以外のユーザーを作成してスキーマをアップグレードすることをお薦めします。次に示す権限は、Upgrade Assistantを起動する前にユーザー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;

auto_loginウォレットのauto_login_onlyへの変換

Oracle HTTP Server (OHS)インスタンスを14c (14.1.2.0.0)にアップグレードする前に、convert_to_auto_login_only.plを使用して、既存のすべてのOHS auto_login walletsをauto_login_onlyに変換する必要があります。

Oracle HTTP Server (OHS) 14c (14.1.2.0.0)でサポートされているウォレットはAuto_login_only ウォレットのみです。サーバーを起動する前に、auto_loginウォレットを識別してauto_login_onlyに変換する必要があります。

  1. すべてのauto_loginウォレットを識別します。auto_login ウォレットには、次の2つの追加ファイルがあります。 
    cwallet.sso
ewallet.p12
  2. convert_to_auto_login_only.plスクリプトを使用して、各auto_loginウォレットをauto_login_onlyに変換します。
    Usage:
perl <path_to_convert_to_auto_login_only.pl> <auto_login_wallet directory> <auto_login_only_wallet directory>
<Password of auto_login_wallet>
auto_login_wallet directory - Directory path to the existing auto_login wallet directory
auto_login_only_wallet directory - Directory path to the new auto_login_only wallet directory, directory will be created
by the tool
Password of auto_login_wallet - Optional: Password of the existing auto_login wallet
    次のコマンドでは、デフォルト・ウォレットを例として使用します。次のコマンドを実行する前に、特定の環境-DOMAIN_HOMEおよびORACLE_HOME環境変数のディレクトリ・パスを調整する必要があります。
    Linux/Unix:
cd $DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/keystores/
$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/ohs/common/bin/convert_to_auto_login_only.pl default default/auto_login_only
Windows:
cd %DOMAIN_HOME%\config\fmwconfig\components\OHS\ohs1\keystores
%ORACLE_HOME%\perl\bin\perl %ORACLE_HOME%\ohs\common\bin\convert_to_auto_login_only.pl default default\auto_login_only
  3. 新しいauto_login_only_walletディレクトリを使用するように、すべてのウォレット・ディレクティブを更新します。
    サンプル・エントリ(特定の環境のディレクトリ・パスを調整する必要があります):
    #SSLWallet "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/keystores
/default"
SSLWallet "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/keystores/default
/auto_login_only"
#WLSSLWallet "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/keystores
/default"
WLSSLWallet "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/keystores
/default/auto_login_only"

ノート:

convert_to_auto_login_only.plスクリプトは、リクエストされた証明書(CSR)をインポートしません。証明書署名リクエスト(CSR)が必要な場合は、新しいauto_login_onlyウォレットを作成する必要があります。

アップグレード後に別のスクリプトを実行して、htdocsディレクトリにあるファイルからバージョン情報を削除する必要があります。「htdocsフォルダからのバージョン情報の削除」を参照してください。

DISPLAY環境変数の設定

DISPLAY環境変数がGUIモードを使用できるように正しく設定されていない場合、エラーが発生することがあります。

LinuxおよびUNIXオペレーティング・システム・ユーザー:

DISPLAY環境変数がGUIモードを有効にするように適切に設定されていないと、次に示すエラーが発生することがあります。 

Xlib: connection to ":1.0" refused by server
Xlib: No protocol specified

この問題を解決するには、DISPLAY環境変数をローカル・ワークステーションのシステム名またはIPアドレスに設定して、Upgrade Assistantを再実行します。

このようなエラーがDISPLAYの設定後にも続く場合は、別のGUIツール(vncconfigなど)を起動してみてください。同じエラーが表示される場合は、DISPLAY環境変数の設定に間違いが残っている可能性があります。