Oracle® Fusion Middleware

Oracle HTTP Serverのアップグレード

12c (12.2.1.1)

E77367-01(原本部品番号:E71495-01)

2016年6月

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

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

E77367-01

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

原本著者: Priyanka Chheda

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

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

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

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へのアップグレードの理解

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

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

- 1.3 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ビット・オペレーティング・システムへの移行(32ビットOSの場合のみ必須)

- 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ユーザーの作成

第I部 スタンドアロンOracle HTTP Serverのアップグレード

3 スタンドアロンOracle HTTP Serverのアップグレードの概要

- 3.1 スタンドアロンOracle HTTP Serverトポロジの理解

- 3.2 スタンドアロンOracle HTTP Serverのアップグレード・プロセスの概要

- 3.2.1 スタンドアロン・アップグレード・プロセスのフロー・チャート(11gから12c)

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

- 3.2.3 スタンドアロンOracle HTTP Serverのアップグレード・プロセスのフロー・チャート(以前の12cリリースから)

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

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

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

- 4.1.1 Oracle Web Cache 11gユーザー

- 4.1.2 WebGate 11gユーザー

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

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

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

- 4.2 11gのスタンドアロンOracle HTTP Serverのアップグレード

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

- 4.2.2 Upgrade Assistantを使用した11gドメインのアップグレード

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

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

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

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

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

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

- 5.3 Upgrade Assistantを使用した12cドメインのアップグレード

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

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

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

第II部 管理対象Oracle HTTP Serverのアップグレード

6 管理対象Oracle HTTP Serverのアップグレードの概要

- 6.1 管理対象Oracle HTTP Serverのアップグレード・プロセスのフローチャート

- 6.2 管理対象Oracle HTTP Serverのアップグレード・ロードマップ

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

- 7.1 管理対象12c (12.2.1.1.0) Oracle HTTP Serverのインストール

- 7.2 アップグレード前の必要なスキーマの作成

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

- 7.4 Upgrade Assistantを使用したコンポーネント構成のアップグレード

- 7.5 アップグレード後のタスク

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

- 7.5.2 管理サーバーの起動

- 7.5.3 Oracle HTTP Serverの起動

- 7.5.4 Oracle HTTP Serverインストール成功の確認

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

- 8.1 管理対象12c (12.2.1.1.0) Oracle HTTP Serverのインストール

- 8.2 Upgrade Assistantを使用した既存の12cスキーマのアップグレード

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

- 8.4 Upgrade Assistantを使用したコンポーネント構成のアップグレード

- 8.5 アップグレード後のタスク

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

- 8.5.2 管理サーバーの起動

- 8.5.3 Oracle HTTP Serverの起動

- 8.5.4 Oracle HTTP Serverインストール成功の確認

はじめに

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

- 対象読者

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

- 関連ドキュメント

- 表記規則

対象読者

このマニュアルは、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を参照してください。

関連ドキュメント

詳細は、Oracle Fusion Middleware 12cのドキュメント・ライブラリにある次の関連ドキュメントを参照してください。

- Oracle Fusion Middlewareのアップグレードのプランニング

- Oracle HTTP Serverのインストールと構成

- Oracle HTTP Serverの管理

- 『Oracle Fusion Middlewareの管理』

- Oracle Fusion Middlewareの理解

- Oracle Fusion Middleware Infrastructureへのアップグレード

表記規則

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

表記規則

意味

太字

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

イタリック

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

固定幅フォント

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

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

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

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

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

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

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

- インストーラは、Oracle HTTP Serverの個別のインスタンス・ディレクトリを作成しなくなりました。スタンドアロンOHSのインスタンス情報は、新しいスタンドアロン・ドメインホームに格納されます。詳細は、スタンドアロンOracle HTTP Serverのトポロジの理解を参照してください。

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

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

なし。

1 Oracle HTTP Serverの12cへのアップグレードの理解

Oracle HTTP Serverを12cにアップグレードする前に、Oracle HTTP Server 11gデプロイメントとの違いを理解している必要があります。

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

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

- 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ノード・マネージャを使用して、WebLogic Serverドメイン内にある他の要素と同様に管理できるためです。Oracle HTTPソフトウェアを、Oracle Fusion Middleware Infrastructureをインストールせずに個別のOracleホームにインストールする方法は、スタンドアロン・モードと呼ばれます。

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

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

表1-1は、Oracle HTTP Server 11gと12cの主な違いを表しています。

表1-1 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.2 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-2に示します。

表1-2 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ノード・マネージャ・ソフトウェアを使用して管理されます。

1.3 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ノード・マネージャを使用して、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のアップグレードの準備

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

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

- Oracle Fusion Middlewareアップグレード前のチェックリスト
Oracle Fusion Middlewareアップグレード前のチェックリストでは、少ないダウンタイムでアップグレードを成功させるため、アップグレードを開始する前に実行できるタスクを識別します。

- 完全なバックアップの作成
新しい12c (12.2.1)ディストリビューションをインストールして、既存のOracle Fusion Middlewareデプロイメントのアップグレードを開始する前に、Oracle Fusion Middlewareスキーマをホストするすべてのデータベースを含む、システムに重要なすべてのファイルを必ずバックアップします。

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

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

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

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

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

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

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

Oracle Fusion Middlewareアップグレード前のチェックリストでは、少ないダウンタイムでアップグレードを成功させるため、アップグレードを開始する前に実行できるタスクを識別します。

アップグレードは、サーバーがダウンしている間に実行されます。このチェックリストは、ダウンタイムを少なくするため、時間がかかることが多い重要なアップグレード前タスクのうち、アップグレード前に実行できるものを識別することを目的としています。アップグレード・プロセスの開始前により多くの準備を実施できると、オフラインの時間が短くなります。

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

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

タスク

説明

ドキュメント

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

必須

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

アップグレードに失敗した場合は、アップグレード前の環境をリストアして、アップグレードを改めて開始できます。

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

既存のドメインに含まれる起動スクリプトを変更した場合は、アップグレードの間そのファイルを一時的なディレクトリの場所(既存のドメインの外部)にコピーし、アップグレード後に再デプロイする必要があります。

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

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

オプション

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

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

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

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

必須

ハードウェアとソフトウェア(オペレーティング・システムも含む)の構成が最新の動作保証および要件のドキュメントでサポートされていることを確認してください。

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

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

また、12c製品ディストリビューションをインストールする前に、JDKのサポート対象バージョンを使用するようにします。

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

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

32ビットから64ビット・オペレーティング・システムへの移行(32ビットOSの場合のみ必須)

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

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

オプション

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

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

アップグレードする前に期限切れまたは未使用のデータをパージします。

オプション

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

インスタンスのアップグレードを開始する前に、パージ・スクリプトを使用して、アップグレードした12c環境では不要になるクローズされた11gインスタンスをパージします。

未使用データのパージ

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

EBRデータベースを使用している場合は必須

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

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

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

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

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

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

新しい12c (12.2.1)ディストリビューションをインストールして、既存のOracle Fusion Middlewareデプロイメントのアップグレードを開始する前に、Oracle Fusion Middlewareスキーマをホストするすべてのデータベースを含む、システムに重要なすべてのファイルを必ずバックアップします。

スキーマ・アップグレードを実行する前にデータベースを完全にバックアップすることは、Upgrade Assistantを実行するための前提条件です。実際のアップグレードを続行する前に、Upgrade Assistant前提条件のGUI画面で、バックアップが実行されていることを確認する必要があります。

詳細は、Oracle Fusion Middleware環境のバックアップおよび12cのためのOracle Databaseのアップグレードおよび準備を参照してください。

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

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

- カスタム・ドメイン環境設定のメンテナンス
各ドメインには、動的に生成されるドメインおよびサーバーの起動スクリプト(setDomainEnvなど)が含まれます。起動スクリプトに行った変更は、その後のドメインのアップグレードおよび再構成操作中に上書きされるため、これらの起動スクリプトを変更しないでください。

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

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

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

注意:
スキーマ・アップグレードを実行する前にこれらのバックアップを実行することは、Upgrade Assistantを実行するための前提条件です。実際のアップグレードを続行する前に、Upgrade Assistant前提条件のGUI画面で、バックアップが実行されていることを確認する必要があります。

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

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

カスタム・ドメイン・レベルの環境設定を維持するには、アップグレードの前に、カスタム・ドメイン情報を格納するファイルを別途作成してください。

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

setUserOverridesファイルにおける起動のカスタマイズの例を次に示します。

# add custom libraries to the WebLogic Server system claspath
if [ "${POST_CLASSPATH}" != "" ] ; then
POST_CLASSPATH="${POST_CLASSPATH}${CLASSPATHSEP}${HOME}/foo/fooBar.jar"
export POST_CLASSPATH
else
POST_CLASSPATH="${HOME}/foo/fooBar.jar"
export POST_CLASSPATH
fi

# specify additional java command line options for servers
JAVA_OPTIONS="${JAVA_OPTIONS}  -Dcustom.property.key=custom.value"

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

注意:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- このリリースのOracle Fusion MiddlewareでJDKが動作保証されていることの確認
汎用インストーラを使用してOracle Fusion Middleware製品をインストールするには、インストーラを実行する前に、サポートされているJDKをシステムにダウンロードしてインストールする必要があります。

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

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

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

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

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

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

Oracle Fusion Middleware 12cのインストールおよび12cへのアップグレードの詳細は、「システム要件と仕様のレビュー」を参照してください。

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

- 32ビットから64ビット・オペレーティング・システムへの移行(32ビットOSの場合のみ必須)
この手順は、32ビット環境を実行している場合にのみ必要です。OSが32ビットの場合は、アップグレード前に、32ビット環境を64ビット・ソフトウェア環境に移行する必要があります。

2.4.2.1 32ビットから64ビット・オペレーティング・システムへの移行(32ビットOSの場合のみ必須)

この手順は、32ビット環境を実行している場合にのみ必要です。OSが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 すべてのプロセスを停止する

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

たとえば、管理サーバーを停止するには、次のコマンドを入力します。

DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]

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ホームでインストールする必要があります。

12cディストリビューションの入手方法の詳細は、製品ディストリビューションの理解と入手を参照してください。インストール・ユーザーを識別するには、インストール・ユーザーの選択を参照してください。インストールおよび構成用のディレクトリ構造を理解するには、インストールおよび構成のためのディレクトリの理解を参照してください。インストールするコンポーネントの詳細は、コンポーネント固有のインストール・ガイドを参照してください。

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

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

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

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

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

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

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

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

汎用インストーラを使用してOracle Fusion Middleware製品をインストールするには、サポートされているJDKをシステムにダウンロードしてインストールする必要があります。

このマニュアルの発行時における動作保証されたJDKは1.8.0_77でした。

必要なJDKをダウンロードするには、ブラウザで次のURLにアクセスして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 未使用データのパージ

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

注意:
大量のデータをパージする必要がある場合は、表のパーティション化や、その他のデータ最適化戦略の採用について検討してください。大量のデータを削除するスクリプトを使用すると、パフォーマンスに影響を与えることがあります。「パージおよびパーティショニング方法の開発」と「データベース増分管理戦略の策定」を参照してください

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

Oracle Data Integrator (ODI)コンポーネントの場合:

次の手順で作業リポジトリのエクスポート/インポートの一部として過剰なデータがエクスポートおよびインポートされないように、実行ログをパージします。「ログのパージ」を参照してください

SOA Suiteコンポーネントの場合:

クローズされた11gインスタンス・データを移行している場合は、アップグレードの実行前にインスタンスのパージ・スクリプトを実行します。インスタンス・データのパージ・スクリプトの使用を参照してください。

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ユーザーを作成することをお薦めします。FMWユーザーには、スキーマを変更するために必要な権限は付与されますが、完全な管理者権限は与えられません。

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

注意:
v$xatrans$表は、デフォルトでは存在しません。この表を作成するには、このユーザーを作成する前にXAVIEW.SQLスクリプトを実行する必要があります。さらに、v$xatrans$表の権限は、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;

注意:

Oracle Database 11.2.0.3データベース・ユーザーのみ: アップグレードを開始する前に、Oracleパッチ13036331を適用する必要があります。My Oracle Supportにアクセスしてパッチをダウンロードします。

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

第I部 スタンドアロンOracle HTTP Serverのアップグレード

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

- スタンドアロンOracle HTTP Serverのアップグレードの概要
この章では、Oracle Fusion MiddlewareのスタンドアロンOracle HTTP Serverの概略を紹介し、Oracle Fusion Middleware 11gまたは以前の12cリリース(12.1.2以降)のOracle HTTP ServerからこのOracle HTTP Server 12cリリース(12.2.1.1)にアップグレードするために実行する必要がある手順の概要を説明します。

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

- スタンドアロンOracle HTTP Serverのアップグレード(以前の12cリリースから)
この章では、スタンドアロンOracle HTTP Serverを以前のスタンドアロンOracle HTTP Server 12cリリースから最新の12cにアップグレードするためのプロセスについて説明します。

3 スタンドアロンOracle HTTP Serverのアップグレードの概要

この章では、Oracle Fusion MiddlewareのスタンドアロンOracle HTTP Serverの概略を紹介し、Oracle Fusion Middleware 11gまたは以前の12cリリース(12.1.2以降)のOracle HTTP ServerからこのOracle HTTP Server 12cリリース(12.2.1.1)にアップグレードするために実行する必要がある手順の概要を説明します。

注意:

この項は、WebLogic Serverドメイン経由で管理されていないOracle HTTP Serverをアップグレードする場合に利用してください。

Oracle HTTP ServerをOracle WebLogicから管理している場合は、管理対象Oracle HTTP Serverのアップグレードの手順に従ってください。

この章の内容は次のとおりです。

- スタンドアロン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 HTTP Serverをアップグレードするための有効な開始ポイントは、11gリリース11.1.1.7およびそれ以降と、12cリリース12.1.2およびそれ以降です。

親トピック: スタンドアロンOracle HTTP Serverのアップグレード

3.1 スタンドアロン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 HTTP Serverのインストールと構成」を参照

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

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

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

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

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

表3-1は、このトポロジの要素を説明しています。

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

要素

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

WEBHOST

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

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

スタンドアロン・ドメインは11gから12cにアップグレードする場合にのみ作成されます。12.1.2または12.1.3からアップグレードする場合、スタンドアロン・ドメインはすでに存在するので、スタンドアロン・ドメインを作成する必要はありません。

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

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

3.2 スタンドアロンOracle HTTP Serverのアップグレード・プロセスの概要

Oracle HTTP Serverをアップグレードするための有効な開始ポイントは、11gリリース11.1.1.7およびそれ以降と、12cリリース12.1.2およびそれ以降です。

この後の項では、スタンドアロンOracle HTTP Serverのアップグレードを実行する手順の概要を説明します。

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

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

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

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

3.2.1 スタンドアロン・アップグレード・プロセスのフロー・チャート(11gから12c)

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

スタンドアロンOracle HTTP Serverのアップグレードの詳細な手順は、スタンドアロンOracle HTTP Serverのアップグレード(11gから12c)で説明します。

注意:
アップグレードを開始する前に、11gインスタンスをシャットダウンする必要があります。

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

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

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

表3-2 スタンドアロンOracle HTTP Serverのアップグレード・プロセスのロードマップ

手順番号

重要度(必須、条件付きまたはオプション)

タスク

説明

1

推奨。

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

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

2

オプション。

BI 12.2.1.1へのアップグレード方法に影響する可能性のある、相互運用性および互換性の要因について学びます。

サポートされるOracle Fusion Middleware構成で、同一バージョンまたは異なるバージョンの2つ以上のOracle Fusion Middleware製品がどのように連携(相互運用)するかを理解することは重要です。

相互運用性および互換性の詳細は、相互運用性および互換性の理解を参照してください。

3

必須。

既存の環境をバックアップします。

ドメイン構成がアップグレードされて置き換えられるため、アップグレード前に既存の環境をバックアップすることが重要です。バックアップを作成することで、アップグレードが失敗した場合や、アップグレード結果が満足なものでなかった場合にアップグレード前の環境をリストアできます。

4

必須。

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

アップグレード前タスクには、本番環境のクローニング、システム要件や動作保証の確認、未使用データのパージ、非SYSDBAユーザーの作成などがあります。

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

5

必須。

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

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

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

6

必須。

Upgrade Assistantを使用して11gのドメイン構成をアップグレードします。

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

Upgrade Assistantを使用した11gドメインのアップグレードを参照してください。

7

必須。

アップグレード後のタスクを実行して、アップグレードを検証します。

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

Oracle HTTP Serverの管理のOracle HTTP Serverのトラブルシューティングを参照してください。

3.2.3 スタンドアロンOracle HTTP Serverのアップグレード・プロセスのフロー・チャート(以前の12cリリースから)

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

スタンドアロンOracle HTTP Serverのアップグレードの詳細な手順は、スタンドアロンOracle HTTP Serverのアップグレード(以前の12cリリースから)で説明します。

注意:
アップグレードを開始する前に、12cインスタンスをシャットダウンする必要があります。

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

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

表3-3では、スタンドアロンOracle HTTP Serverを12cの以前のリリースから最新バージョンにアップグレードするために実行する必要があるタスクを説明します。

表3-3 スタンドアロンOracle HTTP Serverのアップグレード・プロセスのロードマップ

手順番号

重要度(必須、条件付きまたはオプション)

タスク

説明

1

推奨。

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

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

2

オプション。

BI 12.2.1.1へのアップグレード方法に影響する可能性のある、相互運用性および互換性の要因について学びます。

サポートされるOracle Fusion Middleware構成で、同一バージョンまたは異なるバージョンの2つ以上のOracle Fusion Middleware製品がどのように連携(相互運用)するかを理解することは重要です。

相互運用性および互換性の詳細は、相互運用性および互換性の理解を参照してください。

3

必須。

既存の環境をバックアップします。

ドメイン構成がアップグレードされて置き換えられるため、アップグレード前に既存の環境をバックアップすることが重要です。バックアップを作成することで、アップグレードが失敗した場合や、アップグレード結果が満足なものでなかった場合にアップグレード前の環境をリストアできます。

4

必須。

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

アップグレード前タスクには、本番環境のクローニング、システム要件や動作保証の確認、未使用データのパージ、非SYSDBAユーザーの作成などがあります。

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

5

必須。

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

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

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

6

必須。

既存のドメインを再構成します。

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

再構成ウィザードを使用した既存のドメインの再構成を参照してください。

7

必須。

Upgrade Assistantを使用してドメイン構成をアップグレードします。

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

Upgrade Assistantを使用した12cドメインのアップグレードを参照してください。

8

必須。

アップグレード後のタスクを実行して、アップグレードを検証します。

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

Oracle HTTP Serverの管理のOracle HTTP Serverのトラブルシューティングを参照してください。

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

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

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

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

- 11gのスタンドアロンOracle HTTP Serverのアップグレード
スタンドアロンのOracle HTTP Serverを11gから12cにアップグレードすることは、適切な方法ではありません。新しいOracleホームにOracle HTTP Server 11gソフトウェアをインストールし、次にUpgrade Assistantを使用して11gドメインをアップグレードする必要があります。

親トピック: スタンドアロンOracle HTTP Serverのアップグレード

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

アップグレードを開始する前に、アップグレード中またはその後に既存の設定が影響を受けないことを確認することが重要です。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リリース12.2.1では、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のアプリケーション・アーティファクトの移行

4.1.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の両方を使用し、それらをOracle WebLogic Server (WLS)ドメインに登録してEnterprise Manager Fusion Middleware Controlによって管理している場合は、WLSドメインも12cにアップグレードする必要があります。この場合、関連付けられたOracle HTTP Serverも12cにアップグレードされます。ただし、Web Cacheは、12cのFusion Middleware Controlから削除されます。

4.1.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.1では、WebGateのログ・ファイル名がoblog.logからwebgate.logに変更されました。Oracle HTTP Serverの最新リリースへのアップグレード後に、oblog_config_wg.xmlファイルを手動で更新して、ファイル内に出現する「oblog.log」の各エントリを「webgate.log」に置き換える必要があります。このタスクを実行する手順は、WebGateのログ・ファイル名の更新を参照してください。

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

Oracle Fusion Middleware 12cリリース12.2.1では、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」に置換します。

4.1.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のアプリケーション・アーティファクトの移行」を参照してください。

4.1.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インスタンスの構成ディレクトリに手動でコピーするか、またはアップグレードされた構成を修正して別の場所で参照する必要があります。他のタイプのアプリケーション・アーティファクトは、同様の手順で手動で移行する必要があります。

4.2 11gのスタンドアロンOracle HTTP Serverのアップグレード

スタンドアロンのOracle HTTP Serverを11gから12cにアップグレードすることは、適切な方法ではありません。新しいOracleホームにOracle HTTP Server 11gソフトウェアをインストールし、次にUpgrade Assistantを使用して11gドメインをアップグレードする必要があります。

次のタスクを実行して、スタンドアロンOracle HTTP Serverのアップグレードを完了します。

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

- Upgrade Assistantを使用した11gドメインのアップグレード

- アップグレードの確認

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

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

1. 12.2.1.1製品ディストリビューションをインストールするターゲット・システムにサインインします。

2. Oracle HTTP Serverディストリビューション(UNIX向けのfmw_12.2.1.1.0_ohs_linux64.binとWindows向けのsetup_fmw_12.2.1.1.0_ohs_win64.exe)を、ターゲット・システム上でOracle Technology NetworkまたはOracle Software Delivery Cloudからダウンロードします。

3. Oracle HTTP Serverディストリビューションをダウンロードしたディレクトリに移動します。

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

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

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

5. 次のコマンドを入力して、インストール・プログラムを開始します。
UNIXオペレーティング・システムの場合:

./ohs_linux64.bin

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

setup_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インストールの計画のインストールと構成のディレクトリの選択を参照してください。

10. 「インストール・タイプ」画面で、「スタンドアロンHTTPサーバー(WebLogic Serverとは切り離して管理)」を選択し、「次へ」をクリックします。
インストール・タイプについて詳しくは、Oracle HTTP Serverのインストールと構成のOracle HTTP Serverの標準インストール・トポロジの概要を参照してください。

11. 「前提条件チェック」画面で、ホスト・コンピュータを分析して、特定のオペレーティング・システムの前提条件を満たしているか確認します。
前提条件のチェックが失敗すると、エラー・メッセージが画面の下方に表示されます。エラーを修正し、「再実行」をクリックして再試行します。

エラーや警告メッセージを無視してインストールを続ける場合は、「スキップ」をクリックします(このアプローチはお薦めできません)。

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

13. 「インストール・サマリー」画面で、選択したインストール・オプションを確認します。
これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を入力します。レスポンス・ファイルを使用して、サイレント・インストールを実行できます。「インストール」をクリックします。

14. 「インストールの進行状況」画面のプログレス・バーに100%が表示されたら、「次へ」をクリックします。

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

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

4.2.2 Upgrade Assistantを使用した11gドメインのアップグレード

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

1. 次のコマンドを入力して、Upgrade Assistantを12.2.1.1のOracleホームから実行します。
UNIXオペレーティング・システムの場合:

$Oracle_Home/oracle_common/upgrade/bin/ua

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

%Oracle_Home%\oracle_common\upgrade\bin\ua.bat

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

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

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

注意:

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

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

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

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

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

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

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

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

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

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

表4-1 ノード・マネージャ画面のフィールドの説明

オプション

説明

ユーザー名

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

パスワード

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

リスニング・アドレス

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

リスニング・ポート

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

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

9. 「調査」画面には、各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを検証するUpgrade Assistantのステータスが表示されます。ステータスが「調査が終了しました。」になっている場合は、「アップグレード」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログ・ボックスの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、共通するアップグレード・エラーの解決に関する情報をアップグレードのトラブルシューティングで参照します。

注意:

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

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

10. 「アップグレード・サマリー」画面でツリーを展開して、選択したオプションの概要を確認します。
アップグレードに進む前に、ソース・バージョンとターゲット・バージョンを参照して、両方のバージョンが正しいことを確認してください。

レスポンス・ファイルには、Upgrade Assistantのグラフィカル・ユーザー・インタフェース画面で入力したすべての情報が収集して格納され、後でサイレント・アップグレードを実行するために使用できます。サイレント・アップグレードは、Upgrade Assistantウィザードとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。これらのオプションをレスポンス・ファイルに保存する場合、「保存」をクリックし、レスポンス・ファイルの名前および場所を指定します。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。

11. 「アップグレードの進行状況」画面に、アップグレード・プロセスのステータスと、アップグレードが成功した後のコンポーネントの予測ターゲット・バージョンが表示されます。「次へ」をクリックします。

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

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

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

13. アップグレードに失敗すると、「アップグレード失敗」画面が表示されます。これは、1つ以上のコンポーネントのアップグレードに失敗したことを示します。今行った操作では、コンポーネントをアップグレードできません。
「ログの表示」をクリックすると、エラーの表示およびトラブルシューティングを行えます。

Upgrade Assistantを再び起動する前に、アップグレード前の環境の問題を修正します。アップグレード前の環境をバックアップからリストアし(元のバックアップ・ファイルは必ず別の場所に保持してください)、問題を修正し、Upgrade Assistantを再起動します。

4.2.3 アップグレードの確認

ノード・マネージャおよびスタンドアロンOracle HTTP Serverを正しく起動できれば、アップグレードが成功したことを確認できます。アップグレード後の問題が発生した場合は、インストールのトラブルシューティングを実行してアップグレードを再試行する必要があります。詳細は、Oracle HTTP Server管理者ガイドのOracle HTTP Serverのトラブルシューティングを参照してください。

ノード・マネージャとスタンドアロンOracle HTTP Serverを起動する方法を次のトピックで参照してください。

- ノード・マネージャの起動
WebLogic Serverの本番環境では、サーバー・インスタンスが複数のドメイン、マシンおよび地理的な場所にまたがって分散することがよくあります。ノード・マネージャは、Oracle HTTP Serverインスタンスの管理(起動、停止および再起動)に使用できるWebLogic Serverユーティリティです。

- スタンドアロンOracle HTTP Serverの起動
startComponent.sh|cmdスクリプトを使用して、スタンドアロンOracle HTTP Serverを起動できます。

4.2.3.1 ノード・マネージャの起動

WebLogic Serverの本番環境では、サーバー・インスタンスが複数のドメイン、マシン、および地理的な場所にまたがって分散することがよくあります。ノード・マネージャは、Oracle HTTP Serverインスタンスの管理(起動、停止および再起動)に使用できるWebLogic Serverユーティリティです。

Windowsオペレーティング・システムの場合は、ノード・マネージャを起動サービスとして実行するように構成することをお薦めします。これによって、システムが再起動されるたびに、ノード・マネージャが自動で起動されます。詳細は、『Oracle WebLogic Serverノード・マネージャの管理』の起動サービスとしてのノード・マネージャの実行に関する項を参照してください。

注意:
UNIXプラットフォームでは、ノード・マネージャをルート・ユーザーとして実行しないでください。

1. 次のディレクトリに移動します。
UNIXオペレーティング・システムの場合:

$DOMAIN_HOME/bin

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

%DOMAIN_HOME%\bin

2. UNIXオペレーティング・システムで次のコマンドを実行して、ノード・マネージャを起動します。
nohup ./startNodeManager.sh > nm.out&

この例のnohupとnm.outはサンプル出力ファイルです。

Windowsオペレーティング・システムで次のコマンドを実行して、ノード・マネージャを起動します。

startNodeManager.cmd

「スタート」メニューのショートカットからでもノード・マネージャを起動できます。「ツール」に続いて「ノード マネージャ」をクリックします。

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

startComponent.sh|cmdスクリプトを使用してスタンドアロンOracle HTTP Serverを起動できます。

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

1. 次のディレクトリに移動します。
UNIXオペレーティング・システムの場合:

$DOMAIN_HOME/bin

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

%DOMAIN_HOME%\bin

2. UNIXオペレーティング・システムでは、次のコマンドを入力します。
./startComponent.sh ohs_name

Windowsオペレーティング・システムでは、次のコマンドを入力します。

startComponent.cmd ohs_name

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

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

この章では、スタンドアロンOracle HTTP Serverを、以前のスタンドアロンOracle HTTP Server 12cリリースから最新の12cにアップグレードするプロセスについて説明します。

注意:

この章の情報は、『Oracle Fusion Middlewareのアップグレードのプランニング』を読んで必要なアップグレード前タスクを実行したことを前提としています。

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

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

- 再構成ウィザードを使用した既存のドメインの再構成
再構成ウィザードで、ドメインの場所を維持しながらドメインを再構成します。再構成ウィザードを使用して、ドメインを最新バージョンにアップグレードします。

- Upgrade Assistantを使用した12cドメインのアップグレード

- アップグレードの確認

親トピック: スタンドアロンOracle HTTP Serverのアップグレード

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

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

1. 12.2.1.1製品ディストリビューションをインストールするターゲット・システムにサインインします。

2. Oracle HTTP Serverディストリビューション(UNIX向けのfmw_12.2.1.1.0_ohs_linux64.binとWindows向けのsetup_fmw_12.2.1.1.0_ohs_win64.exe)を、ターゲット・システム上でOracle Technology NetworkまたはOracle Software Delivery Cloudからダウンロードします。

3. Oracle HTTP Serverディストリビューションをダウンロードしたディレクトリに移動します。

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

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

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

5. 次のコマンドを入力して、インストール・プログラムを開始します。
UNIXオペレーティング・システムの場合:

./ohs_linux64.bin

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

setup_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インストールの計画のインストールと構成のディレクトリの選択を参照してください。

10. 「インストール・タイプ」画面で、「スタンドアロンHTTPサーバー(WebLogic Serverとは切り離して管理)」を選択し、「次へ」をクリックします。
インストール・タイプについて詳しくは、Oracle HTTP Serverのインストールと構成のOracle HTTP Serverの標準インストール・トポロジの概要を参照してください。

11. 「前提条件チェック」画面で、ホスト・コンピュータを分析して、特定のオペレーティング・システムの前提条件を満たしているか確認します。
前提条件のチェックが失敗すると、エラー・メッセージが画面の下方に表示されます。エラーを修正し、「再実行」をクリックして再試行します。

エラーや警告メッセージを無視してインストールを続ける場合は、「スキップ」をクリックします(このアプローチはお薦めできません)。

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

13. 「インストール・サマリー」画面で、選択したインストール・オプションを確認します。
これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を入力します。レスポンス・ファイルを使用して、サイレント・インストールを実行できます。「インストール」をクリックします。

14. 「インストールの進行状況」画面のプログレス・バーに100%が表示されたら、「次へ」をクリックします。

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

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

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

再構成ウィザードで、ドメインの場所を保持しながらドメインを再構成します。再構成ウィザードを使用して、ドメインを最新バージョンにアップグレードします。

ドメインを再構成する手順は次のとおりです。

1. ドメインが存在するシステムにサインインします。

2. エディション・ベースのデータベース・ユーザーのみ: エディション・ベースの再関連付けを有効にしてスキーマを構成した場合は、再構成ウィザードを実行する前に、デフォルトのエディション名を手動で指定する必要があります。
デフォルトのエディションを設定するには、次のSQLコマンドを入力します。

ALTER DATABASE DEFAULT EDITION = edition_name;
ここで、edition_nameは、デフォルトのデータベース・エディションの名前です。

3. 次のコマンドを入力して再構成ウィザードを実行します。
UNIXオペレーティング・システムの場合:

$ORACLE_HOME/oracle_common/common/bin/reconfig.sh

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

%ORACLE_HOME%\oracle_common\common\bin\reconfig.cmd

注意:
reconfig.cmdまたはreconfig.shコマンドを実行すると、デフォルトのキャッシュ・ディレクトリが無効であることを示す次のエラー・メッセージが表示される場合があります。
*sys-package-mgr*: パッケージ・キャッシュ・ディレクトリを作成できません。

コマンドに-Dpython.cachedir=valid_directoryパラメータを含めることで、キャッシュ・ディレクトリを変更できます。

再構成ウィザードを開始する際に、次の例に示すように"log"オプションを指定することをお薦めします。

./reconfig.sh -log=/$ORACLE_HOME/logs/reconfig.log -log_priority=ALL

要件に応じてlog_priorityを設定できます。

4. 「ドメインの選択」画面でアップグレードするドメインの場所を指定するか、「参照」をクリックして移動し、ドメイン・ディレクトリを選択します。「次へ」をクリックします。

5. 「再構成セットアップの進行状況」画面には、設定プロセスの進行状況が表示されます。完了したら、「次へ」をクリックします。
このプロセスでは次の処理が行われます。

- Fusion Middleware製品を含む、インストール済製品の再構成テンプレートが自動的に適用されます。これにより、config.xml、config-groups.xml、security.xmlなどの様々なドメイン構成ファイルが更新されます。

- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

- ドメイン・アップグレードが検証されます。

6. 「ドメイン・モードおよびJDK」画面で、ドメインで使用するJDKを選択するか、「参照」をクリックして使用するJDKに移動します。「次へ」をクリックします。

注意:
ここでは「ドメイン・モード」は変更できません。

特定のプラットフォームでサポートされているJDKのリストは、Oracle Fusion Middlewareでサポートされているシステム構成を参照してください。

7. JDBCデータ・ソースには、データ・ソース・インスタンスの作成時、デプロイ時もしくはターゲット指定時、またはサーバー起動時に作成されるデータベース接続のプールが含まれます。
アプリケーションはJNDIツリーでデータ・ソースをルックアップしてから、接続をリクエストします。アプリケーションに接続する必要がなくなった場合は、接続がデータ・ソースの接続プールに戻されます。

ドメイン・ソースに定義されているJDBCデータ・ソースは「JDBCデータ・ソース」画面で構成できます。ドメインを作成する製品に関連付けられるJDBCデータ・ソースは、画面の下半分にリスト表示されます。

設定を指定するデータ・ソースを「データソース名」ドロップダウン・リストから選択します。指定した値は、選択されたデータ・ソースのデータ・ソース・リストの適切な列に表示されます。

データ・ソースがOracle RAC構成の場合は、次の3つのオプションのいずれかを選択できます。

- GridLinkへ変換

- RACマルチ・データ・ソースへ変換

- 変換しない

各オプションの詳細は、「ヘルプ」をクリックしてください。

詳細を指定したら、「次へ」をクリックします。

「JDBCデータ・ソース」画面でデータ・ソースを選択しないと、次の警告を示すポップアップが表示されます。

ドライバがありません

「OK」をクリックして検証せずに続行するか、「取消」をクリックして「JDBCデータ・ソース」ページに戻ります。

この場合、「OK」をクリックしてもデータ・ソースは検証されません。

8. 「JDBCデータ・ソース・テスト」画面で、「JDBCデータ・ソース」画面で構成したデータ・ソース接続のチェック・ボックスを選択し、「選択された接続のテスト」をクリックしてデータ・ソース接続をテストします。

注意:
データベース接続をテストするには、接続するデータベースが起動している必要があります。接続をテストしない場合は、データ・ソースを選択しません。「次へ」をクリックして続行します。

9. 「データベース構成タイプ」画面で、「RCUデータ」を選択します。
RCUサービス表(STB)スキーマ資格証明を使用してデータベース接続の詳細を入力するか、「RCU構成の取得」をクリックします。

再構成ウィザードは、この接続を使用してドメイン内のコンポーネントに必要なデータ・ソースを自動的に構成します。

チェックに成功したら、「次へ」をクリックします。チェックが失敗した場合は、接続の詳細を正しく入力し直して再試行します。

10. 「JDBCコンポーネント・スキーマ・テスト」画面で、すべてのコンポーネント・スキーマを選択して「選択された接続のテスト」をクリックして、各スキーマの接続をテストします。
チェックが終了したら、「次へ」をクリックします。

11. 「ノード・マネージャ」画面は、再構成するドメインで、ホストごとのノード・マネージャが使用されている場合にのみ表示されます。
「ノード・マネージャ」画面で、再構成したドメインで使用するノード・マネージャ構成を選択します。結果として生成される構成は、「ノード・マネージャ・タイプ」および「ノード・マネージャ構成」で選択したオプションの組合せに応じて異なります。

表5-1 ノード・マネージャ画面のフィールドの説明

オプション

説明

ドメインごとのデフォルトの場所

このオプションを選択すると、ノード・マネージャ・ホームが$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

ノード・マネージャ資格証明: ユーザー名、パスワード

再構成されたドメインで、ノード・マネージャの起動に使用するユーザー名とパスワードを指定します。

12. 「拡張構成」画面で、拡張構成を実行するすべてのカテゴリを選択できます。選択したカテゴリごとに、詳細構成を行うことができる適切な構成画面が表示されます。

注意:
「拡張構成」画面に表示されるカテゴリは、ドメインで選択したテンプレートに定義されているリソースによって異なります。

このアップグレードでは、オプションを選択せずに「次へ」をクリックします。

13. 「構成のサマリー」画面で、ドメインの詳細な構成を確認してから続行します。
「表示」ドロップダウン・リストからフィルタ・オプションを選択すると、右側のパネルに表示される項目を制限できます。

構成を変更するには、「戻る」をクリックして適切な画面に戻ります。ドメインを再構成するには、「再構成」をクリックします。

注意:
ドメインの再構成時には、ドメインの場所は変更されません。

14. 「再構成の進行状況」画面に、再構成プロセスの進行状況が表示されます。
このプロセスでは次の処理が行われます。

- ドメイン情報が抽出、保存および更新されます。

- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

プログレス・バーに100%が表示されたら、「次へ」をクリックします。

15. 「構成の終了」画面に、再構成プロセスが成功して完了したか、または失敗したかどうかが示されます。管理サーバーURL(リスニング・ポートを含む)とともに再構成されたドメインの場所も表示します。再構成が成功した場合は、Oracle Weblogic Serverの再構成に成功しましたと表示されます。
再構成プロセスが成功して完了しなかった場合は、その理由を示すエラー・メッセージが表示されます。問題を解決するための適切な措置を講じます。問題を解決できない場合は、My Oracle Supportに連絡してください。

今後の操作での使用に備えて、ドメインの場所と管理サーバーのURLを記録しておきます。

5.3 Upgrade Assistantを使用した12cドメインのアップグレード

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

1. 次のコマンドを入力して、Upgrade Assistantを12.2.1.1のOracleホームから実行します。
UNIXオペレーティング・システムの場合:

$Oracle_Home/oracle_common/upgrade/bin/ua

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

%Oracle_Home%\oracle_common\upgrade\bin\ua.bat

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

3. 「スタンドアロン・コンポーネント」画面で、「スタンドアロン・システム・コンポーネント構成」を選択します。
「既存のドメインの更新」を選択し、既存の12cドメインの場所を「ドメイン・ディレクトリ」フィールドに入力します。「参照」ボタンをクリックして、ナビゲーション・ツリーを使用して既存のドメイン・ディレクトリを選択することもできます。「次へ」をクリックします。

注意:

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

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

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

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

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

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

6. 「インスタンス・ディレクトリ」画面で、「12cソース」を選択して「次」をクリックします。
以前の12cリリースから最新の12cリリースにアップグレードする場合は、Oracleインスタンス・ディレクトリの入力は必要ありません。

7. 「調査」画面には、各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを検証するUpgrade Assistantのステータスが表示されます。ステータスが「調査が終了しました。」になっている場合は、「アップグレード」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログ・ボックスの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、共通するアップグレード・エラーの解決に関する情報をアップグレードのトラブルシューティングで参照します。

注意:

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

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

8. 「アップグレード・サマリー」画面でツリーを展開して、選択したオプションの概要を確認します。
アップグレードに進む前に、ソース・バージョンとターゲット・バージョンを参照して、両方のバージョンが正しいことを確認してください。

レスポンス・ファイルには、Upgrade Assistantのグラフィカル・ユーザー・インタフェース画面で入力したすべての情報が収集して格納され、後でサイレント・アップグレードを実行するために使用できます。サイレント・アップグレードは、Upgrade Assistantウィザードとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。これらのオプションをレスポンス・ファイルに保存する場合、「保存」をクリックし、レスポンス・ファイルの名前および場所を指定します。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。

9. 「アップグレードの進行状況」画面に、アップグレード・プロセスのステータスと、アップグレードが成功した後のコンポーネントの予測ターゲット・バージョンが表示されます。「次へ」をクリックします。

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

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

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

11. アップグレードに失敗すると、「アップグレード失敗」画面が表示されます。これは、1つ以上のコンポーネントのアップグレードに失敗したことを示します。今行った操作では、コンポーネントをアップグレードできません。
「ログの表示」をクリックすると、エラーの表示およびトラブルシューティングを行えます。

Upgrade Assistantを再び起動する前に、アップグレード前の環境の問題を修正します。アップグレード前の環境をバックアップからリストアし(元のバックアップ・ファイルは必ず別の場所に保持してください)、問題を修正し、Upgrade Assistantを再起動します。

5.4 アップグレードの確認

ノード・マネージャおよびスタンドアロンOracle HTTP Serverを正しく起動できれば、アップグレードが成功したことを確認できます。アップグレード後の問題が発生した場合は、インストールのトラブルシューティングを実行してアップグレードを再試行する必要があります。詳細は、Oracle HTTP Server管理者ガイドのOracle HTTP Serverのトラブルシューティングを参照してください。

ノード・マネージャとスタンドアロンOracle HTTP Serverを起動する方法を次のトピックで参照してください。

- ノード・マネージャの起動
WebLogic Serverの本番環境では、サーバー・インスタンスが複数のドメイン、マシンおよび地理的な場所にまたがって分散することがよくあります。ノード・マネージャは、Oracle HTTP Serverインスタンスの管理(起動、停止および再起動)に使用できるWebLogic Serverユーティリティです。

- スタンドアロンOracle HTTP Serverの起動
startComponent.sh|cmdスクリプトを使用して、スタンドアロンOracle HTTP Serverを起動できます。

5.4.1 ノード・マネージャの起動

WebLogic Serverの本番環境では、サーバー・インスタンスが複数のドメイン、マシン、および地理的な場所にまたがって分散することがよくあります。ノード・マネージャは、Oracle HTTP Serverインスタンスの管理(起動、停止および再起動)に使用できるWebLogic Serverユーティリティです。

Windowsオペレーティング・システムの場合は、ノード・マネージャを起動サービスとして実行するように構成することをお薦めします。これによって、システムが再起動されるたびに、ノード・マネージャが自動で起動されます。詳細は、『Oracle WebLogic Serverノード・マネージャの管理』の起動サービスとしてのノード・マネージャの実行に関する項を参照してください。

注意:
UNIXプラットフォームでは、ノード・マネージャをルート・ユーザーとして実行しないでください。

1. 次のディレクトリに移動します。
UNIXオペレーティング・システムの場合:

$DOMAIN_HOME/bin

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

%DOMAIN_HOME%\bin

2. UNIXオペレーティング・システムで次のコマンドを実行して、ノード・マネージャを起動します。
nohup ./startNodeManager.sh > nm.out&

この例のnohupとnm.outはサンプル出力ファイルです。

Windowsオペレーティング・システムで次のコマンドを実行して、ノード・マネージャを起動します。

startNodeManager.cmd

「スタート」メニューのショートカットからでもノード・マネージャを起動できます。「ツール」に続いて「ノード マネージャ」をクリックします。

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

startComponent.sh|cmdスクリプトを使用してスタンドアロンOracle HTTP Serverを起動できます。

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

1. 次のディレクトリに移動します。
UNIXオペレーティング・システムの場合:

$DOMAIN_HOME/bin

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

%DOMAIN_HOME%\bin

2. UNIXオペレーティング・システムでは、次のコマンドを入力します。
./startComponent.sh ohs_name

Windowsオペレーティング・システムでは、次のコマンドを入力します。

startComponent.cmd ohs_name

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

第II部管理対象Oracle HTTP Serverのアップグレード

第II部は、次の章で構成されます。

- 管理対象Oracle HTTP Serverのアップグレードの概要
この章では、Oracle Fusion Middlewareの管理対象Oracle HTTP Serverの概略を紹介し、Oracle Fusion Middleware 11gまたは以前の12cリリース(12.1.2以降)のOracle HTTP ServerからこのOracle HTTP Server 12cリリース(12.2.1.1)にアップグレードするために実行する必要がある手順の概要を説明します。

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

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

6 管理対象Oracle HTTP Serverのアップグレードの概要

この章では、Oracle Fusion Middlewareの管理対象Oracle HTTP Serverの概略を紹介し、Oracle Fusion Middleware 11gまたは以前の12cリリース(12.1.2以降)のOracle HTTP ServerからこのOracle HTTP Server 12cリリース(12.2.1.1)にアップグレードするために実行する必要がある手順の概要を説明します。

この章の内容は次のとおりです。

- 管理対象Oracle HTTP Serverのアップグレード・プロセスのフローチャート
このトピックは、フローチャートを使用して、11gまたは以前の12cリリースからOracle HTTP Serverをアップグレードするプロセス・フローを理解するために役立ちます。

- 管理対象Oracle HTTP Serverのアップグレード・ロードマップ

親トピック: 管理対象Oracle HTTP Serverのアップグレード

6.1 管理対象Oracle HTTP Serverのアップグレード・プロセスのフローチャート

このトピックは、フローチャートを使用して、11gまたは以前の12cリリースからOracle HTTP Serverをアップグレードするプロセス・フローを理解するために役立ちます。

図6-1は、管理対象Oracle HTTP Serverを最新の12cリリースにアップグレードするためのプロセス・フローを示しています。

図6-1 管理対象Oracle HTTP Serverのアップグレード・プロセスのフローチャート

6.2 管理対象Oracle HTTP Serverのアップグレード・ロードマップ

表6-1では、管理対象Oracle HTTP Serverを11gリリースまたは以前の12cから最新バージョン(12.2.1.1)にアップグレードするために実行する必要があるタスクを説明します。

表6-1 管理対象Oracle HTTP Serverのアップグレード・プロセスのロードマップ

手順番号

重要度(必須、条件付きまたはオプション)

タスク

説明

1

推奨。

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

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

2

オプション。

BI 12.2.1.1へのアップグレード方法に影響する可能性のある、相互運用性および互換性の要因について学びます。

サポートされるOracle Fusion Middleware構成で、同一バージョンまたは異なるバージョンの2つ以上のOracle Fusion Middleware製品がどのように連携(相互運用)するかを理解することは重要です。

相互運用性および互換性の詳細は、相互運用性および互換性の理解を参照してください。

3

必須。

既存の環境をバックアップします。

ドメイン構成がアップグレードされて置き換えられるため、アップグレード前に既存の環境をバックアップすることが重要です。バックアップを作成することで、アップグレードが失敗した場合や、アップグレード結果が満足なものでなかった場合にアップグレード前の環境をリストアできます。

4

必須。

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

アップグレード前タスクには、本番環境のクローニング、システム要件や動作保証の確認、未使用データのパージ、非SYSDBAユーザーの作成などがあります。

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

5

必須。

管理対象Oracle HTTP Serverをインストールします。

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

管理対象12c (12.2.1.1.0) Oracle HTTP Serverのインストールを参照してください。

6

条件付き:
11gリリースからアップグレードする場合

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

アップグレード前の必要なスキーマの作成を参照してください。

7

条件付き:
以前の12cリリースからアップグレードする場合

Upgrade Assistantを使用して既存のスキーマをアップグレードします。

Upgrade Assistantを使用した既存の12cスキーマのアップグレードを参照してください。

8

必須。

既存のドメインを再構成します。

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

再構成ウィザードを使用した既存のドメインの再構成を参照してください。

9

必須。

Upgrade Assistantを使用してドメイン構成をアップグレードします。

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

Upgrade Assistantを使用したコンポーネント構成のアップグレードを参照してください。

10

必須。

アップグレード後のタスクを実行して、アップグレードを検証します。

11gから12cへのアップグレード後のタスクについては、アップグレード後のタスクを参照してください。

以前の12cのアップグレード後のタスクについては、アップグレード後のタスクを参照してください。

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

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

- 管理対象12c (12.2.1.1.0) Oracle HTTP Serverのインストール
既存の管理対象Oracle HTTP Server 12c (12.1.2、12.1.3または12.2.1)コンポーネントをアップグレードする前に、まずOracle HTTP Serverリリース12.2.1.1.0をインストールする必要があります。

- アップグレード前の必要なスキーマの作成
Oracle HTTP Server 11gからアップグレードする場合は、アップグレードの開始前に、必要な12cスキーマを作成する必要があります。Oracle HTTP Serverに必要なスキーマは、サービス表(STB)およびOracle Platform Security Services (OPSS)です。

- 再構成ウィザードを使用した11gドメインの再構成
12cの再構成ウィザードを使用して、11g Oracle HTTP Serverドメインをアップグレードする必要があります。

- Upgrade Assistantを使用したコンポーネント構成のアップグレード
管理対象ドメインのコンポーネントを含むOracleホームからUpgrade Assistantを実行する場合、「WebLogicコンポーネント構成」アップグレード・オプションを使用できます。

- アップグレード後のタスク
アップグレード後のタスクには、ノード・マネージャの起動、管理サーバーの起動、Oracle HTTP Serverの起動および11gから12cへのアップグレードが成功したかどうかの確認などが含まれます。

親トピック: 管理対象Oracle HTTP Serverのアップグレード

7.1 管理対象12c (12.2.1.1.0) Oracle HTTP Serverのインストール

既存の管理対象Oracle HTTP Server 12c (12.1.2、12.1.3または12.2.1)コンポーネントをアップグレードする前に、まずOracle HTTP Serverリリース12.2.1.1.0をインストールする必要があります。

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

1. Oracle HTTP Serverをインストールするホストにログインします。

2. Oracle HTTP Server製品ディストリビューション(fmw_12.2.1.1.0_ohs_linux64.bin|.exe)を、ホスト・システム上でOracle Technology NetworkまたはOracle Software Delivery Cloudからダウンロードします。

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. Oracle HTTP Serverディストリビューションは.binファイルです。以下のコマンドを入力して、インストーラを実行します。
./distribution_filename.bin

6. 「インストール・インベントリの設定」画面の「インベントリ・ディレクトリ」フィールドで、中央インベントリを作成する場所を指定します。
この画面で選択したオペレーティング・システム・グループ名に、中央インベントリの場所への書込み権限があることを確認してください。「OK」をクリックします。

注意:
Windowsオペレーティング・システムでは、この画面は表示されません。中央インベントリの詳細は、Oracle Universal InstallerによるソフトウェアのインストールでOracle中央インベントリの理解を参照してください。

7. 「ようこそ」画面で情報を確認し、「次へ」をクリックします。

8. 「自動更新」画面で次のいずれかのオプションを選択し、「次へ」をクリックします。

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

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

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

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

Oracle Fusion Middlewareディレクトリ構造の詳細は、Oracle Fusion Middlewareインストールの計画のインストールと構成のディレクトリの選択を参照してください。

10. 「インストール・タイプ」画面で、「同じ場所に配置されたHTTPサーバー(WebLogic Server経由で管理)」を選択し、「次へ」をクリックします。
インストール・タイプについて詳しくは、Oracle HTTP Serverのインストールと構成のOracle HTTP Serverの標準インストール・トポロジの概要を参照してください。

11. 「前提条件チェック」画面で、システムが必要な最低要件を満たしていることを確認して「次へ」をクリックします。警告またはエラー・メッセージが表示された場合は、Oracle Fusion Middlewareのシステム要件と仕様を参照してください。
この画面に表示される他のオプションの詳細は、「ヘルプ」をクリックしてください。

12. 「インストール・サマリー」画面で、選択したインストール・オプションを確認します。
これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を入力します。レスポンス・ファイルを使用して、サイレント・インストールを実行できます。「インストール」をクリックします。

13. 「インストールの進行状況」画面のプログレス・バーに100%が表示されたら、「次へ」をクリックします。
インストールに成功した場合は、「インストール完了」画面に「Oracle HTTP Server (OHS)が正常にインストールされました。」というメッセージが表示されます。「終了」 をクリックしてインストーラを終了します。

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

7.2 アップグレード前の必要なスキーマの作成

Oracle HTTP Server 11gからアップグレードする場合は、アップグレードの開始前に、必要な12cスキーマを作成する必要があります。Oracle HTTP Serverに必要なスキーマは、サービス表(STB)およびOracle Platform Security Services (OPSS)です。

注意:
この手順は、データベースに対して完全な管理者権限を持つSYSまたはSYSDBAユーザーが行うことを前提としています。限られたデータベース権限しかない場合は、データベース権限が制限されたユーザーとしてのスキーマの作成の手順に従ってください。RCUの使用の詳細は、リポジトリ作成ユーティリティによるスキーマの作成を参照してください。

12cスキーマを作成する手順は次のとおりです。

1. 次のディレクトリに移動します。
12c_Oracle_Home/oracle_common/bin/

2. 次のコマンドを入力してRCUを実行します。
./rcu

3. 「ようこそ」画面で「次へ」をクリックします。

4. 「リポジトリの作成」画面で「リポジトリの作成」を選択し、「システム・ロードおよび製品ロード」を選択します。「次へ」をクリックします。

5. 「データベース接続の詳細」画面で「データベース・タイプ」をクリックして、次の詳細を入力します。

表7-1 Oracle Databaseと、エディションベースで再定義されるOracle Databaseに対する接続資格証明

オプション

説明と例

ホスト名

データベースが実行されるサーバーの名前を、次の書式で指定します。

examplehost.exampledomain.com

Oracle RACデータベースの場合は、このフィールドにVIP名またはいずれかのノード名を指定します。

ポート

データベースのポート番号を指定します。Oracleデータベースのデフォルトのポート番号は1521です。

サービス名

データベースのサービス名を指定します。通常、サービス名はグローバル・データベース名と同じです。

Oracle RACデータベースの場合、このフィールドにいずれかのノードのサービス名を指定します。次に例を示します。

examplehost.exampledomain.com

ユーザー名

データベースのユーザー名を入力します。デフォルトのユーザー名はSYSです。

パスワード

データベース・ユーザーのパスワードを入力します。

ロール

ドロップダウン・リストからデータベース・ユーザーのロールを選択します。

標準またはSYSDBA

表7-2 MySQLデータベースに対する接続資格証明

オプション

説明と例

ホスト名

データベースが稼働しているサーバーのホスト名、IPアドレスまたは詳細なサーバー名を、host\server形式で指定します。

ポート

データベースのポート番号を指定します。

データベース名

データベースの名前を指定します。

ユーザー名

管理者権限を持つユーザーの名前を指定します。

パスワード

データベース・ユーザーのパスワードを入力します。

表7-3 Microsoft SQL Serverデータベースに対する接続資格証明

オプション

説明と例

Unicodeのサポート

ドロップダウン・リストから「はい」または「いいえ」を選択します。

サーバー名

データベースが稼働しているサーバーのホスト名、IPアドレスまたは詳細なサーバー名を、host\server形式で指定します。

ポート

データベースのポート番号を指定します。

データベース名

データベースの名前を指定します。

ユーザー名

管理者権限を持つユーザーの名前を指定します。

パスワード

データベース・ユーザーのパスワードを入力します。

表7-4 IBM DB2データベースに対する接続資格証明

オプション

説明と例

サーバー名

データベースが稼働しているサーバーのホスト名、IPアドレスまたは詳細なサーバー名を、host\server形式で指定します。

ポート

データベースのポート番号を指定します。

データベース名

データベースの名前を指定します。

ユーザー名

DB所有者の権限が付与されているユーザーの名前を指定します。IBM DB2データベースのデフォルトのユーザー名はdb2adminです。

パスワード

データベース・ユーザーのパスワードを入力します。

前提条件のチェックに成功したら、「OK」をクリックして次のページに進みます。チェックが失敗した場合は、入力した詳細を確認して再試行します。

6. 「コンポーネントの選択」画面で「新規接頭辞の作成」を選択して、11gスキーマと同じ接頭辞を入力します。
カスタム接頭辞は、これらのスキーマをこのドメインで使用するために論理的にまとめてグループ化するために使用されます。

「AS共通スキーマ」を選択します。このセクションのすべてのスキーマが自動的に選択されます。「次へ」をクリックします。

インストールするコンポーネントの接頭辞とスキーマ名は忘れないでください。製品インストールの構成中に必要になります。これらの値はメモしておくことをお薦めします。

7. 前提条件のチェックが成功したことを確認します。「OK」をクリックして次のページに進みます。

8. 「スキーマ・パスワード」画面で、スキーマの所有者のパスワードを入力します。
この画面で入力したパスワードは忘れないでください。製品インストールの構成中に必要になります。これらの値はメモしておくことをお薦めします。

9. 「表領域のマップ」画面で、作成するスキーマの目的の表領域マッピングを構成します。
「次へ」をクリックすると、別のダイアログ・ウィンドウが開き、これらの表領域の作成を確認するように求められます。「OK」をクリックして先に進み、このダイアログ・ウィンドウを閉じます。

表領域作成の進行状況を示す2番目のダイアログ・ウィンドウが表示されます。この処理が完了したら、「OK」をクリックしてこのウィンドウを閉じ、次の画面に進みます。

10. 「サマリー」画面で情報を確認し、「作成」をクリックしてスキーマの作成を開始します。
この画面には、このRCU操作で作成されたログ・ファイルに関する情報が表示されます。特定のログ・ファイルの名前をクリックして、そのファイルの内容を表示できます。

11. 「完了サマリー」画面の情報を確認し、操作が正常に完了したことを確かめます。「閉じる」をクリックして、スキーマの作成を完了し、RCUを終了します。

どのスキーマを作成するか。

作成するスキーマの決定

システム・ロードおよび製品ロードとは何か。

システム・ロードおよび製品ロードの理解

カスタム接頭辞とは何か。

カスタム接頭辞の理解

スキーマ作成の計画

スキーマ作成の計画

7.3 再構成ウィザードを使用した11gドメインの再構成

12cの再構成ウィザードを使用して、11g Oracle HTTP Serverドメインをアップグレードする必要があります。

ドメインを再構成する手順は次のとおりです。

1. ドメインが存在するシステムにサインインします。

2. エディション・ベースのデータベース・ユーザーのみ: エディション・ベースの再関連付けを有効にしてスキーマを構成した場合は、再構成ウィザードを実行する前に、デフォルトのエディション名を手動で指定する必要があります。
デフォルトのエディションを設定するには、次のSQLコマンドを入力します。

ALTER DATABASE DEFAULT EDITION = edition_name;
ここで、edition_nameは、デフォルトのデータベース・エディションの名前です。

3. 次のコマンドを入力して再構成ウィザードを実行します。
UNIXオペレーティング・システムの場合:

$ORACLE_HOME/oracle_common/common/bin/reconfig.sh

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

%ORACLE_HOME%\oracle_common\common\bin\reconfig.cmd

注意:
reconfig.cmdまたはreconfig.shコマンドを実行すると、デフォルトのキャッシュ・ディレクトリが無効であることを示す次のエラー・メッセージが表示される場合があります。
*sys-package-mgr*: パッケージ・キャッシュ・ディレクトリを作成できません。

コマンドに-Dpython.cachedir=valid_directoryパラメータを含めることで、キャッシュ・ディレクトリを変更できます。

再構成ウィザードを開始する際に、次の例に示すように"log"オプションを指定することをお薦めします。

./reconfig.sh -log=/$ORACLE_HOME/logs/reconfig.log -log_priority=ALL

要件に応じてlog_priorityを設定できます。

4. 「ドメインの選択」画面でアップグレードするドメインの場所を指定するか、「参照」をクリックして移動し、ドメイン・ディレクトリを選択します。「次へ」をクリックします。

5. 「再構成セットアップの進行状況」画面には、設定プロセスの進行状況が表示されます。完了したら、「次へ」をクリックします。
このプロセスでは次の処理が行われます。

- Fusion Middleware製品を含む、インストール済製品の再構成テンプレートが自動的に適用されます。これにより、config.xml、config-groups.xml、security.xmlなどの様々なドメイン構成ファイルが更新されます。

- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

- ドメイン・アップグレードが検証されます。

6. 「ドメイン・モードおよびJDK」画面で、ドメインで使用するJDKを選択するか、「参照」をクリックして使用するJDKに移動します。「次へ」をクリックします。

注意:
ここでは「ドメイン・モード」は変更できません。

特定のプラットフォームでサポートされているJDKのリストは、Oracle Fusion Middlewareでサポートされているシステム構成を参照してください。

7. JDBCデータ・ソースには、データ・ソース・インスタンスの作成時、デプロイ時もしくはターゲット指定時、またはサーバー起動時に作成されるデータベース接続のプールが含まれます。
アプリケーションはJNDIツリーでデータ・ソースをルックアップしてから、接続をリクエストします。アプリケーションに接続する必要がなくなった場合は、接続がデータ・ソースの接続プールに戻されます。

ドメイン・ソースに定義されているJDBCデータ・ソースは「JDBCデータ・ソース」画面で構成できます。ドメインを作成する製品に関連付けられるJDBCデータ・ソースは、画面の下半分にリスト表示されます。

設定を指定するデータ・ソースを「データソース名」ドロップダウン・リストから選択します。指定した値は、選択されたデータ・ソースのデータ・ソース・リストの適切な列に表示されます。

データ・ソースがOracle RAC構成の場合は、次の3つのオプションのいずれかを選択できます。

- GridLinkへ変換

- RACマルチ・データ・ソースへ変換

- 変換しない

各オプションの詳細は、「ヘルプ」をクリックしてください。

詳細を指定したら、「次へ」をクリックします。

「JDBCデータ・ソース」画面でデータ・ソースを選択しないと、次の警告を示すポップアップが表示されます。

ドライバがありません

「OK」をクリックして検証せずに続行するか、「取消」をクリックして「JDBCデータ・ソース」ページに戻ります。

この場合、「OK」をクリックしてもデータ・ソースは検証されません。

8. 「JDBCデータ・ソース・テスト」画面で、「JDBCデータ・ソース」画面で構成したデータ・ソース接続のチェック・ボックスを選択し、「選択された接続のテスト」をクリックしてデータ・ソース接続をテストします。

注意:
データベース接続をテストするには、接続するデータベースが起動している必要があります。接続をテストしない場合は、データ・ソースを選択しません。「次へ」をクリックして続行します。

9. 「データベース構成タイプ」画面で、「RCUデータ」を選択します。
RCUサービス表(STB)スキーマ資格証明を使用してデータベース接続の詳細を入力するか、「RCU構成の取得」をクリックします。

再構成ウィザードは、この接続を使用してドメイン内のコンポーネントに必要なデータ・ソースを自動的に構成します。

チェックに成功したら、「次へ」をクリックします。チェックが失敗した場合は、接続の詳細を正しく入力し直して再試行します。

10. 「JDBCコンポーネント・スキーマ・テスト」画面で、すべてのコンポーネント・スキーマを選択して「選択された接続のテスト」をクリックして、各スキーマの接続をテストします。
チェックが終了したら、「次へ」をクリックします。

11. 「ノード・マネージャ」画面は、再構成するドメインで、ホストごとのノード・マネージャが使用されている場合にのみ表示されます。
「ノード・マネージャ」画面で、再構成したドメインで使用するノード・マネージャ構成を選択します。結果として生成される構成は、「ノード・マネージャ・タイプ」および「ノード・マネージャ構成」で選択したオプションの組合せに応じて異なります。

表7-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

ノード・マネージャ資格証明: ユーザー名、パスワード

再構成されたドメインで、ノード・マネージャの起動に使用するユーザー名とパスワードを指定します。

12. 「拡張構成」画面で、拡張構成を実行するすべてのカテゴリを選択できます。選択したカテゴリごとに、詳細構成を行うことができる適切な構成画面が表示されます。

注意:
「拡張構成」画面に表示されるカテゴリは、ドメインで選択したテンプレートに定義されているリソースによって異なります。

このアップグレードでは、オプションを選択せずに「次へ」をクリックします。

13. 「構成のサマリー」画面で、ドメインの詳細な構成を確認してから続行します。
「表示」ドロップダウン・リストからフィルタ・オプションを選択すると、右側のパネルに表示される項目を制限できます。

構成を変更するには、「戻る」をクリックして適切な画面に戻ります。ドメインを再構成するには、「再構成」をクリックします。

注意:
ドメインの再構成時には、ドメインの場所は変更されません。

14. 「再構成の進行状況」画面に、再構成プロセスの進行状況が表示されます。
このプロセスでは次の処理が行われます。

- ドメイン情報が抽出、保存および更新されます。

- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

プログレス・バーに100%が表示されたら、「次へ」をクリックします。

15. 「構成の終了」画面に、再構成プロセスが成功して完了したか、または失敗したかどうかが示されます。管理サーバーURL(リスニング・ポートを含む)とともに再構成されたドメインの場所も表示します。再構成が成功した場合は、Oracle Weblogic Serverの再構成に成功しましたと表示されます。
再構成プロセスが成功して完了しなかった場合は、その理由を示すエラー・メッセージが表示されます。問題を解決するための適切な措置を講じます。問題を解決できない場合は、My Oracle Supportに連絡してください。

今後の操作での使用に備えて、ドメインの場所と管理サーバーのURLを記録しておきます。

7.4 Upgrade Assistantを使用したコンポーネント構成のアップグレード

管理対象ドメインのコンポーネントを含むOracleホームからUpgrade Assistantを実行する場合、「WebLogicコンポーネント構成」アップグレード・オプションを使用できます。

Oracle HTTP Serverのコンポーネント構成をアップグレードする手順は次のとおりです。

1. 次のコマンドを入力して、Upgrade Assistantを12.2.1.1のOracleホームから実行します。
UNIXオペレーティング・システムの場合:

$Oracle_Home/oracle_common/upgrade/bin/ua

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

%Oracle_Home%\oracle_common\upgrade\bin\ua.bat

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

3. 「WebLogicコンポーネント」画面で、「WebLogicコンポーネント構成」オプションを選択して、管理対象WebLogic Serverドメインのコンポーネント構成をアップグレードします。ドメインを管理しているWebLogic管理サーバーに接続するために必要な接続詳細を入力して、「次」をクリックします。

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

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

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

6. 「調査」画面には、各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを検証するUpgrade Assistantのステータスが表示されます。ステータスが「調査が終了しました。」になっている場合は、「アップグレード」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログ・ボックスの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、共通するアップグレード・エラーの解決に関する情報をアップグレードのトラブルシューティングで参照します。

注意:

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

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

7. 「アップグレード・サマリー」画面でツリーを展開して、選択したオプションの概要を確認します。
アップグレードに進む前に、ソース・バージョンとターゲット・バージョンを参照して、両方のバージョンが正しいことを確認してください。

レスポンス・ファイルには、Upgrade Assistantのグラフィカル・ユーザー・インタフェース画面で入力したすべての情報が収集して格納され、後でサイレント・アップグレードを実行するために使用できます。サイレント・アップグレードは、Upgrade Assistantウィザードとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。これらのオプションをレスポンス・ファイルに保存する場合、「保存」をクリックし、レスポンス・ファイルの名前および場所を指定します。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。

8. 「アップグレードの進行状況」画面に、アップグレード・プロセスのステータスと、アップグレードが成功した後のコンポーネントの予測ターゲット・バージョンが表示されます。「次へ」をクリックします。

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

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

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

10. アップグレードに失敗すると、「アップグレード失敗」画面が表示されます。これは、1つ以上のコンポーネントのアップグレードに失敗したことを示します。今行った操作では、コンポーネントをアップグレードできません。
「ログの表示」をクリックすると、エラーの表示およびトラブルシューティングを行えます。

Upgrade Assistantを再び起動する前に、アップグレード前の環境の問題を修正します。アップグレード前の環境をバックアップからリストアし(元のバックアップ・ファイルは必ず別の場所に保持してください)、問題を修正し、Upgrade Assistantを再起動します。

7.5 アップグレード後のタスク

アップグレード後のタスクには、ノード・マネージャの起動、管理サーバーの起動、Oracle HTTP Serverの起動および11gから12cへのアップグレードが成功したかどうかの確認などが含まれます。

- ノード・マネージャの起動
WebLogic Serverの本番環境では、サーバー・インスタンスが複数のドメイン、マシンおよび地理的な場所にまたがって分散することがよくあります。ノード・マネージャは、離れた場所から管理サーバー・インスタンスや管理対象サーバー・インスタンスを起動、停止、および再起動できるWebLogic Server付属のユーティリティです。

- 管理サーバーの起動
各ドメインでは、1つのWebLogic Serverインスタンスが管理サーバーの役割を担います。管理サーバーではWebLogic Serverドメインを一元的に管理できます。ドメイン内の他のすべてのWebLogic Serverインスタンスは、管理対象サーバーと呼ばれます。1つのWebLogic Serverインスタンスしか含まれないドメインでは、そのサーバーが管理サーバーおよび管理対象サーバーとして機能します。

- Oracle HTTP Serverの起動
Oracle HTTP Serverを起動、停止および再起動するには、Enterprise Manager Fusion Middleware Controlまたはopmnctlコマンドを使用できます。

- Oracle HTTP Serverのインストール成功の確認
管理コンソールとEnterprise Manager Fusion Middleware Controlにログインできれば、Oracle HTTP Serverは正常にインストールされています。

7.5.1 ノード・マネージャの起動

WebLogic Serverの本番環境では、サーバー・インスタンスが複数のドメイン、マシン、および地理的な場所にまたがって分散することがよくあります。ノード・マネージャは、離れた場所から管理サーバー・インスタンスや管理対象サーバー・インスタンスを起動、停止、および再起動できるWebLogic Server付属のユーティリティです。

Windowsオペレーティング・システムの場合は、ノード・マネージャを起動サービスとして実行するように構成することをお薦めします。これによって、システムが再起動されるたびに、ノード・マネージャが自動で起動されます。詳細は、『Oracle WebLogic Serverノード・マネージャの管理』の起動サービスとしてのノード・マネージャの実行に関する項を参照してください。

注意:
UNIXプラットフォームでは、ノード・マネージャをルート・ユーザーとして実行しないでください。

ノード・マネージャを起動するには:

1. 次のディレクトリに移動します。
UNIXオペレーティング・システムの場合:

$ORACLE_HOME/wlserver/server/bin/

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

%ORACLE_HOME%\wlserver\server\bin\

2. UNIXオペレーティング・システムで次のコマンドを実行して、ノード・マネージャを起動します。
nohup ./startNodeManager.sh > nm.out&

この例のnohupとnm.outはサンプル出力ファイルです。

Windowsオペレーティング・システムで次のコマンドを実行して、ノード・マネージャを起動します。

startNodeManager.cmd

「スタート」メニューのショートカットからでもノード・マネージャを起動できます。「ツール」に続いて「ノード マネージャ」をクリックします。

7.5.2 管理サーバーの起動

各ドメインでは、1つのWebLogic Serverインスタンスが管理サーバーの役割を担います。管理サーバーではWebLogic Serverドメインを一元的に管理できます。ドメイン内の他のすべてのWebLogic Serverインスタンスは、管理対象サーバーと呼ばれます。1つのWebLogic Serverインスタンスしか含まれないドメインでは、そのサーバーが管理サーバーおよび管理対象サーバーとして機能します。

通常、開発環境では、管理サーバーを起動し、アプリケーションをすぐにその管理サーバーにデプロイすれば十分です。しかし、本番環境では、アプリケーションを実行する管理対象サーバーの作成をお薦めします。

管理サーバーを起動する手順は次のとおりです。

1. 次のディレクトリに移動します。
$DOMAIN_HOME/DOMAIN_NAME

ここで、DOMAIN_NAMEは、ドメインを配置したディレクトリの名前です。

2. Windowsオペレーティング・システムで次のコマンドを実行して、管理サーバーを起動します。
startWebLogic.cmd

Windowsオペレーティング・システムでは、作成した管理サーバーを起動するためのショートカットが、構成ウィザードによって「スタート」メニューに作成されます。

UNIXオペレーティング・システムで次のコマンドを実行して、管理サーバーを起動します。

./startWebLogic.sh

注意:
サーバーがユーザー名とパスワードの入力を要求する場合は、サーバーを起動する許可を持つWebLogic Serverユーザーの名前を入力します。

7.5.3 Oracle HTTP Serverの起動

Oracle HTTP Serverを起動、停止および再起動するには、Enterprise Manager Fusion Middleware Controlまたはopmnctlコマンドを使用できます。

7.5.3.1 Enterprise Manager Fusion Middleware Controlを使用した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. 「コントロール」メニューから「起動」を選択します。

7.5.3.1.1 opmnctlを使用したOracle HTTP Serverの起動

opmnctlを使用してOracleインスタンス内のOracle HTTP Serverコンポーネントを起動するには、次を実行します。

1. 次のディレクトリに移動します。
ORACLE_INSTANCE/bin

2. 次のコマンドを実行して、Oracleインスタンス内のすべてのOracle HTTP Serverコンポーネントを起動します。
opmnctl startproc process-type=OHS

7.5.3.1.2 opmnctlを使用したOracle HTTP Serverコンポーネントのステータスの判定

Oracle HTTP Serverコンポーネントのステータスを判定する手順は次のとおりです。

1. 次のディレクトリに移動します。
ORACLE_INSTANCE/bin

2. 次のコマンドを入力します。
opmnctl status

サンプル出力は次のようになります。

Processes in Instance: instance1
---------------------------------+--------------------+---------+---------
ias-component                    | process-type       |     pid | status
---------------------------------+--------------------+---------+---------
webcache1                        | WebCache-admin     |   19556 | Alive
webcache1                        | WebCache           |   19555 | Alive
ohs1                             | OHS                |    7249 | Alive

7.5.4 Oracle HTTP Serverインストール成功の確認

管理コンソールとEnterprise Manager Fusion Middleware Controlにログインできれば、Oracle HTTP Serverは正常にインストールされています。

ソフトウェア・パッチが正常にインストールされていることを確認する手順は、次のとおりです。

1. 次のURLにログインします。
http://MachineName.us.oracle.com:7777

2. Enterprise Manager Fusion Middleware Controlにアクセスするには、次のように指定します。
http://MachineName.us.oracle.com:7001/em

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

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

この手順では、システム上に12.1.2 Fusion Middleware Infrastructure (JRFとWebLogic Server)がインストールおよび構成されていることを前提としています。

12cソフトウェアをインストールする前に、RDBMSを除く12.1.2サーバー・インスタンスをすべてシャット・ダウンします。

- 管理対象12c (12.2.1.1.0) Oracle HTTP Serverのインストール
既存の管理対象Oracle HTTP Server 12c (12.1.2、12.1.3または12.2.1)コンポーネントをアップグレードする前に、まずOracle HTTP Serverリリース12.2.1.1.0をインストールする必要があります。

- Upgrade Assistantを使用した既存の12cスキーマのアップグレード
既存の12c OPSS (Oracle Platform Security Services)およびIAU (監査サービス)スキーマを12cのUpgrade Assistantを使用してアップグレードする必要があります。

- 再構成ウィザードを使用した既存のドメインの再構成
再構成ウィザードで、ドメインの場所を維持しながらドメインを再構成します。再構成ウィザードを使用して、ドメインを最新バージョンにアップグレードします。

- Upgrade Assistantを使用したコンポーネント構成のアップグレード
管理対象ドメインのコンポーネントを含むOracleホームからUpgrade Assistantを実行する場合、「WebLogicコンポーネント構成」アップグレード・オプションを使用できます。

- アップグレード後のタスク
アップグレード後のタスクには、ノード・マネージャの起動、管理サーバーの起動、Oracle HTTP Serverの起動および以前の12cリリースから本リリースへのアップグレードが成功したかどうかの確認などが含まれます。

親トピック: 管理対象Oracle HTTP Serverのアップグレード

8.1 管理対象12c (12.2.1.1.0) Oracle HTTP Serverのインストール

既存の管理対象Oracle HTTP Server 12c (12.1.2、12.1.3または12.2.1)コンポーネントをアップグレードする前に、まずOracle HTTP Serverリリース12.2.1.1.0をインストールする必要があります。

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

1. Oracle HTTP Serverをインストールするホストにログインします。

2. Oracle HTTP Server製品ディストリビューション(fmw_12.2.1.1.0_ohs_linux64.bin|.exe)を、ホスト・システム上でOracle Technology NetworkまたはOracle Software Delivery Cloudからダウンロードします。

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. Oracle HTTP Serverディストリビューションは.binファイルです。以下のコマンドを入力して、インストーラを実行します。
./distribution_filename.bin

6. 「インストール・インベントリの設定」画面の「インベントリ・ディレクトリ」フィールドで、中央インベントリを作成する場所を指定します。
この画面で選択したオペレーティング・システム・グループ名に、中央インベントリの場所への書込み権限があることを確認してください。「OK」をクリックします。

注意:
Windowsオペレーティング・システムでは、この画面は表示されません。中央インベントリの詳細は、Oracle Universal InstallerによるソフトウェアのインストールでOracle中央インベントリの理解を参照してください。

7. 「ようこそ」画面で情報を確認し、「次へ」をクリックします。

8. 「自動更新」画面で次のいずれかのオプションを選択し、「次へ」をクリックします。

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

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

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

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

Oracle Fusion Middlewareディレクトリ構造の詳細は、Oracle Fusion Middlewareインストールの計画のインストールと構成のディレクトリの選択を参照してください。

10. 「インストール・タイプ」画面で、「同じ場所に配置されたHTTPサーバー(WebLogic Server経由で管理)」を選択し、「次へ」をクリックします。
インストール・タイプについて詳しくは、Oracle HTTP Serverのインストールと構成のOracle HTTP Serverの標準インストール・トポロジの概要を参照してください。

11. 「前提条件チェック」画面で、システムが必要な最低要件を満たしていることを確認して「次へ」をクリックします。警告またはエラー・メッセージが表示された場合は、Oracle Fusion Middlewareのシステム要件と仕様を参照してください。
この画面に表示される他のオプションの詳細は、「ヘルプ」をクリックしてください。

12. 「インストール・サマリー」画面で、選択したインストール・オプションを確認します。
これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を入力します。レスポンス・ファイルを使用して、サイレント・インストールを実行できます。「インストール」をクリックします。

13. 「インストールの進行状況」画面のプログレス・バーに100%が表示されたら、「次へ」をクリックします。
インストールに成功した場合は、「インストール完了」画面に「Oracle HTTP Server (OHS)が正常にインストールされました。」というメッセージが表示されます。「終了」 をクリックしてインストーラを終了します。

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

8.2 Upgrade Assistantを使用した既存の12cスキーマのアップグレード

既存の12c OPSS (Oracle Platform Security Services)およびIAU (監査サービス)スキーマを12cのUpgrade Assistantを使用してアップグレードする必要があります。

OPSSおよびIAUスキーマをアップグレードする手順は次のとおりです。

1. 次のコマンドを入力して、Upgrade Assistantを12.2.1.1のOracleホームから実行します。
UNIXオペレーティング・システムの場合:

$Oracle_Home/oracle_common/upgrade/bin/ua

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

%Oracle_Home%\oracle_common\upgrade\bin\ua.bat

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

3. 「選択したスキーマ」画面で、「個別に選択されたスキーマ」を選択して「次」をクリックします。
Upgrade Assistantによりスキーマ・アップグレードが可能なコンポーネントが識別され、ユーザーはアップグレードに含めるスキーマを選択できます。

注意:
12.2.1.0コンポーネントをサポートするために使用されるスキーマのみをアップグレードしてください。Oracle Fusion Middleware 12.2.1.0リリースには含まれない、11gまたは12cコンポーネントをサポートするために現在使用されているスキーマをアップグレードしないでください。

4. 「使用可能なコンポーネント」画面に、アップグレード可能なスキーマがある、インストール済Oracle Fusion Middlewareコンポーネントのリストが表示されます。コンポーネントを選択すると、スキーマとすべての依存関係が自動的に選択されます。
「Oracle Platform Security Services」を選択します。これを選択すると、Oracle監査サービスが自動的に選択されます。「次へ」をクリックします。

5. 「ドメイン・ディレクトリ」画面に、12c (12.1.2、12.1.3または12.2.1.0) WebLogicドメイン・ディレクトリを入力します。「参照」をクリックし、ナビゲーション・ツリーを使用して12c WebLogicドメイン・ディレクトリを選択します。
Upgrade Assistantがjps-config.xmlファイルにアクセスするために、12cドメインの場所が必要です。

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

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

7. 「調査」画面には、各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを検証するUpgrade Assistantのステータスが表示されます。ステータスが「調査が終了しました。」になっている場合は、「アップグレード」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログ・ボックスの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、共通するアップグレード・エラーの解決に関する情報をアップグレードのトラブルシューティングで参照します。

注意:

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

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

8. 「アップグレード・サマリー」画面でツリーを展開して、選択したオプションの概要を確認します。
アップグレードに進む前に、ソース・バージョンとターゲット・バージョンを参照して、両方のバージョンが正しいことを確認してください。

レスポンス・ファイルには、Upgrade Assistantのグラフィカル・ユーザー・インタフェース画面で入力したすべての情報が収集して格納され、後でサイレント・アップグレードを実行するために使用できます。サイレント・アップグレードは、Upgrade Assistantウィザードとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。これらのオプションをレスポンス・ファイルに保存する場合、「保存」をクリックし、レスポンス・ファイルの名前および場所を指定します。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。

9. 「アップグレードの進行状況」画面に、アップグレード・プロセスのステータスと、アップグレードが成功した後のコンポーネントの予測ターゲット・バージョンが表示されます。「次へ」をクリックします。

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

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

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

11. アップグレードに失敗すると、「アップグレード失敗」画面が表示されます。これは、1つ以上のコンポーネントのアップグレードに失敗したことを示します。今行った操作では、コンポーネントをアップグレードできません。
「ログの表示」をクリックすると、エラーの表示およびトラブルシューティングを行えます。

Upgrade Assistantを再び起動する前に、アップグレード前の環境の問題を修正します。アップグレード前の環境をバックアップからリストアし(元のバックアップ・ファイルは必ず別の場所に保持してください)、問題を修正し、Upgrade Assistantを再起動します。

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

再構成ウィザードで、ドメインの場所を保持しながらドメインを再構成します。再構成ウィザードを使用して、ドメインを最新バージョンにアップグレードします。

ドメインを再構成する手順は次のとおりです。

1. ドメインが存在するシステムにサインインします。

2. エディション・ベースのデータベース・ユーザーのみ: エディション・ベースの再関連付けを有効にしてスキーマを構成した場合は、再構成ウィザードを実行する前に、デフォルトのエディション名を手動で指定する必要があります。
デフォルトのエディションを設定するには、次のSQLコマンドを入力します。

ALTER DATABASE DEFAULT EDITION = edition_name;
ここで、edition_nameは、デフォルトのデータベース・エディションの名前です。

3. 次のコマンドを入力して再構成ウィザードを実行します。
UNIXオペレーティング・システムの場合:

$ORACLE_HOME/oracle_common/common/bin/reconfig.sh

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

%ORACLE_HOME%\oracle_common\common\bin\reconfig.cmd

注意:
reconfig.cmdまたはreconfig.shコマンドを実行すると、デフォルトのキャッシュ・ディレクトリが無効であることを示す次のエラー・メッセージが表示される場合があります。
*sys-package-mgr*: パッケージ・キャッシュ・ディレクトリを作成できません。

コマンドに-Dpython.cachedir=valid_directoryパラメータを含めることで、キャッシュ・ディレクトリを変更できます。

再構成ウィザードを開始する際に、次の例に示すように"log"オプションを指定することをお薦めします。

./reconfig.sh -log=/$ORACLE_HOME/logs/reconfig.log -log_priority=ALL

要件に応じてlog_priorityを設定できます。

4. 「ドメインの選択」画面でアップグレードするドメインの場所を指定するか、「参照」をクリックして移動し、ドメイン・ディレクトリを選択します。「次へ」をクリックします。

5. 「再構成セットアップの進行状況」画面には、設定プロセスの進行状況が表示されます。完了したら、「次へ」をクリックします。
このプロセスでは次の処理が行われます。

- Fusion Middleware製品を含む、インストール済製品の再構成テンプレートが自動的に適用されます。これにより、config.xml、config-groups.xml、security.xmlなどの様々なドメイン構成ファイルが更新されます。

- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

- ドメイン・アップグレードが検証されます。

6. 「ドメイン・モードおよびJDK」画面で、ドメインで使用するJDKを選択するか、「参照」をクリックして使用するJDKに移動します。「次へ」をクリックします。

注意:
ここでは「ドメイン・モード」は変更できません。

特定のプラットフォームでサポートされているJDKのリストは、Oracle Fusion Middlewareでサポートされているシステム構成を参照してください。

7. JDBCデータ・ソースには、データ・ソース・インスタンスの作成時、デプロイ時もしくはターゲット指定時、またはサーバー起動時に作成されるデータベース接続のプールが含まれます。
アプリケーションはJNDIツリーでデータ・ソースをルックアップしてから、接続をリクエストします。アプリケーションに接続する必要がなくなった場合は、接続がデータ・ソースの接続プールに戻されます。

ドメイン・ソースに定義されているJDBCデータ・ソースは「JDBCデータ・ソース」画面で構成できます。ドメインを作成する製品に関連付けられるJDBCデータ・ソースは、画面の下半分にリスト表示されます。

設定を指定するデータ・ソースを「データソース名」ドロップダウン・リストから選択します。指定した値は、選択されたデータ・ソースのデータ・ソース・リストの適切な列に表示されます。

データ・ソースがOracle RAC構成の場合は、次の3つのオプションのいずれかを選択できます。

- GridLinkへ変換

- RACマルチ・データ・ソースへ変換

- 変換しない

各オプションの詳細は、「ヘルプ」をクリックしてください。

詳細を指定したら、「次へ」をクリックします。

「JDBCデータ・ソース」画面でデータ・ソースを選択しないと、次の警告を示すポップアップが表示されます。

ドライバがありません

「OK」をクリックして検証せずに続行するか、「取消」をクリックして「JDBCデータ・ソース」ページに戻ります。

この場合、「OK」をクリックしてもデータ・ソースは検証されません。

8. 「JDBCデータ・ソース・テスト」画面で、「JDBCデータ・ソース」画面で構成したデータ・ソース接続のチェック・ボックスを選択し、「選択された接続のテスト」をクリックしてデータ・ソース接続をテストします。

注意:
データベース接続をテストするには、接続するデータベースが起動している必要があります。接続をテストしない場合は、データ・ソースを選択しません。「次へ」をクリックして続行します。

9. 「データベース構成タイプ」画面で、「RCUデータ」を選択します。
RCUサービス表(STB)スキーマ資格証明を使用してデータベース接続の詳細を入力するか、「RCU構成の取得」をクリックします。

再構成ウィザードは、この接続を使用してドメイン内のコンポーネントに必要なデータ・ソースを自動的に構成します。

チェックに成功したら、「次へ」をクリックします。チェックが失敗した場合は、接続の詳細を正しく入力し直して再試行します。

10. 「JDBCコンポーネント・スキーマ・テスト」画面で、すべてのコンポーネント・スキーマを選択して「選択された接続のテスト」をクリックして、各スキーマの接続をテストします。
チェックが終了したら、「次へ」をクリックします。

11. 「ノード・マネージャ」画面は、再構成するドメインで、ホストごとのノード・マネージャが使用されている場合にのみ表示されます。
「ノード・マネージャ」画面で、再構成したドメインで使用するノード・マネージャ構成を選択します。結果として生成される構成は、「ノード・マネージャ・タイプ」および「ノード・マネージャ構成」で選択したオプションの組合せに応じて異なります。

表8-1 ノード・マネージャ画面のフィールドの説明

オプション

説明

ドメインごとのデフォルトの場所

このオプションを選択すると、ノード・マネージャ・ホームが$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

ノード・マネージャ資格証明: ユーザー名、パスワード

再構成されたドメインで、ノード・マネージャの起動に使用するユーザー名とパスワードを指定します。

12. 「拡張構成」画面で、拡張構成を実行するすべてのカテゴリを選択できます。選択したカテゴリごとに、詳細構成を行うことができる適切な構成画面が表示されます。

注意:
「拡張構成」画面に表示されるカテゴリは、ドメインで選択したテンプレートに定義されているリソースによって異なります。

このアップグレードでは、オプションを選択せずに「次へ」をクリックします。

13. 「構成のサマリー」画面で、ドメインの詳細な構成を確認してから続行します。
「表示」ドロップダウン・リストからフィルタ・オプションを選択すると、右側のパネルに表示される項目を制限できます。

構成を変更するには、「戻る」をクリックして適切な画面に戻ります。ドメインを再構成するには、「再構成」をクリックします。

注意:
ドメインの再構成時には、ドメインの場所は変更されません。

14. 「再構成の進行状況」画面に、再構成プロセスの進行状況が表示されます。
このプロセスでは次の処理が行われます。

- ドメイン情報が抽出、保存および更新されます。

- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

プログレス・バーに100%が表示されたら、「次へ」をクリックします。

15. 「構成の終了」画面に、再構成プロセスが成功して完了したか、または失敗したかどうかが示されます。管理サーバーURL(リスニング・ポートを含む)とともに再構成されたドメインの場所も表示します。再構成が成功した場合は、Oracle Weblogic Serverの再構成に成功しましたと表示されます。
再構成プロセスが成功して完了しなかった場合は、その理由を示すエラー・メッセージが表示されます。問題を解決するための適切な措置を講じます。問題を解決できない場合は、My Oracle Supportに連絡してください。

今後の操作での使用に備えて、ドメインの場所と管理サーバーのURLを記録しておきます。

8.4 Upgrade Assistantを使用したコンポーネント構成のアップグレード

管理対象ドメインのコンポーネントを含むOracleホームからUpgrade Assistantを実行する場合、「WebLogicコンポーネント構成」アップグレード・オプションを使用できます。

Oracle HTTP Serverのコンポーネント構成をアップグレードする手順は次のとおりです。

1. 次のコマンドを入力して、Upgrade Assistantを12.2.1.1のOracleホームから実行します。
UNIXオペレーティング・システムの場合:

$Oracle_Home/oracle_common/upgrade/bin/ua

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

%Oracle_Home%\oracle_common\upgrade\bin\ua.bat

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

3. 「WebLogicコンポーネント」画面で、「WebLogicコンポーネント構成」オプションを選択して、管理対象WebLogic Serverドメインのコンポーネント構成をアップグレードします。ドメインを管理しているWebLogic管理サーバーに接続するために必要な接続詳細を入力して、「次」をクリックします。

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

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

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

6. 「調査」画面には、各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを検証するUpgrade Assistantのステータスが表示されます。ステータスが「調査が終了しました。」になっている場合は、「アップグレード」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログ・ボックスの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、共通するアップグレード・エラーの解決に関する情報をアップグレードのトラブルシューティングで参照します。

注意:

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

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

7. 「アップグレード・サマリー」画面でツリーを展開して、選択したオプションの概要を確認します。
アップグレードに進む前に、ソース・バージョンとターゲット・バージョンを参照して、両方のバージョンが正しいことを確認してください。

レスポンス・ファイルには、Upgrade Assistantのグラフィカル・ユーザー・インタフェース画面で入力したすべての情報が収集して格納され、後でサイレント・アップグレードを実行するために使用できます。サイレント・アップグレードは、Upgrade Assistantウィザードとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。これらのオプションをレスポンス・ファイルに保存する場合、「保存」をクリックし、レスポンス・ファイルの名前および場所を指定します。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。

8. 「アップグレードの進行状況」画面に、アップグレード・プロセスのステータスと、アップグレードが成功した後のコンポーネントの予測ターゲット・バージョンが表示されます。「次へ」をクリックします。

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

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

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

10. アップグレードに失敗すると、「アップグレード失敗」画面が表示されます。これは、1つ以上のコンポーネントのアップグレードに失敗したことを示します。今行った操作では、コンポーネントをアップグレードできません。
「ログの表示」をクリックすると、エラーの表示およびトラブルシューティングを行えます。

Upgrade Assistantを再び起動する前に、アップグレード前の環境の問題を修正します。アップグレード前の環境をバックアップからリストアし(元のバックアップ・ファイルは必ず別の場所に保持してください)、問題を修正し、Upgrade Assistantを再起動します。

8.5 アップグレード後のタスク

アップグレード後のタスクには、ノード・マネージャの起動、管理サーバーの起動、Oracle HTTP Serverの起動および以前の12cリリースから本リリースへのアップグレードが成功したかどうかの確認などが含まれます。

- ノード・マネージャの起動
WebLogic Serverの本番環境では、サーバー・インスタンスが複数のドメイン、マシンおよび地理的な場所にまたがって分散することがよくあります。ノード・マネージャは、離れた場所から管理サーバー・インスタンスや管理対象サーバー・インスタンスを起動、停止、および再起動できるWebLogic Server付属のユーティリティです。

- 管理サーバーの起動
各ドメインでは、1つのWebLogic Serverインスタンスが管理サーバーの役割を担います。管理サーバーではWebLogic Serverドメインを一元的に管理できます。ドメイン内の他のすべてのWebLogic Serverインスタンスは、管理対象サーバーと呼ばれます。1つのWebLogic Serverインスタンスしか含まれないドメインでは、そのサーバーが管理サーバーおよび管理対象サーバーとして機能します。

- Oracle HTTP Serverの起動
Oracle HTTP Serverを起動、停止および再起動するには、Enterprise Manager Fusion Middleware Controlまたはopmnctlコマンドを使用できます。

- Oracle HTTP Serverのインストール成功の確認
管理コンソールとEnterprise Manager Fusion Middleware Controlにログインできれば、Oracle HTTP Serverは正常にインストールされています。

8.5.1 ノード・マネージャの起動

WebLogic Serverの本番環境では、サーバー・インスタンスが複数のドメイン、マシン、および地理的な場所にまたがって分散することがよくあります。ノード・マネージャは、離れた場所から管理サーバー・インスタンスや管理対象サーバー・インスタンスを起動、停止、および再起動できるWebLogic Server付属のユーティリティです。

Windowsオペレーティング・システムの場合は、ノード・マネージャを起動サービスとして実行するように構成することをお薦めします。これによって、システムが再起動されるたびに、ノード・マネージャが自動で起動されます。詳細は、『Oracle WebLogic Serverノード・マネージャの管理』の起動サービスとしてのノード・マネージャの実行に関する項を参照してください。

注意:
UNIXプラットフォームでは、ノード・マネージャをルート・ユーザーとして実行しないでください。

ノード・マネージャを起動するには:

1. 次のディレクトリに移動します。
UNIXオペレーティング・システムの場合:

$ORACLE_HOME/wlserver/server/bin/

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

%ORACLE_HOME%\wlserver\server\bin\

2. UNIXオペレーティング・システムで次のコマンドを実行して、ノード・マネージャを起動します。
nohup ./startNodeManager.sh > nm.out&

この例のnohupとnm.outはサンプル出力ファイルです。

Windowsオペレーティング・システムで次のコマンドを実行して、ノード・マネージャを起動します。

startNodeManager.cmd

「スタート」メニューのショートカットからでもノード・マネージャを起動できます。「ツール」に続いて「ノード マネージャ」をクリックします。

8.5.2 管理サーバーの起動

各ドメインでは、1つのWebLogic Serverインスタンスが管理サーバーの役割を担います。管理サーバーではWebLogic Serverドメインを一元的に管理できます。ドメイン内の他のすべてのWebLogic Serverインスタンスは、管理対象サーバーと呼ばれます。1つのWebLogic Serverインスタンスしか含まれないドメインでは、そのサーバーが管理サーバーおよび管理対象サーバーとして機能します。

通常、開発環境では、管理サーバーを起動し、アプリケーションをすぐにその管理サーバーにデプロイすれば十分です。しかし、本番環境では、アプリケーションを実行する管理対象サーバーの作成をお薦めします。

管理サーバーを起動する手順は次のとおりです。

1. 次のディレクトリに移動します。
$DOMAIN_HOME/DOMAIN_NAME

ここで、DOMAIN_NAMEは、ドメインを配置したディレクトリの名前です。

2. Windowsオペレーティング・システムで次のコマンドを実行して、管理サーバーを起動します。
startWebLogic.cmd

Windowsオペレーティング・システムでは、作成した管理サーバーを起動するためのショートカットが、構成ウィザードによって「スタート」メニューに作成されます。

UNIXオペレーティング・システムで次のコマンドを実行して、管理サーバーを起動します。

./startWebLogic.sh

注意:
サーバーがユーザー名とパスワードの入力を要求する場合は、サーバーを起動する許可を持つWebLogic Serverユーザーの名前を入力します。

8.5.3 Oracle HTTP Serverの起動

Oracle HTTP Serverを起動、停止および再起動するには、Enterprise Manager Fusion Middleware Controlまたはopmnctlコマンドを使用できます。

8.5.3.1 Enterprise Manager Fusion Middleware Controlを使用した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. 「コントロール」メニューから「起動」を選択します。

8.5.3.1.1 opmnctlを使用したOracle HTTP Serverの起動

opmnctlを使用してOracleインスタンス内のOracle HTTP Serverコンポーネントを起動するには、次を実行します。

1. 次のディレクトリに移動します。
ORACLE_INSTANCE/bin

2. 次のコマンドを実行して、Oracleインスタンス内のすべてのOracle HTTP Serverコンポーネントを起動します。
opmnctl startproc process-type=OHS

8.5.3.1.2 opmnctlを使用したOracle HTTP Serverコンポーネントのステータスの判定

Oracle HTTP Serverコンポーネントのステータスを判定する手順は次のとおりです。

1. 次のディレクトリに移動します。
ORACLE_INSTANCE/bin

2. 次のコマンドを入力します。
opmnctl status

サンプル出力は次のようになります。

Processes in Instance: instance1
---------------------------------+--------------------+---------+---------
ias-component                    | process-type       |     pid | status
---------------------------------+--------------------+---------+---------
webcache1                        | WebCache-admin     |   19556 | Alive
webcache1                        | WebCache           |   19555 | Alive
ohs1                             | OHS                |    7249 | Alive

8.5.4 Oracle HTTP Serverインストール成功の確認

管理コンソールとEnterprise Manager Fusion Middleware Controlにログインできれば、Oracle HTTP Serverは正常にインストールされています。

ソフトウェア・パッチが正常にインストールされていることを確認する手順は、次のとおりです。

1. 次のURLにログインします。
http://MachineName.us.oracle.com:7777

2. Enterprise Manager Fusion Middleware Controlにアクセスするには、次のように指定します。
http://MachineName.us.oracle.com:7001/em

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2016, 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およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork 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を参照してください。