Oracle® Fusion Middleware

Oracle HTTP Serverのアップグレード

12c (12.2.1.2)

E82834-02(原本部品番号:E77927-03)

2017年1月

このガイドでは、このリリースのOracle Fusion MiddlewareへのOracle HTTP Serverのアップグレードについて説明します。

Oracle Fusion Middleware Oracle HTTP Serverのアップグレード, 12c (12.2.1.2)

E82834-02

Copyright © 2014, 2017, Oracle and/or its affiliates. All rights reserved.

原本主著者: Shynitha Shanthakumar

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

このガイドで説明する新機能

- 12cの新機能と変更された機能

- 12cに関するこのドキュメントにおけるその他の大きな変更

1 Oracle HTTP Serverの12c (12.2.1.2)へのアップグレードの概要

- 1.1 Oracle HTTP Serverのアップグレードの開始ポイントについて

- 1.2 Oracle HTTP Serverの標準トポロジについて

- 1.2.1 Oracle HTTP Serverを含むFusion Middleware Infrastructureの標準アップグレード・トポロジ

- 1.2.1.1 WebLogicドメインに関連付けられていないスタンドアロン・エージェントのOracle HTTP Server標準アップグレード・トポロジ

- 1.3 Oracle HTTP Server 11gと12cの違い

- 1.4 アップグレードの制限事項について

- 1.5 このガイドの使用方法

- 1.6 Oracle HTTP Serverがスタンドアロンか管理対象(コロケート)かの判断

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

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

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

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

- 2.2.2 カスタム・ドメイン環境設定のメンテナンス

- 2.3 テストのための本番環境のクローニング

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 2.6 未使用データのパージ

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

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

- 2.9 アップグレードに対応可能な既存のスキーマの特定

第I部 Oracle HTTP Serverのアップグレード(11gから12c)

3 スタンドアロンOracle HTTP Serverのアップグレード(11gから12c)

- 3.1 スタンドアロンOracle HTTP Serverのアップグレード・プロセス(11gから12c)について

- 3.2 アップグレード前の重要な考慮事項

- 3.2.1 Oracle Web Cache 11gユーザー

- 3.2.2 WebGate 11gユーザー

- 3.2.3 WebGateのログ・ファイル名の更新

- 3.2.4 11gのアプリケーション・アーティファクト

- 3.2.5 11gのアプリケーション・アーティファクトの移行

- 3.3 スタンドアロンOracle HTTP Serverのインストール

- 3.4 サーバーとプロセスの停止

- 3.5 ドメイン・コンポーネント構成のアップグレード

- 3.5.1 Upgrade Assistantの起動

- 3.5.1.1 Upgrade Assistantパラメータ

- 3.5.2 Upgrade Assistantを使用した11gドメイン・コンポーネントのアップグレード

- 3.5.3 ドメイン固有コンポーネント構成のアップグレードの確認

- 3.6 サーバーとプロセスの起動

- 3.6.1 スタンドアロンOracle HTTP Serverの起動

- 3.7 アップグレードの確認

4 管理対象Oracle HTTP Serverのアップグレード(11gから12c)

- 4.1 管理対象Oracle HTTP Serverのアップグレード・プロセス(11gから12c)について

- 4.2 製品ディストリビューションのインストール

- 4.3 アップグレード前の準備状況チェックの実行

- 4.3.1 アップグレード前の準備状況チェックの実行について

- 4.3.2 準備状況モードでのUpgrade Assistantの起動

- 4.3.2.1 Upgrade Assistantパラメータ

- 4.3.3 Upgrade Assistantを使用した準備状況チェックの実行

- 4.3.4 準備状況レポートの理解

- 4.4 サーバーとプロセスの停止

- 4.5 RCUを使用した必要な12cスキーマの作成

- 4.6 ドメインの再構成

- 4.6.1 ドメインのバックアップ

- 4.6.2 再構成ウィザードの起動

- 4.6.3 再構成ウィザードを使用したドメインの再構成

- 4.7 ドメイン・コンポーネント構成のアップグレード

- 4.7.1 アップグレード・アシスタントの起動

- 4.7.1.1 Upgrade Assistantパラメータ

- 4.7.2 Upgrade Assistantを使用したドメイン・コンポーネントのアップグレード

- 4.7.3 ドメイン固有コンポーネント構成のアップグレードの確認

- 4.8 サーバーとプロセスの起動

- 4.8.1 Oracle HTTP Serverの起動

- 4.9 アップグレードの確認

- 4.10 WLSTを使用したアップグレード後のウォレットのKSSデータベースへのインポート

第II部 Oracle HTTP Serverのアップグレード(以前の12cリリースから)

5 スタンドアロンOracle HTTP Serverのアップグレード(以前の12cリリースから)

- 5.1 スタンドアロンOracle HTTP Serverのアップグレード・プロセス(以前の12cリリースから)について

- 5.2 スタンドアロンOracle HTTP Serverのインストール

- 5.3 サーバーとプロセスの停止

- 5.4 ドメインの再構成

- 5.4.1 ドメインのバックアップ

- 5.4.2 再構成ウィザードの起動

- 5.4.3 再構成ウィザードを使用した既存のドメインの再構成

- 5.5 スタンドアロン・システム・コンポーネント構成のアップグレード

- 5.5.1 アップグレード・アシスタントの起動

- 5.5.1.1 Upgrade Assistantパラメータ

- 5.5.2 Upgrade Assistantを使用したスタンドアロン・システム・コンポーネント構成のアップグレード

- 5.5.3 ドメイン固有コンポーネント構成のアップグレードの確認

- 5.6 アップグレードの確認

- 5.6.1 ノード・マネージャの起動

- 5.6.2 スタンドアロンOracle HTTP Serverの起動

- 5.7 サーバーとプロセスの起動

6 管理対象Oracle HTTP Serverのアップグレード(以前の12cリリースから)

- 6.1 管理対象Oracle HTTP Serverのアップグレード・プロセス(以前の12cリリースから)について

- 6.2 製品ディストリビューションのインストール

- 6.3 アップグレード前の準備状況チェックの実行

- 6.3.1 アップグレード前の準備状況チェックの実行について

- 6.3.2 準備状況モードでのUpgrade Assistantの起動

- 6.3.2.1 Upgrade Assistantパラメータ

- 6.3.3 Upgrade Assistantを使用した準備状況チェックの実行

- 6.3.4 準備状況レポートの理解

- 6.4 サーバーとプロセスの停止

- 6.5 製品スキーマのアップグレード

- 6.5.1 アップグレードに対応可能な既存のスキーマの特定

- 6.5.2 Upgrade Assistantの起動

- 6.5.2.1 Upgrade Assistantパラメータ

- 6.5.3 Upgrade Assistantを使用した製品スキーマのアップグレード

- 6.5.4 スキーマのアップグレードの確認

- 6.6 ドメインの再構成

- 6.6.1 ドメインのバックアップ

- 6.6.2 再構成ウィザードの起動

- 6.6.3 再構成ウィザードを使用したドメインの再構成

- 6.7 ドメイン・コンポーネント構成のアップグレード

- 6.7.1 Upgrade Assistantの起動

- 6.7.1.1 Upgrade Assistantパラメータ

- 6.7.2 Upgrade Assistantを使用したドメイン・コンポーネントのアップグレード

- 6.7.3 ドメイン固有コンポーネント構成のアップグレードの確認

- 6.8 サーバーとプロセスの起動

- 6.8.1 Oracle HTTP Serverの起動

- 6.9 アップグレードの確認

- 6.10 WLSTを使用したアップグレード後のウォレットのKSSデータベースへのインポート

A SHA-2アルゴリズムを使用して署名された証明書でMD5アルゴリズムを使用して署名された証明書を置き換え

- A.1 ウォレット内にMD5アルゴリズムで署名した証明書が存在するかどうかを確認する方法

- A.2 MD5アルゴリズムで署名された証明書をウォレットから削除する方法

- A.3 SHA-2アルゴリズムで署名された証明書をウォレットに追加する方法

- A.4 MD5アルゴリズムで署名された証明書のサポートを12.2.1.2 Oracle HTTP Serverデプロイメントで有効にする方法

はじめに

ここでは、次の項目について説明します。

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント
12cドキュメント・ライブラリでは、アップグレード・ドキュメントがタスクに基づいて編成されています。タスク固有のページには、一般的なアップグレード手順および関連ドキュメントへのダイレクト・リンクが用意されています。

- 表記規則

対象読者

このマニュアルは、Oracle Fusion Middlewareのアップグレードを担当するOracle Fusion Middlewareシステム管理者を対象としています。このマニュアルは、読者が次の事項に関する知識を持っていることを前提としています。

- 既存のデプロイメントのOracle Fusion Middleware 11gまたはOracle Fusion Middleware 12cシステム管理および構成情報

- アップグレードするシステムの構成および予測される動作

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティへの取り組みについては、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)にアクセスしてください。

Oracleサポートへのアクセス

サポートを購入したオラクル社のお客様は、My Oracle Supportを介して電子的なサポートにアクセスできます。詳細は、http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info、聴覚に障害があるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

関連ドキュメント

12cドキュメント・ライブラリにおいて、アップグレード・ドキュメントはタスクに基づいて編成されています。タスク固有のページには、一般的なアップグレード手順および関連ドキュメントへのダイレクト・リンクが用意されています。

詳細はOracle Fusion Middlewareライブラリを参照してください。

- インストールの情報は、Fusion Middlewareインストール・ドキュメントを参照してください。

- アップグレードの情報は、Fusion Middleware 12cアップグレード・ドキュメントを参照してください。

- 管理関連の情報は、Fusion Middleware 12c管理ドキュメントを参照してください。

- リリース関連の情報は、Fusion Middleware 12cリリース・ノートを参照してください。

表記規則

このマニュアルでは次の表記規則を使用します。

表記規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

このガイドで説明する新機能

次のトピックでは、スタンドアロンOracle HTTP Serverの新機能や変更された機能について紹介し、詳細情報へのリンクを提供します。

- 12cの新機能と変更された機能

- 12cに関するこのドキュメントにおけるその他の大きな変更

12cの新機能と変更された機能

アップグレード・プロセスを開始する前に、次のリストで12cのスタンドアロンOracle HTTP Serverの変更点を確認してください。

- インストーラは、Oracle HTTP Serverの個別のインスタンス・ディレクトリを作成しなくなりました。スタンドアロンOHSのインスタンス情報は、新しいスタンドアロン・ドメインホームに格納されます。詳細は、「Oracle HTTP Serverの標準アップグレード・トポロジ(WebLogicドメインに関連付けられていないスタンドアロン・エージェントの場合)」を参照してください。

- OPMNエージェントとopmnctlコマンドライン・ユーティリティは、Oracle Fusion Middlewareでは使用されなくなりました。かわりに、システム・コンポーネントはNodeManagerおよびWLSTコマンドによって管理されます。

12cに関するこのドキュメントにおけるその他の大きな変更

MD5アルゴリズムで署名された証明書のサポートは削除されました。「SHA-2アルゴリズムを使用して署名された証明書でMD5アルゴリズムを使用して署名された証明書を置き換え」を参照してください。

1 Oracle HTTP Serverの12c (12.2.1.2)へのアップグレードの概要

開始前に、すべての概要情報を再確認して、Oracle HTTP Server 12c (12.2.1.2)の標準アップグレード・トポロジとアップグレード・パスについて理解しておいてください。

- Oracle HTTP Serverのアップグレードの開始ポイントについて
Oracle HTTP Server 12c (12.2.1.2)へのアップグレードは、サポート対象の11gおよび12cリリースから開始できます。

- Oracle HTTP Serverの標準トポロジについて
Oracle HTTP Serverの12c (12.2.1.2)へのアップグレード手順は、既存の製品トポロジ(11gまたは以前の12cリリースのどちらか)に応じて異なります。

- Oracle HTTP Server 11gと12cの違い
使用するOracle HTTP ServerをこのリリースのOracle Fusion Middlewareにアップグレードする前に、いくつかの主要な違いを考慮する必要があります。

- アップグレードの制限事項について
サポート対象の単一Oracle Fusion Middleware構成内で、複数の同一バージョンまたは異なるバージョンのOracle Fusion Middleware製品を使用している場合は、アップグレードの計画前に、相互運用性と互換性にかかわる要因について検討する必要があります。

- このガイドの使用方法
Oracle HTTP Serverのアップグレード計画は、そのデプロイメントがスタンドアロンと管理対象のどちらであるかに応じて異なります。

- Oracle HTTP Serverがスタンドアロンか管理対象(コロケート)かの判断
Oracle HTTP Serverは、Oracle Fusion MiddlewareのWebサーバー・コンポーネントです。これは、Oracle WebLogic Serverのリスナーと、Web上で静的ページ、動的ページ、およびアプリケーションをホストするためのフレームワークを提供します。WebLogic Serverドメイン内に構成したOracle HTTP Serverは、管理対象Oracle HTTP Serverと呼ばれます。これは、Oracle HTTP Serverインスタンスが、Enterprise Manager Fusion Middleware Control、WLSTコマンド行インタフェースまたはノード・マネージャを使用して、WebLogic Serverドメイン内にある他の要素と同様に管理できるためです。Oracle HTTPソフトウェアを、Oracle Fusion Middleware Infrastructureをインストールせずに個別のOracleホームにインストールする方法は、スタンドアロン・モードと呼ばれます。

1.1 Oracle HTTP Serverのアップグレードの開始ポイントについて

Oracle HTTP Server 12c (12.2.1.2)へのアップグレードは、サポート対象の11gおよび12cリリースから開始できます。

サポートされるリリースの開始ポイントは、次のとおりです。

- Oracle HTTP Server 11g リリース1 (11.1.1.7、11.1.1.8および11.1.1.9)

- Oracle HTTP Server 12c (12.1.2.0、12.1.3.0、12.2.1.0および12.2.1.1)

このガイドのアップグレード手順では、既存のOracle HTTP Server 11gドメインおよび既存の12cドメインをOracle Fusion Middleware 12c (12.2.1.2)にアップグレードする方法について説明しています。

1.2 Oracle HTTP Serverの標準トポロジについて

Oracle HTTP Serverの12c (12.2.1.2)へのアップグレード手順は、既存の製品トポロジ(11gまたは以前の12cリリースのどちらか)に応じて異なります。

結果として、Oracle HTTP Serverについて予測されるあらゆるインストールに対して、厳密な手順を示すことが難しくなります。そのため、このアップグレード・ドキュメントでは、いくつかの一般的なOracle HTTP Serverトポロジのアップグレードに対する手順について説明します。これに該当する一般的なトポロジを、標準アップグレード・トポロジと呼びます。

実際のトポロジとは異なることもありますが、ここで説明するトポロジは、同様のOracle HTTP Serverトポロジをアップグレードする際の参考として使用できます。

注意:
アップグレードを成功させるためのアップグレード・プロセスおよびプランニング・リソースの詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareのアップグレードのプランニング』のアップグレードの準備に関する項を参照してください。

12cリリースからのアップグレードの場合、標準トポロジは変更されません。11gからアップグレードする場合は、次に示す項を参照して特定のトポロジをアップグレードします。

- Oracle HTTP Serverを含むFusion Middleware Infrastructureの標準アップグレード・トポロジ
このトピックでは、Oracle HTTP Serverを含むOracle Fusion Middleware 11g Application Developerの標準アップグレード・トポロジと、このガイドのアップグレード手順実行後のOracle Fusion Middleware 12c Infrastructureトポロジを示します。

1.2.1 Oracle HTTP Serverを含むFusion Middleware Infrastructureの標準アップグレード・トポロジ

このトピックでは、Oracle HTTP Serverを含むOracle Fusion Middleware 11g Application Developerの標準アップグレード・トポロジと、このガイドのアップグレード手順実行後のOracle Fusion Middleware 12c Infrastructureトポロジを示します。

図1-1 Oracle HTTP Serverを含むInfrastructureの標準アップグレード・トポロジ

図1-1のほとんどの要素については、表1-1で説明しています。

表1-1 Oracle HTTP Serverを含むInfrastructureの標準アップグレード・トポロジの要素の説明

要素

説明と追加ドキュメントへのリンク

Oracle HTTP Serverを含む11g Application Developerトポロジ

これは図1-1の左側のラベルです。これは、Oracle Fusion Middleware 11g Application Developerインストーラを使用して作成された一般的な単一ホスト・トポロジを示します。

これは、2つの管理対象サーバーのクラスタと管理サーバーが含まれる単一ドメインで構成されます。また、スキーマとともにオプションのファイルベースのストアまたはデータベースが存在します。

図1-1には、11gドメインの一部としてのOracle HTTP Serverインスタンスも示します。

このドキュメントでは、このトポロジを、Oracle Fusion Middleware 12c Infrastructureディストリビューションを使用して作成した同等のトポロジにアップグレードする方法について順を追って説明します。

Oracle HTTP Serverを含む12c Infrastructureの標準インストール・トポロジ

これは図の右側のラベルです。これは、Oracle Fusion Middleware 12c Infrastructureディストリビューションを使用して作成された一般的な単一ホスト・トポロジを示します。

Application Developer 11gトポロジと同様に、これも、2つの管理対象サーバーのクラスタと管理サーバーが含まれる単一ドメインで構成されます。

図1-1には、12cドメインの一部としてのOracle HTTP Serverインスタンスも示します。

「ドメインに関連付けられた」Oracle HTTP Server

Oracle WebLogic Serverドメインに「関連付ける」ように構成されているOracle HTTP Server 11gインスタンス。Oracle Fusion Middleware 11gでは、Oracle HTTP Serverなどのシステム・コンポーネント・インスタンスは、Oracle Universal Installerベースの構成ウィザードで構成され、Oracle Process Manager and Notification Serverを使用して管理されます。

Oracle HTTP Server

図の左側のOracle HTTP Server 11gインスタンスと異なり、12cトポロジに示すOracle HTTP Server 12cインスタンスは、Oracle Fusion Middleware構成ウィザードを使用してドメインの一部として構成されます。これは、Oracle Enterprise Manager Fusion Middleware Control、Oracle WebLogic Scripting Tool (WLST)およびOracle WebLogic Serverノード・マネージャ・ソフトウェアを使用して管理されます。

- WebLogicドメインに関連付けられていないスタンドアロン・エージェントのOracle HTTP Server標準アップグレード・トポロジ
12cでは、スタンドアロンのOracle HTTP ServerはOracle WebLogic Serverドメインで管理されることも、このドメインに関連付けられることもありません。スタンドアロンOracle HTTP Server 12cトポロジは、Oracle Fusion Middleware Infrastructureがなくてもインストールおよび構成できます。ただし、管理対象Oracle HTTP Serverは、既存のOracle WebLogic Serverドメインに関連付けられます。スタンドアロンのシナリオでは、Oracle HTTP Serverソフトウェアを独自のOracleホームにインストールし、Oracle HTTP Serverインスタンスを独自のスタンドアロン・ドメインに構成します。

1.2.1.1 WebLogicドメインに関連付けられていないスタンドアロン・エージェントのOracle HTTP Server標準アップグレード・トポロジ

12cでは、スタンドアロンOracle HTTP ServerがOracle WebLogic Serverドメインで管理されることも、このドメインに関連付けられることもありません。スタンドアロンOracle HTTP Server 12cトポロジは、Oracle Fusion Middleware Infrastructureがなくてもインストールおよび構成できます。ただし、管理対象Oracle HTTP Serverは、既存のOracle WebLogic Serverドメインに関連付けられます。スタンドアロンのシナリオでは、Oracle HTTP Serverソフトウェアを独自のOracleホームにインストールし、Oracle HTTP Serverインスタンスを独自のスタンドアロン・ドメインに構成します。

注意:

- スタンドアロンOracle HTTP Serverのインストール方法および構成方法の詳細は、『Oracle Fusion Middleware Oracle HTTP Serverのインストールと構成』のOracle HTTP Serverのインストールの概要に関する項を参照してください。

- 最新の12cスタンドアロン・ドメインの詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareの理解』のスタンドアロン・ドメインの説明に関する項を参照してください。

- Oracle HTTP Serverの管理シナリオおよび主な機能の詳細は、『Oracle HTTP Server管理者ガイド』の「Oracle HTTP Serverの概要」を参照してください。

- 管理対象Oracle HTTP Serverのアップグレードの詳細は、『Oracle Fusion Middleware Infrastructureへのアップグレード』の「インフラストラクチャのアップグレードの実行」を参照してください。

図1-2に、スタンドアロンのOracle HTTP Serverトポロジを示します。

図1-2 スタンドアロンOracle HTTP Serverのアップグレード・トポロジ

表1-2に、このトポロジの要素の説明を示します。

表1-2 Oracle Fusion MiddlewareスタンドアロンOracle HTTP Serverアップグレード・トポロジの要素の説明

要素

説明と追加ドキュメントへのリンク

WEBHOST

Oracleドキュメントで使用される標準的な用語で、Web層をホストするマシンを指します。

スタンドアロン・ドメイン

スタンドアロン・ドメインは11gから12cにアップグレードする場合にのみ作成されます。12.1.2.0、12.1.3.0、12.2.1.0および12.2.1.1からアップグレードする場合は、すでにスタンドアロン・ドメインが存在しているため、スタンドアロン・ドメインを作成する必要はありません。

スタンドアロン・ドメインにはOracle WebLogicドメインに類似したディレクトリ構造がありますが、これには管理サーバーまたは管理対象サーバーは含まれていません。Oracle WebLogic Serverのノード・マネージャおよびその他のツールを使用すると、スタンドアロンOracle HTTP Serverインスタンスを管理できます。

スタンドアロン・ドメインの詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareの理解』のスタンドアロン・ドメインの説明に関する項を参照してください。

1.3 Oracle HTTP Server 11gと12cの違い

使用するOracle HTTP ServerをこのリリースのOracle Fusion Middlewareにアップグレードする前に、いくつかの主要な違いを考慮する必要があります。

表1-3に、Oracle HTTP Server 11gと12cの主な相違点を示します。

表1-3 Oracle HTTP Server 11gと12cの相違点

Oracle HTTP Server 11g:

Oracle HTTP Server 12c:

通常、Oracle HTTP Serverインスタンスは、11g Middlewareホームとは別のOracleインスタンス・ディレクトリに構成されます。

Oracle Fusion Middleware構成ウィザードを使用して、Oracle HTTP ServerインスタンスをOracle WebLogic Serverドメインの一部として構成できます。

Oracle HTTP Serverインスタンスは、Oracle Process Manager and Notification Server (OPMN)管理ソフトウェアを使用して管理されます。必要に応じて、Oracle HTTP ServerインスタンスをWebLogicドメインと関連付けることもできます。

Oracle Application Server Infrastructureドメインの一部として構成した場合、Oracle HTTP Serverインスタンスは、Oracle Enterprise Manager Fusion Middleware ControlとOracle WebLogic Scripting Tool (WLST)を使用して管理できます。
Oracle Fusion Middleware 12cでは、ノード・マネージャ・エージェントが、Oracle HTTP Serverインスタンスへの管理リクエストの委任と実行を担当します。

mod_ossoはサポート対象で、Oracle HTTP Server 11gに含まれます。
mod_ossoは、12cではサポートされないため、11gで使用した場合はアップグレード後に無効化されます。

mod_ossoはサポート対象外で、Oracle HTTP Server 12cには含まれません。
かわりに、Oracle WebGateを使用することをお薦めします。WebGateをOracle HTTP Serverにインストールできます。Oracle HTTP ServerでのWebGateの構成の詳細は、Oracle Fusion Middleware Oracle HTTP Serverのインストールと構成を参照してください。

Oracle Fusion Middleware 12cにおけるOracle HTTP Serverなどのシステム・コンポーネントの構成および管理方法に関する変更点と、Oracle Fusion Middleware 12cにおけるその他の重要な変更点の詳細は、次を参照してください。

- 12cの新機能と変更された機能

- 12cの新しい用語と非推奨用語

- WebLogic Management Frameworkとは

1.4 アップグレードの制限事項について

サポート対象の単一Oracle Fusion Middleware構成内で、複数の同一バージョンまたは異なるバージョンのOracle Fusion Middleware製品を使用している場合は、アップグレードの計画前に、相互運用性と互換性にかかわる要因について検討する必要があります。

相互運用性

Oracle Fusion Middleware製品のコンテキストでは、相互運用性は、サポート対象のOracle Fusion Middleware構成内で同一バージョン(またはリリース)の2つのOracle Fusion Middleware製品またはコンポーネントを連係動作(相互運用)できる能力と定義されています。 具体的に言うと、相互運用性は、リリース番号またはバージョン番号の最初の4桁が同じ場合に該当します。たとえば、Oracle Fusion Middleware 12c (12.2.1.0)コンポーネントは、通常、他の12c (12.2.1.2)コンポーネントと相互運用性があります。

互換性

Oracle Fusion Middleware製品のコンテキストでは、互換性は、異なるバージョン(またはリリース)の2つのOracle Fusion Middlewareコンポーネントを相互運用できる能力と定義されています。

Oracle Fusion Middlewareリリース12.2.1.2で使用可能な製品と機能のリストは、『Oracle Fusion Middleware相互運用性および互換性の理解』のOracle Fusion Middlewareで使用可能な製品と機能に関する項を参照してください。

ハードウェアまたはソフトウェアのアップグレードを実行する場合は、新しいオペレーティング・システムまたはコンピュータ・ハードウェアがOracle Fusion Middlewareソフトウェアのサポート保証対象になっていること確認してください。詳細は、次のマニュアルを参照してください。

- Oracle Fusion Middlewareでサポートされるシステム構成

- Oracle® Fusion Middlewareのシステム要件と仕様

1.5 このガイドの使用方法

Oracle HTTP Serverのアップグレード計画は、そのデプロイメントがスタンドアロンであるか管理対象であるかに応じて異なります。

開始ポイントとデプロイの種類に応じて、このガイドの次に示すいずれかの部に移動してください。さらに、各部には有効な開始ポイントごとのアップグレード手順について説明するサブセクションがあります。

- Oracle HTTP Serverのアップグレード(11gから12c)

- スタンドアロンOracle HTTP Serverのアップグレード(11gから12c)

- 管理対象Oracle HTTP Serverのアップグレード(11gから12c)

- Oracle HTTP Serverのアップグレード(以前の12cリリースから)

- スタンドアロンOracle HTTP Serverのアップグレード(以前の12cリリースから)

- 管理対象Oracle HTTP Serverのアップグレード(以前の12cリリースから)

注意:
アップグレードの開始前に、概要に関するトピックを再確認して、アップグレード前のタスクを完了してください。

1.6 Oracle HTTP Serverがスタンドアロンか管理対象(コロケート)かの判断

Oracle HTTP Serverは、Oracle Fusion MiddlewareのWebサーバー・コンポーネントです。これは、Oracle WebLogic Serverのリスナーと、Web上で静的ページ、動的ページ、およびアプリケーションをホストするためのフレームワークを提供します。WebLogic Serverドメイン内に構成したOracle HTTP Serverは、管理対象Oracle HTTP Serverと呼ばれます。これは、Oracle HTTP Serverインスタンスが、Enterprise Manager Fusion Middleware Control、WLSTコマンド行インタフェースまたはノード・マネージャを使用して、WebLogic Serverドメイン内にある他の要素と同様に管理できるためです。Oracle HTTPソフトウェアを、Oracle Fusion Middleware Infrastructureをインストールせずに個別のOracleホームにインストールする方法は、スタンドアロン・モードと呼ばれます。

アップグレードするOracle HTTP Serverが管理対象またはスタンドアロンのどちらかを判断するには、次の点を確認します。

11gユーザーの場合: ファイルORACLE_INSTANCE/config/OPMN/opmn/instance.properties内のregisteredプロパティを確認します。trueに設定されている場合はインスタンスが登録されています。管理対象Oracle HTTP Serverは登録されるので、登録されていない場合はスタンドアロンOracle HTTP Serverです。

12cユーザーの場合: ファイルDOMAIN_HOME/init-info/domain-info.xml内の要素extention-template-refとその属性nameを確認します。名前がOracle HTTP Server (Standalone)の要素が見つかった場合は、スタンドアロンOracle HTTP Serverです。また、名前がOracle HTTP Server (Collocated)の要素が見つかった場合はコロケートOHSです。

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

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

注意:
動作保証済のWindowsオペレーティング・システムにOracle HTTP Serverをインストールする場合は、そのシステムにmsvcr90.dllライブラリ・ファイルとlinkinfo.dllライブラリ・ファイルが存在していることを確認してください。Oracle HTTP Serverには、これらのファイルが必要です。詳細は、『Oracle Fusion Middleware Oracle HTTP Server リリース・ノート』の通知なしでHTTPDが終了する可能性のあるライブラリの欠落に関する項を参照してください。必須のライブラリが目的のシステムで取得できない場合は、Microsoft社のサポートに連絡して支援を求めてください。

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

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

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

- 本番環境のテスト用クローニング
実際の本番環境の完全な作業用コピーを作成し、クローン環境をアップグレードし、アップグレードしたコンポーネントが期待どおりに動作することを確認してから(必ず確認した後で)、本番環境をアップグレードします。

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

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

- 未使用データのパージ
アップグレード前に未使用データをパージし、パージの手法を維持することで、アップグレード・プロセスを最適化できます。

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

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

- アップグレードに対応可能な既存のスキーマの特定
このオプションのタスクにより、対応可能なスキーマのリストを確認してから、スキーマ・バージョン・レジストリに問い合せることでアップグレードを開始できます。このレジストリには、バージョン番号、コンポーネント名とID、作成日と変更日、カスタム接頭辞などのスキーマ情報が含まれています。

2.1 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.2)のデータベース・サーバーにエディションを作成する必要があります。

エディション・ベースの再定義(EBR)データベースを使用している場合は、アップグレードを開始する前にエディションを作成する必要があります。
「エディション・ベースの再定義のためのサーバー上でのエディションの作成」を参照してください。

オプション

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

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

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

オプション

開始前に、現在ドメインで使用されているスキーマを特定します。

アップグレードの開始前に、アップグレード前のドメインに存在しているスキーマを把握しておくことが重要です。スキーマ所有者の名前とパスワード、および各スキーマのバージョンを知る必要があります。

「アップグレードに対応可能な既存のスキーマの特定」を参照してください。

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

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

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

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

バックアップの作成の詳細は、次の各項を参照してください。

- 『Oracle Fusion Middleware Oracle Fusion Middlewareの管理』の環境のバックアップに関する項

- 『Oracle Fusion Middleware Oracle Fusion Middlewareのアップグレードのプランニング』の12cのためのOracle Databasesのアップグレードと準備に関する項

システムの完全なバックアップの作成に加え、スキーマ・バージョン・レジストリおよびアップグレードされた環境で使用するカスタム設定もバックアップする必要があります。次を参照してください。

- スキーマ・バージョン・レジストリ表のバックアップ
システム・バックアップには、SYSTEM.SCHEMA_VERSION_REGISTRY$表が含まれる必要があります。

- カスタム・ドメイン環境設定のメンテナンス
アップグレード前の環境でドメイン生成スクリプトまたはサーバー起動スクリプトを変更した場合、こうした変更はインストール、ドメイン更新および再構成操作の際に上書きされることに注意する必要があります。

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

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

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

注意:
Upgrade Assistantを使用してスキーマをアップグレードする前に、完全なデータベース・バックアップを実行する必要があります。アップグレード中、バックアップが実行されていることを確認する必要があります。

2.2.2 カスタム・ドメイン環境設定のメンテナンス

アップグレード前の環境でドメイン生成スクリプトまたはサーバー起動スクリプトを変更した場合、こうした変更はインストール、ドメイン更新および再構成操作の際に上書きされることに注意する必要があります。

どのドメインのインストールにも、動的に生成されたドメインおよびサーバーの起動スクリプト(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ファイルは、domain_home/binディレクトリに格納する必要があります。

注意:

setUserOverridesスクリプトをアップグレード前に作成できない場合は、設定を再適用する必要があります。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverのアップグレード』の起動スクリプトへのカスタマイズの再適用に関する項を参照してください。

2.3 本番環境のテスト用クローニング

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Oracle Fusion Middlewareをホストしているデータベースがサポートされていることの確認
Oracle Fusion Middleware 12cを実行する前に、サポートされるOracleデータベースを必須のスキーマで構成しておく必要があります。

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

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

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

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

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

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

Oracle Fusion Middlewareのシステム要件と仕様に関するドキュメントを使用して、動作保証の要件が満たされていることを確認してください。たとえば、12c (12.2.1.2)の動作保証マトリックスに、目的の製品が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ビット・ソフトウェア環境に移行する必要があります。

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

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

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

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

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

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

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

- (UNIX) DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url

- (Windows) DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url

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

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

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

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

- (UNIX) DOMAIN_HOME/bin/stopWebLogic.sh

- (Windows) DOMAIN_HOME\bin\stopWebLogic.cmd

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

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

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

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

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

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

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

11gのファイルのバックアップの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のバックアップに関する項を参照してください。

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

- 11gドメイン・ホーム

- $ORACLE_HOME/wlserver/common/にある11g /nodemanagerディレクトリ

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

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

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

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

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

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

64ビットターゲット・マシンに11gのファイルをリストアする方法の詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のリカバリに関する項を参照してください。

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

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

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

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

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

詳細なアップグレード手順は、アップグレードするコンポーネントのコンポーネント固有のアップグレード・ガイドを参照してください。

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

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

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

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

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

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

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

このマニュアルの発行時点で、12c (12.2.1.2)の動作保証済JDKは、1.8.0_101です。

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

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

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

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

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

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

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

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

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

2.6 未使用データのパージ

アップグレード前に未使用データをパージし、パージの手法を維持することで、アップグレード・プロセスを最適化できます。

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

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

エディション・ベースの再定義(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;

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

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

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

注意:
以前のリリースで非SYSDBAユーザーのFMWを作成していた場合は、アップグレードの開始前に、このユーザーを削除してから再作成する必要があります。古いFMWユーザーでUpgrade Assistantを実行することは、アップグレードの失敗につながることがあります(新しい権限が追加されているため)。既存のFMWユーザーを変更するのではなく、このユーザーを削除してから再作成することをお薦めします。

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

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

次の例では、welcome1がパスワードです。権限を付与する際に、実際のパスワードを指定していることを確認します。

create user FMW identified by welcome1;
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 Database 11.2.0.3データベース・ユーザーのみ: アップグレードを開始する前に、Oracleパッチ13036331を適用する必要があります。My Oracle Supportにアクセスしてパッチをダウンロードします。

このパッチを適用しない場合は、一部のスキーマで追加の権限を付与する必要があります。

2.9 アップグレードに対応可能な既存のスキーマの特定

このオプションのタスクにより、使用可能なスキーマのリストを確認してから、スキーマ・バージョン・レジストリに問い合せることでアップグレードを開始できます。このレジストリには、バージョン番号、コンポーネント名とID、作成日と変更日、カスタム接頭辞などのスキーマ情報が含まれています。

Upgrade Assistantの実行前に、アップグレードに対応可能なすべてのスキーマのリストをプレビューすることは、アップグレードするスキーマを個別に選択するか、Upgrade Assistantによる自動選択を許可してドメイン内のすべてのスキーマをアップグレードするかを決定する際に役立ちます。

ドメイン内に存在するアップグレードに対応可能なスキーマを特定するには:

1. Oracle Databaseを使用する場合、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 ;

2. 生成されたレポートを調査します。VERSION列の値が11.1.1.6.0以上で、STATUS列の値がVALIDの場合、そのスキーマはアップグレードのサポート対象になります。
アップグレードの必要がないスキーマがある場合は、そのスキーマのアップグレード前のバージョンがschema_version_registry表に維持されます。

3. 既存のスキーマに使用していたスキーマ接頭辞名をメモしておきます。新しい12cスキーマの作成時に、同じ接頭辞を使用することになります。

注意:

- 既存のスキーマがサポート対象のバージョンではない場合は、そのスキーマをサポート対象バージョンにアップグレードしてから、12c (12.2.1.2)のアップグレード手順を使用する必要があります。詳細は、アップグレード前のバージョンのドキュメントを参照してください。

- 一部のコンポーネント(Oracle Enterprise Data Quality、Oracle GoldenGate Monitor、Oracle GoldenGate Veridataなど)では、標準的なOracle Fusion Middlewareのサポート対象バージョン以外のバージョンからのアップグレードがサポートされています。

- 11gでファイルベースのポリシー・ストアを使用していた場合、Upgrade Assistantを実行する前に、ファイルベースのポリシー・ストアをデータベースベースのセキュリティ・ストアに再度関連付ける必要があります。
詳細は、「アップグレード前のファイルベースのポリシー・ストアの再関連付け」を参照してください。

- 11gでOIDベースのポリシー・ストアを使用していた場合は、アップグレードの実行前に必ず新しいOPSSスキーマを作成してください。このOPSSスキーマは、アップグレード後もLDAPベースのストアのままになります。

- RCU 11g (11.1.1.4以前)を使用して作成され、続いてORASDPMを11g (11.1.1.6以降)にアップグレードしたORASDPMスキーマをアップグレードする場合、FMWユーザーは12c (12.2.1.2)にアップグレードする前にユーザーprefix_ORASDPMにCREATE TABLE権限を付与する必要があります。

grant CREATE TABLE to prefix_ORASDPM;
prefixは作成時にスキーマに付けられた名前です。

- Oracle Fusion Middlewareリリース12c (12.2.1.2)のアップグレードに対応可能な製品のスキーマのみをアップグレードできます。まだ12c (12.2.1.2)へのアップグレードが未対応のコンポーネントを含むドメインはアップグレードしないでください。

第I部 Oracle HTTP Serverのアップグレード(11gから12c)

第I部は、次の章で構成されています。

- スタンドアロンOracle HTTP Serverのアップグレード(11gから12c)
この章では、既存のOracle WebLogic Server (WLS)ドメインで管理されていない、またはそのドメインに関連付けられていない、11gのスタンドアロンOracle HTTP Serverを12cにアップグレードする手順について説明します。

- 管理対象Oracle HTTP Serverのアップグレード(11gから12c)
この章では、管理対象Oracle HTTP Serverを11gから12cにアップグレードするための手順について説明します。このアップグレードの有効な開始ポイントは、11gのリリース11.1.1.7以降です。

3 スタンドアロンOracle HTTP Serverのアップグレード(11gから12c)

この章では、既存のOracle WebLogic Server (WLS)ドメインで管理されていない、またはそのドメインに関連付けられていない、11gのスタンドアロンOracle HTTP Serverを12cにアップグレードする手順について説明します。

この章の構成は、次のとおりです。

- スタンドアロンOracle HTTP Serverのアップグレード・プロセス(11gから12c)について
Oracle HTTP Serverのアップグレード・プロセスの概要に関するフローチャートとロードマップを再確認します。

- アップグレード前の重要な考慮事項
アップグレードを開始する前に、アップグレード中またはその後に既存の設定が影響を受けないことを確認することが重要です。Oracle Web CacheまたはWebGateを使用しているか、アプリケーション固有のアーティファクトを11gドメインで使用している場合には、この項の各トピックをよく確認して既存の設定に影響が出ないようにします。

- スタンドアロンOracle HTTP Serverのインストール
アップグレードの開始前に、Oracle HTTP Server 12c (12.2.1.2)ディストリビューションをターゲット・システムにダウンロードし、Oracle Universal Installerを使用してインストールします。

- サーバーとプロセスの停止
Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、すべてのプロセスと管理サーバーや管理対象サーバーを含めたすべてのサーバーを停止する必要があります。

- ドメイン・コンポーネント構成のアップグレード
ドメインの再構成後、更新したドメイン構成と一致するように、ドメイン内でUpgrade Assistantを使用してドメイン・コンポーネント構成をアップグレードします。

- サーバーとプロセスの起動
アップグレードが正常に完了したら、すべてのプロセスと管理サーバーや管理対象サーバーを含めたすべてのサーバーを再起動します。

- アップグレードの検証
ノード・マネージャとスタンドアロンOracle HTTP Serverが正常に起動できることを確認することで、アップグレードが成功していることを検証できます。

親トピック: Oracle HTTP Serverのアップグレード(11gから12c)

3.1 スタンドアロンOracle HTTP Serverのアップグレード・プロセス(11gから12c)について

Oracle HTTP Serverのアップグレード・プロセスの概要に関するフローチャートとロードマップを再確認します。

図3-1は、11gを開始ポイントとするスタンドアロンOracle HTTP Serverのアップグレードに関する手順の概要を示しています。各手順で使用するツールのリストも示します。

図3-1 スタンドアロンOracle HTTP Serverのアップグレード・プロセス・フローチャート(11gから12c)

次の表では、スタンドアロンOracle HTTP Server 11gを12cにアップグレードするために実行する必要があるタスクについて説明しています。

表3-1 スタンドアロンOracle HTTP Serverをアップグレードするためのタスク(11gから12c)

タスク

説明

必須

スタンドアロンOracle HTTP Serverをアップグレードしていることを確認します。

既存の環境にどの種類のOracle HTTP Serverが含まれるかを判断するには、Oracle HTTP Serverがスタンドアロンか管理対象(コロケート)かの判断を参照してください。

必須

アップグレード前のタスクを実行します。

アップグレード前タスクには、ご使用の本番環境のクローニング、システム要件および資格証明の確認、未使用データのパージおよび非SYSDBAユーザーの作成が含まれます。

アップグレード前タスクの完全なリストは、Oracle HTTP Serverのアップグレードの準備を参照してください。

さらに、次のタスクも完了します: 「アップグレード前の重要な考慮事項」。

必須

スタンドアロンOracle HTTP Serverをインストールします。

インストール・プログラムを実行してソフトウェアをインストールします。インストール・タイプスタンドアロンOracle HTTP Server (WebLogic Serverとは切り離して管理)を選択します。これによって、ソフトウェアをシステムに転送し、新しいOracleホーム・ディレクトリを作成します。

スタンドアロンOracle HTTP Serverのインストールを参照してください。

必須

11g環境を停止します。

「サーバーとプロセスの停止」を参照

必須

11gのスタンドアロン・システム・コンポーネント構成のアップグレード。

「ドメイン・コンポーネント構成のアップグレード」を参照してください。

必須

サーバーおよびプロセスを再起動します。

「サーバーとプロセスの起動」を参照してください。

必須

アップグレードを検証します。

Oracle HTTP Serverが予期したとおりの機能を続行しているはずです。アップグレード後の問題がある場合は、インストールのトラブルシューティングを実行してアップグレードを再試行する必要があります。

『Oracle Fusion Middleware Oracle HTTP Serverの管理』のOracle HTTP Serverのトラブルシューティングに関する項を参照してください。

3.2 アップグレード前の重要な考慮事項

アップグレードを開始する前に、アップグレード中またはその後に既存の設定が影響を受けないことを確認することが重要です。Oracle Web CacheまたはWebGateを使用しているか、アプリケーション固有のアーティファクトを11gドメインで使用している場合には、この項の各トピックをよく確認して既存の設定に影響が出ないようにします。

- Oracle Web Cache 11gユーザー
Oracle Web Cacheはセキュアなリバース・プロキシ・キャッシュであり、ブラウザとHTTPサーバーとの間、またはブラウザとContent Managementサーバーとの間にデプロイされる圧縮エンジンです。アクセス頻度の高いコンテンツをキャッシュすることで、Webサイトのパフォーマンスを向上します。オラクル社では、Web Cacheの最終バージョンを11gでリリースしました。Web Cacheは12cでは使用できません。

- WebGate 11gユーザー
WebGateはOracle Access Manager (OAM)のWebサーバー・プラグインで、HTTPリクエストを捕捉して、認証と認可を行うためにアクセス・サーバーに転送します。WebGateはOracle HTTP Server 12cインストールに含まれており、Upgrade AssistantによってOracle HTTP Serverアップグレード処理の一部としてアップグレードされます。

- WebGateのログ・ファイル名の更新
Oracle Fusion Middleware 12cでは、WebGateのログ・ファイル名がoblog.logからwebgate.logに変更されました。Oracle HTTP Serverの最新リリースへのアップグレード後に、oblog_config_wg.xmlファイルを手動で更新して、ファイル内に出現する「oblog.log」の各エントリを「webgate.log」に置き換える必要があります。

- 11gのアプリケーション・アーティファクト
アプリケーション・アーティファクトには、JSPファイル、イメージ、スタイルシート、Javascript、静的HTMLページに加えて、Javaのクラスおよびソース・ファイルやWebアプリケーションの構成ファイルなどのすべてのWebリソースが含まれます。統合開発環境(IDE)は、これらすべてのリソースを使用し、Webアプリケーション・アーティファクトとして参照します。

- 11gのアプリケーション・アーティファクトの移行
Oracleインスタンス内にあるすべての11gアプリケーション・アーティファクトを、HTMLまたはイメージ、CGIまたはFastCGIのスクリプトまたはアプリケーション、サード・パーティのモジュールなど、任意の組合せの静的ファイルを含めて手動で移行する必要があります。11g構成が参照していたアプリケーション・アーティファクトのうち、Oracleインスタンスの外部のディレクトリに保存されていたものは、Oracle HTTP Server 12cが使用する移行後の構成によって引き続き参照されます。

3.2.1 Oracle Web Cache 11gユーザー

Oracle Web Cacheはセキュアなリバース・プロキシ・キャッシュであり、ブラウザとHTTPサーバーとの間、またはブラウザとContent Managementサーバーとの間にデプロイされる圧縮エンジンです。アクセス頻度の高いコンテンツをキャッシュすることで、Webサイトのパフォーマンスを向上します。オラクル社では、Web Cacheの最終バージョンを11gでリリースしました。Web Cacheは12cでは使用できません。

11g環境でWeb Cacheを使用している場合は、次の制限事項を考慮してください。

- Web CacheはFusion Middleware 12cでは使用できません。このため、Web Cacheにはアップグレードはありません。

- Web Cache 11gを12c Oracle HTTP Serverのフロントエンドにする組合せは動作保証されません。

- 11gのセットアップでWeb CacheとOracle HTTP Serverの両方を使用している場合、Oracle HTTP Serverのみを12cにアップグレードできます。この場合、11g Web Cacheを無効にし、トラフィックがOracle HTTP Serverに直接向けられるように構成設定を変更する必要があります。

- 11gセットアップでWeb CacheとOracle HTTP Serverの両方を使用していて、それらをEnterprise Manager Fusion Middleware Controlで管理するためにOracle WebLogic Server (WLS)ドメインに関連付けている場合は、WLSドメインも12cにアップグレードする必要があります。この場合、関連付けられたOracle HTTP Serverも12cにアップグレードされます。ただし、Web Cacheは、12cのFusion Middleware Controlから削除されます。

3.2.2 WebGate 11gユーザー

WebGateはOracle Access Manager (OAM)のWebサーバー・プラグインで、HTTPリクエストを捕捉して、認証と認可を行うためにアクセス・サーバーに転送します。WebGateはOracle HTTP Server 12cインストールに含まれており、Upgrade AssistantによってOracle HTTP Serverアップグレード処理の一部としてアップグレードされます。

注意:
Oracle Fusion Middleware 12c (12.2.1.2)では、WebGateのログ・ファイル名がoblog.logからwebgate.logに変更されています。Oracle HTTP Serverの最新リリースへのアップグレード後に、oblog_config_wg.xmlファイルを手動で更新して、ファイル内に出現する「oblog.log」の各エントリを「webgate.log」に置き換える必要があります。このタスクを実行する手順は、WebGateのログ・ファイル名の更新を参照してください。

3.2.3 WebGateのログ・ファイル名の更新

Oracle Fusion Middleware 12cでは、WebGateのログ・ファイル名がoblog.logからwebgate.logに変更されています。Oracle HTTP Serverの最新リリースへのアップグレード後に、oblog_config_wg.xmlファイルを手動で更新して、ファイル内に出現する「oblog.log」の各エントリを「webgate.log」に置き換える必要があります。

WebGateのログ・ファイル名を更新する手順は次のとおりです。

1. 次のパスにディレクトリを変更します。
DOMAIN_HOME/config/fmwconfig/components/OHS/ohs_instance/webgate/config

2. oblog_config_wg.xmlファイルを編集モードで開きます。

3. すべての「oblog.log」を「webgate.log」に置換します。

3.2.4 11gのアプリケーション・アーティファクト

アプリケーション・アーティファクトには、JSPファイル、イメージ、スタイルシート、Javascript、静的HTMLページに加えて、Javaのクラスおよびソース・ファイルやWebアプリケーションの構成ファイルなどのすべてのWebリソースが含まれます。統合開発環境(IDE)は、これらすべてのリソースを使用し、Webアプリケーション・アーティファクトとして参照します。

11gのアプリケーション・アーティファクトがあり、12cでも引き続き使用する場合は、次をよく確認してください。

- 11g Oracleインスタンスから12cドメインへのOracle HTTP Serverアップグレードの一部として、Oracle HTTP Server構成ディレクトリのレイアウトが、Oracleインスタンスからスタンドアロン・ドメインに移行されます。

- Oracleインスタンスのコンポーネント構成ディレクトリにあるOracle HTTP Server 11gの構成ファイルは、自動的に移行されます。

- Oracleインスタンス内にあるアプリケーション・アーティファクトは、任意の組合せの静的ファイル(HTMLまたはイメージ、CGIまたはFastCGIのスクリプトまたはアプリケーション、サード・パーティのモジュールなど)を含めて、12cへのアップグレード後に手動で移行する必要があります
詳細は、「11gのアプリケーション・アーティファクトの移行」を参照してください。

3.2.5 11gのアプリケーション・アーティファクトの移行

Oracleインスタンス内にあるすべての11gアプリケーション・アーティファクトを、HTMLまたはイメージ、CGIまたはFastCGIのスクリプトまたはアプリケーション、サード・パーティのモジュールなど、任意の組合せの静的ファイルを含めて手動で移行する必要があります。11g構成が参照していたアプリケーション・アーティファクトのうち、Oracleインスタンスの外部のディレクトリに保存されていたものは、Oracle HTTP Server 12cが使用する移行後の構成によって引き続き参照されます。

たとえば、あるサード・パーティのプラグイン・モジュールがOracle HTTP Server 11gのOracleホームにインストールされており、次の例に示す構成を使用してOracleホームの場所から参照されていた場合は、このプラグイン・モジュールを12cのOracle HTTP ServerのOracleホームに手動でインストールするか、またはアップグレードした構成を変更して別の場所で参照する必要があります。

LoadModule example_module "ORACLE_HOME/ohs/modules/mod_example.so"

同様に、静的ファイルが11gのコンポーネント構成ディレクトリ内の/htdocsディレクトリにコピーされていた場合は、これらのファイルも12cインスタンスの構成ディレクトリに手動でコピーするか、またはアップグレードされた構成を修正して別の場所で参照する必要があります。他のタイプのアプリケーション・アーティファクトは、同様の手順で手動で移行する必要があります。

3.3 スタンドアロンOracle HTTP Serverのインストール

アップグレードの開始前に、Oracle HTTP Server 12c (12.2.1.2)ディストリビューションをターゲット・システムにダウンロードし、Oracle Universal Installerを使用してインストールします。

スタンドアロンOracle HTTP Serverをインストールする手順は次のとおりです。

1. 12c (12.2.1.2)製品のディストリビューションをインストールするターゲット・システムにログインします。

2. Oracle Technology NetworkまたはOracle Software Delivery Cloudから、ターゲット・システムに次をダウンロードします。

- Oracle HTTP Server (UNIX: fmw_12.2.1.2.0_ohs_linux64.bin)、(Windows: setup_fmw_12.2.1.2.0_ohs_win64.exe)

3. 12c (12.2.1.2)製品のディストリビューションをダウンロードしたディレクトリに移動します。

4. 使用するマシンが次の要件を満たしていることを確認します。

- システム、パッチ、カーネルおよびその他の要件が、「システム環境の検証ロードマップ」で指定されている要件を満たしていることを確認します。

- Oracle HTTP Serverはデフォルトではポート7777にインストールされるので、ノード上のどのサービスでもポート7777を使用していないことを確認する必要があります。このポートが使用されているかどうかを確認するには、Oracle HTTP Serverをインストールする前に次のコマンドを実行します。このポートが使用されている場合は、解放する必要があります。
netstat -an | grep 7777

5. 次のコマンドを入力して、インストール・プログラムを開始します。
(UNIX) ./fmw_12.2.1.2.0_ohs_linux64.bin

(Windows) setup_fmw_12.2.1.2.0_ohs_win64.exe

6. UNIXオペレーティング・システムでは、このホストにOracle製品を初めてインストールする場合に、「インストール・インベントリの設定」画面が表示されます。
中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システム・グループ名に中央インベントリの場所への書込み権限があることを確認し、「次へ」をクリックします。

注意:
「インストール・インベントリの設定」画面は、Windowsオペレーティング・システムでは表示されません。

7. 「ようこそ」画面で、情報をレビューしてすべての前提条件を満たしていることを確認します。「次へ」をクリックします。

8. 「自動更新」画面で、「自動更新をスキップ」を選択します。オプションは次のとおりです。

- この時点でソフトウェアの更新をシステムで確認しないようにする場合は、「自動更新をスキップ」を選択します。

- パッチ・ファイルをダウンロードした場合は、「ディレクトリからパッチを選択」を選択して、ローカル・ディレクトリに移動します。

- My Oracle Supportアカウントを持っている場合にソフトウェアの更新を自動でダウンロードするには、「My Oracle Supportで更新を検索」を選択します。Oracle Supportの資格証明を入力して、「検索」をクリックします。インストーラがMy Oracle Supportにアクセスするようにプロキシ・サーバーを構成するには、「プロキシ設定」をクリックします。「接続のテスト」をクリックして接続をテストします。

「次へ」をクリックします。

9. 「インストールの場所」画面でOracleホーム・ディレクトリの場所を指定して、「次へ」をクリックします。
ここでは、スタンドアロン・ドメインにOracle HTTP Serverの標準的なインストール・トポロジを使用してインストールを行っているため、Oracleホーム・ディレクトリを任意に指定できます。ただしこのソフトウェアを確実に、新規のOracleホームにインストールしてください。

Oracle Fusion Middlewareのディレクトリ構造の詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareのインストールのプランニング』のインストールおよび構成のためのディレクトリの選択に関する項を参照してください。

10. 「インストール・タイプ」画面で、「スタンドアロンHTTPサーバー(WebLogic Serverとは切り離して管理)」を選択し、「次へ」をクリックします。

11. 「前提条件チェック」画面で、ホスト・コンピュータを分析して、特定のオペレーティング・システムの前提条件を満たしているか確認します。
確認されたタスクのリストを表示するには、「正常なタスクの表示」を選択します。ログの詳細を表示するには、「ログの表示」を選択します。前提条件のチェックが失敗すると、エラー・メッセージが画面の下方に表示されます。エラーを修正し、「再実行」をクリックして再試行します。エラー・メッセージや警告メッセージを無視してインストールを続けるには、「スキップ」をクリックします(非推奨)。

12. Oracle Supportアカウントを持っている場合は、「セキュリティ更新」画面で、セキュリティ更新を受け取る方法を指定します。
Oracle Supportアカウントを所持しておらずこの手順を省略してもかまわない場合は、チェック・ボックスの選択を解除して、後続のダイアログ・ボックスで選択内容を確認します。

13. 「インストール・サマリー」画面で、選択したインストール・オプションを確認します。
これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を入力します。レスポンス・ファイルには、入力したすべての情報が収集して格納され、後で(コマンドラインから)サイレント・インストールを実行するために使用できます。
「インストール」をクリックしてインストールを開始します。

14. 「インストールの進行状況」画面で、プログレス・バーが100%完了になったら、「終了」をクリックしてインストーラを閉じるか、「次へ」をクリックしてサマリーを表示します。

15. 「インストール完了」画面に、インストールの場所と、インストールされた機能セットが表示されます。情報を確認し、「終了」をクリックしてインストーラを閉じます。

これで、Oracle HTTP Serverのスタンドアロン・モードでのインストールが完了しました。

3.4 サーバーとプロセスの停止

Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、すべてのプロセスと管理サーバーや管理対象サーバーを含めたすべてのサーバーを停止する必要があります。

Oracle Fusion Middleware環境は、1つのOracle WebLogic Serverドメイン、1つの管理サーバー、複数の管理対象サーバー、Javaコンポーネント、システム・コンポーネント(Identity Managementのコンポーネントなど)およびメタデータのリポジトリとして使用する1つのデータベースで構成できます。コンポーネントは相互に依存していることがあるため、適切な順序で停止する必要があります。

注意:
この項の手順では、WLSTコマンドライン・ユーティリティまたはスクリプトを使用してサーバーとプロセスを停止する方法について説明します。また、Oracle Fusion Middleware ControlとOracle WebLogic Server管理コンソールを使用することもできます。『Oracle Fusion Middleware Oracle Fusion Middlewareの管理』の管理サーバー、管理対象サーバーおよびノード・マネージャの起動および停止に関する項を参照してください。

Fusion Middleware環境を停止するには、次に示す手順を実行します。

ステップ1: システム・コンポーネントを停止する

Oracle HTTP Serverなどのシステム・コンポーネントを停止するには、stopComponentスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

システム・コンポーネントは任意の順序で停止できます。

ステップ2: 管理対象サーバーを停止する

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

- (UNIX) DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url

- (Windows) DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url

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

ステップ3: Oracle Identity Managementのコンポーネントを停止するOracle Internet Directoryなど、Oracle Identity Managementコンポーネントを停止します。

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

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

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

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

- (UNIX) DOMAIN_HOME/bin/stopWebLogic.sh

- (Windows) DOMAIN_HOME\bin\stopWebLogic.cmd

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

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

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

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

3.5 ドメイン・コンポーネント構成のアップグレード

ドメインの再構成後、更新したドメイン構成と一致するように、ドメイン内でUpgrade Assistantを使用してドメイン・コンポーネント構成をアップグレードします。

- Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade Assistantは非SYSDBAとして実行して、一度にアップグレードするドメインは1つにすることをお薦めします。

- Upgrade Assistantを使用した11gドメイン・コンポーネントのアップグレード
Upgrade Assistantの各画面を通じて、WebLogicドメインのコンポーネント構成をアップグレードします。

- ドメイン固有コンポーネント構成のアップグレードの確認
ドメイン固有コンポーネント構成のアップグレードが成功したことを確認するには、管理コンソールおよびFusion Middleware Controlにログインし、各コンポーネントのバージョン番号が12.2.1.2であることを確認します。

3.5.1 Upgrade Assistantの起動

Upgrade Assistantを実行して、製品のスキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade Assistantは非SYSDBAとして実行して、一度にアップグレードするドメインは1つにすることをお薦めします。

Upgrade Assistantを起動するには、次の手順に従います。

1. oracle_common/upgrade/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. Upgrade Assistantを起動します。

- (UNIX) ./ua

- (Windows) ua.bat

コマンドラインに指定可能なその他のパラメータ(ロギングのパラメータなど)の詳細は、次を参照してください。

- Upgrade Assistantパラメータ

3.5.1.1 Upgrade Assistantパラメータ

コマンドラインからUpgrade Assistantを起動する際に、追加のパラメータを指定できます。

表3-2 Upgrade Assistantコマンドライン・パラメータ

パラメータ

必須/省略可能

説明

-readiness

準備状況チェックの場合は必須
注意: スタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では準備状況チェックを実行できません。

アップグレードの準備状況チェックを実行します(実際のアップグレードは実行しません)。

スキーマと構成がチェックされます。

-examineパラメータを指定した場合は、このパラメータを指定しないでください。

-threads

省略可能

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を特定します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須

レスポンス・ファイルに保存した入力を使用して、Upgrade Assistantを実行します。このレスポンス・ファイルは、GUIモードでUpgrade Assistantを実行したときの入力データから生成されます。このパラメータを使用すると、Upgrade Assistantがサイレント・モードで(Upgrade Assistant画面を表示せずに)実行されます。

-examine

省略可能

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel attribute

省略可能

次のいずれかの属性を指定して、ログイン・レベルを設定します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

デフォルトのロギング・レベルはNOTIFICATIONです。

-logLevel TRACE属性を設定して、より多くのログが記録されるようにすることを検討してください。これは、アップグレードの失敗をトラブルシューティングする際に役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir location

省略可能

アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。既存の書込み可能なディレクトリを指定する必要があります。Upgrade Assistantは、このディレクトリにログ・ファイルと一時ファイルを作成します。

デフォルトの場所は次のとおりです。

UNIXの場合:

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

Windowsの場合:

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

省略可能

すべてのコマンドライン・オプションを表示します。

3.5.2 Upgrade Assistantを使用した11gドメイン・コンポーネントのアップグレード

Upgrade Assistantの各画面を通じて、WebLogicドメインのコンポーネント構成をアップグレードします。

Upgrade Assistantを使用して11gドメインをアップグレードする手順は次のとおりです。

1. 「ようこそ」画面には、Upgrade Assistantの概要と、アップグレード前のいくつかの重要なタスクについての情報が示されます。「次へ」をクリックします。

注意:
Upgrade Assistantの画面の詳細は、画面上の「ヘルプ」をクリックしてください。

2. 「ドメイン・ディレクトリ」画面で、「新規ドメインの作成(11gからのアップグレード時に選択)」を選択します。

3. 「スタンドアロン・コンポーネント」画面で、「スタンドアロン・システム・コンポーネント構成」を選択します。
「新規ドメインの作成」を選択し、「次へ」をクリックします。

注意:

- 「新規ドメインの作成」オプションは、バージョン11gからアップグレードする場合にのみ使用してください。

- アップグレードした11gシステム・コンポーネント用に新しい12cスタンドアロン・ドメインをすでに作成している場合、「既存のドメインの更新」オプションを使用して、スタンドアロンOracle HTTP Serverを備えたスタンドアロン・ドメインを拡張できます。

- 「既存のドメインの更新」オプションは、以前の12cリリース(12.1.2.0、12.1.3.0、12.2.1.0および12.2.1.1)から最新の12cリリース(12.2.1.2)にアップグレードする場合にのみ使用します。

4. 「コンポーネント・リスト」画面で、構成をアップグレードするコンポーネントがリストにすべて含まれていることを確認し、「次」をクリックします。
アップグレードするコンポーネントがリストに含まれていない場合は、「戻る」をクリックして前の画面に戻り、別のドメインを指定します。

5. 「前提条件」画面で、すべてのチェック・ボックスを選択して、前提条件を満たしていることを確認します。「次へ」をクリックします。

注意:
Upgrade Assistantでは、前提条件が満たされているかどうかの確認は行われません。

6. 「インスタンス・ディレクトリ」画面で「11gソース」を選択して、アップグレードする11gインスタンスのディレクトリの場所を指定します。
このインスタンスは、12c Oracle HTTP Serverインスタンスを構成するためのベースとして使用されます。11g Oracle HTTP Serverのインストールは変更されません。

必要に応じて、+をクリックして11gインスタンス・ディレクトリを追加します。「次へ」をクリックします。

注意:
Upgrade Assistantを使用してOracle 10gインスタンスをOracle 12cにアップグレードすることはできません。最初にOracle 10gインスタンスを11gにアップグレードする必要があります。10gから11gへの移行方法の詳細は、使用しているコンポーネントの11gのアップグレード・ドキュメントを参照してください。

7. 「ノード・マネージャ」画面で、次のフィールドを指定して、スタンドアロン・ドメインを管理するための新しいノード・マネージャを作成します。

表3-3 「ノード・マネージャ」画面のフィールドの説明

オプション

説明

ユーザー名

ノード・マネージャへのアクセスに使用するユーザー名を指定します。

パスワード

ノード・マネージャへのアクセスに使用するパスワードを指定します。確認用にパスワードを再入力します。

リスニング・アドレス

ノード・マネージャがリスニングするDNS名またはIPアドレスを入力します。

リスニング・ポート

ノード・マネージャのリスニング・ポート番号を入力します。

注意:
ユーザー名とパスワードは、ノード・マネージャとクライアントの間の接続の認証にのみ使用されます。これらは、サーバー管理者の資格証明とは別のものです。

8. 「調査」画面で、各スタンドアロン・コンポーネントを調査したUpgrade Assistantのステータスを確認して、スタンドアロン・コンポーネントのアップグレードの準備が整っていることを検証します。ステータスが「調査が終了しました。」になっている場合は、「次」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認します。一般的なアップグレード・エラーの解決方法の詳細は、Oracle Fusion Middleware Upgrade Assistantによるアップグレードのアップグレード・ガイドのアップグレードのトラブルシューティングに関する項を参照してください。

注意:

- 確認フェーズ中に検出された問題を、アップグレードを進めずに解決した場合は、バックアップからリストアを再び行わずにUpgrade Assistantを開始できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックしてアップグレードを続行していた場合は、Upgrade Assistantを再開する前に、バックアップからアップグレード前の環境をリストアする必要があります。

- 調査プロセスを取り消しても構成データに影響はありませんが、将来のアップグレード・セッションでは、Upgrade Assistantが収集した情報の再収集が必要になります。

9. 「アップグレード・サマリー」画面で、コンポーネント構成のアップグレードに選択したオプションのサマリーを確認します。
レスポンス・ファイルには、入力したすべての情報が収集および格納されます。このファイルにより、その後のサイレント・アップグレードの実行が可能になります。サイレント・アップグレードは、Upgrade Assistantとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。
「アップグレード」をクリックして、アップグレード・プロセスを開始します。

10. 「アップグレードの進行状況」画面で、アップグレードのステータスを監視します。

注意:
アップグレード・アシスタントにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。これを行うと、環境が不安定になる可能性があります。

正しくアップグレードされていないコンポーネントがある場合は、Upgrade Assistantのログ・ファイルで情報を確認します。

注意:
この画面のプログレス・バーには、現在のアップグレード手順の進行状況が表示されます。アップグレードの残り時間を示すものではありません。

「次へ」をクリックします。

11. アップグレードが成功した場合: 「アップグレード成功」画面で、「閉じる」をクリックし、アップグレードを完了してウィザードを閉じます。新規インストールでコンポーネントを機能させるために手動で実行する必要のあるタスクが、アップグレード後のアクションのウィンドウに表示されます。このウィンドウは、コンポーネントにアップグレード後の手順がある場合にのみ表示されます。

アップグレードが失敗した場合: 「アップグレード失敗」画面で、「ログの表示」をクリックし、エラーを表示してトラブルシューティングします。ログは、ORACLE_HOME/oracle_common/upgrade/logsにあります。アップグレードが失敗した場合は、アップグレード前の環境をバックアップからリストアし、問題を修正してから、Upgrade Assistantを再起動する必要があります。

3.5.3 ドメイン固有コンポーネント構成のアップグレードの確認

ドメイン固有コンポーネント構成のアップグレードが成功したことを確認するには、管理コンソールおよびFusion Middleware Controlにログインし、各コンポーネントのバージョン番号が12.2.1.2になっていることを確認します。

管理コンソールにログインするには、次に移動します: http://administration_server_host:administration_server_port/console

Fusion Middleware Controlにログインするには、次に移動します: http://administration_server_host:administration_server_port/em

注意:

アップグレード後、管理ツールは、前のOracleホームではなく新しい12cのOracleホームから必ず実行してください。

アップグレード・プロセス時に、一部のOWSMドキュメント(ポリシー・セット、ポリシーおよびアサーション・テンプレートなどの事前定義ドキュメント)のアップグレードが必要な場合があります。ポリシー・セットまたは事前定義ドキュメントがアップグレードされると、バージョン番号が1増分されます。

3.6 サーバーとプロセスの起動

アップグレードが正常に完了したら、すべてのプロセスと管理サーバーや管理対象サーバーを含めたすべてのサーバーを再起動します。

コンポーネントは相互に依存していることがあるため、適切な順序で起動する必要があります。

注意:
この項の手順では、WLSTコマンドラインまたはスクリプトを使用してサーバーとプロセスを起動する方法について説明します。また、Oracle Fusion Middleware ControlとOracle WebLogic Server管理コンソールを使用することもできます。『Oracle Fusion Middlewareの管理』の管理サーバーと管理対象サーバーおよびノード・マネージャの起動と停止に関する項を参照してください。

Fusion Middleware環境を起動するには、次に示す手順を実行します。

ステップ1: 管理サーバーの起動

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

管理サーバーを起動するには、startWebLogicスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/startWebLogic.sh

- (Windows) DOMAIN_HOME\bin\startWebLogic.cmd

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

ステップ2: ノード・マネージャを起動する

ノード・マネージャを起動するには、startNodeManagerスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/startNodeManager.sh

- (Windows) DOMAIN_HOME\bin\startNodeManager.cmd

ステップ3: Oracle Identity Managementのコンポーネントを起動する目的の環境に含まれるOracle Identity Managementのコンポーネント(Oracle Internet Directoryなど)を起動します。

- (UNIX) DOMAIN_HOME/bin/startComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\startComponent.cmd component_name

ステップ4: 管理対象サーバーを起動する

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

- (UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

- (Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url

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

注意:
通常、管理対象サーバーを起動すると、そのサーバーにデプロイされているアプリケーションが開始されます。したがって、管理対象サーバーの起動後にアプリケーションを手動で開始する必要はありません。

ステップ5: システム・コンポーネントを起動する

Oracle HTTP Serverなどのシステム・コンポーネントを起動するには、startComponentスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/startComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\startComponent.cmd component_name

システム・コンポーネントは任意の順序で起動できます。

- スタンドアロンOracle HTTP Serverの起動
アップグレード後に、スタンドアロンOracle HTTP Serverを起動します。

3.6.1 スタンドアロンOracle HTTP Serverの起動

アップグレード後に、スタンドアロンOracle HTTP Serverを起動します。

スタンドアロンOracle HTTP Serverを起動する手順は次のとおりです。

1. oracle_common/upgrade/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. スタンドアロンのサーバーを起動するコマンドを入力します。
UNIXオペレーティング・システムの場合: e

./startComponent.sh ohs_name

Windowsオペレーティング・システムの場合:

startComponent.cmd ohs_name

詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareの管理』のシステム・コンポーネントの起動と停止に関する項を参照してください。

3.7 アップグレードの確認

ノード・マネージャおよびスタンドアロンOracle HTTP Serverを正しく起動できれば、アップグレードが成功したことを確認できます。

アップグレード後の問題が発生した場合は、インストールのトラブルシューティングを実行してアップグレードを再試行する必要があります。詳細は、Oracle HTTP Server管理者ガイドのOracle HTTP Serverのトラブルシューティングを参照してください。

新しくアップグレードした環境を起動できない場合は、OracleウォレットでMD5証明書を使用していることが原因になっている可能性があります。MD5署名を使用しているかどうかのチェックの手順およびSHA-2証明書に置き換える手順については、「SHA-2アルゴリズムを使用して署名された証明書でMD5アルゴリズムを使用して署名された証明書を置き換え」を参照してください。

4 管理対象Oracle HTTP Serverのアップグレード(11gから12c)

この章では、管理対象Oracle HTTP Serverを11gから12cにアップグレードするための手順について説明します。このアップグレードの有効な開始ポイントは、11gのリリース11.1.1.7以降です。

- 管理対象Oracle HTTP Serverのアップグレード・プロセス(11gから12c)について
管理対象Oracle HTTP Serverのアップグレード・プロセスの概要に関するフローチャートとロードマップを再確認します。

- 製品ディストリビューションのインストール
アップグレードの開始前に、Oracle Fusion MiddlewareインフラストラクチャとOracle HTTP Server 12c (12.2.1.2)のディストリビューションをターゲット・システムにダウンロードし、Oracle Universal Installerを使用してインストールします。

- アップグレード前の準備状況チェックの実行
アップグレードにかかわる潜在的な問題を特定するために、アップグレード・プロセスの開始前に、準備状況チェックの実行をお薦めします。準備状況チェックによって、アップグレードにかかわる潜在的な問題をすべて検出できるわけではない点に注意してください。準備状況チェックのレポートが成功を示していても、アップグレードが失敗することもあります。

- サーバーとプロセスの停止
Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、すべてのプロセスと管理サーバーや管理対象サーバーを含めたすべてのサーバーを停止する必要があります。

- RCUを使用した必要な12cスキーマの作成
11gからアップグレードする場合は、アップグレードの開始前に、リポジトリ作成ユーティリティ(RCU)を使用して必須の12cスキーマを作成する必要があります。

- ドメインの再構成
再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.2)にあわせて再構成します。

- ドメイン・コンポーネント構成のアップグレード
ドメインの再構成後、更新したドメイン構成と一致するように、ドメイン内でUpgrade Assistantを使用してドメイン・コンポーネント構成をアップグレードします。

- サーバーとプロセスの起動
アップグレードが正常に完了したら、すべてのプロセスと管理サーバーや管理対象サーバーを含めたすべてのサーバーを再起動します。

- アップグレードの確認
管理コンソールとEnterprise Manager Fusion Middleware Controlにログインできれば、アップグレードは正常に完了しています。

- WLSTを使用したアップグレード後のウォレットのKSSデータベースへのインポート
Upgrade Assistantを使用して以前のバージョンのOracle HTTP Serverから12c (12.2.1.2)にアップグレードする場合は、追加のウォレット管理タスクを実行する必要があります。

親トピック: Oracle HTTP Serverのアップグレード(11gから12c)

4.1 管理対象Oracle HTTP Serverのアップグレード・プロセス(11gから12c)について

管理対象Oracle HTTP Serverのアップグレード・プロセスの概要に関するフローチャートとロードマップを再確認します。

図4-1は、最新の12cリリースに管理対象Oracle HTTP Serverをアップグレードする場合のプロセス・フローを示しています。各手順で使用するツールのリストも示します。

図4-1 管理対象Oracle HTTP Serverのアップグレード・プロセス・フローチャート(11gから12c)

表6-1では、11gリリースから12c (12.2.1.2)に管理対象Oracle HTTP Serverをアップグレードする際に実行する必要があるタスクについて説明します。

表4-1 管理対象Oracle HTTP Serverをアップグレードするためのタスク(11gから12c)

タスク

説明

必須

管理対象Oracle HTTP Serverをアップグレードしていることを確認します。

既存の環境にどの種類のOracle HTTP Serverが含まれるかを判断するには、Oracle HTTP Serverがスタンドアロンか管理対象(コロケート)かの判断を参照してください。

必須

このガイドの概要に関するトピックを再確認して、アップグレード前のタスクを完了します(まだ実行していない場合)。

アップグレード前タスクには、ご使用の本番環境のクローニング、システム要件および資格証明の確認、未使用データのパージおよび非SYSDBAユーザーの作成が含まれます。

アップグレード前タスクの完全なリストは、Oracle HTTP Serverのアップグレードの準備を参照してください。

必須

12.2.1.2 Fusion MiddlewareインフラストラクチャとOracle HTTP Serverのディストリビューションをダウンロードしてインストールします。

インフラストラクチャのディストリビューションには、その他のFusion Middleware製品をインストールするための基盤の設定に必要な、WebLogic ServerおよびJava Required Files (JRF)が同梱されています。

このガイドのアップグレード・トポロジに定義されているように、インフラストラクチャは新規のOracleホームにインストールする必要があります。

Oracle HTTP Serverは、12.2.1.2インフラストラクチャのインストール時に作成したOracleホームにインストールする必要があります。

「製品ディストリビューションのインストール」を参照してください。

オプション

準備状況チェックを実行します。

「アップグレード前の準備状況チェックの実行」を参照してください。

必須

11gインスタンスを停止します。

アップグレード・プロセスの開始前に、管理サーバー、管理対象サーバー、および11gインスタンスを停止します。

「サーバーとプロセスの停止」を参照

必須

必要な12cスキーマを作成します。

「RCUを使用した必要な12cスキーマの作成」を参照してください。

必須

再構成ウィザードを使用して、既存の12cドメインを再構成します。

再構成ウィザードを12c Oracle HTTP Serverインストールから実行して、既存のドメインを再構成します。

「ドメインの再構成」を参照してください。

必須

Upgrade Assistantを使用して、既存の12cドメイン構成をアップグレードします。

インストール後、Upgrade Assistantを使用してOracle HTTP Serverおよびシステム・コンポーネント・インフラストラクチャをアップグレードする必要があります。

「ドメイン・コンポーネント構成のアップグレード」を参照してください。

必須

サーバーおよびプロセスを再起動します。

アップグレード・プロセスは完了です。これで、管理サーバー、管理対象サーバーおよび12.2.1.2インスタンスを再起動できます。

「サーバーとプロセスの起動」を参照してください。

必須

アップグレードを検証します。

アップグレードの検証方法は、「アップグレードの確認」を参照してください。

次のアップグレード後のタスクを完了します: 「WLSTを使用したアップグレード後のウォレットのKSSデータベースへのインポート」。

4.2 製品ディストリビューションのインストール

アップグレードの開始前に、Oracle Fusion MiddlewareインフラストラクチャとOracle HTTP Server 12c (12.2.1.2)のディストリビューションをターゲット・システムにダウンロードし、Oracle Universal Installerを使用してインストールします。

注意:
Oracle Fusion Middlewareインフラストラクチャは、その他のFusion Middleware製品より前にインストールする必要があります(アップグレードにインフラストラクチャが必要な場合)。

12c (12.2.1.2)のディストリビューションをインストールするには:

1. 12c (12.2.1.2)製品のディストリビューションをインストールするターゲット・システムにログインします。

2. Oracle Technology NetworkまたはOracle Software Delivery Cloudから、ターゲット・システムに次をダウンロードします。

- Oracle Fusion Middlewareインフラストラクチャ (fmw_12.2.1.2.0_infrastructure_generic.jar)

- Oracle HTTP Server (UNIX: fmw_12.2.1.2.0_ohs_linux64.bin)、(Windows: setup_fmw_12.2.1.2.0_ohs_win64.exe)

3. 使用するマシンが次の要件を満たしていることを確認します。

- システム、パッチ、カーネルおよびその他の要件が、Oracle HTTP Serverのインストールと構成に指定された内容を満たしていることを確認します。

- Oracle HTTP Serverはデフォルトではポート7777にインストールされるので、ノード上のどのサービスでもポート7777を使用していないことを確認する必要があります。このポートが使用されているかどうかを確認するには、Oracle HTTP Serverをインストールする前に次のコマンドを実行します。このポートが使用されている場合は、解放する必要があります。
netstat -an | grep 7777

4. UNIXプラットフォームで、/etc/oraInst.locファイルが存在する場合はその内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。
/etc/oraInst.locファイルが存在しない場合は、この手順をスキップできます。

5. 12c (12.2.1.2)製品のディストリビューションをダウンロードしたディレクトリに移動します。

6. Oracle Fusion Middlewareインフラストラクチャのインストール・プログラムを開始します。

- (UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

- (Windows) JDK_HOME\bin\java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

7. UNIXオペレーティング・システムでは、このホストにOracle製品を初めてインストールする場合に、「インストール・インベントリの設定」画面が表示されます。
中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システム・グループ名に対して中央インベントリの場所への書込み権限が付与されていることを確認し、「次へ」をクリックします。

注意:
「インストール・インベントリの設定」画面は、Windowsオペレーティング・システムでは表示されません。

8. 「ようこそ」画面で、情報をレビューしてすべての前提条件を満たしていることを確認します。「次へ」をクリックします。

9. 「自動更新」画面で、「自動更新をスキップ」を選択します。オプションは次のとおりです。

- この時点でソフトウェアの更新をシステムで確認しないようにする場合は、「自動更新をスキップ」を選択します。

- パッチ・ファイルをダウンロードした場合は、「ディレクトリからパッチを選択」を選択して、ローカル・ディレクトリに移動します。

- My Oracle Supportアカウントを持っている場合にソフトウェアの更新を自動でダウンロードするには、「My Oracle Supportで更新を検索」を選択します。Oracle Supportの資格証明を入力して、「検索」をクリックします。インストーラがMy Oracle Supportにアクセスするようにプロキシ・サーバーを構成するには、「プロキシ設定」をクリックします。「接続のテスト」をクリックして接続をテストします。

「次へ」をクリックします。

10. 「インストールの場所」画面でOracleホーム・ディレクトリの場所を指定して、「次へ」をクリックします。
ここでは、WebLogic Serverドメインに同じ場所に配置(コロケート)されたOracle HTTP Serverの標準的なインストール・トポロジをインストールしているため、既存のOracle Fusion Middleware InfrastructureのOracleホームへのパスを入力します。

Oracle Fusion Middlewareのディレクトリ構造の詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareのインストールのプランニング』のインストールおよび構成のためのディレクトリの選択に関する項を参照してください。

11. 「インストール・タイプ」画面で、次に示す項目を選択します。

- インフラストラクチャの場合は、「Fusion Middlewareインフラストラクチャ」を選択します。

- Oracle HTTP Serverの場合は、「同じ場所に配置されたHTTPサーバー(WebLogic Server経由で管理)」を選択します。

「次へ」をクリックします。

12. 「前提条件チェック」画面では、ホスト・コンピュータを分析して、特定のオペレーティング・システムの前提条件を満たしているか確認します。
確認されたタスクのリストを表示するには、「正常なタスクの表示」を選択します。ログの詳細を表示するには、「ログの表示」を選択します。前提条件のチェックが失敗すると、エラー・メッセージが画面の下方に表示されます。エラーを修正し、「再実行」をクリックして再試行します。エラー・メッセージや警告メッセージを無視してインストールを続けるには、「スキップ」をクリックします(非推奨)。

13. 「インストール・サマリー」画面で、選択したインストール・オプションを確認します。
これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を入力します。レスポンス・ファイルには、入力したすべての情報が収集して格納され、後で(コマンドラインから)サイレント・インストールを実行するために使用できます。
「インストール」をクリックしてインストールを開始します。

14. 「インストールの進行状況」画面で、プログレス・バーが100%完了になったら、「終了」をクリックしてインストーラを閉じるか、「次へ」をクリックしてサマリーを表示します。

15. 「インストール完了」画面に、インストールの場所とインストールされた機能セットが表示されます。情報を確認し、「終了」をクリックしてインストーラを閉じます。

16. Oracle Fusion Middlewareインフラストラクチャのインストール後、次に示すコマンドを入力して、製品ディストリビューションのインストーラを起動し、インストーラの各画面を通じて前述の手順を繰り返します。
(UNIX) ./fmw_12.2.1.2.0_ohs_linux64.bin

(Windows) setup_fmw_12.2.1.2.0_ohs_win64.exe

これで、Oracle HTTP Serverのコロケート・モードでのインストールが完了しました。

4.3 アップグレード前の準備状況チェックの実行

アップグレードにかかわる潜在的な問題を特定するために、アップグレード・プロセスの開始前に、準備状況チェックの実行をお薦めします。準備状況チェックによって、アップグレードにかかわる潜在的な問題をすべて検出できるわけではない点に注意してください。準備状況チェックのレポートが成功を示していても、アップグレードが失敗することもあります。

- Upgrade Assistantを使用したアップグレード前準備状況チェックの実行について
Upgrade Assistantを-readinessモードで実行することで、実際のアップグレードを実行する前に問題を検出できます。Upgrade Assistantを使用すると、準備状況チェックはGUIモードで実行できます。また、レスポンス・ファイルを使用するとサイレント・モードで実行できます。

- 準備状況モードでのUpgrade Assistantの起動
-readinessパラメータを使用して、Upgrade Assistantを準備状況モードで起動します。

- Upgrade Assistantを使用した準備状況チェックの実行
Upgrade Assistantの各画面を通じて、アップグレード前の準備状況チェックを完了します。

- 準備状況レポートの理解
ドメインの準備状況チェックを実行後、レポートを確認して、正常にアップグレードするために何かアクションを実行する必要があるかどうかを判断します。

4.3.1 アップグレード前の準備状況チェックの実行について

Upgrade Assistantを-readinessモードで実行することで、実際のアップグレードを実行する前に問題を検出できます。Upgrade Assistantを使用すると、準備状況チェックはGUIモードで実行できます。また、レスポンス・ファイルを使用するとサイレント・モードで実行できます。

Upgrade Assistantの準備状況チェックは、サポート対象の開始ポイントにあるFusion MiddlewareのスキーマとWebLogicドメインの構成について、読取り専用のアップグレード前確認を実行します。この確認は、読取り専用の操作です。

準備状況チェックでは、フォーマットされ、タイムスタンプの付けられた準備状況レポートが生成され、実際のアップグレードを試みる前に潜在的な問題に対処できます。問題が検出されない場合は、アップグレード・プロセスを開始できます。アップグレードを実行する前に、このレポートを詳細に確認することをお薦めします。

準備状況チェックは、既存のOracle Fusion Middlewareドメインがオンライン(他のユーザーがアクティブに使用している間)またはオフラインである間に実行できます。

準備状況チェックは、実際のアップグレードの実行前に、何度でも実行できます。ただし、アップグレードの実行後には、準備状況チェックを実行しないでください。これは、レポート結果が、アップグレード前の準備状況チェックと異なることがあるためです。

注意:

パフォーマンスへの影響を避けるため、準備状況チェックはピーク時以外に実行するようにしてください。

4.3.2 準備状況モードでのUpgrade Assistantの起動

-readinessパラメータを使用して、Upgrade Assistantを準備状況モードで起動します。

Upgrade Assistantを使用して、アップグレード前の環境に対する準備状況チェックを実行するには:

1. oracle_common/upgrade/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. Upgrade Assistantを起動します。

- (UNIX) ./ua -readiness

- (Windows) ua.bat -readiness

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

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

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

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

その他のコマンドラインに指定可能なパラメータの詳細は、次の項を参照してください。

- Upgrade Assistantパラメータ

4.3.2.1 Upgrade Assistantパラメータ

コマンドラインからUpgrade Assistantを起動する際に、追加のパラメータを指定できます。

表4-2 Upgrade Assistantコマンドライン・パラメータ

パラメータ

必須/省略可能

説明

-readiness

準備状況チェックの場合は必須
注意: スタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では準備状況チェックを実行できません。

アップグレードの準備状況チェックを実行します(実際のアップグレードは実行しません)。

スキーマと構成がチェックされます。

-examineパラメータを指定した場合は、このパラメータを指定しないでください。

-threads

省略可能

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を特定します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須

レスポンス・ファイルに保存した入力を使用して、Upgrade Assistantを実行します。このレスポンス・ファイルは、GUIモードでUpgrade Assistantを実行したときの入力データから生成されます。このパラメータを使用すると、Upgrade Assistantがサイレント・モードで(Upgrade Assistant画面を表示せずに)実行されます。

-examine

省略可能

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel attribute

省略可能

次のいずれかの属性を指定して、ログイン・レベルを設定します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

デフォルトのロギング・レベルはNOTIFICATIONです。

-logLevel TRACE属性を設定して、より多くのログが記録されるようにすることを検討してください。これは、アップグレードの失敗をトラブルシューティングする際に役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir location

省略可能

アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。既存の書込み可能なディレクトリを指定する必要があります。Upgrade Assistantは、このディレクトリにログ・ファイルと一時ファイルを作成します。

デフォルトの場所は次のとおりです。

UNIXの場合:

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

Windowsの場合:

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

省略可能

すべてのコマンドライン・オプションを表示します。

4.3.3 Upgrade Assistantを使用した準備状況チェックの実行

Upgrade Assistantの各画面を通じて、アップグレード前の準備状況チェックを完了します。

準備状況チェックは、サポートされるアップグレードの開始点にあるスキーマまたはコンポーネント構成に対してのみ実行されます。

準備状況チェックを完了するには:

1. 「ようこそ」画面で、準備状況チェックに関する情報を確認します。「次へ」をクリックします。

2. 「準備状況チェック・タイプ」画面で、実行する準備状況チェックを選択します。

- 「個別に選択されたスキーマ」: アップグレード前に確認するスキーマを個別に選択できます。準備状況チェックは、スキーマがアップグレードに対応しているかどうか、またはアップグレードが必要かどうかをレポートします。
このオプションを選択すると、画面名が「選択したスキーマ」に変更されます。

- 「ドメイン・ベース」: Upgrade Assistantは、「ドメイン・ディレクトリ」フィールドで指定されたドメイン内で、アップグレード可能なスキーマまたはコンポーネントのすべてを検出して選択するようになります。
このオプションを選択すると、画面名が「スキーマおよび構成」に変更されます。

Upgrade Assistantですべてのスキーマとコンポーネント構成をチェックする場合は、デフォルトの選択を変更しないで使用します。それ以外の場合は、次に示す特定のオプションを選択します。

- 「すべてのスキーマのチェックを含める」: アップグレードに対応したコンポーネントをすべて検出して確認します。

- 「すべての構成のチェックを含める」: 管理対象WebLogic Serverドメインのコンポーネント構成を確認します。

「次へ」をクリックします。

3. 「個別に選択されたスキーマ」を選択した場合: 「使用可能なコンポーネント」画面で、アップグレードに対応可能なスキーマを持つコンポーネントを選択して、準備状況チェックの実行対象にします。

依存コンポーネントのあるコンポーネントを選択すると、該当するコンポーネントが自動的に選択されます。たとえば、Oracle Platform Security Servicesを選択すると、Oracle Audit Servicesが自動的に選択されます。

選択したコンポーネントによっては、追加の画面が表示されることがあります。たとえば、次のような作業が必要になることがあります。

- ドメイン・ディレクトリを指定します。

- 選択したスキーマに接続するために、次のスキーマ資格証明を指定します: 「データベース・タイプ」、「DBAユーザー名」および「DBAパスワード」。次に、「接続」をクリックします。

注意:
Oracleデータベースは、デフォルトのデータベース・タイプです。データベース・タイプに間違いがないことを確認してから続行してください。間違ったデータベースを選択していることに気付いた場合でも、正しいタイプに変更するために、この画面に戻らないでください。そのかわりに、Upgrade Assistantを終了してから、正しいデータベース・タイプを選択した状態で準備状況チェックを再開し、すべてのスキーマに正しいデータベース・タイプが適用されるようにします。

- 「スキーマ・ユーザー名」を選択して、「スキーマ・パスワード」を指定します。

「次」をクリックして、準備状況チェックを開始します。

4. 「準備状況サマリー」画面で、選択内容に応じて実行される準備状況チェックのサマリーを確認します。
選択内容を保存して、今後、レスポンス(サイレンス)モードでUpgrade Assistantを再実行する場合は、「レスポンス・ファイルの保存」をクリックして、レスポンス・ファイルの場所と名前を指定します。サイレント・アップグレードは、Upgrade Assistantとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。

詳細レポートを表示するには、「ログの表示」をクリックします。

「次へ」をクリックします。

5. 「準備状況チェック」画面で、準備状況チェックのステータスを確認します。このプロセスには、数分かかることがあります。
複数のコンポーネントをチェックしている場合、それぞれのコンポーネントの進行状況は、それぞれ専用のプログレス・バーで同時に表示されます。

準備状況チェックが完了したら、「続行」をクリックします。

6. 「準備状況の終了」画面で、準備状況チェックの結果(「準備状況成功」または「準備状況失敗」)を確認します。

- 準備状況チェックが成功した場合は、「準備状況レポートの表示」をクリックして完全なレポートを確認します。準備状況チェックが成功した場合でも、実際のアップグレードを実行する前に、準備状況レポートを確認するようにしてください。「検索」オプションは、レポート内の特定の語句を検索する際に使用します。また、このレポートには、完成した準備状況チェック・レポート・ファイルが格納されている場所も示されます。

- 準備状況チェックで問題またはエラーが発生した場合は、「ログの表示」をクリックしてログ・ファイルを確認し、問題を特定して修正してから、準備状況チェックを再開します。ログ・ファイルは、設定したコマンドライン・オプションによって管理されます。

4.3.4 準備状況レポートの理解

ドメインの準備状況チェックを実行後、レポートを確認して、正常にアップグレードするために何かアクションを実行する必要があるかどうかを判断します。

準備状況レポート・ファイルの形式は、次のとおりです。

readiness_timestamp.txt

timestampは、準備状況チェックが実行された日時を示します。

準備状況レポートには、次に示す情報が含まれています。

表4-3 準備状況レポートの要素

レポートの情報

説明

必要なアクション

全体的な準備状況ステータス: SUCCESSまたはFAILURE

レポートの上部には、準備状況チェックが成功したか、または1つ以上のエラーが発生して完了したかが示されます。

1つ以上のエラーが発生してレポートが完了した場合、アップグレードを試みる前に、FAILを検索し、障害の原因となった問題を修正します。準備状況チェックは、アップグレードする前に必要に応じて何度でも再実行できます。

Timestamp

レポートが生成された日付と時刻です。

必要なアクションはありません。

ログ・ファイルの場所

ORACLE_HOME/oracle_common/upgrade/logs

生成されたログ・ファイルのディレクトリの場所です。

必要なアクションはありません。

準備状況レポートの場所

ORACLE_HOME/oracle_common/upgrade/logs

生成された準備状況レポートのディレクトリの場所です。

必要なアクションはありません。

チェックされたコンポーネントの名前

チェックに含まれるコンポーネントの名前およびバージョンとステータス。

このリリースにアップグレードできないコンポーネント(SOAコア拡張など)がドメインに含まれている場合は、アップグレードを試みないでください。

チェックされたスキーマの名前

チェックに含まれるスキーマの名前および現在のバージョンとステータス。

スキーマのバージョン番号をレビューします。このリリースにアップグレードできないスキーマがドメインに含まれる場合は、アップグレードを試みないでください。

個別のオブジェクトのテスト・ステータス: FAIL

準備状況チェックのテストで、特定のオブジェクトに問題が検出されています。

失敗した問題がすべて解決するまでアップグレードしないでください。

個別のオブジェクトのテスト・ステータス: PASS

準備状況チェックのテストでは、特定のオブジェクトに問題が検出されませんでした。

準備状況チェック・レポートにPASSステータスのみが表示されている場合、環境をアップグレードできます。ただし、準備状況チェックでは、ハードウェアやアップグレード時の接続性などの外部環境に関する問題を検出することはできません。アップグレードの進捗を常に監視する必要があります。

<オブジェクト>の準備状況チェックの完了ステータス: FAILURE

準備状況チェックによって、スキーマ、索引、データ型などの特定のオブジェクトに関する、解決する必要があるエラーが1つ以上検出されました。

失敗した問題がすべて解決するまでアップグレードしないでください。

<オブジェクト>の準備状況チェックの完了ステータス: SUCCESS

準備状況チェック・テストによって問題が検出されませんでした。

必要なアクションはありません。

準備状況レポート・ファイルのサンプルを次に示します。使用対象のレポートにはこれらすべてのチェックが含まれない場合があります。

Upgrade readiness check completed with one or more errors.

This readiness check report was created on Tue May 30 11:15:52 EDT 2016
Log file is located at: ORACLE_HOME/oracle_common/upgrade/logs/ua2016-05-30-11-14-06AM.log
Readiness Check Report File: ORACLE_HOME/oracle_common/upgrade/logs/readiness2016-05-30-11-15-52AM.txt

Starting readiness check of components.

Oracle Metadata Services
Starting readiness check of Oracle Metadata Services.
Schema User Name: DEV11_MDS
Database Type: Oracle Database
Database Connect String: machinename@yourcompany.com
VERSION Schema DEV11_MDS is currently at version 12.1.1.1.0.  Readiness checks will now be performed.
Starting schema test:  TEST_REQUIRED_TABLES  Test that the schema contains all the required tables
Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS
Starting schema test:  TEST_REQUIRED_PROCEDURES  Test that the schema contains all the required stored procedures
EXCEPTION     Schema is missing a required procedure: GETREPOSITORYFEATURES
Completed schema test: TEST_REQUIRED_PROCEDURES --> Test that the schema contains all the required stored procedures +++ FAIL
Starting schema test:  TEST_REQUIRED_VIEWS  Test that the schema contains all the required database views
Completed schema test: TEST_REQUIRED_VIEWS --> Test that the schema contains all the required database views +++ PASS
Starting index test for table MDS_ATTRIBUTES:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_ATTRIBUTES: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting index test for table MDS_COMPONENTS:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_TXN_LOCKS: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting schema test:  TEST_REQUIRED_TRIGGERS  Test that the schema has all the required triggers
Completed schema test: TEST_REQUIRED_TRIGGERS --> Test that the schema has all the required triggers +++ PASS
Starting schema test:  TEST_MISSING_COLUMNS  Test that tables and views are not missing any required columns
Completed schema test: TEST_MISSING_COLUMNS --> Test that tables and views are not missing any required columns +++ PASS
Starting schema test:  TEST_UNEXPECTED_TABLES  Test that the schema does not contain any unexpected tables
Completed schema test: TEST_UNEXPECTED_TABLES --> Test that the schema does not contain any unexpected tables +++ PASS
Starting schema test:  TEST_UNEXPECTED_PROCEDURES  Test that the schema does not contain any unexpected stored procedures
Completed schema test: TEST_UNEXPECTED_PROCEDURES --> Test that the schema does not contain any unexpected stored procedures +++ PASS
Starting schema test:  TEST_UNEXPECTED_VIEWS  Test that the schema does not contain any unexpected views
Completed schema test: TEST_UNEXPECTED_VIEWS --> Test that the schema does not contain any unexpected views +++ PASS
Starting index test for table MDS_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Completed index test for table MDS_ATTRIBUTES: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Completed index test for table MDS_LABELS: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Starting index test for table MDS_LARGE_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Starting schema test:  TEST_UNEXPECTED_TRIGGERS  Test that the schema does not contain any unexpected triggers
Completed schema test: TEST_UNEXPECTED_TRIGGERS --> Test that the schema does not contain any unexpected triggers +++ PASS
Starting schema test:  TEST_UNEXPECTED_COLUMNS  Test that tables and views do not contain any unexpected columns
Completed schema test: TEST_UNEXPECTED_COLUMNS --> Test that tables and views do not contain any unexpected columns +++ PASS
Starting datatype test for table MDS_ATTRIBUTES:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table MDS_ATTRIBUTES: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table MDS_COMPONENTS:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Starting permissions test:  TEST_DBA_TABLE_GRANTS  Test that DBA user has privilege to view all user tables
Completed permissions test: TEST_DBA_TABLE_GRANTS --> Test that DBA user has privilege to view all user tables +++ PASS
Starting schema test:  TEST_ENOUGH_TABLESPACE  Test that the schema tablespaces automatically extend if full
Completed schema test: TEST_ENOUGH_TABLESPACE --> Test that the schema tablespaces automatically extend if full +++ PASS
Starting schema test:  TEST_USER_TABLESPACE_QUOTA  Test that tablespace quota for this user is sufficient to perform the upgrade
Completed schema test: TEST_USER_TABLESPACE_QUOTA --> Test that tablespace quota for this user is sufficient to perform the upgrade +++ PASS
Starting schema test:  TEST_ONLINE_TABLESPACE  Test that schema tablespaces are online
Completed schema test: TEST_ONLINE_TABLESPACE --> Test that schema tablespaces are online +++ PASS
Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
INFO   Database product version: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
Finished readiness check of Oracle Metadata Services with status: FAILURE.

Oracle Fusion Middleware IAU Schemasの12.1.3.0バージョンを実行していて、それらのスキーマが11g (11.1.1.7以降)または12c (12.1.2.0)からアップグレードされている場合には、準備状況チェックは次に示すエラーで失敗する可能性があります。

Starting index test for table IAU_COMMON:  TEST_REQUIRED_INDEXES --> Test
that the table contains all the required indexes
INFO Audit schema index DYN_EVENT_CATEGORY_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_EVENT_TYPE_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_TENANT_INDEX in table IAU_COMMON is missing
the required columns or index itself is missing. This maybe caused by a known
issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_USER_INDEX in table IAU_COMMON is missing
the required columns or index itself is missing. This maybe caused by a known
issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_COMPONENT_TYPE_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_USER_TENANT_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
Completed index test for table IAU_COMMON: TEST_REQUIRED_INDEXES --> Test
that the table contains all the required indexes +++ FAIL

注意:
準備状況レポートの欠落している索引に関するエラーは無視してもかまいません。これは既知の問題です。欠落している索引に対応するものが、スキーマのアップグレード操作時に追加されます。このエラーは、アップグレードするスキーマがRCUを使用して12cで作成されていた場合は発生しません。

4.4 サーバーとプロセスの停止

Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、すべてのプロセスと管理サーバーや管理対象サーバーを含めたすべてのサーバーを停止する必要があります。

Oracle Fusion Middleware環境は、1つのOracle WebLogic Serverドメイン、1つの管理サーバー、複数の管理対象サーバー、Javaコンポーネント、システム・コンポーネント(Identity Managementのコンポーネントなど)およびメタデータのリポジトリとして使用する1つのデータベースで構成できます。コンポーネントは相互に依存していることがあるため、適切な順序で停止する必要があります。

注意:
この項の手順では、WLSTコマンドライン・ユーティリティまたはスクリプトを使用してサーバーとプロセスを停止する方法について説明します。また、Oracle Fusion Middleware ControlとOracle WebLogic Server管理コンソールを使用することもできます。『Oracle Fusion Middleware Oracle Fusion Middlewareの管理』の管理サーバー、管理対象サーバーおよびノード・マネージャの起動および停止に関する項を参照してください。

Fusion Middleware環境を停止するには、次に示す手順を実行します。

ステップ1: システム・コンポーネントを停止する

Oracle HTTP Serverなどのシステム・コンポーネントを停止するには、stopComponentスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

システム・コンポーネントは任意の順序で停止できます。

ステップ2: 管理対象サーバーを停止する

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

- (UNIX) DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url

- (Windows) DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url

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

ステップ3: Oracle Identity Managementのコンポーネントを停止するOracle Internet Directoryなど、Oracle Identity Managementコンポーネントを停止します。

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

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

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

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

- (UNIX) DOMAIN_HOME/bin/stopWebLogic.sh

- (Windows) DOMAIN_HOME\bin\stopWebLogic.cmd

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

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

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

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

4.5 RCUを使用した必要な12cスキーマの作成

11gからアップグレードする場合は、アップグレードの開始前に、リポジトリ作成ユーティリティ(RCU)を使用して必須の12cスキーマを作成する必要があります。

注意:
以前のOracle Fusion Middleware 12cリリースからアップグレードする場合は、これに該当するスキーマを再作成する必要はありません(そのスキーマがすでに存在する場合)。ドメインの既存のスキーマを特定するには、次の手順を参照してください。

11gからアップグレードする場合は、ドメイン内に既存のスキーマを特定するために、アップグレード前チェックリストを参照してください。12cにアップグレードする前に、次のスキーマが存在している必要があります。

- サービス表スキーマ(prefix_STB)。このスキーマは12cで新規のものであり、ドメインベースのアップグレードに必要になります。基本的なスキーマ構成情報(スキーマ接頭辞やパスワードなど)が格納され、他のOracle Fusion Middlewareコンポーネントはドメイン作成中にこれにアクセスして使用できます。このスキーマはリポジトリ作成ユーティリティ(RCU)を実行するときに自動的に作成され、ここで他の11gスキーマに使用した既存のスキーマ所有者接頭辞を指定します。注意: サービス表スキーマが存在しない場合、UPGAST-00328: スキーマ・バージョンのレジストリ表はこのデータベースに存在しません。その場合、アップグレード・アシスタントを実行するためにはサービス表スキーマを作成する必要があります。というエラー・メッセージが表示されることがあります。

- Oracle Platform Security Services (OPSS)スキーマ(prefix_OPSS)。このスキーマは、11gでOIDベースのセキュリティ・ストアを使用している場合に必要です。このスキーマは、リポジトリ作成ユーティリティ(RCU)の実行時に自動的に作成されます。LDAPベースのOPSSセキュリティ・ストアでサポートされているのは、Oracle Internet Directory (OID)のみです。LDAPベースのポリシー・ストアは、通常、本番環境で使用します。アップグレード前に、OIDベースのセキュリティ・ストアを再関連付けする必要はありません。アップグレード・アシスタントの実行中に、OPSSスキーマを選択できます。アップグレード・アシスタントは、OIDベースのセキュリティ・ストアを自動的にアップグレードします。注意: 12c OPSSデータベース・スキーマが必要なのは、ドメインの再構成時に12cスキーマを参照するためです。ドメインでは、アップグレード完了後にOIDベースのセキュリティ・ストアが引き続き使用されます。

RCUを使用して12cスキーマを作成する手順は次のとおりです。

1. (オプション) 11gからアップグレードし、既存のドメインにどのスキーマが存在しているかを確認するには、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 ;

2. コマンドラインからjava -versionを実行して、動作保証されたJDKがすでにシステムにあることを確認します。12c (12.2.1.2)の場合、動作保証済JDKは1.8.0_101以降です。
JAVA_HOME環境変数が、動作保証済JDKの場所に設定されていることを確認します。次に例を示します。

- (UNIX) setenv JAVA_HOME /home/Oracle/Java/jdk1.8.0_101

- (Windows) set JAVA_HOME=C:\home\Oracle\Java\jdk1.8.0_101

$JAVA_HOME/binを$PATHに追加します。

3. oracle_common/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/bin

- (Windows) ORACLE_HOME\oracle_common\bin

4. RCUを起動します。

- (UNIX) ./rcu

- (Windows) rcu.bat

5. 「ようこそ」画面で「次へ」をクリックします。

6. 「リポジトリの作成」画面で「リポジトリの作成」を選択し、「システム・ロードおよび製品ロード」を選択します。
DBA権限を持っていない場合は、「システム・ロードに対するスクリプトの準備」を選択します。これにより、SQLスクリプトが生成されます。このスクリプトには、RCUが選択されたコンポーネントに対してアクションを実行するときにコールするものと同じSQL文とブロックがすべて含まれています。このスクリプトが生成された後は、必要なSYSまたはSYSDBA権限を持つユーザーが、このスクリプトを実行してシステム・ロード・フェーズを完了できます。
「次へ」をクリックします。

7. 「データベース接続の詳細」画面で、「データベース・タイプ」を選択し、11gスキーマをホストするデータベースの接続情報を入力します。次の該当する表を参照してください。

表4-4 Oracle Databaseと、エディションベースで再定義されるOracle Databaseに対する接続資格証明

オプション

説明と例

ホスト名

データベースが実行されるサーバーの名前を、次の書式で指定します。

examplehost.exampledomain.com

Oracle RACデータベースの場合は、このフィールドにVIP名またはいずれかのノード名を指定します。

ポート

データベースのポート番号を指定します。Oracleデータベースのデフォルトのポート番号は、1521です。

サービス名

データベースのサービス名を指定します。通常、サービス名はグローバル・データベース名と同じです。

Oracle RACデータベースの場合、このフィールドにいずれかのノードのサービス名を指定します。次に例を示します。

examplehost.exampledomain.com

ユーザー名

データベースのユーザー名を入力します。デフォルトのユーザー名はSYSです。

パスワード

データベース・ユーザーのパスワードを入力します。

ロール

ドロップダウン・リストからデータベース・ユーザーのロールを選択します。

「標準」またはSYSDBA

表4-5 MySQLデータベースに対する接続資格証明

オプション

説明と例

ホスト名

データベースが稼働しているサーバーのホスト名、IPアドレスまたは詳細なサーバー名を、host\server形式で指定します。

ポート

データベースのポート番号を指定します。

データベース名

データベースの名前を指定します。

ユーザー名

管理者権限を持つユーザーの名前を指定します。

パスワード

データベース・ユーザーのパスワードを入力します。

表4-6 Microsoft SQL Serverデータベースに対する接続資格証明

オプション

説明と例

Unicodeのサポート

ドロップダウン・リストから「はい」または「いいえ」を選択します。

サーバー名

データベースが稼働しているサーバーのホスト名、IPアドレスまたは詳細なサーバー名を、host\server形式で指定します。
MSSQL名前付きインスタンス: 名前付きインスタンスは、コンピュータのネットワーク名にインストール時に指定したインスタンス名を追加することで識別されます。クライアントは、接続時に、サーバー名とインスタンス名の両方を指定する必要があります。

ポート

データベースのポート番号を指定します。

データベース名

データベースの名前を指定します。

ユーザー名

管理者権限を持つユーザーの名前を指定します。

パスワード

データベース・ユーザーのパスワードを入力します。

表4-7 IBM DB2データベースに対する接続資格証明

オプション

説明と例

サーバー名

データベースが稼働しているサーバーのホスト名、IPアドレスまたは詳細なサーバー名を、host\server形式で指定します。

ポート

データベースのポート番号を指定します。

データベース名

データベースの名前を指定します。

ユーザー名

DB所有者の権限が付与されているユーザーの名前を指定します。IBM DB2データベースのデフォルトのユーザー名はdb2adminです。

パスワード

データベース・ユーザーのパスワードを入力します。

前提条件のチェックに成功したら、「OK」をクリックして次のページに進みます。チェックが失敗した場合は、入力した詳細を確認して再試行します。

8. 「コンポーネントの選択」画面で、「既存の接頭辞の選択」を選択し、ドロップダウン・メニューから既存の11gスキーマの作成に使用した接頭辞(たとえば、DEV11G)を選択します。この接頭辞は、スキーマをこのドメインで使用するために論理的にまとめてグループ化するために使用されます。
「AS共通スキーマ」を選択します。

注意: デフォルトで、Common Infrastructure Servicesサービス表(prefix_STB)およびOracle Platform Security Services (prefix_OPSS)スキーマが選択されます(これらが作成されていない場合)。

インストールするコンポーネントの接頭辞とスキーマ名を書き留めます。インストールの構成時にこの情報が必要になります。「次へ」をクリックします。

9. 「前提条件チェック」ダイアログで、前提条件チェックが正常であることを確認し、「OK」をクリックします。

10. 「スキーマ・パスワード」画面で、スキーマの所有者のパスワードを入力します。
この画面で入力したパスワードを書き留めてください。製品インストールの構成中に必要となります。

11. 「表領域のマップ」画面で、作成するスキーマの目的の表領域マッピングを構成します。
「次へ」をクリックしてから、確認ダイアログの「OK」をクリックします。進行状況ダイアログに表領域の作成が完了したことが示されたら、「OK」をクリックします。

RCUの起動時に、Transparent Data Encryption (TDE)がデータベース(OracleまたはOracle EBR)内で有効化されている場合にのみ、「表領域の暗号化」チェック・ボックスが表示されます。RCUで作成される新しい表領域をすべて暗号化するには、「表領域のマップ」画面で「表領域の暗号化」チェック・ボックスを選択します。

12. 「サマリー」画面で情報を確認し、「作成」をクリックしてスキーマの作成を開始します。
この画面には、このRCU操作で作成されたログ・ファイルに関する情報が表示されます。特定のログ・ファイルの名前をクリックして、そのファイルの内容を表示できます。

13. 「完了サマリー」画面の情報を確認し、操作が正常に完了したことを確かめます。「閉じる」をクリックして、スキーマの作成を完了します。

4.6 ドメインの再構成

再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.2)にあわせて再構成します。

WebLogic Serverドメインを再構成すると、ドメイン内のアプリケーションに応じて、次の項目が自動的に更新されます。

- WebLogic Serverコア・インフラストラクチャ

- ドメイン・バージョン

注意:

ドメインの再構成を開始する前に、次の制限事項に注意してください。

- 再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。

- アップグレード・プロセス中に、非動的クラスタ・ドメインを動的クラスタ・ドメインに変換することはサポートされていません。
動的クラスタ機能は、再構成ウィザードの実行中に使用できますが、サポートされているアップグレードは非動的クラスタのアップグレードのみで、その後で動的クラスタを追加することになります。アップグレード・プロセス中に動的クラスタを追加することはできません。

具体的には、ドメインを再構成する場合、次のことが発生します。

- ドメインのconfig.xmlファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンに更新されます。

- すべてのインストール済Oracle製品の再構成テンプレートは、自動的に選択されてドメインに適用されます。これらのテンプレートは、WebLogicドメインが現在のWebLogic Serverバージョンと互換性を持つために必要な再構成タスクを定義します。

- 起動スクリプトが更新されます。
変更済の起動スクリプトを維持する場合は、そのスクリプトをバックアップしてから、再構成ウィザードを開始してください。

注意:
ドメインの再構成プロセスを開始すると、元に戻すことはできません。再構成ウィザードの実行前には、アップグレード前チェックリストで説明しているように、ドメインのバックアップが作成されていることを確認してください。再構成ウィザードの実行中にエラーまたは他の割込みが発生した場合、バックアップ場所から元のドメイン・ディレクトリにファイルとディレクトリをコピーすることによって、ドメインをリストアする必要があります。これは、再構成前の元の状態にドメインを復元するための唯一の方法です。

再構成ウィザードを使用して既存のドメインを再構成する手順に従います。ドメインの再構成の一般情報は、『Oracle Fusion Middleware Oracle WebLogic Serverのアップグレード』のWebLogicドメインの再構成に関する項を参照してください。

- ドメインのバックアップ

- 再構成ウィザードの起動

- 再構成ウィザードを使用したドメインの再構成
再構成ウィザードの各画面を通じて既存のドメインを再構成します。

4.6.1 ドメインのバックアップ

再構成ウィザードの実行前に、ドメイン・ディレクトリのバックアップ・コピーを作成します。

ドメイン・ディレクトリのバックアップを作成するには:

1. コンテンツを保持するには、ソース・ドメインを別の場所にコピーします。
たとえば、C:\domains\mydomainをC:\domains\mydomain_backupにコピーします。

2. 各リモート管理対象サーバーのドメインを更新する前に、各リモート・マシンのドメイン・ディレクトリのバックアップ・コピーを作成します。

3. ドメインのバックアップしたバージョンが完全であることを確認します。

なんらかの理由でドメインの再構成が失敗した場合は、すべてのファイルおよびディレクトリをバックアップ・ディレクトリから元のドメイン・ディレクトリにコピーしてドメインを完全に再構成前の元の状態に戻す必要があります。

4.6.2 再構成ウィザードの起動

再構成ウィザードをグラフィカル・モードで起動する手順は次のとおりです。

1. ドメインが存在するシステムにサインインします。

2. コマンド・シェル(UNIXオペレーティング・システムの場合)またはコマンド・プロンプト・ウィンドウ(Windowsオペレーティング・システムの場合)を開きます。

3. エディション・ベースのデータベース・ユーザーのみ: スキーマがEBRデータベースを使用して構成されている場合、再構成ウィザードを実行する前に、手動でデフォルトのエディション名を設定する必要があります。
次のSQLコマンドを実行して、デフォルト・エディションを設定します。
ALTER DATABASE DEFAULT EDITION = edition_name;

edition_nameは、子エディションの名前です。

4. oracle_common/common/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/common/bin

- (Windows) ORACLE_HOME\oracle_common\commom\bin

5. 次に示すロギングオプションを指定して、再構成ウィザードを開始します。

- (UNIX) ./reconfig.sh -log=log_file -log_priority=ALL

- (Windows) reconfig.cmd -log=log_file -log_priority=ALL

log_fileは、ドメイン再構成セッション用に作成するログ・ファイルの絶対パスです。これは、再構成処理をトラブルシューティングする必要がある場合に役立つことがあります。

パラメータ-log_priority=ALLにより、ログは詳細モードで記録されるようになります。

注意:

このコマンドを実行すると、デフォルトのキャッシュ・ディレクトリが無効であることを示す次のエラー・メッセージが表示される場合があります。

*sys-package-mgr*: can't create package cache dir

環境変数CONFIG_JVM_ARGSを設定することでキャッシュ・ディレクトリを変更できます。次に例を示します。

CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

4.6.3 再構成ウィザードを使用したドメインの再構成

再構成ウィザードの各画面を通じて、既存のドメインを再構成します。

ドメインを再構成する手順は次のとおりです。

1. 「ドメインの選択」画面でアップグレードするドメインの場所を指定するか、「参照」をクリックして移動し、ドメイン・ディレクトリを選択します。「次へ」をクリックします。

2. 「再構成セットアップの進行状況」画面で、セットアップ・プロセスの進行状況を確認します。完了したら、「次へ」をクリックします。
このプロセスでは次の処理が行われます。

- Fusion Middleware製品を含む、インストール済製品の再構成テンプレートが自動的に適用されます。これにより、config.xml、config-groups.xml、security.xmlなどの様々なドメイン構成ファイルが更新されます。

- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

- ドメイン・アップグレードが検証されます。

3. 「ドメイン・モードおよびJDK」画面で、ドメインで使用するJDKを選択するか、「参照」をクリックして使用するJDKに移動します。12c (12.2.1.2)のサポート対象JDKバージョンは、1.8.0_101以降です。「次へ」をクリックします。

注意:
ここでは「ドメイン・モード」は変更できません。

特定のプラットフォームでサポートされているJDKのリストは、Oracle Fusion Middlewareでサポートされているシステム構成を参照してください。

4. 「JDBCデータ・ソース」画面で、ドメイン・ソースで定義したJDBCデータ・ソースを構成します。
ドメインを作成する製品に関連付けられるJDBCデータ・ソースは、画面の下半分にリスト表示されます。JDBCデータ・ソースには、データ・ソース・インスタンスの作成時、デプロイ時もしくはターゲット指定時、またはサーバー起動時に作成されるデータベース接続のプールが含まれます。 アプリケーションはJNDIツリーでデータ・ソースをルックアップしてから、接続をリクエストします。アプリケーションに接続する必要がなくなった場合は、接続がデータ・ソースの接続プールに戻されます。

「データソース名」ドロップダウン・リストから、設定を指定するデータ・ソースを選択します。指定した値は、選択されたデータ・ソースのデータ・ソース・リストの適切な列に表示されます。

データ・ソースがOracle RAC構成の場合は、次の3つのオプションのいずれかを選択できます。

- GridLinkへ変換

- RACマルチ・データ・ソースへ変換

- 変換しない

各オプションの詳細は、「ヘルプ」をクリックしてください。

詳細を指定したら、「次へ」をクリックします。

「JDBCデータ・ソース」画面でデータ・ソースを選択しないと、次に示す警告が表示されます。

ドライバがありません

「OK」をクリックして検証せずに続行するか、「取消」をクリックして「JDBCデータ・ソース」ページに戻ります。

この場合、「OK」をクリックしてもデータ・ソースは検証されません。

5. 「JDBCデータ・ソース・テスト」画面で、「JDBCデータ・ソース」画面で構成したデータ・ソース接続のチェック・ボックスを選択し、「選択された接続のテスト」をクリックしてデータ・ソース接続をテストします。

注意:
データベース接続をテストするには、接続するデータベースが起動している必要があります。接続をテストしない場合は、データ・ソースを選択しません。「次へ」をクリックして続行します。

6. 「データベース構成タイプ」画面で、「RCUデータ」を選択して、サーバー表(_STB)スキーマに接続します。
RCUサービス表(_STB)スキーマ資格証明を使用してデータベース接続の詳細を入力して、「RCU構成の取得」をクリックします。

再構成ウィザードは、この接続を使用してドメイン内のコンポーネントに必要なデータ・ソースを自動的に構成します。
注意: 既存の11gデータ・ソースの場合、再構成では既存の値が保存されます。RCUで12c用にスキーマが作成された新しいデータ・ソースの場合、デフォルトの接続データは_STBスキーマから取得されます。特定のスキーマの接続データが_STBスキーマにない場合は、デフォルトの接続データが使用されます。

チェックに成功したら、「次へ」をクリックします。チェックが失敗した場合は、接続の詳細を正しく入力し直して再試行します。

7. 「JDBCコンポーネント・スキーマ・テスト」画面で、すべてのコンポーネント・スキーマを選択して「選択された接続のテスト」をクリックして、各スキーマの接続をテストします。テストの結果は、「ステータス」列に表示されます。
チェックが終了したら、「次へ」をクリックします。

8. 「ノード・マネージャ」画面は、再構成するドメインで、ホストごとのノード・マネージャが使用されている場合にのみ表示されます。
「ノード・マネージャ」画面で、再構成したドメインで使用するノード・マネージャ構成を選択します。結果として生成される構成は、「ノード・マネージャ・タイプ」および「ノード・マネージャ構成」で選択したオプションの組合せに応じて異なります。

表4-8 ノード・マネージャ画面のフィールドの説明

オプション

説明

ドメインごとのデフォルトの場所

このオプションを選択すると、ノード・マネージャ・ホームはDOMAIN_NAME/nodemanagerに再定義され、ノード・マネージャ・ホームの編集ができなくなります。

ドメインごとのカスタムの場所

このオプションは、このドメインの特定の場所に、ドメインごとのノード・マネージャ構成ファイルを作成する場合に選択します。「ノード・マネージャ・ホーム」フィールドでディレクトリを指定するか、「参照」をクリックしてナビゲーション・ツリーを使用してその場所を選択します。指定するディレクトリは空である必要があります。このディレクトリに、nodemanager.propertiesおよびnodemanager.domainsファイルが作成されます。

ノード・マネージャ・ホーム

ドメインごとのカスタムの場所オプションを選択した場合は、「参照」をクリックして、ドメインごとのノード・マネージャ構成の格納に使用するディレクトリの場所に移動します。

手動ノード・マネージャ・セットアップ

このオプションを選択した場合は、ドメインのノード・マネージャ構成の作成がスキップされ、残りのフィールドはすべて変更できなくなるため、ドメインでノード・マネージャを使用する場合はノード・マネージャ構成の実行の説明に従って、ノード・マネージャを手動で構成する必要があります。再構成されたドメインでは、ホストごとのノード・マネージャ構成が引き続き使用されます。

既存のドメインがノード・マネージャを使用するように構成されておらず、再構成されたドメインでノード・マネージャを使用しない場合も、このオプションを選択する必要があります。

ノード・マネージャ構成の詳細は、『Oracle WebLogic Serverノード・マネージャの管理』を参照してください。

ノード・マネージャ構成

次の2つのオプションから1つを選択します。「手動ノード・マネージャ・セットアップ」を選択した場合は、次のフィールドを使用できません。

新規構成の作成

nodemanager.propertiesのデフォルトの設定を使用して、再構成されたドメインに、ドメインごとのノード・マネージャ構成が自動的に作成されます。ドメインが正常に再構成された後に、必要に応じて、nodemanager.propertiesを変更できます。

既存の構成を移行

すでに存在するホストごとのノード・マネージャ構成が、再構成されたドメインのドメインごとの構成に移行されます。これには、ListenAddress、ListenPort、StartScriptName、JavaHomeおよびLogFileの環境固有の設定は含まれません。

ノード・マネージャ・ホーム

「既存の構成を移行」オプションを選択した場合は、再構成したドメインの移行先にするノード・マネージャのホーム・ディレクトリを入力するか、参照してください。

Oracle推奨デフォルトの適用

このチェック・ボックスは、「既存の構成を移行」オプションを選択した場合に、nodemanager.propertiesファイルに指定されているOracle推奨のデフォルトを使用するときに選択します。移行されるnodemanager.propertiesファイルの設定を引き続き使用する場合は、このチェック・ボックスの選択を解除してください。

推奨されるプロパティのデフォルト値は次のとおりです。

LogLimit=0
AuthenticationEnabled=true
LogLevel=INFO
DomainsFileEnabled=true
NativeVersionEnabled=true
LogToStderr=true
SecureListener=true
LogCount=1
StopScriptEnabled=false
QuitEnabled=false
LogAppend=true
StateCheckInterval=500
CrashRecoveryEnabled=false
StartScriptEnabled=true
LogFormatter=weblogic.nodemanager.server.LogFormatter
ListenBacklog=50

ノード・マネージャ資格証明: ユーザー名、パスワード

再構成されたドメインで、ノード・マネージャの起動に使用するユーザー名とパスワードを指定します。

9. 「拡張構成」画面で、拡張構成を実行するすべてのカテゴリを選択できます。選択したカテゴリごとに、詳細構成を行うことができる適切な構成画面が表示されます。

注意:
「拡張構成」画面に表示されるカテゴリは、ドメインで選択したテンプレートに定義されているリソースによって異なります。

このアップグレードでは、オプションを選択せずに「次へ」をクリックします。

10. 「構成のサマリー」画面で、ドメインの詳細な構成を確認してから続行します。
「表示」ドロップダウン・リストからフィルタ・オプションを選択すると、右側のパネルに表示される項目を制限できます。

構成を変更するには、「戻る」をクリックして適切な画面に戻ります。ドメインを再構成するには、「再構成」をクリックします。

注意:
ドメインの再構成時には、ドメインの場所は変更されません。

11. 「再構成の進行状況」画面に、再構成プロセスの進行状況が表示されます。
このプロセスでは次の処理が行われます。

- ドメイン情報が抽出、保存および更新されます。

- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

プログレス・バーに100%が表示されたら、「次へ」をクリックします。

12. 「構成の終了」画面に、再構成プロセスが成功して完了したか、または失敗したかどうかが示されます。管理サーバーURL(リスニング・ポートを含む)とともに再構成されたドメインの場所も表示します。再構成が成功した場合は、「Oracle Weblogic Serverの再構成に成功しました」と表示されます。
再構成プロセスが正常に完了しなかった場合は、その理由を示すエラー・メッセージが表示されます。問題を解決するための適切な措置を講じます。問題を解決できない場合は、My Oracle Supportに連絡してください。

今後の操作での使用に備えて、ドメインの場所と管理サーバーのURLを記録しておきます。

4.7 ドメイン・コンポーネント構成のアップグレード

ドメインの再構成後、更新したドメイン構成と一致するように、ドメイン内でUpgrade Assistantを使用してドメイン・コンポーネント構成をアップグレードします。

- Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade Assistantは非SYSDBAとして実行して、一度にアップグレードするドメインは1つにすることをお薦めします。

- Upgrade Assistantを使用したドメイン・コンポーネントのアップグレード
Upgrade Assistantの各画面を通じて、WebLogicドメインのコンポーネント構成をアップグレードします。

- ドメイン固有コンポーネント構成のアップグレードの確認
ドメイン固有コンポーネント構成のアップグレードが成功したことを確認するには、管理コンソールおよびFusion Middleware Controlにログインし、各コンポーネントのバージョン番号が12.2.1.2であることを確認します。

4.7.1 Upgrade Assistantの起動

Upgrade Assistantを実行して、製品のスキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade Assistantは非SYSDBAとして実行して、一度にアップグレードするドメインは1つにすることをお薦めします。

Upgrade Assistantを起動するには、次の手順に従います。

1. oracle_common/upgrade/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. Upgrade Assistantを起動します。

- (UNIX) ./ua

- (Windows) ua.bat

コマンドラインに指定可能なその他のパラメータ(ロギングのパラメータなど)の詳細は、次を参照してください。

- Upgrade Assistantパラメータ

4.7.1.1 Upgrade Assistantパラメータ

コマンドラインからUpgrade Assistantを起動する際に、追加のパラメータを指定できます。

表4-9 Upgrade Assistantコマンドライン・パラメータ

パラメータ

必須/省略可能

説明

-readiness

準備状況チェックの場合は必須
注意: スタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では準備状況チェックを実行できません。

アップグレードの準備状況チェックを実行します(実際のアップグレードは実行しません)。

スキーマと構成がチェックされます。

-examineパラメータを指定した場合は、このパラメータを指定しないでください。

-threads

省略可能

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を特定します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須

レスポンス・ファイルに保存した入力を使用して、Upgrade Assistantを実行します。このレスポンス・ファイルは、GUIモードでUpgrade Assistantを実行したときの入力データから生成されます。このパラメータを使用すると、Upgrade Assistantがサイレント・モードで(Upgrade Assistant画面を表示せずに)実行されます。

-examine

省略可能

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel attribute

省略可能

次のいずれかの属性を指定して、ログイン・レベルを設定します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

デフォルトのロギング・レベルはNOTIFICATIONです。

-logLevel TRACE属性を設定して、より多くのログが記録されるようにすることを検討してください。これは、アップグレードの失敗をトラブルシューティングする際に役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir location

省略可能

アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。既存の書込み可能なディレクトリを指定する必要があります。Upgrade Assistantは、このディレクトリにログ・ファイルと一時ファイルを作成します。

デフォルトの場所は次のとおりです。

UNIXの場合:

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

Windowsの場合:

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

省略可能

すべてのコマンドライン・オプションを表示します。

4.7.2 Upgrade Assistantを使用したドメイン・コンポーネントのアップグレード

Upgrade Assistantの各画面を通じて、WebLogicドメインのコンポーネント構成をアップグレードします。

再構成ウィザードを実行して、WebLogicドメインを12c (12.2.1.2)にあわせて再構成したら、Upgrade Assistantを実行してドメイン・コンポーネント構成を更新後のドメイン構成と一致するようにアップグレードする必要があります。

Upgrade Assistantを使用して、ドメイン・コンポーネント構成をアップグレードするには:

1. 「ようこそ」画面には、Upgrade Assistantの概要と、アップグレード前のいくつかの重要なタスクについての情報が示されます。「次へ」をクリックします。

注意:
Upgrade Assistantの画面の詳細は、画面上の「ヘルプ」をクリックしてください。

2. 「WebLogicコンポーネント」画面で、「WebLogicコンポーネント構成」オプションを選択して、管理対象WebLogic Serverドメインのコンポーネント構成をアップグレードします。ドメインを管理しているWebLogic管理サーバーに接続するために必要な接続詳細を入力して、「次」をクリックします。

3. 「コンポーネント・リスト」画面で、構成をアップグレードするコンポーネントがリストにすべて含まれていることを確認し、「次」をクリックします。
アップグレードするコンポーネントがリストに含まれていない場合は、「戻る」をクリックして前の画面に戻り、別のドメインを指定します。

4. 「前提条件」画面で、すべてのチェック・ボックスを選択して、前提条件を満たしていることを確認します。「次へ」をクリックします。

注意:
Upgrade Assistantでは、前提条件が満たされているかどうかの確認は行われません。

5. 「調査」画面で、各コンポーネントを調査したUpgrade Assistantのステータスを確認して、コンポーネント構成のアップグレードの準備が整っていることを検証します。ステータスが「調査が終了しました。」になっている場合は、「次」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認します。一般的なアップグレード・エラーの解決方法の詳細は、Oracle Fusion Middleware Upgrade Assistantによるアップグレードのアップグレード・ガイド のアップグレードのトラブルシューティングに関する項を参照してください。

注意:

- 確認フェーズ中に検出された問題を、アップグレードを進めずに解決した場合は、バックアップからリストアを再び行わずにUpgrade Assistantを開始できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックしてアップグレードを続行していた場合は、Upgrade Assistantを再開する前に、バックアップからアップグレード前の環境をリストアする必要があります。

- 調査プロセスを取り消しても構成データに影響はありませんが、将来のアップグレード・セッションでは、Upgrade Assistantが収集した情報の再収集が必要になります。

6. 「アップグレード・サマリー」画面で、コンポーネント構成のアップグレードに選択したオプションのサマリーを確認します。
レスポンス・ファイルには、入力したすべての情報が収集および格納されます。このファイルにより、その後のサイレント・アップグレードの実行が可能になります。サイレント・アップグレードは、Upgrade Assistantとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。

7. 「アップグレードの進行状況」画面で、アップグレードのステータスを監視します。

注意:
アップグレード・アシスタントにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。これを行うと、環境が不安定になる可能性があります。

正しくアップグレードされていないコンポーネントがある場合は、Upgrade Assistantのログ・ファイルで情報を確認します。

注意:
この画面のプログレス・バーには、現在のアップグレード手順の進行状況が表示されます。アップグレードの残り時間を示すものではありません。

「次へ」をクリックします。

8. アップグレードが成功した場合: 「アップグレード成功」画面で、「閉じる」をクリックし、アップグレードを完了してウィザードを閉じます。新規インストールでコンポーネントを機能させるために手動で実行する必要のあるタスクが、アップグレード後のアクションのウィンドウに表示されます。このウィンドウは、コンポーネントにアップグレード後の手順がある場合にのみ表示されます。

アップグレードが失敗した場合: 「アップグレード失敗」画面で、「ログの表示」をクリックし、エラーを表示してトラブルシューティングします。ログは、ORACLE_HOME/oracle_common/upgrade/logsにあります。

注意:
アップグレードが失敗した場合は、アップグレード前の環境をバックアップからリストアし、問題を修正してから、Upgrade Assistantを再起動する必要があります。

4.7.3 ドメイン固有コンポーネント構成のアップグレードの確認

ドメイン固有コンポーネント構成のアップグレードが成功したことを確認するには、管理コンソールおよびFusion Middleware Controlにログインし、各コンポーネントのバージョン番号が12.2.1.2になっていることを確認します。

管理コンソールにログインするには、次に移動します: http://administration_server_host:administration_server_port/console

Fusion Middleware Controlにログインするには、次に移動します: http://administration_server_host:administration_server_port/em

注意:

アップグレード後、管理ツールは、前のOracleホームではなく新しい12cのOracleホームから必ず実行してください。

アップグレード・プロセス時に、一部のOWSMドキュメント(ポリシー・セット、ポリシーおよびアサーション・テンプレートなどの事前定義ドキュメント)のアップグレードが必要な場合があります。ポリシー・セットまたは事前定義ドキュメントがアップグレードされると、バージョン番号が1増分されます。

4.8 サーバーとプロセスの起動

アップグレードが正常に完了したら、すべてのプロセスと管理サーバーや管理対象サーバーを含めたすべてのサーバーを再起動します。

コンポーネントは相互に依存していることがあるため、適切な順序で起動する必要があります。

注意:
この項の手順では、WLSTコマンドラインまたはスクリプトを使用してサーバーとプロセスを起動する方法について説明します。また、Oracle Fusion Middleware ControlとOracle WebLogic Server管理コンソールを使用することもできます。『Oracle Fusion Middlewareの管理』の管理サーバーと管理対象サーバーおよびノード・マネージャの起動と停止に関する項を参照してください。

Fusion Middleware環境を起動するには、次に示す手順を実行します。

ステップ1: 管理サーバーの起動

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

管理サーバーを起動するには、startWebLogicスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/startWebLogic.sh

- (Windows) DOMAIN_HOME\bin\startWebLogic.cmd

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

ステップ2: ノード・マネージャを起動する

ノード・マネージャを起動するには、startNodeManagerスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/startNodeManager.sh

- (Windows) DOMAIN_HOME\bin\startNodeManager.cmd

ステップ3: Oracle Identity Managementのコンポーネントを起動する目的の環境に含まれるOracle Identity Managementのコンポーネント(Oracle Internet Directoryなど)を起動します。

- (UNIX) DOMAIN_HOME/bin/startComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\startComponent.cmd component_name

ステップ4: 管理対象サーバーを起動する

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

- (UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

- (Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url

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

注意:
通常、管理対象サーバーを起動すると、そのサーバーにデプロイされているアプリケーションが開始されます。したがって、管理対象サーバーの起動後にアプリケーションを手動で開始する必要はありません。

ステップ5: システム・コンポーネントを起動する

Oracle HTTP Serverなどのシステム・コンポーネントを起動するには、startComponentスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/startComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\startComponent.cmd component_name

システム・コンポーネントは任意の順序で起動できます。

- Oracle HTTP Serverの起動
Enterprise Manager Fusion Middleware Controlを使用すると、Oracle HTTP Serverを起動、停止および再起動できます。

4.8.1 Oracle HTTP Serverの起動

Enterprise Manager Fusion Middleware Controlを使用すると、Oracle HTTP Serverを起動、停止および再起動できます。

Oracle HTTP Serverは、ノード・マネージャで起動できます。起動の手順は、『Oracle Fusion Middleware Oracle HTTP Serverの管理』のリモートからのOracle HTTP Serverの実行に関する項を参照してください。

Enterprise Manager Fusion Middleware Controlを使用して、Oracle HTTP Serverを起動するには:

1. Oracle HTTP Serverのホーム・ページへ移動します。

2. 「Oracle HTTP Server」メニューから次の手順を実行します。

a. 制御を選択します。

b. 「コントロール」メニューから「起動」を選択します。

または

3. 「ターゲット・ナビゲーション」ツリーから次の手順を実行します。

a. 起動するOracle HTTP Serverインスタンスを右クリックします。

b. 制御を選択します。

c. 「コントロール」メニューから「起動」を選択します。

4.9 アップグレードの確認

管理コンソールとEnterprise Manager Fusion Middleware Controlにログインできれば、アップグレードは正常に完了しています。

アップグレードを確認するには:

1. 次に示すURLにサインインします。
http://MachineName.us.oracle.com:7777

2. Enterprise Manager Fusion Middleware Controlにアクセスするには、次のように指定します。
http://MachineName.us.oracle.com:7001/em

新しくアップグレードした環境を起動できない場合は、OracleウォレットでMD5証明書を使用していることが原因になっている可能性があります。MD5署名を使用しているかどうかのチェックの手順およびSHA-2証明書に置き換える手順については、「SHA-2アルゴリズムを使用して署名された証明書でMD5アルゴリズムを使用して署名された証明書を置き換え」を参照してください。

4.10 WLSTを使用したアップグレード後のウォレットのKSSデータベースへのインポート

Upgrade Assistantを使用して以前のバージョンのOracle HTTP Serverから12c (12.2.1.2)にアップグレードする場合は、追加のウォレット管理タスクを実行する必要があります。

ohs_postUpgradeコマンドを使用してOracle HTTP ServerインスタンスのウォレットをKSSデータベースにインポートします。

このコマンドはドメイン内のすべてのOracle HTTP Serverインスタンスを解析し、同じキーストア名に対するエントリがデータベースに存在しない場合は、KSSデータベースにウォレットをインポートします。このコマンドの詳細は、ohs_postUpgradeを参照してください。

1. コマンドラインからWLSTを起動します。

(UNIX) ORACLE_HOME/oracle_common/common/bin/wlst.sh

(Windows) ORACLE_HOME\oracle_common\common\/bin\wlst.cmd

2. 管理サーバー・インスタンスに接続します。
connect('<userName', '<password>', '<host>:<port>')

3. ohs_postUpgradeカスタムWLSTコマンドを実行します。次に例を示します。
ohs_postUpgrade()

第II部 Oracle HTTP Serverのアップグレード(以前の12cリリースから)

第II部は、次の章で構成されます。

- スタンドアロンOracle HTTP Serverのアップグレード(以前の12cリリースから)
この章では、スタンドアロンOracle HTTP Serverを以前のスタンドアロンOracle HTTP Server 12cリリースから最新の12cにアップグレードするためのプロセスについて説明します。

- 管理対象Oracle HTTP Serverのアップグレード(以前の12cリリースから)
この章では、管理対象Oracle HTTP Serverを以前の12cリリースから最新の12cリリースにアップグレードするための手順について説明します。このアップグレードの有効な開始ポイントは、12cのリリース12.1.2以降です。

5 スタンドアロンOracle HTTP Serverのアップグレード(以前の12cリリースから)

この章では、スタンドアロンOracle HTTP Serverを、以前のスタンドアロンOracle HTTP Server 12cリリースから最新の12cにアップグレードするプロセスについて説明します。

注意:

この章の情報は、『Oracle Fusion Middleware Oracle Fusion Middlewareのアップグレードのプランニング』のOracle Fusion Middleware 12c (12.2.1.2)のアップグレードのプランニングに関する項にリストされている必須のアップグレード前タスクについて理解して実行していることを前提としています。

この章の構成は、次のとおりです。

- スタンドアロンOracle HTTP Serverのアップグレード・プロセス(以前の12cリリースから)について
Oracle HTTP Serverのアップグレード・プロセスの概要に関するフローチャートとロードマップを再確認します。

- スタンドアロンOracle HTTP Serverのインストール
アップグレードの開始前に、Oracle HTTP Server 12c (12.2.1.2)ディストリビューションをターゲット・システムにダウンロードし、Oracle Universal Installerを使用してインストールします。

- サーバーとプロセスの停止
Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、すべてのプロセスと管理サーバーや管理対象サーバーを含めたすべてのサーバーを停止する必要があります。

- ドメインの再構成
再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.2)にあわせて再構成します。

- スタンドアロン・システム・コンポーネント構成のアップグレード
エージェントがOPMNで管理されている場合は、Upgrade Assistantを使用して、スタンドアロン・エージェントのコンポーネント構成をアップグレードします。スタンドアロン・コンポーネント構成のアップグレードは、OPMNで管理されていないスタンドアロン・エージェントのアップグレードをサポートしていません。

- アップグレードの検証
ノード・マネージャとスタンドアロンOracle HTTP Serverが正常に起動できることを確認することで、アップグレードが成功していることを検証できます。

- サーバーとプロセスの起動
アップグレードが正常に完了したら、すべてのプロセスと管理サーバーや管理対象サーバーを含めたすべてのサーバーを再起動します。

親トピック: Oracle HTTP Serverのアップグレード(以前の12cリリースから)

5.1 スタンドアロンOracle HTTP Serverのアップグレード・プロセス(以前の12cリリースから)について

Oracle HTTP Serverのアップグレード・プロセスの概要に関するフローチャートとロードマップを再確認します。

図5-1は、別の12cリリースを開始ポイントとするスタンドアロンOracle HTTP Serverのアップグレードに関する手順の概要を示しています。各手順で使用するツールのリストも示します。

図5-1 スタンドアロンOracle HTTP Serverのアップグレード・プロセス・フローチャート(以前の12cリリースから)

次の表は、スタンドアロンOracle HTTP Serverを以前の12cリリースから最新バージョンにアップグレードするために実行する必要があるタスクについて説明しています。

表5-1 スタンドアロンOracle HTTP Serverをアップグレードするためのタスク(以前の12cリリースから)

タスク

説明

必須

スタンドアロンOracle HTTP Serverをアップグレードしていることを確認します。

既存の環境にどの種類のOracle HTTP Serverが含まれるかを判断するには、Oracle HTTP Serverがスタンドアロンか管理対象(コロケート)かの判断を参照してください。

必須

アップグレード前のタスクを実行します。

アップグレード前タスクには、ご使用の本番環境のクローニング、システム要件および資格証明の確認、未使用データのパージおよび非SYSDBAユーザーの作成が含まれます。

アップグレード前タスクの完全なリストは、Oracle HTTP Serverのアップグレードの準備を参照してください。

必須

スタンドアロンOracle HTTP Serverをインストールします。

インストール・プログラムを実行してソフトウェアをインストールします。インストール・タイプスタンドアロンOracle HTTP Server (WebLogic Serverとは切り離して管理)を選択します。これによって、ソフトウェアをシステムに転送し、新しいOracleホーム・ディレクトリを作成します。

スタンドアロンOracle HTTP Serverのインストールを参照してください。

必須

12c環境を停止します。

「サーバーとプロセスの停止」を参照

必須

既存のドメインを再構成します。

再構成ウィザードを12c Oracle HTTP Serverインストールから実行して、既存のドメインを再構成します。

「ドメインの再構成」を参照してください。

必須

スタンドアロンのシステム・コンポーネント構成をアップグレードします。

「スタンドアロン・システム・コンポーネント構成のアップグレード」を参照してください。

必須

サーバーおよびプロセスを再起動します。

「サーバーとプロセスの起動」を参照してください。

必須

アップグレードを検証します。

Oracle HTTP Serverが予期したとおりの機能を続行しているはずです。アップグレード後の問題がある場合は、インストールのトラブルシューティングを実行してアップグレードを再試行する必要があります。

『Oracle Fusion Middleware Oracle HTTP Serverの管理』のOracle HTTP Serverのトラブルシューティングに関する項。

5.2 スタンドアロンOracle HTTP Serverのインストール

アップグレードの開始前に、Oracle HTTP Server 12c (12.2.1.2)ディストリビューションをターゲット・システムにダウンロードし、Oracle Universal Installerを使用してインストールします。

スタンドアロンOracle HTTP Serverをインストールする手順は次のとおりです。

1. 12c (12.2.1.2)製品のディストリビューションをインストールするターゲット・システムにログインします。

2. Oracle Technology NetworkまたはOracle Software Delivery Cloudから、ターゲット・システムに次をダウンロードします。

- Oracle HTTP Server (UNIX: fmw_12.2.1.2.0_ohs_linux64.bin)、(Windows: setup_fmw_12.2.1.2.0_ohs_win64.exe)

3. 12c (12.2.1.2)製品のディストリビューションをダウンロードしたディレクトリに移動します。

4. 使用するマシンが次の要件を満たしていることを確認します。

- システム、パッチ、カーネルおよびその他の要件が、「システム環境の検証ロードマップ」で指定されている要件を満たしていることを確認します。

- Oracle HTTP Serverはデフォルトではポート7777にインストールされるので、ノード上のどのサービスでもポート7777を使用していないことを確認する必要があります。このポートが使用されているかどうかを確認するには、Oracle HTTP Serverをインストールする前に次のコマンドを実行します。このポートが使用されている場合は、解放する必要があります。
netstat -an | grep 7777

5. 次のコマンドを入力して、インストール・プログラムを開始します。
(UNIX) ./fmw_12.2.1.2.0_ohs_linux64.bin

(Windows) setup_fmw_12.2.1.2.0_ohs_win64.exe

6. UNIXオペレーティング・システムでは、このホストにOracle製品を初めてインストールする場合に、「インストール・インベントリの設定」画面が表示されます。
中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システム・グループ名に中央インベントリの場所への書込み権限があることを確認し、「次へ」をクリックします。

注意:
「インストール・インベントリの設定」画面は、Windowsオペレーティング・システムでは表示されません。

7. 「ようこそ」画面で、情報をレビューしてすべての前提条件を満たしていることを確認します。「次へ」をクリックします。

8. 「自動更新」画面で、「自動更新をスキップ」を選択します。オプションは次のとおりです。

- この時点でソフトウェアの更新をシステムで確認しないようにする場合は、「自動更新をスキップ」を選択します。

- パッチ・ファイルをダウンロードした場合は、「ディレクトリからパッチを選択」を選択して、ローカル・ディレクトリに移動します。

- My Oracle Supportアカウントを持っている場合にソフトウェアの更新を自動でダウンロードするには、「My Oracle Supportで更新を検索」を選択します。Oracle Supportの資格証明を入力して、「検索」をクリックします。インストーラがMy Oracle Supportにアクセスするようにプロキシ・サーバーを構成するには、「プロキシ設定」をクリックします。「接続のテスト」をクリックして接続をテストします。

「次へ」をクリックします。

9. 「インストールの場所」画面でOracleホーム・ディレクトリの場所を指定して、「次へ」をクリックします。
ここでは、スタンドアロン・ドメインにOracle HTTP Serverの標準的なインストール・トポロジを使用してインストールを行っているため、Oracleホーム・ディレクトリを任意に指定できます。ただしこのソフトウェアを確実に、新規のOracleホームにインストールしてください。

Oracle Fusion Middlewareのディレクトリ構造の詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareのインストールのプランニング』のインストールおよび構成のためのディレクトリの選択に関する項を参照してください。

10. 「インストール・タイプ」画面で、「スタンドアロンHTTPサーバー(WebLogic Serverとは切り離して管理)」を選択し、「次へ」をクリックします。

11. 「前提条件チェック」画面で、ホスト・コンピュータを分析して、特定のオペレーティング・システムの前提条件を満たしているか確認します。
確認されたタスクのリストを表示するには、「正常なタスクの表示」を選択します。ログの詳細を表示するには、「ログの表示」を選択します。前提条件のチェックが失敗すると、エラー・メッセージが画面の下方に表示されます。エラーを修正し、「再実行」をクリックして再試行します。エラー・メッセージや警告メッセージを無視してインストールを続けるには、「スキップ」をクリックします(非推奨)。

12. Oracle Supportアカウントを持っている場合は、「セキュリティ更新」画面で、セキュリティ更新を受け取る方法を指定します。
Oracle Supportアカウントを所持しておらずこの手順を省略してもかまわない場合は、チェック・ボックスの選択を解除して、後続のダイアログ・ボックスで選択内容を確認します。

13. 「インストール・サマリー」画面で、選択したインストール・オプションを確認します。
これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を入力します。レスポンス・ファイルには、入力したすべての情報が収集して格納され、後で(コマンドラインから)サイレント・インストールを実行するために使用できます。
「インストール」をクリックしてインストールを開始します。

14. 「インストールの進行状況」画面で、プログレス・バーが100%完了になったら、「終了」をクリックしてインストーラを閉じるか、「次へ」をクリックしてサマリーを表示します。

15. 「インストール完了」画面に、インストールの場所と、インストールされた機能セットが表示されます。情報を確認し、「終了」をクリックしてインストーラを閉じます。

これで、Oracle HTTP Serverのスタンドアロン・モードでのインストールが完了しました。

5.3 サーバーとプロセスの停止

Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、すべてのプロセスと管理サーバーや管理対象サーバーを含めたすべてのサーバーを停止する必要があります。

Oracle Fusion Middleware環境は、1つのOracle WebLogic Serverドメイン、1つの管理サーバー、複数の管理対象サーバー、Javaコンポーネント、システム・コンポーネント(Identity Managementのコンポーネントなど)およびメタデータのリポジトリとして使用する1つのデータベースで構成できます。コンポーネントは相互に依存していることがあるため、適切な順序で停止する必要があります。

注意:
この項の手順では、WLSTコマンドライン・ユーティリティまたはスクリプトを使用してサーバーとプロセスを停止する方法について説明します。また、Oracle Fusion Middleware ControlとOracle WebLogic Server管理コンソールを使用することもできます。『Oracle Fusion Middleware Oracle Fusion Middlewareの管理』の管理サーバー、管理対象サーバーおよびノード・マネージャの起動および停止に関する項を参照してください。

Fusion Middleware環境を停止するには、次に示す手順を実行します。

ステップ1: システム・コンポーネントを停止する

Oracle HTTP Serverなどのシステム・コンポーネントを停止するには、stopComponentスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

システム・コンポーネントは任意の順序で停止できます。

ステップ2: 管理対象サーバーを停止する

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

- (UNIX) DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url

- (Windows) DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url

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

ステップ3: Oracle Identity Managementのコンポーネントを停止するOracle Internet Directoryなど、Oracle Identity Managementコンポーネントを停止します。

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

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

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

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

- (UNIX) DOMAIN_HOME/bin/stopWebLogic.sh

- (Windows) DOMAIN_HOME\bin\stopWebLogic.cmd

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

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

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

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

5.4 ドメインの再構成

再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.2)にあわせて再構成します。

WebLogic Serverドメインを再構成すると、ドメイン内のアプリケーションに応じて、次の項目が自動的に更新されます。

- WebLogic Serverコア・インフラストラクチャ

- ドメイン・バージョン

注意:

ドメインの再構成を開始する前に、次の制限事項に注意してください。

- 再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。

- アップグレード・プロセス中に、非動的クラスタ・ドメインを動的クラスタ・ドメインに変換することはサポートされていません。
動的クラスタ機能は、再構成ウィザードの実行中に使用できますが、サポートされているアップグレードは非動的クラスタのアップグレードのみで、その後で動的クラスタを追加することになります。アップグレード・プロセス中に動的クラスタを追加することはできません。

具体的には、ドメインを再構成する場合、次のことが発生します。

- ドメインのconfig.xmlファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンに更新されます。

- すべてのインストール済Oracle製品の再構成テンプレートは、自動的に選択されてドメインに適用されます。これらのテンプレートは、WebLogicドメインが現在のWebLogic Serverバージョンと互換性を持つために必要な再構成タスクを定義します。

- 起動スクリプトが更新されます。
変更済の起動スクリプトを維持する場合は、そのスクリプトをバックアップしてから、再構成ウィザードを開始してください。

注意:
ドメインの再構成プロセスを開始すると、元に戻すことはできません。再構成ウィザードの実行前には、アップグレード前チェックリストで説明しているように、ドメインのバックアップが作成されていることを確認してください。再構成ウィザードの実行中にエラーまたは他の割込みが発生した場合、バックアップ場所から元のドメイン・ディレクトリにファイルとディレクトリをコピーすることによって、ドメインをリストアする必要があります。これは、再構成前の元の状態にドメインを復元するための唯一の方法です。

再構成ウィザードを使用して既存のドメインを再構成する手順に従います。ドメインの再構成の一般情報は、『Oracle Fusion Middleware Oracle WebLogic Serverのアップグレード』のWebLogicドメインの再構成に関する項を参照してください。

- ドメインのバックアップ

- 再構成ウィザードの起動

- 再構成ウィザードを使用した既存のドメインの再構成
再構成ウィザードの各画面を通じて既存のドメインを再構成します。

5.4.1 ドメインのバックアップ

再構成ウィザードの実行前に、ドメイン・ディレクトリのバックアップ・コピーを作成します。

ドメイン・ディレクトリのバックアップを作成するには:

1. コンテンツを保持するには、ソース・ドメインを別の場所にコピーします。
たとえば、C:\domains\mydomainをC:\domains\mydomain_backupにコピーします。

2. 各リモート管理対象サーバーのドメインを更新する前に、各リモート・マシンのドメイン・ディレクトリのバックアップ・コピーを作成します。

3. ドメインのバックアップしたバージョンが完全であることを確認します。

なんらかの理由でドメインの再構成が失敗した場合は、すべてのファイルおよびディレクトリをバックアップ・ディレクトリから元のドメイン・ディレクトリにコピーしてドメインを完全に再構成前の元の状態に戻す必要があります。

5.4.2 再構成ウィザードの起動

再構成ウィザードをグラフィカル・モードで起動する手順は次のとおりです。

1. ドメインが存在するシステムにサインインします。

2. コマンド・シェル(UNIXオペレーティング・システムの場合)またはコマンド・プロンプト・ウィンドウ(Windowsオペレーティング・システムの場合)を開きます。

3. エディション・ベースのデータベース・ユーザーのみ: スキーマがEBRデータベースを使用して構成されている場合、再構成ウィザードを実行する前に、手動でデフォルトのエディション名を設定する必要があります。
次のSQLコマンドを実行して、デフォルト・エディションを設定します。
ALTER DATABASE DEFAULT EDITION = edition_name;

edition_nameは、子エディションの名前です。

4. oracle_common/common/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/common/bin

- (Windows) ORACLE_HOME\oracle_common\commom\bin

5. 次に示すロギングオプションを指定して、再構成ウィザードを開始します。

- (UNIX) ./reconfig.sh -log=log_file -log_priority=ALL

- (Windows) reconfig.cmd -log=log_file -log_priority=ALL

log_fileは、ドメイン再構成セッション用に作成するログ・ファイルの絶対パスです。これは、再構成処理をトラブルシューティングする必要がある場合に役立つことがあります。

パラメータ-log_priority=ALLにより、ログは詳細モードで記録されるようになります。

注意:

このコマンドを実行すると、デフォルトのキャッシュ・ディレクトリが無効であることを示す次のエラー・メッセージが表示される場合があります。

*sys-package-mgr*: can't create package cache dir

環境変数CONFIG_JVM_ARGSを設定することでキャッシュ・ディレクトリを変更できます。次に例を示します。

CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

5.4.3 再構成ウィザードを使用した既存のドメインの再構成

再構成ウィザードの各画面を通じて、既存のドメインを再構成します。

再構成ウィザードを使用してドメインを再構成するには:

1. 「ドメインの選択」画面でアップグレードするドメインの場所を指定するか、「参照」をクリックして移動し、ドメイン・ディレクトリを選択します。「次へ」をクリックします。

2. 「再構成セットアップの進行状況」画面で、セットアップ・プロセスの進行状況を確認します。完了したら、「次へ」をクリックします。
このプロセスでは次の処理が行われます。

- Fusion Middleware製品を含む、インストール済製品の再構成テンプレートが自動的に適用されます。これにより、config.xml、config-groups.xml、security.xmlなどの様々なドメイン構成ファイルが更新されます。

- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

- ドメイン・アップグレードが検証されます。

3. 「ドメイン・モードおよびJDK」画面で、ドメインで使用するJDKを選択するか、「参照」をクリックして使用するJDKに移動します。12c (12.2.1.2)のサポート対象JDKバージョンは、1.8.0_101以降です。「次へ」をクリックします。

注意:
ここでは「ドメイン・モード」は変更できません。

特定のプラットフォームでサポートされているJDKのリストは、Oracle Fusion Middlewareでサポートされているシステム構成を参照してください。

4. 「JDBCデータ・ソース」画面で、ドメイン・ソースで定義したJDBCデータ・ソースを構成します。
ドメインを作成する製品に関連付けられるJDBCデータ・ソースは、画面の下半分にリスト表示されます。JDBCデータ・ソースには、データ・ソース・インスタンスの作成時、デプロイ時もしくはターゲット指定時、またはサーバー起動時に作成されるデータベース接続のプールが含まれます。 アプリケーションはJNDIツリーでデータ・ソースをルックアップしてから、接続をリクエストします。アプリケーションに接続する必要がなくなった場合は、接続がデータ・ソースの接続プールに戻されます。

「データソース名」ドロップダウン・リストから、設定を指定するデータ・ソースを選択します。指定した値は、選択されたデータ・ソースのデータ・ソース・リストの適切な列に表示されます。

データ・ソースがOracle RAC構成の場合は、次の3つのオプションのいずれかを選択できます。

- GridLinkへ変換

- RACマルチ・データ・ソースへ変換

- 変換しない

各オプションの詳細は、「ヘルプ」をクリックしてください。

詳細を指定したら、「次へ」をクリックします。

「JDBCデータ・ソース」画面でデータ・ソースを選択しないと、次に示す警告が表示されます。

ドライバがありません

「OK」をクリックして検証せずに続行するか、「取消」をクリックして「JDBCデータ・ソース」ページに戻ります。

この場合、「OK」をクリックしてもデータ・ソースは検証されません。

5. 「JDBCデータ・ソース・テスト」画面で、「JDBCデータ・ソース」画面で構成したデータ・ソース接続のチェック・ボックスを選択し、「選択された接続のテスト」をクリックしてデータ・ソース接続をテストします。

注意:
データベース接続をテストするには、接続するデータベースが起動している必要があります。接続をテストしない場合は、データ・ソースを選択しません。「次へ」をクリックして続行します。

6. 「データベース構成タイプ」画面で、「RCUデータ」を選択して、サーバー表(_STB)スキーマに接続します。
RCUサービス表(_STB)スキーマ資格証明を使用してデータベース接続の詳細を入力して、「RCU構成の取得」をクリックします。

再構成ウィザードは、この接続を使用してドメイン内のコンポーネントに必要なデータ・ソースを自動的に構成します。
注意: 既存の11gデータ・ソースの場合、再構成では既存の値が保存されます。RCUで12c用にスキーマが作成された新しいデータ・ソースの場合、デフォルトの接続データは_STBスキーマから取得されます。特定のスキーマの接続データが_STBスキーマにない場合は、デフォルトの接続データが使用されます。

チェックに成功したら、「次へ」をクリックします。チェックが失敗した場合は、接続の詳細を正しく入力し直して再試行します。

7. 「JDBCコンポーネント・スキーマ・テスト」画面で、すべてのコンポーネント・スキーマを選択して「選択された接続のテスト」をクリックして、各スキーマの接続をテストします。テストの結果は、「ステータス」列に表示されます。
チェックが終了したら、「次へ」をクリックします。

8. 「ノード・マネージャ」画面は、再構成するドメインで、ホストごとのノード・マネージャが使用されている場合にのみ表示されます。
「ノード・マネージャ」画面で、再構成したドメインで使用するノード・マネージャ構成を選択します。結果として生成される構成は、「ノード・マネージャ・タイプ」および「ノード・マネージャ構成」で選択したオプションの組合せに応じて異なります。

表5-2 ノード・マネージャ画面のフィールドの説明

オプション

説明

ドメインごとのデフォルトの場所

このオプションを選択すると、ノード・マネージャ・ホームはDOMAIN_NAME/nodemanagerに再定義され、ノード・マネージャ・ホームの編集ができなくなります。

ドメインごとのカスタムの場所

このオプションは、このドメインの特定の場所に、ドメインごとのノード・マネージャ構成ファイルを作成する場合に選択します。「ノード・マネージャ・ホーム」フィールドでディレクトリを指定するか、「参照」をクリックしてナビゲーション・ツリーを使用してその場所を選択します。指定するディレクトリは空である必要があります。このディレクトリに、nodemanager.propertiesおよびnodemanager.domainsファイルが作成されます。

ノード・マネージャ・ホーム

ドメインごとのカスタムの場所オプションを選択した場合は、「参照」をクリックして、ドメインごとのノード・マネージャ構成の格納に使用するディレクトリの場所に移動します。

手動ノード・マネージャ・セットアップ

このオプションを選択した場合は、ドメインのノード・マネージャ構成の作成がスキップされ、残りのフィールドはすべて変更できなくなるため、ドメインでノード・マネージャを使用する場合はノード・マネージャ構成の実行の説明に従って、ノード・マネージャを手動で構成する必要があります。再構成されたドメインでは、ホストごとのノード・マネージャ構成が引き続き使用されます。

既存のドメインがノード・マネージャを使用するように構成されておらず、再構成されたドメインでノード・マネージャを使用しない場合も、このオプションを選択する必要があります。

ノード・マネージャ構成の詳細は、『Oracle WebLogic Serverノード・マネージャの管理』を参照してください。

ノード・マネージャ構成

次の2つのオプションから1つを選択します。「手動ノード・マネージャ・セットアップ」を選択した場合は、次のフィールドを使用できません。

新規構成の作成

nodemanager.propertiesのデフォルトの設定を使用して、再構成されたドメインに、ドメインごとのノード・マネージャ構成が自動的に作成されます。ドメインが正常に再構成された後に、必要に応じて、nodemanager.propertiesを変更できます。

既存の構成を移行

すでに存在するホストごとのノード・マネージャ構成が、再構成されたドメインのドメインごとの構成に移行されます。これには、ListenAddress、ListenPort、StartScriptName、JavaHomeおよびLogFileの環境固有の設定は含まれません。

ノード・マネージャ・ホーム

「既存の構成を移行」オプションを選択した場合は、再構成したドメインの移行先にするノード・マネージャのホーム・ディレクトリを入力するか、参照してください。

Oracle推奨デフォルトの適用

このチェック・ボックスは、「既存の構成を移行」オプションを選択した場合に、nodemanager.propertiesファイルに指定されているOracle推奨のデフォルトを使用するときに選択します。移行されるnodemanager.propertiesファイルの設定を引き続き使用する場合は、このチェック・ボックスの選択を解除してください。

推奨されるプロパティのデフォルト値は次のとおりです。

LogLimit=0
AuthenticationEnabled=true
LogLevel=INFO
DomainsFileEnabled=true
NativeVersionEnabled=true
LogToStderr=true
SecureListener=true
LogCount=1
StopScriptEnabled=false
QuitEnabled=false
LogAppend=true
StateCheckInterval=500
CrashRecoveryEnabled=false
StartScriptEnabled=true
LogFormatter=weblogic.nodemanager.server.LogFormatter
ListenBacklog=50

ノード・マネージャ資格証明: ユーザー名、パスワード

再構成されたドメインで、ノード・マネージャの起動に使用するユーザー名とパスワードを指定します。

9. 「拡張構成」画面で、拡張構成を実行するすべてのカテゴリを選択できます。選択したカテゴリごとに、詳細構成を行うことができる適切な構成画面が表示されます。

注意:
「拡張構成」画面に表示されるカテゴリは、ドメインで選択したテンプレートに定義されているリソースによって異なります。

このアップグレードでは、オプションを選択せずに「次へ」をクリックします。

10. 「構成のサマリー」画面で、ドメインの詳細な構成を確認してから続行します。
「表示」ドロップダウン・リストからフィルタ・オプションを選択すると、右側のパネルに表示される項目を制限できます。

構成を変更するには、「戻る」をクリックして適切な画面に戻ります。ドメインを再構成するには、「再構成」をクリックします。

注意:
ドメインの再構成時には、ドメインの場所は変更されません。

11. 「再構成の進行状況」画面に、再構成プロセスの進行状況が表示されます。
このプロセスでは次の処理が行われます。

- ドメイン情報が抽出、保存および更新されます。

- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

プログレス・バーに100%が表示されたら、「次へ」をクリックします。

12. 「構成の終了」画面に、再構成プロセスが成功して完了したか、または失敗したかどうかが示されます。管理サーバーURL(リスニング・ポートを含む)とともに再構成されたドメインの場所も表示します。再構成が成功した場合は、「Oracle Weblogic Serverの再構成に成功しました」と表示されます。
再構成プロセスが正常に完了しなかった場合は、その理由を示すエラー・メッセージが表示されます。問題を解決するための適切な措置を講じます。問題を解決できない場合は、My Oracle Supportに連絡してください。

今後の操作での使用に備えて、ドメインの場所と管理サーバーのURLを記録しておきます。

5.5 スタンドアロン・システム・コンポーネント構成のアップグレード

エージェントがOPMNで管理されている場合は、Upgrade Assistantを使用して、スタンドアロン・エージェントのコンポーネント構成をアップグレードします。スタンドアロン・コンポーネント構成のアップグレードは、OPMNで管理されていないスタンドアロン・エージェントのアップグレードをサポートしていません。

- Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade Assistantは非SYSDBAとして実行して、一度にアップグレードするドメインは1つにすることをお薦めします。

- Upgrade Assistantを使用したスタンドアロン・システム・コンポーネント構成のアップグレード
Upgrade Assistantの各画面を通じて、スタンドアロンのシステム・コンポーネント構成をアップグレードします。

- ドメイン固有コンポーネント構成のアップグレードの確認
ドメイン固有コンポーネント構成のアップグレードが成功したことを確認するには、管理コンソールおよびFusion Middleware Controlにログインし、各コンポーネントのバージョン番号が12.2.1.2であることを確認します。

5.5.1 Upgrade Assistantの起動

Upgrade Assistantを実行して、製品のスキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade Assistantは非SYSDBAとして実行して、一度にアップグレードするドメインは1つにすることをお薦めします。

Upgrade Assistantを起動するには、次の手順に従います。

1. oracle_common/upgrade/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. Upgrade Assistantを起動します。

- (UNIX) ./ua

- (Windows) ua.bat

コマンドラインに指定可能なその他のパラメータ(ロギングのパラメータなど)の詳細は、次を参照してください。

- Upgrade Assistantパラメータ

5.5.1.1 Upgrade Assistantパラメータ

コマンドラインからUpgrade Assistantを起動する際に、追加のパラメータを指定できます。

表5-3 Upgrade Assistantコマンドライン・パラメータ

パラメータ

必須/省略可能

説明

-readiness

準備状況チェックの場合は必須
注意: スタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では準備状況チェックを実行できません。

アップグレードの準備状況チェックを実行します(実際のアップグレードは実行しません)。

スキーマと構成がチェックされます。

-examineパラメータを指定した場合は、このパラメータを指定しないでください。

-threads

省略可能

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を特定します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須

レスポンス・ファイルに保存した入力を使用して、Upgrade Assistantを実行します。このレスポンス・ファイルは、GUIモードでUpgrade Assistantを実行したときの入力データから生成されます。このパラメータを使用すると、Upgrade Assistantがサイレント・モードで(Upgrade Assistant画面を表示せずに)実行されます。

-examine

省略可能

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel attribute

省略可能

次のいずれかの属性を指定して、ログイン・レベルを設定します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

デフォルトのロギング・レベルはNOTIFICATIONです。

-logLevel TRACE属性を設定して、より多くのログが記録されるようにすることを検討してください。これは、アップグレードの失敗をトラブルシューティングする際に役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir location

省略可能

アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。既存の書込み可能なディレクトリを指定する必要があります。Upgrade Assistantは、このディレクトリにログ・ファイルと一時ファイルを作成します。

デフォルトの場所は次のとおりです。

UNIXの場合:

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

Windowsの場合:

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

省略可能

すべてのコマンドライン・オプションを表示します。

5.5.2 Upgrade Assistantを使用したスタンドアロン・システム・コンポーネント構成のアップグレード

Upgrade Assistantの各画面を通じて、スタンドアロンのシステム・コンポーネント構成をアップグレードします。

Upgrade Assistantを使用して既存の12cドメインをアップグレードするには:

1. 「ようこそ」画面には、Upgrade Assistantの概要と、アップグレード前のいくつかの重要なタスクについての情報が示されます。「次へ」をクリックします。

注意:
Upgrade Assistantの画面の詳細は、画面上の「ヘルプ」をクリックしてください。

2. 「スタンドアロン・コンポーネント」画面で、「スタンドアロン・システム・コンポーネント構成」を選択します。
「既存のドメインの更新」を選択し、既存の12cドメインの場所を「ドメイン・ディレクトリ」フィールドに入力します。「参照」ボタンをクリックして、ナビゲーション・ツリーを使用して既存のドメイン・ディレクトリを選択することもできます。「次へ」をクリックします。

注意:

- 「新規ドメインの作成」オプションは、バージョン11gからアップグレードする場合にのみ使用してください。

- アップグレードした11gシステム・コンポーネント用に新しい12cスタンドアロン・ドメインをすでに作成している場合、「既存のドメインの更新」オプションを使用して、スタンドアロンOracle HTTP Serverを備えたスタンドアロン・ドメインを拡張できます。

- 「既存のドメインの更新」オプションは、以前の12cリリース(12.1.2.0、12.1.3.0、12.2.1.0および12.2.1.1)から最新の12cリリース(12.2.1.2)にアップグレードする場合にのみ使用します。

3. 「コンポーネント・リスト」画面で、構成をアップグレードするコンポーネントがリストにすべて含まれていることを確認し、「次」をクリックします。
アップグレードするコンポーネントがリストに含まれていない場合は、「戻る」をクリックして前の画面に戻り、別のドメインを指定します。

4. 「前提条件」画面で、すべてのチェック・ボックスを選択して、前提条件を満たしていることを確認します。「次へ」をクリックします。

注意:
Upgrade Assistantでは、前提条件が満たされているかどうかの確認は行われません。

5. 「インスタンス・ディレクトリ」画面で、「12cソース」を選択して「次」をクリックします。
以前の12cリリースから最新の12cリリースにアップグレードする場合は、Oracleインスタンス・ディレクトリの入力は必要ありません。

6. 「調査」画面で、各スタンドアロン・コンポーネントを調査したUpgrade Assistantのステータスを確認して、スタンドアロン・コンポーネントのアップグレードの準備が整っていることを検証します。ステータスが「調査が終了しました。」になっている場合は、「次」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認します。一般的なアップグレード・エラーの解決方法の詳細は、Oracle Fusion Middleware Upgrade Assistantによるアップグレードのアップグレード・ガイドのアップグレードのトラブルシューティングに関する項を参照してください。

注意:

- 確認フェーズ中に検出された問題を、アップグレードを進めずに解決した場合は、バックアップからリストアを再び行わずにUpgrade Assistantを開始できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックしてアップグレードを続行していた場合は、Upgrade Assistantを再開する前に、バックアップからアップグレード前の環境をリストアする必要があります。

- 調査プロセスを取り消しても構成データに影響はありませんが、将来のアップグレード・セッションでは、Upgrade Assistantが収集した情報の再収集が必要になります。

7. 「アップグレード・サマリー」画面で、コンポーネント構成のアップグレードに選択したオプションのサマリーを確認します。
レスポンス・ファイルには、入力したすべての情報が収集および格納されます。このファイルにより、その後のサイレント・アップグレードの実行が可能になります。サイレント・アップグレードは、Upgrade Assistantとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。
「アップグレード」をクリックして、アップグレード・プロセスを開始します。

8. 「アップグレードの進行状況」画面で、アップグレードのステータスを監視します。

注意:
アップグレード・アシスタントにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。これを行うと、環境が不安定になる可能性があります。

正しくアップグレードされていないコンポーネントがある場合は、Upgrade Assistantのログ・ファイルで情報を確認します。

注意:
この画面のプログレス・バーには、現在のアップグレード手順の進行状況が表示されます。アップグレードの残り時間を示すものではありません。

「次へ」をクリックします。

9. アップグレードが成功した場合: 「アップグレード成功」画面で、「閉じる」をクリックし、アップグレードを完了してウィザードを閉じます。新規インストールでコンポーネントを機能させるために手動で実行する必要のあるタスクが、アップグレード後のアクションのウィンドウに表示されます。このウィンドウは、コンポーネントにアップグレード後の手順がある場合にのみ表示されます。

アップグレードが失敗した場合: 「アップグレード失敗」画面で、「ログの表示」をクリックし、エラーを表示してトラブルシューティングします。ログは、ORACLE_HOME/oracle_common/upgrade/logsにあります。アップグレードが失敗した場合は、アップグレード前の環境をバックアップからリストアし、問題を修正してから、Upgrade Assistantを再起動する必要があります。

5.5.3 ドメイン固有コンポーネント構成のアップグレードの確認

ドメイン固有コンポーネント構成のアップグレードが成功したことを確認するには、管理コンソールおよびFusion Middleware Controlにログインし、各コンポーネントのバージョン番号が12.2.1.2になっていることを確認します。

管理コンソールにログインするには、次に移動します: http://administration_server_host:administration_server_port/console

Fusion Middleware Controlにログインするには、次に移動します: http://administration_server_host:administration_server_port/em

注意:

アップグレード後、管理ツールは、前のOracleホームではなく新しい12cのOracleホームから必ず実行してください。

アップグレード・プロセス時に、一部のOWSMドキュメント(ポリシー・セット、ポリシーおよびアサーション・テンプレートなどの事前定義ドキュメント)のアップグレードが必要な場合があります。ポリシー・セットまたは事前定義ドキュメントがアップグレードされると、バージョン番号が1増分されます。

5.6 アップグレードの確認

ノード・マネージャおよびスタンドアロンOracle HTTP Serverを正しく起動できれば、アップグレードが成功したことを確認できます。

アップグレード後の問題が発生した場合は、インストールのトラブルシューティングを実行してアップグレードを再試行する必要があります。詳細は、Oracle HTTP Server管理者ガイドのOracle HTTP Serverのトラブルシューティングを参照してください。

新しくアップグレードした環境を起動できない場合は、OracleウォレットでMD5証明書を使用していることが原因になっている可能性があります。MD5署名を使用しているかどうかのチェックの手順およびSHA-2証明書に置き換える手順については、「SHA-2アルゴリズムを使用して署名された証明書でMD5アルゴリズムを使用して署名された証明書を置き換え」を参照してください。

- ノード・マネージャの起動
WebLogic Serverの本番環境では、サーバー・インスタンスが複数のドメイン、マシンおよび地理的な場所にまたがって分散することがよくあります。ノード・マネージャは、Oracle HTTP Serverインスタンスの管理(起動、停止および再起動)に使用できるWebLogic Serverユーティリティです。

- スタンドアロンOracle HTTP Serverの起動
アップグレード後に、スタンドアロンOracle HTTP Serverを起動します。

5.6.1 ノード・マネージャの起動

WebLogic Serverの本番環境では、サーバー・インスタンスが複数のドメイン、マシン、および地理的な場所にまたがって分散することがよくあります。ノード・マネージャは、Oracle HTTP Serverインスタンスの管理(起動、停止および再起動)に使用できるWebLogic Serverユーティリティです。

Windowsオペレーティング・システムでは、ノード・マネージャをスタートアップ・サービスとして、ノード・マネージャを構成することをお薦めします。これによって、システムが再起動されるたびに、ノード・マネージャが自動で起動されます。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverノード・マネージャの管理』の起動サービスとしてのノード・マネージャの実行に関する項を参照してください。

注意:
UNIXプラットフォームでは、ノード・マネージャをルート・ユーザーとして実行しないでください。

5.6.2 スタンドアロンOracle HTTP Serverの起動

アップグレード後に、スタンドアロンOracle HTTP Serverを起動します。

スタンドアロンOracle HTTP Serverを起動する手順は次のとおりです。

1. oracle_common/upgrade/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. スタンドアロンのサーバーを起動するコマンドを入力します。
UNIXオペレーティング・システムの場合: e

./startComponent.sh ohs_name

Windowsオペレーティング・システムの場合:

startComponent.cmd ohs_name

詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareの管理』のシステム・コンポーネントの起動と停止に関する項を参照してください。

5.7 サーバーとプロセスの起動

アップグレードが正常に完了したら、すべてのプロセスと管理サーバーや管理対象サーバーを含めたすべてのサーバーを再起動します。

コンポーネントは相互に依存していることがあるため、適切な順序で起動する必要があります。

注意:
この項の手順では、WLSTコマンドラインまたはスクリプトを使用してサーバーとプロセスを起動する方法について説明します。また、Oracle Fusion Middleware ControlとOracle WebLogic Server管理コンソールを使用することもできます。『Oracle Fusion Middlewareの管理』の管理サーバーと管理対象サーバーおよびノード・マネージャの起動と停止に関する項を参照してください。

Fusion Middleware環境を起動するには、次に示す手順を実行します。

ステップ1: 管理サーバーの起動

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

管理サーバーを起動するには、startWebLogicスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/startWebLogic.sh

- (Windows) DOMAIN_HOME\bin\startWebLogic.cmd

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

ステップ2: ノード・マネージャを起動する

ノード・マネージャを起動するには、startNodeManagerスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/startNodeManager.sh

- (Windows) DOMAIN_HOME\bin\startNodeManager.cmd

ステップ3: Oracle Identity Managementのコンポーネントを起動する目的の環境に含まれるOracle Identity Managementのコンポーネント(Oracle Internet Directoryなど)を起動します。

- (UNIX) DOMAIN_HOME/bin/startComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\startComponent.cmd component_name

ステップ4: 管理対象サーバーを起動する

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

- (UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

- (Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url

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

注意:
通常、管理対象サーバーを起動すると、そのサーバーにデプロイされているアプリケーションが開始されます。したがって、管理対象サーバーの起動後にアプリケーションを手動で開始する必要はありません。

ステップ5: システム・コンポーネントを起動する

Oracle HTTP Serverなどのシステム・コンポーネントを起動するには、startComponentスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/startComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\startComponent.cmd component_name

システム・コンポーネントは任意の順序で起動できます。

6 管理対象Oracle HTTP Serverのアップグレード(以前の12cリリースから)

この章では、管理対象Oracle HTTP Serverを以前の12cリリースから最新の12cリリースにアップグレードするための手順について説明します。このアップグレードの有効な開始ポイントは、12cのリリース12.1.2以降です。

この手順は、目的のシステムにインストールされ構成されている12c Fusion Middlewareインフラストラクチャ(JRFとWebLogic Server)が存在していることを前提としています。

- 管理対象Oracle HTTP Serverのアップグレード・プロセス(以前の12cリリースから)について
管理対象Oracle HTTP Serverのアップグレード・プロセスの概要に関するフローチャートとロードマップを再確認します。

- 製品ディストリビューションのインストール
アップグレードの開始前に、Oracle Fusion MiddlewareインフラストラクチャとOracle HTTP Server 12c (12.2.1.2)のディストリビューションをターゲット・システムにダウンロードし、Oracle Universal Installerを使用してインストールします。

- アップグレード前の準備状況チェックの実行
アップグレードにかかわる潜在的な問題を特定するために、アップグレード・プロセスの開始前に、準備状況チェックの実行をお薦めします。準備状況チェックによって、アップグレードにかかわる潜在的な問題をすべて検出できるわけではない点に注意してください。準備状況チェックのレポートが成功を示していても、アップグレードが失敗することもあります。

- サーバーとプロセスの停止
Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、すべてのプロセスと管理サーバーや管理対象サーバーを含めたすべてのサーバーを停止する必要があります。

- 製品スキーマのアップグレード
サーバーとプロセスの停止後、Upgrade Assistantを使用して、Oracle Fusion Middlewareの現在のリリースにあわせてサポート対象の製品スキーマをアップグレードします。

- ドメインの再構成
再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.2)にあわせて再構成します。

- ドメイン・コンポーネント構成のアップグレード
ドメインの再構成後、更新したドメイン構成と一致するように、ドメイン内でUpgrade Assistantを使用してドメイン・コンポーネント構成をアップグレードします。

- サーバーとプロセスの起動
アップグレードが正常に完了したら、すべてのプロセスと管理サーバーや管理対象サーバーを含めたすべてのサーバーを再起動します。

- アップグレードの確認
管理コンソールとEnterprise Manager Fusion Middleware Controlにログインできれば、アップグレードは正常に完了しています。

- WLSTを使用したアップグレード後のウォレットのKSSデータベースへのインポート
Upgrade Assistantを使用して以前のバージョンのOracle HTTP Serverから12c (12.2.1.2)にアップグレードする場合は、追加のウォレット管理タスクを実行する必要があります。

親トピック: Oracle HTTP Serverのアップグレード(以前の12cリリースから)

6.1 管理対象Oracle HTTP Serverのアップグレード・プロセス(以前の12cリリースから)について

管理対象Oracle HTTP Serverのアップグレード・プロセスの概要に関するフローチャートとロードマップを再確認します。

図4-1は、最新の12cリリースに管理対象Oracle HTTP Serverをアップグレードする場合のプロセス・フローを示しています。各手順で使用するツールのリストも示します。

図6-1 管理対象Oracle HTTP Serverのアップグレード・プロセス・フローチャート(11gから12c)

表6-1では、以前の12cリリースから12c (12.2.1.2)に管理対象Oracle HTTP Serverをアップグレードする際に実行する必要があるタスクについて説明します。

表6-1 管理対象Oracle HTTP Serverをアップグレードするためのタスク(以前の12cリリースから)

タスク

説明

必須

管理対象Oracle HTTP Serverをアップグレードしていることを確認します。

既存の環境にどの種類のOracle HTTP Serverが含まれるかを判断するには、Oracle HTTP Serverがスタンドアロンか管理対象(コロケート)かの判断を参照してください。

必須

このガイドの概要に関するトピックを再確認して、アップグレード前のタスクを完了します(まだ実行していない場合)。

アップグレード前タスクには、ご使用の本番環境のクローニング、システム要件および資格証明の確認、未使用データのパージおよび非SYSDBAユーザーの作成が含まれます。

アップグレード前タスクの完全なリストは、Oracle HTTP Serverのアップグレードの準備を参照してください。

必須

12.2.1.2 Fusion MiddlewareインフラストラクチャとOracle HTTP Serverのディストリビューションをダウンロードしてインストールします。

インフラストラクチャのディストリビューションには、その他のFusion Middleware製品をインストールするための基盤の設定に必要な、WebLogic ServerおよびJava Required Files (JRF)が同梱されています。

このガイドのアップグレード・トポロジに定義されているように、インフラストラクチャは新規のOracleホームにインストールする必要があります。

Oracle HTTP Serverは、12.2.1.2インフラストラクチャのインストール時に作成したOracleホームにインストールする必要があります。

「製品ディストリビューションのインストール」を参照してください。

オプション

準備状況チェックを実行します。

Upgrade Assistantを使用した準備状況チェックの実行は、アップグレード前の環境について、アップグレードの準備が整っているかどうかを判断する際に役立ちます。
完全な手順は、「アップグレード前の準備状況チェックの実行」を参照してください。

必須

12cインスタンスを停止します。

アップグレード・プロセスの開始前に、管理サーバー、管理対象サーバー、および12cインスタンスを停止します。

「サーバーとプロセスの停止」を参照

必須

Upgrade Assistantを使用して既存のスキーマをアップグレードします。

「製品スキーマのアップグレード」を参照してください。

必須

既存のドメインを再構成します。

再構成ウィザードを12c Oracle HTTP Serverインストールから実行して、既存のドメインを再構成します。

再構成ウィザードを使用した既存のドメインの再構成を参照してください。

必須

既存のドメイン構成をアップグレードします。

インストール後、Upgrade Assistantを使用してOracle HTTP Serverおよびシステム・コンポーネント・インフラストラクチャをアップグレードする必要があります。

「Upgrade Assistantを使用したドメイン・コンポーネントのアップグレード」を参照してください。

必須

サーバーおよびプロセスを再起動します。

アップグレード・プロセスは完了です。これで、管理サーバー、管理対象サーバーおよび12.2.1.2インスタンスを再起動できます。

「サーバーとプロセスの起動」を参照してください。

必須

アップグレードを検証します。

アップグレードの検証方法は、「アップグレードの確認」を参照してください。

次のアップグレード後のタスクを完了します: 「WLSTを使用したアップグレード後のウォレットのKSSデータベースへのインポート」。

6.2 製品ディストリビューションのインストール

アップグレードの開始前に、Oracle Fusion MiddlewareインフラストラクチャとOracle HTTP Server 12c (12.2.1.2)のディストリビューションをターゲット・システムにダウンロードし、Oracle Universal Installerを使用してインストールします。

注意:
Oracle Fusion Middlewareインフラストラクチャは、その他のFusion Middleware製品より前にインストールする必要があります(アップグレードにインフラストラクチャが必要な場合)。

12c (12.2.1.2)のディストリビューションをインストールするには:

1. 12c (12.2.1.2)製品のディストリビューションをインストールするターゲット・システムにログインします。

2. Oracle Technology NetworkまたはOracle Software Delivery Cloudから、ターゲット・システムに次をダウンロードします。

- Oracle Fusion Middlewareインフラストラクチャ (fmw_12.2.1.2.0_infrastructure_generic.jar)

- Oracle HTTP Server (UNIX: fmw_12.2.1.2.0_ohs_linux64.bin)、(Windows: setup_fmw_12.2.1.2.0_ohs_win64.exe)

3. 使用するマシンが次の要件を満たしていることを確認します。

- システム、パッチ、カーネルおよびその他の要件が、Oracle HTTP Serverのインストールと構成に指定された内容を満たしていることを確認します。

- Oracle HTTP Serverはデフォルトではポート7777にインストールされるので、ノード上のどのサービスでもポート7777を使用していないことを確認する必要があります。このポートが使用されているかどうかを確認するには、Oracle HTTP Serverをインストールする前に次のコマンドを実行します。このポートが使用されている場合は、解放する必要があります。
netstat -an | grep 7777

4. UNIXプラットフォームで、/etc/oraInst.locファイルが存在する場合はその内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。
/etc/oraInst.locファイルが存在しない場合は、この手順をスキップできます。

5. 12c (12.2.1.2)製品のディストリビューションをダウンロードしたディレクトリに移動します。

6. Oracle Fusion Middlewareインフラストラクチャのインストール・プログラムを開始します。

- (UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

- (Windows) JDK_HOME\bin\java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

7. UNIXオペレーティング・システムでは、このホストにOracle製品を初めてインストールする場合に、「インストール・インベントリの設定」画面が表示されます。
中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システム・グループ名に対して中央インベントリの場所への書込み権限が付与されていることを確認し、「次へ」をクリックします。

注意:
「インストール・インベントリの設定」画面は、Windowsオペレーティング・システムでは表示されません。

8. 「ようこそ」画面で、情報をレビューしてすべての前提条件を満たしていることを確認します。「次へ」をクリックします。

9. 「自動更新」画面で、「自動更新をスキップ」を選択します。オプションは次のとおりです。

- この時点でソフトウェアの更新をシステムで確認しないようにする場合は、「自動更新をスキップ」を選択します。

- パッチ・ファイルをダウンロードした場合は、「ディレクトリからパッチを選択」を選択して、ローカル・ディレクトリに移動します。

- My Oracle Supportアカウントを持っている場合にソフトウェアの更新を自動でダウンロードするには、「My Oracle Supportで更新を検索」を選択します。Oracle Supportの資格証明を入力して、「検索」をクリックします。インストーラがMy Oracle Supportにアクセスするようにプロキシ・サーバーを構成するには、「プロキシ設定」をクリックします。「接続のテスト」をクリックして接続をテストします。

「次へ」をクリックします。

10. 「インストールの場所」画面でOracleホーム・ディレクトリの場所を指定して、「次へ」をクリックします。
ここでは、WebLogic Serverドメインに同じ場所に配置(コロケート)されたOracle HTTP Serverの標準的なインストール・トポロジをインストールしているため、既存のOracle Fusion Middleware InfrastructureのOracleホームへのパスを入力します。

Oracle Fusion Middlewareのディレクトリ構造の詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareのインストールのプランニング』のインストールおよび構成のためのディレクトリの選択に関する項を参照してください。

11. 「インストール・タイプ」画面で、次に示す項目を選択します。

- インフラストラクチャの場合は、「Fusion Middlewareインフラストラクチャ」を選択します。

- Oracle HTTP Serverの場合は、「同じ場所に配置されたHTTPサーバー(WebLogic Server経由で管理)」を選択します。

「次へ」をクリックします。

12. 「前提条件チェック」画面では、ホスト・コンピュータを分析して、特定のオペレーティング・システムの前提条件を満たしているか確認します。
確認されたタスクのリストを表示するには、「正常なタスクの表示」を選択します。ログの詳細を表示するには、「ログの表示」を選択します。前提条件のチェックが失敗すると、エラー・メッセージが画面の下方に表示されます。エラーを修正し、「再実行」をクリックして再試行します。エラー・メッセージや警告メッセージを無視してインストールを続けるには、「スキップ」をクリックします(非推奨)。

13. 「インストール・サマリー」画面で、選択したインストール・オプションを確認します。
これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を入力します。レスポンス・ファイルには、入力したすべての情報が収集して格納され、後で(コマンドラインから)サイレント・インストールを実行するために使用できます。
「インストール」をクリックしてインストールを開始します。

14. 「インストールの進行状況」画面で、プログレス・バーが100%完了になったら、「終了」をクリックしてインストーラを閉じるか、「次へ」をクリックしてサマリーを表示します。

15. 「インストール完了」画面に、インストールの場所とインストールされた機能セットが表示されます。情報を確認し、「終了」をクリックしてインストーラを閉じます。

16. Oracle Fusion Middlewareインフラストラクチャのインストール後、次に示すコマンドを入力して、製品ディストリビューションのインストーラを起動し、インストーラの各画面を通じて前述の手順を繰り返します。
(UNIX) ./fmw_12.2.1.2.0_ohs_linux64.bin

(Windows) setup_fmw_12.2.1.2.0_ohs_win64.exe

これで、Oracle HTTP Serverのコロケート・モードでのインストールが完了しました。

6.3 アップグレード前の準備状況チェックの実行

アップグレードにかかわる潜在的な問題を特定するために、アップグレード・プロセスの開始前に、準備状況チェックの実行をお薦めします。準備状況チェックによって、アップグレードにかかわる潜在的な問題をすべて検出できるわけではない点に注意してください。準備状況チェックのレポートが成功を示していても、アップグレードが失敗することもあります。

- Upgrade Assistantを使用したアップグレード前準備状況チェックの実行について
Upgrade Assistantを-readinessモードで実行することで、実際のアップグレードを実行する前に問題を検出できます。Upgrade Assistantを使用すると、準備状況チェックはGUIモードで実行できます。また、レスポンス・ファイルを使用するとサイレント・モードで実行できます。

- 準備状況モードでのUpgrade Assistantの起動
-readinessパラメータを使用して、Upgrade Assistantを準備状況モードで起動します。

- Upgrade Assistantを使用した準備状況チェックの実行
Upgrade Assistantの各画面を通じて、アップグレード前の準備状況チェックを完了します。

- 準備状況レポートの理解
ドメインの準備状況チェックを実行後、レポートを確認して、正常にアップグレードするために何かアクションを実行する必要があるかどうかを判断します。

6.3.1 アップグレード前の準備状況チェックの実行について

Upgrade Assistantを-readinessモードで実行することで、実際のアップグレードを実行する前に問題を検出できます。Upgrade Assistantを使用すると、準備状況チェックはGUIモードで実行できます。また、レスポンス・ファイルを使用するとサイレント・モードで実行できます。

Upgrade Assistantの準備状況チェックは、サポート対象の開始ポイントにあるFusion MiddlewareのスキーマとWebLogicドメインの構成について、読取り専用のアップグレード前確認を実行します。この確認は、読取り専用の操作です。

準備状況チェックでは、フォーマットされ、タイムスタンプの付けられた準備状況レポートが生成され、実際のアップグレードを試みる前に潜在的な問題に対処できます。問題が検出されない場合は、アップグレード・プロセスを開始できます。アップグレードを実行する前に、このレポートを詳細に確認することをお薦めします。

準備状況チェックは、既存のOracle Fusion Middlewareドメインがオンライン(他のユーザーがアクティブに使用している間)またはオフラインである間に実行できます。

準備状況チェックは、実際のアップグレードの実行前に、何度でも実行できます。ただし、アップグレードの実行後には、準備状況チェックを実行しないでください。これは、レポート結果が、アップグレード前の準備状況チェックと異なることがあるためです。

注意:

パフォーマンスへの影響を避けるため、準備状況チェックはピーク時以外に実行するようにしてください。

6.3.2 準備状況モードでのUpgrade Assistantの起動

-readinessパラメータを使用して、Upgrade Assistantを準備状況モードで起動します。

Upgrade Assistantを使用して、アップグレード前の環境に対する準備状況チェックを実行するには:

1. oracle_common/upgrade/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. Upgrade Assistantを起動します。

- (UNIX) ./ua -readiness

- (Windows) ua.bat -readiness

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

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

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

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

その他のコマンドラインに指定可能なパラメータの詳細は、次の項を参照してください。

- Upgrade Assistantパラメータ

6.3.2.1 Upgrade Assistantパラメータ

コマンドラインからUpgrade Assistantを起動する際に、追加のパラメータを指定できます。

表6-2 Upgrade Assistantコマンドライン・パラメータ

パラメータ

必須/省略可能

説明

-readiness

準備状況チェックの場合は必須
注意: スタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では準備状況チェックを実行できません。

アップグレードの準備状況チェックを実行します(実際のアップグレードは実行しません)。

スキーマと構成がチェックされます。

-examineパラメータを指定した場合は、このパラメータを指定しないでください。

-threads

省略可能

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を特定します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須

レスポンス・ファイルに保存した入力を使用して、Upgrade Assistantを実行します。このレスポンス・ファイルは、GUIモードでUpgrade Assistantを実行したときの入力データから生成されます。このパラメータを使用すると、Upgrade Assistantがサイレント・モードで(Upgrade Assistant画面を表示せずに)実行されます。

-examine

省略可能

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel attribute

省略可能

次のいずれかの属性を指定して、ログイン・レベルを設定します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

デフォルトのロギング・レベルはNOTIFICATIONです。

-logLevel TRACE属性を設定して、より多くのログが記録されるようにすることを検討してください。これは、アップグレードの失敗をトラブルシューティングする際に役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir location

省略可能

アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。既存の書込み可能なディレクトリを指定する必要があります。Upgrade Assistantは、このディレクトリにログ・ファイルと一時ファイルを作成します。

デフォルトの場所は次のとおりです。

UNIXの場合:

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

Windowsの場合:

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

省略可能

すべてのコマンドライン・オプションを表示します。

6.3.3 Upgrade Assistantを使用した準備状況チェックの実行

Upgrade Assistantの各画面を通じて、アップグレード前の準備状況チェックを完了します。

準備状況チェックは、サポートされるアップグレードの開始点にあるスキーマまたはコンポーネント構成に対してのみ実行されます。

準備状況チェックを完了するには:

1. 「ようこそ」画面で、準備状況チェックに関する情報を確認します。「次へ」をクリックします。

2. 「準備状況チェック・タイプ」画面で、実行する準備状況チェックを選択します。

- 「個別に選択されたスキーマ」: アップグレード前に確認するスキーマを個別に選択できます。準備状況チェックは、スキーマがアップグレードに対応しているかどうか、またはアップグレードが必要かどうかをレポートします。
このオプションを選択すると、画面名が「選択したスキーマ」に変更されます。

- 「ドメイン・ベース」: Upgrade Assistantは、「ドメイン・ディレクトリ」フィールドで指定されたドメイン内で、アップグレード可能なスキーマまたはコンポーネントのすべてを検出して選択するようになります。
このオプションを選択すると、画面名が「スキーマおよび構成」に変更されます。

Upgrade Assistantですべてのスキーマとコンポーネント構成をチェックする場合は、デフォルトの選択を変更しないで使用します。それ以外の場合は、次に示す特定のオプションを選択します。

- 「すべてのスキーマのチェックを含める」: アップグレードに対応したコンポーネントをすべて検出して確認します。

- 「すべての構成のチェックを含める」: 管理対象WebLogic Serverドメインのコンポーネント構成を確認します。

「次へ」をクリックします。

3. 「個別に選択されたスキーマ」を選択した場合: 「使用可能なコンポーネント」画面で、アップグレードに対応可能なスキーマを持つコンポーネントを選択して、準備状況チェックの実行対象にします。

依存コンポーネントのあるコンポーネントを選択すると、該当するコンポーネントが自動的に選択されます。たとえば、Oracle Platform Security Servicesを選択すると、Oracle Audit Servicesが自動的に選択されます。

選択したコンポーネントによっては、追加の画面が表示されることがあります。たとえば、次のような作業が必要になることがあります。

- ドメイン・ディレクトリを指定します。

- 選択したスキーマに接続するために、次のスキーマ資格証明を指定します: 「データベース・タイプ」、「DBAユーザー名」および「DBAパスワード」。次に、「接続」をクリックします。

注意:
Oracleデータベースは、デフォルトのデータベース・タイプです。データベース・タイプに間違いがないことを確認してから続行してください。間違ったデータベースを選択していることに気付いた場合でも、正しいタイプに変更するために、この画面に戻らないでください。そのかわりに、Upgrade Assistantを終了してから、正しいデータベース・タイプを選択した状態で準備状況チェックを再開し、すべてのスキーマに正しいデータベース・タイプが適用されるようにします。

- 「スキーマ・ユーザー名」を選択して、「スキーマ・パスワード」を指定します。

「次」をクリックして、準備状況チェックを開始します。

4. 「準備状況サマリー」画面で、選択内容に応じて実行される準備状況チェックのサマリーを確認します。
選択内容を保存して、今後、レスポンス(サイレンス)モードでUpgrade Assistantを再実行する場合は、「レスポンス・ファイルの保存」をクリックして、レスポンス・ファイルの場所と名前を指定します。サイレント・アップグレードは、Upgrade Assistantとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。

詳細レポートを表示するには、「ログの表示」をクリックします。

「次へ」をクリックします。

5. 「準備状況チェック」画面で、準備状況チェックのステータスを確認します。このプロセスには、数分かかることがあります。
複数のコンポーネントをチェックしている場合、それぞれのコンポーネントの進行状況は、それぞれ専用のプログレス・バーで同時に表示されます。

準備状況チェックが完了したら、「続行」をクリックします。

6. 「準備状況の終了」画面で、準備状況チェックの結果(「準備状況成功」または「準備状況失敗」)を確認します。

- 準備状況チェックが成功した場合は、「準備状況レポートの表示」をクリックして完全なレポートを確認します。準備状況チェックが成功した場合でも、実際のアップグレードを実行する前に、準備状況レポートを確認するようにしてください。「検索」オプションは、レポート内の特定の語句を検索する際に使用します。また、このレポートには、完成した準備状況チェック・レポート・ファイルが格納されている場所も示されます。

- 準備状況チェックで問題またはエラーが発生した場合は、「ログの表示」をクリックしてログ・ファイルを確認し、問題を特定して修正してから、準備状況チェックを再開します。ログ・ファイルは、設定したコマンドライン・オプションによって管理されます。

6.3.4 準備状況レポートの理解

ドメインの準備状況チェックを実行後、レポートを確認して、正常にアップグレードするために何かアクションを実行する必要があるかどうかを判断します。

準備状況レポート・ファイルの形式は、次のとおりです。

readiness_timestamp.txt

timestampは、準備状況チェックが実行された日時を示します。

準備状況レポートには、次に示す情報が含まれています。

表6-3 準備状況レポートの要素

レポートの情報

説明

必要なアクション

全体的な準備状況ステータス: SUCCESSまたはFAILURE

レポートの上部には、準備状況チェックが成功したか、または1つ以上のエラーが発生して完了したかが示されます。

1つ以上のエラーが発生してレポートが完了した場合、アップグレードを試みる前に、FAILを検索し、障害の原因となった問題を修正します。準備状況チェックは、アップグレードする前に必要に応じて何度でも再実行できます。

Timestamp

レポートが生成された日付と時刻です。

必要なアクションはありません。

ログ・ファイルの場所

ORACLE_HOME/oracle_common/upgrade/logs

生成されたログ・ファイルのディレクトリの場所です。

必要なアクションはありません。

準備状況レポートの場所

ORACLE_HOME/oracle_common/upgrade/logs

生成された準備状況レポートのディレクトリの場所です。

必要なアクションはありません。

チェックされたコンポーネントの名前

チェックに含まれるコンポーネントの名前およびバージョンとステータス。

このリリースにアップグレードできないコンポーネント(SOAコア拡張など)がドメインに含まれている場合は、アップグレードを試みないでください。

チェックされたスキーマの名前

チェックに含まれるスキーマの名前および現在のバージョンとステータス。

スキーマのバージョン番号をレビューします。このリリースにアップグレードできないスキーマがドメインに含まれる場合は、アップグレードを試みないでください。

個別のオブジェクトのテスト・ステータス: FAIL

準備状況チェックのテストで、特定のオブジェクトに問題が検出されています。

失敗した問題がすべて解決するまでアップグレードしないでください。

個別のオブジェクトのテスト・ステータス: PASS

準備状況チェックのテストでは、特定のオブジェクトに問題が検出されませんでした。

準備状況チェック・レポートにPASSステータスのみが表示されている場合、環境をアップグレードできます。ただし、準備状況チェックでは、ハードウェアやアップグレード時の接続性などの外部環境に関する問題を検出することはできません。アップグレードの進捗を常に監視する必要があります。

<オブジェクト>の準備状況チェックの完了ステータス: FAILURE

準備状況チェックによって、スキーマ、索引、データ型などの特定のオブジェクトに関する、解決する必要があるエラーが1つ以上検出されました。

失敗した問題がすべて解決するまでアップグレードしないでください。

<オブジェクト>の準備状況チェックの完了ステータス: SUCCESS

準備状況チェック・テストによって問題が検出されませんでした。

必要なアクションはありません。

準備状況レポート・ファイルのサンプルを次に示します。使用対象のレポートにはこれらすべてのチェックが含まれない場合があります。

Upgrade readiness check completed with one or more errors.

This readiness check report was created on Tue May 30 11:15:52 EDT 2016
Log file is located at: ORACLE_HOME/oracle_common/upgrade/logs/ua2016-05-30-11-14-06AM.log
Readiness Check Report File: ORACLE_HOME/oracle_common/upgrade/logs/readiness2016-05-30-11-15-52AM.txt

Starting readiness check of components.

Oracle Metadata Services
Starting readiness check of Oracle Metadata Services.
Schema User Name: DEV11_MDS
Database Type: Oracle Database
Database Connect String: machinename@yourcompany.com
VERSION Schema DEV11_MDS is currently at version 12.1.1.1.0.  Readiness checks will now be performed.
Starting schema test:  TEST_REQUIRED_TABLES  Test that the schema contains all the required tables
Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS
Starting schema test:  TEST_REQUIRED_PROCEDURES  Test that the schema contains all the required stored procedures
EXCEPTION     Schema is missing a required procedure: GETREPOSITORYFEATURES
Completed schema test: TEST_REQUIRED_PROCEDURES --> Test that the schema contains all the required stored procedures +++ FAIL
Starting schema test:  TEST_REQUIRED_VIEWS  Test that the schema contains all the required database views
Completed schema test: TEST_REQUIRED_VIEWS --> Test that the schema contains all the required database views +++ PASS
Starting index test for table MDS_ATTRIBUTES:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_ATTRIBUTES: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting index test for table MDS_COMPONENTS:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_TXN_LOCKS: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting schema test:  TEST_REQUIRED_TRIGGERS  Test that the schema has all the required triggers
Completed schema test: TEST_REQUIRED_TRIGGERS --> Test that the schema has all the required triggers +++ PASS
Starting schema test:  TEST_MISSING_COLUMNS  Test that tables and views are not missing any required columns
Completed schema test: TEST_MISSING_COLUMNS --> Test that tables and views are not missing any required columns +++ PASS
Starting schema test:  TEST_UNEXPECTED_TABLES  Test that the schema does not contain any unexpected tables
Completed schema test: TEST_UNEXPECTED_TABLES --> Test that the schema does not contain any unexpected tables +++ PASS
Starting schema test:  TEST_UNEXPECTED_PROCEDURES  Test that the schema does not contain any unexpected stored procedures
Completed schema test: TEST_UNEXPECTED_PROCEDURES --> Test that the schema does not contain any unexpected stored procedures +++ PASS
Starting schema test:  TEST_UNEXPECTED_VIEWS  Test that the schema does not contain any unexpected views
Completed schema test: TEST_UNEXPECTED_VIEWS --> Test that the schema does not contain any unexpected views +++ PASS
Starting index test for table MDS_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Completed index test for table MDS_ATTRIBUTES: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Completed index test for table MDS_LABELS: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Starting index test for table MDS_LARGE_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Starting schema test:  TEST_UNEXPECTED_TRIGGERS  Test that the schema does not contain any unexpected triggers
Completed schema test: TEST_UNEXPECTED_TRIGGERS --> Test that the schema does not contain any unexpected triggers +++ PASS
Starting schema test:  TEST_UNEXPECTED_COLUMNS  Test that tables and views do not contain any unexpected columns
Completed schema test: TEST_UNEXPECTED_COLUMNS --> Test that tables and views do not contain any unexpected columns +++ PASS
Starting datatype test for table MDS_ATTRIBUTES:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table MDS_ATTRIBUTES: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table MDS_COMPONENTS:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Starting permissions test:  TEST_DBA_TABLE_GRANTS  Test that DBA user has privilege to view all user tables
Completed permissions test: TEST_DBA_TABLE_GRANTS --> Test that DBA user has privilege to view all user tables +++ PASS
Starting schema test:  TEST_ENOUGH_TABLESPACE  Test that the schema tablespaces automatically extend if full
Completed schema test: TEST_ENOUGH_TABLESPACE --> Test that the schema tablespaces automatically extend if full +++ PASS
Starting schema test:  TEST_USER_TABLESPACE_QUOTA  Test that tablespace quota for this user is sufficient to perform the upgrade
Completed schema test: TEST_USER_TABLESPACE_QUOTA --> Test that tablespace quota for this user is sufficient to perform the upgrade +++ PASS
Starting schema test:  TEST_ONLINE_TABLESPACE  Test that schema tablespaces are online
Completed schema test: TEST_ONLINE_TABLESPACE --> Test that schema tablespaces are online +++ PASS
Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
INFO   Database product version: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
Finished readiness check of Oracle Metadata Services with status: FAILURE.

Oracle Fusion Middleware IAU Schemasの12.1.3.0バージョンを実行していて、それらのスキーマが11g (11.1.1.7以降)または12c (12.1.2.0)からアップグレードされている場合には、準備状況チェックは次に示すエラーで失敗する可能性があります。

Starting index test for table IAU_COMMON:  TEST_REQUIRED_INDEXES --> Test
that the table contains all the required indexes
INFO Audit schema index DYN_EVENT_CATEGORY_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_EVENT_TYPE_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_TENANT_INDEX in table IAU_COMMON is missing
the required columns or index itself is missing. This maybe caused by a known
issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_USER_INDEX in table IAU_COMMON is missing
the required columns or index itself is missing. This maybe caused by a known
issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_COMPONENT_TYPE_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_USER_TENANT_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
Completed index test for table IAU_COMMON: TEST_REQUIRED_INDEXES --> Test
that the table contains all the required indexes +++ FAIL

注意:
準備状況レポートの欠落している索引に関するエラーは無視してもかまいません。これは既知の問題です。欠落している索引に対応するものが、スキーマのアップグレード操作時に追加されます。このエラーは、アップグレードするスキーマがRCUを使用して12cで作成されていた場合は発生しません。

6.4 サーバーとプロセスの停止

Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、すべてのプロセスと管理サーバーや管理対象サーバーを含めたすべてのサーバーを停止する必要があります。

Oracle Fusion Middleware環境は、1つのOracle WebLogic Serverドメイン、1つの管理サーバー、複数の管理対象サーバー、Javaコンポーネント、システム・コンポーネント(Identity Managementのコンポーネントなど)およびメタデータのリポジトリとして使用する1つのデータベースで構成できます。コンポーネントは相互に依存していることがあるため、適切な順序で停止する必要があります。

注意:
この項の手順では、WLSTコマンドライン・ユーティリティまたはスクリプトを使用してサーバーとプロセスを停止する方法について説明します。また、Oracle Fusion Middleware ControlとOracle WebLogic Server管理コンソールを使用することもできます。『Oracle Fusion Middleware Oracle Fusion Middlewareの管理』の管理サーバー、管理対象サーバーおよびノード・マネージャの起動および停止に関する項を参照してください。

Fusion Middleware環境を停止するには、次に示す手順を実行します。

ステップ1: システム・コンポーネントを停止する

Oracle HTTP Serverなどのシステム・コンポーネントを停止するには、stopComponentスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

システム・コンポーネントは任意の順序で停止できます。

ステップ2: 管理対象サーバーを停止する

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

- (UNIX) DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url

- (Windows) DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url

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

ステップ3: Oracle Identity Managementのコンポーネントを停止するOracle Internet Directoryなど、Oracle Identity Managementコンポーネントを停止します。

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

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

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

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

- (UNIX) DOMAIN_HOME/bin/stopWebLogic.sh

- (Windows) DOMAIN_HOME\bin\stopWebLogic.cmd

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

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

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

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

6.5 製品スキーマのアップグレード

サーバーとプロセスの停止後、Upgrade Assistantを使用して、Oracle Fusion Middlewareの現在のリリースにあわせてサポート対象の製品スキーマをアップグレードします。

アップグレード・アシスタントを使用すると、個別に選択したスキーマまたはドメインに関連付けられているすべてのスキーマをアップグレードできます。選択したオプションによって、表示されるアップグレード・アシスタントの画面は異なります。

- アップグレードに対応可能な既存のスキーマの特定
このオプションのタスクにより、対応可能なスキーマのリストを確認してから、スキーマ・バージョン・レジストリに問い合せることでアップグレードを開始できます。このレジストリには、バージョン番号、コンポーネント名とID、作成日と変更日、カスタム接頭辞などのスキーマ情報が含まれています。

- Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade Assistantは非SYSDBAとして実行して、一度にアップグレードするドメインは1つにすることをお薦めします。

- Upgrade Assistantを使用した製品スキーマのアップグレード
Upgrade Assistantの各画面を通じて、製品スキーマをアップグレードします。

- スキーマのアップグレードの確認
すべてのアップグレード手順を完了したら、schema_version_registryのスキーマ・バージョンが適切に更新されていることをチェックして、アップグレードの成功を検証します。

6.5.1 アップグレードに対応可能な既存のスキーマの特定

このオプションのタスクにより、使用可能なスキーマのリストを確認してから、スキーマ・バージョン・レジストリに問い合せることでアップグレードを開始できます。このレジストリには、バージョン番号、コンポーネント名とID、作成日と変更日、カスタム接頭辞などのスキーマ情報が含まれています。

Upgrade Assistantの実行前に、アップグレードに対応可能なすべてのスキーマのリストをプレビューすることは、アップグレードするスキーマを個別に選択するか、Upgrade Assistantによる自動選択を許可してドメイン内のすべてのスキーマをアップグレードするかを決定する際に役立ちます。

ドメイン内に存在するアップグレードに対応可能なスキーマを特定するには:

1. Oracle Databaseを使用する場合、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 ;

2. 生成されたレポートを調査します。VERSION列の値が11.1.1.6.0以上で、STATUS列の値がVALIDの場合、そのスキーマはアップグレードのサポート対象になります。
アップグレードの必要がないスキーマがある場合は、そのスキーマのアップグレード前のバージョンがschema_version_registry表に維持されます。

3. 既存のスキーマに使用していたスキーマ接頭辞名をメモしておきます。新しい12cスキーマの作成時に、同じ接頭辞を使用することになります。

注意:

- 既存のスキーマがサポート対象のバージョンではない場合は、そのスキーマをサポート対象バージョンにアップグレードしてから、12c (12.2.1.2)のアップグレード手順を使用する必要があります。詳細は、アップグレード前のバージョンのドキュメントを参照してください。

- 一部のコンポーネント(Oracle Enterprise Data Quality、Oracle GoldenGate Monitor、Oracle GoldenGate Veridataなど)では、標準的なOracle Fusion Middlewareのサポート対象バージョン以外のバージョンからのアップグレードがサポートされています。

- 11gでファイルベースのポリシー・ストアを使用していた場合、Upgrade Assistantを実行する前に、ファイルベースのポリシー・ストアをデータベースベースのセキュリティ・ストアに再度関連付ける必要があります。
詳細は、「アップグレード前のファイルベースのポリシー・ストアの再関連付け」を参照してください。

- 11gでOIDベースのポリシー・ストアを使用していた場合は、アップグレードの実行前に必ず新しいOPSSスキーマを作成してください。このOPSSスキーマは、アップグレード後もLDAPベースのストアのままになります。

- RCU 11g (11.1.1.4以前)を使用して作成され、続いてORASDPMを11g (11.1.1.6以降)にアップグレードしたORASDPMスキーマをアップグレードする場合、FMWユーザーは12c (12.2.1.2)にアップグレードする前にユーザーprefix_ORASDPMにCREATE TABLE権限を付与する必要があります。

grant CREATE TABLE to prefix_ORASDPM;
prefixは作成時にスキーマに付けられた名前です。

- Oracle Fusion Middlewareリリース12c (12.2.1.2)のアップグレードに対応可能な製品のスキーマのみをアップグレードできます。まだ12c (12.2.1.2)へのアップグレードが未対応のコンポーネントを含むドメインはアップグレードしないでください。

6.5.2 Upgrade Assistantの起動

Upgrade Assistantを実行して、製品のスキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade Assistantは非SYSDBAとして実行して、一度にアップグレードするドメインは1つにすることをお薦めします。

Upgrade Assistantを起動するには、次の手順に従います。

1. oracle_common/upgrade/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. Upgrade Assistantを起動します。

- (UNIX) ./ua

- (Windows) ua.bat

コマンドラインに指定可能なその他のパラメータ(ロギングのパラメータなど)の詳細は、次を参照してください。

- Upgrade Assistantパラメータ

6.5.2.1 Upgrade Assistantパラメータ

コマンドラインからUpgrade Assistantを起動する際に、追加のパラメータを指定できます。

表6-4 Upgrade Assistantコマンドライン・パラメータ

パラメータ

必須/省略可能

説明

-readiness

準備状況チェックの場合は必須
注意: スタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では準備状況チェックを実行できません。

アップグレードの準備状況チェックを実行します(実際のアップグレードは実行しません)。

スキーマと構成がチェックされます。

-examineパラメータを指定した場合は、このパラメータを指定しないでください。

-threads

省略可能

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を特定します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須

レスポンス・ファイルに保存した入力を使用して、Upgrade Assistantを実行します。このレスポンス・ファイルは、GUIモードでUpgrade Assistantを実行したときの入力データから生成されます。このパラメータを使用すると、Upgrade Assistantがサイレント・モードで(Upgrade Assistant画面を表示せずに)実行されます。

-examine

省略可能

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel attribute

省略可能

次のいずれかの属性を指定して、ログイン・レベルを設定します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

デフォルトのロギング・レベルはNOTIFICATIONです。

-logLevel TRACE属性を設定して、より多くのログが記録されるようにすることを検討してください。これは、アップグレードの失敗をトラブルシューティングする際に役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir location

省略可能

アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。既存の書込み可能なディレクトリを指定する必要があります。Upgrade Assistantは、このディレクトリにログ・ファイルと一時ファイルを作成します。

デフォルトの場所は次のとおりです。

UNIXの場合:

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

Windowsの場合:

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

省略可能

すべてのコマンドライン・オプションを表示します。

6.5.3 Upgrade Assistantを使用した製品スキーマのアップグレード

Upgrade Assistantの各画面を通じて、製品スキーマをアップグレードします。

OPSSおよびIAUスキーマをアップグレードする手順は次のとおりです。

1. 「ようこそ」画面には、Upgrade Assistantの概要と、アップグレード前のいくつかの重要なタスクについての情報が示されます。「次へ」をクリックします。

注意:
Upgrade Assistantの画面の詳細は、画面上の「ヘルプ」をクリックしてください。

2. 「選択したスキーマ」画面で、次に示すオプションを選択します。

- 「個別に選択されたスキーマ」: ドメインで使用されるスキーマをすべてアップグレードするのではなく、アップグレードするスキーマを個別に選択する場合のオプションです。

注意:
対象の12c (12.2.1.2)コンポーネントをサポートするために使用するスキーマのみをアップグレードしてください。Oracle Fusion Middleware 12c (12.2.1.2)に含まれていないコンポーネントをサポートするために現在使用しているスキーマは、アップグレードしないでください。

「次へ」をクリックします。

3. 「使用可能なコンポーネント」画面に、アップグレード可能なスキーマがある、インストール済Oracle Fusion Middlewareコンポーネントのリストが表示されます。コンポーネントを選択すると、スキーマとすべての依存関係が自動的に選択されます。
「Oracle Platform Security Services」を選択します。これを選択すると、Oracle監査サービスが自動的に選択されます。「次へ」をクリックします。

4. 「ドメイン・ディレクトリ」画面で、12c (12.1.2.0、12.1.3.0、12.2.1.0および12.2.1.1)のWebLogicドメイン・ディレクトリを入力します。「参照」をクリックし、ナビゲーション・ツリーを使用して12c WebLogicドメイン・ディレクトリを選択します。
Upgrade Assistantがjps-config.xmlファイルにアクセスするために、12cドメインの場所が必要です。

5. 「前提条件」画面で、すべてのチェック・ボックスを選択して、前提条件を満たしていることを確認します。「次へ」をクリックします。

注意:
Upgrade Assistantでは、前提条件が満たされているかどうかの確認は行われません。

6. 「調査」画面で、各スキーマを調査したUpgrade Assistantのステータスを確認して、スキーマのアップグレードの準備が整っていることを検証します。ステータスが「調査が終了しました。」になっている場合は、「次」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認します。一般的なアップグレード・エラーの解決方法の詳細は、Oracle Fusion Middleware Upgrade Assistantによるアップグレードのアップグレード・ガイドのアップグレードのトラブルシューティングに関する項を参照してください。

注意:

- 確認フェーズ中に検出された問題を、アップグレードを進めずに解決した場合は、バックアップからリストアを再び行わずにUpgrade Assistantを開始できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックしてアップグレードを続行していた場合は、Upgrade Assistantを再開する前に、バックアップからアップグレード前の環境をリストアする必要があります。

- 調査プロセスを取り消してもスキーマまたは構成データに影響はありませんが、将来のアップグレード・セッションでは、Upgrade Assistantが収集した情報を再収集する必要があります。

7. 「アップグレード・サマリー」画面で、スキーマのアップグレードに選択したオプションのサマリーを確認します。
アップグレード対象のスキーマごとに、正しいソース・バージョンとターゲット・バージョンがリストされていることを確認します。

これらのオプションを保存して、今後、レスポンス(サイレンス)モードでUpgrade Assistantを再実行する場合は、「レスポンス・ファイルの保存」をクリックして、レスポンス・ファイルの場所と名前を指定します。サイレント・アップグレードは、Upgrade Assistantとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。

8. 「アップグレードの進行状況」画面で、アップグレードのステータスを監視します。

注意:
アップグレード・アシスタントにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。これを行うと、環境が不安定になる可能性があります。

正しくアップグレードされていないスキーマがある場合は、Upgrade Assistantのログ・ファイルで情報を確認します。

注意:
この画面のプログレス・バーには、現在のアップグレード手順の進行状況が表示されます。アップグレードの残り時間を示すものではありません。

「次へ」をクリックします。

9. アップグレードが成功した場合: 「アップグレード成功」画面で、「閉じる」をクリックし、アップグレードを完了してウィザードを閉じます。

アップグレードが失敗した場合: 「アップグレード失敗」画面で、「ログの表示」をクリックし、エラーを表示してトラブルシューティングします。ログは、ORACLE_HOME/oracle_common/upgrade/logsにあります。

注意:
アップグレードが失敗した場合は、バックアップからアップグレード前の環境をリストアし、問題を修正してから、Upgrade Assistantを再起動する必要があります。

6.5.4 スキーマのアップグレードの確認

すべてのアップグレード手順を完了したら、schema_version_registryのスキーマ・バージョンが適切に更新されていることをチェックして、アップグレードの成功を検証します。

Oracle Databaseを使用する場合、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 ;

問合せ結果について:

- VERSION列の数値が、そのスキーマの最新のバージョン番号に一致していることを確認します。たとえば、スキーマ・バージョン番号が12.2.1.2.0になっていることを確認します。ただし、すべてのスキーマ・バージョンが更新されるわけではない点に注意してください。一部のスキーマは、このリリースにあわせたアップグレードの必要がなく、アップグレード前のバージョン番号を維持します。

- STATUSフィールドは、スキーマのパッチ適用操作中はUPGRADINGまたはUPGRADEDのどちらかになり、パッチ適用操作が完了するとVALIDになります。

- ステータスが「INVALID」と表示された場合は、ステータスの更新が失敗しています。ログ・ファイルを調べて、失敗した理由を判定する必要があります。

- IAU_APPENDとIAU_VIEWERが所有するシノニム・オブジェクトは、INVALIDと表示されますが、失敗を意味するものではありません。
これらは、シノニムの作成後にターゲット・オブジェクトが変更されるため無効になります。シノニム・オブジェクトは、アクセスされるときに有効になります。これに該当するINVALIDオブジェクトは、無視しても問題ありません。

6.6 ドメインの再構成

再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.2)にあわせて再構成します。

WebLogic Serverドメインを再構成すると、ドメイン内のアプリケーションに応じて、次の項目が自動的に更新されます。

- WebLogic Serverコア・インフラストラクチャ

- ドメイン・バージョン

注意:

ドメインの再構成を開始する前に、次の制限事項に注意してください。

- 再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。

- アップグレード・プロセス中に、非動的クラスタ・ドメインを動的クラスタ・ドメインに変換することはサポートされていません。
動的クラスタ機能は、再構成ウィザードの実行中に使用できますが、サポートされているアップグレードは非動的クラスタのアップグレードのみで、その後で動的クラスタを追加することになります。アップグレード・プロセス中に動的クラスタを追加することはできません。

具体的には、ドメインを再構成する場合、次のことが発生します。

- ドメインのconfig.xmlファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンに更新されます。

- すべてのインストール済Oracle製品の再構成テンプレートは、自動的に選択されてドメインに適用されます。これらのテンプレートは、WebLogicドメインが現在のWebLogic Serverバージョンと互換性を持つために必要な再構成タスクを定義します。

- 起動スクリプトが更新されます。
変更済の起動スクリプトを維持する場合は、そのスクリプトをバックアップしてから、再構成ウィザードを開始してください。

注意:
ドメインの再構成プロセスを開始すると、元に戻すことはできません。再構成ウィザードの実行前には、アップグレード前チェックリストで説明しているように、ドメインのバックアップが作成されていることを確認してください。再構成ウィザードの実行中にエラーまたは他の割込みが発生した場合、バックアップ場所から元のドメイン・ディレクトリにファイルとディレクトリをコピーすることによって、ドメインをリストアする必要があります。これは、再構成前の元の状態にドメインを復元するための唯一の方法です。

再構成ウィザードを使用して既存のドメインを再構成する手順に従います。ドメインの再構成の一般情報は、『Oracle Fusion Middleware Oracle WebLogic Serverのアップグレード』のWebLogicドメインの再構成に関する項を参照してください。

- ドメインのバックアップ

- 再構成ウィザードの起動

- 再構成ウィザードを使用したドメインの再構成
再構成ウィザードの各画面を通じて既存のドメインを再構成します。

6.6.1 ドメインのバックアップ

再構成ウィザードの実行前に、ドメイン・ディレクトリのバックアップ・コピーを作成します。

ドメイン・ディレクトリのバックアップを作成するには:

1. コンテンツを保持するには、ソース・ドメインを別の場所にコピーします。
たとえば、C:\domains\mydomainをC:\domains\mydomain_backupにコピーします。

2. 各リモート管理対象サーバーのドメインを更新する前に、各リモート・マシンのドメイン・ディレクトリのバックアップ・コピーを作成します。

3. ドメインのバックアップしたバージョンが完全であることを確認します。

なんらかの理由でドメインの再構成が失敗した場合は、すべてのファイルおよびディレクトリをバックアップ・ディレクトリから元のドメイン・ディレクトリにコピーしてドメインを完全に再構成前の元の状態に戻す必要があります。

6.6.2 再構成ウィザードの起動

再構成ウィザードをグラフィカル・モードで起動する手順は次のとおりです。

1. ドメインが存在するシステムにサインインします。

2. コマンド・シェル(UNIXオペレーティング・システムの場合)またはコマンド・プロンプト・ウィンドウ(Windowsオペレーティング・システムの場合)を開きます。

3. エディション・ベースのデータベース・ユーザーのみ: スキーマがEBRデータベースを使用して構成されている場合、再構成ウィザードを実行する前に、手動でデフォルトのエディション名を設定する必要があります。
次のSQLコマンドを実行して、デフォルト・エディションを設定します。
ALTER DATABASE DEFAULT EDITION = edition_name;

edition_nameは、子エディションの名前です。

4. oracle_common/common/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/common/bin

- (Windows) ORACLE_HOME\oracle_common\commom\bin

5. 次に示すロギングオプションを指定して、再構成ウィザードを開始します。

- (UNIX) ./reconfig.sh -log=log_file -log_priority=ALL

- (Windows) reconfig.cmd -log=log_file -log_priority=ALL

log_fileは、ドメイン再構成セッション用に作成するログ・ファイルの絶対パスです。これは、再構成処理をトラブルシューティングする必要がある場合に役立つことがあります。

パラメータ-log_priority=ALLにより、ログは詳細モードで記録されるようになります。

注意:

このコマンドを実行すると、デフォルトのキャッシュ・ディレクトリが無効であることを示す次のエラー・メッセージが表示される場合があります。

*sys-package-mgr*: can't create package cache dir

環境変数CONFIG_JVM_ARGSを設定することでキャッシュ・ディレクトリを変更できます。次に例を示します。

CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

6.6.3 再構成ウィザードを使用したドメインの再構成

再構成ウィザードの各画面を通じて、既存のドメインを再構成します。

ドメインを再構成する手順は次のとおりです。

1. 「ドメインの選択」画面でアップグレードするドメインの場所を指定するか、「参照」をクリックして移動し、ドメイン・ディレクトリを選択します。「次へ」をクリックします。

2. 「再構成セットアップの進行状況」画面で、セットアップ・プロセスの進行状況を確認します。完了したら、「次へ」をクリックします。
このプロセスでは次の処理が行われます。

- Fusion Middleware製品を含む、インストール済製品の再構成テンプレートが自動的に適用されます。これにより、config.xml、config-groups.xml、security.xmlなどの様々なドメイン構成ファイルが更新されます。

- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

- ドメイン・アップグレードが検証されます。

3. 「ドメイン・モードおよびJDK」画面で、ドメインで使用するJDKを選択するか、「参照」をクリックして使用するJDKに移動します。12c (12.2.1.2)のサポート対象JDKバージョンは、1.8.0_101以降です。「次へ」をクリックします。

注意:
ここでは「ドメイン・モード」は変更できません。

特定のプラットフォームでサポートされているJDKのリストは、Oracle Fusion Middlewareでサポートされているシステム構成を参照してください。

4. 「JDBCデータ・ソース」画面で、ドメイン・ソースで定義したJDBCデータ・ソースを構成します。
ドメインを作成する製品に関連付けられるJDBCデータ・ソースは、画面の下半分にリスト表示されます。JDBCデータ・ソースには、データ・ソース・インスタンスの作成時、デプロイ時もしくはターゲット指定時、またはサーバー起動時に作成されるデータベース接続のプールが含まれます。 アプリケーションはJNDIツリーでデータ・ソースをルックアップしてから、接続をリクエストします。アプリケーションに接続する必要がなくなった場合は、接続がデータ・ソースの接続プールに戻されます。

「データソース名」ドロップダウン・リストから、設定を指定するデータ・ソースを選択します。指定した値は、選択されたデータ・ソースのデータ・ソース・リストの適切な列に表示されます。

データ・ソースがOracle RAC構成の場合は、次の3つのオプションのいずれかを選択できます。

- GridLinkへ変換

- RACマルチ・データ・ソースへ変換

- 変換しない

各オプションの詳細は、「ヘルプ」をクリックしてください。

詳細を指定したら、「次へ」をクリックします。

「JDBCデータ・ソース」画面でデータ・ソースを選択しないと、次に示す警告が表示されます。

ドライバがありません

「OK」をクリックして検証せずに続行するか、「取消」をクリックして「JDBCデータ・ソース」ページに戻ります。

この場合、「OK」をクリックしてもデータ・ソースは検証されません。

5. 「JDBCデータ・ソース・テスト」画面で、「JDBCデータ・ソース」画面で構成したデータ・ソース接続のチェック・ボックスを選択し、「選択された接続のテスト」をクリックしてデータ・ソース接続をテストします。

注意:
データベース接続をテストするには、接続するデータベースが起動している必要があります。接続をテストしない場合は、データ・ソースを選択しません。「次へ」をクリックして続行します。

6. 「データベース構成タイプ」画面で、「RCUデータ」を選択して、サーバー表(_STB)スキーマに接続します。
RCUサービス表(_STB)スキーマ資格証明を使用してデータベース接続の詳細を入力して、「RCU構成の取得」をクリックします。

再構成ウィザードは、この接続を使用してドメイン内のコンポーネントに必要なデータ・ソースを自動的に構成します。
注意: 既存の11gデータ・ソースの場合、再構成では既存の値が保存されます。RCUで12c用にスキーマが作成された新しいデータ・ソースの場合、デフォルトの接続データは_STBスキーマから取得されます。特定のスキーマの接続データが_STBスキーマにない場合は、デフォルトの接続データが使用されます。

チェックに成功したら、「次へ」をクリックします。チェックが失敗した場合は、接続の詳細を正しく入力し直して再試行します。

7. 「JDBCコンポーネント・スキーマ・テスト」画面で、すべてのコンポーネント・スキーマを選択して「選択された接続のテスト」をクリックして、各スキーマの接続をテストします。テストの結果は、「ステータス」列に表示されます。
チェックが終了したら、「次へ」をクリックします。

8. 「ノード・マネージャ」画面は、再構成するドメインで、ホストごとのノード・マネージャが使用されている場合にのみ表示されます。
「ノード・マネージャ」画面で、再構成したドメインで使用するノード・マネージャ構成を選択します。結果として生成される構成は、「ノード・マネージャ・タイプ」および「ノード・マネージャ構成」で選択したオプションの組合せに応じて異なります。

表6-5 ノード・マネージャ画面のフィールドの説明

オプション

説明

ドメインごとのデフォルトの場所

このオプションを選択すると、ノード・マネージャ・ホームはDOMAIN_NAME/nodemanagerに再定義され、ノード・マネージャ・ホームの編集ができなくなります。

ドメインごとのカスタムの場所

このオプションは、このドメインの特定の場所に、ドメインごとのノード・マネージャ構成ファイルを作成する場合に選択します。「ノード・マネージャ・ホーム」フィールドでディレクトリを指定するか、「参照」をクリックしてナビゲーション・ツリーを使用してその場所を選択します。指定するディレクトリは空である必要があります。このディレクトリに、nodemanager.propertiesおよびnodemanager.domainsファイルが作成されます。

ノード・マネージャ・ホーム

ドメインごとのカスタムの場所オプションを選択した場合は、「参照」をクリックして、ドメインごとのノード・マネージャ構成の格納に使用するディレクトリの場所に移動します。

手動ノード・マネージャ・セットアップ

このオプションを選択した場合は、ドメインのノード・マネージャ構成の作成がスキップされ、残りのフィールドはすべて変更できなくなるため、ドメインでノード・マネージャを使用する場合はノード・マネージャ構成の実行の説明に従って、ノード・マネージャを手動で構成する必要があります。再構成されたドメインでは、ホストごとのノード・マネージャ構成が引き続き使用されます。

既存のドメインがノード・マネージャを使用するように構成されておらず、再構成されたドメインでノード・マネージャを使用しない場合も、このオプションを選択する必要があります。

ノード・マネージャ構成の詳細は、『Oracle WebLogic Serverノード・マネージャの管理』を参照してください。

ノード・マネージャ構成

次の2つのオプションから1つを選択します。「手動ノード・マネージャ・セットアップ」を選択した場合は、次のフィールドを使用できません。

新規構成の作成

nodemanager.propertiesのデフォルトの設定を使用して、再構成されたドメインに、ドメインごとのノード・マネージャ構成が自動的に作成されます。ドメインが正常に再構成された後に、必要に応じて、nodemanager.propertiesを変更できます。

既存の構成を移行

すでに存在するホストごとのノード・マネージャ構成が、再構成されたドメインのドメインごとの構成に移行されます。これには、ListenAddress、ListenPort、StartScriptName、JavaHomeおよびLogFileの環境固有の設定は含まれません。

ノード・マネージャ・ホーム

「既存の構成を移行」オプションを選択した場合は、再構成したドメインの移行先にするノード・マネージャのホーム・ディレクトリを入力するか、参照してください。

Oracle推奨デフォルトの適用

このチェック・ボックスは、「既存の構成を移行」オプションを選択した場合に、nodemanager.propertiesファイルに指定されているOracle推奨のデフォルトを使用するときに選択します。移行されるnodemanager.propertiesファイルの設定を引き続き使用する場合は、このチェック・ボックスの選択を解除してください。

推奨されるプロパティのデフォルト値は次のとおりです。

LogLimit=0
AuthenticationEnabled=true
LogLevel=INFO
DomainsFileEnabled=true
NativeVersionEnabled=true
LogToStderr=true
SecureListener=true
LogCount=1
StopScriptEnabled=false
QuitEnabled=false
LogAppend=true
StateCheckInterval=500
CrashRecoveryEnabled=false
StartScriptEnabled=true
LogFormatter=weblogic.nodemanager.server.LogFormatter
ListenBacklog=50

ノード・マネージャ資格証明: ユーザー名、パスワード

再構成されたドメインで、ノード・マネージャの起動に使用するユーザー名とパスワードを指定します。

9. 「拡張構成」画面で、拡張構成を実行するすべてのカテゴリを選択できます。選択したカテゴリごとに、詳細構成を行うことができる適切な構成画面が表示されます。

注意:
「拡張構成」画面に表示されるカテゴリは、ドメインで選択したテンプレートに定義されているリソースによって異なります。

このアップグレードでは、オプションを選択せずに「次へ」をクリックします。

10. 「構成のサマリー」画面で、ドメインの詳細な構成を確認してから続行します。
「表示」ドロップダウン・リストからフィルタ・オプションを選択すると、右側のパネルに表示される項目を制限できます。

構成を変更するには、「戻る」をクリックして適切な画面に戻ります。ドメインを再構成するには、「再構成」をクリックします。

注意:
ドメインの再構成時には、ドメインの場所は変更されません。

11. 「再構成の進行状況」画面に、再構成プロセスの進行状況が表示されます。
このプロセスでは次の処理が行われます。

- ドメイン情報が抽出、保存および更新されます。

- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

プログレス・バーに100%が表示されたら、「次へ」をクリックします。

12. 「構成の終了」画面に、再構成プロセスが成功して完了したか、または失敗したかどうかが示されます。管理サーバーURL(リスニング・ポートを含む)とともに再構成されたドメインの場所も表示します。再構成が成功した場合は、「Oracle Weblogic Serverの再構成に成功しました」と表示されます。
再構成プロセスが正常に完了しなかった場合は、その理由を示すエラー・メッセージが表示されます。問題を解決するための適切な措置を講じます。問題を解決できない場合は、My Oracle Supportに連絡してください。

今後の操作での使用に備えて、ドメインの場所と管理サーバーのURLを記録しておきます。

6.7 ドメイン・コンポーネント構成のアップグレード

ドメインの再構成後、更新したドメイン構成と一致するように、ドメイン内でUpgrade Assistantを使用してドメイン・コンポーネント構成をアップグレードします。

- Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade Assistantは非SYSDBAとして実行して、一度にアップグレードするドメインは1つにすることをお薦めします。

- Upgrade Assistantを使用したドメイン・コンポーネントのアップグレード
Upgrade Assistantの各画面を通じて、WebLogicドメインのコンポーネント構成をアップグレードします。

- ドメイン固有コンポーネント構成のアップグレードの確認
ドメイン固有コンポーネント構成のアップグレードが成功したことを確認するには、管理コンソールおよびFusion Middleware Controlにログインし、各コンポーネントのバージョン番号が12.2.1.2であることを確認します。

6.7.1 Upgrade Assistantの起動

Upgrade Assistantを実行して、製品のスキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade Assistantは非SYSDBAとして実行して、一度にアップグレードするドメインは1つにすることをお薦めします。

Upgrade Assistantを起動するには、次の手順に従います。

1. oracle_common/upgrade/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. Upgrade Assistantを起動します。

- (UNIX) ./ua

- (Windows) ua.bat

コマンドラインに指定可能なその他のパラメータ(ロギングのパラメータなど)の詳細は、次を参照してください。

- Upgrade Assistantパラメータ

6.7.1.1 Upgrade Assistantパラメータ

コマンドラインからUpgrade Assistantを起動する際に、追加のパラメータを指定できます。

表6-6 Upgrade Assistantコマンドライン・パラメータ

パラメータ

必須/省略可能

説明

-readiness

準備状況チェックの場合は必須
注意: スタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では準備状況チェックを実行できません。

アップグレードの準備状況チェックを実行します(実際のアップグレードは実行しません)。

スキーマと構成がチェックされます。

-examineパラメータを指定した場合は、このパラメータを指定しないでください。

-threads

省略可能

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を特定します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須

レスポンス・ファイルに保存した入力を使用して、Upgrade Assistantを実行します。このレスポンス・ファイルは、GUIモードでUpgrade Assistantを実行したときの入力データから生成されます。このパラメータを使用すると、Upgrade Assistantがサイレント・モードで(Upgrade Assistant画面を表示せずに)実行されます。

-examine

省略可能

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel attribute

省略可能

次のいずれかの属性を指定して、ログイン・レベルを設定します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

デフォルトのロギング・レベルはNOTIFICATIONです。

-logLevel TRACE属性を設定して、より多くのログが記録されるようにすることを検討してください。これは、アップグレードの失敗をトラブルシューティングする際に役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir location

省略可能

アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。既存の書込み可能なディレクトリを指定する必要があります。Upgrade Assistantは、このディレクトリにログ・ファイルと一時ファイルを作成します。

デフォルトの場所は次のとおりです。

UNIXの場合:

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

Windowsの場合:

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

省略可能

すべてのコマンドライン・オプションを表示します。

6.7.2 Upgrade Assistantを使用したドメイン・コンポーネントのアップグレード

Upgrade Assistantの各画面を通じて、WebLogicドメインのコンポーネント構成をアップグレードします。

再構成ウィザードを実行して、WebLogicドメインを12c (12.2.1.2)にあわせて再構成したら、Upgrade Assistantを実行してドメイン・コンポーネント構成を更新後のドメイン構成と一致するようにアップグレードする必要があります。

Upgrade Assistantを使用して、ドメイン・コンポーネント構成をアップグレードするには:

1. 「ようこそ」画面には、Upgrade Assistantの概要と、アップグレード前のいくつかの重要なタスクについての情報が示されます。「次へ」をクリックします。

注意:
Upgrade Assistantの画面の詳細は、画面上の「ヘルプ」をクリックしてください。

2. 「WebLogicコンポーネント」画面で、「WebLogicコンポーネント構成」オプションを選択して、管理対象WebLogic Serverドメインのコンポーネント構成をアップグレードします。ドメインを管理しているWebLogic管理サーバーに接続するために必要な接続詳細を入力して、「次」をクリックします。

3. 「コンポーネント・リスト」画面で、構成をアップグレードするコンポーネントがリストにすべて含まれていることを確認し、「次」をクリックします。
アップグレードするコンポーネントがリストに含まれていない場合は、「戻る」をクリックして前の画面に戻り、別のドメインを指定します。

4. 「前提条件」画面で、すべてのチェック・ボックスを選択して、前提条件を満たしていることを確認します。「次へ」をクリックします。

注意:
Upgrade Assistantでは、前提条件が満たされているかどうかの確認は行われません。

5. 「調査」画面で、各コンポーネントを調査したUpgrade Assistantのステータスを確認して、コンポーネント構成のアップグレードの準備が整っていることを検証します。ステータスが「調査が終了しました。」になっている場合は、「次」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認します。一般的なアップグレード・エラーの解決方法の詳細は、Oracle Fusion Middleware Upgrade Assistantによるアップグレードのアップグレード・ガイドのアップグレードのトラブルシューティングに関する項を参照してください。

注意:

- 確認フェーズ中に検出された問題を、アップグレードを進めずに解決した場合は、バックアップからリストアを再び行わずにUpgrade Assistantを開始できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックしてアップグレードを続行していた場合は、Upgrade Assistantを再開する前に、バックアップからアップグレード前の環境をリストアする必要があります。

- 調査プロセスを取り消しても構成データに影響はありませんが、将来のアップグレード・セッションでは、Upgrade Assistantが収集した情報の再収集が必要になります。

6. 「アップグレード・サマリー」画面で、コンポーネント構成のアップグレードに選択したオプションのサマリーを確認します。
レスポンス・ファイルには、入力したすべての情報が収集および格納されます。このファイルにより、その後のサイレント・アップグレードの実行が可能になります。サイレント・アップグレードは、Upgrade Assistantとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。

7. 「アップグレードの進行状況」画面で、アップグレードのステータスを監視します。

注意:
アップグレード・アシスタントにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。これを行うと、環境が不安定になる可能性があります。

正しくアップグレードされていないコンポーネントがある場合は、Upgrade Assistantのログ・ファイルで情報を確認します。

注意:
この画面のプログレス・バーには、現在のアップグレード手順の進行状況が表示されます。アップグレードの残り時間を示すものではありません。

「次へ」をクリックします。

8. アップグレードが成功した場合: 「アップグレード成功」画面で、「閉じる」をクリックし、アップグレードを完了してウィザードを閉じます。新規インストールでコンポーネントを機能させるために手動で実行する必要のあるタスクが、アップグレード後のアクションのウィンドウに表示されます。このウィンドウは、コンポーネントにアップグレード後の手順がある場合にのみ表示されます。

アップグレードが失敗した場合: 「アップグレード失敗」画面で、「ログの表示」をクリックし、エラーを表示してトラブルシューティングします。ログは、ORACLE_HOME/oracle_common/upgrade/logsにあります。

注意:
アップグレードが失敗した場合は、アップグレード前の環境をバックアップからリストアし、問題を修正してから、Upgrade Assistantを再起動する必要があります。

6.7.3 ドメイン固有コンポーネント構成のアップグレードの確認

ドメイン固有コンポーネント構成のアップグレードが成功したことを確認するには、管理コンソールおよびFusion Middleware Controlにログインし、各コンポーネントのバージョン番号が12.2.1.2になっていることを確認します。

管理コンソールにログインするには、次に移動します: http://administration_server_host:administration_server_port/console

Fusion Middleware Controlにログインするには、次に移動します: http://administration_server_host:administration_server_port/em

注意:

アップグレード後、管理ツールは、前のOracleホームではなく新しい12cのOracleホームから必ず実行してください。

アップグレード・プロセス時に、一部のOWSMドキュメント(ポリシー・セット、ポリシーおよびアサーション・テンプレートなどの事前定義ドキュメント)のアップグレードが必要な場合があります。ポリシー・セットまたは事前定義ドキュメントがアップグレードされると、バージョン番号が1増分されます。

6.8 サーバーとプロセスの起動

アップグレードが正常に完了したら、すべてのプロセスと管理サーバーや管理対象サーバーを含めたすべてのサーバーを再起動します。

コンポーネントは相互に依存していることがあるため、適切な順序で起動する必要があります。

注意:
この項の手順では、WLSTコマンドラインまたはスクリプトを使用してサーバーとプロセスを起動する方法について説明します。また、Oracle Fusion Middleware ControlとOracle WebLogic Server管理コンソールを使用することもできます。『Oracle Fusion Middlewareの管理』の管理サーバーと管理対象サーバーおよびノード・マネージャの起動と停止に関する項を参照してください。

Fusion Middleware環境を起動するには、次に示す手順を実行します。

ステップ1: 管理サーバーの起動

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

管理サーバーを起動するには、startWebLogicスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/startWebLogic.sh

- (Windows) DOMAIN_HOME\bin\startWebLogic.cmd

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

ステップ2: ノード・マネージャを起動する

ノード・マネージャを起動するには、startNodeManagerスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/startNodeManager.sh

- (Windows) DOMAIN_HOME\bin\startNodeManager.cmd

ステップ3: Oracle Identity Managementのコンポーネントを起動する目的の環境に含まれるOracle Identity Managementのコンポーネント(Oracle Internet Directoryなど)を起動します。

- (UNIX) DOMAIN_HOME/bin/startComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\startComponent.cmd component_name

ステップ4: 管理対象サーバーを起動する

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

- (UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

- (Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url

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

注意:
通常、管理対象サーバーを起動すると、そのサーバーにデプロイされているアプリケーションが開始されます。したがって、管理対象サーバーの起動後にアプリケーションを手動で開始する必要はありません。

ステップ5: システム・コンポーネントを起動する

Oracle HTTP Serverなどのシステム・コンポーネントを起動するには、startComponentスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/startComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\startComponent.cmd component_name

システム・コンポーネントは任意の順序で起動できます。

- Oracle HTTP Serverの起動
Enterprise Manager Fusion Middleware Controlを使用すると、Oracle HTTP Serverを起動、停止および再起動できます。

6.8.1 Oracle HTTP Serverの起動

Enterprise Manager Fusion Middleware Controlを使用すると、Oracle HTTP Serverを起動、停止および再起動できます。

Oracle HTTP Serverは、ノード・マネージャで起動できます。起動の手順は、『Oracle Fusion Middleware Oracle HTTP Serverの管理』のリモートからのOracle HTTP Serverの実行に関する項を参照してください。

Enterprise Manager Fusion Middleware Controlを使用して、Oracle HTTP Serverを起動するには:

1. Oracle HTTP Serverのホーム・ページへ移動します。

2. 「Oracle HTTP Server」メニューから次の手順を実行します。

a. 制御を選択します。

b. 「コントロール」メニューから「起動」を選択します。

または

3. 「ターゲット・ナビゲーション」ツリーから次の手順を実行します。

a. 起動するOracle HTTP Serverインスタンスを右クリックします。

b. 制御を選択します。

c. 「コントロール」メニューから「起動」を選択します。

6.9 アップグレードの確認

管理コンソールとEnterprise Manager Fusion Middleware Controlにログインできれば、アップグレードは正常に完了しています。

アップグレードを確認するには:

1. 次に示すURLにサインインします。
http://MachineName.us.oracle.com:7777

2. Enterprise Manager Fusion Middleware Controlにアクセスするには、次のように指定します。
http://MachineName.us.oracle.com:7001/em

新しくアップグレードした環境を起動できない場合は、OracleウォレットでMD5証明書を使用していることが原因になっている可能性があります。MD5署名を使用しているかどうかのチェックの手順およびSHA-2証明書に置き換える手順については、「SHA-2アルゴリズムを使用して署名された証明書でMD5アルゴリズムを使用して署名された証明書を置き換え」を参照してください。

6.10 WLSTを使用したアップグレード後のKSSデータベースへのウォレットのインポート

Upgrade Assistantを使用して以前のバージョンのOracle HTTP Serverから12c (12.2.1.2)にアップグレードする場合は、追加のウォレット管理タスクを実行する必要があります。

ohs_postUpgradeコマンドを使用してOracle HTTP ServerインスタンスのウォレットをKSSデータベースにインポートします。

このコマンドはドメイン内のすべてのOracle HTTP Serverインスタンスを解析し、同じキーストア名に対するエントリがデータベースに存在しない場合は、KSSデータベースにウォレットをインポートします。このコマンドの詳細は、ohs_postUpgradeを参照してください。

1. コマンドラインからWLSTを起動します。

(UNIX) ORACLE_HOME/oracle_common/common/bin/wlst.sh

(Windows) ORACLE_HOME\oracle_common\common\/bin\wlst.cmd

2. 管理サーバー・インスタンスに接続します。
connect('<userName', '<password>', '<host>:<port>')

3. ohs_postUpgradeカスタムWLSTコマンドを実行します。次に例を示します。
ohs_postUpgrade()

A SHA-2アルゴリズムを使用して署名された証明書でMD5アルゴリズムを使用して署名された証明書を置き換え

Message Digest 5 Algorithm (MD5)で署名した証明書の使用は控えるようにしてください。MD5アルゴリズムのセキュリティには脆弱性が見つかっています。そのため、MD5アルゴリズムを使用して署名した証明書は、Secure Hashing Algorithm 2 (SHA-2)で署名した証明書に置き換える必要があります。デフォルトでは、MD5アルゴリズムを使用して署名した証明書は、Oracle HTTP Serverでサポートされなくなりました。

- ウォレット内にMD5アルゴリズムで署名した証明書が存在するかどうかを確認する方法
orapkiユーティリティを使用すると、MD5アルゴリズムで署名した証明書がウォレットに含まれているかどうかを表示できます。

- MD5アルゴリズムで署名された証明書をウォレットから削除する方法
署名アルゴリズム名(Signature algorithm name)が"MD5withRSA"と表示された場合は、MD5アルゴリズムで署名された証明書がウォレット内に存在することを意味します。この証明書は、SHA2アルゴリズムを使用して署名された証明書で置き換える必要があります。

- SHA-2アルゴリズムで署名された証明書をウォレットに追加する方法
MD5アルゴリズムで署名されたCA署名ユーザー証明書を使用している場合、認証局に連絡してSHA-2アルゴリズムで署名された新しいユーザー証明書を取得し、ウォレットにインポートします。

- MD5アルゴリズムで署名された証明書のサポートを12.2.1.2 Oracle HTTP Serverデプロイメントで有効にする方法
デフォルトでは、MD5アルゴリズムで署名された証明書のサポートは廃止されています。これは、MD5アルゴリズムのセキュリティに重大な脆弱性があるためです。それでもMD5アルゴリズムを使用して署名された証明書を使用する場合には、この項の手順に従ってMD5アルゴリズムで署名された証明書のサポートを有効化できます。ただし、MD5アルゴリズムで署名された証明書のサポートを有効化することは、お薦めできません。

A.1 ウォレット内にMD5アルゴリズムで署名した証明書が存在するかどうかを確認する方法

orapkiユーティリティを使用すると、MD5アルゴリズムで署名した証明書がウォレットに含まれているかどうかを表示できます。

MD5証明書がウォレット内に存在するかどうかを確認するには:

1. orapkiおよびkeytoolのパスを見つけます。
(orapki) ORACLE_HOME/oracle_common/bin/orapki

(Keytool) ORACLE_HOME/oracle_common/jdk/jre/bin

2. 次の手順で、JAVA_HOME環境変数を設定します。
export JAVA_HOME=ORACLE_HOME/oracle_common/jdk/jre/

3. 次に示すコマンドを入力して、ウォレットの内容を表示します。
orapki wallet display -wallet wallet_location

サンプル・コマンド:

ORACLE_HOME/oracle_common/bin/orapki wallet display -wallet /scratch/ohs12.2.1.x_install/walletohs2/

出力:

Oracle PKI Tool : Version 12.2.0.1.0
Copyright (c) 2004, 2016, Oracle and/or its affiliates. All rights reserved.

Requested Certificates:
User Certificates:
Subject: CN=www.xyx.com,C=IN
Trusted Certificates:
Subject: CN=www.xyx.com,C=IN

4. ウォレット内に存在する証明のドメイン名(DN)を特定します。この例では、「User Certificates」の「Subject」がウォレット内に存在するDNです("CN=www.xyx.com,C=IN")。

5. 次の例に示すように、ウォレット内に存在する証明書をエクスポートします。
orapki wallet export -wallet wallet_Location -dn 'DN_string' -cert certificate_file

サンプル・コマンド:

ORACLE_HOME/oracle_common/bin/orapki wallet export -wallet /scratch/ohs12.2.1.x_install/walletohs2/ -dn  'CN=www.xyx.com,C=IN' -cert wallet.cert

6. 次に示すコマンドを入力して、前の手順でエクスポートしたcertificate_fileの署名に使用されている署名アルゴリズムをkeytoolで確認します。
ORACLE_HOME/oracle_common/jdk/jre/bin/keytool -printcert -file certificate_file

サンプル・コマンド:

/scratch/ohs12.2.1.x_install/oracle_common/jdk/jre/bin/keytool -printcert -file wallet.cert

出力:

Owner: CN="Self-Signed Certificate for ohs3 ", OU=OAS, O=ORACLE, L=REDWOODSHORES, ST=CA, C=US
Issuer: CN="Self-Signed Certificate for ohs3 ", OU=OAS, O=ORACLE, L=REDWOODSHORES, ST=CA, C=US
Serial number: cd7081c47adb9ff867da01e3fe383e0f
Valid from: Fri Jul 01 04:21:40 PDT 2016 until: Sat Jun 19 04:21:40 PDT 2066
Certificate fingerprints:
MD5: 89:4D:C4:B4:28:7E:D4:0A:93:CA:E4:97:0C:F0:CE:86
SHA1: 53:FB:D6:58:0D:09:85:E9:6D:55:E2:92:E7:87:08:B8:65:92:15:9E
Signature algorithm name: MD5withRSA
Version: 1

「Signature algorithm name: MD5withRSA」は、ウォレット内に存在する証明書の署名に、MD5アルゴリズムが使用されていることを意味します。

A.2 MD5アルゴリズムで署名された証明書をウォレットから削除する方法

署名アルゴリズム名(Signature algorithm name)が"MD5withRSA"と表示された場合は、MD5アルゴリズムで署名された証明書がウォレット内に存在することを意味します。この証明書は、SHA2アルゴリズムを使用して署名された証明書で置き換える必要があります。

MD5アルゴリズムで署名された証明書をウォレットから削除するには:

1. 次に示すコマンドを入力して、MD5アルゴリズムで署名されたユーザー証明書を削除します。
orapki wallet  remove -wallet wallet_location -dn 'DN_string' -user_cert -auto_login_only

サンプル・コマンド:

/scratch/ohs12.2.1.x_install/oracle_common/bin/orapki wallet remove -wallet /scratch/ohs12.2.1.x_install/walletohs2/ -dn 'CN=www.xyx.com,C=IN' -user_cert -auto_login_only

出力:

Oracle PKI Tool : Version 12.2.0.1.0
Copyright (c) 2004, 2016, Oracle and/or its affiliates. All rights reserved.

2. ユーザー証明書が自己署名証明書の場合は、次に示すコマンドを入力して、その証明書を「信頼できる証明書」と「リクエストした証明書」のリストから削除します。
orapki  wallet  remove  -wallet  wallet_location -dn  'DN_string' -trusted_cert  -auto_login_only

orapki  wallet  remove  -wallet  wallet_location -dn  'DN_string' -cert_req  -auto_login_only

サンプル・コマンド:

/scratch/ohs12.2.1.x_install/oracle_common/bin/orapki wallet remove -wallet /scratch/ohs12.2.1.x_install/walletohs2/ -dn 'CN=www.xyx.com,C=IN' -trusted_cert -auto_login_only

出力:

Oracle PKI Tool : Version 12.2.0.1.0
Copyright (c) 2004, 2016, Oracle and/or its affiliates. All rights reserved.

3. MD5アルゴリズムを使用して署名された信頼できる証明書または証明書リクエストがウォレットにある場合、次のコマンドを入力してその証明書を削除します。
orapki wallet remove -wallet wallet_location -dn 'DN_string' -trusted_cert -auto_login_only remove cert request

orapki wallet remove -wallet wallet_location -dn 'DN_string' -cert_req -auto_login_only

A.3 SHA-2アルゴリズムで署名された証明書をウォレットに追加する方法

MD5アルゴリズムで署名されたCA署名ユーザー証明書を使用している場合、認証局に連絡してSHA-2アルゴリズムで署名された新しいユーザー証明書を取得し、ウォレットにインポートします。

SHA-2アルゴリズムを使用して署名された、自己署名証明書を追加する方法は次のとおりです。

1. 証明書が自己署名の場合、次のコマンドを入力して、SHA-2アルゴリズムを使用して署名された自己署名証明書を追加します。
orapki wallet add -wallet wallet_Location  -dn 'DN_String' -keysize 2048 -sign_alg sha256  -self_signed -validity 9125 -auto_login_only

サンプル・コマンド:

/scratch/ohs12.2.1.x_install/oracle_common/bin/orapki wallet add -wallet /scratch/ohs12.2.1.x_install/walletohs2/ -dn 'CN=www.xyx.com,C=IN' -keysize 2048 -sign_alg sha256  -self_signed -validity 9125 -auto_login_only

2. 次のコマンドを入力することで、SHA-2アルゴリズムを使用して署名された信頼できる証明書をウォレットに追加します。
orapki -wallet add -wallet wallet_location -trusted_cert -cert certificate_file -auto_login_only

3. 次のコマンドを入力することで、SHA-2アルゴリズムを使用して署名されたユーザー証明書をウォレットに追加します。
orapki -wallet add -wallet wallet_location -user_cert -cert certificate_file -auto_login_only

証明書ファイルを出力したときに、「Signature algorithm name」が「SHA256withRSA」と表示される場合は、操作が成功しています。サンプル出力は次のようになります。

Owner: CN=www.xyx.com, C=IN
Issuer: CN=www.xyx.com, C=IN
Serial number: f689ec6986c70f973138962eb2f0e5f9
Valid from: Wed May 11 04:01:24 PDT 2016 until: Sat Oct 27 04:01:24 PDT 2018
Certificate fingerprints:
MD5:  D7:0F:CB:00:A7:04:33:DA:2F:8A:AD:C9:2A:9E:DF:26
SHA1: D4:6C:51:DB:53:B5:F5:C7:60:8D:8B:95:68:E6:B0:5E:E8:00:ED:DF
SHA256: B1:EF:73:98:EA:6A:1A:60:FF:1F:10:89:8C:B8:16:63:71:03:1B:6E:38:D1:2D:AE:E9:BD:3E:13:BE:AF:A0:76
Signature algorithm name: SHA256withRSA
Version: 1

A.4 MD5アルゴリズムで署名された証明書のサポートを12.2.1.2 Oracle HTTP Serverデプロイメントで有効にする方法

デフォルトでは、MD5アルゴリズムで署名された証明書のサポートは廃止されています。これは、MD5アルゴリズムのセキュリティに重大な脆弱性があるためです。それでもMD5アルゴリズムを使用して署名された証明書を使用する場合には、この項の手順に従ってMD5アルゴリズムで署名された証明書のサポートを有効化できます。ただし、MD5アルゴリズムで署名された証明書のサポートを有効化することは、お薦めできません。

MD5アルゴリズムで署名された証明書のサポートを有効化するには:

1. スタンドアロンOracle HTTP Serverデプロイメントの場合:

a. Oracle HTTP Serverインスタンスとノード・マネージャを停止します。

b. 次に示すステージング・ディレクトリに変更します。
(UNIX) ORACLE_HOME/user_projects/domains/base_domain/config/fmwconfig/components/OHS/ohs1/

(Windows) ORACLE_HOME\user_projects\domains\base_domain\config\fmwconfig\components\OHS\ohs1\

c. 編集モードでohs.plugins.nodemanager.propertiesファイルを開いて、次に示す行を追加します。
environment.ORACLE_SSL_ALLOW_MD5_CERT_SIGNATURES = 1

d. ノード・マネージャとOracle HTTP Serverインスタンスを再起動します。

2. 管理対象Oracle HTTP Serverデプロイメントの場合:

a. Oracle HTTP Serverインスタンス、ノード・マネージャおよびWebLogic Serverを停止します。

b. 次に示すステージング・ディレクトリに変更します。
(UNIX) ORACLE_HOME/user_projects/domains/base_domain/config/fmwconfig/components/OHS/ohs1/

(Windows) ORACLE_HOME\user_projects\domains\base_domain\config\fmwconfig\components\OHS\ohs1\

c. 編集モードでohs.plugins.nodemanager.propertiesファイルを開いて、次に示す行を追加します。
environment.ORACLE_SSL_ALLOW_MD5_CERT_SIGNATURES = 1

d. WebLogic Server、ノード・マネージャおよびOracle HTTP Serverインスタンスを再起動します。

Oracle HTTP Serverインスタンスごとに、この手順を実行する必要があります。

Oracleの法律上の注意点

コピーライト

Copyright © 1994-2017, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

Pre-General Availability (一般提供前)版のドキュメントについて

このドキュメントがPre-General Availability (一般提供前)版の場合:

このドキュメントはPre-General Availability (一般提供前)版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のPre-General Availability (一般提供前)版のドキュメントについて

このドキュメントが非公開のPre-General Availability (一般提供前)版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のPre-General Availability Trial Agreement (Pre-GAトライアル契約)のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle Partner Network Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティ

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info)か、聴覚に障害のあるお客様は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。