2 Oracle WebCenterコンポーネントのアップグレード前のタスク
ノート:
アップグレードを開始する前に、必ずアップグレード前の環境の完全バックアップを作成してください。アップグレードに失敗した場合は、バックアップからリストアして、アップグレードを再開する必要があります。- アップグレード前のチェックリスト
アップグレード前のチェックリストは、アップグレードを成功させて停止時間を少なくするために、アップグレードを開始する前に実行できるタスクを識別します。 - 完全なバックアップの作成
アップグレードを開始する前に、Oracle Fusion Middlewareスキーマをホストするすべてのデータベースを含め、システムに重要なファイルをすべてバックアップします。 - テストのための本番環境のクローニング
実際の本番環境のコピーを作成し、クローン環境をアップグレードし、アップグレードされたコンポーネントが予想どおりに動作することを確認してから(必ず確認した後で)、本番環境をアップグレードします。 - 動作保証およびシステム要件の確認
ご使用の環境がインストールに必要な要件を満たしていることを確認するには、動作保証マトリックスおよびシステム要件のドキュメントをレビューする必要があります。 - 強化された暗号化(AES 256)を使用する場合のポリシー・ファイルの更新
アップグレードされる環境で強化された暗号化(Advanced Encryption Standard (AES) 256など)を使用する予定の場合は、アップグレードする前に、最新の必要なポリシー・ファイルをJDKに適用することをお薦めします。 - 未使用データのパージ
アップグレード前に未使用データをパージしてパージ方法を管理すると、アップグレード・プロセスを最適化できます。 - エディション・ベースの再定義のためのサーバー上でのエディションの作成
エディション・ベースの再定義(EBR)に対応したスキーマをアップグレードする前に、最初にデータベース・サーバーに接続して、12cのデータベース・サーバーにエディションを作成する必要があります。 - Upgrade Assistantを実行するための非SYSDBAユーザーの作成
Upgrade Assistantを実行するには、FMW
と呼ばれる非SYSDBAユーザーを作成することをお薦めします。このユーザーには、スキーマの変更に必要な権限はありますが、完全な管理者権限はありません。 - アップグレードに対応可能な既存のスキーマの特定
このオプションの作業では、スキーマ・バージョン・レジストリを問い合せることで、アップグレードの開始前に、使用可能スキーマのリストを確認できます。このレジストリには、バージョン番号、コンポーネント名およびID、作成日と変更日、カスタム接頭辞などのスキーマ情報が含まれます。 - Oracle WebCenterのアップグレード前のタスクの実行
Oracle WebCenter製品の12c (12.2.1.3.0)にアップグレードする前に、環境に適用されるアップグレード前のタスクを実行します。
アップグレード前のチェックリスト
アップグレード前のチェックリストは、アップグレードを成功させて停止時間を少なくするために、アップグレードを開始する前に実行できるタスクを識別します。
アップグレードはサーバーの停止中に実行されます。チェックリストは、アップグレード前の重要な(かつ時間がかかる)タスクを識別するためのものであり、これをアップグレード前に実行することで停止時間を短縮できます。アップグレード・プロセスを開始する前の準備を十分行うほど、オフライン時間を減らすことができます。
ノート:
実行するアップグレード前の手順は、既存のシステムの構成、アップグレードするコンポーネントおよびアップグレードと構成プロセスの最後に作成する環境によって異なります。構成またはユースケースに該当するタスクのみを実行してください。表2-1 Oracle Fusion Middleware 12cにアップグレードする前に実行するタスク
タスク | 説明 |
---|---|
必須 既存の環境の完全なバックアップを作成します。 |
アップグレードしようとしているスキーマを含めてシステムに重要なファイルとデータベースをすべてバックアップします。アップグレードに失敗した場合は、アップグレード前の環境をリストアして、アップグレードを再試行する必要があります。 「完全なバックアップの作成」を参照してください。
|
オプション 使用する本番環境を、アップグレードのテスト用プラットフォームとしてクローンします。 |
システム・ファイルの完全なバックアップを作成する他に、本番環境のクローンも作成することをお薦めします。この環境は、アップグレードをテストするために使用されます。 「本番環境のクローニング」を参照してください。 |
必須 サポートされているハードウェアおよびソフトウェア構成上で、製品をインストールおよびアップグレードしていることを確認します。 サポートされている最新のオペレーティング・システムを使用できない場合はアップグレードしないでください。サポート対象のすべての構成と同様、こうした要件を守れない場合は、アップグレードが失敗する可能性があります。 |
ハードウェアとソフトウェア(オペレーティング・システムも含む)の構成が最新の動作保証および要件のドキュメントでサポートされていることを確認します。また、12cの製品ディストリビューションをインストールする前に、サポートされるバージョンのJDKを使用していることを確認します。 動作保証要件は頻繁に更新されるため、アップグレードを開始する直前に、この情報を確認することをお薦めします。 アップグレードの前に、コンポーネントに最新のパッチが適用されていることを確認します。 動作保証とシステム要件の確認に関する項を参照してください。 |
32ビットのオペレーティング・システムの場合にのみ必要 64ビットのオペレーティング・システムに移行してから、アップグレードします。 |
これは現在サポートされていない32ビットのオペレーティング・システムを実行している場合にのみ必要です。 |
オプション 強化された暗号化(AES 256)を使用している場合は、セキュリティ・ポリシー・ファイルを更新します。 |
Fusion Middleware 12cで使用されているセキュリティ・アルゴリズムには、JDK用の追加のポリシー・ファイルが必要になるものがあります。 強化された暗号化(AES 256など)を使用する予定がある場合は、アップグレードの前に、最新の必須ポリシー・ファイルをJDKに適用することをお薦めします。 「強化された暗号化(AES 256)を使用する場合のポリシー・ファイルの更新」を参照してください。 |
オプション アップグレードの前に、古いデータまたは使用しないデータを削除します。 |
パフォーマンスを最適化するために、アップグレードされた環境で使用されないデータおよびオブジェクトをパージすることをお薦めします。 「不使用データのパージ」を参照してください。 |
Oracle Database ユーザーのみ必要エディション・ベースの再定義(EBR)に対応したスキーマをアップグレードする前に、まず、データベース・サーバーに接続して、12c (12.2.1.3.0)のデータベース・サーバーにエディションを作成する必要があります。 | エディション・ベースの再定義(EBR)データベースを使用している場合は、アップグレードを開始する前にエディションを作成する必要があります。
「エディション・ベースの再定義のためのサーバー上でのエディションの作成」を参照してください。 |
オプション アップグレード・アシスタントを実行するための非SYSDBAユーザーを作成します。 |
アップグレード・アシスタントを実行するための、FMWユーザーを作成することをお薦めします。ユーザーFMWは、システム管理者の権限を持たずにアップグレード・アシスタントを実行できます。 |
オプション 開始前に、現在ドメイン内にあるスキーマを識別します。 |
アップグレードの開始前に、アップグレード前のドメイン内のスキーマを把握することが重要です。スキーマ所有者の名前とパスワード、および各スキーマのバージョンを把握する必要があります。 |
完全なバックアップの作成
アップグレードを開始する前に、Oracle Fusion Middlewareスキーマをホストするすべてのデータベースを含め、システムに重要なファイルをすべてバックアップします。
バックアップには、アップグレードが失敗した場合にコンテンツをアップグレード前の状態にリストアできるようにSYSTEM.SCHEMA_VERSION_REGISTRY$
表が含まれている必要があります。
実際のアップグレードを続行する前に、アップグレード・アシスタントの「前提条件」画面で、バックアップが実行されていることを確認するよう要求されます。ただし、アップグレード・アシスタントではバックアップが作成されていることが確認されない点に注意してください。
-
Oracle Fusion Middlewareの管理の環境のバックアップ
-
Oracle Fusion Middlewareのアップグレードのプランニングの12cのための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を実行して既存のスキーマを更新する際、正常に更新できなかった場合は、元のスキーマをリストアしてからやりなおす必要があります。アップグレード・アシスタントを実行する前に、既存のデータベース・スキーマおよびスキーマ・バージョン・レジストリを必ずバックアップします。
ノート:
アップグレード・アシスタントを使用してスキーマをアップグレードする前に、完全なデータベースのバックアップを実行する必要があります。アップグレード中に、バックアップが実行されていることを確認する必要があります。親トピック: 完全なバックアップの作成
カスタマイズされたドメインおよび環境設定のメンテナンス
アップグレード前環境で、ドメインで生成されたサーバー起動スクリプトまたは構成ファイルを変更した場合、これらの変更内容がインストール、ドメイン・アップグレードおよび再構成の操作中に上書きされることに注意することが重要です。アップグレード後もそのまま使用できるように、カスタマイズされたファイルを共有ライブラリの場所に保存してください。
すべてのドメイン・インストールには、動的に生成されたドメインおよび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.3.0)に対して動作保証されたJDKは1.8.0_131でした。
環境が動作保証要件を満たしていることの確認
Oracleでは、動作保証済のすべてのシステムおよび環境で製品のパフォーマンスをテストおよび検証しています。製品をインストールする場合、サポートされているハードウェアまたはソフトウェア構成を使用します。
新しい動作保証要件が確認されると、それらはすぐに適切な動作保証に関するドキュメントに追加されます。新しい動作保証要件は随時確認される場合があるため、動作保証に関するドキュメントはドキュメント・ライブラリの外部に置かれ、Oracle Technology Networkで提供されています。12c (12.2.1.3.0)の動作保証マトリックスに関する説明を参照してください。
親トピック: 動作保証およびシステム要件の確認
システム要件と仕様の確認
ディスク領域、使用可能なメモリー、特定のプラットフォーム・パッケージおよびパッチ、その他のオペレーティング・システム固有の項目などのシステム要件が満たされていることを確認することが重要です。
Oracle Fusion Middlewareのシステム要件と仕様に関するドキュメントを使用して、動作保証要件が満たされていることを確認します。たとえば、12c (12.2.1.3.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ビット・ソフトウェア要件をサポートするハードウェアを調達する
アップグレード・プロセスを開始する前に、サポートされている適切なターゲット・ハードウェアが存在することを確認してください。
すべてのプロセスを停止する
アップグレードの前に、管理対象サーバー、管理サーバー、およびノード・マネージャがホスト上で起動している場合はこれらも含めて、すべてのプロセスを停止する必要があります。
管理対象サーバーの停止
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ビット・ホスト・マシンからすべてのファイルをバックアップする
11gデプロイメント全体の完全バックアップを作成したことを確認してからアップグレード・プロセスを開始する必要があります。移行中に問題が発生した場合、これらのファイルを使用してプロセスを再度開始する必要があります。
ノート:
同一のマシンで32ビットから64ビットへアップグレードする場合、アップグレードが失敗した場合、ソース環境が破損するリスクがあります。詳細は、Oracle Fusion Middleware管理者ガイドの環境のバックアップに関する項を参照してください。
アップグレード時に、次のコンテンツにアクセスする必要があります。
-
11g_DOMAIN_HOME
-
11g_ORACLE_HOME/wlserver/common/
にある11g/nodemanager
ディレクトリ
『Oracle Fusion Middleware管理者ガイド』の環境のバックアップに関する項で説明されている一部のバックアップおよびリカバリ手順は、製品に固有です。完全バックアップを作成するまでアップグレードを続行しないでください。
11gのホスト名およびIPアドレスを使用してターゲットの64ビット・マシンを設定する
ターゲット・マシンのホスト名およびIPアドレスはホストと同一にする必要があります。そのため、ソース・マシンのIPアドレスおよび名前を変更するか、ソース・マシンを停止してネットワークの干渉を回避する必要があります。
IPアドレスおよびホスト名を変更するプロセスは、オペレーティング・システムによって異なります。詳細は、オペレーティング・システムの管理ドキュメントを参照してください。
11gのバックアップを32ビット・ホストから64ビット・ホストにリストアする
11gで使用したものと同じディレクトリ構造を使用して、32ビット・ホストからバックアップしたファイルをリストアします。ターゲット・マシンのディレクトリ構造は、ホスト・マシンのディレクトリ構造と同じである必要があります。
Oracle Fusion Middleware管理者ガイドの環境のリカバリに関する項を参照してください。
12cの製品ディストリビューションのターゲット・マシンへのインストール
アップグレードには、ホーム外のアプローチをお薦めします。したがって、12c製品ディストリビューションは、ターゲット・マシン上の新しいOracleホームでインストールする必要があります。
インストールするコンポーネントの詳細は、コンポーネント固有のインストール・ガイドを参照してください。
標準的なアップグレード手順を使用してターゲットの64ビット環境をアップグレードする
ターゲット・マシンに製品をインストールしたら、コンポーネント固有のアップグレード・ガイドで指定されたアップグレード・ユーティリティを使用して各製品コンポーネントを個々にアップグレードし、アップグレード後のタスクを実行する必要があります。
他のコンポーネントをアップグレードする場合は、コンポーネント固有のアップグレード・ガイドを参照してください。
ノート:
ノード・マネージャ・アップグレード手順では、元のノード・マネージャ・ファイルにアクセスする必要があります。32ビット・ホスト・マシンからすべてのファイルをバックアップする手順の一部として、32ビット・ソース・マシンからバックアップされた11gノード・マネージャ・ファイルを使用します。Oracle Fusion Middlewareをホストしているデータベースがサポートされていることの確認
Oracle Fusion Middleware 12cを実行する前に、サポートされるOracle Databaseを必須のスキーマで構成しておく必要があります。
ノート:
データベース・バージョンがサポートされていない場合は、サポートされているバージョンにアップグレードしてからアップグレードを開始する必要があります。『Oracle Fusion Middlewareのアップグレードのプランニング』の12cのためのOracle Databasesのアップグレードと準備に関する項を参照してください。親トピック: 動作保証およびシステム要件の確認
このリリースのOracle Fusion MiddlewareでJDKが動作保証されていることの確認
このドキュメントの発行時に12c (12.2.1.3.0)で動作保証されていたJDKは1.8.0_131でした。
Oracle Technology Network (OTN)のOracle Fusion Middlewareのサポートされるシステム構成 の情報を参照して、使用する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に適用せずに、強化された暗号化の使用を試行すると、アップグレードに失敗することがあります。その場合は、アップグレード前の環境全体をリストアして、アップグレードを最初からやり直す必要があります。未使用データのパージ
アップグレード前に使用しないデータをパージし、パージ方法を管理することで、アップグレード・プロセスを最適化できます。
一部のコンポーネントには、自動化されたパージ・スクリプトがあります。パージ・スクリプトを使用する場合、パージが完了するまで待ってから、アップグレード・プロセスを開始してください。アップグレード・アシスタントを使用してスキーマをアップグレードするときに、パージ・スクリプトを実行していると、アップグレードは失敗する可能性があります。
エディション・ベースの再定義のためのサーバー上でのエディションの作成
エディション・ベースの再定義(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;
アップグレード・アシスタントを実行するための非SYSDBAユーザーの作成
Upgrade Assistantを実行するために、FMW
という非SYSDBAユーザーを作成することをお薦めします。このユーザーには、スキーマの変更に必要な権限はありますが、完全な管理者権限はありません。
ノート:
SYSDBAではないユーザーFMWは、アップグレード・アシスタントを実行するためにのみ作成されます。このステップが完了したら、このFMWユーザーを削除してください。アップグレード・アシスタントを実行するために必要な権限は、リリースごとに異なる可能性があります。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;
アップグレードで使用可能な既存のスキーマの識別
このオプションのタスクでは、スキーマのバージョン・レジストリを問い合せて、アップグレードを開始する前に使用可能なスキーマのリストを確認できます。このレジストリには、バージョン番号、コンポーネント名および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 ORDER BY MRC_NAME, COMP_ID;
-
生成されたレポートを確認します。
あるスキーマでアップグレードの必要がない場合、
schema_version_registry
表には、アップグレード前のバージョンでそのスキーマが保持されます。 -
既存のスキーマに使用されているスキーマ接頭辞名を確認します。新しい12cスキーマの作成時に、同じ接頭辞を使用することになります。
ノート:
-
既存のスキーマが、サポートされているバージョンからのものでない場合、12c (12.2.1.3.0)のアップグレード手順を使用する前に、それらをサポートされているバージョンにアップグレードする必要があります。詳細は、アップグレード前のバージョンのドキュメントを参照してください。
-
一部のコンポーネント(Oracle Enterprise Data Quality、Oracle GoldenGate Monitor、Oracle GoldenGate Veridataなど)では、標準的なOracle Fusion Middlewareのサポート対象バージョン以外のバージョンからのアップグレードがサポートされています。
-
11gでポリシー・ストアとしてOracle Internet Directory (OID)を使用していた場合、アップグレードの前に、ポリシー・ストアをデータベースベースのポリシー・ストアに再度関連付ける必要があります。
-
Oracle Fusion Middlewareリリース12c (12.2.1.3.0)でアップグレード可能な製品のスキーマのみをアップグレードできます。まだ12c (12.2.1.3.0)へのアップグレードが可能になっていないコンポーネントを含むドメインをアップグレードしないでください。
Oracle WebCenterのアップグレード前のタスクの実行
Oracle WebCenter製品の12c (12.2.1.3.0)にアップグレードする前に、環境に適用されるアップグレード前のタスクを実行します。
Oracle WebCenterのアップグレード前のタスクは、次のとおりです。
アップグレード前のタスク | 詳細情報 |
---|---|
アップグレードの前に、非推奨または廃止されたコンポーネントをすべて無効化します。 |
|
WebCenter Portal 11g環境でファイルベースのポリシー・ストアまたはOracle Internet Directory (OID)をポリシー・ストアとして使用している場合、ポリシー・ストアをデータベースベースのポリシー・ストアに移行します。 |
『Oracle Platform Security Servicesによるアプリケーションの保護』のデータベース・ベースのセキュリティ・ストアの使用に関する項 |
Oracle WebCenter Contentのアップグレード前のタスクを実行します(ContentまたはWebCenter Content Web UIをアップグレードする場合)。 |
|
Oracle WebCenter Enterprise Captureのアップグレード前のタスクを実行します(Enterprise Captureをアップグレードする場合)。 |
|
Oracle WebCenter Portalのアップグレード前のタスクを実行します(WebCenter Portalをアップグレードする場合)。 |
アップグレード前の不要なコンポーネントの無効化
次のコンポーネントは廃止されたか無効であるため、アップグレードの前に無効化する必要があります。
ノート:
これらのコンポーネントを無効化しない場合、アップグレードが失敗し、Content Serverが起動できなくなる可能性があります。-
AppAdapterUniversal
-
CIS_Helper
-
ContentTrackerReports
-
SiteStudioExternalApplications
-
FormEditor (非推奨になったFCKEditorを使用しています)
-
proxyconnections8
-
UrmAgent
-
PDFExportConverter (IBR)
コンポーネントの無効化の詳細は、『Oracle WebCenter Contentの管理』のコンポーネント・マネージャの使用によるコンポーネントの有効化または無効化に関する項を参照してください。
WebCenterのアップグレード可能なスキーマの判別
この表では、12cにアップグレード可能なWebCenterスキーマについて説明します。環境によっては、一部のスキーマを使用しない場合があります。
表2-2 アップグレード可能なWebCenterスキーマ
コンポーネント名 | スキーマ | アップグレード前のスキーマ・バージョン | アップグレード後のスキーマ・バージョン | 依存関係 |
---|---|---|---|---|
Oracle Enterprise Capture |
|
11.1.1.8 11.1.1.9 12.2.1.0 12.2.1.1 12.2.1.2 |
12.2.1.3.0 |
メタデータ・サービス(_MDS_ CaptureはADFアプリケーションであるため、WebCenterサーバーの起動前にMDSスキーマがアップグレードされている必要があります。 Oracle Platform Security Services (_OPSS) CaptureはOPSSスキーマを直接使用しませんが、アップグレード・プロセスにOPSSスキーマのアップグレードが含まれている必要があります。 |
Oracle Portal |
|
11.1.1.6 12.2.1.0 12.2.1.1 12.2.1.2 |
12.2.1.3.0 |
ありません。 |
WebCenter Portal (以前のWebCenter Spaces) |
|
11.1.1.6 11.1.1.7 12.2.1.0 12.2.1.1 12.2.1.2 |
12.2.1.3.0 |
|
Discussions (WebCenter Suite) |
|
11.1.1.7 12.2.1.0 12.2.1.1 12.2.1.2 |
12.2.1.3.0 |
ありません。 |
ディスカッション・クローラ |
|
11.1.1.8 12.2.1.0 12.2.1.1 |
12.2.1.1.0 |
ノート: |
アクティビティ・グラフおよびアナリティクス |
|
11.1.1.7 12.2.1.0 12.2.1.1 |
12.2.1.1.0 |
ありません。 |
ポートレット |
|
11.1.1.2 12.2.1.0 12.2.1.1 |
12.2.1.1.0 |
ありません。 |
Oracle Content Server 11g - 完全 |
|
11.1.1.6 11.1.1.7 11.1.1.8 11.1.1.9 12.2.1.0 12.2.1.1 |
12.2.1.1.0 |
ありません。 |
Oracle WebCenter Sites | prefix_WCSITES |
11.1.1.8.0 12.2.1.0 12.2.1.1 12.2.1.2 |
12.2.1.3.0 |
ありません。 |
Oracle WebCenter Content: Imaging。 |
|
11.1.1.7 11.1.1.8 11.1.1.9 12.2.1.0 12.2.1.1 12.2.1.2 |
12.2.1.3.0 |
IPMスキーマの最新のアップグレード前バージョンは11.1.1.2.1です。 |