Oracle® Fusion Middleware

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

12c (12.2.1.1)

E77368-01(原本部品番号:E71494-01)

2016年6月

Oracle Fusion Middleware Infrastructure 12cへのアップグレードを希望するOracle Fusion Middleware管理者向けのドキュメント。

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

E77368-01

Copyright © 2015, 2016, Oracle and/or its affiliatesAll rights reserved

原本著者: Priyanka Chheda、Lisa Jamen

協力者: Bill Norcott、Michael Rubino、Renga Rengarajan、Robert Donat、Rubis Chowallur、Sitaraman Swaminathan。

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

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

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

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 (12.2.1.1)の新機能と変更された機能

- このガイドのその他の変更点

1 Oracle Fusion Middleware Infrastructureアップグレードの概要

- 1.1 Oracle Fusion Middleware Infrastructureアップグレードの開始点についての理解

- 1.1.1 Oracle Fusion Middleware Infrastructure 12cについて

- 1.1.2 Application Developer 11gとInfrastructure 12cの重要な違い

- 1.1.2.1 Infrastructure 12cにはOracle WebLogic Serverが含まれる

- 1.1.2.2 Infrastructure 12cのデータベース・スキーマ要件

- 1.1.2.3 OIDベースのポリシー・ストアの使用

- 1.1.2.4 Infrastructure 12cドメインにOracle HTTP Serverを含めることができる

- 1.2 セキュリティ・ストアのアップグレード

- 1.3 Infrastructureにおける標準的なアップグレード・トポロジの理解

- 1.3.1 Fusion Middleware Infrastructureの標準アップグレード・トポロジ

- 1.4 Oracle Fusion Middleware 12cの追加新機能の理解

- 1.5 Fusion Middleware Infrastructureへのアップグレードのフロー・チャートおよびタスク・ロードマップ

- 1.5.1 Infrastructure標準アップグレード・トポロジのアップグレードのフロー・チャート

- 1.5.2 Infrastructure標準アップグレード・トポロジのアップグレードのロードマップ

- 1.6 Oracle JDeveloper 12cを使用したカスタム・アプリケーションのアップグレード

2 Fusion Middleware Infrastructureへのアップグレードの準備

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

3 Fusion Middleware Infrastructureのアップグレード

- 3.1 Infrastructure用アップグレード前タスクの完了(必須)

- 3.1.1 カスタムsetDomainEnv設定のメンテナンス(オプション)

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

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

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

- 3.1.5 準備状況チェックの実行

- 3.1.5.1 Upgrade Assistantを使用したアップグレード前準備状況チェックの実行について

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

- 3.1.5.1.2 準備状況チェックの実行

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

- 3.1.5.2 準備状況チェック画面

- 3.1.5.2.1 ようこそ

- 3.1.5.2.2 準備状況チェック・タイプ: 個別に選択されたスキーマ

- 3.1.5.2.3 準備状況チェック・タイプ: ドメイン・ベース

- 3.1.5.2.4 使用可能なコンポーネント

- 3.1.5.2.5 スキーマ資格証明

- 3.1.5.2.6 準備状況サマリー

- 3.1.5.2.7 準備状況チェック

- 3.1.5.2.8 ログ・ビューア

- 3.1.5.2.9 準備状況成功

- 3.1.5.2.10 準備状況レポートのサンプル

- 3.2 Fusion Middleware Infrastructureのインストール

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

- 3.4 作成するスキーマの決定

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

- 3.6 スキーマ・バージョン・レジストリを使用した既存のスキーマの識別

- 3.7 Upgrade Assistantを使用したスキーマのアップグレードについて

- 3.8 Upgrade Assistantでアップグレードできるスキーマの識別

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

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

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

- 3.12 Infrastructureアップグレードのトラブルシューティング

- 3.12.1 認証失敗 — JSch例外: 認証失敗

- 3.12.2 ユーザー・メッセージング・サービス(UMS)構成ファイルのコピー中のエラー

- 3.13 アップグレード後のタスクの実行

4 アップグレード後に実行するタスク

- 4.1 アップグレードの検証チェックリストの使用

- 4.2 サーバーの正しい順序での起動と停止

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

- 4.2.2 管理サーバーの起動

- 4.2.3 Web層(Oracle HTTP Server)の起動

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

- 4.4 カスタム構成設定のsetDomainEnvへの再適用

- 4.5 Oracle Fusion Middleware 12c監査データ・ストアの構成

- 4.6 古いJava EE Webサービス・アプリケーションのセキュリティ・ステータスのメンテナンス

- 4.7 Oracle Fusion Middleware 12cソフトウェアの管理のためのドキュメント・リソース

- 4.8 Oracle Fusion Middleware 12cでの11gアプリケーション・デプロイメントの使用

- 4.8.1 Oracle Application Development Framework (ADF) 12cについて

- 4.8.2 Oracle JDeveloper 12cについて

- 4.8.2.1 Oracle JDeveloper 12cのインストール

- 4.8.2.2 Oracle JDeveloper 12cを使用したアプリケーションの移行

- 4.8.2.3 Oracle JDeveloper 12cを使用した非同期Webサービスの移行について

- 4.9 既存の環境がクラスタ構成の場合

A Upgrade Assistantの起動

- A.1 グラフィカル・ユーザー・インタフェース(GUI)モードでのUpgrade Assistantの起動

- A.1.1 追加のパラメータ(オプション)を使用したUpgrade Assistantの起動

- A.2 レスポンス・ファイル・モードでのUpgrade Assistantの起動

- A.2.1 アップグレード・レスポンス・ファイルの作成

- A.2.2 レスポンス・ファイルを使用したFusion Middlewareのアップグレード

- A.3 DISPLAY環境変数の設定

はじめに

このガイドを使用して、スキーマ、ドメイン構成およびサポートされている11g Oracle Fusion MiddlewareテクノロジをOracle Fusion Middleware Infrastructure 12c (12.2.1)にアップグレードします。

また、このガイドには、Oracle Fusion Middleware Infrastructure 12c (12.1.2または12.1.3)から12c (12.2.1)にアップグレードするための情報も記載されています。

- 対象読者

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

- 関連ドキュメント

- 表記規則

対象読者

このドキュメントは、Oracle Fusion Middlewareのインストール、アップグレードおよび管理タスクの知識がある管理者を対象としています。

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

オラクル社のアクセシビリティへの取組みの詳細は、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 (12.2.1)ドキュメンテーション・セットの次のドキュメントを参照してください。

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

- Oracle Fusion Middleware Infrastructureのインストールと構成

- Oracle WebLogic Serverのアップグレード

- Oracle HTTP Serverのアップグレード

- Oracle Data Integratorのアップグレード

- Oracle SOA SuiteおよびBusiness Process Managementのアップグレード

表記規則

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

表記規則

意味

太字

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

イタリック体

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

固定幅フォント

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

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

この章では、Oracle Fusion Middlewareのアップグレード・ツールおよびプロセスの新機能と変更された機能を示します。

また、ここではこのマニュアルについての情報と、追加情報へのポインタも提供しています。

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

- このガイドのその他の変更点

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

Oracle Fusion Middleware 12cには、次に示す新しいアップグレード処理とツール、さらには新しい一連のインストーラが導入されており、これらはディストリビューションと呼ばれます。

- リリース12c (12.1.2)より、Oracle Fusion Middleware Infrastructureと呼ばれる新しいディストリビューションがあります。このディストリビューションには、Oracle WebLogic ServerインストーラとApplication Developer 11gインストーラの機能を組み合せたインストーラが含まれています。
そのため、このディストリビューションには、JavaアプリケーションとOracle Application Development Framework (Oracle ADF)アプリケーションのデプロイおよび管理に使用できるOracle WebLogic Serverドメインを作成するために必要なすべてのものが含まれています。

詳細は、Oracle Fusion Middlewareの理解に関するドキュメントを参照してください。

- 12c (12.1.2)より、Oracle Fusion Middlewareデータベース・スキーマのアップグレード、およびコンポーネント構成の12cへのアップグレードには、改善された新しいOracle Fusion Middlewareアップグレード・アシスタントが使用されます。
詳細は、『Oracle Fusion Middlewareのアップグレードのプランニング』を参照してください。

- リリース12c (12.1.2)より、既存の11gドメインから12cへのアップグレードには、新しい再構成ウィザードが使用されます。
詳細は、『Oracle WebLogic Serverのアップグレード』を参照してください。

このガイドのその他の変更点

リリース12c (12.1.2)より、Oracle Fusion Middlewareドキュメント・ライブラリに新しいマニュアルが追加されます。ただし、以前、Oracle Fusion Middleware 11gバージョンのOracle Fusion Middleware SOA、WebCenterおよびADFアップグレード・ガイドに含まれていた、Oracle ADF用の内容と似た情報が含まれています。

Oracle Fusion Middleware 12cでは、JavaおよびOracle ADFカスタム・アプリケーションのデプロイメントと管理のためにApplication Developer 11g環境をインストールして構成したOracle Fusion Middleware 11gユーザー向けのアップグレード処理について説明した、別のガイドが必要でした。

1 Oracle Fusion Middleware Infrastructureアップグレードの概要

Oracle Fusion Middleware Infrastructure 12cへのアップグレードには、慎重な準備と計画が必要です。Oracleでは大部分のアップグレード・プロセスを自動化するツールおよびテクノロジを提供しています。

この章のトピックをレビューして、アップグレードを理解し、準備してください。 この章のトピックは、次のとおりです:

- Oracle Fusion Middleware Infrastructureアップグレードの開始点の理解
このガイドのアップグレード手順では、既存のApplication Server 11gドメインおよびそのドメインのOracle Fusion Middlewareコンポーネント構成をOracle Fusion Middleware Infrastructure 12c (12.2.1.1)にアップグレードする方法を重点的に説明します。

- セキュリティ・ストアのアップグレード
OPSSセキュリティ・ストアをアップグレードする前に、アップグレードに失敗した場合にリカバリできるようセキュリティ・ストアをバックアップすることが重要です。

- 標準のInfrastructure用アップグレード・トポロジの理解
標準のInfrastructureアップグレード・トポロジにより、アップグレード前およびアップグレード後の環境を理解するために役立ちます。

- Oracle Fusion Middleware 12cの追加新機能の理解
Oracle Fusion Middleware Infrastructure 12cへのアップグレードを開始する前に、Oracle Fusion Middleware 12cで利用可能な新機能と変更点をレビューしてください。

- Fusion Middleware Infrastructureにアップグレードするためのフロー・チャートおよびロード・マップ
このトピックの各項では、標準的なトポロジをアップグレードするための高度な手順を説明します。

- Oracle JDeveloper 12cを使用したカスタム・アプリケーションのアップグレード
カスタム・アプリケーションをOracle Fusion Middleware Application Developer 11gドメインにデプロイしていた場合、アップグレード手順が完了した後、アプリケーションのデプロイメントはOracle Fusion Middleware 11gでの場合と同様に機能します。ただし、新しいOracle Application Development Framework (Oracle ADF) 12cの機能を利用する場合は、Oracle JDeveloper 12cをダウンロードしてインストールします

1.1 Oracle Fusion Middleware Infrastructureアップグレードの開始点についての理解

このガイドのアップグレード手順では、既存のApplication Server 11gドメインおよびそのドメインのOracle Fusion Middlewareコンポーネント構成をOracle Fusion Middleware Infrastructure 12c (12.2.1.1)にアップグレードすることが第一の焦点です。

サポートされている次の開始点から、このバージョンのOracle Fusion Middleware Infrastructureにアップグレードできます。

- Oracle Fusion Middleware Application Developer 11g (11.1.1.6、11.1.1.7、11.1.1.8、11.1.1.9)

- Oracle Fusion Middleware Infrastructure 12c (12.1.2.0、12.1.3.0、12.2.1.0)。

注意:

既存のApplication Developer 11gドメインに関連付けてOracle HTTP Serverインスタンスをアップグレードする場合、スタンドアロンOracle HTTP Serverのアップグレードの手順の詳細は、Oracle HTTP Serverのアップグレードについてを参照してください。

- Oracle Fusion Middleware Infrastructure 12cについて
Oracle Fusion Middleware 12c (12.2.1.1)リリースの一部として提供されるOracle Fusion Middleware Infrastructureディストリビューションは、11gのOracle WebLogic ServerとApplication Developerのインストーラによって提供されるものと似た一連のテクノロジとコンポーネントを提供します。Infrastructureディストリビューションは、他のFusion Middleware製品をインストールするために必要なWebLogic ServerおよびJava Required Files (JRF)をパックしています。

- Application Developer 11gとInfrastructure 12cとの重要な違い
Oracle Fusion Middleware Infrastructure 12cは11g Application Developerインストールと似ていますが、この項でリスト表示されているいくつかの違いがあります。

1.1.1 Oracle Fusion Middleware Infrastructure 12cについて

Oracle Fusion Middleware 12c (12.2.1.1)リリースの一部として使用可能なOracle Fusion Middleware Infrastructureディストリビューションは、11gのOracle WebLogic ServerおよびApplication Developerインストーラで用意されているものと同様の、一連のテクノロジおよびコンポーネントを備えています。Infrastructureディストリビューションは、他のFusion Middleware製品をインストールするために必要なWebLogic ServerおよびJava Required Files (JRF)をパックしています。

1.1.2 Application Developer 11gとInfrastructure 12cの重要な違い

Oracle Fusion Middleware Infrastructure 12cは11g Application Developerインストールと似ていますが、この項でリスト表示されているいくつかの違いがあります。

- Infrastructure 12cはOracle WebLogic Serverを包含しています
Application Developer 11gインストールには個別の2つのインストールが必要でした(Oracle WebLogic Serverと、その後、Oracle JRFライブラリとコンポーネントを追加するためのApplication Developer)。Oracle Fusion Middleware 12cでは、フレッシュ・インストールにはOracle WebLogic ServerとJava Required Files(JRF)の両方が含まれるOracle Fusion Middleware Infrastructureディストリビューションのみが必要です。

- Infrastructure 12cのデータベース・スキーマ要件
Application Developer 11gインストールと異なり、Infrastructure 12cインストールでは、サポートされているデータベースで一連の必須スキーマを作成する必要があります。特に、Oracle Fusion Middleware Infrastructure 12 cソフトウェアを構成する前に、12cのリポジトリ作成ユーティリティ(RCU)を使用して、必要なデータベース・スキーマを作成する必要があります。

- OIDベースのポリシー・ストア
11gでOracle Internet Directory (OID)ベースのポリシー・ストアを使用している場合は、12cリポジトリ作成ユーティリティ(RCU)を使用して、新しい12c OPSSスキーマを作成します。アップグレード・アシスタントで、OPSSスキーマを選択します(アップグレード・アシスタントによってOIDベースのポリシー・ストアがアップグレードされます)。アップグレードするために、OIDベースのポリシー・ストアを12cに再関連付けする必要はありません。

- Infrastructure 12cドメインはOracle HTTP Serverを含むことができます
Oracle Fusion Middleware 11gでは、通常、Oracle HTTP Serverインスタンスは11g Middlewareホームとは別のOracleインスタンス・ディレクトリに構成されます。ただし、Oracle Fusion Middleware 12cでは、Oracle Fusion Middleware構成ウィザードを使用して、Oracle HTTP ServerインスタンスをOracle WebLogic Serverドメインの一部として構成できます。

1.1.2.1 Infrastructure 12cにはOracle WebLogic Serverが含まれる

Application Developer 11gインストールには個別の2つのインストールが必要でした(Oracle WebLogic Serverと、その後、Oracle JRFライブラリとコンポーネントを追加するためのApplication Developer)。Oracle Fusion Middleware 12cでは、フレッシュ・インストールにはOracle WebLogic ServerとJava Required Files(JRF)の両方が含まれるOracle Fusion Middleware Infrastructureディストリビューションのみが必要です。

アップグレード手順では、新しいOracle Fusion Middleware 12cドメインの構成は必要ありません。かわりに、再構成ウィザードを使用してドメインをアップグレードします。詳細は、Oracle Fusion Middlewareのアップグレードのプランニングのアップグレードおよび構成ツールの理解と入手を参照してください。

1.1.2.2 Infrastructure 12cのデータベース・スキーマ要件

Application Developer 11gインストールと異なり、Infrastructure 12cインストールでは、サポートされているデータベースで一連の必須スキーマを作成する必要があります。特に、Oracle Fusion Middleware Infrastructure 12 cソフトウェアを構成する前に、12cのリポジトリ作成ユーティリティ(RCU)を使用して、必要なデータベース・スキーマを作成する必要があります。

Oracle Fusion Middleware Infrastructure 12cにアップグレードする前に、要件に応じて次のデータベース・スキーマを1つ以上インストールする必要があります。

- サービス表(STB)スキーマは、すべてのOracle Fusion Middleware Infrastructure 12cインストールに必要な新しいスキーマです。このスキーマによって、クロス・コンポーネント・ワイヤリングと呼ばれる新しい12c機能が有効になります。詳細は、Oracle Fusion Middlewareの管理のクロス・コンポーネント・ワイヤリングを参照してください11gリリースからアップグレードする場合、リポジトリ作成ユーティリティ(RCU)を使用して12c STBスキーマを作成する必要があります。ただし、以前の12cリリースからアップグレードする場合は、STBスキーマを作成する必要はなく、Upgrade Assistantを使用してアップグレードできます。

- OPSSスキーマ: Oracle Platform Security Servicesにデータベースベースのポリシー・ストアを提供します。
表1-1に、11gで使用されるポリシー・ストアの概要およびアップグレード方法を示します。

表1-1 Oracle Fusion Middleware 11gポリシー・ストアのアップグレードの概要

使用しているコンソール

次のアクションを実行

参照先

11gのOracle Internet Directory (OID)ベースのポリシー・ストア

- アップグレード前に12cリポジトリ作成ユーティリティ(RCU)を使用して、新しい12c OPSSスキーマを作成します。

- アップグレード・アシスタントで、OPSSスキーマを選択します(アップグレード・アシスタントによってOIDベースのポリシー・ストアがアップグレードされます)。

注意:
12c OPSSデータベース・スキーマが必要なのは、ドメインの再構成時に12cスキーマを参照するためのみです。ドメインでは、アップグレード後にOIDベースのポリシー・ストアが引き続き使用されます。

- OIDベースのセキュリティ・ストアのアップグレード

11gのファイルベースのポリシー・ストアおよびOPSSスキーマ

RCUを使用して12c OPSSスキーマを作成します。

該当なし

データベースベースのポリシー・ストアおよびOPSSスキーマ

アップグレード・アシスタントを使用して、既存の11g OPSSスキーマを作成します。

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

- IAUスキーマ: OPSS監査機能に使用されます。
11gで監査データ・ストアを使用しているかどうか、および使用している監査データ・ストアのタイプに応じて、IAU 12cスキーマの作成が必要な場合があります。詳細は、次の表を参照してください。

表1-2 Oracle Fusion Middleware 11g監査ストアのアップグレードの概要

使用しているコンソール

次のアクションを実行

11gのファイルベースの監査ストア

- アップグレードの前に、新しい12c IAUスキーマを作成します。

データベースベースの監査ストアおよびIAU 11gスキーマ

- Upgrade Assistantを使用して既存の11g IAUスキーマをアップグレードした後、ドメインの再構成時にアップグレードした11gスキーマを参照します。

1.1.2.3 OIDベースのポリシー・ストアの使用

11gでOracle Internet Directory (OID)ベースのポリシー・ストアを使用している場合は、12cリポジトリ作成ユーティリティ(RCU)を使用して、新しい12c OPSSスキーマを作成します。アップグレード・アシスタントで、OPSSスキーマを選択します(アップグレード・アシスタントによってOIDベースのポリシー・ストアがアップグレードされます)。アップグレードするために、OIDベースのポリシー・ストアを12cに再関連付けする必要はありません。

注意:
12c OPSSデータベース・スキーマが必要なのは、ドメインの再構成時に12cスキーマを参照するためのみです。ドメインでは、アップグレード後にOIDベースのポリシー・ストアが引き続き使用されます。

1.1.2.4 Infrastructure 12cドメインにOracle HTTP Serverを含めることができる

Oracle Fusion Middleware 11gでは、通常、Oracle HTTP Serverインスタンスは11g Middlewareホームとは別のOracleインスタンス・ディレクトリに構成されます。ただし、Oracle Fusion Middleware 12cでは、Oracle Fusion Middleware構成ウィザードを使用して、Oracle HTTP ServerインスタンスをOracle WebLogic Serverドメインの一部として構成できます。

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

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

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

Oracle HTTP Serverをアップグレードするには、Oracle HTTP Serverのアップグレードを参照してください。

1.2 セキュリティ・ストアのアップグレード

OPSSセキュリティ・ストアをアップグレードする前に、アップグレードに失敗した場合にリカバリできるようセキュリティ・ストアをバックアップすることが重要です。

セキュリティ・ストアのバックアップの詳細は、「OPSSセキュリティ・ストアのバックアップとリカバリ」を参照してください。

アップグレード手順は、アップグレードされるセキュリティ・ストアのタイプに応じて異なります。アップグレードされるセキュリティ・ストアは、ファイルベース、OIDベースまたはDBベースのいずれも可能です。手順は、ソース監査データ・ストアのタイプ(ファイルベースまたはDBベース)に応じて異なることに注意してください。

セキュリティ・ストアのアップグレードの詳細は、12.2.1.xへのセキュリティ・アップグレードを参照してください。

1.3 Infrastructureにおける標準的なアップグレード・トポロジの理解

標準のInfrastructureアップグレード・トポロジにより、アップグレード前およびアップグレード後の環境を理解するために役立ちます。

Oracle Fusion Middleware Application Developer 11gソフトウェアを使用して、アプリケーション、組織およびアプリケーション・ユーザーのニーズに応じた様々な本番トポロジを作成できます。

そのため、考えられるすべてのApplication Developer 11gインストールに対して正確なアップグレード手順を示すことは困難です。この問題を解決するために、このアップグレード・ドキュメントでは、一般的なApplication Developer構成をアップグレードする詳細な手順を説明しています。この一般的なトポロジを、Oracle Fusion Middleware 12の標準アップグレード・トポロジと呼びます。

このガイドでは、具体的には、Oracle JRFとOracle ADFアプリケーションのデプロイメントをサポートするように構成された2つの管理対象サーバーのクラスタが含まれるドメインを構成するために、Oracle WebLogic ServerとApplication Developer 11gソフトウェアを使用したと想定しています。

実際のトポロジは異なる場合がありますが、ここで説明するトポロジを、他の同様のApplication Developerトポロジをアップグレードする際の参考にしてください。

- Fusion Middleware Infrastructureの標準アップグレード・トポロジ
このトピックでは、Fusion Middleware Infrastructureを最新の12cリリースにアップグレードするための標準トポロジについて説明します。

1.3.1 Fusion Middleware Infrastructureの標準アップグレード・トポロジ

このトピックでは、Fusion Middleware Infrastructureを最新の12cリリースにアップグレードするための標準トポロジについて説明します。

図1-1に、Oracle Fusion Middleware 11g Application Developerの標準アップグレード・トポロジと、このガイドのアップグレード手順実行後のOracle Fusion Middleware 12c Infrastructureトポロジを示します。

図1-1 Infrastructureアップグレード・トポロジ

このトポロジ図のすべての要素を表1-3に示します。

表1-3 Infrastructureの標準アップグレード・トポロジの要素の説明

要素

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

11g Application Developerトポロジ

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

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

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

12c Infrastructureの標準インストール・トポロジ

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

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

APPHOST

アプリケーション層をホストしているマシンを示す、Oracleドキュメントで使用される標準用語。

DBHOST

データベースをホストしているマシンを示す、Oracleドキュメントで使用される標準用語。

Application Developer 11gではデータベースは任意ですが、Oracle Fusion Middleware 12cではデータベースが必要であることに注意してください。詳細は、Infrastructure 12cのデータベース・スキーマ要件を参照してください。

ファイルベースのストア

XMLのファイルベースのセキュリティ・ストア11gでは、ファイルベースのセキュリティ・ストアまたはデータベースベースのセキュリティ・ストアを使用できました。

ただし、12cではファイルベースのストアは非推奨で、サポートされているデータベースでOracle Platform Security Services (OPSS)スキーマを使用する必要があります。再構成ウィザードは、ファイルベースのストアをDBベースのストアに再関連付けするプロセスを自動化します。

スキーマがあるデータベース

リポジトリ作成ユーティリティ(RCU)を使用してOracle Fusion Middlewareスキーマが作成された、サポートされているデータベースを表します。

WebLogicドメイン

論理的に関連するJavaコンポーネントのグループ(ここでは管理サーバー、管理対象サーバーおよびその他の関連するソフトウェアコンポーネント)。

詳細は、Oracle Fusion Middlewareの理解のOracle WebLogic Serverドメインの概要を参照してください。

管理サーバー

ドメインの構成オブジェクトを管理し、管理対象サーバーに構成変更を配布する、ドメインの中央制御エンティティ。

詳細は、Oracle Fusion Middlewareの理解の管理サーバーの概要を参照してください。

Enterprise Manager

Oracle Enterprise Manager Fusion Middleware Control。ドメインを管理するために使用する主要ツール。

詳細は、Oracle Fusion Middlewareの理解のOracle Enterprise Manager Fusion Middleware Controlに関する項を参照してください。

クラスタ

同時に稼働し連携する、複数のWebLogic Serverインスタンスの集合。

詳細は、Oracle Fusion Middlewareの理解の管理対象サーバーと管理対象サーバー・クラスタの理解に関する項を参照してください。

マシン

1つまたは複数のWebLogic Serverインスタンス(サーバー)をホストするコンピュータを論理的に表現するもの。マシンは、ノード・マネージャを使用して管理対象サーバーを起動または停止するためにWebLogicの管理対象サーバーとノード・マネージャを論理的に結び付けるものでもあり、管理対象サーバーはマシンに関連付けされている必要があります。

管理対象サーバー

アプリケーション、アプリケーション・コンポーネント、Webサービスおよび関連リソースをホストします。

詳細は、Oracle Fusion Middlewareの理解の管理対象サーバーと管理対象サーバー・クラスタの理解に関する項を参照してください。

Oracle JRF

Oracle JRF (Java Required Files)は、Oracle WebLogic Serverインストールに含まれておらず、Oracleビジネス・アプリケーションおよびアプリケーション・フレームワークに共通の機能を提供するコンポーネントで構成されています。

JRFには、共通の場所にデプロイされる、いくつかの個別に開発されたライブラリおよびアプリケーションが含まれています。Java Required Filesに属すると見なされるコンポーネントには、Oracle Application Development Frameworkの共有ライブラリやODLロギング・ハンドラなどがあります。

インフラストラクチャ

次のものを含むサービスのコレクションを表すOracle Fusion Middleware 12cの用語(Oracle JRFと同様)。

- Metadata repository (MDS)
これにはOracle Application Developer Frameworkなどの、Oracle Fusion Middlewareコンポーネントのメタデータが含まれます。

詳細は、Oracle Fusion Middlewareの理解のメタデータ・リポジトリの概要を参照してください。

- Oracle Application Developer Framework (ADF)

- Oracle Web Services Manager(OWSM)

Application Developer 11gトポロジは、「Application Developer 11gとInfrastructure 12cの重要な違い」で説明する違いを除き、Oracle Fusion Middleware Infrastructure 12cトポロジと同様です。

1.4 Oracle Fusion Middleware 12cの追加新機能の理解

Oracle Fusion Middleware Infrastructure 12cへのアップグレードを開始する前に、Oracle Fusion Middleware 12cで利用可能な新機能と変更点を確認してください。

特に、Oracle Fusion Middlewareの理解の次の項を参照してください。

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

- 12cの新しい用語および非推奨用語

- WebLogic Management Frameworkとは

1.5 Fusion Middleware Infrastructureへのアップグレードのフロー・チャートおよびタスク・ロードマップ

このトピックの各項では、標準的なトポロジをアップグレードするための高度な手順を説明します。

- Infrastructureの標準アップグレード・トポロジをアップグレードするためのフロー・チャート
このトピックは、フローチャートの助けをかりて高度なアップグレード・プロセスを理解するために役立ちます。

- Infrastructureの標準アップグレード・トポロジをアップグレードするためのロードマップ
このトピックでは、最新のFusion Middleware Infrastructure 12cリリースにアップグレードするために完了する必要がある高度なタスクについて説明します。

1.5.1 Infrastructure標準アップグレード・トポロジのアップグレードのフロー・チャート

このトピックは、フローチャートの助けをかりて高度なアップグレード・プロセスを理解するために役立ちます。

図1-2 Fusion Middleware Infrastructure (標準トポロジ)をアップグレードするためのフロー・チャート

1.5.2 Infrastructure標準アップグレード・トポロジのアップグレードのロードマップ

このトピックでは、最新のFusion Middleware Infrastructure 12cリリースにアップグレードするために完了する必要がある高度なタスクについて説明します。

表1-4 Oracle Fusion Middleware Infrastructureアップグレード・ロードマップ

手順番号

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

タスク

説明

1

推奨。

『アップグレード・プランニング・ガイド』および『相互運用および互換性ガイド』をレビューして、Infrastructure 12.2.1.1へのアップグレード方法に影響する可能性がある相互運用性および互換性の要因について学習してください。

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

プランニング関連の詳細は、Oracle Fusion Middlewareのアップグレードのプランニングを参照してください。

相互運用性および互換性の要因について学習するには、相互運用性および互換性の理解を参照してください。

2

必須。

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

ドメインの構成はインプレースでアップグレードされるため、アップグレードの前に既存の環境をバックアップすることが重要です。バックアップにより、アップグレードが失敗するかアップグレードの結果が満足できない場合にアップグレード前環境をリストアできます。

詳細は、完全なバックアップの作成を参照してください。

.

3

推奨。

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

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

アップグレード前タスクの完全なリストは、Oracle Fusion Middlewareアップグレード前チェックリストを参照してください。

4

必須。

12.2.1.1 Fusion Middleware Infrastructureを新しいOracleホームにインストールします。

Oracle Fusion Middleware Infrastructure 12cを、Oracle Fusion Middleware Application Developer 11gまたは以前の12cバージョンのOracle Fusion Middleware Infrastructureをインストールしたホスト上の新しいOracleホームにインストールします。

Fusion Middleware Infrastructureのインストールの手順に従います。

5

必須。

既存のデプロイメント内の管理サーバーおよび管理対象サーバーを停止します。

サーバーおよびプロセスの停止の説明に従って、管理サーバーおよびすべての管理対象サーバーを停止します。

6

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

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

準備状況チェックは、アップグレード前環境およびその環境のコンポーネントがアップグレードの準備ができていることを確認するために役立ちます。詳細は、準備状況チェックの実行を参照してください。

7

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

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

11gリリースからアップグレードする場合、RCUを使用して必要なスキーマを作成する必要があります。Oracle Fusion Middleware 11gと異なり、サポートされているデータベースに必要なスキーマをインストールしないと、Oracle Fusion Middleware 12cドメインを構成することはできません。
詳細は、RCUを使用した必要なスキーマの作成を参照してください。

8

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

Upgrade Assistantを使用してデータベース・スキーマをアップグレードします。

Upgrade Assistantでは、「ドメインで使用されるすべてのスキーマ」オプションを選択できます。このオプションを選択すると、Upgrade Assistantはドメイン内でアップグレードに利用可能なすべてのスキーマを自動的に選択します。

詳細は、Upgrade Assistantを使用したスキーマのアップグレードについてを参照してください。

9

必須。

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

既存のドメインで再構成ウィザードを実行すると、再構成テンプレートを選択および適用してドメインのアップグレードの準備をします。

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

10

必須。

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

既存のドメインを再構成したら、Upgrade Assistantを実行して既存のドメインで使用されているWebLogicコンポーネントの構成をすべてアップグレードする必要があります。

Upgrade Assistantを使用してアップグレードできる構成のリストは、Upgrade Assistantでアップグレードできる構成の識別を参照してください。

11

必須。

サーバーおよび12.2.1.1インスタンスを再起動します。

アップグレード・プロセスは完了です。これで、管理サーバー、管理対象サーバーおよびご使用の12.2.1.1インスタンスを再起動できます。サーバーの正しい順序での起動と停止を参照してください

12

必須。

アップグレード後タスクを完了します。

ご使用の環境に適用できるアップグレード後タスクを実行します。これらのアップグレード後タスクは、アップグレードが成功したかどうかを確認するために役立ちます。

アップグレード後タスクのリストは、アップグレード後に実行するタスクを参照してください。

13

条件付き
既存の環境がクラスタ構成の場合。

プライマリ・ノードの既存のドメインをパックします。

pack.sh|cmdスクリプトを実行して、プライマリ・ノードのdomaintemplate.jarファイルに既存のドメインをパックします。既存の環境がクラスタ構成の場合を参照してください

14

条件付き
既存の環境がクラスタ構成の場合。

domaintemplate.jarファイルをセカンダリ・ノードにコピーします。

domaintemplate.jarファイルをセカンダリ・ノードにコピーして、セカンダリ・ノードのファイルの内容をアンパックできるようにします。

15

条件付き
既存の環境がクラスタ構成の場合。

セカンダリ・ノードのdomaintemplate.jarファイルをアンパックします。

unpack.sh|cmdスクリプトを実行して、セカンダリ・ノードのdomaintemplate.jarファイルをアンパックします。

16

条件付き
既存の環境がクラスタ構成の場合。

サーバーおよび12.2.1.1インスタンスを再起動します。

セカンダリ・ノードのdomaintemplate.jarファイルをアンパックした後、管理サーバー、管理対象サーバーおよびご使用の12.2.1.1インスタンスを再起動します。

1.6 Oracle JDeveloper 12cを使用したカスタム・アプリケーションのアップグレード

カスタム・アプリケーションをOracle Fusion Middleware Application Developer 11gドメインにデプロイしていた場合、アップグレード手順の実行後、アプリケーションのデプロイメントはOracle Fusion Middleware 11gでの場合と同様に機能します。ただし、新しいOracle Application Development Framework (Oracle ADF) 12cの機能を利用する場合は、Oracle JDeveloper 12cをダウンロードしてインストールします。

詳細は、『Oracle JDeveloperのインストール』を参照してください。

Oracle Fusion Middleware Infrastructure 12へのアップグレードの準備のために11gアプリケーションをテストするには、既存のOracle JDeveloper 11gプロジェクトをOracle JDeveloper 12cで開きます。Oracle JDeveloperによってプロジェクトが12cに移行されます。その後、Oracle JDeveloper内から利用可能な埋込みアプリケーション・サーバーで、アプリケーションをテストできます。Oracle JDeveloper 12cでアプリケーションを確認して必要に応じて変更したら、Application Developer 11gドメインをOracle Fusion Middleware Infrastructure 12cにアップグレードして、アプリケーションを再デプロイします。

アプリケーションの移行の詳細は、Oracle JDeveloperのインストールの前のバージョンからのOracle JDeveloperの移行を参照してください。

2 Fusion Middleware Infrastructureのアップグレードの準備

アップグレードはサーバーが停止している間に実行されます。アップグレード前には時間がかかることがよくあります。これらのアップグレード前タスクを完了することによってご使用の環境をアップグレードに向けて計画および準備し、正常なアップグレードと限られた停止時間が実現されるようにすることをお薦めします。

次のチェックリストを使用して、アップグレード前タスクの完了を確認してください。

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

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

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

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

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

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

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

- Upgrade Assistantを実行する非SYSDBAユーザーの作成
FMWと呼ばれる非SYSDBAユーザーを作成してUpgrade Assistantを実行することをお薦めします。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.1)のデータベース・サーバーにエディションを作成する必要があります。

EBRデータベースを使用する場合に必要

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

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

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

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

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

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

新しい12c (12.2.1.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$表に行を持っています。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 Databaseを必須のスキーマで構成しておく必要があります。

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

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

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

新しい動作保証情報が発表された場合は、適切な動作保証ドキュメントにすぐに追加されます。新しい動作保証要件は随時確認される場合があるため、動作保証に関するドキュメントはドキュメント・ライブラリの外部に置かれ、Oracle Technology Networkで提供されています。詳細は、12c (12.2.1.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ビット環境を実行している場合にのみ必要です。32ビットOSを持っている場合は、アップグレード前に、32ビット環境を64ビット・ソフトウェア環境に移行する必要があります。

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

この手順は、32ビット環境を実行している場合にのみ必要です。32ビットOSを持っている場合は、アップグレード前に、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 Databaseを必須のスキーマで構成しておく必要があります。

アップグレード時のOracle Databaseの要件を理解し、Oracle Fusion Middlewareをホストするデータベースがサポートされており、アップグレードの実行に十分な領域が用意されていることを確認しているものとします。詳細は、12c (12.2.1.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にアクセスしてパッチをダウンロードします。

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

3 Fusion Middleware Infrastructureのアップグレード

この章では、Fusion Midleware Infrastructureを11gまたは前の12cリリースから最新の12c (12.2.1.1)リリースにアップグレードするプロセスについて説明します。

この章のトピックは、次のとおりです:

- Infrastructure用アップグレード前タスクの完了(必須)
Oracle Fusion Middleware 11g Application Developer installationからOracle Fusion Middleware 12c Infrastructureにアップグレードする前に、環境に関連するOracle Fusion Middlewareのアップグレード前タスクを完了することが重要です。アップグレード前タスクのほとんどは、Fusion Middlewareコンポーネントに必要ですが、Infrastructure固有のものもあります。

- Fusion Middleware Infrastructureのインストール
Fusion Middleware InfrastructureのインストールでOracleホーム・ディレクトリが作成され、その他のFusion Middleware製品をインストールするサポート・ソフトウェアが配置されます。

- サーバーとプロセスの停止
Upgrade Assistantを実行する前に、すべてのOracle Fusion Middleware管理対象サーバー、管理サーバーおよび更新するスキーマまたは構成を使用している可能性があるシステム・コンポーネント(OHSなど)を停止します。これを行わないと、結果としてアップグレードが不完全になったり、障害が発生する場合があります。

- 作成するスキーマの決定
ご使用の11gスキーマがファイルベースであったかデータベースベースであったかに応じて必要なスキーマを作成する必要があります。

- RCUを使用した必要なスキーマの作成
11gからアップグレードする場合、アップグレードを開始する前に必要な12cスキーマを作成する必要があります。

- スキーマ・バージョン・レジストリを使用した既存スキーマの識別
データベースにスキーマが作成されると、RCUは、schema_version_registryという表を作成して維持します。この表には、バージョン番号、コンポーネント名とID、作成日と変更日およびカスタム接頭辞などのスキーマ情報が含まれています。Upgrade Assistantを実行すると、アップグレードできるスキーマが識別されます。シングル・セッションのUpgrade Assistantの実行で、複数のスキーマをアップグレードできます。

- Upgrade Assistantを使用したスキーマのアップグレードについて
Upgrade Assistantには、スキーマをアップグレードするオプションが、「個別に選択されたスキーマ」と「ドメインで使用されるすべてのスキーマ」の2つ用意されています。

- Upgrade Assistantでアップグレードできるスキーマの識別
アップグレードを開始する前に、スキーマ・バージョン・レジストリを問い合せて使用可能なスキーマのリストをレビューします。

- Upgrade Assistantを使用したスキーマのアップグレード
Upgrade Assistantを実行して既存のドメイン内のすべてのスキーマを12.2.1.1にアップグレードします。Upgrade Assistantを非SYSDBAユーザーとして実行することをお薦めします。

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

- Upgrade Assistantを使用したドメイン・コンポーネントの構成のアップグレード
Upgrade Assistantを使用して追加のドメイン・コンポーネント構成(OWSMポリシー・メタデータ構造およびアダプタ構成など)をアップグレードするには、この項の手順に従います。

- Infrastructureアップグレードのトラブルシューティング
Infrastructureアップグレードに失敗した場合は、ログ・ファイルおよびこのトピックのガイドラインを使用して原因をトラブルシューティングします。

- アップグレード後タスクの実行
Oracle Fusion Middleware 11g Application DeveloperをOracle Fusion Middleware 12c Infrastructureにアップグレードした後、アップグレード後タスクを完了する必要があります。

3.1 Infrastructure用アップグレード前タスクの完了(必須)

Oracle Fusion Middleware 11g Application Developer installationからOracle Fusion Middleware 12c Infrastructureにアップグレードする前に、環境に関連するOracle Fusion Middlewareのアップグレード前タスクを完了することが重要です。アップグレード前タスクのほとんどは、Fusion Middlewareコンポーネントに必要ですが、Infrastructure固有のものもあります。

注意:

Infrastructureでの必要なアップグレード前タスクの完了に加えて、最初に、Oracle Fusion Middlewareのアップグレード前チェックリストで説明されているすべての該当するアップグレード前タスクを完了する必要があります。

既存の環境をバックアップする必要があります。なんらかの理由でアップグレードに失敗した場合、ソース・バックアップからアップグレード・プロセスをやりなおす必要があります。

詳細は、Oracle Fusion Middlewareのアップグレードのプランニングのアップグレードのバックアップ/リカバリ戦略を参照してください。

Infrastructure固有のアップグレード前タスクの詳細は、次を参照してください。

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

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

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

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

- 準備状況チェックの実行
アップグレード前環境でアップグレード準備が整っていることを確認するために、アップグレード・プロセスを開始する前に準備状況チェックを実行することをお薦めします。

3.1.1 カスタムsetDomainEnv設定のメンテナンス(オプション)

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

注意:

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

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

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

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

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

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

注意:

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

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

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

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

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

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

- -Dweblogic.security.SSL.AllowAnonymousCipher=true

- -Dweblogic.security.SSL.ignoreHostnameVerification=true

注意:

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

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

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

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

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

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

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

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

3.1.5 準備状況チェックの実行

アップグレード前環境でアップグレード準備が整っていることを確認するために、アップグレード・プロセスを開始する前に準備状況チェックを実行することをお薦めします。

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

- 準備状況チェックの画面
この項では、Upgrade Assistantを-readinessモードで実行するときに表示される画面について説明します。

3.1.5.1 Upgrade Assistantを使用したアップグレード前準備状況チェックの実行について

Upgrade Assistantを-readinessモードで実行することにより、実際にアップグレードを実行する前に問題を検出できます。これは、GUIを使用して実行することも、レスポンス・ファイルを使用してサイレント・アップグレードで実行することもできます。

Upgrade Assistantの準備状況チェックでは、既存のOracle Fusion MiddlewareスキーマおよびOracle WebLogic構成の読取り専用のアップグレード前確認を行います。

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

詳細は、「準備状況レポートのサンプル」を参照してください。

注意:
または、準備状況チェックを-responseモードで実行して、レスポンス・ファイルを使用してサイレント準備状況チェックを実行することもできます。Upgrade Assistantでのレスポンス・ファイルの使用の詳細は、「レスポンス・ファイル・モードでのUpgrade Assistantの起動」を参照してください。

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

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

注意:

パフォーマンスが低下する可能性を回避するために、準備状況チェックはオフピーク時に実行することをお薦めします。

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

- 準備状況チェックの実行

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

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

アップグレード前の環境で準備状況チェックを実行するには、次に示すように、Upgrade Assistantを-readinessモードで実行します。

1. ディレクトリを、UNIXオペレーティング・システムでは$ORACLE_HOME/oracle_common/upgrade/binに、Windowsオペレーティング・システムでは%ORACLE_HOME%/oracle_common/upgrade/binに変更します。

2. 次のコマンドを入力してアップグレード・アシスタントを起動します。
UNIXオペレーティング・システムの場合:

./ua -readiness

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

ua.bat -readiness

Upgrade Assistantの各画面で必要な情報を指定します。表示される画面は、選択するアップグレード・オプションによって異なります。次の項では、アップグレード・オプションおよび入力する必要がある情報を説明しています。

3.1.5.1.2 準備状況チェックの実行

Upgrade Assistantを-readinessモードで起動すると、次の画面が表示されます。

または、レスポンス・ファイルを使用して準備状況チェックを実行することもできます。Upgrade Assistantでのレスポンス・ファイルの使用の詳細は、「レスポンス・ファイル・モードでのUpgrade Assistantの起動」を参照してください。

次の画面は、表示される画面のサブセットです。

表3-1 Upgrade Assistant画面: 準備状況チェック

画面

画面が表示されるタイミング

説明

ようこそ

常時。

この画面には、準備状況チェックの概要が示されます。

準備状況チェックのタイプ:

- 個別に選択されたスキーマ

- ドメイン・ベース

常時。

準備状況チェックは、サポートされるアップグレードの開始点にあるスキーマまたはコンポーネント構成に対してのみ実行されます。次の2つのオプションがあります。次にこれらのオプションについて説明します。

- 準備状況チェック・タイプ: 個別に選択されたスキーマ
「個別に選択されたスキーマ」オプションを使用すると、アップグレードする前に確認するスキーマを選択できます。

- 準備状況チェック・タイプ: ドメイン・ベース
「ドメイン・ベース」オプションを使用して、ドメインごとに準備状況チェックが実行されるようにします。

使用可能なコンポーネント

「個別に選択されたスキーマ」が選択されている場合。

この画面には、スキーマが選択される使用可能なコンポーネントがリストされます。ここで何かを選択すると、そのコンポーネントのスキーマに対して準備状況チェックが実行されます。

スキーマ資格証明

常時。

この画面を使用して、選択したスキーマとそのスキーマをホストするデータベースへの接続に必要な情報を入力します。アップグレードするスキーマが以前のFusion MiddlewareのリリースでRCUによって作成された場合は、使用可能なスキーマ名がリストされたドロップダウン・メニューが表示されます。

準備状況サマリー

常時。

この画面には、選択に基づいて実行される準備状況チェックの概要が示されます。

Upgrade Assistantを—response (またはサイレント)モードで再実行する場合は、「レスポンス・ファイルの保存」をクリックします。

「準備状況チェック」

常時。

この画面には、準備状況チェックの現在のステータスが表示されます。チェック対象として選択した内容によっては、このプロセスには数分かかる場合があります。

詳細レポートを表示するには、準備状況レポートのレビューをクリックします。このボタンは、準備状況チェックがすべて完了した後のみ表示されます。

注意:
パフォーマンスの低下を回避するには、準備状況チェックをオフピーク時に実行することを検討してください。

準備状況成功

準備状況チェックが正常に完了した場合。

これで、完全なレポートをレビューできるようになります。

準備状況チェックで問題またはエラーが発生した場合、ログ・ファイルをレビューして問題を特定し、問題を修正してから、準備状況チェックを再開してください。

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

ドメインの準備状況チェックが完了したら、レポートをレビューし、正常なアップグレードが完了する前に実行が必要なアクション(存在する場合)を確認します。

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

レポートの情報

説明

必要な操作

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

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

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

タイムスタンプ

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

処理は必要ありません。

ログ・ファイルの場所

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

処理は必要ありません。

準備状況レポートの場所

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

処理は必要ありません。

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

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

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

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

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

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

ステータス: FAIL

個別準備状況チェック・テストによって問題が検出されました。

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

ステータス: PASS

準備状況チェック・テストによって問題が検出されませんでした。

準備状況チェック・レポートにPASSステータスのみが表示されている場合、環境をアップグレードできます。ただし、準備状況チェックでは、ハードウェアやアップグレード時の接続性などの外部環境に関する問題を検出することはできません。アップグレードの進捗を常に監視する必要があります。

準備状況レポート・ファイルのサンプルを次に示します。使用対象のレポートにはこれらすべてのチェックが含まれる場合や含まれない場合があります。

Upgrade readiness check completed with one or more errors.

This readiness check report was created on Tue May 30 11:15:52 EDT 2016
Log file is located at: /scratch/yourname/oracle/work/middleware_latest/oracle_common/upgrade/logs/ua2016-05-30-11-14-06AM.log
Readiness Check Report File: /scratch/yourname/oracle/work/middleware_latest/oracle_common/upgrade/logs/readiness2016-05-30-11-15-52AM.txt

Starting readiness check of components.

Oracle Metadata Services
Starting readiness check of Oracle Metadata Services.
Schema User Name: DEV11_MDS
Database Type: Oracle Database
Database Connect String: machinename@yourcompany.com
VERSION Schema DEV11_MDS is currently at version 12.1.1.1.0.  Readiness checks will now be performed.
Starting schema test:  TEST_REQUIRED_TABLES  Test that the schema contains all the required tables
Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS
Starting schema test:  TEST_REQUIRED_PROCEDURES  Test that the schema contains all the required stored procedures
EXCEPTION     Schema is missing a required procedure: GETREPOSITORYFEATURES
Completed schema test: TEST_REQUIRED_PROCEDURES --> Test that the schema contains all the required stored procedures +++ FAIL
Starting schema test:  TEST_REQUIRED_VIEWS  Test that the schema contains all the required database views
Completed schema test: TEST_REQUIRED_VIEWS --> Test that the schema contains all the required database views +++ PASS
Starting index test for table MDS_ATTRIBUTES:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_ATTRIBUTES: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting index test for table MDS_COMPONENTS:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_COMPONENTS: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting index test for table MDS_DEPENDENCIES:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_DEPENDENCIES: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting index test for table MDS_DEPL_LINEAGES:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_DEPL_LINEAGES: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting index test for table MDS_LABELS:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_LABELS: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting index test for table MDS_LARGE_ATTRIBUTES:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_LARGE_ATTRIBUTES: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting index test for table MDS_METADATA_DOCS:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_METADATA_DOCS: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting index test for table MDS_NAMESPACES:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_NAMESPACES: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting index test for table MDS_PARTITIONS:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_PARTITIONS: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting index test for table MDS_PATHS:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_PATHS: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting index test for table MDS_PURGE_PATHS:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_PURGE_PATHS: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting index test for table MDS_SANDBOXES:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_SANDBOXES: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting index test for table MDS_STREAMED_DOCS:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_STREAMED_DOCS: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting index test for table MDS_TRANSACTIONS:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_TRANSACTIONS: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting index test for table MDS_TXN_LOCKS:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_TXN_LOCKS: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting schema test:  TEST_REQUIRED_TRIGGERS  Test that the schema has all the required triggers
Completed schema test: TEST_REQUIRED_TRIGGERS --> Test that the schema has all the required triggers +++ PASS
Starting schema test:  TEST_MISSING_COLUMNS  Test that tables and views are not missing any required columns
Completed schema test: TEST_MISSING_COLUMNS --> Test that tables and views are not missing any required columns +++ PASS
Starting schema test:  TEST_UNEXPECTED_TABLES  Test that the schema does not contain any unexpected tables
Completed schema test: TEST_UNEXPECTED_TABLES --> Test that the schema does not contain any unexpected tables +++ PASS
Starting schema test:  TEST_UNEXPECTED_PROCEDURES  Test that the schema does not contain any unexpected stored procedures
Completed schema test: TEST_UNEXPECTED_PROCEDURES --> Test that the schema does not contain any unexpected stored procedures +++ PASS
Starting schema test:  TEST_UNEXPECTED_VIEWS  Test that the schema does not contain any unexpected views
Completed schema test: TEST_UNEXPECTED_VIEWS --> Test that the schema does not contain any unexpected views +++ PASS
Starting index test for table MDS_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Completed index test for table MDS_ATTRIBUTES: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Starting index test for table MDS_COMPONENTS:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Completed index test for table MDS_COMPONENTS: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Starting index test for table MDS_DEPENDENCIES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Completed index test for table MDS_DEPENDENCIES: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Starting index test for table MDS_DEPL_LINEAGES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Completed index test for table MDS_DEPL_LINEAGES: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Starting index test for table MDS_LABELS:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Completed index test for table MDS_LABELS: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Starting index test for table MDS_LARGE_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Completed index test for table MDS_LARGE_ATTRIBUTES: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Starting index test for table MDS_METADATA_DOCS:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Completed index test for table MDS_METADATA_DOCS: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Starting index test for table MDS_NAMESPACES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Completed index test for table MDS_NAMESPACES: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Starting index test for table MDS_PARTITIONS:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Completed index test for table MDS_PARTITIONS: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Starting index test for table MDS_PATHS:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Completed index test for table MDS_PATHS: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Starting index test for table MDS_PURGE_PATHS:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Completed index test for table MDS_PURGE_PATHS: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Starting index test for table MDS_SANDBOXES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Completed index test for table MDS_SANDBOXES: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Starting index test for table MDS_STREAMED_DOCS:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Completed index test for table MDS_STREAMED_DOCS: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Starting index test for table MDS_TRANSACTIONS:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Completed index test for table MDS_TRANSACTIONS: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Starting index test for table MDS_TXN_LOCKS:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Completed index test for table MDS_TXN_LOCKS: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Starting schema test:  TEST_UNEXPECTED_TRIGGERS  Test that the schema does not contain any unexpected triggers
Completed schema test: TEST_UNEXPECTED_TRIGGERS --> Test that the schema does not contain any unexpected triggers +++ PASS
Starting schema test:  TEST_UNEXPECTED_COLUMNS  Test that tables and views do not contain any unexpected columns
Completed schema test: TEST_UNEXPECTED_COLUMNS --> Test that tables and views do not contain any unexpected columns +++ PASS
Starting datatype test for table MDS_ATTRIBUTES:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table MDS_ATTRIBUTES: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table MDS_COMPONENTS:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table MDS_COMPONENTS: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table MDS_DEPENDENCIES:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table MDS_DEPENDENCIES: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table MDS_DEPL_LINEAGES:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table MDS_DEPL_LINEAGES: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table MDS_LABELS:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table MDS_LABELS: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table MDS_LARGE_ATTRIBUTES:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table MDS_LARGE_ATTRIBUTES: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table MDS_METADATA_DOCS:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table MDS_METADATA_DOCS: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table MDS_NAMESPACES:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table MDS_NAMESPACES: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table MDS_PARTITIONS:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table MDS_PARTITIONS: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table MDS_PATHS:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table MDS_PATHS: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table MDS_PURGE_PATHS:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table MDS_PURGE_PATHS: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table MDS_SANDBOXES:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table MDS_SANDBOXES: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table MDS_STREAMED_DOCS:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table MDS_STREAMED_DOCS: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table MDS_TRANSACTIONS:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table MDS_TRANSACTIONS: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table MDS_TXN_LOCKS:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table MDS_TXN_LOCKS: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting permissions test for table MDS_ATTRIBUTES:  TEST_TABLE_GRANTS --> Test that tables have the proper GRANT permissions
Completed permissions test for table MDS_ATTRIBUTES: TEST_TABLE_GRANTS --> Test that tables have the proper GRANT permissions +++ PASS
Starting permissions test for table MDS_COMPONENTS:  TEST_TABLE_GRANTS --> Test that tables have the proper GRANT permissions
Completed permissions test for table MDS_COMPONENTS: TEST_TABLE_GRANTS --> Test that tables have the proper GRANT permissions +++ PASS
Starting permissions test for table MDS_DEPENDENCIES:  TEST_TABLE_GRANTS --> Test that tables have the proper GRANT permissions
Completed permissions test for table MDS_DEPENDENCIES: TEST_TABLE_GRANTS --> Test that tables have the proper GRANT permissions +++ PASS
Starting permissions test for table MDS_DEPL_LINEAGES:  TEST_TABLE_GRANTS --> Test that tables have the proper GRANT permissions
Completed permissions test for table MDS_DEPL_LINEAGES: TEST_TABLE_GRANTS --> Test that tables have the proper GRANT permissions +++ PASS
Starting permissions test for table MDS_LABELS:  TEST_TABLE_GRANTS --> Test that tables have the proper GRANT permissions
Completed permissions test for table MDS_LABELS: TEST_TABLE_GRANTS --> Test that tables have the proper GRANT permissions +++ PASS
Starting permissions test for table MDS_LARGE_ATTRIBUTES:  TEST_TABLE_GRANTS --> Test that tables have the proper GRANT permissions
Completed permissions test for table MDS_LARGE_ATTRIBUTES: TEST_TABLE_GRANTS --> Test that tables have the proper GRANT permissions +++ PASS
Starting permissions test for table MDS_METADATA_DOCS:  TEST_TABLE_GRANTS --> Test that tables have the proper GRANT permissions
Completed permissions test for table MDS_METADATA_DOCS: TEST_TABLE_GRANTS --> Test that tables have the proper GRANT permissions +++ PASS
Starting permissions test for table MDS_NAMESPACES:  TEST_TABLE_GRANTS --> Test that tables have the proper GRANT permissions
Completed permissions test for table MDS_NAMESPACES: TEST_TABLE_GRANTS --> Test that tables have the proper GRANT permissions +++ PASS
Starting permissions test for table MDS_PARTITIONS:  TEST_TABLE_GRANTS --> Test that tables have the proper GRANT permissions
Completed permissions test for table MDS_PARTITIONS: TEST_TABLE_GRANTS --> Test that tables have the proper GRANT permissions +++ PASS
Starting permissions test for table MDS_PATHS:  TEST_TABLE_GRANTS --> Test that tables have the proper GRANT permissions
Completed permissions test for table MDS_PATHS: TEST_TABLE_GRANTS --> Test that tables have the proper GRANT permissions +++ PASS
Starting permissions test for table MDS_PURGE_PATHS:  TEST_TABLE_GRANTS --> Test that tables have the proper GRANT permissions
Completed permissions test for table MDS_PURGE_PATHS: TEST_TABLE_GRANTS --> Test that tables have the proper GRANT permissions +++ PASS
Starting permissions test for table MDS_SANDBOXES:  TEST_TABLE_GRANTS --> Test that tables have the proper GRANT permissions
Completed permissions test for table MDS_SANDBOXES: TEST_TABLE_GRANTS --> Test that tables have the proper GRANT permissions +++ PASS
Starting permissions test for table MDS_STREAMED_DOCS:  TEST_TABLE_GRANTS --> Test that tables have the proper GRANT permissions
Completed permissions test for table MDS_STREAMED_DOCS: TEST_TABLE_GRANTS --> Test that tables have the proper GRANT permissions +++ PASS
Starting permissions test for table MDS_TRANSACTIONS:  TEST_TABLE_GRANTS --> Test that tables have the proper GRANT permissions
Completed permissions test for table MDS_TRANSACTIONS: TEST_TABLE_GRANTS --> Test that tables have the proper GRANT permissions +++ PASS
Starting permissions test for table MDS_TXN_LOCKS:  TEST_TABLE_GRANTS --> Test that tables have the proper GRANT permissions
Completed permissions test for table MDS_TXN_LOCKS: TEST_TABLE_GRANTS --> Test that tables have the proper GRANT permissions +++ PASS
Starting permissions test:  TEST_DBA_TABLE_GRANTS  Test that DBA user has privilege to view all user tables
Completed permissions test: TEST_DBA_TABLE_GRANTS --> Test that DBA user has privilege to view all user tables +++ PASS
Starting schema test:  TEST_ENOUGH_TABLESPACE  Test that the schema tablespaces automatically extend if full
Completed schema test: TEST_ENOUGH_TABLESPACE --> Test that the schema tablespaces automatically extend if full +++ PASS
Starting schema test:  TEST_USER_TABLESPACE_QUOTA  Test that tablespace quota for this user is sufficient to perform the upgrade
Completed schema test: TEST_USER_TABLESPACE_QUOTA --> Test that tablespace quota for this user is sufficient to perform the upgrade +++ PASS
Starting schema test:  TEST_ONLINE_TABLESPACE  Test that schema tablespaces are online
Completed schema test: TEST_ONLINE_TABLESPACE --> Test that schema tablespaces are online +++ PASS
Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
INFO   Database product version: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
Finished readiness check of Oracle Metadata Services with status: FAILURE.

Common Infrastructure Services
Starting readiness check of Common Infrastructure Services.
Schema User Name: DEV1212_STB
Database Type: Oracle Database
Database Connect String: machinename@yourcompany.com
VERSION Schema STB is currently at version 12.1.2.0.0.  Readiness checks will now be performed.
Starting schema test:  TEST_REQUIRED_TABLES  Test that the schema contains all the required tables
Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS
Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS
Starting schema test:  TEST_UNEXPECTED_TABLES  Test that the schema does not contain any unexpected tables
Completed schema test: TEST_UNEXPECTED_TABLES --> Test that the schema does not contain any unexpected tables +++ PASS
Starting schema test:  TEST_REQUIRED_VIEWS  Test that the schema contains all the required database views
Completed schema test: TEST_REQUIRED_VIEWS --> Test that the schema contains all the required database views +++ PASS
Starting schema test:  TEST_MISSING_COLUMNS  Test that tables and views are not missing any required columns
Completed schema test: TEST_MISSING_COLUMNS --> Test that tables and views are not missing any required columns +++ PASS
Starting schema test:  TEST_UNEXPECTED_COLUMNS  Test that tables and views do not contain any unexpected columns
Completed schema test: TEST_UNEXPECTED_COLUMNS --> Test that tables and views do not contain any unexpected columns +++ PASS
Starting schema test:  TEST_UNEXPECTED_PROCEDURES  Test that the schema does not contain any unexpected stored procedures
Completed schema test: TEST_UNEXPECTED_PROCEDURES --> Test that the schema does not contain any unexpected stored procedures +++ PASS
Starting permissions test:  TEST_DBA_TABLE_GRANTS  Test that DBA user has privilege to view all user tables
Starting permissions test:  TEST_DBA_TABLE_GRANTS  Test that DBA user has privilege to view all user tables
Completed permissions test: TEST_DBA_TABLE_GRANTS --> Test that DBA user has privilege to view all user tables +++ PASS
Completed permissions test: TEST_DBA_TABLE_GRANTS --> Test that DBA user has privilege to view all user tables +++ PASS
Starting permissions test for table COMPONENT_SCHEMA_INFO:  TEST_TABLE_GRANTS --> Test that tables have the proper GRANT permissions
Completed permissions test for table TEST_TABLE_GRANTS: Test that tables have the proper GRANT permissions --> PASS +++ {3}
Starting permissions test for table SERVICETABLE:  TEST_TABLE_GRANTS --> Test that tables have the proper GRANT permissions
Completed permissions test for table TEST_TABLE_GRANTS: Test that tables have the proper GRANT permissions --> PASS +++ {3}
Starting datatype test for table COMPONENT_SCHEMA_INFO:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table COMPONENT_SCHEMA_INFO: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table SERVICETABLE:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table SERVICETABLE: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting index test for table COMPONENT_SCHEMA_INFO:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table COMPONENT_SCHEMA_INFO: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting index test for table COMPONENT_SCHEMA_INFO:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Completed index test for table COMPONENT_SCHEMA_INFO: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Starting index test for table SERVICETABLE:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table SERVICETABLE: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting index test for table SERVICETABLE:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Completed index test for table SERVICETABLE: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Starting schema test:  TEST_UNEXPECTED_TRIGGERS  Test that the schema does not contain any unexpected triggers
Completed schema test: TEST_UNEXPECTED_TRIGGERS --> Test that the schema does not contain any unexpected triggers +++ PASS
Starting schema test:  TEST_ENOUGH_TABLESPACE  Test that the schema tablespaces automatically extend if full
Starting schema test:  TEST_ENOUGH_TABLESPACE  Test that the schema tablespaces automatically extend if full
Completed schema test: TEST_ENOUGH_TABLESPACE --> Test that the schema tablespaces automatically extend if full +++ PASS
Completed schema test: TEST_ENOUGH_TABLESPACE --> Test that the schema tablespaces automatically extend if full +++ PASS
Starting schema test:  TEST_ONLINE_TABLESPACE  Test that schema tablespaces are online
Starting schema test:  TEST_ONLINE_TABLESPACE  Test that schema tablespaces are online
Completed schema test: TEST_ONLINE_TABLESPACE --> Test that schema tablespaces are online +++ PASS
Completed schema test: TEST_ONLINE_TABLESPACE --> Test that schema tablespaces are online +++ PASS
Starting schema test:  TEST_USER_TABLESPACE_QUOTA  Test that tablespace quota for this user is sufficient to perform the upgrade
Starting schema test:  TEST_USER_TABLESPACE_QUOTA  Test that tablespace quota for this user is sufficient to perform the upgrade
Completed schema test: TEST_USER_TABLESPACE_QUOTA --> Test that tablespace quota for this user is sufficient to perform the upgrade +++ PASS
Completed schema test: TEST_USER_TABLESPACE_QUOTA --> Test that tablespace quota for this user is sufficient to perform the upgrade +++ PASS
Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
INFO   Database product version: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
Finished readiness check of Common Infrastructure Services with status: SUCCESS.

Finished readiness check of components.

3.1.5.2 準備状況チェック画面

この項では、Upgrade Assistantを-readinessモードで実行するときに表示される画面について説明します。

実際にアップグレードを実行する前にUpgrade Assistantを-readinessモードで実行することにより、アップグレード前の環境における潜在的な問題を検出できます。

- 「ようこそ」

- 準備状況チェック・タイプ: 個別に選択されたスキーマ

- 「準備状況チェック・タイプ: ドメイン・ベース」
「ドメイン・ベース」オプションを使用して、ドメインで使用されるアップグレード可能なスキーマまたはコンポーネント構成(あるいはその両方)をすべてチェックします。スキーマはすべてUpgrade Assistantによって検出されます。スキーマ構成とコンポーネント構成は同時にチェックできます。または、どちらかを選択することもできます。どちらの場合も、レビューするドメイン・ディレクトリを指定する必要があります。

- 「使用可能なコンポーネント」
この画面は、「スキーマ」画面で「個別に選択されたスキーマ」を選択をすると、表示されます。

- スキーマ資格証明

- 準備状況サマリー

- 準備状況チェック

- ログ・ビューア

- 準備状況成功

- 準備状況レポートのサンプル

3.1.5.2.1 ようこそ

図3-1 準備状況へのようこそ

アップグレード・アシスタントの準備状況チェックでは、既存のOracle Fusion MiddlewareスキーマおよびOracle WebLogicコンポーネント構成の読取り専用のアップグレード前確認を行います。

準備状況チェックでは、フォーマットされ、タイムスタンプの付けられた準備状況レポートが作成され、実際のアップグレードを試みる前に問題に対処できます。問題が検出されない場合は、アップグレード・プロセスを開始できます。

Upgrade Assistantの準備状況チェックは、既存の11gまたは12cドメインでオンラインまたはオフラインで実行できます。

注意:
準備状況チェックは12.2.1に同梱されていますが、サポートされているアップグレード前の環境のみがチェックされます。

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

アップグレードを実行する前に、このレポートを詳細に確認することをお薦めします。

3.1.5.2.2 準備状況チェック・タイプ: 個別に選択されたスキーマ

図3-2 個別に選択されたスキーマ

準備状況チェックを実行する場合、2つのオプションが用意されています。

- 個別に選択されたスキーマ

- ドメイン・ベース

チェックの対象を特定のスキーマに制限するには、「個別に選択されたスキーマ」オプションを選択します。「次へ」をクリックすると、スキーマの資格証明を指定する必要があります。

準備状況チェックは、接続先のスキーマに対して実行されます。準備状況チェック・レポートにより、スキーマがアップグレードに対してサポートされているか、またはアップグレードが必要かどうかを確認できます。

3.1.5.2.3 準備状況チェック・タイプ: ドメイン・ベース

「ドメイン・ベース」オプションを使用して、ドメインで使用されるアップグレード可能なスキーマまたはコンポーネント構成(あるいはその両方)をすべてチェックします。スキーマはすべてUpgrade Assistantによって検出されます。スキーマ構成とコンポーネント構成は同時にチェックできます。または、どちらかを選択することもできます。どちらの場合も、レビューするドメイン・ディレクトリを指定する必要があります。

WebLogic Serverドメインをチェックする場合、複数のオプションが用意されています。

ドメイン・ベースの準備状況チェックを実行する場合、1つ以上のオプションを次から選択できます。

- すべてのスキーマのチェックを含める
アップグレード可能なスキーマを持つすべてのコンポーネントをUpgrade Assistantが検出およびレビューできるようにするには、このオプションを選択します。

- すべての構成のチェックを含める
管理対象WebLogic Serverドメインのコンポーネント構成をレビューするには、このオプションを選択します。

ドメイン構成チェックはドメインがオンラインでもオフラインでも実行できます。

- オンラインおよびオフラインの準備状況チェックの実行。
追加のオンライン準備状況チェックを実行するには、このオプションを選択します。このオプションを使用するには、ドメインがオンラインである必要があります。チェックするドメインのホスト名、ポート、ユーザー名およびパスワードを指定する必要があります。
このオプションを選択しない場合、ドメインはオフラインにすることができます。チェックするドメインの場所を指定する必要があります。

図3-3 WebLogic Serverの準備状況チェック・オプション

3.1.5.2.4 使用可能なコンポーネント

この画面は、「スキーマ」画面で「個別に選択されたスキーマ」を選択すると、表示されます。

図3-4 使用可能なコンポーネント

「個別に選択されたスキーマ」を選択した場合、この画面には、スキーマが選択される使用可能なコンポーネントがリストされます。ここで何かを選択すると、そのコンポーネントのスキーマに対して準備状況チェックが実行されます。準備状況チェックを実行するには、対象となるコンポーネントを1つ以上選択する必要があります。

3.1.5.2.5 スキーマ資格証明

この画面を使用して、選択したスキーマとそのスキーマをホストするデータベースへの接続に必要な情報を入力します。レビュー対象のスキーマが前のFusion MiddlewareリリースのRCUによって作成された場合、次に示されているように、使用可能なスキーマ名がリストされているドロップダウン・メニューが表示されます。

「接続」をクリックしてデータベースに接続してから、レビューするスキーマを選択します。注意: ほとんどのスキーマでは、この情報は事前に移入されます。ただし、Upgrade Assistantが接続の詳細を検出できない場合は、次に示すように、これらを手動で入力する必要があります。

複数のコンポーネントを選択すると、スキーマ資格証明画面が依存性の順に表示されます。

図3-5 スキーマ資格証明

3.1.5.2.6 準備状況サマリー

この画面には、選択に基づいて実行される準備状況チェックの概要が示されます。

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

図3-6 準備状況サマリー

3.1.5.2.7 準備状況チェック

この画面には、実行中の準備状況チェックの全体的な進捗および完了の詳細が表示されます。複数のコンポーネントをチェックしている場合、コンポーネントごとに独自の進捗バーが表示され、これらが並行してチェックされます。完了したら、準備状況レポートのレビューをクリックし、完全なテキスト・レポートを表示します。

注意: 準備状況チェックをオンライン本番環境で実行している場合、パフォーマンスの低下を回避するためにオフピーク時にチェックを実行することをお薦めします。

図3-7 準備状況チェックの完了

3.1.5.2.8 ログ・ビューア

任意の画面で「ログの表示」をクリックすると、最新のログ情報を表示できます。

ログ・ファイルは、設定したコマンドライン・オプションによって管理されます。詳細は、「追加のパラメータ(オプション)を使用したUpgrade Assistantの起動」を参照してください。

図3-8 ログ・ファイルのサンプル

3.1.5.2.9 準備状況成功

「準備状況成功」は、準備状況の確認が正常に完了したことを示します。

レビューが正常に完了した場合でも、準備状況レポートのレビューをクリックし、実際にアップグレードする前に準備状況レポートをレビューする必要があります。

図3-9 準備状況の終了: 準備状況成功

3.1.5.2.10 準備状況レポートのサンプル

チェックを実行した後、フォーマットされた準備状況レポートが作成されます。実際にアップグレードを開始する前にレポートをレビューし、問題を修正するようにしてください。「検索」オプションを使用して、レポート内の特定の単語(スキーマ名やコマンドなど)を検索します。

また、このレポートには、完成した準備状況チェック・レポート・ファイルが格納されている場所も示されます。

図3-10 準備状況レポート・ビューア

3.2 Fusion Middleware Infrastructureのインストール

Fusion Middleware InfrastructureのインストールでOracleホーム・ディレクトリが作成され、その他のFusion Middleware製品をインストールするサポート・ソフトウェアが配置されます。

Fusion Middleware Infrastructureディストリビューションをインストールする手順は、次のとおりです。

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

2. Oracle Fusion Middleware Infrastructureディストリビューション(fmw_12.2.1.1.0_infrastructure_generic.jar)をOracle Technology NetworkまたはOracle Software Delivery Cloudからターゲット・システムにダウンロードします。

3. 12.2.1.1製品ディストリビューションをダウンロードしたディレクトリに変更します。

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

$JDK_HOME/bin/java [-d64] -jar fmw_12.2.1.1.0_infrastructure_generic.jar

注意:
HP-UX Itaniumを使用している場合のみ"-d64"フラグを使用します。

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

%JDK_HOME%\bin\java -jar fmw_12.2.1.1.0_infrastructure_generic.jar

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

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

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

7. 「自動更新」画面で「自動更新をスキップ」を選択して「次」をクリックします。

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

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

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

8. 「インストールの場所」画面で、Oracleホーム・ディレクトリの場所を指定して「次」をクリックします。
Oracle Fusion Middlewareディレクトリ構造の詳細は、Oracle Fusion Middlewareのインストールのプランニングのインストールおよび構成のためのディレクトリの選択を参照してください

9. 「インストール・タイプ」画面で、Fusion Middleware Infrastructureを選択して「次」をクリックします。

注意:
このドキュメントのトポロジにサーバーの例は含まれません。製品環境にはサンプルをインストールしないように強くお薦めします。

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

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

11. 「セキュリティ更新」画面でMy Oracle Supportアカウント情報を入力すると、最新の製品情報およびセキュリティ・アップデートをMy Oracle Supportアカウントを介して受け取ることができます。
この画面は、ホスト上にOracle製品を初めてインストールすると表示されます。

Oracle Supportアカウントを所有していない場合、この手順をスキップするには、チェック・ボックスの選択を解除し、フォローアップのダイアログ・ボックスで選択を確認します。

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

13. 「インストールの進行状況」画面で、進捗バーに100%が表示されたら「次」をクリックします。

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

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

Upgrade Assistantを実行する前に、すべてのOracle Fusion Middleware管理対象サーバー、管理サーバーおよび更新するスキーマまたは構成を使用している可能性があるシステム・コンポーネント(OHSなど)を停止します。これを行わないと、結果としてアップグレードが不完全になったり、障害が発生する場合があります。

ノード・マネージャを実行している場合は、ノード・マネージャも停止する必要があります。これを行うには、ノード・マネージャが実行されているコンソール・ウィンドウを閉じるか、stopNodeManager WLSTコマンドを使用します。

Oracle Fusion Middleware環境を停止する手順は、Oracle Fusion Middlewareの管理のOracle Fusion Middleware環境の停止を参照してください。

3.4 作成するスキーマの決定

ご使用の11gスキーマがファイルベースであったかデータベースベースであったかに応じて必要なスキーマを作成する必要があります。

次のシナリオを参考にしてください。

- 11gでデータベースを使用していなかった場合、サポートされているデータベースをインストールして構成し、Infrastructure 12cのデータベース・スキーマ要件の説明に従って、1つ以上のデータベース・スキーマを作成する必要もあります。

- Application Developer 11gドメインのスキーマをホストするためにデータベースをすでに使用していた場合は、スキーマ・バージョン・レジストリを使用した既存のスキーマの識別の説明に従って、スキーマ・バージョン・レジストリを使用して、データベースですでに利用可能なOracle Fusion Middleware 11gスキーマのリストを表示します。
「スキーマ・バージョン・レジストリ」にリスト表示されたスキーマを手動で作成する必要はありません。かわりに、後からUpgrade Assistantを使用してアップグレード・プロセス中に11gスキーマをアップグレードできます。

ただし、その場合もInfrastructure 12cのデータベース・スキーマ要件の説明に従って、必要なスキーマを作成する必要があります。

注意:

リリース12cより、サービス表(_STB)スキーマは、すべてのInfrastructureインストールに必要です。サービス表は、インフラストラクチャをアップグレードするたびに、アップグレードする必要があります。新しいInfrastructureのインストールで、古いバージョンのスキーマは使用できません。

以前の12cリリースからアップグレードする場合は、12cスキーマを作成する必要はなく、Upgrade Assistantを使用して直接アップグレードできます。

3.5 RCUを使用した必要なスキーマの作成

11gからアップグレードする場合、アップグレードを開始する前に必要な12cスキーマを作成する必要があります。

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

11gリリースからアップグレードする場合は、12cスキーマの作成中に同じ接頭辞を指定する必要があります。

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

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

$ORACLE_HOME/oracle_common/bin

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

%ORACLE_HOME%\oracle_common\bin

2. 次のコマンドを入力して、RCUを実行します。
UNIXオペレーティング・システムの場合:

./rcu

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

rcu.bat

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

4. 「リポジトリの作成」画面で、「リポジトリの作成」を選択してから「システム・ロードおよび製品ロード」を選択します。「次」をクリックします。
DBA権限がない場合、「システム・ロードに対するスクリプトの準備」を選択します。

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

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

オプション

説明と例

ホスト名

データベースが稼働しているサーバーの名前を次の書式で指定します。

examplehost.exampledomain.com

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

ポート

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

サービス名

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

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

examplehost.exampledomain.com

ユーザー名

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

パスワード

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

ロール

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

通常またはSYSDBA

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

オプション

説明と例

ホスト名

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

ポート

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

データベース名

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

ユーザー名

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

パスワード

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

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

オプション

説明と例

Unicodeサポート

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

サーバー名

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

ポート

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

データベース名

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

ユーザー名

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

パスワード

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

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

オプション

説明と例

サーバー名

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

ポート

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

データベース名

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

ユーザー名

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

パスワード

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

前提条件のチェックが正常に実行されたら、「OK」をクリックして次のページに進みます。チェックに失敗した場合、入力した詳細をレビューして再試行します。

6. 「コンポーネントの選択」画面で、「新規接頭辞の作成」を選択し、11gスキーマと同じ接頭辞を入力します。
「AS共通スキーマ」を選択します。このセクションのすべてのスキーマが自動的に選択されます。「次」をクリックします。

コンポーネントの前提条件の進行状況を示す「前提条件チェック」ボックスが表示されます。操作完了後に「OK」をクリックします。

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

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

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

RCUの起動時にTransparent Data Encryption (TDE)がデータベース(OracleまたはOracle EBR)内で有効化されている場合にのみ、「表領域の暗号化」チェック・ボックスが表示されます。RCUにより作成されるすべての新しい表領域を暗号化するために、「表領域のマップ」画面で「表領域の暗号化」チェック・ボックスを選択します。

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

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

作成するスキーマ

作成するスキーマの決定

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

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

カスタム接頭辞

カスタム接頭辞の理解

スキーマ作成の計画

スキーマ作成の計画

3.6 スキーマ・バージョン・レジストリを使用した既存のスキーマの識別

データベースにスキーマが作成されると、RCUは、schema_version_registryという表を作成して維持します。この表には、バージョン番号、コンポーネント名とID、作成日と変更日およびカスタム接頭辞などのスキーマ情報が含まれています。Upgrade Assistantを実行すると、アップグレードできるスキーマが識別されます。シングル・セッションのUpgrade Assistantの実行で、複数のスキーマをアップグレードできます。

どの11gまたは12cスキーマが12.2.1.1にアップグレードできるかを判断するには、Upgrade AssistantによるアップグレードのUpgrade Assistantを使用してアップグレードできるスキーマの識別を参照してください。

または、次のコマンドを使用してschema_version_registry表を問い合せて既存のスキーマを識別します。

select * from schema_version_registry;

3.7 Upgrade Assistantを使用したスキーマのアップグレードについて

Upgrade Assistantには、スキーマをアップグレードするオプションが、「個別に選択されたスキーマ」と「ドメインで使用されるすべてのスキーマ」の2つ用意されています。

個別に選択されたスキーマ

このオプションを使用すると、アップグレードするコンポーネント・スキーマを選択できます。アップグレード用のスキーマを個別に選択する場合で、ドメインで使用されるすべてのスキーマをアップグレードしない場合は、このオプションを選択します。

たとえば、ドメインの外部にあるRCUを使用してスキーマを作成してUpgrade Assistantを試行してから、Upgrade Assistantを使用してこれらをアップグレードします。

ドメインで使用されるすべてのスキーマ

このオプションにより、Upgrade Assistantは指定したドメイン内の使用可能なスキーマをすべて検出し、それらをアップグレードに含めることができます。これは、ドメイン支援のスキーマ・アップグレードとも呼ばれています。

3.8 Upgrade Assistantでアップグレードできるスキーマの識別

アップグレードを開始する前に、スキーマのバージョン・レジストリを問い合せて使用可能なスキーマのリストをレビューします。

このオプションの手順は、アップグレード・プロセスを開始する前に手動でschema_version_registry表を問い合せる場合に使用できます。Upgrade Assistantは、アップグレードできるすべてのスキーマを識別して、アップグレードするスキーマを個別に選択するか、またはドメイン内のスキーマのすべてをアップグレードできる点に注意することが重要です。さらに、Upgrade Assistantを—readinessモードで実行すると、すべてのスキーマとその現在のアップグレード前バージョンを含んだレポートを受け取ります。

Oracle Databaseを使用する場合、Oracle DBAを持つユーザーとしてデータベースに接続し、SQL*Plusから次を実行して現行のバージョン番号を取得します。

SET LINE 120
COLUMN MRC_NAME FORMAT A14
COLUMN COMP_ID FORMAT A20
COLUMN VERSION FORMAT A12
COLUMN STATUS FORMAT A9
COLUMN UPGRADED FORMAT A8
SELECT MRC_NAME, COMP_ID, OWNER, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY ORDER BY MRC_NAME, COMP_ID ;

SQLスクリプト(version.sqlなど)に保存されると、次のレポートが生成されます。

VERSIONの数値が11.1.1.7.0以上で、STATUS列がVALIDであれば、そのスキーマはアップグレードでサポートされます。

あるスキーマでアップグレードの必要がない場合、schema_version_registry表には、アップグレード後もアップグレード前のバージョンでそのスキーマが保持されます。

ヒント:

スキーマ・バージョン・レジストリから収集した情報を対応するスキーマと比較し、まだアップグレードできないスキーマがドメイン内にあるかどうかを確認します。

アップグレードが必要なスキーマに関する注意

- ほとんどのコンポーネントで、アップグレードできるスキーマ・バージョンの開始点は、11gリリース1 (1.1.1.7.0、11.1.1.8.0、または11.1.1.9.0)または12c (12.1.2、12.1.3または12.2.1.0)のみです。スキーマが、サポートされているバージョンでない場合、12c (12.2.1.1)のアップグレード手順を使用する前に、それらをアップグレードする必要があります。
Oracle Enterprise Data QualityやOracle Golden Gate Veridataなど、一部のコンポーネントでは、サポートされている標準的なOracle Fusion Middlewareバージョン以外のバージョンからのアップグレードがサポートされています。

アップグレードに必要なスキーマに関する追加情報は、コンポーネント固有のインストールおよびアップグレードのドキュメントを参照してください。

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

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

3.9 Upgrade Assistantを使用したスキーマのアップグレード

Upgrade Assistantを実行して既存のドメイン内のすべてのスキーマを12.2.1.1にアップグレードします。Upgrade Assistantを非SYSDBAユーザーとして実行することをお薦めします。

スキーマをアップグレードする手順は、次のとおりです。

1. 次のコマンドを入力して、12.2.1.1 OracleホームからUpgrade Assistantを実行します。
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はアップグレードできるスキーマを含むすべてのコンポーネントを検出し選択します。さらに、Upgrade Assistantはスキーマの入力画面に接続情報を事前に移入します。

4. 「コンポーネント・リスト」画面で、ドメイン内のアップグレードするコンポーネントとスキーマがすべてリスト表示されていることを確認して「次」をクリックします。
アップグレードするコンポーネントやスキーマが表示されない場合は、「戻る」をクリックして前の画面に移動し、異なるドメインを指定してください。

一部のコンポーネントやスキーマをリストから除外する場合は、「すべてのスキーマ」画面に戻り、「個別に選択されたスキーマ」を選択します。このオプションにより、アップグレードに含めるスキーマのみを選択できます。

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

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

6. スキーマ資格証明の各画面で、選択したスキーマへの接続に必要な情報およびこの画面のスキーマをホストするデータベースを指定します。

画面名は、選択したスキーマのタイプによって変わります。次に例を示します。"MDS Schema"。

リリース12.1.2のUCSUMSスキーマでは、コンポーネントIDまたはスキーマ名が変わるため、Upgrade Assistantは、使用可能なスキーマを自動的に認識し、それらをドロップダウン・リストに表示することはありません。 テキスト・フィールドに手動で名前を入力する必要があります。名前は、アップグレードの開始点に応じて、prefix_ORASDPMまたはprefix_UMSのいずれかになります。

ヒント:
データベース接続文字列の形式は、テキスト・ボックスの下に表示されています。データベース接続文字列を提案された書式で指定します。

7. 「調査」画面には、各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを確認するUpgrade Assistantのステータスが表示されます。ステータスが「調査が終了しました。」であれば、「アップグレード」をクリックします。
調査フェーズが失敗した場合、「調査失敗」ダイアログ・ボックスの「いいえ」をクリックしてアップグレードを取り消すことをお薦めします。エラーの原因を表示するには、「ログの表示」をクリックして、アップグレードのトラブルシューティングに関する説明で一般的なアップグレード・エラーの解決方法を参照してください。

注意:

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

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

8. 「アップグレード・サマリー」画面で、ツリーを展開してそれまでに指定したオプションのサマリーをレビューします。
「ソース・バージョン」および「ターゲット・バージョン」をレビューして、アップグレードを進める前に両方のバージョンが正しいことを確認してください。

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

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

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

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

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

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

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

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

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

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

重要
ソースがクラスタ化環境の場合、プライマリ・ノードでのみ再構成ウィザードを実行します。変更をドメイン内の他のクラスタ・メンバーに適用するには、既存の環境がクラスタ化構成の場合の説明に従って、パック/アンパック・ユーティリティを使用します。

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

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

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

オプション

説明

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

このオプションを選択すると、ノード・マネージャ・ホームが$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」に注意してください。

拡張構成関連のすべての画面(「管理対象サーバー」、「クラスタ」、「マシン」、「HTTPプロキシ・アプリケーション」、「Coherenceクラスタ」、「システム・コンポーネント」など)については、Oracle WebLogic Serverのアップグレードを参照してください。

ドメインの再構成時にエラーが発生した場合は、Oracle WebLogic Serverのアップグレードのドメインのアップグレード・プロセスに関する重要な注意事項を参照してください。

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

アップグレード・アシスタントを使用して追加のドメイン・コンポーネント構成(OWSMポリシー・メタデータ構造およびアダプタ構成など)をアップグレードするには、この項の手順に従います。

ドメイン構成をアップグレードする手順は、次のとおりです。

1. 次のコマンドを入力して、12.2.1.1 OracleホームからUpgrade Assistantを実行します。
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. 「すべての構成」画面で、「ドメインによって使用されるすべての構成」を選択し、ドメインの場所を「ドメイン・ディレクトリ」フィールドに直接入力するか、「参照」をクリックしてナビゲーション・ツリーで有効なドメイン・ディレクトリを選択して指定します。「次」をクリックします。

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

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

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

6. 「UMS構成」画面で、UMS 11g構成ファイルをホストするリモート管理対象サーバーのログイン資格証明を指定します。必要な前提条件をすべて満たし、必要なログイン情報を指定した場合、Upgrade Assistantにより、リモート構成ファイルが自動的にコピーされます。

注意:
Upgrade Assistantにより管理対象サーバーまたは構成ファイルを特定できない場合は、手動でファイルをコピーしてからUpgrade Assistantを再起動する必要があります。詳細は、ユーザー・メッセージング・サービス(UMS)構成ファイルのコピー中のエラーを参照してください。

7. 「調査」画面には、各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを確認するUpgrade Assistantのステータスが表示されます。ステータスが「調査が終了しました。」であれば、「アップグレード」をクリックします。
調査フェーズが失敗した場合、「調査失敗」ダイアログ・ボックスの「いいえ」をクリックしてアップグレードを取り消すことをお薦めします。エラーの原因を表示するには、「ログの表示」をクリックして、アップグレードのトラブルシューティングに関する説明で一般的なアップグレード・エラーの解決方法を参照してください。

注意:

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

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

8. 「アップグレード・サマリー」画面で、ツリーを展開してそれまでに指定したオプションのサマリーをレビューします。
「ソース・バージョン」および「ターゲット・バージョン」をレビューして、アップグレードを進める前に両方のバージョンが正しいことを確認してください。

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

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

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

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

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

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

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

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

3.12 Infrastructureアップグレードのトラブルシューティング

Infrastructureアップグレードに失敗した場合は、ログ・ファイルおよびこのトピックのガイドラインを使用して原因をトラブルシューティングします。

注意:

大半のFusion Middlewareエラーと同様、調査フェーズで検出されたエラーは修正可能であり、アップグレード・アシスタントの実行を継続できます。しかし、アップグレード・フェーズで発生したエラーは、リストア済のバックアップ・ファイルを使用して修正する必要があり、アップグレード・プロセスは最初からやりなおす必要があります。アップグレード・フェーズでエラーの発生したアップグレードを、再実行しないでください。その環境は不安定だとみなして、アップグレード前の状態にリストアする必要があります。

詳細は、Upgrade Assistantによるアップグレードの一般的なトラブルシューティングのガイドラインを参照してください。

- 認証失敗 — JSch例外: 認証失敗
Upgrade Assistantを実行してWeblogicコンポーネント構成をアップグレードする際に、UMSサーバーに不適切なログイン資格証明を指定した場合、Upgrade Assistantのログ・ファイルにこのトピックに示されているような例外を受け取ります。

- ユーザー・メッセージング・サービス(UMS)構成ファイルのコピー中のエラー
Upgrade AssistantでUMS構成ファイルの自動コピーに失敗した場合は、UMSをアップグレードする前に、アップグレードを停止して構成ファイルを手動でコピーする必要があります。この手順は、アップグレード・アシスタントで構成ファイルの自動コピーが失敗した場合、または構成ファイルを手動でコピーした場合のみ必要です。

3.12.1 認証失敗 — JSch例外: 認証失敗

Upgrade Assistantを実行してWeblogicコンポーネント構成をアップグレードする際に、UMSサーバーに不適切なログイン資格証明を指定した場合、Upgrade Assistantのログ・ファイルにこのトピックに示されているような例外を受け取ります。

[upgrade.UCSUMS.UCSUMS_CONFIGURATION_PLUGIN] [tid: 110] [ecid:
88ab893d-a523-4a83-b5a6-f7b1cf8cb029-00000001,0] [[
com.jcraft.jsch.JSchException: Auth fail

このエラーの解決方法は、エラーが発生した時点に応じて異なります。

調査フェーズ (アップグレード・フェーズの前)でこのエラーが発生した場合: すべての管理対象サーバーおよびディレクトリに対して入力したユーザー名およびパスワードが有効であること、および指定したユーザー名にssh権限があることを確認します。エラーを修正した後、接続を再試行します。

アップグレード・フェーズでエラーが発生した場合、アップグレード操作は正常に行われておらず、バックアップからファイルをリストアして、アップグレードをやりなおす必要があります。要求に従って、適切なログイン資格証明を入力していることを確認してください。

注意:
アップグレード・フェーズで発生したエラーは非リエントラントであり、エラーを修正してアップグレードを続行することはできません。「アップグレード」をクリックした後でエラーが発生した場合は、アップグレード・プロセスをやりなおす前に、バックアップから環境をリストアする必要があります。

3.12.2 ユーザー・メッセージング・サービス(UMS)構成ファイルのコピー中のエラー

アップグレード・アシスタントでUMS構成ファイルの自動コピーに失敗した場合は、UMSをアップグレードする前に、アップグレードを停止して構成ファイルを手動でコピーする必要があります。この手順は、アップグレード・アシスタントで構成ファイルの自動コピーが失敗した場合、または構成ファイルを手動でコピーした場合のみ必要です。

この項では、UMSを11gから12cにアップグレードする際にリモートの管理対象サーバー・ノードから管理サーバーにコピーされる、UMS構成ファイルの場所について説明します。必要な前提条件をすべて満たし、必要なログイン情報を指定した場合、リモート構成ファイルは、アップグレード・アシスタントにより自動的にコピーされます。アップグレード・アシスタントによる構成ファイルのコピーに関する詳細は、『Oracle Fusion Middleware Upgrade Assistantによるアップグレード』を参照してください。

ただし、Upgrade Assistantでファイルの場所を特定できない場合は、リモートの管理対象サーバーからアップグレードを実行している管理サーバー上の同じ場所に、構成ファイルをコピーする必要があります。コピーする必要がある構成ファイルには、UMSサーバー構成ファイル(appconfig.xml)、ドライバの構成ファイル(driverconfig.xml)およびユーザー・プリファレンス・ファイル(businessterms.xml)などがあります。これらのファイルは、表3-7に示されているように、各管理対象サーバーの/applicationsフォルダに置かれています。

管理対象サーバーから管理サーバーに構成ファイルを手動でコピーした後、Upgrade Assistantを使用したドメイン・コンポーネント構成のアップグレードに記載されている手順に従って、Upgrade Assistantを起動しなおす必要があります

表3-7 構成ファイルの場所

構成ファイル

場所

UMSサーバー(appconfig.xml)

$DOMAIN_HOME/config/fmwconfig/servers/MANAGED_SERVER_NAME/applications/usermessagingserver/configuration/appconfig.xml

ドライバの構成(driverconfig.xml)

$DOMAIN_HOME/config/fmwconfig/servers/MANAGED_SERVER_NAME/applications/usermessagingdriver-DRIVER_NAME/configuration/driverconfig.xml

ユーザー・プリファレンス(businessterms.xml)

$DOMAIN_HOME/config/fmwconfig/servers/MANAGED_SERVER_NAME/applications/usermessagingserver/configuration/businessterms.xml

注意:

ドメイン内に複数のドライバがデプロイされている場合は、すべてのドライバの構成ファイルをコピーしていることを確認してください。DRIVER_NAMEを、ドメインにデプロイされているすべてのドライバ名で置き換えて確認できます。

3.13 アップグレード後のタスクの実行

Oracle Fusion Middleware 11g Application DeveloperをOracle Fusion Middleware 12c Infrastructureにアップグレードした後、アップグレード後タスクを完了する必要があります。

アップグレード後タスクについては、アップグレード後に実行するタスクを参照してください。

4 アップグレード後に実行するタスク

この項のトピックでは、Oracle Fusion Middleware 12c Infrastructureへのアップグレード後に実行する必要がある場合があるタスクについて説明します。アップグレードした環境に当てはまる手順のみを実行してください。

- アップグレード検証チェックリストの使用
アップグレード後、ノード・マネージャ、管理サーバー、Web層、管理コンソールおよびEnterprise Managerを起動できるかどうかの確認などの基本的な管理タスクを正常に完了できることを確認してください。

- サーバーの正しい順序での起動と停止
デプロイメントに関する問題を回避するために特定の順序でサーバーを起動および停止することをお薦めします。

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

- setDomainEnvへのカスタム構成設定の再適用
アプリケーション環境の12cへのアップグレードを完了するには、起動スクリプト(setDomainEnvなど)へのカスタム構成設定の再適用が必要な場合があります。これらのスクリプトは、アップグレード時に新しい12cバージョンで上書きされます。前のリリースで作成したカスタム構成設定は手動で再適用する必要があります。

- Oracle Fusion Middleware 12cの監査データ・ストアの構成
11gデプロイメントでファイルベースの監査ストアを使用していた場合は、Oracle Fusion Middleware 12cへのアップグレード後に、データベースベースの監査データ・ストアへの監査データのロードを有効にする必要があります。

- 古いJava EE Webサービス・アプリケーションのセキュリティ・ステータスの維持
12cにおいて、Java EE Webサービスおよびクライアントに対するグローバル・ポリシー・アタッチメントのサポートを導入すると、既存のJava EE Webサービスおよびクライアント(12.1.2およびそれ以前)の後方互換性に影響する場合があります。ポリシーの不在に依存しているJava EE Webサービスまたはクライアント・エンドポイントが、グローバル・ポリシー・アタッチメントのスコープに含まれる場合、グローバル・ポリシー・アタッチメントの存在によって、そのエンドポイントのセキュリティ動作が変更される場合があります。

- Oracle Fusion Middleware 12cソフトウェアを管理するためのドキュメント・リソース
このトピックでは、Infrastructure 12cへのアップグレード後に実行することが多い一般的な管理タスクおよび関連するドキュメント・リソースのリストを示しています。

- Oracle Fusion Middleware 12cにおける11gアプリケーション・デプロイメントの使用
Oracle Fusion Middleware 12cへのアップグレード後、Oracle Fusion Middleware 11gにデプロイしていたカスタムJavaおよびApplication Development Framework (ADF)は、Oracle Fusion Middleware 11gと同じように動作します。ただし、ADF 12cおよびJDeveloper 12cで利用可能ないくつかの新機能があります。

- 既存の環境がクラスタ構成の場合
既存の環境がクラスタ構成の場合、パック・ユーティリティおよびアンパック・ユーティリティを使用してそのドメイン内の他のクラスタ・メンバーに変更を適用する必要があります。

4.1 アップグレードの検証チェックリストの使用

アップグレード後、ノード・マネージャ、管理サーバー、Web層、管理コンソールおよびEnterprise Managerを起動できるかどうかの確認などの基本的な管理タスクを正常に完了できることを確認してください。

注意:

次のサーバーを起動する順序は重要です。それらを正しい順序で起動(停止)しないと、デプロイメントに関する問題が発生する可能性があるからです。

詳細は、「サーバーの正しい順序での起動と停止」を参照してください。

1. ノード・マネージャを起動できることを確認します。

2. 管理サーバーおよび管理対象サーバー(ある場合)を、元のドメイン・ホームのbinディレクトリから起動できることを確認します。Windowsオペレーティング・システム・ユーザーの場合は、新しいコマンド・プロンプトで(12cのUpgrade Assistantを起動したコマンド・プロンプトではなく)サーバーを起動すると便利です。

注意:
OHS自身の構成には、管理対象サーバーは必要ありません。

3. Web層(OHSサーバー)を起動できることを確認します。

4. 次のURLを使用して、管理コンソールおよびEnterprise Managerに接続できることを確認します。
管理コンソール: http://machinename.my_company_com:administration_port/console

Enterprise Manager: http://machinename.my_company_com:administration_port/em

4.2 サーバーの正しい順序での起動と停止

デプロイメントに関する問題を回避するために特定の順序でサーバーを起動および停止することをお薦めします。

Infrastructureのアップグレード後は、ご使用の環境にあるすべての管理サーバーと管理対象サーバーを起動して、それらが予期したとおりに機能していることを確認してください。

注意:

管理サーバー、管理対象サーバーおよびコンポーネントを含めたOracle Fusion Middlewareの開始および停止の手順については、Oracle Fusion Middlewareの管理のOracle Fusion Middlewareの開始と停止を参照してください。

次の順序でサーバーを起動します。

1. ノード・マネージャ

2. 管理サーバー

3. Web層(Oracle HTTP Serverを含む)

4. Oracle Web Services Manager (OWSM)の管理対象サーバー(インストールされている場合)

5. サービス指向アーキテクチャ(SOA)の管理対象サーバー(インストールされている場合)

6. Oracle Service Bus (OSB)の管理対象サーバー(インストールされている場合)

7. Business Activity Monitoring (BAM)の管理対象サーバー(インストールされている場合)

次の順序でサーバーを停止します。

1. Business Activity Monitoring (BAM)の管理対象サーバー(インストールされている場合)

2. Oracle Service Bus (OSB)の管理対象サーバー(インストールされている場合)

3. サービス指向アーキテクチャ(SOA)の管理対象サーバー(インストールされている場合)

4. Oracle Web Services Manager (OWSM)の管理対象サーバー(インストールされている場合)

5. Web層(Oracle HTTP Serverを含む)

6. 管理サーバー

7. ノード・マネージャ

サーバーの停止の詳細は、Oracle Fusion Middlewareの管理のOracle Fusion Middlewareの起動と停止を参照してください。

- ノード・マネージャの起動
ノード・マネージャは、WebLogic Serverとは別のプロセスとして稼働するJavaユーティリティであり、これを使用すると、管理サーバーを基準とした場所に関係なく、管理対象サーバーに対して共通操作を実行できます。

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

- Web層(Oracle HTTP Server)の起動
Oracle HTTP Serverは、Oracle Fusion MiddlewareのWebサーバー・コンポーネントです。これは、Oracle WebLogic Serverのリスナーと、Web上で静的ページ、動的ページ、およびアプリケーションをホストするためのフレームワークを提供します。

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

ノード・マネージャはWebLogic Serverとは別のプロセスで実行するJavaユーティリティです。管理サーバーとの位置関係に関係なく、管理対象サーバーに対する共通操作が可能になります。

注意:

ホストごとのノード・マネージャ構成を使用するには、適切なノード・マネージャ・スクリプトでJAVA_OPTIONSに–Dohs.product.home=<MW_HOME>が設定されていることを確認してください。ノード・マネージャ・サービスを使用していない場合は、NodeManager.cmd|shコマンドを実行します。ノード・マネージャ・サービスを使用している場合は、installNodeMgrSvc.cmdコマンドを実行します。

使用するホストとポートは、アップグレードされた設定で使用するものと一致している必要があります。ファイルのホストまたはポートの値を編集して適切な詳細でノード・マネージャ・サービスをインストールする方法の詳細は、Oracle Fusion Middleware Oracle WebLogic Serverノード・マネージャ管理者ガイドのJavaノード・マネージャの構成を参照してください。

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

1. ディレクトリをDOMAIN_HOME/binに変更します

2. Unixオペレーティング・システムでは次のコマンドを入力します: nohup ./startNodeManager.sh > nm.out&
ここでnohupおよびnm.outはサンプル出力ファイルです

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

4.2.2 管理サーバーの起動

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

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

1. Unixオペレーティング・システムでは、ディレクトリをDOMAIN_HOME/binに変更します。
Windowsオペレーティング・システムでは、ディレクトリをDOMAIN_HOME\binに変更します。

2. Unixオペレーティング・システムでは、次のコマンドを入力します: ./startWebLogic.sh
Windowsオペレーティング・システムでは、次のコマンドを入力します: startWebLogic.cmd

ドメインが正しく再構成されたことを確認するには、次のURLを使用して管理コンソールにログインし、コンソールに表示されるバージョン番号が12.2.1であることを確認します。
http://administration_server_host:administration_server_port/console

4.2.3 Web層(Oracle HTTP Server)の起動

Oracle HTTP Serverは、Oracle Fusion MiddlewareのWebサーバー・コンポーネントです。これは、Oracle WebLogic Serverのリスナーと、Web上で静的ページ、動的ページ、およびアプリケーションをホストするためのフレームワークを提供します。

Oracle HTTP Serverを起動する手順は、次のとおりです。

1. ディレクトリをDOMAIN_HOME/binに変更します。

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

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

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

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

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

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

注意:

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

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

4.4 カスタム構成設定のsetDomainEnvへの再適用

アプリケーション環境の12cへのアップグレードを完了するには、起動スクリプト(setDomainEnvなど)へのカスタム構成設定の再適用が必要な場合があります。これらのスクリプトは、アップグレード時に新しい12cバージョンで上書きされます。前のリリースで作成したカスタム構成設定は手動で再適用する必要があります。

詳細は、起動スクリプトへのカスタマイズの再適用を参照してください。

注意:

今後のアップグレードにおいてカスタム構成設定の消失を防ぐには、カスタムsetDomainEnv設定のメンテナンス(オプション)を参照してください。

4.5 Oracle Fusion Middleware 12c監査データ・ストアの構成

11gデプロイメントでファイルベースの監査ストアを使用していた場合は、Oracle Fusion Middleware 12cへのアップグレード後に、データベースベースの監査データ・ストアへの監査データのロードを有効にする必要があります。

包括的なアップグレード処理の一環として、他のOracle Fusion Middlewareスキーマが存在するデータベースにIAUスキーマを作成しておく必要があります。監査データ・ストアの使用の詳細は、 Fusion Middlewareアプリケーション・セキュリティ・ガイドの監査の構成および管理を参照してください。

4.6 古いJava EE Webサービス・アプリケーションのセキュリティ・ステータスのメンテナンス

12cにおいて、Java EE Webサービスおよびクライアントに対するグローバル・ポリシー・アタッチメントのサポートを導入すると、既存のJava EE Webサービスおよびクライアント(12.1.2およびそれ以前)の後方互換性に影響する場合があります。ポリシーの不在に依存しているJava EE Webサービスまたはクライアント・エンドポイントが、グローバル・ポリシー・アタッチメントのスコープに含まれる場合、グローバル・ポリシー・アタッチメントの存在によって、そのエンドポイントのセキュリティ動作が変更される場合があります。

注意:

Fusion Middleware 12.1.2およびそれ以前では、SOAP WebサービスおよびSOAP Webサービス・クライアントのサブジェクト・タイプのために定義されたグローバル・ポリシー・アタッチメントは、Oracle Infrastructure Webサービスおよびクライアントにのみ適用可能であり、Java EE Webサービスおよびクライアントからは無視されていました。12c (12.2.1)へのアップグレード後は、これらのサブジェクト・タイプのために定義されたグローバル・ポリシー・アタッチメントは、Java EE Webサービスおよびクライアントにも適用され、既存のJava EE Webサービスおよびクライアントのセキュリティ動作に影響を与える場合があります。

後方互換性を維持するには、特定のサービスまたはクライアントにOWSM動作無効ポリシー(no_authentication_service_policy、no_authorization_service_policyまたはno_messageprotection_service_policyなど)をアタッチすることにより、それらのエンドポイントへのグローバル・ポリシー・アタッチメントを無効化できます。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のグローバルにアタッチされたポリシーの無効化を参照してください。

注意:

WebLogic Wssp1.5-No-Op.xml動作無効ポリシーを使用できます。ただし、WebLogicセキュリティ・ポリシーは、プログラムでのみWebサービス・クライアントにアタッチできるため、コードの変更が必要です。詳細は、Oracle WebLogic Server WebLogic Webサービスの保護の「グローバルにアタッチされたポリシーの無効化」を参照してください

4.7 Oracle Fusion Middleware 12cソフトウェアの管理のためのドキュメント・リソース

このトピックでは、Infrastructure 12cへのアップグレード後に実行することが多い一般的な管理タスクおよび関連するドキュメント・リソースのリストを示しています。

表4-1に、Infrastructure 12cへのアップグレード後に実行することが多い一般的な管理タスクを示します。

表4-1 基本的な管理タスク

タスク

説明

参照先

Fusion Middleware管理ツールについての学習

環境の管理に使用できる各種ツールについて習熟します。

Oracle Fusion Middlewareの管理のOracle Fusion Middleware管理ツールの概要。

製品およびサーバーの起動と停止

Oracle Fusion Middleware(管理サーバー、管理対象サーバー、コンポーネントを含む)起動と停止の方法について学習します。

Oracle Fusion Middlewareの管理のOracle Fusion Middlewareの起動と停止。

Secure Sockets Layer (SSL)の構成

Oracle Fusion Middlewareコンポーネント間で、SSLを使用したセキュアな通信を設定する方法について学習します。

Oracle Fusion Middlewareの管理のOracle Fusion MiddlewareでのSSLの構成。

Oracle Fusion Middlewareのモニタリング

Oracle Fusion Middlewareコンポーネントのステータスを追跡する方法を学習します。

Oracle Fusion Middlewareの管理のOracle Fusion Middlewareの監視。

バックアップとリカバリの手順の理解

Oracle Fusion Middlewareのバックアップとリカバリの推奨手順について学習します。

Oracle Fusion Middlewareの管理のバックアップとリカバリの概要。

4.8 Oracle Fusion Middleware 12cでの11gアプリケーション・デプロイメントの使用

Oracle Fusion Middleware 12cへのアップグレード後、Oracle Fusion Middleware 11gにデプロイしていたカスタムJavaおよびApplication Development Framework (ADF)は、Oracle Fusion Middleware 11gと同じように動作します。ただし、ADF 12cおよびJDeveloper 12cで利用可能ないくつかの新機能があります。

次の項では、アプリケーションをJDeveloper 12cに移行する方法についての追加情報を示します。

- Oracle Application Development Framework (ADF) 12cについて

- Oracle JDeveloper 12cについて

- Oracle Application Development Framework (ADF) 12cについて
Oracle ADFは、エンドツーエンドJava EEフレームワークです。これによって、追加設定なしで使用できるインフラストラクチャ・サービスと、視覚的で宣言的な開発エクスペリエンスが提供され、アプリケーション開発が簡素化されます。

- Oracle JDeveloper 12cについて
Oracle JDeveloperは、アプリケーション・ライフサイクルの各段階に対処するJavaベースのアプリケーションの開発を簡素化する統合開発環境です。JDeveloperは、Oracleのプラットフォームおよびアプリケーションに対する完全なエンド・ツー・エンドの開発を提供します。

4.8.1 Oracle Application Development Framework (ADF) 12cについて

Oracle ADFは、エンドツーエンドJava EEフレームワークです。これによって、追加設定なしで使用できるインフラストラクチャ・サービスと、視覚的で宣言的な開発エクスペリエンスが提供され、アプリケーション開発が簡素化されます。

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

- Oracle Application Development Frameworkの理解

- Oracle Application Development Framework (ADF)共通タスク・ページ

4.8.2 Oracle JDeveloper 12cについて

Oracle JDeveloperは、アプリケーション・ライフサイクルの各段階に対処するJavaベースのアプリケーションの開発を簡素化する統合開発環境です。JDeveloperは、Oracleのプラットフォームおよびアプリケーションに対する完全なエンド・ツー・エンドの開発を提供します。

- Oracle JDeveloper 12cのインストール
Oracle JDeveloperは、アプリケーションをローカルでテストするために使用できる埋込みバージョンのOracle WebLogic Serverを提供します。

- Oracle JDeveloper 12cを使用したアプリケーションの移行
Oracle JDeveloper 12cのインストール後、Oracle JDeveloper 12cでカスタム・アプリケーション・プロジェクトを開いて、Oracle JDeveloper 12cに自動的に移行できます。

- Oracle JDeveloper 12cを使用した非同期Webサービスの移行について
アプリケーションにApplication Development Framework Business Components (ADF BC)非同期Webサービスが含まれている場合、Oracle JDeveloperまたはojdeployコマンド行ツールを使用してそれを再作成し、必要なデプロイメント・ディスクリプタをデプロイメント・アーカイブに生成します。

4.8.2.1 Oracle JDeveloper 12cのインストール

Oracle JDeveloperは、アプリケーションをローカルでテストするために使用できる埋込みバージョンのOracle WebLogic Serverを提供します。

Oracle JDeveloper 12cをインストールするには、Oracle JDeveloperのインストールを参照してください。

JDeveloperを使用したアプリケーションのテストの詳細は、Oracle JDeveloperのインストールのOracle JDeveloperで開発したアプリケーションのデプロイとテストを参照してください。

4.8.2.2 Oracle JDeveloper 12cを使用したアプリケーションの移行

Oracle JDeveloper 12cのインストール後、Oracle JDeveloper 12cでカスタム・アプリケーション・プロジェクトを開いて、Oracle JDeveloper 12cに自動的に移行できます。

詳細は、Oracle JDeveloperのインストールの前のバージョンからOracle JDeveloper 12.2.1への移行を参照してください。

4.8.2.3 Oracle JDeveloper 12cを使用した非同期Webサービスの移行について

アプリケーションにApplication Development Framework Business Components (ADF BC)非同期Webサービスが含まれている場合、Oracle JDeveloperまたはojdeployコマンド行ツールを使用してそれを再作成し、必要なデプロイメント・ディスクリプタをデプロイメント・アーカイブに生成します。

非同期Webサービスの開発の詳細は、Oracle Infrastructure Webサービスの開発の非同期Webサービスの開発を参照してください。

4.9 既存の環境がクラスタ構成の場合

既存の環境がクラスタ構成の場合、パック・ユーティリティおよびアンパック・ユーティリティを使用してそのドメイン内の他のクラスタ・メンバーに変更を適用する必要があります。

4.9.1 プライマリ・ノードのドメインのパック

プライマリ・ノードのドメインをパックする手順は、次のとおりです。

1. プライマリ・ノードにログインします。

2. 次の例に示すように、ドメインをパックします。
./pack.sh -managed=true -domain=$DOMAIN_HOME/user_projects/domains/base_domain -template=sampledomaintemplate.jar -template_name=sample_domain_template

4.9.2 セカンダリ・ノードのドメインのアンパック

セカンダリ・ノードのドメインをアンパックする手順は、次のとおりです。

1. セカンダリ・ノードにログインします。

2. 次の例に示すように、ドメインを含むsampledomaintemplate.jarファイルをアンパックします。
./unpack.sh -domain=$DOMAIN_HOME/user_projects/domains/base_domain -template=$ORACLE_HOME/oracle_common/common/bin/sampledomaintemplate.jar -app_dir=$DOMAIN_HOME/user_projects/applications -overwrite_domain=true

A Upgrade Assistantの起動

この項では、Oracle Fusion Middleware Upgrade Assistantの実行方法について説明します。Upgrade Assistantは、グラフィカル・ユーザー・インタフェース(GUI)モードとレスポンス・ファイル・モードのどちらでも実行できます。

このトピックで説明するオプションのコマンドライン・インタフェース引数を使用して、Oracle Fusion Middlewareコンポーネントを最新のバージョンにアップグレードできます。また、一部のアップグレード・タスクを自動化するレスポンス・ファイルを作成することもできます。

この節の内容は以下のとおりです。

- グラフィカル・ユーザー・インタフェース(GUI)モードでのUpgrade Assistantの起動
Upgrade Assistantは、スキーマ、コンポーネント構成およびスタンドアロンのシステム・コンポーネントをアップグレードするために使用されます。

- 「レスポンス・ファイル・モードでのUpgrade Assistantの起動」
サイレントまたはハンズフリー・アップグレードはレスポンス・ファイルを使用して実行できます。レスポンス・ファイルはUpgrade Assistantの画面で情報を入力した後でのみ作成できます。

- DISPLAY環境変数の設定

A.1 グラフィカル・ユーザー・インタフェース(GUI)モードでのUpgrade Assistantの起動

Upgrade Assistantは、スキーマ、コンポーネント構成およびスタンドアロンのシステム・コンポーネントをアップグレードするために使用されます。

他のドメインのアップグレードを開始する前に、単一のドメインのスキーマのアップグレードおよびコンポーネント構成を正常に完了させることをお薦めします。

注意:
Upgrade Assistantは可能であればいつでも、SYSDBA以外のユーザーが実行する必要があります。スキーマをアップグレードするために必要な権限を持つユーザーを作成する手順は、非SYSDBAユーザーの作成で説明されています。

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

1. UNIXオペレーティング・システムでは、ディレクトリをORACLE_HOME/oracle_common/upgrade/binに変更します。

Windowsオペレーティング・システムでは、ディレクトリをORACLE_HOME\oracle_common\upgrade\binに変更します。

2. 次のコマンドを入力して、アップグレード・アシスタントを起動します。

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

./ua

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

ua.bat

次のUNIXの例に示すように、ロギング・パラメータを使用してアップグレード・アシスタントを起動することもできます。

./ua [-logLevel <log_level] [-logDir <log_directory>]

ロギング・レベル。次のいずれかを選択します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

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

注意:
トラブルシューティングする場合、-logLevelをTRACEに設定すると、より多くの情報がロギングされます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があるため、別の情報が必要ない場合は、logLevelを変更してください。

- 追加のパラメータ(オプション)を使用したUpgrade Assistantの起動

A.1.1 追加のパラメータ(オプション)を使用したUpgrade Assistantの起動

表A-1に、Upgrade AssistantをGUIモードで実行する際に使用できるコマンドライン・パラメータをリストします。次の例は、これらのパラメータを各オペレーティング・システムで使用する方法を示します。

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

ディレクトリをORACLE_HOME/oracle_common/upgrade/binに変更します。

コマンドを入力します: ./ua -help

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

ディレクトリをORACLE_HOME/oracle_common/upgrade/binに変更します。

コマンドを入力します: ua.bat -help

注意:
Oracle Upgrade Assistantを起動するときに、「サーバーに接続できません。」、「サーバーによって接続が拒否されました」または「表示を開くことができません」などのXlibエラーが発生する場合、「DISPLAY環境変数の設定」の説明に従ってDISPLAY環境変数を設定して、Upgrade Assistantを再起動する必要があります。

表A-1 Upgrade Assistant GUIコマンドライン・パラメータ

パラメータ

必須パラメータ/オプション・パラメータ

説明

-logLevel

オプション。

ロギング・レベル。次のいずれかを選択します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

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

注意:
トラブルシューティングする場合、-logLevelをTRACEに設定すると、より多くの情報がロギングされます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があるため、別の情報が必要ない場合は、logLevelを変更してください。

注意:
TRACEメッセージは、Upgrade Assistantログ・ファイル・ビューアに含まれていません。TRACEメッセージを表示するには、別のツールを使用する必要があります。

-logDir

オプション。

注意:
Upgrade Assistantが読取り専用ディレクトリにインストールされている場合、ログ・ディレクトリを書込み可能にするには、このパラメータを指定する必要があります。ログ・ディレクトリが読取り専用である場合、Upgrade Assistantは機能しなくなります。

アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を変更します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

UNIXオペレーティング・システムの場合、デフォルトの場所は次のとおりです。

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

Windowsオペレーティング・システムの場合、デフォルトの場所は次のとおりです。

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

-threads

オプション

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

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

-readiness

準備状況チェックに必要

実際の調査またはアップグレードを実行せずにアップグレードの準備状況チェックを実行します。

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

注意:
-readinessオプションは、コマンドラインに-examineオプションとともには表示されない場合があります。

詳細は、「準備状況チェックの実行」を参照してください

-help

オプション。

コマンドライン・オプションをすべてコンソールに出力します。

A.2 レスポンス・ファイル・モードでのUpgrade Assistantの起動

サイレントまたはハンズフリー・アップグレードはレスポンス・ファイルを使用して実行できます。レスポンス・ファイルはUpgrade Assistantの画面で情報を入力した後でのみ作成できます。

次のトピックでは、レスポンス・ファイルを使用して、サポートされているOracle Fusion Middlewareコンポーネントをサイレント・モードでアップグレードする方法について説明します。このレスポンス・ファイルは、Upgrade Assistantのグラフィカル・ユーザー・インタフェース画面で入力したすべての情報を収集し、Upgrade Assistantウィザードの機能とまったく同じ機能を実行します。

注意:
最初にUpgrade AssistantをGUIモードで実行して、サイレント・アップグレードを完了するためのレスポンス・ファイルを生成します。

- アップグレード・レスポンス・ファイルの作成

- レスポンス・ファイルを使用したFusion Middlewareのアップグレード

A.2.1 アップグレード・レスポンス・ファイルの作成

「アップグレード・サマリー」画面の「レスポンス・ファイルの保存」オプションは、Upgrade Assistant画面ですでに入力した情報を使用するファイルを作成します。レスポンス・ファイルにより、Upgrade Assistantウィザードの画面を介してデータを手動で入力するかわりに、保存された情報を使用できます。

「レスポンス・ファイルの保存」オプションを選択すると、このレスポンス・ファイルの名前と作成場所を入力するように求められます。作成されたら、そのファイルをそのまま使用して他のシステムにアップグレード・オプションを複製するか、必要に応じて変更できます。

詳細は、「レスポンス・ファイルを使用したFusion Middlewareのアップグレード」を参照してください。

A.2.2 レスポンス・ファイルを使用したFusion Middlewareのアップグレード

コマンドライン・インタフェース(CLI)からレスポンス・ファイルを使用してアップグレードを実行するには、次のコマンドを使用します。

UNIXオペレーティング・システムでは、次のようにします。

ディレクトリをORACLE_HOME/oracle_common/upgrade/bin に変更します。

次を実行します。

./ua -response <response_file> [-examine] [-logLevel <log_level>] [-logDir <log_directory>] [-threads <number>]
Windowsオペレーティング・システムの場合:

ディレクトリをORACLE_HOME/oracle_common/upgrade/bin に変更します。

次を実行します。

ua.bat -response <response_file> [-examine] [-logLevel <log_level>] [-logDir <log_directory>] [-threads <number>]

表A-2 Upgrade Assistantのレスポンス・ファイル・モードのコマンドライン・パラメータ

パラメータ

必須パラメータ/オプション・パラメータ

説明

-readiness

準備状況チェックに必要

実際の調査またはアップグレードを実行せずにアップグレードの準備状況チェックを実行します。

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

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

詳細は、「準備状況チェックの実行」を参照してください

-threads

オプション

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

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

-response

必須。

アップグレードを実行するには、入力が含まれているファイルが必要です。このファイルは、グラフィカル・モードでUpgrade Assistantを実行しているときに入力した入力から生成できます。

-examine

オプション。

このオプションが有効になっている場合、Upgrade Assistantは調査フェーズを実行しますが、実際のアップグレードは行いません。

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

-logLevel

オプション。

ロギング・レベル。次のいずれかを選択します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

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

注意:
-logLevelをTRACEに設定すると、より多くの情報がロギングされます。これは、失敗したアップグレードをトラブルシューティングするときに役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir

オプション。

アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を変更します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

UNIXオペレーティング・システムの場合、デフォルトの場所は次のとおりです。

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

Windowsオペレーティング・システムの場合、デフォルトの場所は次のとおりです。

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

-help

オプション。

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

A.3 DISPLAY環境変数の設定

GUIモードでUpgrade Assistantを実行する場合、DISPLAY変数を適切に設定しないと、次のようなエラーが発生する場合があります。

Xlib: ":1.0"への接続がサーバーで拒否されました

Xlib: プロトコルが指定されていません

原因: これらのエラーは、画面にGUIの表示を許可するDISPLAY変数が適切に設定されていないことを示しています。

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

DISPLAY変数を設定してもこれらのエラーが発生し続ける場合は、vncconfigなどの他のGUIツールの起動を試みてください。同じエラーが表示される場合は、DISPLAY環境変数が正しく設定されていない場合があります。

オラクルの法律上の注意点について

コピーライトについて

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を参照してください。