Oracle WebCenterコンポーネントのアップグレード前のタスク

2 Oracle WebCenterコンポーネントのアップグレード前のタスク

アップグレード前のチェックリストを使用して、アップグレードを開始する前に実行する必要があるタスクを判別できます。実行するタスクは、既存のデプロイメントおよびアップグレードされるコンポーネントと構成によって異なります。リストを確認し、必要なタスクをすべて実行するまでアップグレードを開始しないでください。

ノート:

アップグレードを開始する前に、必ずアップグレード前の環境の完全バックアップを作成してください。アップグレードに失敗した場合は、バックアップからリストアして、アップグレードを再開する必要があります。

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

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

アップグレードはサーバーの停止中に実行されます。チェックリストは、アップグレード前の重要な(かつ時間がかかる)タスクを識別するためのものであり、これをアップグレード前に実行することで停止時間を短縮できます。アップグレード・プロセスを開始する前の準備を十分行うほど、オフライン時間を減らすことができます。

ノート:

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

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

表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モードを使用できるように適切に設定されていない場合、エラーが表示される場合があります。

必須

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

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

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

バックアップにスキーマ・バージョン・レジストリ表が含まれていることを確認します。「スキーマ・バージョン・レジストリ表のバックアップ」を参照してください。
既存のドメインの起動スクリプトまたは構成ファイルを変更またはカスタマイズした場合(たとえば、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表を含める必要があります。これにより、アップグレードが失敗したときに、コンテンツをアップグレード前の状態にリストアできるようになります。

実際のアップグレードを続行する前に、アップグレード・アシスタントの「前提条件」画面で、バックアップが実行されていることを確認するよう要求されます。ただし、アップグレード・アシスタントではバックアップが作成されていることが確認されない点に注意してください。

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

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

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

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

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

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

ノート:

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

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

アップグレードに関する問題を明らかにし、修正します。
エンドツーエンドのアップグレードを完了させる練習をします。
アップグレードのパフォーマンスおよびパージ・スクリプトがどのように役立つかを理解します。
アップグレードの完了までに必要な時間を理解します。
データベース・リソースの使用(一時表領域、PGAなど)について理解します。

ノート:

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

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

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

ノート:

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

警告:

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

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

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

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

ステップ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

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

ノート:

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

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

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

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

新しいターゲット・ホストへのドメイン・テンプレートのコンテンツのコピー

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

ターゲット・マシン上で、新しいOracleホームに移動します。
```
cd 1412_ORACLE_HOME/oracle_common/common/bin/
```

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が動作保証されていることの確認

このマニュアルの発行時点で、14c (14.1.2.0.0)の動作保証済JDKは17.0.12です。

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ファイルの汎用とプラットフォーム固有のディストリビューションとの相違点の理解に関する項を参照してください。

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に変更できます。

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

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

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

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

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

ノート:

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

未使用データのパージ

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

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

アップグレード・アシスタントを実行するための非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;

アップグレードで使用可能な既存のスキーマの識別

アップグレード前にこのオプションのステップを使用して、スキーマ・バージョン・レジストリ表を問い合せることができます。この表には、スキーマ所有者、バージョン番号、コンポーネント名とID、作成日と変更日、カスタム接頭辞などのスキーマ情報が含まれています。

アップグレード・アシスタントでは、ドメイン内のすべてのスキーマをアップグレードすることも、アップグレードするスキーマを個々に選択することもできます。いずれかの方法を選択するために、次のステップに従って、アップグレードに使用可能なすべてのスキーマのリストを確認します。

Oracleデータベースを使用している場合、Oracle DBA権限を持つアカウントを使用してデータベースに接続し、SQL*Plusから次を実行します。

SET LINE 120
COLUMN MRC_NAME FORMAT A14
COLUMN COMP_ID FORMAT A20
COLUMN VERSION FORMAT A12
COLUMN STATUS FORMAT A9
COLUMN UPGRADED FORMAT A8
SELECT MRC_NAME, COMP_ID, OWNER, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY WHERE OWNER LIKE UPPER('<PREFIX>_%');

生成されたレポートを確認します。

ノート:

アップグレード後、レポートを再度生成して、更新されたバージョンのスキーマを表示できます。アップグレードの必要がないスキーマがある場合は、そのスキーマのアップグレード前のバージョンがschema_version_registry表に維持されます。
既存のスキーマが、サポートされているバージョンからのものでない場合、14c (14.1.2.0.0)のアップグレード手順を使用する前に、それらをサポートされているバージョンにアップグレードする必要があります。詳細は、アップグレード前のバージョンのドキュメントを参照してください。
以前のバージョンでOIDベースのポリシー・ストアを使用していた場合、アップグレードを実行する前に新しいOPSSスキーマを必ず作成します。アップグレード後も、OPSSスキーマはLDAPベース・ストアのままです。
Oracle Fusion Middlewareリリース14c (14.1.2.0.0)でアップグレード可能な製品のスキーマのみをアップグレードできます。まだ14c (14.1.2.0.0)へのアップグレードが可能になっていないコンポーネントを含むドメインをアップグレードしないでください。

Auto_loginウォレットのAuto_login_onlyへの変換

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

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

すべてのauto_loginウォレットを識別します。auto_login ウォレットには、次の2つの追加ファイルがあります。
```
cwallet.sso
ewallet.p12
```

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

新しい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ディレクトリにあるファイルからバージョン情報を削除する必要があります。unresolvable-reference.html#GUID-FA91B77F-3539-40AC-83CE-AB638C491453を参照してください。

DISPLAY環境変数の設定

DISPLAY環境変数がGUIモードを使用できるように適切に設定されていない場合、エラーが表示される場合があります。

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

DISPLAY環境変数がGUIモードを使用できるように適切に設定されていない場合、次のエラーが表示される場合があります。

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

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

DISPLAY変数を設定してもこれらのエラーが発生し続ける場合は、vncconfigなどの他のGUIツールの起動を試みてください。同じエラーが表示される場合は、DISPLAY環境変数が正しく設定されていない場合があります。

Oracle WebCenterのアップグレード前のタスクの実行

Oracle WebCenter製品の14c (14.1.2.0.0)にアップグレードする前に、環境に適用されるアップグレード前のタスクを実行します。

Oracle WebCenterのアップグレード前のタスクは、次のとおりです。

アップグレード前のタスク	詳細情報
アップグレードの前に、非推奨または廃止されたコンポーネントをすべて無効化します。	アップグレード前の不要なコンポーネントの無効化
ポートレット・プロデューサ・アプリケーションのメタデータのエクスポート	ポートレット・プロデューサ・アプリケーションのメタデータのエクスポート
Oracle WebCenter Contentのアップグレード前のタスクを実行します(ContentまたはWebCenter Content Web UIをアップグレードする場合)。	WebCenter Contentのアップグレード前のタスクの実行
Oracle WebCenter Enterprise Captureのアップグレード前のタスクを実行します(Enterprise Captureをアップグレードする場合)。	Oracle WebCenter Enterprise Captureのアップグレード前のタスクの実行

アップグレード前の不要なコンポーネントの無効化

次のコンポーネントは廃止されたか無効であるため、アップグレードの前に無効化する必要があります。

ノート:

これらのコンポーネントを無効化しない場合、アップグレードが失敗し、Content Serverが起動できなくなる可能性があります。

CheckoutAndOpenInNative
CIS_Helper
ContentTrackerReports
SiteStudioExternalApplications
FormEditor (非推奨になったFCKEditorを使用しています)
proxyconnections8
UrmAgent
PDFExportConverter (IBR)
Folders_g

コンポーネントの無効化の詳細は、『Oracle WebCenter Contentの管理』のコンポーネント・マネージャの使用によるコンポーネントの有効化または無効化に関する項を参照してください。

ポートレット・プロデューサ・アプリケーションのメタデータのエクスポート

アプリケーションで、WSRPパラメータ・フォーム・ポートレット、サンプルWSRPポートレット・プロデューサ、およびサンプルPDK-Javaポートレット・プロデューサを含む事前構成済のポートレット・プロデューサを使用している場合、exportPortletClientMetadata WLSTコマンドを実行して、WebCenter Portalのポートレット・クライアント・メタデータおよびプロデューサのカスタマイズとパーソナライズをエクスポートする必要があります。

exportPortletClientMetadata(appName='webcenter', fileName='/tmp/portletClientExport.ear')