2 アップグレード前の要件

Oracle Fusion Middleware Infrastructure 14c (14.1.2.0.0)へのアップグレードを開始する前に、アップグレード前のタスク(現在の環境のバックアップやクローニング、目的のシステムが動作保証要件を満たしていることの確認など)を実行する必要があります。

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

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

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

ノート:

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

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

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

タスク 説明

必須

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

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

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

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

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

省略可能

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

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

必須

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

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

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

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

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

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

省略可能

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

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

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

必須

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

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

unresolvable-reference.html#GUID-315E9CA9-0200-4690-927B-F5E03EB97D5Bを参照してください。

必須

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

unresolvable-reference.html#GUID-96635459-410E-4700-8559-55BA40B2DADA

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

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

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

バックアップには、SYSTEM.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では、動作保証済のすべてのシステムおよび環境で製品のパフォーマンスをテストおよび検証しています。製品をインストールする場合、サポートされているハードウェアまたはソフトウェア構成を使用します。

新しい動作保証要件が確認されると、その要件はすぐに該当する動作保証に関するドキュメントに追加されます。新しい動作保証要件は随時確認される場合があるため、動作保証に関するドキュメントはドキュメント・ライブラリの外部に置かれ、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 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に変更できます。
  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 12cで使用されているセキュリティ・アルゴリズムには、JDK用の追加のポリシー・ファイルが必要になるものがあります。「Java暗号化アーキテクチャOracleプロバイダのドキュメント」を参照してください。

ノート:

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

未使用データのパージ

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

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

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

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

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

ノート:

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

ノート:

この例では、非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;

カスタムsetDomainEnv設定のメンテナンス

すべてのドメインには、動的に生成されたドメインおよびsetDomainEnvなどのサーバー起動スクリプトがあります。起動スクリプトに行った変更は、その後のドメインのアップグレード操作中に上書きされるため、これらの起動スクリプトを変更しないでください。

注意:

アップグレード前にsetDomainEnvスクリプト(または他の起動スクリプト)に加えられた変更は、ドメインの再構成プロセスで再生成されるスクリプトにより上書きされます。別のファイルを作成して、アップグレード前にカスタマイズしたドメイン設定を格納してください。

たとえば、ドメインのすべてのサーバーに適用されるサーバー起動パラメータをカスタマイズする場合は、setUserOverrides.cmd (Windows)またはsetUserOverrides.sh (UNIX)という名前のファイルを作成することにより、たとえば、WebLogic Serverクラスパスにカスタム・ライブラリを追加する、サーバー実行用の追加のJavaコマンド行オプションを指定する、または追加の環境変数を指定する、などの構成が可能です。このファイルに追加されたカスタム設定はドメインのアップグレード操作中に保存され、packおよびunpackコマンドを使用する際にリモート・サーバーに継承されます。

setUserOverridesファイルにおける起動のカスタマイズの例を次に示します。
# add custom libraries to the WebLogic Server system claspath
  if [ "${POST_CLASSPATH}" != "" ] ; then
    POST_CLASSPATH="${POST_CLASSPATH}${CLASSPATHSEP}${HOME}/foo/fooBar.jar"
    export POST_CLASSPATH
  else
    POST_CLASSPATH="${HOME}/foo/fooBar.jar"
    export POST_CLASSPATH
  fi
 
# specify additional java command line options for servers
JAVA_OPTIONS="${JAVA_OPTIONS}  -Dcustom.property.key=custom.value"

サーバーの起動中にsetUserOverridesファイルが存在する場合、このファイルが起動シーケンスに含まれ、このファイルにオーバーライドがあれば、有効になります。setUserOverridesファイルは、domain_home/binディレクトリに格納する必要があります。

ノート:

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

事前定義ドキュメントのクローニングおよびOWSMポリシー・アタッチメントの移行

アップグレードの際、ご使用の環境向けにカスタマイズされていない事前定義ドキュメントは読取り専用バージョンで置き換えられ、新しい読取り専用の事前定義ドキュメントが追加される点に注意してください。ただし、カスタマイズされた既存の事前定義済ドキュメント、およびリポジトリのユーザー作成のカスタム・ポリシーは上書きされません。

最新のポリシーを常にすべて取得できるように、変更した事前定義ドキュメントはクローニングし、ポリシー・アタッチメントは移行することをお薦めします。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理OWSMリポジトリのアップグレードを参照してください。

手動で管理するレスポンス・ファイルの更新

このステップは、Upgrade Assistantで生成されたものを使用せずに、手動で管理するresponses.txtファイルを使用する場合にのみ必要です。

サイレントまたはハンズフリー・アップグレードはレスポンス・ファイルを使用して実行できます。レスポンス・ファイルはUpgrade Assistantの画面で情報を入力した後でのみ作成できます。responses.txtファイルが、14c (14.1.2.0.0) Upgrade Assistantの「レスポンス・ファイルの保存」ボタンを使用して生成されたものでない場合は、このファイルを手動で更新する必要があります。

14c (14.1.2.0.0)では新しいWLSRuntimeSchemaDataSourceデータ・ソースが導入されました。つまり、responses.txtファイルは以前のWebLogic Serverバージョンとは別のものになります。14c (14.1.2.0.0) Upgrade Assistantの「レスポンス・ファイルの保存」ボタンでは新しいWLSRuntimeSchemaDataSourceデータ・ソースが認識されるため、Upgrade Assistantで生成されたresponses.txtファイルを使用する場合は、何もする必要はありません。

ノート:

14c (14.1.2.0.0) Upgrade Assistantによって生成されたレスポンス・ファイルを使用することをお薦めします。スキーマのアップグレードを試行する前にUpgrade Assistantを使用して準備状況チェックを実行する場合は、「レスポンス・ファイルの保存」ボタンをクリックします。これにより、すべてのWLS_RUNTIME.XXXプロパティが含まれたresponse.txtファイルが生成されます。

  1. エディタでresponses.txtファイルを開きます。
  2. エディタの検索機能を使用して、[WLS.WLS]を検索します。
  3. リストの最初のWLS.XXXプロパティを見つけます(例: WLS.WLS.databaseType = Oracle Database)
    ...
    WLS.databaseType = Oracle Database
    
  4. 前述のプロパティを含む、すべてのWLS.XXXプロパティをコピーします:
    ...
    WLS.databaseType = Oracle Database
    WLS.databaseConnectionString = <connect-string>
    WLS.schemaConnectionString = <connect-string>
    WLS.schemaUserName = <PREFIX>_WLS
    WLS.encryptedSchemaPassword = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    WLS.dbaUserName = system
    WLS.encryptedDbaPassword = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  5. コピーしたWLS.XXXプロパティを、最後にコピーしたプロパティの下に貼り付けます。
    ...
    WLS.databaseType = Oracle Database
    WLS.databaseConnectionString = <connect-string>
    WLS.schemaConnectionString = <connect-string>
    WLS.schemaUserName = <PREFIX>_WLS
    WLS.encryptedSchemaPassword = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    WLS.dbaUserName = system
    WLS.encryptedDbaPassword = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    
    
    WLS.databaseType = Oracle Database
    WLS.databaseConnectionString = <connect-string>
    WLS.schemaConnectionString = <connect-string>
    WLS.schemaUserName = <PREFIX>_WLS
    WLS.encryptedSchemaPassword = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    WLS.dbaUserName = system
    WLS.encryptedDbaPassword = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  6. 貼り付けたプロパティ内のWLS.XXXWLS_RUNTIME.XXXに置き換えます
    ...
    WLS.databaseType = Oracle Database
    WLS.databaseConnectionString = <connect-string>
    WLS.schemaConnectionString = <connect-string>
    WLS.schemaUserName = <PREFIX>_WLS
    WLS.encryptedSchemaPassword = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    WLS.dbaUserName = system
    WLS.encryptedDbaPassword = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    
    
    WLS_RUNTIME.databaseType = Oracle Database
    WLS_RUNTIME.databaseConnectionString = <connect-string>
    WLS_RUNTIME.schemaConnectionString = <connect-string>
    WLS_RUNTIME.schemaUserName = <PREFIX>_WLS_RUNTIME
    WLS_RUNTIME.encryptedSchemaPassword = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    WLS_RUNTIME.dbaUserName = system
    WLS_RUNTIME.encryptedDbaPassword = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    ノート: 必ず、WLS_RUNTIME.schemaUserNameプロパティに割り当てられた値を変更してください。<PREFIX>_WLSではなく<PREFIX>_WLS_RUNTIMEにする必要があります。

  7. WLS_RUNTIME.XXXプロパティを手動で追加したファイルを保存します。