アップグレード前の要件

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

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

Oracle Fusion Middlewareアップグレード前のチェックリスト
アップグレードの成功と限定的な停止時間を実現するために、アップグレードの開始前に、このチェックリストのタスクを実行してください。
完全なバックアップの作成
アップグレードを開始する前に、Oracle Fusion Middlewareスキーマをホストするすべてのデータベースを含め、システムに重要なファイルをすべてバックアップします。
テストのための本番環境のクローニング
実際の本番環境のコピーを作成し、クローン環境をアップグレードし、アップグレードされたコンポーネントが予想どおりに動作することを確認してから(必ず確認した後で)、本番環境をアップグレードします。
動作保証およびシステム要件の確認
ご使用の環境がインストールに必要な要件を満たしていることを確認するには、動作保証マトリックスおよびシステム要件のドキュメントをレビューする必要があります。
強化された暗号化(AES 256)を使用する場合のポリシー・ファイルの更新
アップグレードされる環境で強化された暗号化(Advanced Encryption Standard (AES) 256など)を使用する予定の場合は、アップグレードする前に、最新の必要なポリシー・ファイルをJDKに適用することをお薦めします。
未使用データのパージ
アップグレード前に未使用データをパージしてパージ方法を管理すると、アップグレード・プロセスを最適化できます。
エディション・ベースの再定義のためのサーバー上でのエディションの作成
エディション・ベースの再定義(EBR)に対応したスキーマをアップグレードする前に、最初にデータベース・サーバーに接続して、12cのデータベース・サーバーにエディションを作成する必要があります。
Upgrade Assistantを実行するための非SYSDBAユーザーの作成
Upgrade Assistantを実行するには、FMWと呼ばれる非SYSDBAユーザーを作成することをお薦めします。このユーザーはスキーマの変更に必要な権限は持っていますが、完全な管理者権限は持っていません。
カスタムsetDomainEnv設定のメンテナンス
すべてのドメインには、動的に生成されたドメインおよびサーバーの起動スクリプト(setDomainEnvなど)があります。起動スクリプトに行った変更は、その後のドメインのアップグレード操作中に上書きされるため、これらの起動スクリプトを変更しないでください。
OIDセキュリティ・ストアでの認証なしSSLモードの使用方法
SSLプロトコルでは、認証、整合性および機密保護を含むトランスポート層セキュリティがクライアントとサーバーとの間の接続に提供されます。SSL認証モードは、インスタンス固有の構成エントリ内のorclsslauthentication属性によって制御されます。デフォルトでは、Oracle Internet Directory(OID)はSSL認証なしモード(orclsslauthentication=1)を使用します。
OWSMポリシー・セットからのサーバー・インスタンス・スコープの削除
ポリシー・セット内のサーバー・インスタンス・スコープは、11g (11.1.1.7.0)では非推奨で、12cではサポートされていません。ただし、サーバー・インスタンス・スコープを使用するポリシー・セットがある場合は、12cへのアップグレード中に無効化されます。したがって、12cにアップグレードする前に、11gのすべてのポリシー・セットからサーバー・インスタンス・スコープを削除する必要があります。
事前定義ドキュメントのクローニングおよびOWSMポリシー・アタッチメントの移行
アップグレードの際、ご使用の環境向けにカスタマイズされていない事前定義ドキュメントは読取り専用バージョンで置き換えられ、新しい読取り専用の事前定義ドキュメントが追加される点に注意してください。ただし、カスタマイズされた既存の事前定義済ドキュメント、およびリポジトリのユーザー作成のカスタム・ポリシーは上書きされません。

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

アップグレードの成功と限定的な停止時間を実現するために、アップグレードの開始前に、このチェックリストのタスクを実行してください。

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

ノート:

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

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

タスク説明

タスク	説明
必須既存の環境の完全なバックアップを作成します。	アップグレードしようとしているスキーマを含めて、システムに重要なファイルとデータベースをすべてバックアップします。アップグレードに失敗した場合、アップグレード前の環境をリストアして、アップグレードを再度開始する必要があります。「完全なバックアップの作成」を参照してください。スキーマ・バージョン・レジストリ表がバックアップに含まれていることを確認します。「スキーマ・バージョン・レジストリ表のバックアップ」を参照してください。既存のドメインの起動スクリプトを変更した場合、アップグレード中はそれらを一時ディレクトリ(既存のドメイン以外)の場所にコピーし、アップグレード後に再デプロイする必要があります。「カスタマイズされたドメインおよび環境設定の保持」を参照してください。
省略可能使用する本番環境を、アップグレードのテスト用プラットフォームとしてクローンします。	システム・ファイルの完全なバックアップを作成する他に、本番環境のクローンも作成することをお薦めします。この環境は、アップグレードをテストするために使用されます。「本番環境のテスト用クローニング」を参照してください。
必須サポートされているハードウェアおよびソフトウェア構成上で、製品をインストールおよびアップグレードしていることを確認します。注意: サポートされている最新のオペレーティング・システムを使用できない場合はアップグレードしないでください。サポート対象のすべての構成と同様、こうした要件を守れない場合は、アップグレードが失敗する可能性があります。	(オペレーティング・システムを含む)ハードウェアとソフトウェアの構成が最新の動作保証および要件のドキュメントでサポートされていることを確認します。また、12c製品のディストリビューションをインストールする前に、サポート対象バージョンのJDKを使用していることを確認してください。動作保証要件は頻繁に更新されるため、アップグレードを開始する直前に、この情報を確認することをお薦めします。アップグレードの前に、コンポーネントに最新のパッチが適用されていることを確認します。動作保証とシステム要件の確認に関する項を参照してください。
32ビット・オペレーティング・システムの場合にのみ必須アップグレードする前に、64ビット・オペレーティング・システムに移行します。	これは、現在サポート対象外の32ビット・オペレーティング・システムを実行している場合にのみ必要になります。「32ビットから64ビット・オペレーティング・システムへの移行」を参照してください。
省略可能強化された暗号化(AES 256)を使用している場合は、セキュリティ・ポリシー・ファイルを更新します。	Fusion Middleware 12cで使用されているセキュリティ・アルゴリズムには、JDK用の追加のポリシー・ファイルが必要になるものがあります。強化された暗号化(AES 256など)を使用する予定がある場合は、アップグレードする前に、最新の必要なポリシー・ファイルをJDKに適用することをお薦めします。「強化された暗号化(AES 256)を使用する際のポリシー・ファイルの更新」を参照してください。
省略可能アップグレードの前に、古いデータまたは使用しないデータを削除します。	パフォーマンスを最適化するために、アップグレードした環境では使用されないデータとオブジェクトはパージすることをお薦めします。「未使用データのパージ」を参照してください。
Oracle Databaseユーザーの場合にのみ必須エディション・ベースの再定義(EBR)に対応したスキーマをアップグレードする前に、データベース・サーバーに接続して、12c (12.2.1.4.0)のデータベース・サーバー上でエディションを作成する必要があります。	エディション・ベースの再定義(EBR)データベースを使用している場合は、アップグレードを開始する前にエディションを作成する必要があります。「エディション・ベースの再定義のためのサーバー上でのエディションの作成」を参照してください。
省略可能 Upgrade Assistantを実行するための非SYSDBAユーザーを作成します。	Upgrade Assistantを実行するための、FMWユーザーを作成することをお薦めします。ユーザーFMWは、システム管理者の権限を持たずにUpgrade Assistantを実行できます。「Upgrade Assistantを実行するための非SYSDBAユーザーの作成」を参照してください。
省略可能カスタムの`setDomainEnv`設定を維持します。	アップグレード前に`setDomainEnv`スクリプト(または他の起動スクリプト)に加えた変更内容は、ドメインの再構成プロセスで再生成されるスクリプトによって上書きされます。そのため、アップグレードの前に、個別のファイルを作成して、カスタマイズしたドメイン設定を保存しておくことが重要です。「カスタムsetDomainEnv設定のメンテナンス」を参照してください。
省略可能 OIDセキュリティ・ストアでの認証なしSSLモードを使用するための前提条件を完全に満たします。	認証なしSSLを使用する場合は、`weblogic.properties`ファイルに、次に示す2つのプロパティを追加する必要があります。 `-Dweblogic.security.SSL.AllowAnonymousCipher=true` `-Dweblogic.security.SSL.ignoreHostnameVerification=true` 「OIDセキュリティ・ストアでの認証なしSSLモードの使用方法」を参照してください。
必須 OWSMポリシー・セットからサーバー・インスタンス・スコープを削除します。	ポリシー・セットのサーバー・インスタンス・スコープは、11g (11.1.1.7.0)では非推奨でしたが、12cではサポートされなくなりました。ただし、サーバー・インスタンス・スコープを使用するポリシー・セットがある場合は、12cへのアップグレード中に無効化されます。したがって、12cにアップグレードする前に、11gのすべてのポリシー・セットからサーバー・インスタンス・スコープを削除する必要があります。「OWSMポリシー・セットからのサーバー・インスタンス・スコープの削除」を参照してください。
必須目的の環境にあわせてカスタマイズした事前定義済ドキュメントのクローンを作成します。	最新のポリシーを常にすべて取得できるように、変更した事前定義ドキュメントはクローニングし、ポリシー・アタッチメントは移行することをお薦めします。「事前定義ドキュメントのクローニングおよびOWSMポリシー・アタッチメントの移行」を参照してください。

必須

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

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

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

スキーマ・バージョン・レジストリ表がバックアップに含まれていることを確認します。「スキーマ・バージョン・レジストリ表のバックアップ」を参照してください。
既存のドメインの起動スクリプトを変更した場合、アップグレード中はそれらを一時ディレクトリ(既存のドメイン以外)の場所にコピーし、アップグレード後に再デプロイする必要があります。「カスタマイズされたドメインおよび環境設定の保持」を参照してください。

省略可能

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

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

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

必須

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

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

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

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

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

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

32ビット・オペレーティング・システムの場合にのみ必須

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

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

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

省略可能

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

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

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

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

省略可能

アップグレードの前に、古いデータまたは使用しないデータを削除します。

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

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

Oracle Databaseユーザーの場合にのみ必須

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

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

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

省略可能

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

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

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

省略可能

カスタムのsetDomainEnv設定を維持します。

アップグレード前にsetDomainEnvスクリプト(または他の起動スクリプト)に加えた変更内容は、ドメインの再構成プロセスで再生成されるスクリプトによって上書きされます。そのため、アップグレードの前に、個別のファイルを作成して、カスタマイズしたドメイン設定を保存しておくことが重要です。

「カスタムsetDomainEnv設定のメンテナンス」を参照してください。

省略可能

OIDセキュリティ・ストアでの認証なしSSLモードを使用するための前提条件を完全に満たします。

認証なしSSLを使用する場合は、weblogic.propertiesファイルに、次に示す2つのプロパティを追加する必要があります。

-Dweblogic.security.SSL.AllowAnonymousCipher=true
-Dweblogic.security.SSL.ignoreHostnameVerification=true

「OIDセキュリティ・ストアでの認証なしSSLモードの使用方法」を参照してください。

必須

OWSMポリシー・セットからサーバー・インスタンス・スコープを削除します。

ポリシー・セットのサーバー・インスタンス・スコープは、11g (11.1.1.7.0)では非推奨でしたが、12cではサポートされなくなりました。ただし、サーバー・インスタンス・スコープを使用するポリシー・セットがある場合は、12cへのアップグレード中に無効化されます。したがって、12cにアップグレードする前に、11gのすべてのポリシー・セットからサーバー・インスタンス・スコープを削除する必要があります。

「OWSMポリシー・セットからのサーバー・インスタンス・スコープの削除」を参照してください。

必須

目的の環境にあわせてカスタマイズした事前定義済ドキュメントのクローンを作成します。

最新のポリシーを常にすべて取得できるように、変更した事前定義ドキュメントはクローニングし、ポリシー・アタッチメントは移行することをお薦めします。

「事前定義ドキュメントのクローニングおよびOWSMポリシー・アタッチメントの移行」を参照してください。

親トピック: アップグレード前の要件

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

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

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

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

参照:

Oracle Fusion Middlewareの管理の環境のバックアップ
Oracle Fusion Middlewareのアップグレードのプランニングの12c (12.2.1.4.0)のためのOracleデータベースのアップグレードおよび準備

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

親トピック: アップグレード前の要件

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

システム・バックアップには、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など)について理解します。

ノート:

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

親トピック: アップグレード前の要件

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

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

ノート:

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

警告:

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

環境が動作保証要件を満たしていることの確認
Oracleでは、動作保証済のすべてのシステムおよび環境で製品のパフォーマンスをテストおよび検証しています。製品をインストールする場合、サポートされているハードウェアまたはソフトウェア構成を使用します。
システム要件と仕様の確認
ディスク領域、使用可能なメモリー、特定のプラットフォーム・パッケージおよびパッチ、その他のオペレーティング・システム固有の項目などのシステム要件が満たされていることを確認することが重要です。
Oracle Fusion Middlewareをホストしているデータベースがサポートされていることの確認
Oracle Fusion Middleware 12cを実行する前に、サポートされるOracle Databaseを必須のスキーマで構成しておく必要があります。
このリリースのOracle Fusion MiddlewareでJDKが動作保証されていることの確認
このマニュアルの発行時における12c (12.2.1.4.0)に対して動作保証されたJDKは1.8.0_211でした。

親トピック: アップグレード前の要件

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

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

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

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

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

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

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

ノート:

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

32ビット環境を実行している場合は、追加のステップのセットを実行する必要があります。

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

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

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

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

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

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

ノート:

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

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

注意:

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

アップグレードの64ビット・ソフトウェア要件をサポートするハードウェアを調達する
アップグレード・プロセスを開始する前に、サポートされている適切なターゲット・ハードウェアが存在することを確認してください。
すべてのプロセスを停止する
アップグレードの前に、すべてのプロセスを停止する必要があります。ホスト上で管理対象サーバー、管理サーバーおよびノード・マネージャが起動されている場合は、これらも含めて停止する必要があります。
32ビット・ホスト・マシンからすべてのファイルをバックアップする
11gデプロイメント全体の完全バックアップを作成したことを確認してからアップグレード・プロセスを開始する必要があります。移行中に問題が発生した場合、これらのファイルを使用してプロセスを再度開始する必要があります。
11gのホスト名およびIPアドレスを使用してターゲットの64ビット・マシンを設定する
ターゲット・マシンのホスト名およびIPアドレスはホストと同一にする必要があります。そのため、ソース・マシンのIPアドレスおよび名前を変更するか、ソース・マシンを停止してネットワークの干渉を回避する必要があります。
11gバックアップを32ビット・ホストから64ビット・ホストにリストアする
11gで使用したものと同じディレクトリ構造を使用して、32ビット・ホストからバックアップしたファイルをリストアします。ターゲット・マシンのディレクトリ構造は、ホスト・マシンのディレクトリ構造と同じである必要があります。
12c製品ディストリビューションをターゲット・マシンにインストールする
アップグレードはホーム外で実行することをお薦めします。したがって、12c製品ディストリビューションは、ターゲット・マシン上の新しいOracleホームでインストールする必要があります。
標準的なアップグレード手順を使用してターゲットの64ビット環境をアップグレードする
ターゲット・マシンに製品をインストールしたら、コンポーネント固有のアップグレード・ガイドで指定されたアップグレード・ユーティリティを使用して各製品コンポーネントを個々にアップグレードし、アップグレード後のタスクを実行する必要があります。

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

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

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

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

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

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

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

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

(UNIX) EXISTING_DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url
(Windows) EXISTING_DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url

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

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

管理サーバーを停止するときに、管理サーバーで稼働しているプロセス(WebLogic Server管理コンソールやFusion Middleware Controlなど)も停止します。

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

(UNIX) EXISTING_DOMAIN_HOME/bin/stopWebLogic.sh
(Windows) EXISTING_DOMAIN_HOME\bin\stopWebLogic.cmd

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

ノード・マネージャを停止します

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

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

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

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

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

ノート:

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

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

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

11g_DOMAIN_HOME
11g_ORACLE_HOME/wlserver/common/にある11g/nodemanagerディレクトリ

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

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

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

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

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

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

11gのバックアップを32ビット・ホストから64ビット・ホストにリストアする

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

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

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

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

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

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

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

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

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

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

ノート:

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

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

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

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

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

ノート:

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

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

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

このマニュアルの発行時における12c (12.2.1.4.0)に対して動作保証されたJDKは1.8.0_211でした。

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

サポート対象外のJDKを使用している場合やJDKをインストールしていない場合は、次に示すWebサイトから必須のJava SE JDKをダウンロードする必要があります。

http://www.oracle.com/technetwork/java/javase/downloads/index.html

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

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

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

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

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

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

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

ノート:

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

親トピック: アップグレード前の要件

未使用データのパージ

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

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

親トピック: アップグレード前の要件

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

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

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

ノート:

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

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

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

create edition Oracle_FMW_12_2_1_1 as child of Oracle_FMW_11_1_1_7_0;

ここで、Oracle_FMW_11_1_1_7_0は、11.1.1.7スキーマを作成したときにRCU 11.1.1.7で指定するエディション名の例です。エディションを作成する際は、実際に使用する名前を入力してください。

次に示すメッセージは、エディションの作成が成功を示しています。

エディションが作成されました。

アップグレードの間、再構成ウィザードを実行して既存のドメインを再構成するよう要求されます。再構成ウィザードの実行前に、データベースのデフォルト・エディションを指定する必要があります。次のSQLコマンドを使用して、データベースのデフォルト・エディション名を手動で次のように設定します。

ALTER DATABASE DEFAULT EDITION = Oracle_FMW_12_2_1_1;

親トピック: アップグレード前の要件

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

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

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

ノート:

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

デフォルトでは、v$xatrans$表は存在しません。ユーザーを作成する前に、XAVIEW.SQLスクリプトを実行して、この表を作成する必要があります。さらに、v$xatrans$表のgrant select権限は、Oracle Identity Governanceでのみ必要です。構成にOracle Identity Governanceが必要ない場合、またはv$xatrans$表が存在しない場合は、次の行をスクリプトから削除します。

   grant select on v$xatrans$ to FMW with grant option;

次の例では、passwordはFMWユーザーに対して設定されたパスワードです。権限を付与する際は、必ず実際のパスワードを指定してください。

create user FMW identified by password;
grant dba to FMW;
grant execute on DBMS_LOB to FMW with grant option;
grant execute on DBMS_OUTPUT to FMW with grant option;
grant execute on DBMS_STATS to FMW with grant option;
grant execute on sys.dbms_aqadm to FMW with grant option;
grant execute on sys.dbms_aqin to FMW with grant option;
grant execute on sys.dbms_aqjms to FMW with grant option;
grant execute on sys.dbms_aq to FMW with grant option;
grant execute on utl_file to FMW with grant option;
grant execute on dbms_lock to FMW with grant option;
grant select on sys.V_$INSTANCE to FMW with grant option;
grant select on sys.GV_$INSTANCE to FMW with grant option;
grant select on sys.V_$SESSION to FMW with grant option;
grant select on sys.GV_$SESSION to FMW with grant option;
grant select on dba_scheduler_jobs to FMW with grant option;
grant select on dba_scheduler_job_run_details to FMW with grant option;
grant select on dba_scheduler_running_jobs to FMW with grant option;
grant select on dba_aq_agents to FMW with grant option;
grant execute on sys.DBMS_SHARED_POOL to FMW with grant option;
grant select on dba_2pc_pending to FMW with grant option;
grant select on dba_pending_transactions to FMW with grant option;
grant execute on DBMS_FLASHBACK to FMW with grant option;
grant execute on dbms_crypto to FMW with grant option;
grant execute on DBMS_REPUTIL to FMW with grant option;
grant execute on dbms_job to FMW with grant option;
grant select on pending_trans$ to FMW with grant option;
grant select on dba_scheduler_job_classes to fmw with grant option;
grant select on SYS.DBA_DATA_FILES to FMW with grant option;
grant select on SYS.V_$ASM_DISKGROUP to FMW with grant option;
grant select on v$xatrans$ to FMW with grant option;
grant execute on sys.dbms_system to FMW with grant option;
grant execute on DBMS_SCHEDULER to FMW with grant option;
grant select on dba_data_files to FMW with grant option;
grant execute on UTL_RAW to FMW with grant option;
grant execute on DBMS_XMLDOM to FMW with grant option;
grant execute on DBMS_APPLICATION_INFO to FMW with grant option;
grant execute on DBMS_UTILITY to FMW with grant option;
grant execute on DBMS_SESSION to FMW with grant option;
grant execute on DBMS_METADATA to FMW with grant option;
grant execute on DBMS_XMLGEN to FMW with grant option;
grant execute on DBMS_DATAPUMP to FMW with grant option;
grant execute on DBMS_MVIEW to FMW with grant option;
grant select on ALL_ENCRYPTED_COLUMNS to FMW with grant option;
grant select on dba_queue_subscribers to FMW with grant option; 
grant execute on SYS.DBMS_ASSERT to FMW with grant option;
grant select on dba_subscr_registrations to FMW with grant option;
grant manage scheduler to FMW;

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

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

親トピック: アップグレード前の要件

カスタム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スクリプトを作成できない場合は、「起動スクリプトへのカスタマイズの再適用」の説明に従って、設定を再適用する必要があります。

親トピック: アップグレード前の要件

OIDセキュリティ・ストアでの認証なしSSLモードの使用方法

SSLプロトコルでは、認証、整合性および機密保護を含むトランスポート層セキュリティがクライアントとサーバーとの間の接続に提供されます。SSL認証モードは、インスタンス固有の構成エントリ内のorclsslauthentication属性によって制御されます。デフォルトでは、Oracle Internet Directory(OID)はSSL認証なしモード(orclsslauthentication=1)を使用します。

12c Infrastructureにアップグレードし、OIDをセキュリティ・ポリシー・ストアとしてOracle WebLogic Serverで使用している場合、デフォルトのSSLモードを変更する必要があります。Oracle Internet Directory 11gでは、SSL相互運用性モードはデフォルトで有効です。ただし、Oracle Internet Directoryは、SSL相互運用性モードが無効であることを前提として、JDKのSSLに完全に準拠しています。

Oracle Internet Directory (OID)における認証なしSSLモードのデフォルト使用は、介在者(MITM)攻撃を受けやすくなるため、本番環境ではお薦めできません。

ただし、認証なしSSLが必要で、WebLogic Serverがクライアントの場合は、アップグレード前に次のシステム・プロパティをweblogic.propertiesファイルに適用する必要があります。

-Dweblogic.security.SSL.AllowAnonymousCipher=true
-Dweblogic.security.SSL.ignoreHostnameVerification=true

ノート:

これらのプロパティを設定することにより、匿名暗号スイートが有効化され、ホスト名の検証チェックなしでクライアント接続が確立されるため、WebLogic Serverは介在者攻撃を受けやすくなる可能性があります。

WebLogic Server 12cでOIDを使用する場合は、サーバー認証またはクライアント/サーバーSSL認証の使用をお薦めします。

親トピック: アップグレード前の要件

OWSMポリシー・セットからのサーバー・インスタンス・スコープの削除

ポリシー・セットのサーバー・インスタンス・スコープは、11g (11.1.1.7.0)では非推奨で、12cではサポートされていません。ただし、サーバー・インスタンス・スコープを使用するポリシー・セットがある場合は、12cへのアップグレード中に無効化されます。したがって、12cにアップグレードする前に、11gのすべてのポリシー・セットからサーバー・インスタンス・スコープを削除する必要があります。

詳細は、Oracle Fusion Middleware 11gリリース1 (11.1.1.7.0)のドキュメント・ライブラリのWebサービスのためのセキュリティおよび管理者ガイドのポリシー・セットの編集を参照してください。

親トピック: アップグレード前の要件

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

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

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

親トピック: アップグレード前の要件