Oracle® Fusion Middleware

Oracle Data Integratorのアップグレード

12c (12.2.1.2)

E82836-01(原本部品番号:E77902-02)

2016年11月

このドキュメントは、インストール担当者およびシステム管理者を対象に、Oracle Data Integratorを12c (12.2.1.2)にアップグレードする方法について説明します

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

E82836-01

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

原本著者: Ingrid Snedecor

原本協力著者: Priyanka Chheda、Lisa Jamen

原本協力者: Ayush Ganeriwal、Srinivasa Ganti、Sachin Thatte

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

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

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

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およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

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

はじめに

- 対象者

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

- 関連ドキュメント

- 表記規則

第I部 概要

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

- 1.1 Oracle Data Integratorアップグレードの開始点について

- 1.2 Oracle Data Integrator標準トポロジについて

- 1.2.1 スタンドアロン・エージェントのOracle Data Integrator標準アップグレード・トポロジ

- 1.2.2 スタンドアロン・コロケート・エージェントのOracle Data Integrator標準アップグレード・トポロジ

- 1.2.3 Java EEエージェントのOracle Data Integrator標準アップグレード・トポロジ

- 1.3 Oracle Data Integrator 12cの新機能について

- 1.3.1 WebLogic Management Frameworkによるスタンドアロン・エージェントの管理

- 1.3.2 独自のディレクトリへのスタンドアロン・エージェントのインストール

- 1.3.3 リポジトリ・アップグレードでオブジェクト名の一意性が検証される

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 2.8 アップグレード・アシスタントを実行する非SYSDBAユーザーの作成

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

- 2.10 ODIの外部認証の構成

第II部 Oracle Data Integratorの11gからのアップグレード

3 Oracle Data Integratorスタンドアロン・エージェント環境の11gからのアップグレード

- 3.1 Oracle Data Integratorスタンドアロン・エージェントのアップグレード・プロセスについて

- 3.2 Oracle Data Integratorスタンドアロン・エージェント環境のインストール

- 3.3 必要な12cスキーマの作成

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

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

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

- 3.5.1.1 アップグレード・アシスタントのコマンドライン・パラメータ

- 3.5.2 アップグレード・アシスタントを使用した製品スキーマのアップグレード

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

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

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

- 3.6.1.1 アップグレード・アシスタントのコマンドライン・パラメータ

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

- 3.7 サーバーおよびプロセスの起動

4 Oracle Data Integratorスタンドアロン・コロケート・エージェント環境の11gからのアップグレード

- 4.1 Oracle Data Integratorスタンドアロン・コロケート・エージェントのアップグレード・プロセスについて

- 4.2 Oracle Data Integratorスタンドアロン・コロケート・エージェント環境のインストール

- 4.3 必要な12cスキーマの作成

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

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

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

- 4.4.2.1 アップグレード・アシスタントのコマンドライン・パラメータ

- 4.4.3 アップグレード・アシスタントでの準備状況チェックの実行

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

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

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

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

- 4.6.1.1 アップグレード・アシスタントのコマンドライン・パラメータ

- 4.6.2 アップグレード・アシスタントを使用した製品スキーマのアップグレード

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

- 4.7 ドメインの再構成

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

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

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

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

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

- 4.8.1.1 アップグレード・アシスタントのコマンドライン・パラメータ

- 4.8.2 アップグレード・アシスタントを使用したドメイン・コンポーネント構成のアップグレード

- 4.9 サーバーおよびプロセスの起動

5 Oracle Data Integrator Java EEエージェント環境の11gからのアップグレード

- 5.1 Oracle Data Integrator Java EEエージェントのアップグレード・プロセスについて

- 5.2 Oracle Data Integrator Java EE環境のインストール

- 5.3 必要な12cスキーマの作成

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

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

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

- 5.4.2.1 アップグレード・アシスタントのコマンドライン・パラメータ

- 5.4.3 アップグレード・アシスタントでの準備状況チェックの実行

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

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

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

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

- 5.6.1.1 アップグレード・アシスタントのコマンドライン・パラメータ

- 5.6.2 アップグレード・アシスタントを使用した製品スキーマのアップグレード

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

- 5.7 ドメインの再構成

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

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

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

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

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

- 5.8.1.1 アップグレード・アシスタントのコマンドライン・パラメータ

- 5.8.2 アップグレード・アシスタントを使用したドメイン・コンポーネント構成のアップグレード

- 5.9 サーバーおよびプロセスの起動

第III部 Oracle Data Integratorの前の12cリリースからのアップグレード

6 Oracle Data Integratorスタンドアロン・エージェント環境の前の12cリリースからのアップグレード

- 6.1 Oracle Data Integratorスタンドアロン・エージェントのアップグレード・プロセスについて

- 6.2 Oracle Data Integratorスタンドアロン・エージェント環境のインストール

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

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

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

- 6.4.1.1 アップグレード・アシスタントのコマンドライン・パラメータ

- 6.4.2 アップグレード・アシスタントを使用した製品スキーマのアップグレード

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

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

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

- 6.5.1.1 アップグレード・アシスタントのコマンドライン・パラメータ

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

- 6.6 サーバーおよびプロセスの起動

7 Oracle Data Integratorスタンドアロン・コロケート・エージェント環境の前の12cリリースからのアップグレード

- 7.1 Oracle Data Integratorスタンドアロン・コロケート・エージェントのアップグレード・プロセスについて

- 7.2 Oracle Data Integratorスタンドアロン・コロケート・エージェント環境のインストール

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

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

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

- 7.3.2.1 アップグレード・アシスタントのコマンドライン・パラメータ

- 7.3.3 アップグレード・アシスタントでの準備状況チェックの実行

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

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

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

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

- 7.5.1.1 アップグレード・アシスタントのコマンドライン・パラメータ

- 7.5.2 アップグレード・アシスタントを使用した製品スキーマのアップグレード

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

- 7.6 ドメインの再構成

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

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

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

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

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

- 7.7.1.1 アップグレード・アシスタントのコマンドライン・パラメータ

- 7.7.2 アップグレード・アシスタントを使用したドメイン・コンポーネント構成のアップグレード

- 7.8 サーバーおよびプロセスの起動

8 Oracle Data Integrator Java EEエージェント環境の前の12cリリースからのアップグレード

- 8.1 Oracle Data Integrator Java EEエージェントのアップグレード・プロセスについて

- 8.2 Oracle Data Integrator Java EE環境のインストール

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

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

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

- 8.3.2.1 アップグレード・アシスタントのコマンドライン・パラメータ

- 8.3.3 アップグレード・アシスタントでの準備状況チェックの実行

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

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

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

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

- 8.5.1.1 アップグレード・アシスタントのコマンドライン・パラメータ

- 8.5.2 アップグレード・アシスタントを使用した製品スキーマのアップグレード

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

- 8.6 ドメインの再構成

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

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

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

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

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

- 8.7.1.1 アップグレード・アシスタントのコマンドライン・パラメータ

- 8.7.2 アップグレード・アシスタントを使用したドメイン・コンポーネント構成のアップグレード

- 8.8 サーバーおよびプロセスの起動

第IV部 トラブルシューティングおよび高度な構成

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

10 高度なアップグレード・オプション

A 代替API

はじめに

このマニュアルでは、既存のOracle Data Integrator環境を12c (12.2.1.2)にアップグレードする方法について説明します。

- 対象読者

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

- 関連ドキュメント

- 表記規則

対象読者

このドキュメントは、Oracle Data Integratorのインストール、保守およびアップグレードを担当するシステム管理者を対象としています。ここでは、読者に次の知識があることを前提としています。

- Oracle Fusion Middlewareシステムの管理および構成

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

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

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

Oracleサポートへのアクセス

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

関連ドキュメント

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

- Oracle Data Integrator情報は、Oracle Data Integratorドキュメントを参照してください。

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

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

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

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

表記規則

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

表記規則

意味

太字

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

斜体

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

固定幅フォント

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

第I部 概要

Oracle Fusion Middleware Oracle Data Integratorのアップグレードのこの部では、Oracle Data Integratorについて紹介し、12c (12.2.1.2)にアップグレードするための準備として実行する必要がある手順を示します。

- Oracle Data Integratorの12c (12.2.1.2)へのアップグレードの概要
開始する前に、概要の情報をすべて確認して、Oracle Data Integrator 12c (12.2.1.2)の標準アップグレード・トポロジおよびアップグレード・パスを理解します。

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

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

開始する前に、概要の情報をすべて確認して、Oracle Data Integrator 12c (12.2.1.2)の標準アップグレード・トポロジおよびアップグレード・パスを理解します。

アップグレード前の情報および準備の手順の次に、このガイドの手順は2つの項に分かれます。

- 11gからのアップグレード、Oracle Data Integratorの11gからのアップグレードに記載。

- 前の12cリリースからのアップグレード、Oracle Data Integratorの前の12cリリースからのアップグレードに記載

注意:Fusion Middlewareのアップグレードのプランニングに関する一般情報およびアップグレードのその他の概念およびリソースについては、Oracle Fusion Middleware Oracle Fusion Middlewareのアップグレードのプランニングの次の各項を参照してください。

- Oracle Fusion Middleware 12cへのアップグレードのプランニング (12.2.1.2)

- インプレース・アップグレードとアウトオブプレース・アップグレードの理解

- 基本的な12cのアップグレード・タスクの理解

次のトピックでは、Oracle Data Integratorのアップグレードに関する概念について説明します。

- Oracle Data Integratorアップグレードの開始点について
サポートされている11gおよび12cのリリースから、Oracle Data Integrator 12c (12.2.1.2)にアップグレードできます。

- Oracle Data Integrator標準トポロジについて
Oracle Data Integratorを12c (12.2.1.2)にアップグレードする手順は、既存の本番トポロジ(11gまたは前の12cリリース)によって異なります。

- Oracle Data Integrator 12cの新機能について
Oracle Data Integrator 11gと12cの間には複数の変更点があります。

親トピック: はじめに

1.1 Oracle Data Integratorアップグレードの開始点について

サポートされている11gおよび12cのリリースから、Oracle Data Integrator 12c (12.2.1.2)にアップグレードできます。

サポートされているリリース開始点は次のとおりです。

- Oracle Data Integrator 11gリリース1 (11.1.1.6、11.1.1.7および11.1.1.9)

- Oracle Data Integrator 12c (12.1.2.0、12.1.3.0、12.2.1.0および12.2.1.1)

このガイドのアップグレード手順では、既存のOracle Data Integrator 11gまたは12c環境からOracle Fusion Middleware 12c (12.2.1.2)にアップグレードする方法を説明します。アップグレードが必要なその他のコンポーネントが環境に含まれる場合に備えて、サポート・ドキュメントへのリンクが提供されています。

既存のバージョンのOracle Data Integratorが11g リリース1 (11.1.1.6)より古い場合、12c (12.2.1.2)にアップグレードする前に、まず次のサポートされるバージョンのいずれかにソフトウェアをアップグレードする必要があります。

- 11g リリース1 (11.1.1.6)にアップグレードするには、11g リリース1 (11.1.1.6)ドキュメント・ライブラリのOracle Fusion Middleware Oracle Data Integratorアップグレード・ガイドを参照してください。

- 11g リリース1 (11.1.1.7)にアップグレードするには、11g リリース1 (11.1.1.7)ドキュメント・ライブラリのOracle Fusion Middleware Oracle Data Integratorアップグレード・ガイドを参照してください。

1.2 Oracle Data Integrator標準トポロジについて

Oracle Data Integratorを12c (12.2.1.2)にアップグレードする手順は、既存の本番トポロジ(11gまたは前の12cリリース)によって異なります。

そのため、考えられるすべてのOracle Data Integratorインストールに対して正確なアップグレード手順を示すことは困難です。したがって、このガイドではいくつかの一般的なOracle Data Integratorトポロジをアップグレードする手順について説明します。これらの一般的なトポロジを、標準アップグレード・トポロジと呼びます。

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

注意:
アップグレードを成功させるためのアップグレード・プロセスおよびプランニング・リソースの詳細は、Oracle Fusion Middleware Oracle Fusion MiddlewareのアップグレードのプランニングのOracle Fusion Middleware 12c (12.2.1.2)へのアップグレードのプランニングを参照してください。

前の12cリリースからアップグレードする場合、標準トポロジはそのままです。Oracle Data Integratorの前の12cリリースからのアップグレードを参照してください。

11gからアップグレードする場合、次の項を参照して次の特定のトポロジをアップグレードします。

- スタンドアロン・エージェントのOracle Data Integrator標準アップグレード・トポロジ

- スタンドアロン・コロケート・エージェントのOracle Data Integrator標準アップグレード・トポロジ

- Java EEエージェントのOracle Data Integrator標準アップグレード・トポロジ

1.2.1 スタンドアロン・エージェントのOracle Data Integrator標準アップグレード・トポロジ

11gから12c (12.2.1.2)にアップグレードする場合、WebLogicドメイン内に構成されていないスタンドアロン・エージェントのOracle Data Integratorトポロジはここに示すように更新されます。前の12cリリースからアップグレードする場合、既存のトポロジはそのままです。

スタンドアロン・エージェントは、独立したJava仮想マシン(JVM)プロセスで動作します。スタンドアロン・エージェントは、JDBCによって、作業リポジトリとソースおよびターゲット・データ・サーバーに接続します。スタンドアロン・エージェントはJava仮想マシンがインストールされているサーバーにインストールできます。いずれかのデータ・サーバーに対してローカルであるリソース(ファイル・システムまたはデータベース・インスタンスがインストールされたローダー・ユーティリティなど)を使用する必要があり、このマシンにはJava EEアプリケーション・サーバーをインストールしない場合、このタイプのエージェントが適切です。

11gでは、次のスタンドアロン・エージェント構成が可能でした。

- OPMNで管理されないスタンドアロンOracleインスタンスとしてのスタンドアロン・エージェント。この構成では、アップグレード・アシスタントはスタンドアロン・システム・コンポーネント構成の12c (12.2.1.2)へのアップグレードをサポートしていません。

- OPMNで管理されるスタンドアロン・エージェント。この構成では、アップグレード・アシスタントはスタンドアロン・システム・コンポーネント構成の12c (12.2.1.2)へのアップグレードをサポートしています。

図1-1に、OPMNによって管理されるスタンドアロン・エージェントの11g Oracle Data Integrator標準インストール・トポロジと、このガイドのアップグレード手順実行後の12cトポロジを示します。

このトポロジのアップグレード・ロードマップおよび手順は、Oracle Data Integratorスタンドアロン・エージェント環境の11gからのアップグレードに示されています。

図1-1 スタンドアロン・エージェントのOracle Data Integrator標準アップグレード・トポロジ

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

表1-1 スタンドアロン・エージェントの標準アップグレード・トポロジの要素の説明

要素

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

11g Oracle Data Integratorスタンドアロン標準インストール・トポロジ

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

これは、1台のマシン上の単一スタンドアロン・エージェント(OracleDIAgent1)で構成されます。スタンドアロン・エージェントはOPMNで管理されます。

図に示すように、マスターおよび作業リポジトリのリレーショナル・データベースも必要です。

12c Oracle Data Integratorスタンドアロン・エージェント標準インストール・トポロジ

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

これは、スタンドアロン・ドメイン内に構成された単一スタンドアロン・エージェント(OracleDIAgent1)と、マスターおよび作業リポジトリのリレーショナル・データベースで構成されます。

APPHOST

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

DBHOST

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

スタンドアロン・エージェント

独立したJava仮想マシン(JVM)プロセスで動作するスタンドアロンOracle Data Integratorエージェントです。

11gでは、スタンドアロン・エージェントはインストールの一部として直接作成されます。

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

詳細は、Oracle Fusion Middleware Oracle HTTP Serverの管理のスタンドアロン・ドメインを参照してください。

システム・コンポーネント

12cでは、スタンドアロン・エージェントを作成する前にスタンドアロン・ドメインを作成する必要があります。システム・コンポーネントはスタンドアロン・エージェントに対応します。

1.2.2 スタンドアロン・コロケート・エージェントのOracle Data Integrator標準アップグレード・トポロジ

11gから12c (12.2.1.2)にアップグレードする場合、WebLogicドメイン内に構成されているスタンドアロン・エージェントのOracle Data Integratorトポロジはここに示すように更新されます。前の12cリリースからアップグレードする場合、既存のトポロジはそのままです。

スタンドアロン・コロケート・エージェントは、独立したJava Virtual Machine (JVM)プロセスで動作しますが、WebLogic Serverドメインの一部であり、WebLogic管理サーバーによって制御されます。スタンドアロン・コロケート・エージェントは、Java仮想マシンがインストールされている任意のサーバーにインストールできますが、WebLogic管理サーバーへの接続が必要です。いずれかのデータ・サーバーに対してローカルであるリソースを使用する必要があるが、すべてのアプリケーションの管理をエンタープライズ・アプリケーション・サーバーで一元化する場合は、このタイプのエージェントが適切です。

11gでは、次のスタンドアロン・コロケート・エージェント構成が可能でした。

- OPMNで管理されないスタンドアロン・コロケート・エージェント。この構成では、アップグレード・アシスタントはWebLogicドメイン・コンポーネント構成の12c (12.2.1.2)へのアップグレードをサポートしていません。

- OPMNで管理されるスタンドアロン・コロケート・エージェント。この構成では、アップグレード・アシスタントはWebLogicドメイン・コンポーネント構成の12c (12.2.1.2)へのアップグレードをサポートしています。

図1-2に、OPMNによって管理されるスタンドアロン・コロケート・エージェントの11g Oracle Data Integrator標準インストール・トポロジと、このガイドのアップグレード手順実行後の12cトポロジを示します。

このトポロジのアップグレード・ロードマップおよび手順は、Oracle Data Integratorスタンドアロン・コロケート・エージェント環境の11gからのアップグレードに示されています。

図1-2 スタンドアロン・コロケート・エージェントのOracle Data Integrator標準アップグレード・トポロジ

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

表1-2 スタンドアロン・コロケート・エージェントの標準アップグレード・トポロジの要素の説明

要素

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

11g Oracle Data Integratorスタンドアロン標準インストール・トポロジ

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

これは、1台のマシン上の単一スタンドアロン・エージェント(OracleDIAgent1)で構成されます。スタンドアロン・エージェントはOPMNによって管理され、WebLogicドメインの一部です。

図に示すように、マスターおよび作業リポジトリのリレーショナル・データベースも必要です。

12c Oracle Data Integratorスタンドアロン標準インストール・トポロジ

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

これは、WebLogicドメイン内に構成された単一スタンドアロン・エージェント(OracleDIAgent1)と、マスターおよび作業リポジトリのリレーショナル・データベースで構成されます。

APPHOST

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

DBHOST

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

WebLogicドメイン

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

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

管理サーバー

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

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

Enterprise Manager

Oracle Enterprise Manager Fusion Middleware Control。

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

スタンドアロン・エージェント

独立したJava仮想マシン(JVM)プロセスで動作するスタンドアロンOracle Data Integratorエージェントです。

11gでは、スタンドアロン・エージェントはインストールの一部として直接作成されます。

システム・コンポーネント

システム・コンポーネントは、WebLogic Management Frameworkで管理されるスタンドアロン・エージェントに対応しています。

1.2.3 Java EEエージェントのOracle Data Integrator標準アップグレード・トポロジ

11gから12c (12.2.1.2)にアップグレードする場合、Java EEエージェントのOracle Data Integratorトポロジはここに示すように更新されます。前の12cリリースからアップグレードする場合、既存のトポロジはそのままです。

Java EEエージェントは、Java EEアプリケーション・サーバー(Oracle WebLogic Serverなど)にWebアプリケーションとしてデプロイされます。Java EEエージェントは、アプリケーション・サーバーのあらゆる機能の恩恵を受けることができます(JDBCデータソースまたはOracle WebLogic Serverのクラスタ化など)。エンタープライズ・アプリケーション・サーバーにおけるすべてのアプリケーションのデプロイおよび管理を集中させる必要がある場合や、高可用性の要件がある場合、このタイプのエージェントが適切です。

図1-3に、11g Oracle Data Integrator Java EE標準インストール・トポロジと、このガイドのアップグレード手順実行後の12cトポロジを示します。

このトポロジのアップグレード・ロードマップおよび手順は、「Oracle Data Integrator Java EEエージェント環境の11gからのアップグレード」に示されています。

図1-3 Java EEエージェントのOracle Data Integrator標準アップグレード・トポロジ

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

表1-3 Java EEエージェントの標準アップグレード・トポロジの要素の説明

要素

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

11g Oracle Data Integrator Java EEトポロジ

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

これは、2つの管理対象サーバーのクラスタ、Java EEエージェントおよび管理サーバーが含まれる単一ドメインで構成されます。また、ドメインには、マスターおよび作業リポジトリ・スキーマのリレーショナル・データベースのほか、Oracle Platform Security Services (OPSS)のLDAPベース・ストアまたはファイル・ストアのいずれかが必要です。

12c Oracle Data Integrator Java EE標準インストール・トポロジ

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

11gトポロジと同様に、2つの管理対象サーバーのクラスタ、Java EEエージェント、管理サーバーのほか、マスターおよび作業リポジトリ・スキーマのデータベースが含まれる単一ドメインで構成されます。

11gトポロジとは異なり、OPSSに使用できるのはLDAPベース・ストアのみであり、ファイルベース・ストアは12cでは使用できません。

APPHOST

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

DBHOST

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

WebLogicドメイン

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

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

管理サーバー

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

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

Enterprise Manager

Oracle Enterprise Manager Fusion Middleware Control。

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

クラスタ

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

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

マシン

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

管理対象サーバー

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

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

Java EEエージェント

Java EEエージェントは、WebLogicドメイン内に構成された管理対象サーバー上にデプロイされ動作するJEEアプリケーションです。

これらのエージェントの詳細およびこれらをOracle Data Integratorトポロジ全体に適合させる方法の詳細は、Oracle Data Integratorでの統合プロジェクトの開発のOracle Data Integratorトポロジの概要を参照してください。

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と同様)。

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

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

- Oracle Application Developer Framework (ADF)

- Oracle Web Services Manager(OWSM)

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

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

1.3 Oracle Data Integrator 12cの新機能について

Oracle Data Integrator 11gと12cの間には複数の変更点があります。

12cの新機能を全般的に理解するには、Oracle Fusion Middleware Oracle Fusion Middlewareの理解の12cの新機能および変更された機能を参照してください。

使用する環境にOracle WebLogic ServerがOracle ADFとともに含まれる場合は、Oracle Fusion Middleware Oracle Fusion Middleware InfrastructureへのアップグレードのApplication Developer 11gとInfrastructure 12cの重要な相違点を参照してください。

Oracle Data Integrator 11gと12cの間には、次の重要な相違点があります。

- WebLogic Management Frameworkによるスタンドアロン・エージェントの管理

- 独自のディレクトリへのスタンドアロン・エージェントのインストール

- リポジトリ・アップグレードでオブジェクト名の一意性が検証される

1.3.1 WebLogic Management Frameworkによるスタンドアロン・エージェントの管理

12cでは、Oracle Data Integratorスタンドアロン・エージェントなどのシステム・コンポーネントはWebLogic Management Frameworkで管理されます。

詳細は、Oracle Fusion Middleware Oracle Fusion Middlewareの理解のWebLogic管理フレームワークとはを参照してください。

1.3.2 独自のディレクトリへのスタンドアロン・エージェントのインストール

12cでは、WebLogic Serverドメイン内に構成されているスタンドアロン・エージェントは、製品インストール・ディレクトリとは別のディレクトリにインストールされます。

詳細は、Oracle Fusion Middleware Oracle Data Integratorのインストールと構成のOracle Data Integratorスタンドアロン・エージェントの標準インストール・トポロジについてを参照してください。

1.3.3 リポジトリ・アップグレードでオブジェクト名の一意性が検証される

12cへのリポジトリ・アップグレード中に、(ネームスペース・ルールに従って)特定数のオブジェクトに対して重複する名前がないかチェックされます。このチェックは実際のアップグレードが開始される前に行われ、重複が検出された場合は、アップグレード・ログ内の重複リストを含むレポートを出力し、アップグレードを停止する必要があります。次に、ODI Studioを使用して11gリポジトリに接続し、手動で(名前変更または削除により)重複を修正した後、アップグレードを再開する必要があります。

12cでは、次のオブジェクトは一意の名前を持つ必要があります。

- インタフェース

- フォルダ

- プロシージャ/KM

注意:

ナレッジ・モジュールは、親スコープ内で一意の名前を持つ必要があります。これは独自プロジェクトのナレッジ・モジュールまたはグローバル・ナレッジ・モジュールに適用されます。

- パッケージ

- プロファイル

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

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

- アップグレード前のチェックリスト
アップグレード前のチェックリストは、アップグレードを成功させて停止時間を少なくするために、アップグレードを開始する前に実行できるタスクを識別します。

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

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

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

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

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

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

- アップグレード・アシスタントを実行する非SYSDBAユーザーの作成
アップグレード・アシスタントを実行するには、FMWと呼ばれる非SYSDBAユーザーを作成することをお薦めします。このユーザーはスキーマの変更に必要な権限は持っていますが、完全な管理者権限は持っていません。

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

- ODIの外部認証の構成
アップグレード・アシスタントを起動する前に、外部認証モードを内部認証に切り替えます。

親トピック: はじめに

2.1 アップグレード前チェックリスト

アップグレード前のチェックリストは、アップグレードを成功させて停止時間を少なくするために、アップグレードを開始する前に実行できるタスクを識別します。

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

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

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

タスク

説明

必須

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

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

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

- バックアップにスキーマ・バージョン・レジストリ表が含まれていることを確認します。スキーマ・バージョン・レジストリ表のバックアップを参照してください。

- 既存のドメインの起動スクリプトを変更した場合、アップグレード中はそれらを一時ディレクトリ(既存のドメイン以外)の場所にコピーし、アップグレード後に再デプロイする必要があります。カスタム・ドメイン環境設定のメンテナンスを参照してください。

オプション

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

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

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

必須

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

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

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

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

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

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

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

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

これは、サポートされていない32ビットのオペレーティング・システムを現在実行している場合のみ必須です。
32ビットから64ビット・オペレーティング・システムへの移行を参照してください。

オプション

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

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

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

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

オプション

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

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

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

Oracle Databaseユーザーのみ必須

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

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

オプション

アップグレード・アシスタントを実行するための非SYSDBAユーザーを作成します。

アップグレード・アシスタントを実行するための、FMWユーザーを作成することをお薦めします。ユーザーFMWは、システム管理者の権限を持たずにアップグレード・アシスタントを実行できます。

アップグレード・アシスタントを実行する非SYSDBAユーザーの作成を参照してください。

オプション

開始する前に、どのスキーマが現在ドメイン内にあるかを特定します。

アップグレードを開始する前に、アップグレード前のドメインにどのスキーマがあるかを確認することが重要です。スキーマ所有者名とパスワード、および各スキーマのバージョンも確認する必要があります。

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

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

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

アップグレードが失敗した場合にSYSTEM.SCHEMA_VERSION_REGISTRY$表の内容をアップグレード前の状態にリストアできるように、バックアップにこの表を含める必要があります。

アップグレード・アシスタントの「前提条件」画面で、実際のアップグレードに進む前に、バックアップが実行されていることを確認するプロンプトが表示されます。ただし、アップグレード・アシスタントではバックアップが作成されたことが確認されない点に注意してください。

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

- Oracle Fusion Middleware Oracle Fusion Middlewareの管理の環境のバックアップ

- Oracle Fusion Middleware Oracle Fusion Middlewareのアップグレードのプランニングの12cのためのOracleデータベースのアップグレードおよび準備

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

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

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

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

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

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

注意:
スキーマ・アップグレードを実行する前にこれらのバックアップを実行することは、アップグレード・アシスタントを実行するための前提条件です。アップグレード中に、バックアップが実行されたことを確認するよう要求されます。

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

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

すべてのドメイン・インストールには、動的に生成されたドメインおよびsetDomainEnvなどのサーバー起動スクリプトがあります。これらのファイルは、インストールおよびアップグレード・プロセス中に新しいバージョンに置き換えられます。カスタムのドメインレベルの環境設定を維持するには、スクリプトを直接変更するかわりに、アップグレードする前に別のファイルを作成してカスタムのドメイン情報を格納することをお薦めします。

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

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

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

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

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

注意:

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3.1 テストのためのOracle Data Integrator本番環境のクローニング

Oracle Data Integrator本番環境のクローニングには、2つの部分のプロセスがあります。

- タスク1: 既存の本番環境のクローニング(またはコピー)。下の例ではAと呼びます。

- タスク2: クローニングした環境でのフル・アップグレードの実行。下の例ではBと呼びます。

タスク1: アップグレードの検証のために既存の本番環境をクローニングします(A)。

1. テスト・マシンに、本番ODIインスタンス・バージョンと一致するODI 11gまたは12cバージョンをインストールします。

a. アップグレード前の環境がODI 11gリリース1の場合は、特定の11gリリースのOracle Data Integratorインストレーション・ガイドを参照してください。

b. アップグレード前の環境が前のODI 12cリリースの場合は、特定の12cリリースのOracle Fusion Middleware Oracle Data Integratorのインストールと構成ガイドを参照してください。

2. 先程インストールした本番バージョンからリポジトリ作成ユーティリティ(RCU)を実行して、新しいODIリポジトリ・スキーマを作成します(B)。非本番スキーマでテストを実行できます。

注意:
ODI 11g本番環境をクローニングする場合:
RCUを使用して新規リポジトリを作成する場合、マスターおよび作業両方のリポジトリIDを入力する必要があります。デフォルトは、0=マスターおよび1=作業です。手順6のリポジトリ・インポートでIDの競合が発生するのを防ぐために、新しいIDは既存の本番リポジトリで使用したIDとは異なるものにしてください。

ODI 12c本番環境をクローニングする場合、その必要はありません。

3. 複数の作業リポジトリがある場合、本番環境と一致する別の作業リポジトリを作成する必要があります。詳細は、インスタンス・リリースの『ODIインストレーション・ガイド』の作業リポジトリの作成を参照してください。

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

5. ODIエクスポート機能を使用して、本番環境からODIマスター・リポジトリおよび作業リポジトリをエクスポートします。Oracle Fusion Middleware Oracle Data Integratorでの統合プロジェクトの開発のマスター・リポジトリのエクスポートおよびインポートを参照してください。

6. ODIマスター・リポジトリおよび作業リポジトリ・エクスポート(手順3で作成した)を、新たに作成したODIスキーマ(手順2で作成した)にインポートします。

これで、テスト環境は本番ODI環境のクローンになりました。

タスク2: クローニングした環境をアップグレードして、アップグレードをテスト(B)

1. アップグレード前チェックリストをレビューして、アップグレード前のすべての要件が満たされていることを確認します。

2. ODI 12c (12.2.1.2)およびその他の製品ディストリビューションを、テスト・マシン上の新しいOracleホームにインストールします。Oracle Fusion Middleware Oracle Data Integratorのインストールと構成のOracle Data Integratorソフトウェアのインストールを参照してください。

3. 環境用の標準的なアップグレード手順に従います。環境に適したアップグレード手順を選択する必要があります。Oracle Data Integrator標準トポロジについてを参照してください。

4. すべてのアップグレード後構成タスクを実行して、アップグレードしたコンポーネントが予想どおりに動作することを確認します。

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.2)の動作保証マトリックスに関する説明を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- (UNIX) DOMAIN_HOME/bin/stopWebLogic.sh

- (Windows) DOMAIN_HOME\bin\stopWebLogic.cmd

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

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

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

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

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

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

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

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

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

- 11gドメイン・ホーム

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

注意:
データベース・バージョンがもうサポートされていない場合は、アップグレードを開始する前にサポートされているバージョンにアップグレードする必要があります。Oracle Fusion Middleware Oracle Fusion Middlewareのアップグレードのプランニングの12cのためのOracleデータベースのアップグレードおよび準備を参照してください

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

Oracle Fusion Middleware製品ディストリビューションをインストールするには、サポートされているJDKをシステムにダウンロードしてインストールする必要があります。

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

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

JDKがサポートされていない場合またはJDKがインストールされていない場合は、次のWebサイトから必要なJava SE JDKをダウンロードする必要があります。

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

JDKは、Oracleホームの外部にインストールしてください。Oracle Universal Installerにより指定されたOracleホーム・ディレクトリが空であることが検証され、空のディレクトリが指定されていなければインストールは行われません。JDKをOracleホームにインストールした場合、今後の操作で問題が発生することがあります。このため、JDKは/home/oracle/products/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 Fusion Middleware Oracle Data Integratorの管理のログのパージを参照してください。

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 アップグレード・アシスタントを実行する非SYSDBAユーザーの作成

アップグレード・アシスタントを実行するには、FMWと呼ばれる非SYSDBAユーザーを作成することをお薦めします。このユーザーはスキーマの変更に必要な権限は持っていますが、完全な管理者権限は持っていません。

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

注意
前のリリースで非SYSDBAユーザーFMWを作成した場合は、アップグレードを開始する前にこのユーザーを削除して再作成する必要があります。古いFMWユーザーを使用してアップグレード・アシスタントを実行すると、新しい権限が追加されてアップグレードが失敗する可能性があります。既存のFMWユーザーを変更するのではなく、削除して再作成することをお薦めします。

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

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

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

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

注意:

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

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

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

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

アップグレード・アシスタントでドメイン内のすべてのスキーマをアップグレードするか、個別のスキーマを選択してアップグレードすることができます。決定しやすくするために、次の手順に従って、アップグレードに使用可能なすべてのスキーマのリストを表示します。

1. Oracle Databaseを使用する場合、Oracle DBA権限を持つアカウントを使用してデータベースに接続し、SQL*Plusから次を実行します。

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

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

3. 既存のスキーマに使用したスキーマ接頭辞名をメモします。新しい12cスキーマの作成時に同じ接頭辞を使用します。

注意

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

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

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

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

2.10 ODIの外部認証の構成

アップグレード・アシスタントを起動する前に、外部認証モードを内部認証に切り替えます。

ODIが外部認証モードで構成されている場合、アップグレード・アシスタントで特定のODI資格証明を認証できるように、アップグレードの前に認証メカニズムを内部認証に切り替える必要があります。アップグレード・プロセスが完了したら、アップグレードした環境でこの外部認証を再度切り替える必要があります。

注意:
これは、外部認証を使用している場合にのみ適用されます。外部認証を使用していない場合は、この手順をスキップします。

Oracle Fusion Middleware Oracle Data Integratorの管理の次のトピックを参照してください。

- 外部認証の構成

- 既存のマスター・リポジトリから外部認証モードへの切替え

第II部 Oracle Data Integratorの11gからのアップグレード

Oracle Fusion Middleware Oracle Data Integratorのアップグレードのこの部では、11gリリースから12c (12.2.1.2)へのOracle Data Integratorのアップグレードに関する情報を提供します。

- Oracle Data Integratorスタンドアロン・エージェント環境の11gからのアップグレード
WebLogicドメイン内に構成されていないOracle Data Integratorスタンドアロン・エージェント環境をOracle Fusion Middleware 11gから12c (12.2.1.2)にアップグレードできます。

- Oracle Data Integratorスタンドアロン・コロケート・エージェント環境の11gからのアップグレード
WebLogicドメイン内に構成されているOracle Data Integratorスタンドアロン・エージェント環境をOracle Fusion Middleware 11gから12c (12.2.1.2)にアップグレードできます。

- Oracle Data Integrator Java EEエージェント環境の11gからのアップグレード
Oracle Data Integrator Java EEエージェント環境をOracle Fusion Middleware 11gから12c (12.2.1.2)にアップグレードできます。

3 Oracle Data Integratorスタンドアロン・エージェント環境の11gからのアップグレード

WebLogicドメイン内に構成されていないOracle Data Integratorスタンドアロン・エージェント環境をOracle Fusion Middleware 11gから12c (12.2.1.2)にアップグレードできます。

- Oracle Data Integratorスタンドアロン・エージェントのアップグレード・プロセスについて
WebLogicドメイン内に構成されていないOracle Data Integratorスタンドアロン・エージェントのアップグレード・プロセスの概要を示すフローチャートおよびロードマップを確認します。

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

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

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

- 製品スキーマのアップグレード
サーバーおよびプロセスを停止した後、アップグレード・アシスタントを使用して、サポートされている製品スキーマを現在のリリースのOracle Fusion Middlewareにアップグレードします。

- スタンドアロン・システム・コンポーネント構成のアップグレード
エージェントがOPMNによって管理される場合、アップグレード・アシスタントを使用してスタンドアロン・エージェントのコンポーネント構成をアップグレードします。スタンドアロン・コンポーネント構成のアップグレードは、OPMNによって管理されないスタンドアロン・エージェントのアップグレードをサポートしていません。

- サーバーおよびプロセスの起動
アップグレードが成功した後、管理サーバーおよび管理対象サーバーを含め、すべてのプロセスおよびサーバーを再起動します。

親トピック: Oracle Data Integratorの11gからのアップグレード

3.1 Oracle Data Integratorスタンドアロン・エージェントのアップグレード・プロセスについて

WebLogicドメイン内に構成されていないOracle Data Integratorスタンドアロン・エージェントのアップグレード・プロセスの概要を示すフローチャートおよびロードマップを確認します。

表3-1 Oracle Data Integratorスタンドアロン・エージェントを11gからアップグレードするためのタスク

タスク

説明

必須

このガイドの概要のトピックをまだ確認していない場合は確認し、必要なアップグレード前のタスクを完了します。

次を参照してください。

- Oracle Data Integratorの12c (12.2.1.2)へのアップグレードの概要

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

必須

Oracle Data Integratorスタンドアロン12c (12.2.1.2)を新しいOracleホームにインストールします。

アップグレードを開始する前に、11g本番デプロイメントと同じホスト上の新しいOracleホームに製品ソフトウェアをインストールします。12cでは、11g Middlewareホームを表現するために、Oracleホームを使用します。

Oracle Data Integratorスタンドアロン・エージェント環境のインストールを参照してください。

必須

リポジトリ作成ユーティリティ(RCU)を起動して、必要な12cデータベース・スキーマを作成します。

STBスキーマを作成します。

必要な12cスキーマの作成を参照してください。

必須

11g環境を停止します(すべての管理サーバーと管理対象サーバーを停止します)。

警告: アップグレード中にサーバーを停止しないと、データが破壊される可能性があります。

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

必須

アップグレード・アシスタントを起動して、11gのデータベース・スキーマをアップグレードし、すべてのアクティブ(進行中の)インスタンス・データを移行します。

製品スキーマのアップグレードを参照してください。

注意: アクティブ・インスタンス・データのアップグレードは、アップグレード・アシスタントの実行中に自動で開始されます。データが正常に新しい12c (12.2.1.2)環境にアップグレードされたら、アップグレード・アシスタントを終了してもかまいません。クローズされたインスタンスのアップグレードは、バックグランド・プロセスで継続されます。

OPMNによって管理される場合は必須

アップグレード・アシスタントを(再度)起動して、スタンドアロン・システム・コンポーネント構成をアップグレードします。

エージェントがOPMNによって管理される場合、アップグレード・アシスタントを実行してスタンドアロン・エージェントのコンポーネント構成をアップグレードします。スタンドアロン・コンポーネント構成のアップグレードは、OPMNによって管理されないスタンドアロン・エージェントのアップグレードをサポートしていません。

スタンドアロン・システム・コンポーネント構成のアップグレードを参照してください。

必須

サーバーおよび12c (12.2.1.2)インスタンスを再起動します。

アップグレード・プロセスが完了したら、12c (12.2.1.2)インスタンスを再起動します。

サーバーおよびプロセスの起動を参照してください。

必須

アップグレードを確認します。

バックアップを削除する前に、アップグレードしたコンポーネントがすべて期待どおりに動作していることを確認します。

3.2 Oracle Data Integratorスタンドアロン・エージェント環境のインストール

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

12c (12.2.1.2)ディストリビューションをインストールする手順は次のとおりです。

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

2. 次の12c (12.2.1.2)製品ディストリビューションをOracle Technology NetworkまたはOracle Software Delivery Cloudからターゲット・システムにダウンロードします。

- Oracle Data Integrator (fmw_12.2.1.2.0_odi_Disk1_1of2.zipおよびfmw_12.2.1.2.0_odi_Disk1_2of2.zip )

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

4. インストールfmw_12.2.1.2.0_odi_Disk1_1of2.zipおよびfmw_12.2.1.2.0_odi_Disk1_2of2.zipファイルを解凍します。

5. 次のコマンドを入力して製品ディストリビューションのインストーラを起動し、前述の手順を繰り返してインストーラの各画面を移動します。
(UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.2.0_odi_generic.jar

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

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

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

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

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

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

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

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

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

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

10. 「インストール・タイプ」画面で、「スタンドアロン・インストール」を選択します。
「次へ」をクリックします。

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

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

13. 「インストールの進行状況」画面で進捗バーが100%になったら、「終了」をクリックしてインストーラを閉じるか、「次へ」をクリックしてサマリーを確認します。

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

3.3 必要な12cスキーマの作成

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

このガイドで説明するODI環境では、必須のスキーマは次のとおりです。

- ODIスタンドアロン・エージェント(WebLogicドメインなし): STB

- ODIスタンドアロン・コロケート・エージェント(WebLogicドメインあり): STB、OPSS、IAU、IAU_VIEWERおよびIAU_APPEND

- ODI Java EEエージェント: STB、OPSS、IAU、IAU_VIEWERおよびIAU_APPEND

注意:
Oracle Fusion Middlewareの前の12cリリースからアップグレードする場合、これらのスキーマがすでに存在する場合には再作成する必要はありません。ドメインの既存のスキーマを特定するには、次の手順を参照してください。

11gからアップグレードする場合は、「アップグレード前チェックリスト」を参照して、ドメイン内の既存のスキーマを特定します。12cにアップグレードする前に、次のスキーマが存在している必要があります。

- サービス表スキーマ(prefix_STB)。このスキーマは12cで新規のものであり、ドメインベースのアップグレードに必要になります。基本的なスキーマ構成情報(スキーマ接頭辞やパスワードなど)が格納され、他のOracle Fusion Middlewareコンポーネントはドメイン作成中にこれにアクセスして使用できます。このスキーマはリポジトリ作成ユーティリティ(RCU)を実行するときに自動的に作成され、ここで他の11gスキーマに使用した既存のスキーマ所有者接頭辞を指定します。注意: サービス表スキーマが存在しない場合、UPGAST-00328: スキーマ・バージョンのレジストリ表はこのデータベースに存在しません。その場合、アップグレード・アシスタントを実行するためにはサービス表スキーマを作成する必要があります。というエラー・メッセージが表示されることがあります。

- Oracle Platform Security Services (OPSS)スキーマ(prefix_OPSS)。このスキーマは、11gでOIDベースのセキュリティ・ストアを使用している場合に必要です。このスキーマは、リポジトリ作成ユーティリティ(RCU)を実行するときに自動的に作成されます。LDAPベースのOPSSセキュリティ・ストアでサポートされているのは、Oracle Internet Directory (OID)のみです。LDAPベースのポリシー・ストアは、通常、本番環境で使用します。アップグレード前に、OIDベースのセキュリティ・ストアを再関連付けする必要はありません。アップグレード・アシスタントの実行中に、OPSSスキーマを選択できます。アップグレード・アシスタントは、OIDベースのセキュリティ・ストアを自動的にアップグレードします。注意: 12c OPSSデータベース・スキーマが必要なのは、ドメインの再構成時に12cスキーマを参照するためです。ドメインでは、アップグレード完了後にOIDベースのセキュリティ・ストアが引き続き使用されます。

- 監査スキーマ。監査サービス(_IAU)をアップグレードする場合、_IAUに加えて、_IAU_VIEWERおよび_IAU_APPENDを必ず選択します。これらを選択したときに、アップグレード・アシスタントによって自動的に作成されます。

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

1. (オプション) 11gからアップグレードし、既存のドメインにどのスキーマが存在しているかを確認するには、DBA権限を持つユーザーとしてデータベースに接続し、SQL*Plusから次のコードを実行します。

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

2. コマンドラインからjava -versionを実行して、動作保証されたJDKがすでにシステムにあることを確認します。12c (12.2.1.2)では、動作保証されたJDKは1.8.0_101以上です。
JAVA_HOME環境変数が、動作保証されたJDKの場所に設定されていることを確認します。次に例を示します。

- (UNIX) setenv JAVA_HOME /home/Oracle/Java/jdk1.8.0_101

- (Windows) set JAVA_HOME=C:\home\Oracle\Java\jdk1.8.0_101

$JAVA_HOME/binを$PATHに追加します。

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

- (UNIX) ORACLE_HOME/oracle_common/bin

- (Windows) ORACLE_HOME\oracle_common\bin

4. RCUを起動します。

- (UNIX) ./rcu

- (Windows) rcu.bat

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

6. 「リポジトリの作成」画面で「リポジトリの作成」を選択し、「システム・ロードおよび製品ロード」を選択します。
DBA権限を持っていない場合は、「システム・ロードに対するスクリプトの準備」を選択します。これによって、RCUが選択されたコンポーネントに対してアクションを実行した場合にコールされるSQL文およびブロックと同じものを、すべて含むSQLスクリプトが生成されます。このスクリプトが生成された後は、必要なSYSまたはSYSDBA権限を持つユーザーが、このスクリプトを実行してシステム・ロード・フェーズを完了できます。
「次へ」をクリックします。

7. 「データベース接続の詳細」画面で、「データベース・タイプ」を選択し、11gスキーマをホストするデータベースの接続情報を入力します。次の該当する表を参照してください。

表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形式で指定します。
MSSQL指定インスタンス: 指定インスタンスは、コンピュータのネットワーク名とインストール中に指定したインスタンス名によって識別されます。クライアントは接続時にサーバー名とインスタンス名の両方を指定する必要があります。

ポート

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

データベース名

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

ユーザー名

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

パスワード

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

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

オプション

説明および例

サーバー名

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

ポート

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

データベース名

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

ユーザー名

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

パスワード

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

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

8. 「コンポーネントの選択」画面で、「既存の接頭辞の選択」を選択し、ドロップダウン・メニューから既存の11gスキーマの作成に使用した接頭辞(たとえば、DEV11G)を選択します。この接頭辞は、スキーマをこのドメインで使用するために論理的にまとめてグループ化するために使用されます。
注意: デフォルトで、Common Infrastructure Services Table (prefix_STB)およびOracle Platform Security Services (prefix_OPSS)スキーマが選択されます(それらがまだ作成されていない場合)。

インストールするコンポーネントの接頭辞とスキーマ名を書き留めます。インストールの構成時にこの情報が必要になります。「次へ」をクリックします。

9. 「前提条件チェック」ダイアログで、前提条件チェックが正常であることを確認し、「OK」をクリックします。

10. 「スキーマ・パスワード」画面で、スキーマの所有者のパスワードを入力します。
この画面で入力したパスワードを書き留めてください。製品インストールの構成中に必要となります。

11. 「表領域のマップ」画面で、作成するスキーマの目的の表領域マッピングを構成します。
「次へ」をクリックして、確認ダイアログで「OK」をクリックします。進行状況ダイアログに表領域の作成が完了したことが示されたら、「OK」をクリックします。

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

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

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

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

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

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

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

Fusion Middleware環境を停止するには、次の手順に従います。

手順1: システム・コンポーネントの停止

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

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

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

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

手順2: 管理対象サーバーの停止

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

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

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

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

手順3: Oracle Identity Managementコンポーネントの停止環境を構成しているOracle Internet DirectoryなどのOracle Identity Managementコンポーネントがあれば、それをすべて停止します。

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

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

ステップ4: 管理サーバーの停止

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

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

- (UNIX) DOMAIN_HOME/bin/stopWebLogic.sh

- (Windows) DOMAIN_HOME\bin\stopWebLogic.cmd

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

注意:
リポジトリ用に外部のパスワード記憶域が設定されている場合は、アップグレード中に作業リポジトリのパスワードを取得できるように、資格証明ストアをホストしているサーバーが稼働している必要があります。詳細は、Oracle Fusion Middleware Oracle Data Integratorの管理の外部パスワード記憶域の設定を参照してください。

手順5: ノード・マネージャの停止

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

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

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

サーバーおよびプロセスを停止した後、アップグレード・アシスタントを使用して、サポートされている製品スキーマを現在のリリースのOracle Fusion Middlewareにアップグレードします。

アップグレード・アシスタントを使用すると、個別に選択したスキーマまたはドメインに関連付けられているすべてのスキーマをアップグレードできます。選択したオプションによって、表示されるアップグレード・アシスタントの画面は異なります。

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

- アップグレード・アシスタントを使用した製品スキーマのアップグレード
アップグレード・アシスタントの各画面を移動して、製品スキーマをアップグレードします。

- スキーマ・アップグレードの確認
すべてのアップグレード手順の完了後、schema_version_registryのスキーマ・バージョンが正しく更新されたことを確認して、アップグレードが成功したことを確認します。

3.5.1 Upgrade Assistantの起動

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

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

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

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. アップグレード・アシスタントを起動します。

- (UNIX) ./ua

- (Windows) ua.bat

ロギング・パラメータなど、コマンドラインで指定できるその他のパラメータの詳細は、次を参照してください。

- アップグレード・アシスタントのコマンドライン・パラメータ

3.5.1.1 アップグレード・アシスタントのコマンドライン・パラメータ

コマンドラインからアップグレード・アシスタントを起動するとき、追加パラメータを指定できます。

表3-6 アップグレード・アシスタントのコマンドライン・パラメータ

パラメータ

必須またはオプション

説明

-readiness

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

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

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

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

-threads

オプション

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

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

-response

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

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

-examine

オプション

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

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

-logLevel 属性

オプション

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

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

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

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

-logDir 場所

オプション

アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。アップグレード・アシスタントによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

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

(UNIX) ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

(Windows) ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

オプション

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

3.5.2 アップグレード・アシスタントを使用した製品スキーマのアップグレード

アップグレード・アシスタントの各画面を移動して、製品スキーマをアップグレードします。

注意

- 外部認証を使用している場合は、外部認証が内部認証に変更されていることを確認してください。

- エディションベースの再定義(EBR)ユーザーのみ: エディション・ベースの再定義(EBR)に対応したスキーマをアップグレードする前に、データベース・サーバーに接続して、12cのデータベース・サーバーにエディションを作成する必要があります。12cの新しいエディションは、既存の11cエディションの子である必要があります。再定義のためのサーバーでのエディション作成の詳細は、エディションベースの再定義のためのサーバー上でのエディションの作成を参照してください。

アップグレード・アシスタントで製品スキーマをアップグレードする手順は次のとおりです。

1. 「ようこそ」画面で、アップグレード・アシスタントの概要と、重要なアップグレード前のタスクに関する情報を確認します。「次へ」をクリックします

注意:
アップグレード・アシスタント画面の詳細は、画面で「ヘルプ」をクリックしてください。

2. 「選択したスキーマ」画面で、「個別に選択されたスキーマ」を選択します。

注意:
12c (12.2.1.2)コンポーネントをサポートするために使用されるスキーマのみをアップグレードしてください。Oracle Fusion Middleware 12c (12.2.1.2)に含まれていないコンポーネントをサポートするために現在使用されているスキーマはアップグレードしないでください。

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

3. 「使用可能なコンポーネント」画面で、マスターおよび作業リポジトリ・スキーマをアップグレードするために「Oracle Data Integrator」を選択します。

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

注意:
アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。

5. ODIスキーマ画面で、アップグレードする各スキーマのデータベース接続の詳細を指定します。

- 「データベース・タイプ」ドロップダウン・メニューからデータベース・タイプを選択します。

- データベース接続の詳細を入力して、「接続」をクリックします。

- 「スキーマ・ユーザー名」ドロップダウン・メニューからアップグレードするスキーマを選択し、スキーマのパスワードを入力します。アップグレードするスキーマに対して正しいスキーマ接頭辞を使用してください。

6. 「ODIオプション」画面で、すべてのオプションを選択します。

表3-7 ODIのオプション

オプション

説明

ナレッジ・モジュールを必須更新で置換

これを選択すると、標準ナレッジ・モジュールが最新バージョンに置き換えられます。Oracleによりインストールされたナレッジ・モジュールに対するカスタマイズ内容は上書きされます。ただし、インストールされたナレッジ・モジュールをコピーしてからそのナレッジ・モジュールをカスタマイズした場合、カスタマイズ内容は失われません。

トポロジおよびセキュリティ・メタデータのアップグレード

これを選択すると、テクノロジ、データ型、セキュリティ・プロファイルなどのトポロジおよびセキュリティ・アーティファクトが最新バージョンに置き換えられます。インストールされたオブジェクトのカスタマイズ内容は上書きされます。オブジェクトをコピーしてからカスタマイズした場合、カスタマイズ内容は失われません。

高度なアップグレード・オプションの詳細は、「高度なアップグレード・オプション」を参照してください。

7. 「ODIスーパーバイザ」画面に、アップグレードするODIリポジトリのスーパーバイザ・アカウント資格証明を入力します。

インストールされているスーパーバイザ・アカウントはSUPERVISORです。ODIのマスター・リポジトリおよび作業リポジトリの作成時にリポジトリ作成ユーティリティ(RCU)で求められたときに指定した、正しいスーパーバイザ・アカウント名およびパスワードについては、ODI管理者に確認してください。

注意:
「ドメインで使用されるすべてのスキーマ」が選択されている場合、ODIのスーパーバイザ資格証明はドメインに含まれていないため、最初のインスタンスにあらかじめ移入されません。複数のODIスキーマがある場合、アップグレード・アシスタントは最初の資格証明のセットを使用してユーザー・エントリに移入します。

8. 「ODIアップグレード・キー」画面で、自動生成されたアップグレード・キーを使用して、リポジトリ・オブジェクトの11g IDを一意のGUIDに変換するか、独自のキーを「アップグレード・キー」フィールドに指定します。

推奨事項

- 自動生成されたキーを編集して、覚えやすい意味のあるキーを指定します。

- ODIオブジェクトがXMLファイルからインポートされるときに同じアップグレード・キーを指定できるように、アップグレード・キーを書き留めます。

ODIオブジェクトは、ODIリポジトリ、ならびにこうしたリポジトリからエクスポートされたXMLファイルに存在し、リポジトリ間のメタデータ交換などで使用できます。そのため、同一オブジェクトの複数のコピーが異なるリポジトリおよびXMLファイルに含まれる場合があります。

12cでは、ODIはオブジェクト識別に数字の内部IDではなくGUIDを使用します。アップグレード後にオブジェクトIDが保持されるようにするため、決定性アルゴリズムが適用され、既存のオブジェクトの内部IDからGUIDが計算されます(新規オブジェクトの場合、ODIにより無作為のGUIDが生成されます)。

数字の内部IDが実際にはユニバーサルに一意ではなく、疑似的な一意性を実現するためにリポジトリIDに依存していたため、ODIではユーザーがアップグレード・キーを指定して、重複したGUIDが生成される可能性を下げることができます。アップグレード・キーが数字の内部IDとともにGUID生成アルゴリズムに提供され、GUIDが計算されます。

このように異なるアップグレード・キーを選択することで、偶然同じ数字の内部IDを持つオブジェクトについて重複したGUIDを取得せずに済みます。ただし、同じオブジェクトの複数のコピーが(リポジトリ内に、またはXMLファイルにエクスポートされて)存在する場合、オブジェクトのすべてのコピーに対して同じGUIDが生成される必要があります。そのため、その特定のオブジェクトのコピーに関係するすべてのアップグレード操作に対して、同じアップグレード・キーを使用する必要があります。

たとえば、11gリポジトリにIDとして1001を持つプロジェクトがあり、また同じリポジトリからエクスポートされたファイルに、同じプロジェクト(ID = 1001)が含まれるとします。この場合、リポジトリのアップグレードに使用されるアップグレード・キーは、アップグレード済の12cリポジトリにXMLファイルをインポートする際に使用されるアップグレード・キーと同じである必要があります。これによって、インポート・ファイルのプロジェクト・オブジェクトは、リポジトリのプロジェクト・オブジェクトと正しく一致します(いずれかのSYNONYMインポート・モードを使用した場合)。ただし、別のリポジトリで作成されたオブジェクトを含むソースから11g XMLエクスポート・ファイルが提供され、そのリポジトリの情報がない場合、偶然同じ内部ID (1001)を持つプロジェクトが含まれている可能性があります。この場合、誤ったオブジェクトの一致によるメタデータの破損を防ぐため、そのファイルをリポジトリにインポートする際には、別のカスタム・アップグレード・キーを使用する必要があります。

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

注意:

- 調査フェーズの間に、アップグレードを続行せずに検出された問題を解決した場合は、バックアップからリストアすることなしに、アップグレード・アシスタントを再起動できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックして続行した場合は、アップグレード・アシスタントを再起動する前に、アップグレード前の環境をバックアップからリストアする必要があります。

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

10. 「アップグレード・サマリー」画面で、スキーマ・アップグレードに選択したオプションのサマリーを確認します。
正しいソース・バージョンとターゲット・バージョンが、アップグレード対象の各スキーマにリストされていることを確認します。

後でアップグレード・アシスタントをレスポンス(またはサイレント)モードで再び実行するためにこれらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックして、レスポンス・ファイルの場所および名前を指定します。サイレント・アップグレードは、アップグレード・アシスタント・とまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。

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

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

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

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

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

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

12. アップグレードが成功した場合、「アップグレード成功」画面で「閉じる」をクリックし、アップグレードを完了してウィザードを閉じます。

アップグレードが失敗した場合、「アップグレード失敗」画面で「ログの表示」をクリックし、エラーを表示してトラブルシューティングします。ログはORACLE_HOME/oracle_common/upgrade/logsにあります。

注意:
アップグレードに失敗した場合、アップグレード前の環境をバックアップからリストアし、問題を修正して、アップグレード・アシスタントを再起動する必要があります。

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

すべてのアップグレード手順の完了後、schema_version_registryのスキーマ・バージョンが正しく更新されたことを確認して、アップグレードが成功したことを確認します。

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

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

問合せ結果:

- VERSION列の数値が、そのスキーマの最新のバージョン番号に一致していることを確認します。たとえば、スキーマ・バージョン番号が12.2.1.2.0であることを確認します。ただし、すべてのスキーマ・バージョンが更新されるわけではないことに注意してください。一部のスキーマではこのリリースへのアップグレードが必要なく、アップグレード前のバージョン番号が保持されます。

- STATUSフィールドは、スキーマのパッチ適用操作中は「UPGRADING」または「UPGRADED」に、操作が完了すると「VALID」になります。

- ステータスが「INVALID」と表示された場合は、ステータスの更新が失敗しています。ログ・ファイルを調べて、失敗した理由を判定する必要があります。

- IAU_APPENDおよびIAU_VIEWERによって所有されるシノニム・オブジェクトは、INVALIDとして表示されますが、失敗を示すものではありません。
それらは、シノニムの作成後にターゲット・オブジェクトが変更されるため無効になります。シノニム・オブジェクトはアクセスされると有効になります。これらのINVALIDオブジェクトは無視しても問題ありません。

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

エージェントがOPMNによって管理される場合、アップグレード・アシスタントを使用してスタンドアロン・エージェントのコンポーネント構成をアップグレードします。スタンドアロン・コンポーネント構成のアップグレードは、OPMNによって管理されないスタンドアロン・エージェントのアップグレードをサポートしていません。

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

- アップグレード・アシスタントを使用したスタンドアロン・システム・コンポーネント構成のアップグレード
アップグレード・アシスタントの各画面を移動して、スタンドアロン・システム・コンポーネント構成をアップグレードします。

3.6.1 Upgrade Assistantの起動

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

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

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

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. アップグレード・アシスタントを起動します。

- (UNIX) ./ua

- (Windows) ua.bat

ロギング・パラメータなど、コマンドラインで指定できるその他のパラメータの詳細は、次を参照してください。

- アップグレード・アシスタントのコマンドライン・パラメータ

3.6.1.1 アップグレード・アシスタントのコマンドライン・パラメータ

コマンドラインからアップグレード・アシスタントを起動するとき、追加パラメータを指定できます。

表3-8 アップグレード・アシスタントのコマンドライン・パラメータ

パラメータ

必須またはオプション

説明

-readiness

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

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

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

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

-threads

オプション

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

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

-response

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

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

-examine

オプション

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

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

-logLevel 属性

オプション

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

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

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

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

-logDir 場所

オプション

アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。アップグレード・アシスタントによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

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

(UNIX) ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

(Windows) ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

オプション

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

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

アップグレード・アシスタントの各画面を移動して、スタンドアロン・システム・コンポーネント構成をアップグレードします。

注意:
エージェントがOPMNによって管理される場合のみ、アップグレード・アシスタントを使用してスタンドアロン・エージェントのコンポーネント構成をアップグレードします。スタンドアロン・コンポーネント構成のアップグレードは、OPMNによって管理されないスタンドアロン・エージェントのアップグレードをサポートしていません。

アップグレード・アシスタントを使用してスタンドアロン・システム・コンポーネント構成をアップグレードする手順は次のとおりです。

1. 「ようこそ」画面で、アップグレード・アシスタントの概要と、重要なアップグレード前のタスクに関する情報を確認します。「次へ」をクリックします

注意:
アップグレード・アシスタント画面の詳細は、画面で「ヘルプ」をクリックしてください。

2. 次の画面で次のようにします。

- 「スタンドアロン・システム・コンポーネント構成」を選択し、「新規ドメインの作成」を選択します。

注意:
12cより、スタンドアロン・システム・コンポーネントには、独自のスタンドアロン・ドメインがそれぞれ作成されます。11gスタンドアロン・システム・コンポーネント(以前にドメインの関連付けをしていない)をアップグレードする場合、最初にシステム・コンポーネントに新規スタンドアロン・ドメインを作成する必要があります。

- 「ドメイン・ディレクトリ」フィールドで、作成するドメインのフルパスを指定します。ドメイン・ホームがOracleホーム・ディレクトリの外部にある場合、Oracle Fusion Middleware Oracle Fusion Middlewareのインストールのプランニングの推奨ディレクトリ構造の理解に要約されているディレクトリ構造に従ってドメイン・ホームを配置することをお薦めします。このディレクトリ構造は、ソフトウェアのアップグレードや再インストールが必要になったときに問題を回避するために役立ちます。

ヒント:
「既存のドメインの更新」オプションは、別のシステム・コンポーネントのアップグレードまたは以前の部分的なOracle Data Integratorアップグレードのいずれかにより、アップグレードがすでに実行され、ドメインが作成されている場合に使用できます。このような場合、新規ドメインの作成が不要となります。

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

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

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

注意:
アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。

5. 「インスタンス・ディレクトリ」画面で、アップグレード対象となる1つ以上のOracleインスタンス・ディレクトリの場所を指定します。

6. 「ノード・マネージャ」画面で、スタンドアロン・システム・コンポーネントのアップグレード時にドメインの作成に使用されるノード・マネージャの資格証明を指定します。

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

注意:

- 調査フェーズの間に、アップグレードを続行せずに検出された問題を解決した場合は、バックアップからリストアすることなしに、アップグレード・アシスタントを再起動できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックして続行した場合は、アップグレード・アシスタントを再起動する前に、アップグレード前の環境をバックアップからリストアする必要があります。

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

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

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

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

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

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

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

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

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

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

3.7 サーバーおよびプロセスの起動

アップグレードが成功した後、管理サーバーおよび管理対象サーバーを含め、すべてのプロセスおよびサーバーを再起動します。

これらのコンポーネントは相互に依存する場合があるため、正しい順序で起動する必要があります。

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

Fusion Middleware環境を起動するには、次の手順に従います。

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

管理サーバーを起動する場合、管理サーバーで稼働しているWebLogic Server管理コンソールやFusion Middleware Controlなどのプロセスも起動します。

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

- (UNIX) DOMAIN_HOME/bin/startWebLogic.sh

- (Windows) DOMAIN_HOME\bin\startWebLogic.cmd

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

手順2: ノード・マネージャの起動

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

- (UNIX) DOMAIN_HOME/bin/startNodeManager.sh

- (Windows) DOMAIN_HOME\bin\startNodeManager.cmd

手順3: Oracle Identity Managementコンポーネントの起動環境を構成しているOracle Internet DirectoryなどのOracle Identity Managementコンポーネントがあれば、それをすべて起動します。

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

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

手順4: 管理対象サーバーの起動

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

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

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

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

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

手順5: システム・コンポーネントの起動

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

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

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

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

4 Oracle Data Integratorスタンドアロン・コロケート・エージェント環境の11gからのアップグレード

WebLogicドメイン内に構成されているOracle Data Integratorスタンドアロン・エージェント環境をOracle Fusion Middleware 11gから12c (12.2.1.2)にアップグレードできます。

- Oracle Data Integratorスタンドアロン・コロケート・エージェントのアップグレード・プロセスについて
WebLogicドメイン内に構成されているOracle Data Integratorスタンドアロン・エージェントのアップグレード・プロセスの概要を示すプロセス・フローチャートを確認します。

- Oracle Data Integratorスタンドアロン・コロケート・エージェント環境のインストール
アップグレードを開始する前に、Oracle Fusion Middleware InfrastructureおよびOracle Data Integrator 12c (12.2.1.2)ディストリビューションをターゲット・システムにダウンロードし、Oracle Universal Installerを使用してインストールします。

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

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

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

- 製品スキーマのアップグレード
サーバーおよびプロセスを停止した後、アップグレード・アシスタントを使用して、サポートされている製品スキーマを現在のリリースのOracle Fusion Middlewareにアップグレードします。

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

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

- サーバーおよびプロセスの起動
アップグレードが成功した後、管理サーバーおよび管理対象サーバーを含め、すべてのプロセスおよびサーバーを再起動します。

親トピック: Oracle Data Integratorの11gからのアップグレード

4.1 Oracle Data Integratorスタンドアロン・コロケート・エージェントのアップグレード・プロセスについて

WebLogicドメイン内に構成されているOracle Data Integratorスタンドアロン・エージェントのアップグレード・プロセスの概要を示すプロセス・フローチャートを確認します。

表4-1 Oracle Data Integratorスタンドアロン・コロケート・エージェントを11gからアップグレードするためのタスク

タスク

説明

必須

このガイドの概要のトピックをまだ確認していない場合は確認し、必要なアップグレード前のタスクを完了します。

次を参照してください。

- Oracle Data Integratorの12c (12.2.1.2)へのアップグレードの概要

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

必須

Oracle Fusion Middleware InfrastructureおよびOracle Data Integrator 12c (12.2.1.2)を新しいOracleホームにインストールします。

Oracle Data Integratorスタンドアロン・コロケート・エージェント環境のインストールを参照してください。

必須

リポジトリ作成ユーティリティ(RCU)を起動して、必要な12cデータベース・スキーマを作成します。

STB、OPSS、IAU、IAU_VIEWERおよびIAU_APPENDスキーマを作成します。

必要な12cスキーマの作成を参照してください。

オプション

アップグレード前の準備状況チェックを実行します。

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

必須

11g環境を停止します(すべての管理サーバーと管理対象サーバーを停止します)。

警告: アップグレード中にサーバーを停止しないと、データが破壊される可能性があります。

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

必須

アップグレード・アシスタントを起動して、11gのデータベース・スキーマをアップグレードし、すべてのアクティブ(進行中の)インスタンス・データを移行します。

製品スキーマのアップグレードを参照してください。

注意: アクティブ・インスタンス・データのアップグレードは、アップグレード・アシスタントの実行中に自動で開始されます。データが正常に新しい12c (12.2.1.2)環境にアップグレードされたら、アップグレード・アシスタントを終了してもかまいません。クローズされたインスタンスのアップグレードは、バックグランド・プロセスで継続されます。

必須

再構成ウィザードを起動して、ドメインとノード・マネージャを再構成します。

構成ウィザードを実行して、既存のドメインを更新して新しくインストールしたソフトウェアを使用します。

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

必須

アップグレード・アシスタントを(再度)起動して、ドメイン構成をアップグレードします。

アップグレード・アシスタントを実行して、再構成したドメインのコンポーネント構成をアップグレードします。ドメイン・コンポーネント構成のアップグレードは、OPMNによって管理されないスタンドアロン・エージェントのアップグレードをサポートしていません。

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

必須

サーバーおよび12c (12.2.1.2)インスタンスを再起動します。

アップグレード・プロセスが完了したら、12c (12.2.1.2)インスタンスを再起動します。

サーバーおよびプロセスの起動を参照してください。

必須

アップグレードを確認します。

バックアップを削除する前に、アップグレードしたコンポーネントがすべて期待どおりに動作していることを確認します。

4.2 Oracle Data Integratorスタンドアロン・コロケート・エージェント環境のインストール

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

注意:
アップグレードにInfrastructureが必要な場合、他のFusion Middleware製品をインストールする前に、まずOracle Fusion Middleware Infrastructureディストリビューションをインストールする必要があります。

12c (12.2.1.2)ディストリビューションをインストールする手順は次のとおりです。

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

2. 次の12c (12.2.1.2)製品ディストリビューションをOracle Technology NetworkまたはOracle Software Delivery Cloudからターゲット・システムにダウンロードします。

- Oracle Fusion Middleware Infrastructure (fmw_12.2.1.2.0_infrastructure_generic.jar)

- Oracle Data Integrator (fmw_12.2.1.2.0_odi_Disk1_1of2.zipおよびfmw_12.2.1.2.0_odi_Disk1_2of2.zip )

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

4. インストールfmw_12.2.1.2.0_odi_Disk1_1of2.zipおよびfmw_12.2.1.2.0_odi_Disk1_2of2.zipファイルを解凍します。

5. Oracle Fusion Middleware Infrastructureのインストール・プログラムを起動します。

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

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

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

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

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

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

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

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

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

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

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

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

- Infrastructureには、「Fusion Middlewareインフラストラクチャ」を選択します

- Oracle Data Integratorには、「エンタープライズ・インストール」を選択します

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

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

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

13. 「インストールの進行状況」画面で進捗バーが100%になったら、「終了」をクリックしてインストーラを閉じるか、「次へ」をクリックしてサマリーを確認します。

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

15. Oracle Fusion Middleware Infrastructureをインストールした後、次のコマンドを入力して製品ディストリビューションのインストーラを起動し、前述の手順を繰り返してインストーラの各画面を移動します。
(UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.2.0_odi_generic.jar

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

4.3 必要な12cスキーマの作成

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

このガイドで説明するODI環境では、必須のスキーマは次のとおりです。

- ODIスタンドアロン・エージェント(WebLogicドメインなし): STB

- ODIスタンドアロン・コロケート・エージェント(WebLogicドメインあり): STB、OPSS、IAU、IAU_VIEWERおよびIAU_APPEND

- ODI Java EEエージェント: STB、OPSS、IAU、IAU_VIEWERおよびIAU_APPEND

注意:
Oracle Fusion Middlewareの前の12cリリースからアップグレードする場合、これらのスキーマがすでに存在する場合には再作成する必要はありません。ドメインの既存のスキーマを特定するには、次の手順を参照してください。

11gからアップグレードする場合は、「アップグレード前チェックリスト」を参照して、ドメイン内の既存のスキーマを特定します。12cにアップグレードする前に、次のスキーマが存在している必要があります。

- サービス表スキーマ(prefix_STB)。このスキーマは12cで新規のものであり、ドメインベースのアップグレードに必要になります。基本的なスキーマ構成情報(スキーマ接頭辞やパスワードなど)が格納され、他のOracle Fusion Middlewareコンポーネントはドメイン作成中にこれにアクセスして使用できます。このスキーマはリポジトリ作成ユーティリティ(RCU)を実行するときに自動的に作成され、ここで他の11gスキーマに使用した既存のスキーマ所有者接頭辞を指定します。注意: サービス表スキーマが存在しない場合、UPGAST-00328: スキーマ・バージョンのレジストリ表はこのデータベースに存在しません。その場合、アップグレード・アシスタントを実行するためにはサービス表スキーマを作成する必要があります。というエラー・メッセージが表示されることがあります。

- Oracle Platform Security Services (OPSS)スキーマ(prefix_OPSS)。このスキーマは、11gでOIDベースのセキュリティ・ストアを使用している場合に必要です。このスキーマは、リポジトリ作成ユーティリティ(RCU)を実行するときに自動的に作成されます。LDAPベースのOPSSセキュリティ・ストアでサポートされているのは、Oracle Internet Directory (OID)のみです。LDAPベースのポリシー・ストアは、通常、本番環境で使用します。アップグレード前に、OIDベースのセキュリティ・ストアを再関連付けする必要はありません。アップグレード・アシスタントの実行中に、OPSSスキーマを選択できます。アップグレード・アシスタントは、OIDベースのセキュリティ・ストアを自動的にアップグレードします。注意: 12c OPSSデータベース・スキーマが必要なのは、ドメインの再構成時に12cスキーマを参照するためです。ドメインでは、アップグレード完了後にOIDベースのセキュリティ・ストアが引き続き使用されます。

- 監査スキーマ。監査サービス(_IAU)をアップグレードする場合、_IAUに加えて、_IAU_VIEWERおよび_IAU_APPENDを必ず選択します。これらを選択したときに、アップグレード・アシスタントによって自動的に作成されます。

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

1. (オプション) 11gからアップグレードし、既存のドメインにどのスキーマが存在しているかを確認するには、DBA権限を持つユーザーとしてデータベースに接続し、SQL*Plusから次のコードを実行します。

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

2. コマンドラインからjava -versionを実行して、動作保証されたJDKがすでにシステムにあることを確認します。12c (12.2.1.2)では、動作保証されたJDKは1.8.0_101以上です。
JAVA_HOME環境変数が、動作保証されたJDKの場所に設定されていることを確認します。次に例を示します。

- (UNIX) setenv JAVA_HOME /home/Oracle/Java/jdk1.8.0_101

- (Windows) set JAVA_HOME=C:\home\Oracle\Java\jdk1.8.0_101

$JAVA_HOME/binを$PATHに追加します。

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

- (UNIX) ORACLE_HOME/oracle_common/bin

- (Windows) ORACLE_HOME\oracle_common\bin

4. RCUを起動します。

- (UNIX) ./rcu

- (Windows) rcu.bat

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

6. 「リポジトリの作成」画面で「リポジトリの作成」を選択し、「システム・ロードおよび製品ロード」を選択します。
DBA権限を持っていない場合は、「システム・ロードに対するスクリプトの準備」を選択します。これによって、RCUが選択されたコンポーネントに対してアクションを実行した場合にコールされるSQL文およびブロックと同じものを、すべて含むSQLスクリプトが生成されます。このスクリプトが生成された後は、必要なSYSまたはSYSDBA権限を持つユーザーが、このスクリプトを実行してシステム・ロード・フェーズを完了できます。
「次へ」をクリックします。

7. 「データベース接続の詳細」画面で、「データベース・タイプ」を選択し、11gスキーマをホストするデータベースの接続情報を入力します。次の該当する表を参照してください。

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

オプション

説明および例

ホスト名

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

examplehost.exampledomain.com

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

ポート

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

サービス名

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

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

examplehost.exampledomain.com

ユーザー名

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

パスワード

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

ロール

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

「標準」または「SYSDBA」

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

オプション

説明および例

ホスト名

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

ポート

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

データベース名

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

ユーザー名

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

パスワード

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

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

オプション

説明および例

Unicodeのサポート

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

サーバー名

データベースが稼働しているサーバーのホスト名、IPアドレスまたは詳細なサーバー名を、host\server形式で指定します。
MSSQL指定インスタンス: 指定インスタンスは、コンピュータのネットワーク名とインストール中に指定したインスタンス名によって識別されます。クライアントは接続時にサーバー名とインスタンス名の両方を指定する必要があります。

ポート

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

データベース名

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

ユーザー名

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

パスワード

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

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

オプション

説明および例

サーバー名

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

ポート

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

データベース名

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

ユーザー名

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

パスワード

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

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

8. 「コンポーネントの選択」画面で、「既存の接頭辞の選択」を選択し、ドロップダウン・メニューから既存の11gスキーマの作成に使用した接頭辞(たとえば、DEV11G)を選択します。この接頭辞は、スキーマをこのドメインで使用するために論理的にまとめてグループ化するために使用されます。
注意: デフォルトで、Common Infrastructure Services Table (prefix_STB)およびOracle Platform Security Services (prefix_OPSS)スキーマが選択されます(それらがまだ作成されていない場合)。

インストールするコンポーネントの接頭辞とスキーマ名を書き留めます。インストールの構成時にこの情報が必要になります。「次へ」をクリックします。

9. 「前提条件チェック」ダイアログで、前提条件チェックが正常であることを確認し、「OK」をクリックします。

10. 「スキーマ・パスワード」画面で、スキーマの所有者のパスワードを入力します。
この画面で入力したパスワードを書き留めてください。製品インストールの構成中に必要となります。

11. 「表領域のマップ」画面で、作成するスキーマの目的の表領域マッピングを構成します。
「次へ」をクリックして、確認ダイアログで「OK」をクリックします。進行状況ダイアログに表領域の作成が完了したことが示されたら、「OK」をクリックします。

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

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

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

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

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

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

- 準備状況モードでのアップグレード・アシスタントの起動
-readinessパラメータを使用して、アップグレード・アシスタントを準備状況モードで起動します。

- アップグレード・アシスタントでの準備状況チェックの実行
アップグレード・アシスタントの各画面を移動して、アップグレード前の準備状況チェックを完了します。

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

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

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

アップグレード・アシスタントの準備状況チェックでは、サポートされる開始点にあるFusion MiddlewareスキーマおよびWebLogicドメイン構成の読取り専用のアップグレード前確認を実行します。確認は読取り専用操作です。

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

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

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

注意:

パフォーマンスが影響されることを回避するために、オフピーク時に準備状況チェックを実行することをお薦めします。

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

-readinessパラメータを使用して、アップグレード・アシスタントを準備状況モードで起動します。

アップグレード・アシスタントでアップグレード前の環境に対して準備状況チェックを実行する手順は次のとおりです。

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

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. アップグレード・アシスタントを起動します。

- (UNIX) ./ua -readiness

- (Windows) ua.bat -readiness

注意:
GUIモードを許可するようにDISPLAY環境変数を適切に設定していない場合、次のエラーが発生することがあります。

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

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

DISPLAYを設定してもこのエラーが引き続き発生する場合は、vncconfigなどの他のGUIツールの起動を試みてください。同じエラーが表示される場合は、DISPLAY環境変数がまだ正しく設定されていない可能性があります。

コマンドラインで指定できるその他のパラメータの詳細は、次を参照してください。

- アップグレード・アシスタントのコマンドライン・パラメータ

4.4.2.1 アップグレード・アシスタントのコマンドライン・パラメータ

コマンドラインからアップグレード・アシスタントを起動するとき、追加パラメータを指定できます。

表5-6 アップグレード・アシスタントのコマンドライン・パラメータ

パラメータ

必須またはオプション

説明

-readiness

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

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

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

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

-threads

オプション

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

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

-response

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

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

-examine

オプション

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

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

-logLevel 属性

オプション

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

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

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

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

-logDir 場所

オプション

アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。アップグレード・アシスタントによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

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

(UNIX) ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

(Windows) ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

オプション

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

4.4.3 アップグレード・アシスタントでの準備状況チェックの実行

アップグレード・アシスタントの各画面を移動して、アップグレード前の準備状況チェックを完了します。

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

準備状況チェックを完了する手順は次のとおりです。

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

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

- 「個別に選択されたスキーマ」を使用すると、アップグレード前の確認のために個別のスキーマを選択できます。準備状況チェックにより、スキーマがアップグレードに対してサポートされているか、またはアップグレードが必要な箇所が報告されます。
このオプションを選択すると、画面名が「選択したスキーマ」になります。

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

アップグレード・アシスタントですべてのスキーマおよびコンポーネント構成を同時に確認する場合は、デフォルトの選択のままにし、それ以外の場合は特定のオプションを選択します。

- 「すべてのスキーマのチェックを含める」は、アップグレード可能なスキーマを含むすべてのコンポーネントを検出および確認します。

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

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

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

依存コンポーネントを持つコンポーネントを選択した場合、それらのコンポーネントは自動的に選択されます。たとえば、Oracle Platform Security Servicesを選択した場合、Oracle Audit Servicesは自動的に選択されます。

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

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

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

注意
Oracle Databaseがデフォルトのデータベース・タイプです。続行する前に、正しいデータベース・タイプを選択したことを確認してください。間違ったデータベース・タイプを選択したことがわかった場合、正しいタイプに変更するためにこの画面に戻らないでください。かわりに、アップグレード・アシスタントを閉じて、正しいデータベース・タイプを選択して準備状況チェックを再起動し、正しいデータベース・タイプがすべてのスキーマに適用されることを確認してください。

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

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

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

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

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

5. 「準備状況チェック」画面で、準備状況チェックのステータスを確認します。 プロセスは数分かかる場合があります。
複数のコンポーネントを確認している場合、各コンポーネントの進行状況が固有の進捗バーに並行して表示されます。

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

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

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

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

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

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

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

readiness_timestamp.txt

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

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

表5-7 準備状況レポートの要素

レポートの情報

説明

必要なアクション

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

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

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

タイムスタンプ

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

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

ログ・ファイルの場所

ORACLE_HOME/oracle_common/upgrade/logs

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

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

準備状況レポートの場所

ORACLE_HOME/oracle_common/upgrade/logs

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

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

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

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

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

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

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

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

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

準備状況チェック・テストによって、特定のオブジェクトの問題が検出されました。

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

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

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

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

<オブジェクト>の完了した準備状況チェック・ステータス: FAILURE

準備状況チェックによって、スキーマ、索引、データ型など、特定のオブジェクトについての解決する必要がある1つ以上のエラーが検出されました。

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

<オブジェクト>の完了した準備状況チェック・ステータス: SUCCESS

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

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

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

Upgrade readiness check completed with one or more errors.

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

Starting readiness check of components.

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

12.1.3.0リリースのOracle Fusion Middleware IAUスキーマを実行しており、それらのスキーマが11gリリース(11.1.1.7以上)または12c (12.1.2.0)からアップグレードされた場合、準備状況チェックは次のエラーで失敗することがあります。

Starting index test for table IAU_COMMON:  TEST_REQUIRED_INDEXES --> Test
that the table contains all the required indexes
INFO Audit schema index DYN_EVENT_CATEGORY_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_EVENT_TYPE_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_TENANT_INDEX in table IAU_COMMON is missing
the required columns or index itself is missing. This maybe caused by a known
issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_USER_INDEX in table IAU_COMMON is missing
the required columns or index itself is missing. This maybe caused by a known
issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_COMPONENT_TYPE_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_USER_TENANT_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
Completed index test for table IAU_COMMON: TEST_REQUIRED_INDEXES --> Test
that the table contains all the required indexes +++ FAIL

注意:
準備状況レポートの索引欠落エラーは無視できます。これは既知の問題です。該当の欠落している索引は、スキーマ・アップグレード操作中に追加されます。アップグレードするスキーマがRCUを使用して12cで作成された場合、このエラーは発生しません。

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

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

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

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

Fusion Middleware環境を停止するには、次の手順に従います。

手順1: システム・コンポーネントの停止

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

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

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

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

手順2: 管理対象サーバーの停止

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

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

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

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

手順3: Oracle Identity Managementコンポーネントの停止環境を構成しているOracle Internet DirectoryなどのOracle Identity Managementコンポーネントがあれば、それをすべて停止します。

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

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

ステップ4: 管理サーバーの停止

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

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

- (UNIX) DOMAIN_HOME/bin/stopWebLogic.sh

- (Windows) DOMAIN_HOME\bin\stopWebLogic.cmd

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

注意:
リポジトリ用に外部のパスワード記憶域が設定されている場合は、アップグレード中に作業リポジトリのパスワードを取得できるように、資格証明ストアをホストしているサーバーが稼働している必要があります。詳細は、Oracle Fusion Middleware Oracle Data Integratorの管理の外部パスワード記憶域の設定を参照してください。

手順5: ノード・マネージャの停止

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

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

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

サーバーおよびプロセスを停止した後、アップグレード・アシスタントを使用して、サポートされている製品スキーマを現在のリリースのOracle Fusion Middlewareにアップグレードします。

アップグレード・アシスタントを使用すると、個別に選択したスキーマまたはドメインに関連付けられているすべてのスキーマをアップグレードできます。選択したオプションによって、表示されるアップグレード・アシスタントの画面は異なります。

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

- アップグレード・アシスタントを使用した製品スキーマのアップグレード
アップグレード・アシスタントの各画面を移動して、製品スキーマをアップグレードします。

- スキーマ・アップグレードの確認
すべてのアップグレード手順の完了後、schema_version_registryのスキーマ・バージョンが正しく更新されたことを確認して、アップグレードが成功したことを確認します。

4.6.1 Upgrade Assistantの起動

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

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

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

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. アップグレード・アシスタントを起動します。

- (UNIX) ./ua

- (Windows) ua.bat

ロギング・パラメータなど、コマンドラインで指定できるその他のパラメータの詳細は、次を参照してください。

- アップグレード・アシスタントのコマンドライン・パラメータ

4.6.1.1 アップグレード・アシスタントのコマンドライン・パラメータ

コマンドラインからアップグレード・アシスタントを起動するとき、追加パラメータを指定できます。

表4-8 アップグレード・アシスタントのコマンドライン・パラメータ

パラメータ

必須またはオプション

説明

-readiness

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

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

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

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

-threads

オプション

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

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

-response

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

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

-examine

オプション

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

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

-logLevel 属性

オプション

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

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

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

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

-logDir 場所

オプション

アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。アップグレード・アシスタントによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

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

(UNIX) ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

(Windows) ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

オプション

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

4.6.2 アップグレード・アシスタントを使用した製品スキーマのアップグレード

アップグレード・アシスタントの各画面を移動して、製品スキーマをアップグレードします。

注意

- 外部認証を使用している場合は、外部認証が内部認証に変更されていることを確認してください。

- エディションベースの再定義(EBR)ユーザーのみ: エディション・ベースの再定義(EBR)に対応したスキーマをアップグレードする前に、データベース・サーバーに接続して、12cのデータベース・サーバーにエディションを作成する必要があります。12cの新しいエディションは、既存の11cエディションの子である必要があります。再定義のためのサーバーでのエディション作成の詳細は、エディションベースの再定義のためのサーバー上でのエディションの作成を参照してください。

アップグレード・アシスタントで製品スキーマをアップグレードする手順は次のとおりです。

1. 「ようこそ」画面で、アップグレード・アシスタントの概要と、重要なアップグレード前のタスクに関する情報を確認します。「次へ」をクリックします

注意:
アップグレード・アシスタント画面の詳細は、画面で「ヘルプ」をクリックしてください。

2. 「選択したスキーマ」画面で、「個別に選択されたスキーマ」を選択します。

注意:
12c (12.2.1.2)コンポーネントをサポートするために使用されるスキーマのみをアップグレードしてください。Oracle Fusion Middleware 12c (12.2.1.2)に含まれていないコンポーネントをサポートするために現在使用されているスキーマはアップグレードしないでください。

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

3. 「使用可能なコンポーネント」画面で、マスターおよび作業リポジトリ・スキーマをアップグレードするために「Oracle Data Integrator」を選択します。

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

注意:
アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。

5. ODIスキーマ画面で、アップグレードする各スキーマのデータベース接続の詳細を指定します。

- 「データベース・タイプ」ドロップダウン・メニューからデータベース・タイプを選択します。

- データベース接続の詳細を入力して、「接続」をクリックします。

- 「スキーマ・ユーザー名」ドロップダウン・メニューからアップグレードするスキーマを選択し、スキーマのパスワードを入力します。アップグレードするスキーマに対して正しいスキーマ接頭辞を使用してください。

6. 「ODIオプション」画面で、すべてのオプションを選択します。

表5-9 ODIのオプション

オプション

説明

ナレッジ・モジュールを必須更新で置換

これを選択すると、標準ナレッジ・モジュールが最新バージョンに置き換えられます。Oracleによりインストールされたナレッジ・モジュールに対するカスタマイズ内容は上書きされます。ただし、インストールされたナレッジ・モジュールをコピーしてからそのナレッジ・モジュールをカスタマイズした場合、カスタマイズ内容は失われません。

トポロジおよびセキュリティ・メタデータのアップグレード

これを選択すると、テクノロジ、データ型、セキュリティ・プロファイルなどのトポロジおよびセキュリティ・アーティファクトが最新バージョンに置き換えられます。インストールされたオブジェクトのカスタマイズ内容は上書きされます。オブジェクトをコピーしてからカスタマイズした場合、カスタマイズ内容は失われません。

高度なアップグレード・オプションの詳細は、「高度なアップグレード・オプション」を参照してください。

7. 「ODIスーパーバイザ」画面に、アップグレードするODIリポジトリのスーパーバイザ・アカウント資格証明を入力します。

インストールされているスーパーバイザ・アカウントはSUPERVISORです。ODIのマスター・リポジトリおよび作業リポジトリの作成時にリポジトリ作成ユーティリティ(RCU)で求められたときに指定した、正しいスーパーバイザ・アカウント名およびパスワードについては、ODI管理者に確認してください。

注意:
「ドメインで使用されるすべてのスキーマ」が選択されている場合、ODIのスーパーバイザ資格証明はドメインに含まれていないため、最初のインスタンスにあらかじめ移入されません。複数のODIスキーマがある場合、アップグレード・アシスタントは最初の資格証明のセットを使用してユーザー・エントリに移入します。

8. 「ODIアップグレード・キー」画面で、自動生成されたアップグレード・キーを使用して、リポジトリ・オブジェクトの11g IDを一意のGUIDに変換するか、独自のキーを「アップグレード・キー」フィールドに指定します。

推奨事項

- 自動生成されたキーを編集して、覚えやすい意味のあるキーを指定します。

- ODIオブジェクトがXMLファイルからインポートされるときに同じアップグレード・キーを指定できるように、アップグレード・キーを書き留めます。

ODIオブジェクトは、ODIリポジトリ、ならびにこうしたリポジトリからエクスポートされたXMLファイルに存在し、リポジトリ間のメタデータ交換などで使用できます。そのため、同一オブジェクトの複数のコピーが異なるリポジトリおよびXMLファイルに含まれる場合があります。

12cでは、ODIはオブジェクト識別に数字の内部IDではなくGUIDを使用します。アップグレード後にオブジェクトIDが保持されるようにするため、決定性アルゴリズムが適用され、既存のオブジェクトの内部IDからGUIDが計算されます(新規オブジェクトの場合、ODIにより無作為のGUIDが生成されます)。

数字の内部IDが実際にはユニバーサルに一意ではなく、疑似的な一意性を実現するためにリポジトリIDに依存していたため、ODIではユーザーがアップグレード・キーを指定して、重複したGUIDが生成される可能性を下げることができます。アップグレード・キーが数字の内部IDとともにGUID生成アルゴリズムに提供され、GUIDが計算されます。

このように異なるアップグレード・キーを選択することで、偶然同じ数字の内部IDを持つオブジェクトについて重複したGUIDを取得せずに済みます。ただし、同じオブジェクトの複数のコピーが(リポジトリ内に、またはXMLファイルにエクスポートされて)存在する場合、オブジェクトのすべてのコピーに対して同じGUIDが生成される必要があります。そのため、その特定のオブジェクトのコピーに関係するすべてのアップグレード操作に対して、同じアップグレード・キーを使用する必要があります。

たとえば、11gリポジトリにIDとして1001を持つプロジェクトがあり、また同じリポジトリからエクスポートされたファイルに、同じプロジェクト(ID = 1001)が含まれるとします。この場合、リポジトリのアップグレードに使用されるアップグレード・キーは、アップグレード済の12cリポジトリにXMLファイルをインポートする際に使用されるアップグレード・キーと同じである必要があります。これによって、インポート・ファイルのプロジェクト・オブジェクトは、リポジトリのプロジェクト・オブジェクトと正しく一致します(いずれかのSYNONYMインポート・モードを使用した場合)。ただし、別のリポジトリで作成されたオブジェクトを含むソースから11g XMLエクスポート・ファイルが提供され、そのリポジトリの情報がない場合、偶然同じ内部ID (1001)を持つプロジェクトが含まれている可能性があります。この場合、誤ったオブジェクトの一致によるメタデータの破損を防ぐため、そのファイルをリポジトリにインポートする際には、別のカスタム・アップグレード・キーを使用する必要があります。

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

注意:

- 調査フェーズの間に、アップグレードを続行せずに検出された問題を解決した場合は、バックアップからリストアすることなしに、アップグレード・アシスタントを再起動できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックして続行した場合は、アップグレード・アシスタントを再起動する前に、アップグレード前の環境をバックアップからリストアする必要があります。

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

10. 「アップグレード・サマリー」画面で、スキーマ・アップグレードに選択したオプションのサマリーを確認します。
正しいソース・バージョンとターゲット・バージョンが、アップグレード対象の各スキーマにリストされていることを確認します。

後でアップグレード・アシスタントをレスポンス(またはサイレント)モードで再び実行するためにこれらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックして、レスポンス・ファイルの場所および名前を指定します。サイレント・アップグレードは、アップグレード・アシスタント・とまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。

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

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

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

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

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

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

12. アップグレードが成功した場合、「アップグレード成功」画面で「閉じる」をクリックし、アップグレードを完了してウィザードを閉じます。

アップグレードが失敗した場合、「アップグレード失敗」画面で「ログの表示」をクリックし、エラーを表示してトラブルシューティングします。ログはORACLE_HOME/oracle_common/upgrade/logsにあります。

注意:
アップグレードに失敗した場合、アップグレード前の環境をバックアップからリストアし、問題を修正して、アップグレード・アシスタントを再起動する必要があります。

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

すべてのアップグレード手順の完了後、schema_version_registryのスキーマ・バージョンが正しく更新されたことを確認して、アップグレードが成功したことを確認します。

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

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

問合せ結果:

- VERSION列の数値が、そのスキーマの最新のバージョン番号に一致していることを確認します。たとえば、スキーマ・バージョン番号が12.2.1.2.0であることを確認します。ただし、すべてのスキーマ・バージョンが更新されるわけではないことに注意してください。一部のスキーマではこのリリースへのアップグレードが必要なく、アップグレード前のバージョン番号が保持されます。

- STATUSフィールドは、スキーマのパッチ適用操作中は「UPGRADING」または「UPGRADED」に、操作が完了すると「VALID」になります。

- ステータスが「INVALID」と表示された場合は、ステータスの更新が失敗しています。ログ・ファイルを調べて、失敗した理由を判定する必要があります。

- IAU_APPENDおよびIAU_VIEWERによって所有されるシノニム・オブジェクトは、INVALIDとして表示されますが、失敗を示すものではありません。
それらは、シノニムの作成後にターゲット・オブジェクトが変更されるため無効になります。シノニム・オブジェクトはアクセスされると有効になります。これらのINVALIDオブジェクトは無視しても問題ありません。

4.7 ドメインの再構成

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

WebLogic Serverドメインを再構成する場合は、ドメイン内のアプリケーションに応じて次の項目が自動的に更新されます。

- WebLogic Serverコア・インフラストラクチャ

- ドメイン・バージョン

注意:

ドメインの再構成を開始する前に、次の制限に注意してください。

- 再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。

- アップグレード・プロセス中に非動的クラスタ・ドメインを動的クラスタ・ドメインに変換することはサポートされていません。
動的クラスタ機能は再構成ウィザードの実行中は使用できますが、非動的クラスタをアップグレードしてから動的クラスタを追加することのみがサポートされています。アップグレード・プロセス中に動的クラスタを追加することはできません。

具体的には、ドメインを再構成すると、次のようになります。

- ドメインのconfig.xmlファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンに更新されます。

- すべてのインストール済Oracle製品の再構成テンプレートは、自動的に選択されてドメインに適用されます。これらのテンプレートは、WebLogicドメインが現在のWebLogic Serverバージョンと互換性を持つために必要な再構成タスクを定義します。

- 起動スクリプトが更新されます。
変更した起動スクリプトを保持する場合、再構成ウィザードを起動する前にそのスクリプトをバックアップしてください。

注意:
ドメインの再構成プロセスを開始すると、元に戻すことはできません。再構成ウィザードを実行する前に、アップグレード前チェックリストで示されているようにドメインをバックアップしたことを確認してください。再構成ウィザードの実行中にエラーまたは他の割込みが発生した場合、バックアップ場所から元のドメイン・ディレクトリにファイルとディレクトリをコピーすることによって、ドメインをリストアする必要があります。これは、再構成前にドメインを確実に元の状態に戻す唯一の方法です。

再構成ウィザードを使用して既存のドメインを再構成する手順に従います。ドメインの再構成に関する一般情報は、Oracle Fusion Middleware Oracle WebLogic ServerのアップグレードのWebLogicドメインの再構成を参照してください。

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

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

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

4.7.1 ドメインのバックアップ

再構成ウィザードを実行する前に、ドメイン・ディレクトリのバックアップ・コピーを作成します。

ドメイン・ディレクトリのバックアップを作成する手順は次のとおりです。

1. コンテンツを保持するには、ソース・ドメインを別の場所にコピーします。
たとえば、C:\domains\mydomainをC:\domains\mydomain_backupにコピーします。

2. 各リモート管理対象サーバーのドメインを更新する前に、各リモート・マシンのドメイン・ディレクトリのバックアップ・コピーを作成します。

3. ドメインのバックアップしたバージョンが完全であることを確認します。

ドメインの再構成がなんらかの理由で失敗した場合は、再構成を実行する前に、すべてのファイルおよびディレクトリをバックアップ・ディレクトリから元のドメイン・ディレクトリにコピーしてドメインを完全に元の状態に戻す必要があります。

4.7.2 再構成ウィザードの起動

再構成ウィザードをグラフィカル・モードで起動する手順は次のとおりです。

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

2. コマンド・シェル(UNIXオペレーティング・システムの場合)またはコマンド・プロンプト・ウィンドウ(Windowsオペレーティング・システムの場合)を開きます。

3. エディション・ベースのデータベース・ユーザーのみ: スキーマがEBRデータベースを使用して構成されている場合、再構成ウィザードを実行する前に、手動でデフォルトのエディション名を設定する必要があります。
次のSQLコマンドを実行して、デフォルト・エディションを設定します。
ALTER DATABASE DEFAULT EDITION = edition_name;

ここで、edition_nameは、子エディション名です。

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

- (UNIX) ORACLE_HOME/oracle_common/common/bin

- (Windows) ORACLE_HOME\oracle_common\commom\bin

5. 再構成ウィザードを次のロギング・オプションとともに起動します。

- (UNIX) ./reconfig.sh -log=log_file -log_priority=ALL

- (Windows) reconfig.cmd -log=log_file -log_priority=ALL

log_fileは、ドメイン再構成セッション用に作成するログ・ファイルの絶対パスです。これは、再構成処理をトラブルシューティングする必要がある場合に役立つことがあります。

パラメータ-log_priority=ALLは、ログを詳細モードで出力します。

注意:

このコマンドを実行すると、デフォルトのキャッシュ・ディレクトリが無効であることを示す次のエラー・メッセージが表示される場合があります。

*sys-package-mgr*: can't create package cache dir

環境変数CONFIG_JVM_ARGSを設定することでキャッシュ・ディレクトリを変更できます。次に例を示します。

CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

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

アップグレード・アシスタントを実行する前に、再構成ウィザードの各画面を移動して既存のドメインを再構成します。

注意:
ソースがクラスタ環境である場合は、再構成ウィザードをプライマリ・ノードでのみ実行します。packおよびunpackユーティリティを使用して、ドメイン内の他のクラスタ・メンバーに変更を適用します。

再構成ウィザードを使用してドメインを再構成する手順は次のとおりです。

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

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

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

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

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

3. 「ドメイン・モードおよびJDK」画面で、ドメインで使用するJDKを選択するか、「参照」をクリックして、使用するJDKにナビゲートします。12c (12.2.1.2)に対してサポートされているJDKバージョンは1.8.0_101以上です。「次へ」をクリックします。

注意:
このステージでは、「ドメイン・モード」を変更することはできません。

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

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

再構成ウィザードは、この接続を使用して、ドメインのコンポーネントに必要なデータソースを自動的に構成します。
注意: 既存の11gデータ・ソースの場合、再構成では既存の値が保持されます。スキーマがRCUによって12c用に作成された新しいデータ・ソースの場合、デフォルトの接続データは_STBスキーマから取得されます。特定のスキーマの接続データが_STBスキーマにない場合は、デフォルトの接続データが使用されます。

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

5. 「JDBCコンポーネント・スキーマ」画面で、各コンポーネント・スキーマのDBMS/サービスおよびホスト名が正しいことを確認し、「次へ」をクリックします。

6. 「JDBCコンポーネント・スキーマ・テスト」画面で、すべてのコンポーネント・スキーマを選択して「選択された接続のテスト」をクリックし、各スキーマの接続をテストします。テストの結果は、「ステータス」列に表示されます。
チェックが完了したら、「次へ」をクリックします。

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

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

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

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

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

注意:
ドメインを再構成しても、その場所は変更されません。

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

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

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

進捗バーが100%になったら、「次へ」をクリックします。

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

以後の操作のためにドメインの場所と管理サーバーURLをメモします。

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

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

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

- アップグレード・アシスタントを使用したドメイン・コンポーネント構成のアップグレード
アップグレード・アシスタントの各画面を移動して、WebLogicドメイン内のコンポーネント構成をアップグレードします。

4.8.1 Upgrade Assistantの起動

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

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

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

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. アップグレード・アシスタントを起動します。

- (UNIX) ./ua

- (Windows) ua.bat

ロギング・パラメータなど、コマンドラインで指定できるその他のパラメータの詳細は、次を参照してください。

- アップグレード・アシスタントのコマンドライン・パラメータ

4.8.1.1 アップグレード・アシスタントのコマンドライン・パラメータ

コマンドラインからアップグレード・アシスタントを起動するとき、追加パラメータを指定できます。

表4-10 アップグレード・アシスタントのコマンドライン・パラメータ

パラメータ

必須またはオプション

説明

-readiness

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

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

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

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

-threads

オプション

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

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

-response

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

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

-examine

オプション

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

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

-logLevel 属性

オプション

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

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

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

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

-logDir 場所

オプション

アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。アップグレード・アシスタントによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

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

(UNIX) ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

(Windows) ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

オプション

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

4.8.2 アップグレード・アシスタントを使用したドメイン・コンポーネント構成のアップグレード

アップグレード・アシスタントの各画面を移動して、WebLogicドメイン内のコンポーネント構成をアップグレードします。

再構成ウィザードを実行してWebLogicドメインを12c (12.2.1.2)に再構成した後、アップグレード・アシスタントを実行して、ドメイン・コンポーネント構成を更新済ドメイン構成に一致するようにアップグレードする必要があります。

アップグレード・アシスタントを使用してドメイン・コンポーネント構成をアップグレードする手順は次のとおりです。

1. 「ようこそ」画面で、アップグレード・アシスタントの概要と、重要なアップグレード前のタスクに関する情報を確認します。「次へ」をクリックします

注意:
アップグレード・アシスタント画面の詳細は、画面で「ヘルプ」をクリックしてください。

2. 次の画面で次のようにします。

- 「ドメインによって使用されるすべての構成」を選択します。画面名は「WebLogicコンポーネント」になります。

- 「ドメイン・ディレクトリ」フィールドにWebLogicドメイン・ディレクトリ・パスを入力します。

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

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

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

注意:
アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。

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

注意:

- 調査フェーズの間に、アップグレードを続行せずに検出された問題を解決した場合は、バックアップからリストアすることなしに、アップグレード・アシスタントを再起動できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックして続行した場合は、アップグレード・アシスタントを再起動する前に、アップグレード前の環境をバックアップからリストアする必要があります。

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

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

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

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

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

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

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

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

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

アップグレードが失敗した場合、「アップグレード失敗」画面で「ログの表示」をクリックし、エラーを表示してトラブルシューティングします。ログはORACLE_HOME/oracle_common/upgrade/logsにあります。

注意:
アップグレードに失敗した場合、アップグレード前の環境をバックアップからリストアし、問題を修正して、アップグレード・アシスタントを再起動する必要があります。

4.9 サーバーおよびプロセスの起動

アップグレードが成功した後、管理サーバーおよび管理対象サーバーを含め、すべてのプロセスおよびサーバーを再起動します。

これらのコンポーネントは相互に依存する場合があるため、正しい順序で起動する必要があります。

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

Fusion Middleware環境を起動するには、次の手順に従います。

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

管理サーバーを起動する場合、管理サーバーで稼働しているWebLogic Server管理コンソールやFusion Middleware Controlなどのプロセスも起動します。

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

- (UNIX) DOMAIN_HOME/bin/startWebLogic.sh

- (Windows) DOMAIN_HOME\bin\startWebLogic.cmd

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

手順2: ノード・マネージャの起動

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

- (UNIX) DOMAIN_HOME/bin/startNodeManager.sh

- (Windows) DOMAIN_HOME\bin\startNodeManager.cmd

手順3: Oracle Identity Managementコンポーネントの起動環境を構成しているOracle Internet DirectoryなどのOracle Identity Managementコンポーネントがあれば、それをすべて起動します。

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

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

手順4: 管理対象サーバーの起動

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

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

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

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

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

手順5: システム・コンポーネントの起動

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

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

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

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

5 Oracle Data Integrator Java EEエージェント環境の11gからのアップグレード

Oracle Data Integrator Java EEエージェント環境をOracle Fusion Middleware 11gから12c (12.2.1.2)にアップグレードできます。

- Oracle Data Integrator Java EEエージェントのアップグレード・プロセスについて
Oracle Data Integrator Java EEエージェントのアップグレード・プロセスの概要を示すプロセス・フローチャートを確認します。

- Oracle Data Integrator Java EE環境のインストール
アップグレードを開始する前に、Oracle Fusion Middleware InfrastructureおよびOracle Data Integrator 12c (12.2.1.2)ディストリビューションをターゲット・システムにダウンロードし、Oracle Universal Installerを使用してインストールします。

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

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

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

- 製品スキーマのアップグレード
サーバーおよびプロセスを停止した後、アップグレード・アシスタントを使用して、サポートされている製品スキーマを現在のリリースのOracle Fusion Middlewareにアップグレードします。

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

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

- サーバーおよびプロセスの起動
アップグレードが成功した後、管理サーバーおよび管理対象サーバーを含め、すべてのプロセスおよびサーバーを再起動します。

親トピック: Oracle Data Integratorの11gからのアップグレード

5.1 Oracle Data Integrator Java EEエージェントのアップグレード・プロセスについて

Oracle Data Integrator Java EEエージェントのアップグレード・プロセスの概要を示すプロセス・フローチャートを確認します。

表5-1 Oracle Data Integratorをアップグレードするためのタスク

タスク

説明

必須

このガイドの概要のトピックをまだ確認していない場合は確認し、必要なアップグレード前のタスクを完了します。

次を参照してください。

- Oracle Data Integratorの12c (12.2.1.2)へのアップグレードの概要

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

必須

Oracle Fusion Middleware InfrastructureおよびOracle Data Integrator 12c (12.2.1.2)を新しいOracleホームにインストールします。

Oracle Data Integrator Java EE環境のインストールを参照してください。

必須

リポジトリ作成ユーティリティ(RCU)を起動して、必要な12cデータベース・スキーマを作成します。

STB、OPSS、IAU、IAU_VIEWERおよびIAU_APPENDスキーマを作成します。

必要な12cスキーマの作成を参照してください。

オプション

アップグレード前の準備状況チェックを実行します。

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

必須

11g環境を停止します(すべての管理サーバーと管理対象サーバーを停止します)。

警告: アップグレード中にサーバーを停止しないと、データが破壊される可能性があります。

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

必須

アップグレード・アシスタントを起動して、11gのデータベース・スキーマをアップグレードし、すべてのアクティブ(進行中の)インスタンス・データを移行します。

製品スキーマのアップグレードを参照してください。

注意: アクティブ・インスタンス・データのアップグレードは、アップグレード・アシスタントの実行中に自動で開始されます。データが正常に新しい12c (12.2.1.2)環境にアップグレードされたら、アップグレード・アシスタントを終了してもかまいません。クローズされたインスタンスのアップグレードは、バックグランド・プロセスで継続されます。

必須

再構成ウィザードを起動してドメインを再構成します。

構成ウィザードを実行して、既存のドメインを更新して新しくインストールしたソフトウェアを使用します。

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

JRFコンポーネントのアップグレードが必要な場合は必須

アップグレード・アシスタントを(再度)起動して、ドメイン・コンポーネント構成をアップグレードします。

アップグレード・アシスタントを実行して、再構成したドメインのコンポーネント構成をアップグレードします。

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

必須

サーバーおよび12c (12.2.1.2)インスタンスを再起動します。

アップグレード・プロセスが完了したら、12c (12.2.1.2)インスタンスを再起動します。

サーバーおよびプロセスの起動を参照してください。

必須

アップグレードを確認します。

バックアップを削除する前に、アップグレードしたコンポーネントがすべて期待どおりに動作していることを確認します。

5.2 Oracle Data Integrator Java EE環境のインストール

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

注意:
アップグレードにInfrastructureが必要な場合、他のFusion Middleware製品をインストールする前に、まずOracle Fusion Middleware Infrastructureディストリビューションをインストールする必要があります。

12c (12.2.1.2)ディストリビューションをインストールする手順は次のとおりです。

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

2. 次の12c (12.2.1.2)製品ディストリビューションをOracle Technology NetworkまたはOracle Software Delivery Cloudからターゲット・システムにダウンロードします。

- Oracle Fusion Middleware Infrastructure (fmw_12.2.1.2.0_infrastructure_generic.jar)

- Oracle Data Integrator (fmw_12.2.1.2.0_odi_Disk1_1of2.zipおよびfmw_12.2.1.2.0_odi_Disk1_2of2.zip )

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

4. インストールfmw_12.2.1.2.0_odi_Disk1_1of2.zipおよびfmw_12.2.1.2.0_odi_Disk1_2of2.zipファイルを解凍します。

5. Oracle Fusion Middleware Infrastructureのインストール・プログラムを起動します。

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

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

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

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

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

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

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

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

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

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

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

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

- Infrastructureには、「Fusion Middlewareインフラストラクチャ」を選択します

- Oracle Data Integratorには、「エンタープライズ・インストール」を選択します

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

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

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

13. 「インストールの進行状況」画面で進捗バーが100%になったら、「終了」をクリックしてインストーラを閉じるか、「次へ」をクリックしてサマリーを確認します。

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

15. Oracle Fusion Middleware Infrastructureをインストールした後、次のコマンドを入力して製品ディストリビューションのインストーラを起動し、前述の手順を繰り返してインストーラの各画面を移動します。
(UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.2.0_odi_generic.jar

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

5.3 必要な12cスキーマの作成

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

このガイドで説明するODI環境では、必須のスキーマは次のとおりです。

- ODIスタンドアロン・エージェント(WebLogicドメインなし): STB

- ODIスタンドアロン・コロケート・エージェント(WebLogicドメインあり): STB、OPSS、IAU、IAU_VIEWERおよびIAU_APPEND

- ODI Java EEエージェント: STB、OPSS、IAU、IAU_VIEWERおよびIAU_APPEND

注意:
Oracle Fusion Middlewareの前の12cリリースからアップグレードする場合、これらのスキーマがすでに存在する場合には再作成する必要はありません。ドメインの既存のスキーマを特定するには、次の手順を参照してください。

11gからアップグレードする場合は、「アップグレード前チェックリスト」を参照して、ドメイン内の既存のスキーマを特定します。12cにアップグレードする前に、次のスキーマが存在している必要があります。

- サービス表スキーマ(prefix_STB)。このスキーマは12cで新規のものであり、ドメインベースのアップグレードに必要になります。基本的なスキーマ構成情報(スキーマ接頭辞やパスワードなど)が格納され、他のOracle Fusion Middlewareコンポーネントはドメイン作成中にこれにアクセスして使用できます。このスキーマはリポジトリ作成ユーティリティ(RCU)を実行するときに自動的に作成され、ここで他の11gスキーマに使用した既存のスキーマ所有者接頭辞を指定します。注意: サービス表スキーマが存在しない場合、UPGAST-00328: スキーマ・バージョンのレジストリ表はこのデータベースに存在しません。その場合、アップグレード・アシスタントを実行するためにはサービス表スキーマを作成する必要があります。というエラー・メッセージが表示されることがあります。

- Oracle Platform Security Services (OPSS)スキーマ(prefix_OPSS)。このスキーマは、11gでOIDベースのセキュリティ・ストアを使用している場合に必要です。このスキーマは、リポジトリ作成ユーティリティ(RCU)を実行するときに自動的に作成されます。LDAPベースのOPSSセキュリティ・ストアでサポートされているのは、Oracle Internet Directory (OID)のみです。LDAPベースのポリシー・ストアは、通常、本番環境で使用します。アップグレード前に、OIDベースのセキュリティ・ストアを再関連付けする必要はありません。アップグレード・アシスタントの実行中に、OPSSスキーマを選択できます。アップグレード・アシスタントは、OIDベースのセキュリティ・ストアを自動的にアップグレードします。注意: 12c OPSSデータベース・スキーマが必要なのは、ドメインの再構成時に12cスキーマを参照するためです。ドメインでは、アップグレード完了後にOIDベースのセキュリティ・ストアが引き続き使用されます。

- 監査スキーマ。監査サービス(_IAU)をアップグレードする場合、_IAUに加えて、_IAU_VIEWERおよび_IAU_APPENDを必ず選択します。これらを選択したときに、アップグレード・アシスタントによって自動的に作成されます。

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

1. (オプション) 11gからアップグレードし、既存のドメインにどのスキーマが存在しているかを確認するには、DBA権限を持つユーザーとしてデータベースに接続し、SQL*Plusから次のコードを実行します。

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

2. コマンドラインからjava -versionを実行して、動作保証されたJDKがすでにシステムにあることを確認します。12c (12.2.1.2)では、動作保証されたJDKは1.8.0_101以上です。
JAVA_HOME環境変数が、動作保証されたJDKの場所に設定されていることを確認します。次に例を示します。

- (UNIX) setenv JAVA_HOME /home/Oracle/Java/jdk1.8.0_101

- (Windows) set JAVA_HOME=C:\home\Oracle\Java\jdk1.8.0_101

$JAVA_HOME/binを$PATHに追加します。

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

- (UNIX) ORACLE_HOME/oracle_common/bin

- (Windows) ORACLE_HOME\oracle_common\bin

4. RCUを起動します。

- (UNIX) ./rcu

- (Windows) rcu.bat

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

6. 「リポジトリの作成」画面で「リポジトリの作成」を選択し、「システム・ロードおよび製品ロード」を選択します。
DBA権限を持っていない場合は、「システム・ロードに対するスクリプトの準備」を選択します。これによって、RCUが選択されたコンポーネントに対してアクションを実行した場合にコールされるSQL文およびブロックと同じものを、すべて含むSQLスクリプトが生成されます。このスクリプトが生成された後は、必要なSYSまたはSYSDBA権限を持つユーザーが、このスクリプトを実行してシステム・ロード・フェーズを完了できます。
「次へ」をクリックします。

7. 「データベース接続の詳細」画面で、「データベース・タイプ」を選択し、11gスキーマをホストするデータベースの接続情報を入力します。次の該当する表を参照してください。

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

オプション

説明および例

ホスト名

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

examplehost.exampledomain.com

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

ポート

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

サービス名

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

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

examplehost.exampledomain.com

ユーザー名

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

パスワード

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

ロール

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

「標準」または「SYSDBA」

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

オプション

説明および例

ホスト名

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

ポート

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

データベース名

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

ユーザー名

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

パスワード

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

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

オプション

説明および例

Unicodeのサポート

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

サーバー名

データベースが稼働しているサーバーのホスト名、IPアドレスまたは詳細なサーバー名を、host\server形式で指定します。
MSSQL指定インスタンス: 指定インスタンスは、コンピュータのネットワーク名とインストール中に指定したインスタンス名によって識別されます。クライアントは接続時にサーバー名とインスタンス名の両方を指定する必要があります。

ポート

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

データベース名

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

ユーザー名

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

パスワード

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

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

オプション

説明および例

サーバー名

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

ポート

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

データベース名

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

ユーザー名

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

パスワード

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

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

8. 「コンポーネントの選択」画面で、「既存の接頭辞の選択」を選択し、ドロップダウン・メニューから既存の11gスキーマの作成に使用した接頭辞(たとえば、DEV11G)を選択します。この接頭辞は、スキーマをこのドメインで使用するために論理的にまとめてグループ化するために使用されます。
注意: デフォルトで、Common Infrastructure Services Table (prefix_STB)およびOracle Platform Security Services (prefix_OPSS)スキーマが選択されます(それらがまだ作成されていない場合)。

インストールするコンポーネントの接頭辞とスキーマ名を書き留めます。インストールの構成時にこの情報が必要になります。「次へ」をクリックします。

9. 「前提条件チェック」ダイアログで、前提条件チェックが正常であることを確認し、「OK」をクリックします。

10. 「スキーマ・パスワード」画面で、スキーマの所有者のパスワードを入力します。
この画面で入力したパスワードを書き留めてください。製品インストールの構成中に必要となります。

11. 「表領域のマップ」画面で、作成するスキーマの目的の表領域マッピングを構成します。
「次へ」をクリックして、確認ダイアログで「OK」をクリックします。進行状況ダイアログに表領域の作成が完了したことが示されたら、「OK」をクリックします。

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

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

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

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

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

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

- 準備状況モードでのアップグレード・アシスタントの起動
-readinessパラメータを使用して、アップグレード・アシスタントを準備状況モードで起動します。

- アップグレード・アシスタントでの準備状況チェックの実行
アップグレード・アシスタントの各画面を移動して、アップグレード前の準備状況チェックを完了します。

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

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

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

アップグレード・アシスタントの準備状況チェックでは、サポートされる開始点にあるFusion MiddlewareスキーマおよびWebLogicドメイン構成の読取り専用のアップグレード前確認を実行します。確認は読取り専用操作です。

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

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

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

注意:

パフォーマンスが影響されることを回避するために、オフピーク時に準備状況チェックを実行することをお薦めします。

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

-readinessパラメータを使用して、アップグレード・アシスタントを準備状況モードで起動します。

アップグレード・アシスタントでアップグレード前の環境に対して準備状況チェックを実行する手順は次のとおりです。

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

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. アップグレード・アシスタントを起動します。

- (UNIX) ./ua -readiness

- (Windows) ua.bat -readiness

注意:
GUIモードを許可するようにDISPLAY環境変数を適切に設定していない場合、次のエラーが発生することがあります。

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

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

DISPLAYを設定してもこのエラーが引き続き発生する場合は、vncconfigなどの他のGUIツールの起動を試みてください。同じエラーが表示される場合は、DISPLAY環境変数がまだ正しく設定されていない可能性があります。

コマンドラインで指定できるその他のパラメータの詳細は、次を参照してください。

- アップグレード・アシスタントのコマンドライン・パラメータ

5.4.2.1 アップグレード・アシスタントのコマンドライン・パラメータ

コマンドラインからアップグレード・アシスタントを起動するとき、追加パラメータを指定できます。

表5-6 アップグレード・アシスタントのコマンドライン・パラメータ

パラメータ

必須またはオプション

説明

-readiness

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

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

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

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

-threads

オプション

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

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

-response

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

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

-examine

オプション

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

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

-logLevel 属性

オプション

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

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

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

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

-logDir 場所

オプション

アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。アップグレード・アシスタントによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

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

(UNIX) ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

(Windows) ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

オプション

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

5.4.3 アップグレード・アシスタントでの準備状況チェックの実行

アップグレード・アシスタントの各画面を移動して、アップグレード前の準備状況チェックを完了します。

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

準備状況チェックを完了する手順は次のとおりです。

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

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

- 「個別に選択されたスキーマ」を使用すると、アップグレード前の確認のために個別のスキーマを選択できます。準備状況チェックにより、スキーマがアップグレードに対してサポートされているか、またはアップグレードが必要な箇所が報告されます。
このオプションを選択すると、画面名が「選択したスキーマ」になります。

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

アップグレード・アシスタントですべてのスキーマおよびコンポーネント構成を同時に確認する場合は、デフォルトの選択のままにし、それ以外の場合は特定のオプションを選択します。

- 「すべてのスキーマのチェックを含める」は、アップグレード可能なスキーマを含むすべてのコンポーネントを検出および確認します。

- 「すべての構成のチェックを含める」は、管理対象WebLogic Serverドメインのコンポーネント構成を確認します。

「次へ」をクリックします。

3. 「個別に選択されたスキーマ」を選択した場合、「使用可能なコンポーネント」画面で、準備状況チェックを実行する、アップグレード可能なスキーマを含むコンポーネントを選択します。

依存コンポーネントを持つコンポーネントを選択した場合、それらのコンポーネントは自動的に選択されます。たとえば、Oracle Platform Security Servicesを選択した場合、Oracle Audit Servicesは自動的に選択されます。

選択したコンポーネントに応じて、追加の画面が表示される場合があります。たとえば、次のような作業が必要になることがあります。

- ドメイン・ディレクトリを指定します。

- スキーマ資格証明を指定して、選択したスキーマに接続します: 「データベース・タイプ」、「DBAユーザー名」および「DBAパスワード」。次に「接続」をクリックします。

注意
Oracle Databaseがデフォルトのデータベース・タイプです。続行する前に、正しいデータベース・タイプを選択したことを確認してください。間違ったデータベース・タイプを選択したことがわかった場合、正しいタイプに変更するためにこの画面に戻らないでください。かわりに、アップグレード・アシスタントを閉じて、正しいデータベース・タイプを選択して準備状況チェックを再起動し、正しいデータベース・タイプがすべてのスキーマに適用されることを確認してください。

- 「スキーマ・ユーザー名」を選択して、「スキーマ・パスワード」を指定します。

「次へ」をクリックして準備状況チェックを開始します。

4. 「準備状況サマリー」画面で、選択に基づいて実行された準備状況チェックのサマリーを確認します。
後でアップグレード・アシスタントをレスポンス(またはサイレント)モードで再び実行するために選択内容をレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックして、レスポンス・ファイルの場所および名前を指定します。サイレント・アップグレードは、アップグレード・アシスタント・とまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。

詳細レポートを表示するには、「ログの表示」をクリックします。

「次へ」をクリックします。

5. 「準備状況チェック」画面で、準備状況チェックのステータスを確認します。 プロセスは数分かかる場合があります。
複数のコンポーネントを確認している場合、各コンポーネントの進行状況が固有の進捗バーに並行して表示されます。

準備状況チェックが完了したら「続行」をクリックします。

6. 「準備状況の終了」画面で、準備状況チェックの結果(「準備状況成功」または「準備状況失敗」)を確認します。

- 準備状況チェックが成功した場合、「準備状況レポートの表示」をクリックして完全なレポートを確認します。準備状況チェックが成功した場合でも、実際のアップグレードを実行する前に準備状況レポートを確認することをお薦めします。「検索」オプションを使用して、レポート内の特定の語または句を検索します。また、このレポートには、完成した準備状況チェック・レポート・ファイルが格納されている場所も示されます。

- 準備状況チェックで問題またはエラーが発生した場合、「ログの表示」をクリックしてログ・ファイルを確認し、問題を特定および修正してから、準備状況チェックを再開してください。ログ・ファイルは、設定したコマンドライン・オプションによって管理されます。

5.4.4 準備状況レポートの理解

ドメインの準備状況チェックを実行した後、レポートを確認して、アップグレードが成功するためにアクションを実行する必要があるかどうかを決定します。

準備状況レポート・ファイルの形式は次のとおりです。

readiness_timestamp.txt

timestampは、準備状況チェックが実行された日時を示します。

準備状況レポートには、次の情報が含まれています。

表5-7 準備状況レポートの要素

レポートの情報

説明

必要なアクション

全体的な準備状況ステータス: SUCCESSまたはFAILURE

レポートの上部には、アップグレードの準備状況チェックが成功したか、または1つ以上のエラーが発生して完了したかが示されます。

1つ以上のエラーが発生してレポートが完了した場合、アップグレードを試みる前に、FAILを検索し、障害の原因となった問題を修正します。準備状況チェックは、アップグレードする前に必要に応じて何度でも再実行できます。

タイムスタンプ

レポートが生成された日付と時刻。

必要なアクションはありません。

ログ・ファイルの場所

ORACLE_HOME/oracle_common/upgrade/logs

生成されたログ・ファイルのディレクトリの場所。

必要なアクションはありません。

準備状況レポートの場所

ORACLE_HOME/oracle_common/upgrade/logs

生成された準備状況レポートのディレクトリの場所。

必要なアクションはありません。

チェックされたコンポーネントの名前

チェックに含まれるコンポーネントの名前およびバージョンとステータス。

このリリースにアップグレードできないコンポーネント(SOAコア拡張など)がドメインに含まれる場合は、アップグレードを試みないでください。

チェックされたスキーマの名前

チェックに含まれるスキーマの名前および現在のバージョンとステータス。

スキーマのバージョン番号をレビューします。このリリースにアップグレードできないスキーマがドメインに含まれる場合は、アップグレードを試みないでください。

個別のオブジェクト・テスト・ステータス: FAIL

準備状況チェック・テストによって、特定のオブジェクトの問題が検出されました。

失敗した問題がすべて解決されるまではアップグレードしないでください。

個別のオブジェクト・テスト・ステータス: PASS

準備状況チェック・テストによって、特定のオブジェクトの問題が検出されませんでした。

準備状況チェック・レポートにPASSステータスのみが表示されている場合、環境をアップグレードできます。ただし、準備状況チェックでは、ハードウェアやアップグレード時の接続性などの外部環境に関する問題を検出することはできません。アップグレードの進捗を常に監視する必要があります。

<オブジェクト>の完了した準備状況チェック・ステータス: FAILURE

準備状況チェックによって、スキーマ、索引、データ型など、特定のオブジェクトについての解決する必要がある1つ以上のエラーが検出されました。

FAILED問題がすべて解決されるまではアップグレードしないでください。

<オブジェクト>の完了した準備状況チェック・ステータス: SUCCESS

準備状況チェック・テストによって問題が検出されませんでした。

必要なアクションはありません。

準備状況レポート・ファイルのサンプルを次に示します。使用対象のレポートにはこれらすべてのチェックが含まれる場合や含まれない場合があります。

Upgrade readiness check completed with one or more errors.

This readiness check report was created on Tue May 30 11:15:52 EDT 2016
Log file is located at: ORACLE_HOME/oracle_common/upgrade/logs/ua2016-05-30-11-14-06AM.log
Readiness Check Report File: ORACLE_HOME/oracle_common/upgrade/logs/readiness2016-05-30-11-15-52AM.txt

Starting readiness check of components.

Oracle Metadata Services
Starting readiness check of Oracle Metadata Services.
Schema User Name: DEV11_MDS
Database Type: Oracle Database
Database Connect String: machinename@yourcompany.com
VERSION Schema DEV11_MDS is currently at version 12.1.1.1.0.  Readiness checks will now be performed.
Starting schema test:  TEST_REQUIRED_TABLES  Test that the schema contains all the required tables
Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS
Starting schema test:  TEST_REQUIRED_PROCEDURES  Test that the schema contains all the required stored procedures
EXCEPTION     Schema is missing a required procedure: GETREPOSITORYFEATURES
Completed schema test: TEST_REQUIRED_PROCEDURES --> Test that the schema contains all the required stored procedures +++ FAIL
Starting schema test:  TEST_REQUIRED_VIEWS  Test that the schema contains all the required database views
Completed schema test: TEST_REQUIRED_VIEWS --> Test that the schema contains all the required database views +++ PASS
Starting index test for table MDS_ATTRIBUTES:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_ATTRIBUTES: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting index test for table MDS_COMPONENTS:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_TXN_LOCKS: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting schema test:  TEST_REQUIRED_TRIGGERS  Test that the schema has all the required triggers
Completed schema test: TEST_REQUIRED_TRIGGERS --> Test that the schema has all the required triggers +++ PASS
Starting schema test:  TEST_MISSING_COLUMNS  Test that tables and views are not missing any required columns
Completed schema test: TEST_MISSING_COLUMNS --> Test that tables and views are not missing any required columns +++ PASS
Starting schema test:  TEST_UNEXPECTED_TABLES  Test that the schema does not contain any unexpected tables
Completed schema test: TEST_UNEXPECTED_TABLES --> Test that the schema does not contain any unexpected tables +++ PASS
Starting schema test:  TEST_UNEXPECTED_PROCEDURES  Test that the schema does not contain any unexpected stored procedures
Completed schema test: TEST_UNEXPECTED_PROCEDURES --> Test that the schema does not contain any unexpected stored procedures +++ PASS
Starting schema test:  TEST_UNEXPECTED_VIEWS  Test that the schema does not contain any unexpected views
Completed schema test: TEST_UNEXPECTED_VIEWS --> Test that the schema does not contain any unexpected views +++ PASS
Starting index test for table MDS_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Completed index test for table MDS_ATTRIBUTES: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Completed index test for table MDS_LABELS: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Starting index test for table MDS_LARGE_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Starting schema test:  TEST_UNEXPECTED_TRIGGERS  Test that the schema does not contain any unexpected triggers
Completed schema test: TEST_UNEXPECTED_TRIGGERS --> Test that the schema does not contain any unexpected triggers +++ PASS
Starting schema test:  TEST_UNEXPECTED_COLUMNS  Test that tables and views do not contain any unexpected columns
Completed schema test: TEST_UNEXPECTED_COLUMNS --> Test that tables and views do not contain any unexpected columns +++ PASS
Starting datatype test for table MDS_ATTRIBUTES:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table MDS_ATTRIBUTES: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table MDS_COMPONENTS:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Starting permissions test:  TEST_DBA_TABLE_GRANTS  Test that DBA user has privilege to view all user tables
Completed permissions test: TEST_DBA_TABLE_GRANTS --> Test that DBA user has privilege to view all user tables +++ PASS
Starting schema test:  TEST_ENOUGH_TABLESPACE  Test that the schema tablespaces automatically extend if full
Completed schema test: TEST_ENOUGH_TABLESPACE --> Test that the schema tablespaces automatically extend if full +++ PASS
Starting schema test:  TEST_USER_TABLESPACE_QUOTA  Test that tablespace quota for this user is sufficient to perform the upgrade
Completed schema test: TEST_USER_TABLESPACE_QUOTA --> Test that tablespace quota for this user is sufficient to perform the upgrade +++ PASS
Starting schema test:  TEST_ONLINE_TABLESPACE  Test that schema tablespaces are online
Completed schema test: TEST_ONLINE_TABLESPACE --> Test that schema tablespaces are online +++ PASS
Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
INFO   Database product version: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
Finished readiness check of Oracle Metadata Services with status: FAILURE.

12.1.3.0リリースのOracle Fusion Middleware IAUスキーマを実行しており、それらのスキーマが11gリリース(11.1.1.7以上)または12c (12.1.2.0)からアップグレードされた場合、準備状況チェックは次のエラーで失敗することがあります。

Starting index test for table IAU_COMMON:  TEST_REQUIRED_INDEXES --> Test
that the table contains all the required indexes
INFO Audit schema index DYN_EVENT_CATEGORY_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_EVENT_TYPE_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_TENANT_INDEX in table IAU_COMMON is missing
the required columns or index itself is missing. This maybe caused by a known
issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_USER_INDEX in table IAU_COMMON is missing
the required columns or index itself is missing. This maybe caused by a known
issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_COMPONENT_TYPE_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_USER_TENANT_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
Completed index test for table IAU_COMMON: TEST_REQUIRED_INDEXES --> Test
that the table contains all the required indexes +++ FAIL

注意:
準備状況レポートの索引欠落エラーは無視できます。これは既知の問題です。該当の欠落している索引は、スキーマ・アップグレード操作中に追加されます。アップグレードするスキーマがRCUを使用して12cで作成された場合、このエラーは発生しません。

5.5 サーバーとプロセスの停止

アップグレード・アシスタントを実行してスキーマおよび構成をアップグレードする前に、管理サーバーや管理対象サーバーを含め、すべてのプロセスとサーバーを停止する必要があります。

Oracle Fusion Middleware環境は、Oracle WebLogic Serverドメイン、管理サーバー、複数の管理対象サーバー、Javaコンポーネント、アイデンティティ管理コンポーネントなどのシステム・コンポーネント、およびメタデータのリポジトリに使用されるデータベースで構成できます。これらのコンポーネントは相互に依存する場合があるため、正しい順序で停止する必要があります。

注意:
この項の手順では、WLSTコマンドライン・ユーティリティまたはスクリプトを使用してサーバーおよびプロセスを停止する方法について説明します。Oracle Fusion Middleware ControlおよびOracle WebLogic Server管理コンソールを使用することもできます。Oracle Fusion Middlewareの管理の管理サーバー、管理対象サーバーおよびノード・マネージャの起動および停止を参照してください。

Fusion Middleware環境を停止するには、次の手順に従います。

手順1: システム・コンポーネントの停止

Oracle HTTP Serverなどのシステム・コンポーネントを停止するには、stopComponentスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

システム・コンポーネントは任意の順序で停止できます。

手順2: 管理対象サーバーの停止

WebLogic Server管理対象サーバーを停止するには、stopManagedWebLogicスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url

- (Windows) DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url

プロンプトが表示されたらユーザー名とパスワードを入力します。

手順3: Oracle Identity Managementコンポーネントの停止環境を構成しているOracle Internet DirectoryなどのOracle Identity Managementコンポーネントがあれば、それをすべて停止します。

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

ステップ4: 管理サーバーの停止

管理サーバーを停止する場合、管理サーバーで稼働しているWebLogic Server管理コンソールやFusion Middleware Controlなどのプロセスも停止します。

管理サーバーを停止するには、stopWebLogicスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/stopWebLogic.sh

- (Windows) DOMAIN_HOME\bin\stopWebLogic.cmd

プロンプトが表示されたら、管理サーバーのユーザー名とパスワードおよびURLを入力します。

注意:
リポジトリ用に外部のパスワード記憶域が設定されている場合は、アップグレード中に作業リポジトリのパスワードを取得できるように、資格証明ストアをホストしているサーバーが稼働している必要があります。詳細は、Oracle Fusion Middleware Oracle Data Integratorの管理の外部パスワード記憶域の設定を参照してください。

手順5: ノード・マネージャの停止

ノード・マネージャを停止するには、それが実行されているコマンド・シェルを閉じます。

またはnodemanager.propertiesのQuitEnabledの属性をtrueに設定した後(デフォルトはfalseです)、WLSTを使用して、ノード・マネージャに接続して停止できます。詳細は、Oracle Fusion Middleware WebLogic Server WLSTコマンド・リファレンスのstopNodeManagerを参照してください。

5.6 製品スキーマのアップグレード

サーバーおよびプロセスを停止した後、アップグレード・アシスタントを使用して、サポートされている製品スキーマを現在のリリースのOracle Fusion Middlewareにアップグレードします。

アップグレード・アシスタントを使用すると、個別に選択したスキーマまたはドメインに関連付けられているすべてのスキーマをアップグレードできます。選択したオプションによって、表示されるアップグレード・アシスタントの画面は異なります。

- アップグレード・アシスタントの起動
アップグレード・アシスタントを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。一度に1つのドメインのアップグレードを完了して、アップグレード・アシスタントを非SYSDBAユーザーとして実行することをお薦めします。

- アップグレード・アシスタントを使用した製品スキーマのアップグレード
アップグレード・アシスタントの各画面を移動して、製品スキーマをアップグレードします。

- スキーマ・アップグレードの確認
すべてのアップグレード手順の完了後、schema_version_registryのスキーマ・バージョンが正しく更新されたことを確認して、アップグレードが成功したことを確認します。

5.6.1 Upgrade Assistantの起動

アップグレード・アシスタントを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。一度に1つのドメインのアップグレードを完了して、アップグレード・アシスタントを非SYSDBAユーザーとして実行することをお薦めします。

Upgrade Assistantを起動するには、次の手順に従います。

1. oracle_common/upgrade/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. アップグレード・アシスタントを起動します。

- (UNIX) ./ua

- (Windows) ua.bat

ロギング・パラメータなど、コマンドラインで指定できるその他のパラメータの詳細は、次を参照してください。

- アップグレード・アシスタントのコマンドライン・パラメータ

5.6.1.1 アップグレード・アシスタントのコマンドライン・パラメータ

コマンドラインからアップグレード・アシスタントを起動するとき、追加パラメータを指定できます。

表5-8 アップグレード・アシスタントのコマンドライン・パラメータ

パラメータ

必須またはオプション

説明

-readiness

準備状況チェックに必須
注意: 準備状況チェックはスタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では実行できません。

実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。

スキーマおよび構成がチェックされます。

-examineパラメータを指定した場合、このパラメータを使用しないでください。

-threads

オプション

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックに必須

アップグレード・アシスタントがGUIモードで実行されたときに入力されたデータから生成されたレスポンス・ファイルに保存された入力を使用して、アップグレード・アシスタントを実行します。このパラメータを使用すると、アップグレード・アシスタントがサイレント・モードで(アップグレード・アシスタント画面を表示せずに)実行されます。

-examine

オプション

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel 属性

オプション

次のいずれかの属性を指定してロギング・レベルを設定します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

デフォルトのロギング・レベルはNOTIFICATIONです。

より多くの情報がロギングされるように-logLevel TRACE属性を設定することを検討してください。これは、失敗したアップグレードをトラブルシューティングするときに役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir 場所

オプション

アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。アップグレード・アシスタントによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

デフォルトの場所は次のとおりです。

(UNIX) ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

(Windows) ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

オプション

すべてのコマンドライン・オプションを表示します。

5.6.2 アップグレード・アシスタントを使用した製品スキーマのアップグレード

アップグレード・アシスタントの各画面を移動して、製品スキーマをアップグレードします。

注意

- 外部認証を使用している場合は、外部認証が内部認証に変更されていることを確認してください。

- エディションベースの再定義(EBR)ユーザーのみ: エディション・ベースの再定義(EBR)に対応したスキーマをアップグレードする前に、データベース・サーバーに接続して、12cのデータベース・サーバーにエディションを作成する必要があります。12cの新しいエディションは、既存の11cエディションの子である必要があります。再定義のためのサーバーでのエディション作成の詳細は、エディションベースの再定義のためのサーバー上でのエディションの作成を参照してください。

アップグレード・アシスタントで製品スキーマをアップグレードする手順は次のとおりです。

1. 「ようこそ」画面で、アップグレード・アシスタントの概要と、重要なアップグレード前のタスクに関する情報を確認します。「次へ」をクリックします

注意:
アップグレード・アシスタント画面の詳細は、画面で「ヘルプ」をクリックしてください。

2. 「選択したスキーマ」画面で、「個別に選択されたスキーマ」を選択します。

注意:
12c (12.2.1.2)コンポーネントをサポートするために使用されるスキーマのみをアップグレードしてください。Oracle Fusion Middleware 12c (12.2.1.2)に含まれていないコンポーネントをサポートするために現在使用されているスキーマはアップグレードしないでください。

「次へ」をクリックします。

3. 「使用可能なコンポーネント」画面で、マスターおよび作業リポジトリ・スキーマをアップグレードするために「Oracle Data Integrator」を選択します。

4. 「前提条件」画面ですべてのチェック・ボックスを選択して、前提条件を満たしていることを確認します。「次へ」をクリックします

注意:
アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。

5. ODIスキーマ画面で、アップグレードする各スキーマのデータベース接続の詳細を指定します。

- 「データベース・タイプ」ドロップダウン・メニューからデータベース・タイプを選択します。

- データベース接続の詳細を入力して、「接続」をクリックします。

- 「スキーマ・ユーザー名」ドロップダウン・メニューからアップグレードするスキーマを選択し、スキーマのパスワードを入力します。アップグレードするスキーマに対して正しいスキーマ接頭辞を使用してください。

6. 「ODIオプション」画面で、すべてのオプションを選択します。

表5-9 ODIのオプション

オプション

説明

ナレッジ・モジュールを必須更新で置換

これを選択すると、標準ナレッジ・モジュールが最新バージョンに置き換えられます。Oracleによりインストールされたナレッジ・モジュールに対するカスタマイズ内容は上書きされます。ただし、インストールされたナレッジ・モジュールをコピーしてからそのナレッジ・モジュールをカスタマイズした場合、カスタマイズ内容は失われません。

トポロジおよびセキュリティ・メタデータのアップグレード

これを選択すると、テクノロジ、データ型、セキュリティ・プロファイルなどのトポロジおよびセキュリティ・アーティファクトが最新バージョンに置き換えられます。インストールされたオブジェクトのカスタマイズ内容は上書きされます。オブジェクトをコピーしてからカスタマイズした場合、カスタマイズ内容は失われません。

高度なアップグレード・オプションの詳細は、「高度なアップグレード・オプション」を参照してください。

7. 「ODIスーパーバイザ」画面に、アップグレードするODIリポジトリのスーパーバイザ・アカウント資格証明を入力します。

インストールされているスーパーバイザ・アカウントはSUPERVISORです。ODIのマスター・リポジトリおよび作業リポジトリの作成時にリポジトリ作成ユーティリティ(RCU)で求められたときに指定した、正しいスーパーバイザ・アカウント名およびパスワードについては、ODI管理者に確認してください。

注意:
「ドメインで使用されるすべてのスキーマ」が選択されている場合、ODIのスーパーバイザ資格証明はドメインに含まれていないため、最初のインスタンスにあらかじめ移入されません。複数のODIスキーマがある場合、アップグレード・アシスタントは最初の資格証明のセットを使用してユーザー・エントリに移入します。

8. 「ODIアップグレード・キー」画面で、自動生成されたアップグレード・キーを使用して、リポジトリ・オブジェクトの11g IDを一意のGUIDに変換するか、独自のキーを「アップグレード・キー」フィールドに指定します。

推奨事項

- 自動生成されたキーを編集して、覚えやすい意味のあるキーを指定します。

- ODIオブジェクトがXMLファイルからインポートされるときに同じアップグレード・キーを指定できるように、アップグレード・キーを書き留めます。

ODIオブジェクトは、ODIリポジトリ、ならびにこうしたリポジトリからエクスポートされたXMLファイルに存在し、リポジトリ間のメタデータ交換などで使用できます。そのため、同一オブジェクトの複数のコピーが異なるリポジトリおよびXMLファイルに含まれる場合があります。

12cでは、ODIはオブジェクト識別に数字の内部IDではなくGUIDを使用します。アップグレード後にオブジェクトIDが保持されるようにするため、決定性アルゴリズムが適用され、既存のオブジェクトの内部IDからGUIDが計算されます(新規オブジェクトの場合、ODIにより無作為のGUIDが生成されます)。

数字の内部IDが実際にはユニバーサルに一意ではなく、疑似的な一意性を実現するためにリポジトリIDに依存していたため、ODIではユーザーがアップグレード・キーを指定して、重複したGUIDが生成される可能性を下げることができます。アップグレード・キーが数字の内部IDとともにGUID生成アルゴリズムに提供され、GUIDが計算されます。

このように異なるアップグレード・キーを選択することで、偶然同じ数字の内部IDを持つオブジェクトについて重複したGUIDを取得せずに済みます。ただし、同じオブジェクトの複数のコピーが(リポジトリ内に、またはXMLファイルにエクスポートされて)存在する場合、オブジェクトのすべてのコピーに対して同じGUIDが生成される必要があります。そのため、その特定のオブジェクトのコピーに関係するすべてのアップグレード操作に対して、同じアップグレード・キーを使用する必要があります。

たとえば、11gリポジトリにIDとして1001を持つプロジェクトがあり、また同じリポジトリからエクスポートされたファイルに、同じプロジェクト(ID = 1001)が含まれるとします。この場合、リポジトリのアップグレードに使用されるアップグレード・キーは、アップグレード済の12cリポジトリにXMLファイルをインポートする際に使用されるアップグレード・キーと同じである必要があります。これによって、インポート・ファイルのプロジェクト・オブジェクトは、リポジトリのプロジェクト・オブジェクトと正しく一致します(いずれかのSYNONYMインポート・モードを使用した場合)。ただし、別のリポジトリで作成されたオブジェクトを含むソースから11g XMLエクスポート・ファイルが提供され、そのリポジトリの情報がない場合、偶然同じ内部ID (1001)を持つプロジェクトが含まれている可能性があります。この場合、誤ったオブジェクトの一致によるメタデータの破損を防ぐため、そのファイルをリポジトリにインポートする際には、別のカスタム・アップグレード・キーを使用する必要があります。

9. 「調査」画面で、各スキーマを調査した際のアップグレード・アシスタントのステータスを確認し、スキーマのアップグレード準備が整っていることを確認します。ステータスが「調査が終了しました。」になっている場合は、「次へ」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、共通するアップグレード・エラーの解決に関する情報をOracle Fusion Middleware Upgrade Assistantによるアップグレードのアップグレードのトラブルシューティングで参照します。

注意:

- 調査フェーズの間に、アップグレードを続行せずに検出された問題を解決した場合は、バックアップからリストアすることなしに、アップグレード・アシスタントを再起動できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックして続行した場合は、アップグレード・アシスタントを再起動する前に、アップグレード前の環境をバックアップからリストアする必要があります。

- 調査プロセスを取り消してもスキーマまたは構成データに影響はありませんが、将来のアップグレード・セッションでは、Upgrade Assistantが収集した情報を再収集する必要があります。

10. 「アップグレード・サマリー」画面で、スキーマ・アップグレードに選択したオプションのサマリーを確認します。
正しいソース・バージョンとターゲット・バージョンが、アップグレード対象の各スキーマにリストされていることを確認します。

後でアップグレード・アシスタントをレスポンス(またはサイレント)モードで再び実行するためにこれらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックして、レスポンス・ファイルの場所および名前を指定します。サイレント・アップグレードは、アップグレード・アシスタント・とまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。

11. 「アップグレードの進行状況」画面でアップグレードのステータスを監視します。

注意:
アップグレード・アシスタントにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。これを行うと、環境が不安定になる可能性があります。

正しくアップグレードされていないスキーマがある場合は、アップグレード・アシスタントのログ・ファイルで情報を確認します。

注意:
この画面の進捗バーには、現在のアップグレード手順の進行状況が表示されます。アップグレードの残り時間を示すものではありません。

「次へ」をクリックします。

12. アップグレードが成功した場合、「アップグレード成功」画面で「閉じる」をクリックし、アップグレードを完了してウィザードを閉じます。

アップグレードが失敗した場合、「アップグレード失敗」画面で「ログの表示」をクリックし、エラーを表示してトラブルシューティングします。ログはORACLE_HOME/oracle_common/upgrade/logsにあります。

注意:
アップグレードに失敗した場合、アップグレード前の環境をバックアップからリストアし、問題を修正して、アップグレード・アシスタントを再起動する必要があります。

5.6.3 スキーマのアップグレードの確認

すべてのアップグレード手順の完了後、schema_version_registryのスキーマ・バージョンが正しく更新されたことを確認して、アップグレードが成功したことを確認します。

Oracle Databaseを使用する場合、Oracle DBAを持つユーザーとしてデータベースに接続し、SQL*Plusから次を実行して現行のバージョン番号を取得します。

SET LINE 120
COLUMN MRC_NAME FORMAT A14
COLUMN COMP_ID FORMAT A20
COLUMN VERSION FORMAT A12
COLUMN STATUS FORMAT A9
COLUMN UPGRADED FORMAT A8
SELECT MRC_NAME, COMP_ID, OWNER, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY ORDER BY MRC_NAME, COMP_ID ;

問合せ結果:

- VERSION列の数値が、そのスキーマの最新のバージョン番号に一致していることを確認します。たとえば、スキーマ・バージョン番号が12.2.1.2.0であることを確認します。ただし、すべてのスキーマ・バージョンが更新されるわけではないことに注意してください。一部のスキーマではこのリリースへのアップグレードが必要なく、アップグレード前のバージョン番号が保持されます。

- STATUSフィールドは、スキーマのパッチ適用操作中は「UPGRADING」または「UPGRADED」に、操作が完了すると「VALID」になります。

- ステータスが「INVALID」と表示された場合は、ステータスの更新が失敗しています。ログ・ファイルを調べて、失敗した理由を判定する必要があります。

- IAU_APPENDおよびIAU_VIEWERによって所有されるシノニム・オブジェクトは、INVALIDとして表示されますが、失敗を示すものではありません。
それらは、シノニムの作成後にターゲット・オブジェクトが変更されるため無効になります。シノニム・オブジェクトはアクセスされると有効になります。これらのINVALIDオブジェクトは無視しても問題ありません。

5.7 ドメインの再構成

再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.2)に再構成します。

WebLogic Serverドメインを再構成する場合は、ドメイン内のアプリケーションに応じて次の項目が自動的に更新されます。

- WebLogic Serverコア・インフラストラクチャ

- ドメイン・バージョン

注意:

ドメインの再構成を開始する前に、次の制限に注意してください。

- 再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。

- アップグレード・プロセス中に非動的クラスタ・ドメインを動的クラスタ・ドメインに変換することはサポートされていません。
動的クラスタ機能は再構成ウィザードの実行中は使用できますが、非動的クラスタをアップグレードしてから動的クラスタを追加することのみがサポートされています。アップグレード・プロセス中に動的クラスタを追加することはできません。

具体的には、ドメインを再構成すると、次のようになります。

- ドメインのconfig.xmlファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンに更新されます。

- すべてのインストール済Oracle製品の再構成テンプレートは、自動的に選択されてドメインに適用されます。これらのテンプレートは、WebLogicドメインが現在のWebLogic Serverバージョンと互換性を持つために必要な再構成タスクを定義します。

- 起動スクリプトが更新されます。
変更した起動スクリプトを保持する場合、再構成ウィザードを起動する前にそのスクリプトをバックアップしてください。

注意:
ドメインの再構成プロセスを開始すると、元に戻すことはできません。再構成ウィザードを実行する前に、アップグレード前チェックリストで示されているようにドメインをバックアップしたことを確認してください。再構成ウィザードの実行中にエラーまたは他の割込みが発生した場合、バックアップ場所から元のドメイン・ディレクトリにファイルとディレクトリをコピーすることによって、ドメインをリストアする必要があります。これは、再構成前にドメインを確実に元の状態に戻す唯一の方法です。

再構成ウィザードを使用して既存のドメインを再構成する手順に従います。ドメインの再構成に関する一般情報は、Oracle Fusion Middleware Oracle WebLogic ServerのアップグレードのWebLogicドメインの再構成を参照してください。

- ドメインのバックアップ

- 再構成ウィザードの起動

- 再構成ウィザードを使用したドメインの再構成

5.7.1 ドメインのバックアップ

再構成ウィザードを実行する前に、ドメイン・ディレクトリのバックアップ・コピーを作成します。

ドメイン・ディレクトリのバックアップを作成する手順は次のとおりです。

1. コンテンツを保持するには、ソース・ドメインを別の場所にコピーします。
たとえば、C:\domains\mydomainをC:\domains\mydomain_backupにコピーします。

2. 各リモート管理対象サーバーのドメインを更新する前に、各リモート・マシンのドメイン・ディレクトリのバックアップ・コピーを作成します。

3. ドメインのバックアップしたバージョンが完全であることを確認します。

ドメインの再構成がなんらかの理由で失敗した場合は、再構成を実行する前に、すべてのファイルおよびディレクトリをバックアップ・ディレクトリから元のドメイン・ディレクトリにコピーしてドメインを完全に元の状態に戻す必要があります。

5.7.2 再構成ウィザードの起動

再構成ウィザードをグラフィカル・モードで起動する手順は次のとおりです。

1. ドメインが存在するシステムにサインインします。

2. コマンド・シェル(UNIXオペレーティング・システムの場合)またはコマンド・プロンプト・ウィンドウ(Windowsオペレーティング・システムの場合)を開きます。

3. エディション・ベースのデータベース・ユーザーのみ: スキーマがEBRデータベースを使用して構成されている場合、再構成ウィザードを実行する前に、手動でデフォルトのエディション名を設定する必要があります。
次のSQLコマンドを実行して、デフォルト・エディションを設定します。
ALTER DATABASE DEFAULT EDITION = edition_name;

ここで、edition_nameは、子エディション名です。

4. oracle_common/common/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/common/bin

- (Windows) ORACLE_HOME\oracle_common\commom\bin

5. 再構成ウィザードを次のロギング・オプションとともに起動します。

- (UNIX) ./reconfig.sh -log=log_file -log_priority=ALL

- (Windows) reconfig.cmd -log=log_file -log_priority=ALL

log_fileは、ドメイン再構成セッション用に作成するログ・ファイルの絶対パスです。これは、再構成処理をトラブルシューティングする必要がある場合に役立つことがあります。

パラメータ-log_priority=ALLは、ログを詳細モードで出力します。

注意:

このコマンドを実行すると、デフォルトのキャッシュ・ディレクトリが無効であることを示す次のエラー・メッセージが表示される場合があります。

*sys-package-mgr*: can't create package cache dir

環境変数CONFIG_JVM_ARGSを設定することでキャッシュ・ディレクトリを変更できます。次に例を示します。

CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

5.7.3 再構成ウィザードを使用したドメインの再構成

アップグレード・アシスタントを実行する前に、再構成ウィザードの各画面を移動して既存のドメインを再構成します。

注意:
ソースがクラスタ環境である場合は、再構成ウィザードをプライマリ・ノードでのみ実行します。packおよびunpackユーティリティを使用して、ドメイン内の他のクラスタ・メンバーに変更を適用します。

再構成ウィザードを使用してドメインを再構成する手順は次のとおりです。

1. 「ドメインの選択」画面で、アップグレードするドメインの場所を指定するか、「参照」をクリックしてナビゲートし、ドメインのディレクトリを選択します。「次へ」をクリックします。

2. 「再構成セットアップの進行状況」画面で、設定プロセスの進行状況を表示します。完了したら、「次へ」をクリックします。
このプロセスでは次の処理が行われます。

- Fusion Middleware製品を含む、インストール済製品の再構成テンプレートが自動的に適用されます。これにより、config.xml、config-groups.xml、security.xmlなどの様々なドメイン構成ファイルが更新されます。

- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

- ドメイン・アップグレードが検証されます。

3. 「ドメイン・モードおよびJDK」画面で、ドメインで使用するJDKを選択するか、「参照」をクリックして、使用するJDKにナビゲートします。12c (12.2.1.2)に対してサポートされているJDKバージョンは1.8.0_101以上です。「次へ」をクリックします。

注意:
このステージでは、「ドメイン・モード」を変更することはできません。

特定のプラットフォームでサポートされているJDKのリストは、Oracle Fusion Middlewareでサポートされているシステム構成の説明を参照してください。

4. 「データベース構成タイプ」画面で、「RCUデータ」を選択してサービス表(_STB)スキーマに接続します。
RCUサービス表(_STB)スキーマ資格証明を使用してデータベース接続の詳細を入力するか、「RCU構成の取得」をクリックします。

再構成ウィザードは、この接続を使用して、ドメインのコンポーネントに必要なデータソースを自動的に構成します。
注意: 既存の11gデータ・ソースの場合、再構成では既存の値が保持されます。スキーマがRCUによって12c用に作成された新しいデータ・ソースの場合、デフォルトの接続データは_STBスキーマから取得されます。特定のスキーマの接続データが_STBスキーマにない場合は、デフォルトの接続データが使用されます。

チェックが成功した場合は、「次へ」をクリックします。チェックが失敗した場合は、接続の正しい詳細を再入力し、再試行します。

5. 「JDBCコンポーネント・スキーマ」画面で、各コンポーネント・スキーマのDBMS/サービスおよびホスト名が正しいことを確認し、「次へ」をクリックします。

6. 「JDBCコンポーネント・スキーマ・テスト」画面で、すべてのコンポーネント・スキーマを選択して「選択された接続のテスト」をクリックし、各スキーマの接続をテストします。テストの結果は、「ステータス」列に表示されます。
チェックが完了したら、「次へ」をクリックします。

7. 「拡張構成」画面で、拡張構成を実行するすべてのカテゴリを選択できます。選択したカテゴリごとに、詳細構成を行うことができる適切な構成画面が表示されます。

注意:
「拡張構成」画面にリストされるカテゴリは、ドメインに選択したテンプレートに定義されているリソースによって異なります。

このアップグレードではオプションを選択せずに、「次へ」をクリックします。

8. 「構成のサマリー」画面で、ドメインの詳細な構成設定を確認してから続行します。
「表示」ドロップダウン・リストからフィルタ・オプションを選択すると、右側のパネルに表示される項目を制限できます。

構成を変更するには、「戻る」をクリックして適切な画面に戻ります。ドメインを再構成するには、「再構成」をクリックします。

注意:
ドメインを再構成しても、その場所は変更されません。

9. 「再構成の進行状況」画面には、再構成プロセスの進行状況が表示されます。
このプロセスでは次の処理が行われます。

- ドメイン情報が抽出、保存および更新されます。

- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

進捗バーが100%になったら、「次へ」をクリックします。

10. 「構成の終了」画面には、再構成プロセスが正常に完了したか失敗したかが示されます。管理サーバーURL(リスニング・ポートを含む)とともに再構成されたドメインの場所も表示します。再構成が成功した場合は、「Oracle Weblogic Serverの再構成に成功しました」と表示されます。
再構成プロセスが正常に完了しなかった場合は、その理由を示すエラー・メッセージが表示されます。問題を解決するための適切な措置を講じます。問題を解決できない場合は、My Oracle Supportに連絡してください。

以後の操作のためにドメインの場所と管理サーバーURLをメモします。

5.8 ドメイン・コンポーネント構成のアップグレード

ドメインの再構成後、アップグレード・アシスタントを使用して、ドメイン内のドメイン・コンポーネント構成を更新済ドメイン構成に一致するようにアップグレードします。

- アップグレード・アシスタントの起動
アップグレード・アシスタントを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。一度に1つのドメインのアップグレードを完了して、アップグレード・アシスタントを非SYSDBAユーザーとして実行することをお薦めします。

- アップグレード・アシスタントを使用したドメイン・コンポーネント構成のアップグレード
アップグレード・アシスタントの各画面を移動して、WebLogicドメイン内のコンポーネント構成をアップグレードします。

5.8.1 Upgrade Assistantの起動

アップグレード・アシスタントを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。一度に1つのドメインのアップグレードを完了して、アップグレード・アシスタントを非SYSDBAユーザーとして実行することをお薦めします。

Upgrade Assistantを起動するには、次の手順に従います。

1. oracle_common/upgrade/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. アップグレード・アシスタントを起動します。

- (UNIX) ./ua

- (Windows) ua.bat

ロギング・パラメータなど、コマンドラインで指定できるその他のパラメータの詳細は、次を参照してください。

- アップグレード・アシスタントのコマンドライン・パラメータ

5.8.1.1 アップグレード・アシスタントのコマンドライン・パラメータ

コマンドラインからアップグレード・アシスタントを起動するとき、追加パラメータを指定できます。

表5-10 アップグレード・アシスタントのコマンドライン・パラメータ

パラメータ

必須またはオプション

説明

-readiness

準備状況チェックに必須
注意: 準備状況チェックはスタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では実行できません。

実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。

スキーマおよび構成がチェックされます。

-examineパラメータを指定した場合、このパラメータを使用しないでください。

-threads

オプション

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックに必須

アップグレード・アシスタントがGUIモードで実行されたときに入力されたデータから生成されたレスポンス・ファイルに保存された入力を使用して、アップグレード・アシスタントを実行します。このパラメータを使用すると、アップグレード・アシスタントがサイレント・モードで(アップグレード・アシスタント画面を表示せずに)実行されます。

-examine

オプション

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel 属性

オプション

次のいずれかの属性を指定してロギング・レベルを設定します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

デフォルトのロギング・レベルはNOTIFICATIONです。

より多くの情報がロギングされるように-logLevel TRACE属性を設定することを検討してください。これは、失敗したアップグレードをトラブルシューティングするときに役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir 場所

オプション

アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。アップグレード・アシスタントによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

デフォルトの場所は次のとおりです。

(UNIX) ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

(Windows) ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

オプション

すべてのコマンドライン・オプションを表示します。

5.8.2 アップグレード・アシスタントを使用したドメイン・コンポーネント構成のアップグレード

アップグレード・アシスタントの各画面を移動して、WebLogicドメイン内のコンポーネント構成をアップグレードします。

再構成ウィザードを実行してWebLogicドメインを12c (12.2.1.2)に再構成した後、アップグレード・アシスタントを実行して、ドメイン・コンポーネント構成を更新済ドメイン構成に一致するようにアップグレードする必要があります。

アップグレード・アシスタントを使用してドメイン・コンポーネント構成をアップグレードする手順は次のとおりです。

1. 「ようこそ」画面で、アップグレード・アシスタントの概要と、重要なアップグレード前のタスクに関する情報を確認します。「次へ」をクリックします

注意:
アップグレード・アシスタント画面の詳細は、画面で「ヘルプ」をクリックしてください。

2. 次の画面で次のようにします。

- 「ドメインによって使用されるすべての構成」を選択します。画面名は「WebLogicコンポーネント」になります。

- 「ドメイン・ディレクトリ」フィールドにWebLogicドメイン・ディレクトリ・パスを入力します。

「次へ」をクリックします。

3. 「コンポーネント・リスト」画面で、構成をアップグレードするすべてのコンポーネントがリストに含まれていることを確認して「次へ」をクリックします。
アップグレード対象のコンポーネントが表示されていない場合は、「戻る」をクリックして前の画面に戻り、別のドメインを指定します。

4. 「前提条件」画面ですべてのチェック・ボックスを選択して、前提条件を満たしていることを確認します。「次へ」をクリックします

注意:
アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。

5. 「調査」画面で、各コンポーネントを調査した際のアップグレード・アシスタントのステータスを確認し、コンポーネント構成のアップグレード準備が整っていることを確認します。ステータスが「調査が終了しました。」になっている場合は、「次へ」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、共通するアップグレード・エラーの解決に関する情報をOracle Fusion Middleware Upgrade Assistantによるアップグレードのアップグレードのトラブルシューティングで参照します。

注意:

- 調査フェーズの間に、アップグレードを続行せずに検出された問題を解決した場合は、バックアップからリストアすることなしに、アップグレード・アシスタントを再起動できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックして続行した場合は、アップグレード・アシスタントを再起動する前に、アップグレード前の環境をバックアップからリストアする必要があります。

- 調査プロセスを取り消しても構成データに影響はありませんが、将来のアップグレード・セッションでは、アップグレード・アシスタントが収集した情報を再収集する必要があります。

6. 「アップグレード・サマリー」画面で、コンポーネント構成アップグレードに選択したオプションのサマリーを確認します。
レスポンス・ファイルには、入力したすべての情報が収集して格納され、後でサイレント・アップグレードを実行するために使用できます。サイレント・アップグレードは、アップグレード・アシスタント・とまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。

7. 「アップグレードの進行状況」画面でアップグレードのステータスを監視します。

注意:
アップグレード・アシスタントにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。これを行うと、環境が不安定になる可能性があります。

正しくアップグレードされていないコンポーネントがある場合は、Upgrade Assistantのログ・ファイルで情報を確認します。

注意:
この画面の進捗バーには、現在のアップグレード手順の進行状況が表示されます。アップグレードの残り時間を示すものではありません。

「次へ」をクリックします。

8. アップグレードが成功した場合、「アップグレード成功」画面で「閉じる」をクリックし、アップグレードを完了してウィザードを閉じます。新規インストールでコンポーネントを機能させるために手動で実行する必要のあるタスクが、アップグレード後のアクションのウィンドウに表示されます。このウィンドウは、コンポーネントにアップグレード後の手順がある場合にのみ表示されます。

アップグレードが失敗した場合、「アップグレード失敗」画面で「ログの表示」をクリックし、エラーを表示してトラブルシューティングします。ログはORACLE_HOME/oracle_common/upgrade/logsにあります。

注意:
アップグレードに失敗した場合、アップグレード前の環境をバックアップからリストアし、問題を修正して、アップグレード・アシスタントを再起動する必要があります。

5.9 サーバーおよびプロセスの起動

アップグレードが成功した後、管理サーバーおよび管理対象サーバーを含め、すべてのプロセスおよびサーバーを再起動します。

これらのコンポーネントは相互に依存する場合があるため、正しい順序で起動する必要があります。

注意:
この項の手順では、WLSTコマンドラインまたはスクリプトを使用してサーバーおよびプロセスを起動する方法について説明します。Oracle Fusion Middleware ControlおよびOracle WebLogic Server管理コンソールを使用することもできます。Oracle Fusion Middlewareの管理の管理サーバー、管理対象サーバーおよびノード・マネージャの起動および停止を参照してください。

Fusion Middleware環境を起動するには、次の手順に従います。

ステップ1: 管理サーバーの起動

管理サーバーを起動する場合、管理サーバーで稼働しているWebLogic Server管理コンソールやFusion Middleware Controlなどのプロセスも起動します。

管理サーバーを起動するには、startWebLogicスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/startWebLogic.sh

- (Windows) DOMAIN_HOME\bin\startWebLogic.cmd

プロンプトが表示されたら、管理サーバーのユーザー名とパスワードおよびURLを入力します。

手順2: ノード・マネージャの起動

ノード・マネージャを起動するには、startNodeManagerスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/startNodeManager.sh

- (Windows) DOMAIN_HOME\bin\startNodeManager.cmd

手順3: Oracle Identity Managementコンポーネントの起動環境を構成しているOracle Internet DirectoryなどのOracle Identity Managementコンポーネントがあれば、それをすべて起動します。

- (UNIX) DOMAIN_HOME/bin/startComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\startComponent.cmd component_name

手順4: 管理対象サーバーの起動

WebLogic Server管理対象サーバーを起動するには、startManagedWebLogicスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

- (Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url

プロンプトが表示されたらユーザー名とパスワードを入力します。

注意:
通常は、管理対象サーバーの起動により、それにデプロイされているアプリケーションが開始されます。したがって、管理対象サーバーの起動後にアプリケーションを手動で開始する必要はありません。

手順5: システム・コンポーネントの起動

Oracle HTTP Serverなどのシステム・コンポーネントを起動するには、startComponentスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/startComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\startComponent.cmd component_name

システム・コンポーネントは任意の順序で起動できます。

第III部 Oracle Data Integratorの前の12cリリースからのアップグレード

Oracle Fusion Middleware Oracle Data Integratorのアップグレードのこの部では、前の12cリリースからのOracle Data Integratorのアップグレードに関する情報を提供します。

注意:
前の12cリリースからのアップグレードには、11gからのアップグレード時に使用したものとは異なるセットのアップグレード手順が含まれます。12.1.2.0、12.1.3.0、12.2.1.0、12.2.1.1など、前の12cリリースからアップグレードする場合、フル・アップグレードを実行して12c (12.2.1.2)にします。

- Oracle Data Integratorスタンドアロン・エージェント環境の前の12cリリースからのアップグレード
WebLogicドメイン内に構成されていないOracle Data Integratorスタンドアロン・エージェント環境を前のOracle Fusion Middleware 12cリリースから12c (12.2.1.2)にアップグレードできます。

- Oracle Data Integratorスタンドアロン・コロケート・エージェント環境の前の12cリリースからのアップグレード
WebLogicドメイン内に構成されているOracle Data Integratorスタンドアロン・エージェント環境を前のOracle Fusion Middleware 12cリリースから12c (12.2.1.2)にアップグレードできます。

- Oracle Data Integrator Java EEエージェント環境の前の12cリリースからのアップグレード
Oracle Data Integrator Java EEエージェント環境を前のOracle Fusion Middleware 12cリリースから12c (12.2.1.2)にアップグレードできます。

6 Oracle Data Integratorスタンドアロン・エージェント環境の前の12cリリースからのアップグレード

WebLogicドメイン内に構成されていないOracle Data Integratorスタンドアロン・エージェント環境を前のOracle Fusion Middleware 12cリリースから12c (12.2.1.2)にアップグレードできます。

- Oracle Data Integratorスタンドアロン・エージェントのアップグレード・プロセスについて
WebLogicドメイン内に構成されていないOracle Data Integratorスタンドアロン・エージェントのアップグレード・プロセスの概要を示すフローチャートおよびロードマップを確認します。

- Oracle Data Integratorスタンドアロン・エージェント環境のインストール
アップグレードを開始する前に、Oracle Data Integrator 12c (12.2.1.2)ディストリビューションをターゲット・システムにダウンロードし、Oracle Universal Installerを使用してインストールします。

- サーバーおよびプロセスの停止
アップグレード・アシスタントを実行してスキーマおよび構成をアップグレードする前に、管理サーバーや管理対象サーバーを含め、すべてのプロセスとサーバーを停止する必要があります。

- 製品スキーマのアップグレード
サーバーおよびプロセスを停止した後、アップグレード・アシスタントを使用して、サポートされている製品スキーマを現在のリリースのOracle Fusion Middlewareにアップグレードします。

- スタンドアロン・システム・コンポーネント構成のアップグレード
アップグレード・アシスタントを使用して、スタンドアロン・システム・コンポーネント構成をアップグレードします。

- サーバーおよびプロセスの起動
アップグレードが成功した後、管理サーバーおよび管理対象サーバーを含め、すべてのプロセスおよびサーバーを再起動します。

親トピック: Oracle Data Integratorの前の12cリリースからのアップグレード

6.1 Oracle Data Integratorスタンドアロン・エージェントのアップグレード・プロセスについて

WebLogicドメイン内に構成されていないOracle Data Integratorスタンドアロン・エージェントのアップグレード・プロセスの概要を示すフローチャートおよびロードマップを確認します。

表6-1 Oracle Data Integratorスタンドアロン・エージェントを前の12cリリースからアップグレードするためのタスク

タスク

説明

必須

このガイドの概要のトピックをまだ確認していない場合は確認し、必要なアップグレード前のタスクを完了します。

次を参照してください。

- Oracle Data Integratorの12c (12.2.1.2)へのアップグレードの概要

- アップグレード前の要件

必須

Oracle Data Integratorスタンドアロン12c (12.2.1.2)を新しいOracleホームにインストールします。

製品ソフトウェアを新しいOracleホームにインストールします。

Oracle Data Integratorスタンドアロン・エージェント環境のインストールを参照してください。

必須

12c環境を停止します(すべての管理サーバーと管理対象サーバーを停止します)。

警告: アップグレード中にサーバーを停止しないと、データが破壊される可能性があります。

「サーバーとプロセスの停止」を参照

必須

アップグレード・アシスタントを起動して、データベース・スキーマをアップグレードし、すべてのアクティブ(進行中の)インスタンス・データを移行します。

製品スキーマのアップグレードを参照してください。

注意: アクティブ・インスタンス・データのアップグレードは、アップグレード・アシスタントの実行中に自動で開始されます。データが正常に新しい12c (12.2.1.2)環境にアップグレードされたら、アップグレード・アシスタントを終了してもかまいません。クローズされたインスタンスのアップグレードは、バックグランド・プロセスで継続されます。

必須

アップグレード・アシスタントを(再度)起動して、スタンドアロン・システム・コンポーネント構成をアップグレードします。

アップグレード・アシスタントを実行して、スタンドアロン・エージェントのコンポーネント構成をアップグレードします。

スタンドアロン・システム・コンポーネント構成のアップグレードを参照してください。

必須

サーバーおよび12c (12.2.1.2)インスタンスを再起動します。

アップグレード・プロセスが完了したら、12c (12.2.1.2)インスタンスを再起動します。

サーバーおよびプロセスの起動を参照してください。

必須

アップグレードを確認します。

バックアップを削除する前に、アップグレードしたコンポーネントがすべて期待どおりに動作していることを確認します。

6.2 Oracle Data Integratorスタンドアロン・エージェント環境のインストール

アップグレードを開始する前に、Oracle Data Integrator 12c (12.2.1.2)ディストリビューションをターゲット・システムにダウンロードし、Oracle Universal Installerを使用してインストールします。

12c (12.2.1.2)ディストリビューションをインストールする手順は次のとおりです。

1. 12c (12.2.1.2)製品ディストリビューションをインストールするターゲット・システムにサインインします。

2. 次の12c (12.2.1.2)製品ディストリビューションをOracle Technology NetworkまたはOracle Software Delivery Cloudからターゲット・システムにダウンロードします。

- Oracle Data Integrator (fmw_12.2.1.2.0_odi_Disk1_1of2.zipおよびfmw_12.2.1.2.0_odi_Disk1_2of2.zip )

3. 12c (12.2.1.2)製品のディストリビューションをダウンロードしたディレクトリに移動します。

4. インストールfmw_12.2.1.2.0_odi_Disk1_1of2.zipおよびfmw_12.2.1.2.0_odi_Disk1_2of2.zipファイルを解凍します。

5. 次のコマンドを入力して製品ディストリビューションのインストーラを起動し、前述の手順を繰り返してインストーラの各画面を移動します。
(UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.2.0_odi_generic.jar

(Windows) JDK_HOME\bin\java -jar fmw_12.2.1.2.0_odi_generic.jar

6. UNIXオペレーティング・システムでは、このホストにOracle製品を初めてインストールする場合に、「インストール・インベントリの設定」画面が表示されます。
中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システム・グループ名に対して中央インベントリの場所への書込み権限が付与されていることを確認し、「次へ」をクリックします。

注意:
「インストール・インベントリの設定」画面は、Windowsオペレーティング・システムでは表示されません。

7. 「ようこそ」画面で、情報をレビューしてすべての前提条件を満たしていることを確認します。「次へ」をクリックします

8. 「自動更新」画面で「自動更新をスキップ」を選択します。オプションは次のとおりです。

- この時点でソフトウェアの更新をシステムで確認しないようにする場合は、「自動更新をスキップ」を選択します。

- パッチ・ファイルをダウンロードした場合は、「ディレクトリからパッチを選択」を選択して、ローカル・ディレクトリに移動します。

- My Oracle Supportアカウントを持っている場合にソフトウェアの更新を自動でダウンロードするには、「My Oracle Supportで更新を検索」を選択します。Oracle Supportの資格証明を入力して、「検索」をクリックします。インストーラがMy Oracle Supportにアクセスするようにプロキシ・サーバーを構成するには、「プロキシ設定」をクリックします。「接続のテスト」をクリックして接続をテストします。

「次へ」をクリックします。

9. 「インストールの場所」画面でOracleホーム・ディレクトリの場所を指定し、「次へ」をクリックします。
Oracle Fusion Middlewareディレクトリ構造の詳細は、Oracle Fusion Middleware Oracle Fusion Middlewareのインストールのプランニングのインストールおよび構成のためのディレクトリの理解を参照してください。

10. 「インストール・タイプ」画面で、「スタンドアロン・インストール」を選択します。
「次へ」をクリックします。

11. 「前提条件チェック」画面では、ホスト・コンピュータを分析して、特定のオペレーティング・システムの前提条件を満たしているか確認します。
確認されたタスクのリストを表示するには、「正常なタスクの表示」を選択します。ログの詳細を表示するには、「ログの表示」を選択します。前提条件のチェックが失敗すると、エラー・メッセージが画面の下方に表示されます。エラーを修正し、「再実行」をクリックして再試行します。エラー・メッセージや警告メッセージを無視してインストールを続けるには、「スキップ」をクリックします(非推奨)。

12. 「インストールの概要」画面で、選択したインストール・オプションを確認します。
これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を入力します。レスポンス・ファイルには、入力したすべての情報が収集して格納され、後で(コマンドラインから)サイレント・インストールを実行するために使用できます。
「インストール」をクリックしてインストールを開始します。

13. 「インストールの進行状況」画面で進捗バーが100%になったら、「終了」をクリックしてインストーラを閉じるか、「次へ」をクリックしてサマリーを確認します。

14. 「インストール完了」画面に、インストールの場所とインストールされた機能セットが表示されます。情報を確認し、「終了」をクリックしてインストーラを閉じます。

6.3 サーバーとプロセスの停止

アップグレード・アシスタントを実行してスキーマおよび構成をアップグレードする前に、管理サーバーや管理対象サーバーを含め、すべてのプロセスとサーバーを停止する必要があります。

Oracle Fusion Middleware環境は、Oracle WebLogic Serverドメイン、管理サーバー、複数の管理対象サーバー、Javaコンポーネント、アイデンティティ管理コンポーネントなどのシステム・コンポーネント、およびメタデータのリポジトリに使用されるデータベースで構成できます。これらのコンポーネントは相互に依存する場合があるため、正しい順序で停止する必要があります。

注意:
この項の手順では、WLSTコマンドライン・ユーティリティまたはスクリプトを使用してサーバーおよびプロセスを停止する方法について説明します。Oracle Fusion Middleware ControlおよびOracle WebLogic Server管理コンソールを使用することもできます。Oracle Fusion Middlewareの管理の管理サーバー、管理対象サーバーおよびノード・マネージャの起動および停止を参照してください。

Fusion Middleware環境を停止するには、次の手順に従います。

手順1: システム・コンポーネントの停止

Oracle HTTP Serverなどのシステム・コンポーネントを停止するには、stopComponentスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

システム・コンポーネントは任意の順序で停止できます。

手順2: 管理対象サーバーの停止

WebLogic Server管理対象サーバーを停止するには、stopManagedWebLogicスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url

- (Windows) DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url

プロンプトが表示されたらユーザー名とパスワードを入力します。

手順3: Oracle Identity Managementコンポーネントの停止環境を構成しているOracle Internet DirectoryなどのOracle Identity Managementコンポーネントがあれば、それをすべて停止します。

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

ステップ4: 管理サーバーの停止

管理サーバーを停止する場合、管理サーバーで稼働しているWebLogic Server管理コンソールやFusion Middleware Controlなどのプロセスも停止します。

管理サーバーを停止するには、stopWebLogicスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/stopWebLogic.sh

- (Windows) DOMAIN_HOME\bin\stopWebLogic.cmd

プロンプトが表示されたら、管理サーバーのユーザー名とパスワードおよびURLを入力します。

注意:
リポジトリ用に外部のパスワード記憶域が設定されている場合は、アップグレード中に作業リポジトリのパスワードを取得できるように、資格証明ストアをホストしているサーバーが稼働している必要があります。詳細は、Oracle Fusion Middleware Oracle Data Integratorの管理の外部パスワード記憶域の設定を参照してください。

手順5: ノード・マネージャの停止

ノード・マネージャを停止するには、それが実行されているコマンド・シェルを閉じます。

またはnodemanager.propertiesのQuitEnabledの属性をtrueに設定した後(デフォルトはfalseです)、WLSTを使用して、ノード・マネージャに接続して停止できます。詳細は、Oracle Fusion Middleware WebLogic Server WLSTコマンド・リファレンスのstopNodeManagerを参照してください。

6.4 製品スキーマのアップグレード

サーバーおよびプロセスを停止した後、アップグレード・アシスタントを使用して、サポートされている製品スキーマを現在のリリースのOracle Fusion Middlewareにアップグレードします。

アップグレード・アシスタントを使用すると、個別に選択したスキーマまたはドメインに関連付けられているすべてのスキーマをアップグレードできます。選択したオプションによって、表示されるアップグレード・アシスタントの画面は異なります。

- アップグレード・アシスタントの起動
アップグレード・アシスタントを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。一度に1つのドメインのアップグレードを完了して、アップグレード・アシスタントを非SYSDBAユーザーとして実行することをお薦めします。

- アップグレード・アシスタントを使用した製品スキーマのアップグレード
アップグレード・アシスタントの各画面を移動して、製品スキーマをアップグレードします。

- スキーマ・アップグレードの確認
すべてのアップグレード手順の完了後、schema_version_registryのスキーマ・バージョンが正しく更新されたことを確認して、アップグレードが成功したことを確認します。

6.4.1 Upgrade Assistantの起動

アップグレード・アシスタントを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。一度に1つのドメインのアップグレードを完了して、アップグレード・アシスタントを非SYSDBAユーザーとして実行することをお薦めします。

Upgrade Assistantを起動するには、次の手順に従います。

1. oracle_common/upgrade/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. アップグレード・アシスタントを起動します。

- (UNIX) ./ua

- (Windows) ua.bat

ロギング・パラメータなど、コマンドラインで指定できるその他のパラメータの詳細は、次を参照してください。

- アップグレード・アシスタントのコマンドライン・パラメータ

6.4.1.1 アップグレード・アシスタントのコマンドライン・パラメータ

コマンドラインからアップグレード・アシスタントを起動するとき、追加パラメータを指定できます。

表6-2 アップグレード・アシスタントのコマンドライン・パラメータ

パラメータ

必須またはオプション

説明

-readiness

準備状況チェックに必須
注意: 準備状況チェックはスタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では実行できません。

実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。

スキーマおよび構成がチェックされます。

-examineパラメータを指定した場合、このパラメータを使用しないでください。

-threads

オプション

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックに必須

アップグレード・アシスタントがGUIモードで実行されたときに入力されたデータから生成されたレスポンス・ファイルに保存された入力を使用して、アップグレード・アシスタントを実行します。このパラメータを使用すると、アップグレード・アシスタントがサイレント・モードで(アップグレード・アシスタント画面を表示せずに)実行されます。

-examine

オプション

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel 属性

オプション

次のいずれかの属性を指定してロギング・レベルを設定します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

デフォルトのロギング・レベルはNOTIFICATIONです。

より多くの情報がロギングされるように-logLevel TRACE属性を設定することを検討してください。これは、失敗したアップグレードをトラブルシューティングするときに役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir 場所

オプション

アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。アップグレード・アシスタントによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

デフォルトの場所は次のとおりです。

(UNIX) ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

(Windows) ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

オプション

すべてのコマンドライン・オプションを表示します。

6.4.2 アップグレード・アシスタントを使用した製品スキーマのアップグレード

アップグレード・アシスタントの各画面を移動して、製品スキーマをアップグレードします。

注意

- 外部認証を使用している場合は、外部認証が内部認証に変更されていることを確認してください。

- エディションベースの再定義(EBR)ユーザーのみ: エディション・ベースの再定義(EBR)に対応したスキーマをアップグレードする前に、データベース・サーバーに接続して、12cのデータベース・サーバーにエディションを作成する必要があります。12cの新しいエディションは、既存の12cエディションの子である必要があります。再定義のためのサーバーでのエディション作成の詳細は、エディションベースの再定義のためのサーバー上でのエディションの作成を参照してください。

アップグレード・アシスタントで製品スキーマをアップグレードする手順は次のとおりです。

1. 「ようこそ」画面で、アップグレード・アシスタントの概要と、重要なアップグレード前のタスクに関する情報を確認します。「次へ」をクリックします

注意:
アップグレード・アシスタント画面の詳細は、画面で「ヘルプ」をクリックしてください。

2. 「選択したスキーマ」画面で、「個別に選択されたスキーマ」を選択します。

注意:
12c (12.2.1.2)コンポーネントをサポートするために使用されるスキーマのみをアップグレードしてください。Oracle Fusion Middleware 12c (12.2.1.2)に含まれていないコンポーネントをサポートするために現在使用されているスキーマはアップグレードしないでください。

「次へ」をクリックします。

3. 「使用可能なコンポーネント」画面で、マスターおよび作業リポジトリ・スキーマをアップグレードするために「Oracle Data Integrator」を選択します。

4. 「前提条件」画面ですべてのチェック・ボックスを選択して、前提条件を満たしていることを確認します。「次へ」をクリックします

注意:
アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。

5. ODIスキーマ画面で、アップグレードする各スキーマのデータベース接続の詳細を指定します。

- 「データベース・タイプ」ドロップダウン・メニューからデータベース・タイプを選択します。

- データベース接続の詳細を入力して、「接続」をクリックします。

- 「スキーマ・ユーザー名」ドロップダウン・メニューからアップグレードするスキーマを選択し、スキーマのパスワードを入力します。アップグレードするスキーマに対して正しいスキーマ接頭辞を使用してください。

6. 「ODIオプション」画面で、すべてのオプションを選択します。

表6-3 ODIのオプション

オプション

説明

ナレッジ・モジュールを必須更新で置換

これを選択すると、標準ナレッジ・モジュールが最新バージョンに置き換えられます。Oracleによりインストールされたナレッジ・モジュールに対するカスタマイズ内容は上書きされます。ただし、インストールされたナレッジ・モジュールをコピーしてからそのナレッジ・モジュールをカスタマイズした場合、カスタマイズ内容は失われません。

トポロジおよびセキュリティ・メタデータのアップグレード

これを選択すると、テクノロジ、データ型、セキュリティ・プロファイルなどのトポロジおよびセキュリティ・アーティファクトが最新バージョンに置き換えられます。インストールされたオブジェクトのカスタマイズ内容は上書きされます。オブジェクトをコピーしてからカスタマイズした場合、カスタマイズ内容は失われません。

高度なアップグレード・オプションの詳細は、「高度なアップグレード・オプション」を参照してください。

7. 「ODIスーパーバイザ」画面に、アップグレードするODIリポジトリのスーパーバイザ・アカウント資格証明を入力します。

インストールされているスーパーバイザ・アカウントはSUPERVISORです。ODIのマスター・リポジトリおよび作業リポジトリの作成時にリポジトリ作成ユーティリティ(RCU)で求められたときに指定した、正しいスーパーバイザ・アカウント名およびパスワードについては、ODI管理者に確認してください。

注意:
「ドメインで使用されるすべてのスキーマ」が選択されている場合、ODIのスーパーバイザ資格証明はドメインに含まれていないため、最初のインスタンスにあらかじめ移入されません。複数のODIスキーマがある場合、アップグレード・アシスタントは最初の資格証明のセットを使用してユーザー・エントリに移入します。

8. 「調査」画面で、各スキーマを調査した際のアップグレード・アシスタントのステータスを確認し、スキーマのアップグレード準備が整っていることを確認します。ステータスが「調査が終了しました。」になっている場合は、「次へ」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、共通するアップグレード・エラーの解決に関する情報をOracle Fusion Middleware Upgrade Assistantによるアップグレードのアップグレードのトラブルシューティングで参照します。

注意:

- 調査フェーズの間に、アップグレードを続行せずに検出された問題を解決した場合は、バックアップからリストアすることなしに、アップグレード・アシスタントを再起動できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックして続行した場合は、アップグレード・アシスタントを再起動する前に、アップグレード前の環境をバックアップからリストアする必要があります。

- 調査プロセスを取り消してもスキーマまたは構成データに影響はありませんが、将来のアップグレード・セッションでは、Upgrade Assistantが収集した情報を再収集する必要があります。

9. 「アップグレード・サマリー」画面で、スキーマ・アップグレードに選択したオプションのサマリーを確認します。
正しいソース・バージョンとターゲット・バージョンが、アップグレード対象の各スキーマにリストされていることを確認します。

後でアップグレード・アシスタントをレスポンス(またはサイレント)モードで再び実行するためにこれらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックして、レスポンス・ファイルの場所および名前を指定します。サイレント・アップグレードは、アップグレード・アシスタント・とまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。

10. 「アップグレードの進行状況」画面でアップグレードのステータスを監視します。

注意:
アップグレード・アシスタントにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。これを行うと、環境が不安定になる可能性があります。

正しくアップグレードされていないスキーマがある場合は、アップグレード・アシスタントのログ・ファイルで情報を確認します。

注意:
この画面の進捗バーには、現在のアップグレード手順の進行状況が表示されます。アップグレードの残り時間を示すものではありません。

「次へ」をクリックします。

11. アップグレードが成功した場合、「アップグレード成功」画面で「閉じる」をクリックし、アップグレードを完了してウィザードを閉じます。

アップグレードが失敗した場合、「アップグレード失敗」画面で「ログの表示」をクリックし、エラーを表示してトラブルシューティングします。ログはORACLE_HOME/oracle_common/upgrade/logsにあります。

注意:
アップグレードに失敗した場合、アップグレード前の環境をバックアップからリストアし、問題を修正して、アップグレード・アシスタントを再起動する必要があります。

6.4.3 スキーマのアップグレードの確認

すべてのアップグレード手順の完了後、schema_version_registryのスキーマ・バージョンが正しく更新されたことを確認して、アップグレードが成功したことを確認します。

Oracle Databaseを使用する場合、Oracle DBAを持つユーザーとしてデータベースに接続し、SQL*Plusから次を実行して現行のバージョン番号を取得します。

SET LINE 120
COLUMN MRC_NAME FORMAT A14
COLUMN COMP_ID FORMAT A20
COLUMN VERSION FORMAT A12
COLUMN STATUS FORMAT A9
COLUMN UPGRADED FORMAT A8
SELECT MRC_NAME, COMP_ID, OWNER, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY ORDER BY MRC_NAME, COMP_ID ;

問合せ結果:

- VERSION列の数値が、そのスキーマの最新のバージョン番号に一致していることを確認します。たとえば、スキーマ・バージョン番号が12.2.1.2.0であることを確認します。ただし、すべてのスキーマ・バージョンが更新されるわけではないことに注意してください。一部のスキーマではこのリリースへのアップグレードが必要なく、アップグレード前のバージョン番号が保持されます。

- STATUSフィールドは、スキーマのパッチ適用操作中は「UPGRADING」または「UPGRADED」に、操作が完了すると「VALID」になります。

- ステータスが「INVALID」と表示された場合は、ステータスの更新が失敗しています。ログ・ファイルを調べて、失敗した理由を判定する必要があります。

- IAU_APPENDおよびIAU_VIEWERによって所有されるシノニム・オブジェクトは、INVALIDとして表示されますが、失敗を示すものではありません。
それらは、シノニムの作成後にターゲット・オブジェクトが変更されるため無効になります。シノニム・オブジェクトはアクセスされると有効になります。これらのINVALIDオブジェクトは無視しても問題ありません。

6.5 スタンドアロン・システム・コンポーネント構成のアップグレード

アップグレード・アシスタントを使用して、スタンドアロン・システム・コンポーネント構成をアップグレードします。

- アップグレード・アシスタントの起動
アップグレード・アシスタントを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。一度に1つのドメインのアップグレードを完了して、アップグレード・アシスタントを非SYSDBAユーザーとして実行することをお薦めします。

- アップグレード・アシスタントを使用したスタンドアロン・システム・コンポーネント構成のアップグレード
アップグレード・アシスタントの各画面を移動して、スタンドアロン・システム・コンポーネント構成をアップグレードします。

6.5.1 Upgrade Assistantの起動

アップグレード・アシスタントを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。一度に1つのドメインのアップグレードを完了して、アップグレード・アシスタントを非SYSDBAユーザーとして実行することをお薦めします。

Upgrade Assistantを起動するには、次の手順に従います。

1. oracle_common/upgrade/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. アップグレード・アシスタントを起動します。

- (UNIX) ./ua

- (Windows) ua.bat

ロギング・パラメータなど、コマンドラインで指定できるその他のパラメータの詳細は、次を参照してください。

- アップグレード・アシスタントのコマンドライン・パラメータ

6.5.1.1 アップグレード・アシスタントのコマンドライン・パラメータ

コマンドラインからアップグレード・アシスタントを起動するとき、追加パラメータを指定できます。

表6-4 アップグレード・アシスタントのコマンドライン・パラメータ

パラメータ

必須またはオプション

説明

-readiness

準備状況チェックに必須
注意: 準備状況チェックはスタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では実行できません。

実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。

スキーマおよび構成がチェックされます。

-examineパラメータを指定した場合、このパラメータを使用しないでください。

-threads

オプション

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックに必須

アップグレード・アシスタントがGUIモードで実行されたときに入力されたデータから生成されたレスポンス・ファイルに保存された入力を使用して、アップグレード・アシスタントを実行します。このパラメータを使用すると、アップグレード・アシスタントがサイレント・モードで(アップグレード・アシスタント画面を表示せずに)実行されます。

-examine

オプション

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel 属性

オプション

次のいずれかの属性を指定してロギング・レベルを設定します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

デフォルトのロギング・レベルはNOTIFICATIONです。

より多くの情報がロギングされるように-logLevel TRACE属性を設定することを検討してください。これは、失敗したアップグレードをトラブルシューティングするときに役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir 場所

オプション

アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。アップグレード・アシスタントによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

デフォルトの場所は次のとおりです。

(UNIX) ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

(Windows) ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

オプション

すべてのコマンドライン・オプションを表示します。

6.5.2 アップグレード・アシスタントを使用したスタンドアロン・システム・コンポーネント構成のアップグレード

アップグレード・アシスタントの各画面を移動して、スタンドアロン・システム・コンポーネント構成をアップグレードします。

アップグレード・アシスタントを使用してスタンドアロン・システム・コンポーネント構成をアップグレードする手順は次のとおりです。

1. 「ようこそ」画面で、アップグレード・アシスタントの概要と、重要なアップグレード前のタスクに関する情報を確認します。「次へ」をクリックします

注意:
アップグレード・アシスタント画面の詳細は、画面で「ヘルプ」をクリックしてください。

2. 次の画面で次のようにします。

- 「スタンドアロン・システム・コンポーネント構成」を選択し、「既存のドメインの更新」を選択します。

- 「ドメインの場所」フィールドで、更新する既存のスタンドアロン・ドメインの場所を選択します 。

- 「次へ」をクリックします。

3. 「コンポーネント・リスト」画面で、構成をアップグレードするすべてのコンポーネントがリストに含まれていることを確認して「次へ」をクリックします。
アップグレード対象のコンポーネントが表示されていない場合は、「戻る」をクリックして前の画面に戻り、別のドメインを指定します。

4. 「前提条件」画面ですべてのチェック・ボックスを選択して、前提条件を満たしていることを確認します。「次へ」をクリックします

注意:
アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。

5. 「インスタンス・ディレクトリ」画面で、アップグレード対象となる1つ以上のOracleインスタンス・ディレクトリの場所を指定します。

6. 「ノード・マネージャ」画面で、スタンドアロン・システム・コンポーネントのアップグレード時にドメインの作成に使用されるノード・マネージャの資格証明を指定します。

7. 「調査」画面で、各スタンドアロン・コンポーネントを調査した際のアップグレード・アシスタントのステータスを確認し、スタンドアロン・コンポーネント構成のアップグレード準備が整っていることを確認します。ステータスが「調査が終了しました。」になっている場合は、「次へ」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、共通するアップグレード・エラーの解決に関する情報をOracle Fusion Middleware Upgrade Assistantによるアップグレードのアップグレードのトラブルシューティングで参照します。

注意:

- 調査フェーズの間に、アップグレードを続行せずに検出された問題を解決した場合は、バックアップからリストアすることなしに、アップグレード・アシスタントを再起動できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックして続行した場合は、アップグレード・アシスタントを再起動する前に、アップグレード前の環境をバックアップからリストアする必要があります。

- 調査プロセスを取り消しても構成データに影響はありませんが、将来のアップグレード・セッションでは、アップグレード・アシスタントが収集した情報を再収集する必要があります。

8. 「アップグレード・サマリー」画面で、コンポーネント構成アップグレードに選択したオプションのサマリーを確認します。
レスポンス・ファイルには、入力したすべての情報が収集して格納され、後でサイレント・アップグレードを実行するために使用できます。サイレント・アップグレードは、アップグレード・アシスタント・とまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。

9. 「アップグレードの進行状況」画面でアップグレードのステータスを監視します。

注意:
アップグレード・アシスタントにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。これを行うと、環境が不安定になる可能性があります。

正しくアップグレードされていないコンポーネントがある場合は、Upgrade Assistantのログ・ファイルで情報を確認します。

注意:
この画面の進捗バーには、現在のアップグレード手順の進行状況が表示されます。アップグレードの残り時間を示すものではありません。

「次へ」をクリックします。

10. アップグレードが成功した場合、「アップグレード成功」画面で「閉じる」をクリックし、アップグレードを完了してウィザードを閉じます。新規インストールでコンポーネントを機能させるために手動で実行する必要のあるタスクが、アップグレード後のアクションのウィンドウに表示されます。このウィンドウは、コンポーネントにアップグレード後の手順がある場合にのみ表示されます。

アップグレードが失敗した場合、「アップグレード失敗」画面で「ログの表示」をクリックし、エラーを表示してトラブルシューティングします。ログはORACLE_HOME/oracle_common/upgrade/logsにあります。アップグレードに失敗した場合、アップグレード前の環境をバックアップからリストアし、問題を修正して、アップグレード・アシスタントを再起動する必要があります。

6.6 サーバーおよびプロセスの起動

アップグレードが成功した後、管理サーバーおよび管理対象サーバーを含め、すべてのプロセスおよびサーバーを再起動します。

これらのコンポーネントは相互に依存する場合があるため、正しい順序で起動する必要があります。

注意:
この項の手順では、WLSTコマンドラインまたはスクリプトを使用してサーバーおよびプロセスを起動する方法について説明します。Oracle Fusion Middleware ControlおよびOracle WebLogic Server管理コンソールを使用することもできます。Oracle Fusion Middlewareの管理の管理サーバー、管理対象サーバーおよびノード・マネージャの起動および停止を参照してください。

Fusion Middleware環境を起動するには、次の手順に従います。

ステップ1: 管理サーバーの起動

管理サーバーを起動する場合、管理サーバーで稼働しているWebLogic Server管理コンソールやFusion Middleware Controlなどのプロセスも起動します。

管理サーバーを起動するには、startWebLogicスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/startWebLogic.sh

- (Windows) DOMAIN_HOME\bin\startWebLogic.cmd

プロンプトが表示されたら、管理サーバーのユーザー名とパスワードおよびURLを入力します。

手順2: ノード・マネージャの起動

ノード・マネージャを起動するには、startNodeManagerスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/startNodeManager.sh

- (Windows) DOMAIN_HOME\bin\startNodeManager.cmd

手順3: Oracle Identity Managementコンポーネントの起動環境を構成しているOracle Internet DirectoryなどのOracle Identity Managementコンポーネントがあれば、それをすべて起動します。

- (UNIX) DOMAIN_HOME/bin/startComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\startComponent.cmd component_name

手順4: 管理対象サーバーの起動

WebLogic Server管理対象サーバーを起動するには、startManagedWebLogicスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

- (Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url

プロンプトが表示されたらユーザー名とパスワードを入力します。

注意:
通常は、管理対象サーバーの起動により、それにデプロイされているアプリケーションが開始されます。したがって、管理対象サーバーの起動後にアプリケーションを手動で開始する必要はありません。

手順5: システム・コンポーネントの起動

Oracle HTTP Serverなどのシステム・コンポーネントを起動するには、startComponentスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/startComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\startComponent.cmd component_name

システム・コンポーネントは任意の順序で起動できます。

7 Oracle Data Integratorスタンドアロン・コロケート・エージェント環境の前の12cリリースからのアップグレード

WebLogicドメイン内に構成されているOracle Data Integratorスタンドアロン・エージェント環境を前のOracle Fusion Middleware 12cリリースから12c (12.2.1.2)にアップグレードできます。

- Oracle Data Integratorスタンドアロン・コロケート・エージェントのアップグレード・プロセスについて
WebLogicドメイン内に構成されているOracle Data Integratorスタンドアロン・エージェントのアップグレード・プロセスの概要を示すプロセス・フローチャートを確認します。

- Oracle Data Integratorスタンドアロン・コロケート・エージェント環境のインストール
アップグレードを開始する前に、Oracle Fusion Middleware InfrastructureおよびOracle Data Integrator 12c (12.2.1.2)ディストリビューションをターゲット・システムにダウンロードし、Oracle Universal Installerを使用してインストールします。

- アップグレード前の準備状況チェックの実行
アップグレードの潜在的な問題を特定するために、アップグレード・プロセスを開始する前に準備状況チェックを実行することをお薦めします。準備状況チェックで、アップグレードの潜在的な問題をすべて検出できない場合があることに注意してください。準備状況チェックで成功が報告されても、アップグレードが失敗する場合があります。

- サーバーおよびプロセスの停止
アップグレード・アシスタントを実行してスキーマおよび構成をアップグレードする前に、管理サーバーや管理対象サーバーを含め、すべてのプロセスとサーバーを停止する必要があります。

- 製品スキーマのアップグレード
サーバーおよびプロセスを停止した後、アップグレード・アシスタントを使用して、サポートされている製品スキーマを現在のリリースのOracle Fusion Middlewareにアップグレードします。

- ドメインの再構成
再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.2)に再構成します。

- ドメイン・コンポーネント構成のアップグレード
ドメインの再構成後、アップグレード・アシスタントを使用して、ドメイン内のドメイン・コンポーネント構成を更新済ドメイン構成に一致するようにアップグレードします。

- サーバーおよびプロセスの起動
アップグレードが成功した後、管理サーバーおよび管理対象サーバーを含め、すべてのプロセスおよびサーバーを再起動します。

親トピック: Oracle Data Integratorの前の12cリリースからのアップグレード

7.1 Oracle Data Integratorスタンドアロン・コロケート・エージェントのアップグレード・プロセスについて

WebLogicドメイン内に構成されているOracle Data Integratorスタンドアロン・エージェントのアップグレード・プロセスの概要を示すプロセス・フローチャートを確認します。

表7-1 Oracle Data Integratorスタンドアロン・コロケート・エージェントを前の12cリリースからアップグレードするためのタスク

タスク

説明

必須

このガイドの概要のトピックをまだ確認していない場合は確認し、必要なアップグレード前のタスクを完了します。

次を参照してください。

- Oracle Data Integratorの12c (12.2.1.2)へのアップグレードの概要

- アップグレード前の要件

必須

Oracle Fusion Middleware InfrastructureおよびOracle Data Integrator 12c (12.2.1.2)を新しいOracleホームにインストールします。

Oracle Data Integratorスタンドアロン・コロケート・エージェント環境のインストールを参照してください。

オプション

アップグレード前の準備状況チェックを実行します。

「アップグレード前の準備状況チェックの実行」を参照してください。

必須

12c環境を停止します(すべての管理サーバーと管理対象サーバーを停止します)。

警告: アップグレード中にサーバーを停止しないと、データが破壊される可能性があります。

「サーバーとプロセスの停止」を参照

必須

アップグレード・アシスタントを起動して、データベース・スキーマをアップグレードし、すべてのアクティブ(進行中の)インスタンス・データを移行します。

製品スキーマのアップグレードを参照してください。

注意: アクティブ・インスタンス・データのアップグレードは、アップグレード・アシスタントの実行中に自動で開始されます。データが正常に新しい12c (12.2.1.2)環境にアップグレードされたら、アップグレード・アシスタントを終了してもかまいません。クローズされたインスタンスのアップグレードは、バックグランド・プロセスで継続されます。

必須

再構成ウィザードを起動して、ドメインとノード・マネージャを再構成します。

構成ウィザードを実行して、既存のドメインを更新して新しくインストールしたソフトウェアを使用します。

ドメインの再構成を参照してください。

必須

アップグレード・アシスタントを(再度)起動して、ドメイン構成をアップグレードします。

アップグレード・アシスタントを実行して、再構成したドメインのコンポーネント構成をアップグレードします。

ドメイン・コンポーネント構成のアップグレードを参照してください。

必須

サーバーおよび12c (12.2.1.2)インスタンスを再起動します。

アップグレード・プロセスが完了したら、12c (12.2.1.2)インスタンスを再起動します。

サーバーおよびプロセスの起動を参照してください。

必須

アップグレードを確認します。

バックアップを削除する前に、アップグレードしたコンポーネントがすべて期待どおりに動作していることを確認します。

7.2 Oracle Data Integratorスタンドアロン・コロケート・エージェント環境のインストール

アップグレードを開始する前に、Oracle Fusion Middleware InfrastructureおよびOracle Data Integrator 12c (12.2.1.2)ディストリビューションをターゲット・システムにダウンロードし、Oracle Universal Installerを使用してインストールします。

注意:
アップグレードにInfrastructureが必要な場合、他のFusion Middleware製品をインストールする前に、まずOracle Fusion Middleware Infrastructureディストリビューションをインストールする必要があります。

12c (12.2.1.2)ディストリビューションをインストールする手順は次のとおりです。

1. 12c (12.2.1.2)製品ディストリビューションをインストールするターゲット・システムにサインインします。

2. 次の12c (12.2.1.2)製品ディストリビューションをOracle Technology NetworkまたはOracle Software Delivery Cloudからターゲット・システムにダウンロードします。

- Oracle Fusion Middleware Infrastructure (fmw_12.2.1.2.0_infrastructure_generic.jar)

- Oracle Data Integrator (fmw_12.2.1.2.0_odi_Disk1_1of2.zipおよびfmw_12.2.1.2.0_odi_Disk1_2of2.zip )

3. 12c (12.2.1.2)製品のディストリビューションをダウンロードしたディレクトリに移動します。

4. インストールfmw_12.2.1.2.0_odi_Disk1_1of2.zipおよびfmw_12.2.1.2.0_odi_Disk1_2of2.zipファイルを解凍します。

5. Oracle Fusion Middleware Infrastructureのインストール・プログラムを起動します。

- (UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

- (Windows) JDK_HOME\bin\java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

6. UNIXオペレーティング・システムでは、このホストにOracle製品を初めてインストールする場合に、「インストール・インベントリの設定」画面が表示されます。
中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システム・グループ名に対して中央インベントリの場所への書込み権限が付与されていることを確認し、「次へ」をクリックします。

注意:
「インストール・インベントリの設定」画面は、Windowsオペレーティング・システムでは表示されません。

7. 「ようこそ」画面で、情報をレビューしてすべての前提条件を満たしていることを確認します。「次へ」をクリックします

8. 「自動更新」画面で「自動更新をスキップ」を選択します。オプションは次のとおりです。

- この時点でソフトウェアの更新をシステムで確認しないようにする場合は、「自動更新をスキップ」を選択します。

- パッチ・ファイルをダウンロードした場合は、「ディレクトリからパッチを選択」を選択して、ローカル・ディレクトリに移動します。

- My Oracle Supportアカウントを持っている場合にソフトウェアの更新を自動でダウンロードするには、「My Oracle Supportで更新を検索」を選択します。Oracle Supportの資格証明を入力して、「検索」をクリックします。インストーラがMy Oracle Supportにアクセスするようにプロキシ・サーバーを構成するには、「プロキシ設定」をクリックします。「接続のテスト」をクリックして接続をテストします。

「次へ」をクリックします。

9. 「インストールの場所」画面でOracleホーム・ディレクトリの場所を指定し、「次へ」をクリックします。
Oracle Fusion Middlewareディレクトリ構造の詳細は、Oracle Fusion Middleware Oracle Fusion Middlewareのインストールのプランニングのインストールおよび構成のためのディレクトリの理解を参照してください。

10. 「インストール・タイプ」画面で、次を選択します。

- Infrastructureには、「Fusion Middlewareインフラストラクチャ」を選択します

- Oracle Data Integratorには、「エンタープライズ・インストール」を選択します

「次へ」をクリックします。

11. 「前提条件チェック」画面では、ホスト・コンピュータを分析して、特定のオペレーティング・システムの前提条件を満たしているか確認します。
確認されたタスクのリストを表示するには、「正常なタスクの表示」を選択します。ログの詳細を表示するには、「ログの表示」を選択します。前提条件のチェックが失敗すると、エラー・メッセージが画面の下方に表示されます。エラーを修正し、「再実行」をクリックして再試行します。エラー・メッセージや警告メッセージを無視してインストールを続けるには、「スキップ」をクリックします(非推奨)。

12. 「インストールの概要」画面で、選択したインストール・オプションを確認します。
これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を入力します。レスポンス・ファイルには、入力したすべての情報が収集して格納され、後で(コマンドラインから)サイレント・インストールを実行するために使用できます。
「インストール」をクリックしてインストールを開始します。

13. 「インストールの進行状況」画面で進捗バーが100%になったら、「終了」をクリックしてインストーラを閉じるか、「次へ」をクリックしてサマリーを確認します。

14. 「インストール完了」画面に、インストールの場所とインストールされた機能セットが表示されます。情報を確認し、「終了」をクリックしてインストーラを閉じます。

15. Oracle Fusion Middleware Infrastructureをインストールした後、次のコマンドを入力して製品ディストリビューションのインストーラを起動し、前述の手順を繰り返してインストーラの各画面を移動します。
(UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.2.0_odi_generic.jar

(Windows) JDK_HOME\bin\java -jar fmw_12.2.1.2.0_odi_generic.jar

7.3 アップグレード前の準備状況チェックの実行

アップグレードの潜在的な問題を特定するために、アップグレード・プロセスを開始する前に準備状況チェックを実行することをお薦めします。準備状況チェックで、アップグレードの潜在的な問題をすべて検出できない場合があることに注意してください。準備状況チェックで成功が報告されても、アップグレードが失敗する場合があります。

- アップグレード前の準備状況チェックの実行について
アップグレード・アシスタントを-readinessモードで実行することにより、実際にアップグレードを実行する前に問題を検出できます。準備状況チェックは、アップグレード・アシスタントを使用してGUIモードで実行するか、レスポンス・ファイルを使用してサイレント・モードで実行できます。

- 準備状況モードでのアップグレード・アシスタントの起動
-readinessパラメータを使用して、アップグレード・アシスタントを準備状況モードで起動します。

- アップグレード・アシスタントでの準備状況チェックの実行
アップグレード・アシスタントの各画面を移動して、アップグレード前の準備状況チェックを完了します。

- 準備状況レポートの理解
ドメインの準備状況チェックを実行した後、レポートを確認して、アップグレードが成功するためにアクションを実行する必要があるかどうかを決定します。

7.3.1 アップグレード前の準備状況チェックの実行について

アップグレード・アシスタントを-readinessモードで実行することにより、実際にアップグレードを実行する前に問題を検出できます。準備状況チェックは、アップグレード・アシスタントを使用してGUIモードで実行するか、レスポンス・ファイルを使用してサイレント・モードで実行できます。

アップグレード・アシスタントの準備状況チェックでは、サポートされる開始点にあるFusion MiddlewareスキーマおよびWebLogicドメイン構成の読取り専用のアップグレード前確認を実行します。確認は読取り専用操作です。

準備状況チェックでは、フォーマットされ、タイムスタンプの付けられた準備状況レポートが生成され、実際のアップグレードを試みる前に潜在的な問題に対処できます。問題が検出されない場合は、アップグレード・プロセスを開始できます。アップグレードを実行する前に、このレポートを詳細に確認することをお薦めします。

準備状況チェックは、既存のOracle Fusion Middlewareドメインがオンライン(他のユーザーがアクティブに使用している間)またはオフラインである間に実行できます。

実際のアップグレードを実行する前に、準備状況チェックを何度でも実行できます。ただし、アップグレードを実行した後は、レポートの結果がアップグレード前の準備状況チェックの結果と異なる可能性があるため、準備状況チェックを実行しないでください。

注意:

パフォーマンスが影響されることを回避するために、オフピーク時に準備状況チェックを実行することをお薦めします。

7.3.2 準備状況モードでのUpgrade Assistantの起動

-readinessパラメータを使用して、アップグレード・アシスタントを準備状況モードで起動します。

アップグレード・アシスタントでアップグレード前の環境に対して準備状況チェックを実行する手順は次のとおりです。

1. oracle_common/upgrade/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. アップグレード・アシスタントを起動します。

- (UNIX) ./ua -readiness

- (Windows) ua.bat -readiness

注意:
GUIモードを許可するようにDISPLAY環境変数を適切に設定していない場合、次のエラーが発生することがあります。

Xlib: connection to ":1.0" refused by server
Xlib: No protocol specified

この問題を解決するには、使用するローカル・ワークステーションのシステム名またはIPアドレスにDISPLAY環境変数を設定して、アップグレード・アシスタントを再実行します。

DISPLAYを設定してもこのエラーが引き続き発生する場合は、vncconfigなどの他のGUIツールの起動を試みてください。同じエラーが表示される場合は、DISPLAY環境変数がまだ正しく設定されていない可能性があります。

コマンドラインで指定できるその他のパラメータの詳細は、次を参照してください。

- アップグレード・アシスタントのコマンドライン・パラメータ

7.3.2.1 アップグレード・アシスタントのコマンドライン・パラメータ

コマンドラインからアップグレード・アシスタントを起動するとき、追加パラメータを指定できます。

表7-2 アップグレード・アシスタントのコマンドライン・パラメータ

パラメータ

必須またはオプション

説明

-readiness

準備状況チェックに必須
注意: 準備状況チェックはスタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では実行できません。

実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。

スキーマおよび構成がチェックされます。

-examineパラメータを指定した場合、このパラメータを使用しないでください。

-threads

オプション

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックに必須

アップグレード・アシスタントがGUIモードで実行されたときに入力されたデータから生成されたレスポンス・ファイルに保存された入力を使用して、アップグレード・アシスタントを実行します。このパラメータを使用すると、アップグレード・アシスタントがサイレント・モードで(アップグレード・アシスタント画面を表示せずに)実行されます。

-examine

オプション

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel 属性

オプション

次のいずれかの属性を指定してロギング・レベルを設定します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

デフォルトのロギング・レベルはNOTIFICATIONです。

より多くの情報がロギングされるように-logLevel TRACE属性を設定することを検討してください。これは、失敗したアップグレードをトラブルシューティングするときに役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir 場所

オプション

アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。アップグレード・アシスタントによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

デフォルトの場所は次のとおりです。

(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

オプション

すべてのコマンドライン・オプションを表示します。

7.3.3 アップグレード・アシスタントでの準備状況チェックの実行

アップグレード・アシスタントの各画面を移動して、アップグレード前の準備状況チェックを完了します。

準備状況チェックは、サポートされるアップグレードの開始点にあるスキーマまたはコンポーネント構成に対してのみ実行されます。

準備状況チェックを完了する手順は次のとおりです。

1. 「ようこそ」画面で、準備状況チェックに関する情報を確認します。「次へ」をクリックします

2. 「準備状況チェック・タイプ」画面で、実行する準備状況チェックを選択します。

- 「個別に選択されたスキーマ」を使用すると、アップグレード前の確認のために個別のスキーマを選択できます。準備状況チェックにより、スキーマがアップグレードに対してサポートされているか、またはアップグレードが必要な箇所が報告されます。
このオプションを選択すると、画面名が「選択したスキーマ」になります。

- 「ドメイン・ベース」を使用すると、「ドメイン・ディレクトリ」フィールドで指定したドメイン内のアップグレードに適格なすべてのスキーマまたはコンポーネント構成を、アップグレード・アシスタントで検出および選択できます。
このオプションを選択すると、画面名がスキーマおよび構成になります。

アップグレード・アシスタントですべてのスキーマおよびコンポーネント構成を同時に確認する場合は、デフォルトの選択のままにし、それ以外の場合は特定のオプションを選択します。

- 「すべてのスキーマのチェックを含める」は、アップグレード可能なスキーマを含むすべてのコンポーネントを検出および確認します。

- 「すべての構成のチェックを含める」は、管理対象WebLogic Serverドメインのコンポーネント構成を確認します。

「次へ」をクリックします。

3. 「個別に選択されたスキーマ」を選択した場合、「使用可能なコンポーネント」画面で、準備状況チェックを実行する、アップグレード可能なスキーマを含むコンポーネントを選択します。

依存コンポーネントを持つコンポーネントを選択した場合、それらのコンポーネントは自動的に選択されます。たとえば、Oracle Platform Security Servicesを選択した場合、Oracle Audit Servicesは自動的に選択されます。

選択したコンポーネントに応じて、追加の画面が表示される場合があります。たとえば、次のような作業が必要になることがあります。

- ドメイン・ディレクトリを指定します。

- スキーマ資格証明を指定して、選択したスキーマに接続します: 「データベース・タイプ」、「DBAユーザー名」および「DBAパスワード」。次に「接続」をクリックします。

注意
Oracle Databaseがデフォルトのデータベース・タイプです。続行する前に、正しいデータベース・タイプを選択したことを確認してください。間違ったデータベース・タイプを選択したことがわかった場合、正しいタイプに変更するためにこの画面に戻らないでください。かわりに、アップグレード・アシスタントを閉じて、正しいデータベース・タイプを選択して準備状況チェックを再起動し、正しいデータベース・タイプがすべてのスキーマに適用されることを確認してください。

- 「スキーマ・ユーザー名」を選択して、「スキーマ・パスワード」を指定します。

「次へ」をクリックして準備状況チェックを開始します。

4. 「準備状況サマリー」画面で、選択に基づいて実行された準備状況チェックのサマリーを確認します。
後でアップグレード・アシスタントをレスポンス(またはサイレント)モードで再び実行するために選択内容をレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックして、レスポンス・ファイルの場所および名前を指定します。サイレント・アップグレードは、アップグレード・アシスタント・とまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。

詳細レポートを表示するには、「ログの表示」をクリックします。

「次へ」をクリックします。

5. 「準備状況チェック」画面で、準備状況チェックのステータスを確認します。 プロセスは数分かかる場合があります。
複数のコンポーネントを確認している場合、各コンポーネントの進行状況が固有の進捗バーに並行して表示されます。

準備状況チェックが完了したら「続行」をクリックします。

6. 「準備状況の終了」画面で、準備状況チェックの結果(「準備状況成功」または「準備状況失敗」)を確認します。

- 準備状況チェックが成功した場合、「準備状況レポートの表示」をクリックして完全なレポートを確認します。準備状況チェックが成功した場合でも、実際のアップグレードを実行する前に準備状況レポートを確認することをお薦めします。「検索」オプションを使用して、レポート内の特定の語または句を検索します。また、このレポートには、完成した準備状況チェック・レポート・ファイルが格納されている場所も示されます。

- 準備状況チェックで問題またはエラーが発生した場合、「ログの表示」をクリックしてログ・ファイルを確認し、問題を特定および修正してから、準備状況チェックを再開してください。ログ・ファイルは、設定したコマンドライン・オプションによって管理されます。

7.3.4 準備状況レポートの理解

ドメインの準備状況チェックを実行した後、レポートを確認して、アップグレードが成功するためにアクションを実行する必要があるかどうかを決定します。

準備状況レポート・ファイルの形式は次のとおりです。

readiness_timestamp.txt

timestampは、準備状況チェックが実行された日時を示します。

準備状況レポートには、次の情報が含まれています。

表7-3 準備状況レポートの要素

レポートの情報

説明

必要なアクション

全体的な準備状況ステータス: SUCCESSまたはFAILURE

レポートの上部には、アップグレードの準備状況チェックが成功したか、または1つ以上のエラーが発生して完了したかが示されます。

1つ以上のエラーが発生してレポートが完了した場合、アップグレードを試みる前に、FAILを検索し、障害の原因となった問題を修正します。準備状況チェックは、アップグレードする前に必要に応じて何度でも再実行できます。

タイムスタンプ

レポートが生成された日付と時刻。

必要なアクションはありません。

ログ・ファイルの場所

ORACLE_HOME/oracle_common/upgrade/logs

生成されたログ・ファイルのディレクトリの場所。

必要なアクションはありません。

準備状況レポートの場所

ORACLE_HOME/oracle_common/upgrade/logs

生成された準備状況レポートのディレクトリの場所。

必要なアクションはありません。

チェックされたコンポーネントの名前

チェックに含まれるコンポーネントの名前およびバージョンとステータス。

このリリースにアップグレードできないコンポーネント(SOAコア拡張など)がドメインに含まれる場合は、アップグレードを試みないでください。

チェックされたスキーマの名前

チェックに含まれるスキーマの名前および現在のバージョンとステータス。

スキーマのバージョン番号をレビューします。このリリースにアップグレードできないスキーマがドメインに含まれる場合は、アップグレードを試みないでください。

個別のオブジェクト・テスト・ステータス: FAIL

準備状況チェック・テストによって、特定のオブジェクトの問題が検出されました。

失敗した問題がすべて解決されるまではアップグレードしないでください。

個別のオブジェクト・テスト・ステータス: PASS

準備状況チェック・テストによって、特定のオブジェクトの問題が検出されませんでした。

準備状況チェック・レポートにPASSステータスのみが表示されている場合、環境をアップグレードできます。ただし、準備状況チェックでは、ハードウェアやアップグレード時の接続性などの外部環境に関する問題を検出することはできません。アップグレードの進捗を常に監視する必要があります。

<オブジェクト>の完了した準備状況チェック・ステータス: FAILURE

準備状況チェックによって、スキーマ、索引、データ型など、特定のオブジェクトについての解決する必要がある1つ以上のエラーが検出されました。

FAILED問題がすべて解決されるまではアップグレードしないでください。

<オブジェクト>の完了した準備状況チェック・ステータス: SUCCESS

準備状況チェック・テストによって問題が検出されませんでした。

必要なアクションはありません。

準備状況レポート・ファイルのサンプルを次に示します。使用対象のレポートにはこれらすべてのチェックが含まれる場合や含まれない場合があります。

Upgrade readiness check completed with one or more errors.

This readiness check report was created on Tue May 30 11:15:52 EDT 2016
Log file is located at: ORACLE_HOME/oracle_common/upgrade/logs/ua2016-05-30-11-14-06AM.log
Readiness Check Report File: ORACLE_HOME/oracle_common/upgrade/logs/readiness2016-05-30-11-15-52AM.txt

Starting readiness check of components.

Oracle Metadata Services
Starting readiness check of Oracle Metadata Services.
Schema User Name: DEV11_MDS
Database Type: Oracle Database
Database Connect String: machinename@yourcompany.com
VERSION Schema DEV11_MDS is currently at version 12.1.1.1.0.  Readiness checks will now be performed.
Starting schema test:  TEST_REQUIRED_TABLES  Test that the schema contains all the required tables
Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS
Starting schema test:  TEST_REQUIRED_PROCEDURES  Test that the schema contains all the required stored procedures
EXCEPTION     Schema is missing a required procedure: GETREPOSITORYFEATURES
Completed schema test: TEST_REQUIRED_PROCEDURES --> Test that the schema contains all the required stored procedures +++ FAIL
Starting schema test:  TEST_REQUIRED_VIEWS  Test that the schema contains all the required database views
Completed schema test: TEST_REQUIRED_VIEWS --> Test that the schema contains all the required database views +++ PASS
Starting index test for table MDS_ATTRIBUTES:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_ATTRIBUTES: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting index test for table MDS_COMPONENTS:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_TXN_LOCKS: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting schema test:  TEST_REQUIRED_TRIGGERS  Test that the schema has all the required triggers
Completed schema test: TEST_REQUIRED_TRIGGERS --> Test that the schema has all the required triggers +++ PASS
Starting schema test:  TEST_MISSING_COLUMNS  Test that tables and views are not missing any required columns
Completed schema test: TEST_MISSING_COLUMNS --> Test that tables and views are not missing any required columns +++ PASS
Starting schema test:  TEST_UNEXPECTED_TABLES  Test that the schema does not contain any unexpected tables
Completed schema test: TEST_UNEXPECTED_TABLES --> Test that the schema does not contain any unexpected tables +++ PASS
Starting schema test:  TEST_UNEXPECTED_PROCEDURES  Test that the schema does not contain any unexpected stored procedures
Completed schema test: TEST_UNEXPECTED_PROCEDURES --> Test that the schema does not contain any unexpected stored procedures +++ PASS
Starting schema test:  TEST_UNEXPECTED_VIEWS  Test that the schema does not contain any unexpected views
Completed schema test: TEST_UNEXPECTED_VIEWS --> Test that the schema does not contain any unexpected views +++ PASS
Starting index test for table MDS_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Completed index test for table MDS_ATTRIBUTES: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Completed index test for table MDS_LABELS: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Starting index test for table MDS_LARGE_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Starting schema test:  TEST_UNEXPECTED_TRIGGERS  Test that the schema does not contain any unexpected triggers
Completed schema test: TEST_UNEXPECTED_TRIGGERS --> Test that the schema does not contain any unexpected triggers +++ PASS
Starting schema test:  TEST_UNEXPECTED_COLUMNS  Test that tables and views do not contain any unexpected columns
Completed schema test: TEST_UNEXPECTED_COLUMNS --> Test that tables and views do not contain any unexpected columns +++ PASS
Starting datatype test for table MDS_ATTRIBUTES:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table MDS_ATTRIBUTES: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table MDS_COMPONENTS:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Starting permissions test:  TEST_DBA_TABLE_GRANTS  Test that DBA user has privilege to view all user tables
Completed permissions test: TEST_DBA_TABLE_GRANTS --> Test that DBA user has privilege to view all user tables +++ PASS
Starting schema test:  TEST_ENOUGH_TABLESPACE  Test that the schema tablespaces automatically extend if full
Completed schema test: TEST_ENOUGH_TABLESPACE --> Test that the schema tablespaces automatically extend if full +++ PASS
Starting schema test:  TEST_USER_TABLESPACE_QUOTA  Test that tablespace quota for this user is sufficient to perform the upgrade
Completed schema test: TEST_USER_TABLESPACE_QUOTA --> Test that tablespace quota for this user is sufficient to perform the upgrade +++ PASS
Starting schema test:  TEST_ONLINE_TABLESPACE  Test that schema tablespaces are online
Completed schema test: TEST_ONLINE_TABLESPACE --> Test that schema tablespaces are online +++ PASS
Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
INFO   Database product version: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
Finished readiness check of Oracle Metadata Services with status: FAILURE.

12.1.3.0リリースのOracle Fusion Middleware IAUスキーマを実行しており、それらのスキーマが11gリリース(11.1.1.7以上)または12c (12.1.2.0)からアップグレードされた場合、準備状況チェックは次のエラーで失敗することがあります。

Starting index test for table IAU_COMMON:  TEST_REQUIRED_INDEXES --> Test
that the table contains all the required indexes
INFO Audit schema index DYN_EVENT_CATEGORY_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_EVENT_TYPE_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_TENANT_INDEX in table IAU_COMMON is missing
the required columns or index itself is missing. This maybe caused by a known
issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_USER_INDEX in table IAU_COMMON is missing
the required columns or index itself is missing. This maybe caused by a known
issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_COMPONENT_TYPE_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_USER_TENANT_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
Completed index test for table IAU_COMMON: TEST_REQUIRED_INDEXES --> Test
that the table contains all the required indexes +++ FAIL

注意:
準備状況レポートの索引欠落エラーは無視できます。これは既知の問題です。該当の欠落している索引は、スキーマ・アップグレード操作中に追加されます。アップグレードするスキーマがRCUを使用して12cで作成された場合、このエラーは発生しません。

7.4 サーバーとプロセスの停止

アップグレード・アシスタントを実行してスキーマおよび構成をアップグレードする前に、管理サーバーや管理対象サーバーを含め、すべてのプロセスとサーバーを停止する必要があります。

Oracle Fusion Middleware環境は、Oracle WebLogic Serverドメイン、管理サーバー、複数の管理対象サーバー、Javaコンポーネント、アイデンティティ管理コンポーネントなどのシステム・コンポーネント、およびメタデータのリポジトリに使用されるデータベースで構成できます。これらのコンポーネントは相互に依存する場合があるため、正しい順序で停止する必要があります。

注意:
この項の手順では、WLSTコマンドライン・ユーティリティまたはスクリプトを使用してサーバーおよびプロセスを停止する方法について説明します。Oracle Fusion Middleware ControlおよびOracle WebLogic Server管理コンソールを使用することもできます。Oracle Fusion Middlewareの管理の管理サーバー、管理対象サーバーおよびノード・マネージャの起動および停止を参照してください。

Fusion Middleware環境を停止するには、次の手順に従います。

手順1: システム・コンポーネントの停止

Oracle HTTP Serverなどのシステム・コンポーネントを停止するには、stopComponentスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

システム・コンポーネントは任意の順序で停止できます。

手順2: 管理対象サーバーの停止

WebLogic Server管理対象サーバーを停止するには、stopManagedWebLogicスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url

- (Windows) DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url

プロンプトが表示されたらユーザー名とパスワードを入力します。

手順3: Oracle Identity Managementコンポーネントの停止環境を構成しているOracle Internet DirectoryなどのOracle Identity Managementコンポーネントがあれば、それをすべて停止します。

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

ステップ4: 管理サーバーの停止

管理サーバーを停止する場合、管理サーバーで稼働しているWebLogic Server管理コンソールやFusion Middleware Controlなどのプロセスも停止します。

管理サーバーを停止するには、stopWebLogicスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/stopWebLogic.sh

- (Windows) DOMAIN_HOME\bin\stopWebLogic.cmd

プロンプトが表示されたら、管理サーバーのユーザー名とパスワードおよびURLを入力します。

注意:
リポジトリ用に外部のパスワード記憶域が設定されている場合は、アップグレード中に作業リポジトリのパスワードを取得できるように、資格証明ストアをホストしているサーバーが稼働している必要があります。詳細は、Oracle Fusion Middleware Oracle Data Integratorの管理の外部パスワード記憶域の設定を参照してください。

手順5: ノード・マネージャの停止

ノード・マネージャを停止するには、それが実行されているコマンド・シェルを閉じます。

またはnodemanager.propertiesのQuitEnabledの属性をtrueに設定した後(デフォルトはfalseです)、WLSTを使用して、ノード・マネージャに接続して停止できます。詳細は、Oracle Fusion Middleware WebLogic Server WLSTコマンド・リファレンスのstopNodeManagerを参照してください。

7.5 製品スキーマのアップグレード

サーバーおよびプロセスを停止した後、アップグレード・アシスタントを使用して、サポートされている製品スキーマを現在のリリースのOracle Fusion Middlewareにアップグレードします。

アップグレード・アシスタントを使用すると、個別に選択したスキーマまたはドメインに関連付けられているすべてのスキーマをアップグレードできます。選択したオプションによって、表示されるアップグレード・アシスタントの画面は異なります。

- アップグレード・アシスタントの起動
アップグレード・アシスタントを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。一度に1つのドメインのアップグレードを完了して、アップグレード・アシスタントを非SYSDBAユーザーとして実行することをお薦めします。

- アップグレード・アシスタントを使用した製品スキーマのアップグレード
アップグレード・アシスタントの各画面を移動して、製品スキーマをアップグレードします。

- スキーマ・アップグレードの確認
すべてのアップグレード手順の完了後、schema_version_registryのスキーマ・バージョンが正しく更新されたことを確認して、アップグレードが成功したことを確認します。

7.5.1 Upgrade Assistantの起動

アップグレード・アシスタントを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。一度に1つのドメインのアップグレードを完了して、アップグレード・アシスタントを非SYSDBAユーザーとして実行することをお薦めします。

Upgrade Assistantを起動するには、次の手順に従います。

1. oracle_common/upgrade/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. アップグレード・アシスタントを起動します。

- (UNIX) ./ua

- (Windows) ua.bat

ロギング・パラメータなど、コマンドラインで指定できるその他のパラメータの詳細は、次を参照してください。

- アップグレード・アシスタントのコマンドライン・パラメータ

7.5.1.1 アップグレード・アシスタントのコマンドライン・パラメータ

コマンドラインからアップグレード・アシスタントを起動するとき、追加パラメータを指定できます。

表7-4 アップグレード・アシスタントのコマンドライン・パラメータ

パラメータ

必須またはオプション

説明

-readiness

準備状況チェックに必須
注意: 準備状況チェックはスタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では実行できません。

実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。

スキーマおよび構成がチェックされます。

-examineパラメータを指定した場合、このパラメータを使用しないでください。

-threads

オプション

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックに必須

アップグレード・アシスタントがGUIモードで実行されたときに入力されたデータから生成されたレスポンス・ファイルに保存された入力を使用して、アップグレード・アシスタントを実行します。このパラメータを使用すると、アップグレード・アシスタントがサイレント・モードで(アップグレード・アシスタント画面を表示せずに)実行されます。

-examine

オプション

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel 属性

オプション

次のいずれかの属性を指定してロギング・レベルを設定します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

デフォルトのロギング・レベルはNOTIFICATIONです。

より多くの情報がロギングされるように-logLevel TRACE属性を設定することを検討してください。これは、失敗したアップグレードをトラブルシューティングするときに役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir 場所

オプション

アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。アップグレード・アシスタントによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

デフォルトの場所は次のとおりです。

(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

オプション

すべてのコマンドライン・オプションを表示します。

7.5.2 アップグレード・アシスタントを使用した製品スキーマのアップグレード

アップグレード・アシスタントの各画面を移動して、製品スキーマをアップグレードします。

注意

- 外部認証を使用している場合は、外部認証が内部認証に変更されていることを確認してください。

- エディションベースの再定義(EBR)ユーザーのみ: エディション・ベースの再定義(EBR)に対応したスキーマをアップグレードする前に、データベース・サーバーに接続して、12cのデータベース・サーバーにエディションを作成する必要があります。12cの新しいエディションは、既存の12cエディションの子である必要があります。再定義のためのサーバーでのエディション作成の詳細は、エディションベースの再定義のためのサーバー上でのエディションの作成を参照してください。

アップグレード・アシスタントで製品スキーマをアップグレードする手順は次のとおりです。

1. 「ようこそ」画面で、アップグレード・アシスタントの概要と、重要なアップグレード前のタスクに関する情報を確認します。「次へ」をクリックします

注意:
アップグレード・アシスタント画面の詳細は、画面で「ヘルプ」をクリックしてください。

2. 「選択したスキーマ」画面で、「個別に選択されたスキーマ」を選択します。

注意:
12c (12.2.1.2)コンポーネントをサポートするために使用されるスキーマのみをアップグレードしてください。Oracle Fusion Middleware 12c (12.2.1.2)に含まれていないコンポーネントをサポートするために現在使用されているスキーマはアップグレードしないでください。

「次へ」をクリックします。

3. 「使用可能なコンポーネント」画面で、マスターおよび作業リポジトリ・スキーマをアップグレードするために「Oracle Data Integrator」を選択します。

4. 「前提条件」画面ですべてのチェック・ボックスを選択して、前提条件を満たしていることを確認します。「次へ」をクリックします

注意:
アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。

5. ODIスキーマ画面で、アップグレードする各スキーマのデータベース接続の詳細を指定します。

- 「データベース・タイプ」ドロップダウン・メニューからデータベース・タイプを選択します。

- データベース接続の詳細を入力して、「接続」をクリックします。

- 「スキーマ・ユーザー名」ドロップダウン・メニューからアップグレードするスキーマを選択し、スキーマのパスワードを入力します。アップグレードするスキーマに対して正しいスキーマ接頭辞を使用してください。

6. 「ODIオプション」画面で、すべてのオプションを選択します。

表7-5 ODIのオプション

オプション

説明

ナレッジ・モジュールを必須更新で置換

これを選択すると、標準ナレッジ・モジュールが最新バージョンに置き換えられます。Oracleによりインストールされたナレッジ・モジュールに対するカスタマイズ内容は上書きされます。ただし、インストールされたナレッジ・モジュールをコピーしてからそのナレッジ・モジュールをカスタマイズした場合、カスタマイズ内容は失われません。

トポロジおよびセキュリティ・メタデータのアップグレード

これを選択すると、テクノロジ、データ型、セキュリティ・プロファイルなどのトポロジおよびセキュリティ・アーティファクトが最新バージョンに置き換えられます。インストールされたオブジェクトのカスタマイズ内容は上書きされます。オブジェクトをコピーしてからカスタマイズした場合、カスタマイズ内容は失われません。

高度なアップグレード・オプションの詳細は、「高度なアップグレード・オプション」を参照してください。

7. 「ODIスーパーバイザ」画面に、アップグレードするODIリポジトリのスーパーバイザ・アカウント資格証明を入力します。

インストールされているスーパーバイザ・アカウントはSUPERVISORです。ODIのマスター・リポジトリおよび作業リポジトリの作成時にリポジトリ作成ユーティリティ(RCU)で求められたときに指定した、正しいスーパーバイザ・アカウント名およびパスワードについては、ODI管理者に確認してください。

注意:
「ドメインで使用されるすべてのスキーマ」が選択されている場合、ODIのスーパーバイザ資格証明はドメインに含まれていないため、最初のインスタンスにあらかじめ移入されません。複数のODIスキーマがある場合、アップグレード・アシスタントは最初の資格証明のセットを使用してユーザー・エントリに移入します。

8. 「調査」画面で、各スキーマを調査した際のアップグレード・アシスタントのステータスを確認し、スキーマのアップグレード準備が整っていることを確認します。ステータスが「調査が終了しました。」になっている場合は、「次へ」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、共通するアップグレード・エラーの解決に関する情報をOracle Fusion Middleware Upgrade Assistantによるアップグレードのアップグレードのトラブルシューティングで参照します。

注意:

- 調査フェーズの間に、アップグレードを続行せずに検出された問題を解決した場合は、バックアップからリストアすることなしに、アップグレード・アシスタントを再起動できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックして続行した場合は、アップグレード・アシスタントを再起動する前に、アップグレード前の環境をバックアップからリストアする必要があります。

- 調査プロセスを取り消してもスキーマまたは構成データに影響はありませんが、将来のアップグレード・セッションでは、Upgrade Assistantが収集した情報を再収集する必要があります。

9. 「アップグレード・サマリー」画面で、スキーマ・アップグレードに選択したオプションのサマリーを確認します。
正しいソース・バージョンとターゲット・バージョンが、アップグレード対象の各スキーマにリストされていることを確認します。

後でアップグレード・アシスタントをレスポンス(またはサイレント)モードで再び実行するためにこれらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックして、レスポンス・ファイルの場所および名前を指定します。サイレント・アップグレードは、アップグレード・アシスタント・とまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。

10. 「アップグレードの進行状況」画面でアップグレードのステータスを監視します。

注意:
アップグレード・アシスタントにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。これを行うと、環境が不安定になる可能性があります。

正しくアップグレードされていないスキーマがある場合は、アップグレード・アシスタントのログ・ファイルで情報を確認します。

注意:
この画面の進捗バーには、現在のアップグレード手順の進行状況が表示されます。アップグレードの残り時間を示すものではありません。

「次へ」をクリックします。

11. アップグレードが成功した場合、「アップグレード成功」画面で「閉じる」をクリックし、アップグレードを完了してウィザードを閉じます。

アップグレードが失敗した場合、「アップグレード失敗」画面で「ログの表示」をクリックし、エラーを表示してトラブルシューティングします。ログはORACLE_HOME/oracle_common/upgrade/logsにあります。

注意:
アップグレードに失敗した場合、アップグレード前の環境をバックアップからリストアし、問題を修正して、アップグレード・アシスタントを再起動する必要があります。

7.5.3 スキーマのアップグレードの確認

すべてのアップグレード手順の完了後、schema_version_registryのスキーマ・バージョンが正しく更新されたことを確認して、アップグレードが成功したことを確認します。

Oracle Databaseを使用する場合、Oracle DBAを持つユーザーとしてデータベースに接続し、SQL*Plusから次を実行して現行のバージョン番号を取得します。

SET LINE 120
COLUMN MRC_NAME FORMAT A14
COLUMN COMP_ID FORMAT A20
COLUMN VERSION FORMAT A12
COLUMN STATUS FORMAT A9
COLUMN UPGRADED FORMAT A8
SELECT MRC_NAME, COMP_ID, OWNER, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY ORDER BY MRC_NAME, COMP_ID ;

問合せ結果:

- VERSION列の数値が、そのスキーマの最新のバージョン番号に一致していることを確認します。たとえば、スキーマ・バージョン番号が12.2.1.2.0であることを確認します。ただし、すべてのスキーマ・バージョンが更新されるわけではないことに注意してください。一部のスキーマではこのリリースへのアップグレードが必要なく、アップグレード前のバージョン番号が保持されます。

- STATUSフィールドは、スキーマのパッチ適用操作中は「UPGRADING」または「UPGRADED」に、操作が完了すると「VALID」になります。

- ステータスが「INVALID」と表示された場合は、ステータスの更新が失敗しています。ログ・ファイルを調べて、失敗した理由を判定する必要があります。

- IAU_APPENDおよびIAU_VIEWERによって所有されるシノニム・オブジェクトは、INVALIDとして表示されますが、失敗を示すものではありません。
それらは、シノニムの作成後にターゲット・オブジェクトが変更されるため無効になります。シノニム・オブジェクトはアクセスされると有効になります。これらのINVALIDオブジェクトは無視しても問題ありません。

7.6 ドメインの再構成

再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.2)に再構成します。

WebLogic Serverドメインを再構成する場合は、ドメイン内のアプリケーションに応じて次の項目が自動的に更新されます。

- WebLogic Serverコア・インフラストラクチャ

- ドメイン・バージョン

注意:

ドメインの再構成を開始する前に、次の制限に注意してください。

- 再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。

- アップグレード・プロセス中に非動的クラスタ・ドメインを動的クラスタ・ドメインに変換することはサポートされていません。
動的クラスタ機能は再構成ウィザードの実行中は使用できますが、非動的クラスタをアップグレードしてから動的クラスタを追加することのみがサポートされています。アップグレード・プロセス中に動的クラスタを追加することはできません。

具体的には、ドメインを再構成すると、次のようになります。

- ドメインのconfig.xmlファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンに更新されます。

- すべてのインストール済Oracle製品の再構成テンプレートは、自動的に選択されてドメインに適用されます。これらのテンプレートは、WebLogicドメインが現在のWebLogic Serverバージョンと互換性を持つために必要な再構成タスクを定義します。

- 起動スクリプトが更新されます。
変更した起動スクリプトを保持する場合、再構成ウィザードを起動する前にそのスクリプトをバックアップしてください。

注意:
ドメインの再構成プロセスを開始すると、元に戻すことはできません。再構成ウィザードを実行する前に、アップグレード前チェックリストで示されているようにドメインをバックアップしたことを確認してください。再構成ウィザードの実行中にエラーまたは他の割込みが発生した場合、バックアップ場所から元のドメイン・ディレクトリにファイルとディレクトリをコピーすることによって、ドメインをリストアする必要があります。これは、再構成前にドメインを確実に元の状態に戻す唯一の方法です。

再構成ウィザードを使用して既存のドメインを再構成する手順に従います。ドメインの再構成に関する一般情報は、Oracle Fusion Middleware Oracle WebLogic ServerのアップグレードのWebLogicドメインの再構成を参照してください。

- ドメインのバックアップ

- 再構成ウィザードの起動

- 再構成ウィザードを使用したドメインの再構成

7.6.1 ドメインのバックアップ

再構成ウィザードを実行する前に、ドメイン・ディレクトリのバックアップ・コピーを作成します。

ドメイン・ディレクトリのバックアップを作成する手順は次のとおりです。

1. コンテンツを保持するには、ソース・ドメインを別の場所にコピーします。
たとえば、C:\domains\mydomainをC:\domains\mydomain_backupにコピーします。

2. 各リモート管理対象サーバーのドメインを更新する前に、各リモート・マシンのドメイン・ディレクトリのバックアップ・コピーを作成します。

3. ドメインのバックアップしたバージョンが完全であることを確認します。

ドメインの再構成がなんらかの理由で失敗した場合は、再構成を実行する前に、すべてのファイルおよびディレクトリをバックアップ・ディレクトリから元のドメイン・ディレクトリにコピーしてドメインを完全に元の状態に戻す必要があります。

7.6.2 再構成ウィザードの起動

再構成ウィザードをグラフィカル・モードで起動する手順は次のとおりです。

1. ドメインが存在するシステムにサインインします。

2. コマンド・シェル(UNIXオペレーティング・システムの場合)またはコマンド・プロンプト・ウィンドウ(Windowsオペレーティング・システムの場合)を開きます。

3. エディション・ベースのデータベース・ユーザーのみ: スキーマがEBRデータベースを使用して構成されている場合、再構成ウィザードを実行する前に、手動でデフォルトのエディション名を設定する必要があります。
次のSQLコマンドを実行して、デフォルト・エディションを設定します。
ALTER DATABASE DEFAULT EDITION = edition_name;

ここで、edition_nameは、子エディション名です。

4. oracle_common/common/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/common/bin

- (Windows) ORACLE_HOME\oracle_common\commom\bin

5. 再構成ウィザードを次のロギング・オプションとともに起動します。

- (UNIX) ./reconfig.sh -log=log_file -log_priority=ALL

- (Windows) reconfig.cmd -log=log_file -log_priority=ALL

log_fileは、ドメイン再構成セッション用に作成するログ・ファイルの絶対パスです。これは、再構成処理をトラブルシューティングする必要がある場合に役立つことがあります。

パラメータ-log_priority=ALLは、ログを詳細モードで出力します。

注意:

このコマンドを実行すると、デフォルトのキャッシュ・ディレクトリが無効であることを示す次のエラー・メッセージが表示される場合があります。

*sys-package-mgr*: can't create package cache dir

環境変数CONFIG_JVM_ARGSを設定することでキャッシュ・ディレクトリを変更できます。次に例を示します。

CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

7.6.3 再構成ウィザードを使用したドメインの再構成

アップグレード・アシスタントを実行する前に、再構成ウィザードの各画面を移動して既存のドメインを再構成します。

注意:
ソースがクラスタ環境である場合は、再構成ウィザードをプライマリ・ノードでのみ実行します。packおよびunpackユーティリティを使用して、ドメイン内の他のクラスタ・メンバーに変更を適用します。

再構成ウィザードを使用してドメインを再構成する手順は次のとおりです。

1. 「ドメインの選択」画面で、アップグレードするドメインの場所を指定するか、「参照」をクリックしてナビゲートし、ドメインのディレクトリを選択します。「次へ」をクリックします。

2. 「再構成セットアップの進行状況」画面で、設定プロセスの進行状況を表示します。完了したら、「次へ」をクリックします。
このプロセスでは次の処理が行われます。

- Fusion Middleware製品を含む、インストール済製品の再構成テンプレートが自動的に適用されます。これにより、config.xml、config-groups.xml、security.xmlなどの様々なドメイン構成ファイルが更新されます。

- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

- ドメイン・アップグレードが検証されます。

3. 「ドメイン・モードおよびJDK」画面で、ドメインで使用するJDKを選択するか、「参照」をクリックして、使用するJDKにナビゲートします。12c (12.2.1.2)に対してサポートされているJDKバージョンは1.8.0_101以上です。「次へ」をクリックします。

注意:
このステージでは、「ドメイン・モード」を変更することはできません。

特定のプラットフォームでサポートされているJDKのリストは、Oracle Fusion Middlewareでサポートされているシステム構成の説明を参照してください。

4. 「データベース構成タイプ」画面で、「RCUデータ」を選択してサービス表(_STB)スキーマに接続します。
RCUサービス表(_STB)スキーマ資格証明を使用してデータベース接続の詳細を入力するか、「RCU構成の取得」をクリックします。

再構成ウィザードは、この接続を使用して、ドメインのコンポーネントに必要なデータソースを自動的に構成します。
注意: 既存の11gデータ・ソースの場合、再構成では既存の値が保持されます。スキーマがRCUによって12c用に作成された新しいデータ・ソースの場合、デフォルトの接続データは_STBスキーマから取得されます。特定のスキーマの接続データが_STBスキーマにない場合は、デフォルトの接続データが使用されます。

チェックが成功した場合は、「次へ」をクリックします。チェックが失敗した場合は、接続の正しい詳細を再入力し、再試行します。

5. 「JDBCコンポーネント・スキーマ」画面で、各コンポーネント・スキーマのDBMS/サービスおよびホスト名が正しいことを確認し、「次へ」をクリックします。

6. 「JDBCコンポーネント・スキーマ・テスト」画面で、すべてのコンポーネント・スキーマを選択して「選択された接続のテスト」をクリックし、各スキーマの接続をテストします。テストの結果は、「ステータス」列に表示されます。
チェックが完了したら、「次へ」をクリックします。

7. 「拡張構成」画面で、拡張構成を実行するすべてのカテゴリを選択できます。選択したカテゴリごとに、詳細構成を行うことができる適切な構成画面が表示されます。

注意:
「拡張構成」画面にリストされるカテゴリは、ドメインに選択したテンプレートに定義されているリソースによって異なります。

このアップグレードではオプションを選択せずに、「次へ」をクリックします。

8. 「構成のサマリー」画面で、ドメインの詳細な構成設定を確認してから続行します。
「表示」ドロップダウン・リストからフィルタ・オプションを選択すると、右側のパネルに表示される項目を制限できます。

構成を変更するには、「戻る」をクリックして適切な画面に戻ります。ドメインを再構成するには、「再構成」をクリックします。

注意:
ドメインを再構成しても、その場所は変更されません。

9. 「再構成の進行状況」画面には、再構成プロセスの進行状況が表示されます。
このプロセスでは次の処理が行われます。

- ドメイン情報が抽出、保存および更新されます。

- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

進捗バーが100%になったら、「次へ」をクリックします。

10. 「構成の終了」画面には、再構成プロセスが正常に完了したか失敗したかが示されます。管理サーバーURL(リスニング・ポートを含む)とともに再構成されたドメインの場所も表示します。再構成が成功した場合は、「Oracle Weblogic Serverの再構成に成功しました」と表示されます。
再構成プロセスが正常に完了しなかった場合は、その理由を示すエラー・メッセージが表示されます。問題を解決するための適切な措置を講じます。問題を解決できない場合は、My Oracle Supportに連絡してください。

以後の操作のためにドメインの場所と管理サーバーURLをメモします。

7.7 ドメイン・コンポーネント構成のアップグレード

ドメインの再構成後、アップグレード・アシスタントを使用して、ドメイン内のドメイン・コンポーネント構成を更新済ドメイン構成に一致するようにアップグレードします。

- アップグレード・アシスタントの起動
アップグレード・アシスタントを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。一度に1つのドメインのアップグレードを完了して、アップグレード・アシスタントを非SYSDBAユーザーとして実行することをお薦めします。

- アップグレード・アシスタントを使用したドメイン・コンポーネント構成のアップグレード
アップグレード・アシスタントの各画面を移動して、WebLogicドメイン内のコンポーネント構成をアップグレードします。

7.7.1 Upgrade Assistantの起動

アップグレード・アシスタントを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。一度に1つのドメインのアップグレードを完了して、アップグレード・アシスタントを非SYSDBAユーザーとして実行することをお薦めします。

Upgrade Assistantを起動するには、次の手順に従います。

1. oracle_common/upgrade/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. アップグレード・アシスタントを起動します。

- (UNIX) ./ua

- (Windows) ua.bat

ロギング・パラメータなど、コマンドラインで指定できるその他のパラメータの詳細は、次を参照してください。

- アップグレード・アシスタントのコマンドライン・パラメータ

7.7.1.1 アップグレード・アシスタントのコマンドライン・パラメータ

コマンドラインからアップグレード・アシスタントを起動するとき、追加パラメータを指定できます。

表7-6 アップグレード・アシスタントのコマンドライン・パラメータ

パラメータ

必須またはオプション

説明

-readiness

準備状況チェックに必須
注意: 準備状況チェックはスタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では実行できません。

実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。

スキーマおよび構成がチェックされます。

-examineパラメータを指定した場合、このパラメータを使用しないでください。

-threads

オプション

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックに必須

アップグレード・アシスタントがGUIモードで実行されたときに入力されたデータから生成されたレスポンス・ファイルに保存された入力を使用して、アップグレード・アシスタントを実行します。このパラメータを使用すると、アップグレード・アシスタントがサイレント・モードで(アップグレード・アシスタント画面を表示せずに)実行されます。

-examine

オプション

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel 属性

オプション

次のいずれかの属性を指定してロギング・レベルを設定します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

デフォルトのロギング・レベルはNOTIFICATIONです。

より多くの情報がロギングされるように-logLevel TRACE属性を設定することを検討してください。これは、失敗したアップグレードをトラブルシューティングするときに役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir 場所

オプション

アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。アップグレード・アシスタントによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

デフォルトの場所は次のとおりです。

(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

オプション

すべてのコマンドライン・オプションを表示します。

7.7.2 アップグレード・アシスタントを使用したドメイン・コンポーネント構成のアップグレード

アップグレード・アシスタントの各画面を移動して、WebLogicドメイン内のコンポーネント構成をアップグレードします。

再構成ウィザードを実行してWebLogicドメインを12c (12.2.1.2)に再構成した後、アップグレード・アシスタントを実行して、ドメイン・コンポーネント構成を更新済ドメイン構成に一致するようにアップグレードする必要があります。

アップグレード・アシスタントを使用してドメイン・コンポーネント構成をアップグレードする手順は次のとおりです。

1. 「ようこそ」画面で、アップグレード・アシスタントの概要と、重要なアップグレード前のタスクに関する情報を確認します。「次へ」をクリックします

注意:
アップグレード・アシスタント画面の詳細は、画面で「ヘルプ」をクリックしてください。

2. 次の画面で次のようにします。

- 「ドメインによって使用されるすべての構成」を選択します。画面名は「WebLogicコンポーネント」になります。

- 「ドメイン・ディレクトリ」フィールドにWebLogicドメイン・ディレクトリ・パスを入力します。

「次へ」をクリックします。

3. 「コンポーネント・リスト」画面で、構成をアップグレードするすべてのコンポーネントがリストに含まれていることを確認して「次へ」をクリックします。
アップグレード対象のコンポーネントが表示されていない場合は、「戻る」をクリックして前の画面に戻り、別のドメインを指定します。

4. 「前提条件」画面ですべてのチェック・ボックスを選択して、前提条件を満たしていることを確認します。「次へ」をクリックします

注意:
アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。

5. 「調査」画面で、各コンポーネントを調査した際のアップグレード・アシスタントのステータスを確認し、コンポーネント構成のアップグレード準備が整っていることを確認します。ステータスが「調査が終了しました。」になっている場合は、「次へ」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、共通するアップグレード・エラーの解決に関する情報をOracle Fusion Middleware Upgrade Assistantによるアップグレードのアップグレードのトラブルシューティングで参照します。

注意:

- 調査フェーズの間に、アップグレードを続行せずに検出された問題を解決した場合は、バックアップからリストアすることなしに、アップグレード・アシスタントを再起動できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックして続行した場合は、アップグレード・アシスタントを再起動する前に、アップグレード前の環境をバックアップからリストアする必要があります。

- 調査プロセスを取り消しても構成データに影響はありませんが、将来のアップグレード・セッションでは、アップグレード・アシスタントが収集した情報を再収集する必要があります。

6. 「アップグレード・サマリー」画面で、コンポーネント構成アップグレードに選択したオプションのサマリーを確認します。
レスポンス・ファイルには、入力したすべての情報が収集して格納され、後でサイレント・アップグレードを実行するために使用できます。サイレント・アップグレードは、アップグレード・アシスタント・とまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。

7. 「アップグレードの進行状況」画面でアップグレードのステータスを監視します。

注意:
アップグレード・アシスタントにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。これを行うと、環境が不安定になる可能性があります。

正しくアップグレードされていないコンポーネントがある場合は、Upgrade Assistantのログ・ファイルで情報を確認します。

注意:
この画面の進捗バーには、現在のアップグレード手順の進行状況が表示されます。アップグレードの残り時間を示すものではありません。

「次へ」をクリックします。

8. アップグレードが成功した場合、「アップグレード成功」画面で「閉じる」をクリックし、アップグレードを完了してウィザードを閉じます。新規インストールでコンポーネントを機能させるために手動で実行する必要のあるタスクが、アップグレード後のアクションのウィンドウに表示されます。このウィンドウは、コンポーネントにアップグレード後の手順がある場合にのみ表示されます。

アップグレードが失敗した場合、「アップグレード失敗」画面で「ログの表示」をクリックし、エラーを表示してトラブルシューティングします。ログはORACLE_HOME/oracle_common/upgrade/logsにあります。

注意:
アップグレードに失敗した場合、アップグレード前の環境をバックアップからリストアし、問題を修正して、アップグレード・アシスタントを再起動する必要があります。

7.8 サーバーおよびプロセスの起動

アップグレードが成功した後、管理サーバーおよび管理対象サーバーを含め、すべてのプロセスおよびサーバーを再起動します。

これらのコンポーネントは相互に依存する場合があるため、正しい順序で起動する必要があります。

注意:
この項の手順では、WLSTコマンドラインまたはスクリプトを使用してサーバーおよびプロセスを起動する方法について説明します。Oracle Fusion Middleware ControlおよびOracle WebLogic Server管理コンソールを使用することもできます。Oracle Fusion Middlewareの管理の管理サーバー、管理対象サーバーおよびノード・マネージャの起動および停止を参照してください。

Fusion Middleware環境を起動するには、次の手順に従います。

ステップ1: 管理サーバーの起動

管理サーバーを起動する場合、管理サーバーで稼働しているWebLogic Server管理コンソールやFusion Middleware Controlなどのプロセスも起動します。

管理サーバーを起動するには、startWebLogicスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/startWebLogic.sh

- (Windows) DOMAIN_HOME\bin\startWebLogic.cmd

プロンプトが表示されたら、管理サーバーのユーザー名とパスワードおよびURLを入力します。

手順2: ノード・マネージャの起動

ノード・マネージャを起動するには、startNodeManagerスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/startNodeManager.sh

- (Windows) DOMAIN_HOME\bin\startNodeManager.cmd

手順3: Oracle Identity Managementコンポーネントの起動環境を構成しているOracle Internet DirectoryなどのOracle Identity Managementコンポーネントがあれば、それをすべて起動します。

- (UNIX) DOMAIN_HOME/bin/startComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\startComponent.cmd component_name

手順4: 管理対象サーバーの起動

WebLogic Server管理対象サーバーを起動するには、startManagedWebLogicスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

- (Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url

プロンプトが表示されたらユーザー名とパスワードを入力します。

注意:
通常は、管理対象サーバーの起動により、それにデプロイされているアプリケーションが開始されます。したがって、管理対象サーバーの起動後にアプリケーションを手動で開始する必要はありません。

手順5: システム・コンポーネントの起動

Oracle HTTP Serverなどのシステム・コンポーネントを起動するには、startComponentスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/startComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\startComponent.cmd component_name

システム・コンポーネントは任意の順序で起動できます。

8 Oracle Data Integrator Java EEエージェント環境の前の12cリリースからのアップグレード

Oracle Data Integrator Java EEエージェント環境を前のOracle Fusion Middleware 12cリリースから12c (12.2.1.2)にアップグレードできます。

- Oracle Data Integrator Java EEエージェントのアップグレード・プロセスについて
Oracle Data Integrator Java EEエージェントのアップグレード・プロセスの概要を示すプロセス・フローチャートを確認します。

- Oracle Data Integrator Java EE環境のインストール
アップグレードを開始する前に、Oracle Fusion Middleware InfrastructureおよびOracle Data Integrator 12c (12.2.1.2)ディストリビューションをターゲット・システムにダウンロードし、Oracle Universal Installerを使用してインストールします。

- アップグレード前の準備状況チェックの実行
アップグレードの潜在的な問題を特定するために、アップグレード・プロセスを開始する前に準備状況チェックを実行することをお薦めします。準備状況チェックで、アップグレードの潜在的な問題をすべて検出できない場合があることに注意してください。準備状況チェックで成功が報告されても、アップグレードが失敗する場合があります。

- サーバーおよびプロセスの停止
アップグレード・アシスタントを実行してスキーマおよび構成をアップグレードする前に、管理サーバーや管理対象サーバーを含め、すべてのプロセスとサーバーを停止する必要があります。

- 製品スキーマのアップグレード
サーバーおよびプロセスを停止した後、アップグレード・アシスタントを使用して、サポートされている製品スキーマを現在のリリースのOracle Fusion Middlewareにアップグレードします。

- ドメインの再構成
再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.2)に再構成します。

- ドメイン・コンポーネント構成のアップグレード
ドメインの再構成後、アップグレード・アシスタントを使用して、ドメイン内のドメイン・コンポーネント構成を更新済ドメイン構成に一致するようにアップグレードします。

- サーバーおよびプロセスの起動
アップグレードが成功した後、管理サーバーおよび管理対象サーバーを含め、すべてのプロセスおよびサーバーを再起動します。

親トピック: Oracle Data Integratorの前の12cリリースからのアップグレード

8.1 Oracle Data Integrator Java EEエージェントのアップグレード・プロセスについて

Oracle Data Integrator Java EEエージェントのアップグレード・プロセスの概要を示すプロセス・フローチャートを確認します。

表8-1 Oracle Data Integrator Java EEエージェントを前の12cリリースからアップグレードするためのタスク

タスク

説明

必須

このガイドの概要のトピックをまだ確認していない場合は確認し、必要なアップグレード前のタスクを完了します。

次を参照してください。

- Oracle Data Integratorの12c (12.2.1.2)へのアップグレードの概要

- アップグレード前の要件

必須

Oracle Fusion Middleware InfrastructureおよびOracle Data Integrator 12c (12.2.1.2)を新しいOracleホームにインストールします。

Oracle Data Integrator Java EE環境のインストールを参照してください。

オプション

アップグレード前の準備状況チェックを実行します。

「アップグレード前の準備状況チェックの実行」を参照してください。

必須

12c環境を停止します(すべての管理サーバーと管理対象サーバーを停止します)。

警告: アップグレード中にサーバーを停止しないと、データが破壊される可能性があります。

「サーバーとプロセスの停止」を参照

必須

アップグレード・アシスタントを起動して、データベース・スキーマをアップグレードし、すべてのアクティブ(進行中の)インスタンス・データを移行します。

製品スキーマのアップグレードを参照してください。

注意: アクティブ・インスタンス・データのアップグレードは、アップグレード・アシスタントの実行中に自動で開始されます。データが正常に新しい12c (12.2.1.2)環境にアップグレードされたら、アップグレード・アシスタントを終了してもかまいません。クローズされたインスタンスのアップグレードは、バックグランド・プロセスで継続されます。

必須

再構成ウィザードを起動してドメインを再構成します。

構成ウィザードを実行して、既存のドメインを更新して新しくインストールしたソフトウェアを使用します。

ドメインの再構成を参照してください。

JRFコンポーネントのアップグレードが必要な場合は必須

アップグレード・アシスタントを(再度)起動して、ドメイン・コンポーネント構成をアップグレードします。

アップグレード・アシスタントを実行して、再構成したドメインのコンポーネント構成をアップグレードします。

ドメイン・コンポーネント構成のアップグレードを参照してください。

必須

サーバーおよび12c (12.2.1.2)インスタンスを再起動します。

アップグレード・プロセスが完了したら、12c (12.2.1.2)インスタンスを再起動します。

サーバーおよびプロセスの起動を参照してください。

必須

アップグレードを確認します。

バックアップを削除する前に、アップグレードしたコンポーネントがすべて期待どおりに動作していることを確認します。

8.2 Oracle Data Integrator Java EE環境のインストール

アップグレードを開始する前に、Oracle Fusion Middleware InfrastructureおよびOracle Data Integrator 12c (12.2.1.2)ディストリビューションをターゲット・システムにダウンロードし、Oracle Universal Installerを使用してインストールします。

注意:
アップグレードにInfrastructureが必要な場合、他のFusion Middleware製品をインストールする前に、まずOracle Fusion Middleware Infrastructureディストリビューションをインストールする必要があります。

12c (12.2.1.2)ディストリビューションをインストールする手順は次のとおりです。

1. 12c (12.2.1.2)製品ディストリビューションをインストールするターゲット・システムにサインインします。

2. 次の12c (12.2.1.2)製品ディストリビューションをOracle Technology NetworkまたはOracle Software Delivery Cloudからターゲット・システムにダウンロードします。

- Oracle Fusion Middleware Infrastructure (fmw_12.2.1.2.0_infrastructure_generic.jar)

- Oracle Data Integrator (fmw_12.2.1.2.0_odi_Disk1_1of2.zipおよびfmw_12.2.1.2.0_odi_Disk1_2of2.zip )

3. 12c (12.2.1.2)製品のディストリビューションをダウンロードしたディレクトリに移動します。

4. インストールfmw_12.2.1.2.0_odi_Disk1_1of2.zipおよびfmw_12.2.1.2.0_odi_Disk1_2of2.zipファイルを解凍します。

5. Oracle Fusion Middleware Infrastructureのインストール・プログラムを起動します。

- (UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

- (Windows) JDK_HOME\bin\java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

6. UNIXオペレーティング・システムでは、このホストにOracle製品を初めてインストールする場合に、「インストール・インベントリの設定」画面が表示されます。
中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システム・グループ名に対して中央インベントリの場所への書込み権限が付与されていることを確認し、「次へ」をクリックします。

注意:
「インストール・インベントリの設定」画面は、Windowsオペレーティング・システムでは表示されません。

7. 「ようこそ」画面で、情報をレビューしてすべての前提条件を満たしていることを確認します。「次へ」をクリックします

8. 「自動更新」画面で「自動更新をスキップ」を選択します。オプションは次のとおりです。

- この時点でソフトウェアの更新をシステムで確認しないようにする場合は、「自動更新をスキップ」を選択します。

- パッチ・ファイルをダウンロードした場合は、「ディレクトリからパッチを選択」を選択して、ローカル・ディレクトリに移動します。

- My Oracle Supportアカウントを持っている場合にソフトウェアの更新を自動でダウンロードするには、「My Oracle Supportで更新を検索」を選択します。Oracle Supportの資格証明を入力して、「検索」をクリックします。インストーラがMy Oracle Supportにアクセスするようにプロキシ・サーバーを構成するには、「プロキシ設定」をクリックします。「接続のテスト」をクリックして接続をテストします。

「次へ」をクリックします。

9. 「インストールの場所」画面でOracleホーム・ディレクトリの場所を指定し、「次へ」をクリックします。
Oracle Fusion Middlewareディレクトリ構造の詳細は、Oracle Fusion Middleware Oracle Fusion Middlewareのインストールのプランニングのインストールおよび構成のためのディレクトリの理解を参照してください。

10. 「インストール・タイプ」画面で、次を選択します。

- Infrastructureには、「Fusion Middlewareインフラストラクチャ」を選択します

- Oracle Data Integratorには、「エンタープライズ・インストール」を選択します

「次へ」をクリックします。

11. 「前提条件チェック」画面では、ホスト・コンピュータを分析して、特定のオペレーティング・システムの前提条件を満たしているか確認します。
確認されたタスクのリストを表示するには、「正常なタスクの表示」を選択します。ログの詳細を表示するには、「ログの表示」を選択します。前提条件のチェックが失敗すると、エラー・メッセージが画面の下方に表示されます。エラーを修正し、「再実行」をクリックして再試行します。エラー・メッセージや警告メッセージを無視してインストールを続けるには、「スキップ」をクリックします(非推奨)。

12. 「インストールの概要」画面で、選択したインストール・オプションを確認します。
これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を入力します。レスポンス・ファイルには、入力したすべての情報が収集して格納され、後で(コマンドラインから)サイレント・インストールを実行するために使用できます。
「インストール」をクリックしてインストールを開始します。

13. 「インストールの進行状況」画面で進捗バーが100%になったら、「終了」をクリックしてインストーラを閉じるか、「次へ」をクリックしてサマリーを確認します。

14. 「インストール完了」画面に、インストールの場所とインストールされた機能セットが表示されます。情報を確認し、「終了」をクリックしてインストーラを閉じます。

15. Oracle Fusion Middleware Infrastructureをインストールした後、次のコマンドを入力して製品ディストリビューションのインストーラを起動し、前述の手順を繰り返してインストーラの各画面を移動します。
(UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.2.0_odi_generic.jar

(Windows) JDK_HOME\bin\java -jar fmw_12.2.1.2.0_odi_generic.jar

8.3 アップグレード前の準備状況チェックの実行

アップグレードの潜在的な問題を特定するために、アップグレード・プロセスを開始する前に準備状況チェックを実行することをお薦めします。準備状況チェックで、アップグレードの潜在的な問題をすべて検出できない場合があることに注意してください。準備状況チェックで成功が報告されても、アップグレードが失敗する場合があります。

- アップグレード前の準備状況チェックの実行について
アップグレード・アシスタントを-readinessモードで実行することにより、実際にアップグレードを実行する前に問題を検出できます。準備状況チェックは、アップグレード・アシスタントを使用してGUIモードで実行するか、レスポンス・ファイルを使用してサイレント・モードで実行できます。

- 準備状況モードでのアップグレード・アシスタントの起動
-readinessパラメータを使用して、アップグレード・アシスタントを準備状況モードで起動します。

- アップグレード・アシスタントでの準備状況チェックの実行
アップグレード・アシスタントの各画面を移動して、アップグレード前の準備状況チェックを完了します。

- 準備状況レポートの理解
ドメインの準備状況チェックを実行した後、レポートを確認して、アップグレードが成功するためにアクションを実行する必要があるかどうかを決定します。

8.3.1 アップグレード前の準備状況チェックの実行について

アップグレード・アシスタントを-readinessモードで実行することにより、実際にアップグレードを実行する前に問題を検出できます。準備状況チェックは、アップグレード・アシスタントを使用してGUIモードで実行するか、レスポンス・ファイルを使用してサイレント・モードで実行できます。

アップグレード・アシスタントの準備状況チェックでは、サポートされる開始点にあるFusion MiddlewareスキーマおよびWebLogicドメイン構成の読取り専用のアップグレード前確認を実行します。確認は読取り専用操作です。

準備状況チェックでは、フォーマットされ、タイムスタンプの付けられた準備状況レポートが生成され、実際のアップグレードを試みる前に潜在的な問題に対処できます。問題が検出されない場合は、アップグレード・プロセスを開始できます。アップグレードを実行する前に、このレポートを詳細に確認することをお薦めします。

準備状況チェックは、既存のOracle Fusion Middlewareドメインがオンライン(他のユーザーがアクティブに使用している間)またはオフラインである間に実行できます。

実際のアップグレードを実行する前に、準備状況チェックを何度でも実行できます。ただし、アップグレードを実行した後は、レポートの結果がアップグレード前の準備状況チェックの結果と異なる可能性があるため、準備状況チェックを実行しないでください。

注意:

パフォーマンスが影響されることを回避するために、オフピーク時に準備状況チェックを実行することをお薦めします。

8.3.2 準備状況モードでのUpgrade Assistantの起動

-readinessパラメータを使用して、アップグレード・アシスタントを準備状況モードで起動します。

アップグレード・アシスタントでアップグレード前の環境に対して準備状況チェックを実行する手順は次のとおりです。

1. oracle_common/upgrade/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. アップグレード・アシスタントを起動します。

- (UNIX) ./ua -readiness

- (Windows) ua.bat -readiness

注意:
GUIモードを許可するようにDISPLAY環境変数を適切に設定していない場合、次のエラーが発生することがあります。

Xlib: connection to ":1.0" refused by server
Xlib: No protocol specified

この問題を解決するには、使用するローカル・ワークステーションのシステム名またはIPアドレスにDISPLAY環境変数を設定して、アップグレード・アシスタントを再実行します。

DISPLAYを設定してもこのエラーが引き続き発生する場合は、vncconfigなどの他のGUIツールの起動を試みてください。同じエラーが表示される場合は、DISPLAY環境変数がまだ正しく設定されていない可能性があります。

コマンドラインで指定できるその他のパラメータの詳細は、次を参照してください。

- アップグレード・アシスタントのコマンドライン・パラメータ

8.3.2.1 アップグレード・アシスタントのコマンドライン・パラメータ

コマンドラインからアップグレード・アシスタントを起動するとき、追加パラメータを指定できます。

表8-2 アップグレード・アシスタントのコマンドライン・パラメータ

パラメータ

必須またはオプション

説明

-readiness

準備状況チェックに必須
注意: 準備状況チェックはスタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では実行できません。

実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。

スキーマおよび構成がチェックされます。

-examineパラメータを指定した場合、このパラメータを使用しないでください。

-threads

オプション

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックに必須

アップグレード・アシスタントがGUIモードで実行されたときに入力されたデータから生成されたレスポンス・ファイルに保存された入力を使用して、アップグレード・アシスタントを実行します。このパラメータを使用すると、アップグレード・アシスタントがサイレント・モードで(アップグレード・アシスタント画面を表示せずに)実行されます。

-examine

オプション

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel 属性

オプション

次のいずれかの属性を指定してロギング・レベルを設定します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

デフォルトのロギング・レベルはNOTIFICATIONです。

より多くの情報がロギングされるように-logLevel TRACE属性を設定することを検討してください。これは、失敗したアップグレードをトラブルシューティングするときに役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir 場所

オプション

アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。アップグレード・アシスタントによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

デフォルトの場所は次のとおりです。

(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

オプション

すべてのコマンドライン・オプションを表示します。

8.3.3 アップグレード・アシスタントでの準備状況チェックの実行

アップグレード・アシスタントの各画面を移動して、アップグレード前の準備状況チェックを完了します。

準備状況チェックは、サポートされるアップグレードの開始点にあるスキーマまたはコンポーネント構成に対してのみ実行されます。

準備状況チェックを完了する手順は次のとおりです。

1. 「ようこそ」画面で、準備状況チェックに関する情報を確認します。「次へ」をクリックします

2. 「準備状況チェック・タイプ」画面で、実行する準備状況チェックを選択します。

- 「個別に選択されたスキーマ」を使用すると、アップグレード前の確認のために個別のスキーマを選択できます。準備状況チェックにより、スキーマがアップグレードに対してサポートされているか、またはアップグレードが必要な箇所が報告されます。
このオプションを選択すると、画面名が「選択したスキーマ」になります。

- 「ドメイン・ベース」を使用すると、「ドメイン・ディレクトリ」フィールドで指定したドメイン内のアップグレードに適格なすべてのスキーマまたはコンポーネント構成を、アップグレード・アシスタントで検出および選択できます。
このオプションを選択すると、画面名がスキーマおよび構成になります。

アップグレード・アシスタントですべてのスキーマおよびコンポーネント構成を同時に確認する場合は、デフォルトの選択のままにし、それ以外の場合は特定のオプションを選択します。

- 「すべてのスキーマのチェックを含める」は、アップグレード可能なスキーマを含むすべてのコンポーネントを検出および確認します。

- 「すべての構成のチェックを含める」は、管理対象WebLogic Serverドメインのコンポーネント構成を確認します。

「次へ」をクリックします。

3. 「個別に選択されたスキーマ」を選択した場合、「使用可能なコンポーネント」画面で、準備状況チェックを実行する、アップグレード可能なスキーマを含むコンポーネントを選択します。

依存コンポーネントを持つコンポーネントを選択した場合、それらのコンポーネントは自動的に選択されます。たとえば、Oracle Platform Security Servicesを選択した場合、Oracle Audit Servicesは自動的に選択されます。

選択したコンポーネントに応じて、追加の画面が表示される場合があります。たとえば、次のような作業が必要になることがあります。

- ドメイン・ディレクトリを指定します。

- スキーマ資格証明を指定して、選択したスキーマに接続します: 「データベース・タイプ」、「DBAユーザー名」および「DBAパスワード」。次に「接続」をクリックします。

注意
Oracle Databaseがデフォルトのデータベース・タイプです。続行する前に、正しいデータベース・タイプを選択したことを確認してください。間違ったデータベース・タイプを選択したことがわかった場合、正しいタイプに変更するためにこの画面に戻らないでください。かわりに、アップグレード・アシスタントを閉じて、正しいデータベース・タイプを選択して準備状況チェックを再起動し、正しいデータベース・タイプがすべてのスキーマに適用されることを確認してください。

- 「スキーマ・ユーザー名」を選択して、「スキーマ・パスワード」を指定します。

「次へ」をクリックして準備状況チェックを開始します。

4. 「準備状況サマリー」画面で、選択に基づいて実行された準備状況チェックのサマリーを確認します。
後でアップグレード・アシスタントをレスポンス(またはサイレント)モードで再び実行するために選択内容をレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックして、レスポンス・ファイルの場所および名前を指定します。サイレント・アップグレードは、アップグレード・アシスタント・とまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。

詳細レポートを表示するには、「ログの表示」をクリックします。

「次へ」をクリックします。

5. 「準備状況チェック」画面で、準備状況チェックのステータスを確認します。 プロセスは数分かかる場合があります。
複数のコンポーネントを確認している場合、各コンポーネントの進行状況が固有の進捗バーに並行して表示されます。

準備状況チェックが完了したら「続行」をクリックします。

6. 「準備状況の終了」画面で、準備状況チェックの結果(「準備状況成功」または「準備状況失敗」)を確認します。

- 準備状況チェックが成功した場合、「準備状況レポートの表示」をクリックして完全なレポートを確認します。準備状況チェックが成功した場合でも、実際のアップグレードを実行する前に準備状況レポートを確認することをお薦めします。「検索」オプションを使用して、レポート内の特定の語または句を検索します。また、このレポートには、完成した準備状況チェック・レポート・ファイルが格納されている場所も示されます。

- 準備状況チェックで問題またはエラーが発生した場合、「ログの表示」をクリックしてログ・ファイルを確認し、問題を特定および修正してから、準備状況チェックを再開してください。ログ・ファイルは、設定したコマンドライン・オプションによって管理されます。

8.3.4 準備状況レポートの理解

ドメインの準備状況チェックを実行した後、レポートを確認して、アップグレードが成功するためにアクションを実行する必要があるかどうかを決定します。

準備状況レポート・ファイルの形式は次のとおりです。

readiness_timestamp.txt

timestampは、準備状況チェックが実行された日時を示します。

準備状況レポートには、次の情報が含まれています。

表8-3 準備状況レポートの要素

レポートの情報

説明

必要なアクション

全体的な準備状況ステータス: SUCCESSまたはFAILURE

レポートの上部には、アップグレードの準備状況チェックが成功したか、または1つ以上のエラーが発生して完了したかが示されます。

1つ以上のエラーが発生してレポートが完了した場合、アップグレードを試みる前に、FAILを検索し、障害の原因となった問題を修正します。準備状況チェックは、アップグレードする前に必要に応じて何度でも再実行できます。

タイムスタンプ

レポートが生成された日付と時刻。

必要なアクションはありません。

ログ・ファイルの場所

ORACLE_HOME/oracle_common/upgrade/logs

生成されたログ・ファイルのディレクトリの場所。

必要なアクションはありません。

準備状況レポートの場所

ORACLE_HOME/oracle_common/upgrade/logs

生成された準備状況レポートのディレクトリの場所。

必要なアクションはありません。

チェックされたコンポーネントの名前

チェックに含まれるコンポーネントの名前およびバージョンとステータス。

このリリースにアップグレードできないコンポーネント(SOAコア拡張など)がドメインに含まれる場合は、アップグレードを試みないでください。

チェックされたスキーマの名前

チェックに含まれるスキーマの名前および現在のバージョンとステータス。

スキーマのバージョン番号をレビューします。このリリースにアップグレードできないスキーマがドメインに含まれる場合は、アップグレードを試みないでください。

個別のオブジェクト・テスト・ステータス: FAIL

準備状況チェック・テストによって、特定のオブジェクトの問題が検出されました。

失敗した問題がすべて解決されるまではアップグレードしないでください。

個別のオブジェクト・テスト・ステータス: PASS

準備状況チェック・テストによって、特定のオブジェクトの問題が検出されませんでした。

準備状況チェック・レポートにPASSステータスのみが表示されている場合、環境をアップグレードできます。ただし、準備状況チェックでは、ハードウェアやアップグレード時の接続性などの外部環境に関する問題を検出することはできません。アップグレードの進捗を常に監視する必要があります。

<オブジェクト>の完了した準備状況チェック・ステータス: FAILURE

準備状況チェックによって、スキーマ、索引、データ型など、特定のオブジェクトについての解決する必要がある1つ以上のエラーが検出されました。

FAILED問題がすべて解決されるまではアップグレードしないでください。

<オブジェクト>の完了した準備状況チェック・ステータス: SUCCESS

準備状況チェック・テストによって問題が検出されませんでした。

必要なアクションはありません。

準備状況レポート・ファイルのサンプルを次に示します。使用対象のレポートにはこれらすべてのチェックが含まれる場合や含まれない場合があります。

Upgrade readiness check completed with one or more errors.

This readiness check report was created on Tue May 30 11:15:52 EDT 2016
Log file is located at: ORACLE_HOME/oracle_common/upgrade/logs/ua2016-05-30-11-14-06AM.log
Readiness Check Report File: ORACLE_HOME/oracle_common/upgrade/logs/readiness2016-05-30-11-15-52AM.txt

Starting readiness check of components.

Oracle Metadata Services
Starting readiness check of Oracle Metadata Services.
Schema User Name: DEV11_MDS
Database Type: Oracle Database
Database Connect String: machinename@yourcompany.com
VERSION Schema DEV11_MDS is currently at version 12.1.1.1.0.  Readiness checks will now be performed.
Starting schema test:  TEST_REQUIRED_TABLES  Test that the schema contains all the required tables
Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS
Starting schema test:  TEST_REQUIRED_PROCEDURES  Test that the schema contains all the required stored procedures
EXCEPTION     Schema is missing a required procedure: GETREPOSITORYFEATURES
Completed schema test: TEST_REQUIRED_PROCEDURES --> Test that the schema contains all the required stored procedures +++ FAIL
Starting schema test:  TEST_REQUIRED_VIEWS  Test that the schema contains all the required database views
Completed schema test: TEST_REQUIRED_VIEWS --> Test that the schema contains all the required database views +++ PASS
Starting index test for table MDS_ATTRIBUTES:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_ATTRIBUTES: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting index test for table MDS_COMPONENTS:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_TXN_LOCKS: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting schema test:  TEST_REQUIRED_TRIGGERS  Test that the schema has all the required triggers
Completed schema test: TEST_REQUIRED_TRIGGERS --> Test that the schema has all the required triggers +++ PASS
Starting schema test:  TEST_MISSING_COLUMNS  Test that tables and views are not missing any required columns
Completed schema test: TEST_MISSING_COLUMNS --> Test that tables and views are not missing any required columns +++ PASS
Starting schema test:  TEST_UNEXPECTED_TABLES  Test that the schema does not contain any unexpected tables
Completed schema test: TEST_UNEXPECTED_TABLES --> Test that the schema does not contain any unexpected tables +++ PASS
Starting schema test:  TEST_UNEXPECTED_PROCEDURES  Test that the schema does not contain any unexpected stored procedures
Completed schema test: TEST_UNEXPECTED_PROCEDURES --> Test that the schema does not contain any unexpected stored procedures +++ PASS
Starting schema test:  TEST_UNEXPECTED_VIEWS  Test that the schema does not contain any unexpected views
Completed schema test: TEST_UNEXPECTED_VIEWS --> Test that the schema does not contain any unexpected views +++ PASS
Starting index test for table MDS_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Completed index test for table MDS_ATTRIBUTES: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Completed index test for table MDS_LABELS: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Starting index test for table MDS_LARGE_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Starting schema test:  TEST_UNEXPECTED_TRIGGERS  Test that the schema does not contain any unexpected triggers
Completed schema test: TEST_UNEXPECTED_TRIGGERS --> Test that the schema does not contain any unexpected triggers +++ PASS
Starting schema test:  TEST_UNEXPECTED_COLUMNS  Test that tables and views do not contain any unexpected columns
Completed schema test: TEST_UNEXPECTED_COLUMNS --> Test that tables and views do not contain any unexpected columns +++ PASS
Starting datatype test for table MDS_ATTRIBUTES:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table MDS_ATTRIBUTES: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table MDS_COMPONENTS:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Starting permissions test:  TEST_DBA_TABLE_GRANTS  Test that DBA user has privilege to view all user tables
Completed permissions test: TEST_DBA_TABLE_GRANTS --> Test that DBA user has privilege to view all user tables +++ PASS
Starting schema test:  TEST_ENOUGH_TABLESPACE  Test that the schema tablespaces automatically extend if full
Completed schema test: TEST_ENOUGH_TABLESPACE --> Test that the schema tablespaces automatically extend if full +++ PASS
Starting schema test:  TEST_USER_TABLESPACE_QUOTA  Test that tablespace quota for this user is sufficient to perform the upgrade
Completed schema test: TEST_USER_TABLESPACE_QUOTA --> Test that tablespace quota for this user is sufficient to perform the upgrade +++ PASS
Starting schema test:  TEST_ONLINE_TABLESPACE  Test that schema tablespaces are online
Completed schema test: TEST_ONLINE_TABLESPACE --> Test that schema tablespaces are online +++ PASS
Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
INFO   Database product version: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
Finished readiness check of Oracle Metadata Services with status: FAILURE.

12.1.3.0リリースのOracle Fusion Middleware IAUスキーマを実行しており、それらのスキーマが11gリリース(11.1.1.7以上)または12c (12.1.2.0)からアップグレードされた場合、準備状況チェックは次のエラーで失敗することがあります。

Starting index test for table IAU_COMMON:  TEST_REQUIRED_INDEXES --> Test
that the table contains all the required indexes
INFO Audit schema index DYN_EVENT_CATEGORY_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_EVENT_TYPE_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_TENANT_INDEX in table IAU_COMMON is missing
the required columns or index itself is missing. This maybe caused by a known
issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_USER_INDEX in table IAU_COMMON is missing
the required columns or index itself is missing. This maybe caused by a known
issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_COMPONENT_TYPE_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_USER_TENANT_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
Completed index test for table IAU_COMMON: TEST_REQUIRED_INDEXES --> Test
that the table contains all the required indexes +++ FAIL

注意:
準備状況レポートの索引欠落エラーは無視できます。これは既知の問題です。該当の欠落している索引は、スキーマ・アップグレード操作中に追加されます。アップグレードするスキーマがRCUを使用して12cで作成された場合、このエラーは発生しません。

8.4 サーバーとプロセスの停止

アップグレード・アシスタントを実行してスキーマおよび構成をアップグレードする前に、管理サーバーや管理対象サーバーを含め、すべてのプロセスとサーバーを停止する必要があります。

Oracle Fusion Middleware環境は、Oracle WebLogic Serverドメイン、管理サーバー、複数の管理対象サーバー、Javaコンポーネント、アイデンティティ管理コンポーネントなどのシステム・コンポーネント、およびメタデータのリポジトリに使用されるデータベースで構成できます。これらのコンポーネントは相互に依存する場合があるため、正しい順序で停止する必要があります。

注意:
この項の手順では、WLSTコマンドライン・ユーティリティまたはスクリプトを使用してサーバーおよびプロセスを停止する方法について説明します。Oracle Fusion Middleware ControlおよびOracle WebLogic Server管理コンソールを使用することもできます。Oracle Fusion Middlewareの管理の管理サーバー、管理対象サーバーおよびノード・マネージャの起動および停止を参照してください。

Fusion Middleware環境を停止するには、次の手順に従います。

手順1: システム・コンポーネントの停止

Oracle HTTP Serverなどのシステム・コンポーネントを停止するには、stopComponentスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

システム・コンポーネントは任意の順序で停止できます。

手順2: 管理対象サーバーの停止

WebLogic Server管理対象サーバーを停止するには、stopManagedWebLogicスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url

- (Windows) DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url

プロンプトが表示されたらユーザー名とパスワードを入力します。

手順3: Oracle Identity Managementコンポーネントの停止環境を構成しているOracle Internet DirectoryなどのOracle Identity Managementコンポーネントがあれば、それをすべて停止します。

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

ステップ4: 管理サーバーの停止

管理サーバーを停止する場合、管理サーバーで稼働しているWebLogic Server管理コンソールやFusion Middleware Controlなどのプロセスも停止します。

管理サーバーを停止するには、stopWebLogicスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/stopWebLogic.sh

- (Windows) DOMAIN_HOME\bin\stopWebLogic.cmd

プロンプトが表示されたら、管理サーバーのユーザー名とパスワードおよびURLを入力します。

注意:
リポジトリ用に外部のパスワード記憶域が設定されている場合は、アップグレード中に作業リポジトリのパスワードを取得できるように、資格証明ストアをホストしているサーバーが稼働している必要があります。詳細は、Oracle Fusion Middleware Oracle Data Integratorの管理の外部パスワード記憶域の設定を参照してください。

手順5: ノード・マネージャの停止

ノード・マネージャを停止するには、それが実行されているコマンド・シェルを閉じます。

またはnodemanager.propertiesのQuitEnabledの属性をtrueに設定した後(デフォルトはfalseです)、WLSTを使用して、ノード・マネージャに接続して停止できます。詳細は、Oracle Fusion Middleware WebLogic Server WLSTコマンド・リファレンスのstopNodeManagerを参照してください。

8.5 製品スキーマのアップグレード

サーバーおよびプロセスを停止した後、アップグレード・アシスタントを使用して、サポートされている製品スキーマを現在のリリースのOracle Fusion Middlewareにアップグレードします。

アップグレード・アシスタントを使用すると、個別に選択したスキーマまたはドメインに関連付けられているすべてのスキーマをアップグレードできます。選択したオプションによって、表示されるアップグレード・アシスタントの画面は異なります。

- アップグレード・アシスタントの起動
アップグレード・アシスタントを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。一度に1つのドメインのアップグレードを完了して、アップグレード・アシスタントを非SYSDBAユーザーとして実行することをお薦めします。

- アップグレード・アシスタントを使用した製品スキーマのアップグレード
アップグレード・アシスタントの各画面を移動して、製品スキーマをアップグレードします。

- スキーマ・アップグレードの確認
すべてのアップグレード手順の完了後、schema_version_registryのスキーマ・バージョンが正しく更新されたことを確認して、アップグレードが成功したことを確認します。

8.5.1 Upgrade Assistantの起動

アップグレード・アシスタントを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。一度に1つのドメインのアップグレードを完了して、アップグレード・アシスタントを非SYSDBAユーザーとして実行することをお薦めします。

Upgrade Assistantを起動するには、次の手順に従います。

1. oracle_common/upgrade/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. アップグレード・アシスタントを起動します。

- (UNIX) ./ua

- (Windows) ua.bat

ロギング・パラメータなど、コマンドラインで指定できるその他のパラメータの詳細は、次を参照してください。

- アップグレード・アシスタントのコマンドライン・パラメータ

8.5.1.1 アップグレード・アシスタントのコマンドライン・パラメータ

コマンドラインからアップグレード・アシスタントを起動するとき、追加パラメータを指定できます。

表8-4 アップグレード・アシスタントのコマンドライン・パラメータ

パラメータ

必須またはオプション

説明

-readiness

準備状況チェックに必須
注意: 準備状況チェックはスタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では実行できません。

実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。

スキーマおよび構成がチェックされます。

-examineパラメータを指定した場合、このパラメータを使用しないでください。

-threads

オプション

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックに必須

アップグレード・アシスタントがGUIモードで実行されたときに入力されたデータから生成されたレスポンス・ファイルに保存された入力を使用して、アップグレード・アシスタントを実行します。このパラメータを使用すると、アップグレード・アシスタントがサイレント・モードで(アップグレード・アシスタント画面を表示せずに)実行されます。

-examine

オプション

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel 属性

オプション

次のいずれかの属性を指定してロギング・レベルを設定します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

デフォルトのロギング・レベルはNOTIFICATIONです。

より多くの情報がロギングされるように-logLevel TRACE属性を設定することを検討してください。これは、失敗したアップグレードをトラブルシューティングするときに役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir 場所

オプション

アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。アップグレード・アシスタントによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

デフォルトの場所は次のとおりです。

(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

オプション

すべてのコマンドライン・オプションを表示します。

8.5.2 アップグレード・アシスタントを使用した製品スキーマのアップグレード

アップグレード・アシスタントの各画面を移動して、製品スキーマをアップグレードします。

注意

- 外部認証を使用している場合は、外部認証が内部認証に変更されていることを確認してください。

- エディションベースの再定義(EBR)ユーザーのみ: エディション・ベースの再定義(EBR)に対応したスキーマをアップグレードする前に、データベース・サーバーに接続して、12cのデータベース・サーバーにエディションを作成する必要があります。12cの新しいエディションは、既存の12cエディションの子である必要があります。再定義のためのサーバーでのエディション作成の詳細は、エディションベースの再定義のためのサーバー上でのエディションの作成を参照してください。

アップグレード・アシスタントで製品スキーマをアップグレードする手順は次のとおりです。

1. 「ようこそ」画面で、アップグレード・アシスタントの概要と、重要なアップグレード前のタスクに関する情報を確認します。「次へ」をクリックします

注意:
アップグレード・アシスタント画面の詳細は、画面で「ヘルプ」をクリックしてください。

2. 「選択したスキーマ」画面で、「個別に選択されたスキーマ」を選択します。

注意:
12c (12.2.1.2)コンポーネントをサポートするために使用されるスキーマのみをアップグレードしてください。Oracle Fusion Middleware 12c (12.2.1.2)に含まれていないコンポーネントをサポートするために現在使用されているスキーマはアップグレードしないでください。

「次へ」をクリックします。

3. 「使用可能なコンポーネント」画面で、マスターおよび作業リポジトリ・スキーマをアップグレードするために「Oracle Data Integrator」を選択します。

4. 「前提条件」画面ですべてのチェック・ボックスを選択して、前提条件を満たしていることを確認します。「次へ」をクリックします

注意:
アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。

5. ODIスキーマ画面で、アップグレードする各スキーマのデータベース接続の詳細を指定します。

- 「データベース・タイプ」ドロップダウン・メニューからデータベース・タイプを選択します。

- データベース接続の詳細を入力して、「接続」をクリックします。

- 「スキーマ・ユーザー名」ドロップダウン・メニューからアップグレードするスキーマを選択し、スキーマのパスワードを入力します。アップグレードするスキーマに対して正しいスキーマ接頭辞を使用してください。

6. 「ODIオプション」画面で、すべてのオプションを選択します。

表8-5 ODIのオプション

オプション

説明

ナレッジ・モジュールを必須更新で置換

これを選択すると、標準ナレッジ・モジュールが最新バージョンに置き換えられます。Oracleによりインストールされたナレッジ・モジュールに対するカスタマイズ内容は上書きされます。ただし、インストールされたナレッジ・モジュールをコピーしてからそのナレッジ・モジュールをカスタマイズした場合、カスタマイズ内容は失われません。

トポロジおよびセキュリティ・メタデータのアップグレード

これを選択すると、テクノロジ、データ型、セキュリティ・プロファイルなどのトポロジおよびセキュリティ・アーティファクトが最新バージョンに置き換えられます。インストールされたオブジェクトのカスタマイズ内容は上書きされます。オブジェクトをコピーしてからカスタマイズした場合、カスタマイズ内容は失われません。

高度なアップグレード・オプションの詳細は、「高度なアップグレード・オプション」を参照してください。

7. 「ODIスーパーバイザ」画面に、アップグレードするODIリポジトリのスーパーバイザ・アカウント資格証明を入力します。

インストールされているスーパーバイザ・アカウントはSUPERVISORです。ODIのマスター・リポジトリおよび作業リポジトリの作成時にリポジトリ作成ユーティリティ(RCU)で求められたときに指定した、正しいスーパーバイザ・アカウント名およびパスワードについては、ODI管理者に確認してください。

注意:
「ドメインで使用されるすべてのスキーマ」が選択されている場合、ODIのスーパーバイザ資格証明はドメインに含まれていないため、最初のインスタンスにあらかじめ移入されません。複数のODIスキーマがある場合、アップグレード・アシスタントは最初の資格証明のセットを使用してユーザー・エントリに移入します。

8. 「調査」画面で、各スキーマを調査した際のアップグレード・アシスタントのステータスを確認し、スキーマのアップグレード準備が整っていることを確認します。ステータスが「調査が終了しました。」になっている場合は、「次へ」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、共通するアップグレード・エラーの解決に関する情報をOracle Fusion Middleware Upgrade Assistantによるアップグレードのアップグレードのトラブルシューティングで参照します。

注意:

- 調査フェーズの間に、アップグレードを続行せずに検出された問題を解決した場合は、バックアップからリストアすることなしに、アップグレード・アシスタントを再起動できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックして続行した場合は、アップグレード・アシスタントを再起動する前に、アップグレード前の環境をバックアップからリストアする必要があります。

- 調査プロセスを取り消してもスキーマまたは構成データに影響はありませんが、将来のアップグレード・セッションでは、Upgrade Assistantが収集した情報を再収集する必要があります。

9. 「アップグレード・サマリー」画面で、スキーマ・アップグレードに選択したオプションのサマリーを確認します。
正しいソース・バージョンとターゲット・バージョンが、アップグレード対象の各スキーマにリストされていることを確認します。

後でアップグレード・アシスタントをレスポンス(またはサイレント)モードで再び実行するためにこれらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックして、レスポンス・ファイルの場所および名前を指定します。サイレント・アップグレードは、アップグレード・アシスタント・とまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。

10. 「アップグレードの進行状況」画面でアップグレードのステータスを監視します。

注意:
アップグレード・アシスタントにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。これを行うと、環境が不安定になる可能性があります。

正しくアップグレードされていないスキーマがある場合は、アップグレード・アシスタントのログ・ファイルで情報を確認します。

注意:
この画面の進捗バーには、現在のアップグレード手順の進行状況が表示されます。アップグレードの残り時間を示すものではありません。

「次へ」をクリックします。

11. アップグレードが成功した場合、「アップグレード成功」画面で「閉じる」をクリックし、アップグレードを完了してウィザードを閉じます。

アップグレードが失敗した場合、「アップグレード失敗」画面で「ログの表示」をクリックし、エラーを表示してトラブルシューティングします。ログはORACLE_HOME/oracle_common/upgrade/logsにあります。

注意:
アップグレードに失敗した場合、アップグレード前の環境をバックアップからリストアし、問題を修正して、アップグレード・アシスタントを再起動する必要があります。

8.5.3 スキーマのアップグレードの確認

すべてのアップグレード手順の完了後、schema_version_registryのスキーマ・バージョンが正しく更新されたことを確認して、アップグレードが成功したことを確認します。

Oracle Databaseを使用する場合、Oracle DBAを持つユーザーとしてデータベースに接続し、SQL*Plusから次を実行して現行のバージョン番号を取得します。

SET LINE 120
COLUMN MRC_NAME FORMAT A14
COLUMN COMP_ID FORMAT A20
COLUMN VERSION FORMAT A12
COLUMN STATUS FORMAT A9
COLUMN UPGRADED FORMAT A8
SELECT MRC_NAME, COMP_ID, OWNER, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY ORDER BY MRC_NAME, COMP_ID ;

問合せ結果:

- VERSION列の数値が、そのスキーマの最新のバージョン番号に一致していることを確認します。たとえば、スキーマ・バージョン番号が12.2.1.2.0であることを確認します。ただし、すべてのスキーマ・バージョンが更新されるわけではないことに注意してください。一部のスキーマではこのリリースへのアップグレードが必要なく、アップグレード前のバージョン番号が保持されます。

- STATUSフィールドは、スキーマのパッチ適用操作中は「UPGRADING」または「UPGRADED」に、操作が完了すると「VALID」になります。

- ステータスが「INVALID」と表示された場合は、ステータスの更新が失敗しています。ログ・ファイルを調べて、失敗した理由を判定する必要があります。

- IAU_APPENDおよびIAU_VIEWERによって所有されるシノニム・オブジェクトは、INVALIDとして表示されますが、失敗を示すものではありません。
それらは、シノニムの作成後にターゲット・オブジェクトが変更されるため無効になります。シノニム・オブジェクトはアクセスされると有効になります。これらのINVALIDオブジェクトは無視しても問題ありません。

8.6 ドメインの再構成

再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.2)に再構成します。

WebLogic Serverドメインを再構成する場合は、ドメイン内のアプリケーションに応じて次の項目が自動的に更新されます。

- WebLogic Serverコア・インフラストラクチャ

- ドメイン・バージョン

注意:

ドメインの再構成を開始する前に、次の制限に注意してください。

- 再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。

- アップグレード・プロセス中に非動的クラスタ・ドメインを動的クラスタ・ドメインに変換することはサポートされていません。
動的クラスタ機能は再構成ウィザードの実行中は使用できますが、非動的クラスタをアップグレードしてから動的クラスタを追加することのみがサポートされています。アップグレード・プロセス中に動的クラスタを追加することはできません。

具体的には、ドメインを再構成すると、次のようになります。

- ドメインのconfig.xmlファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンに更新されます。

- すべてのインストール済Oracle製品の再構成テンプレートは、自動的に選択されてドメインに適用されます。これらのテンプレートは、WebLogicドメインが現在のWebLogic Serverバージョンと互換性を持つために必要な再構成タスクを定義します。

- 起動スクリプトが更新されます。
変更した起動スクリプトを保持する場合、再構成ウィザードを起動する前にそのスクリプトをバックアップしてください。

注意:
ドメインの再構成プロセスを開始すると、元に戻すことはできません。再構成ウィザードを実行する前に、アップグレード前チェックリストで示されているようにドメインをバックアップしたことを確認してください。再構成ウィザードの実行中にエラーまたは他の割込みが発生した場合、バックアップ場所から元のドメイン・ディレクトリにファイルとディレクトリをコピーすることによって、ドメインをリストアする必要があります。これは、再構成前にドメインを確実に元の状態に戻す唯一の方法です。

再構成ウィザードを使用して既存のドメインを再構成する手順に従います。ドメインの再構成に関する一般情報は、Oracle Fusion Middleware Oracle WebLogic ServerのアップグレードのWebLogicドメインの再構成を参照してください。

- ドメインのバックアップ

- 再構成ウィザードの起動

- 再構成ウィザードを使用したドメインの再構成

8.6.1 ドメインのバックアップ

再構成ウィザードを実行する前に、ドメイン・ディレクトリのバックアップ・コピーを作成します。

ドメイン・ディレクトリのバックアップを作成する手順は次のとおりです。

1. コンテンツを保持するには、ソース・ドメインを別の場所にコピーします。
たとえば、C:\domains\mydomainをC:\domains\mydomain_backupにコピーします。

2. 各リモート管理対象サーバーのドメインを更新する前に、各リモート・マシンのドメイン・ディレクトリのバックアップ・コピーを作成します。

3. ドメインのバックアップしたバージョンが完全であることを確認します。

ドメインの再構成がなんらかの理由で失敗した場合は、再構成を実行する前に、すべてのファイルおよびディレクトリをバックアップ・ディレクトリから元のドメイン・ディレクトリにコピーしてドメインを完全に元の状態に戻す必要があります。

8.6.2 再構成ウィザードの起動

再構成ウィザードをグラフィカル・モードで起動する手順は次のとおりです。

1. ドメインが存在するシステムにサインインします。

2. コマンド・シェル(UNIXオペレーティング・システムの場合)またはコマンド・プロンプト・ウィンドウ(Windowsオペレーティング・システムの場合)を開きます。

3. エディション・ベースのデータベース・ユーザーのみ: スキーマがEBRデータベースを使用して構成されている場合、再構成ウィザードを実行する前に、手動でデフォルトのエディション名を設定する必要があります。
次のSQLコマンドを実行して、デフォルト・エディションを設定します。
ALTER DATABASE DEFAULT EDITION = edition_name;

ここで、edition_nameは、子エディション名です。

4. oracle_common/common/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/common/bin

- (Windows) ORACLE_HOME\oracle_common\commom\bin

5. 再構成ウィザードを次のロギング・オプションとともに起動します。

- (UNIX) ./reconfig.sh -log=log_file -log_priority=ALL

- (Windows) reconfig.cmd -log=log_file -log_priority=ALL

log_fileは、ドメイン再構成セッション用に作成するログ・ファイルの絶対パスです。これは、再構成処理をトラブルシューティングする必要がある場合に役立つことがあります。

パラメータ-log_priority=ALLは、ログを詳細モードで出力します。

注意:

このコマンドを実行すると、デフォルトのキャッシュ・ディレクトリが無効であることを示す次のエラー・メッセージが表示される場合があります。

*sys-package-mgr*: can't create package cache dir

環境変数CONFIG_JVM_ARGSを設定することでキャッシュ・ディレクトリを変更できます。次に例を示します。

CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

8.6.3 再構成ウィザードを使用したドメインの再構成

アップグレード・アシスタントを実行する前に、再構成ウィザードの各画面を移動して既存のドメインを再構成します。

注意:
ソースがクラスタ環境である場合は、再構成ウィザードをプライマリ・ノードでのみ実行します。packおよびunpackユーティリティを使用して、ドメイン内の他のクラスタ・メンバーに変更を適用します。

再構成ウィザードを使用してドメインを再構成する手順は次のとおりです。

1. 「ドメインの選択」画面で、アップグレードするドメインの場所を指定するか、「参照」をクリックしてナビゲートし、ドメインのディレクトリを選択します。「次へ」をクリックします。

2. 「再構成セットアップの進行状況」画面で、設定プロセスの進行状況を表示します。完了したら、「次へ」をクリックします。
このプロセスでは次の処理が行われます。

- Fusion Middleware製品を含む、インストール済製品の再構成テンプレートが自動的に適用されます。これにより、config.xml、config-groups.xml、security.xmlなどの様々なドメイン構成ファイルが更新されます。

- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

- ドメイン・アップグレードが検証されます。

3. 「ドメイン・モードおよびJDK」画面で、ドメインで使用するJDKを選択するか、「参照」をクリックして、使用するJDKにナビゲートします。12c (12.2.1.2)に対してサポートされているJDKバージョンは1.8.0_101以上です。「次へ」をクリックします。

注意:
このステージでは、「ドメイン・モード」を変更することはできません。

特定のプラットフォームでサポートされているJDKのリストは、Oracle Fusion Middlewareでサポートされているシステム構成の説明を参照してください。

4. 「データベース構成タイプ」画面で、「RCUデータ」を選択してサービス表(_STB)スキーマに接続します。
RCUサービス表(_STB)スキーマ資格証明を使用してデータベース接続の詳細を入力するか、「RCU構成の取得」をクリックします。

再構成ウィザードは、この接続を使用して、ドメインのコンポーネントに必要なデータソースを自動的に構成します。
注意: 既存の11gデータ・ソースの場合、再構成では既存の値が保持されます。スキーマがRCUによって12c用に作成された新しいデータ・ソースの場合、デフォルトの接続データは_STBスキーマから取得されます。特定のスキーマの接続データが_STBスキーマにない場合は、デフォルトの接続データが使用されます。

チェックが成功した場合は、「次へ」をクリックします。チェックが失敗した場合は、接続の正しい詳細を再入力し、再試行します。

5. 「JDBCコンポーネント・スキーマ」画面で、各コンポーネント・スキーマのDBMS/サービスおよびホスト名が正しいことを確認し、「次へ」をクリックします。

6. 「JDBCコンポーネント・スキーマ・テスト」画面で、すべてのコンポーネント・スキーマを選択して「選択された接続のテスト」をクリックし、各スキーマの接続をテストします。テストの結果は、「ステータス」列に表示されます。
チェックが完了したら、「次へ」をクリックします。

7. 「拡張構成」画面で、拡張構成を実行するすべてのカテゴリを選択できます。選択したカテゴリごとに、詳細構成を行うことができる適切な構成画面が表示されます。

注意:
「拡張構成」画面にリストされるカテゴリは、ドメインに選択したテンプレートに定義されているリソースによって異なります。

このアップグレードではオプションを選択せずに、「次へ」をクリックします。

8. 「構成のサマリー」画面で、ドメインの詳細な構成設定を確認してから続行します。
「表示」ドロップダウン・リストからフィルタ・オプションを選択すると、右側のパネルに表示される項目を制限できます。

構成を変更するには、「戻る」をクリックして適切な画面に戻ります。ドメインを再構成するには、「再構成」をクリックします。

注意:
ドメインを再構成しても、その場所は変更されません。

9. 「再構成の進行状況」画面には、再構成プロセスの進行状況が表示されます。
このプロセスでは次の処理が行われます。

- ドメイン情報が抽出、保存および更新されます。

- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

進捗バーが100%になったら、「次へ」をクリックします。

10. 「構成の終了」画面には、再構成プロセスが正常に完了したか失敗したかが示されます。管理サーバーURL(リスニング・ポートを含む)とともに再構成されたドメインの場所も表示します。再構成が成功した場合は、「Oracle Weblogic Serverの再構成に成功しました」と表示されます。
再構成プロセスが正常に完了しなかった場合は、その理由を示すエラー・メッセージが表示されます。問題を解決するための適切な措置を講じます。問題を解決できない場合は、My Oracle Supportに連絡してください。

以後の操作のためにドメインの場所と管理サーバーURLをメモします。

8.7 ドメイン・コンポーネント構成のアップグレード

ドメインの再構成後、アップグレード・アシスタントを使用して、ドメイン内のドメイン・コンポーネント構成を更新済ドメイン構成に一致するようにアップグレードします。

- アップグレード・アシスタントの起動
アップグレード・アシスタントを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。一度に1つのドメインのアップグレードを完了して、アップグレード・アシスタントを非SYSDBAユーザーとして実行することをお薦めします。

- アップグレード・アシスタントを使用したドメイン・コンポーネント構成のアップグレード
アップグレード・アシスタントの各画面を移動して、WebLogicドメイン内のコンポーネント構成をアップグレードします。

8.7.1 Upgrade Assistantの起動

アップグレード・アシスタントを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。一度に1つのドメインのアップグレードを完了して、アップグレード・アシスタントを非SYSDBAユーザーとして実行することをお薦めします。

Upgrade Assistantを起動するには、次の手順に従います。

1. oracle_common/upgrade/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. アップグレード・アシスタントを起動します。

- (UNIX) ./ua

- (Windows) ua.bat

ロギング・パラメータなど、コマンドラインで指定できるその他のパラメータの詳細は、次を参照してください。

- アップグレード・アシスタントのコマンドライン・パラメータ

8.7.1.1 アップグレード・アシスタントのコマンドライン・パラメータ

コマンドラインからアップグレード・アシスタントを起動するとき、追加パラメータを指定できます。

表8-6 アップグレード・アシスタントのコマンドライン・パラメータ

パラメータ

必須またはオプション

説明

-readiness

準備状況チェックに必須
注意: 準備状況チェックはスタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では実行できません。

実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。

スキーマおよび構成がチェックされます。

-examineパラメータを指定した場合、このパラメータを使用しないでください。

-threads

オプション

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックに必須

アップグレード・アシスタントがGUIモードで実行されたときに入力されたデータから生成されたレスポンス・ファイルに保存された入力を使用して、アップグレード・アシスタントを実行します。このパラメータを使用すると、アップグレード・アシスタントがサイレント・モードで(アップグレード・アシスタント画面を表示せずに)実行されます。

-examine

オプション

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel 属性

オプション

次のいずれかの属性を指定してロギング・レベルを設定します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

デフォルトのロギング・レベルはNOTIFICATIONです。

より多くの情報がロギングされるように-logLevel TRACE属性を設定することを検討してください。これは、失敗したアップグレードをトラブルシューティングするときに役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir 場所

オプション

アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。アップグレード・アシスタントによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

デフォルトの場所は次のとおりです。

(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

オプション

すべてのコマンドライン・オプションを表示します。

8.7.2 アップグレード・アシスタントを使用したドメイン・コンポーネント構成のアップグレード

アップグレード・アシスタントの各画面を移動して、WebLogicドメイン内のコンポーネント構成をアップグレードします。

再構成ウィザードを実行してWebLogicドメインを12c (12.2.1.2)に再構成した後、アップグレード・アシスタントを実行して、ドメイン・コンポーネント構成を更新済ドメイン構成に一致するようにアップグレードする必要があります。

アップグレード・アシスタントを使用してドメイン・コンポーネント構成をアップグレードする手順は次のとおりです。

1. 「ようこそ」画面で、アップグレード・アシスタントの概要と、重要なアップグレード前のタスクに関する情報を確認します。「次へ」をクリックします

注意:
アップグレード・アシスタント画面の詳細は、画面で「ヘルプ」をクリックしてください。

2. 次の画面で次のようにします。

- 「ドメインによって使用されるすべての構成」を選択します。画面名は「WebLogicコンポーネント」になります。

- 「ドメイン・ディレクトリ」フィールドにWebLogicドメイン・ディレクトリ・パスを入力します。

「次へ」をクリックします。

3. 「コンポーネント・リスト」画面で、構成をアップグレードするすべてのコンポーネントがリストに含まれていることを確認して「次へ」をクリックします。
アップグレード対象のコンポーネントが表示されていない場合は、「戻る」をクリックして前の画面に戻り、別のドメインを指定します。

4. 「前提条件」画面ですべてのチェック・ボックスを選択して、前提条件を満たしていることを確認します。「次へ」をクリックします

注意:
アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。

5. 「調査」画面で、各コンポーネントを調査した際のアップグレード・アシスタントのステータスを確認し、コンポーネント構成のアップグレード準備が整っていることを確認します。ステータスが「調査が終了しました。」になっている場合は、「次へ」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、共通するアップグレード・エラーの解決に関する情報をOracle Fusion Middleware Upgrade Assistantによるアップグレードのアップグレードのトラブルシューティングで参照します。

注意:

- 調査フェーズの間に、アップグレードを続行せずに検出された問題を解決した場合は、バックアップからリストアすることなしに、アップグレード・アシスタントを再起動できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックして続行した場合は、アップグレード・アシスタントを再起動する前に、アップグレード前の環境をバックアップからリストアする必要があります。

- 調査プロセスを取り消しても構成データに影響はありませんが、将来のアップグレード・セッションでは、アップグレード・アシスタントが収集した情報を再収集する必要があります。

6. 「アップグレード・サマリー」画面で、コンポーネント構成アップグレードに選択したオプションのサマリーを確認します。
レスポンス・ファイルには、入力したすべての情報が収集して格納され、後でサイレント・アップグレードを実行するために使用できます。サイレント・アップグレードは、アップグレード・アシスタント・とまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。

7. 「アップグレードの進行状況」画面でアップグレードのステータスを監視します。

注意:
アップグレード・アシスタントにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。これを行うと、環境が不安定になる可能性があります。

正しくアップグレードされていないコンポーネントがある場合は、Upgrade Assistantのログ・ファイルで情報を確認します。

注意:
この画面の進捗バーには、現在のアップグレード手順の進行状況が表示されます。アップグレードの残り時間を示すものではありません。

「次へ」をクリックします。

8. アップグレードが成功した場合、「アップグレード成功」画面で「閉じる」をクリックし、アップグレードを完了してウィザードを閉じます。新規インストールでコンポーネントを機能させるために手動で実行する必要のあるタスクが、アップグレード後のアクションのウィンドウに表示されます。このウィンドウは、コンポーネントにアップグレード後の手順がある場合にのみ表示されます。

アップグレードが失敗した場合、「アップグレード失敗」画面で「ログの表示」をクリックし、エラーを表示してトラブルシューティングします。ログはORACLE_HOME/oracle_common/upgrade/logsにあります。

注意:
アップグレードに失敗した場合、アップグレード前の環境をバックアップからリストアし、問題を修正して、アップグレード・アシスタントを再起動する必要があります。

8.8 サーバーおよびプロセスの起動

アップグレードが成功した後、管理サーバーおよび管理対象サーバーを含め、すべてのプロセスおよびサーバーを再起動します。

これらのコンポーネントは相互に依存する場合があるため、正しい順序で起動する必要があります。

注意:
この項の手順では、WLSTコマンドラインまたはスクリプトを使用してサーバーおよびプロセスを起動する方法について説明します。Oracle Fusion Middleware ControlおよびOracle WebLogic Server管理コンソールを使用することもできます。Oracle Fusion Middlewareの管理の管理サーバー、管理対象サーバーおよびノード・マネージャの起動および停止を参照してください。

Fusion Middleware環境を起動するには、次の手順に従います。

ステップ1: 管理サーバーの起動

管理サーバーを起動する場合、管理サーバーで稼働しているWebLogic Server管理コンソールやFusion Middleware Controlなどのプロセスも起動します。

管理サーバーを起動するには、startWebLogicスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/startWebLogic.sh

- (Windows) DOMAIN_HOME\bin\startWebLogic.cmd

プロンプトが表示されたら、管理サーバーのユーザー名とパスワードおよびURLを入力します。

手順2: ノード・マネージャの起動

ノード・マネージャを起動するには、startNodeManagerスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/startNodeManager.sh

- (Windows) DOMAIN_HOME\bin\startNodeManager.cmd

手順3: Oracle Identity Managementコンポーネントの起動環境を構成しているOracle Internet DirectoryなどのOracle Identity Managementコンポーネントがあれば、それをすべて起動します。

- (UNIX) DOMAIN_HOME/bin/startComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\startComponent.cmd component_name

手順4: 管理対象サーバーの起動

WebLogic Server管理対象サーバーを起動するには、startManagedWebLogicスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

- (Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url

プロンプトが表示されたらユーザー名とパスワードを入力します。

注意:
通常は、管理対象サーバーの起動により、それにデプロイされているアプリケーションが開始されます。したがって、管理対象サーバーの起動後にアプリケーションを手動で開始する必要はありません。

手順5: システム・コンポーネントの起動

Oracle HTTP Serverなどのシステム・コンポーネントを起動するには、startComponentスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/startComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\startComponent.cmd component_name

システム・コンポーネントは任意の順序で起動できます。

第IV部 トラブルシューティングおよび高度な構成

Oracle Fusion Middleware Oracle Data Integratorのアップグレードのこの部では、アップグレードの問題のトラブルシューティングおよび高度なアップグレード構成用のオプションに関する情報を提供します。

- アップグレードのトラブルシューティング
アップグレード・プロセスが失敗した場合は、アップグレード・アシスタントを閉じて問題を修正し、アップグレード・アシスタントを再起動する必要があります。

- 高度なアップグレード・オプション
Oracle Data Integratorをアップグレードするための、追加のオプションを設定できます。

9 アップグレードのトラブルシューティング

アップグレード・プロセスが失敗した場合は、アップグレード・アシスタントを閉じて問題を修正し、アップグレード・アシスタントを再起動する必要があります。

アップグレード・プロセスの起動後にアップグレード・プロセスが失敗した場合は、クローニングされたリポジトリを削除して、根本的な問題を修正してから、新たにクローニングしたリポジトリで起動する必要があります。失敗したアップグレード・プロセスを再起動することはできません。

トラブルシューティングの詳細は、Oracle Fusion Middleware Upgrade Assistantによるアップグレードのアップグレードのトラブルシューティングを参照してください。

アップグレード・ログ・エラーのトラブルシューティング

アップグレード・アシスタント・ログ・ファイルに<#>, 11g interfaces are converted with errorsが含まれている場合は、アップグレード・アシスタント・ログでインタフェース名およびIDをチェックし、11gリポジトリでODI Studioを使用して問題を修正してください。インタフェース変換中のエラーは、11gインタフェースの検証の失敗(式のカッコが一致しないなど)により発生することがあります。変換エラーがある場合、結果のマッピングが不完全になることがありますが、他の変換に影響を与えることはありません。

このようなインタフェース・アップグレード・エラーが発生した場合の対処方法は次のとおりです。

- アップグレード・アシスタント・ログ・ファイルで強調表示されているインタフェースが使用されておらず、無視できる場合は、アップグレード済の12cリポジトリを引き続き使用できます。

- インタフェースを有効な12cマッピングに変換する場合は、エラーのある各インタフェースを11g環境で修正し、次の2つの方法のいずれかを使用して再変換する必要があります。

- これらのインタフェースのみエクスポートし、アップグレード済の12cリポジトリにインポートします。インポート・プロセスによって、内部的に11gインタフェースが12cマッピングにアップグレードされます。12cリポジトリへのインタフェースのインポートの詳細は、Oracle Fusion Middleware Oracle Data Integratorでの統合プロジェクトの開発のオブジェクトのインポートを参照してください。

- 修正したインタフェースを使用してアップグレード全部を再度実行します。エラーのあるインタフェースが多数ある場合は、この方法をお薦めします。

アップグレードのパフォーマンス・エラーのトラブルシューティング

リポジトリに存在するセッションの数が、アップグレードのパフォーマンスに影響します。アップグレードのパフォーマンス向上を図るには、セッションのログをアーカイブしてパージすることをお薦めします。

DB2データベース・トランザクション・ログ・エラーのトラブルシューティング

DB2データベースを使用する場合、ODIアップグレード時にデータベース・トランザクション・ログがいっぱいになることがあります。

より大きなログ・ファイルを使用できるように、データベース構成パラメータの値を引き上げることができます。ログ・ファイルを大きくすると、より多くのスペースが必要になりますが、アプリケーションで操作をリトライする必要性が減少します。ログ・ファイルのサイズは10000以上、プライマリ・ログ・ファイルの数は50以上に設定する必要があります。次のコマンドを使用します。

db2 'update database config for database_alias using LOGFILSIZ 10000'
db2 'update database config for database_alias using LOGPRIMARY 50'

親トピック: トラブルシューティングおよび高度な構成

10 高度なアップグレード・オプション

Oracle Data Integratorをアップグレードするための、追加のオプションを設定できます。

これらの追加のオプションは12c (12.1.3)アップグレード・アシスタントでは表示されていましたが、12c (12.2.1.2)アップグレード・アシスタントでは非表示になっています。これらのオプションが必要な場合は、サイレント・モードで使用するレスポンス・ファイルで設定します。

表10-1 高度なアップグレード・オプション

12c (12.1.3)でのオプション名

12c (12.2.1.2)レスポンス・ファイルのオプション名

想定される値(デフォルト＝yes)

説明

GUIDを使用するようにリポジトリをアップグレード

ODI_GUID.option

yesまたはno

これを選択すると、リポジトリが12c完全モードに設定されます。すべてのオブジェクトが、内部IDではなく、12c GUIDを使用して参照されます。

Oracle Data Integrator 12c全体で真に一意の識別スキームを利用するには、このオプションを選択しておく必要があります。

注意: このオプションは、11gリポジトリからアップグレードする場合にのみ適用されます。12cリポジトリの場合、このオプションは無視され、リポジトリはアップグレード前と同じモードのままになります。

odiRef代替APIを使用するカスタム・ナレッジ・モジュールおよびプロシージャがある場合、これらは内部識別子をパラメータとみなすため(getFlexFieldValue()など)、このオプションを選択せずに、リポジトリを11g互換性モードにしておくことができます。こうしたナレッジ・モジュールおよびプロシージャを使用してオブジェクトから生成されたシナリオは、引き続き11g互換性モードで動作しますが、12c完全モードでは動作しません。11g互換性モードを使用することで、新しいodiRef代替API (GUIDをパラメータとみなすAPI)を使用するようカスタム・ナレッジ・モジュールおよびプロシージャをスムーズに遷移できます。すべてのカスタム・ナレッジ・モジュールおよびプロシージャが新しいodiRef代替APIを使用するよう変更された後で、リポジトリを12c完全モードに切り替えることができます。

アップグレード後にリポジトリを完全GUIDモードに変更するには(アップグレード中にアップグレード・アシスタントでオプションを選択していない場合)、Studioに移動し、ODIドロップダウン・メニューでオプション「リポジトリ互換性モードの切替え」を選択します。これで、フルGUIDモードに切り替えるオプションが使用可能になります。リポジトリがすでに完全GUIDモードだった場合、このオプションは無効です。

GUID変更の影響を受ける代替メッセージすべてのリストは、付録A-1を参照してください。

12cマッピングを使用するようにインタフェースをアップグレードします - 11g SDKの互換性が失われます

ODI_SDK.option

yesまたはno

この選択により、すべての11gインタフェースが12cマッピングに変換されます。12cマッピングに変換されたら、使用前に既存のすべてのシナリオを再生成する必要があります。既存の11g SDKアプリケーションは使用できないため、12c SDKを使用するように、それらをアップグレードする必要があります。

変換が実行されても、結果のマッピングが11g互換性モードになる場合、11g Java SDKを使用してマッピングを変更できます。ただし、11g SDKを使用した場合のみ変更できます。Studio UIでは読取り専用です。

このオプションを選択しない場合、12cマッピングへの変換が実行されますが、結果のマッピングは11g互換性モードのままになります。11g SDKを使用してこれらのインタフェースを変更した後、ODI Studioグラフィカル・インタフェースまたは12c SDKを使用して12cマッピングに変換できます。

既存のインタフェースの読取りまたは更新のために11g SDKを使用するJavaコードが大量にある場合を除いて、このオプションは選択しておくことをお薦めします。このオプションは、11gリポジトリからアップグレードする場合にのみ適用されます。12cリポジトリの場合、このオプションは無視され、リポジトリはアップグレード前と同じモードのままになります。

注意: この移行が正しく機能するためには、11gリポジトリのすべてのインタフェースが有効である必要があります(11g Studioからの検証時にエラーを返さないなど)。11gインタフェースが無効である場合、アップグレード・アシスタントは12cマッピングへの移行を試行しますが、結果は保証されません。インタフェースの移行が失敗したり、例外がログ・ファイルに出力される場合があります。いずれの場合も、結果のマッピングが無効になります。スムーズにアップグレードする最良の方法は、最初に11gリポジトリのすべてのインタフェースが有効であることを確認することです。

移行中に一部の11gインタフェースで失敗があっても、アップグレード・プロセスは停止しません。すべてのインタフェースが処理されるまでアップグレードは続行されます。

AES-128暗号化アルゴリズムの使用

ODI_AES.option

yesまたはno

128ビットのキーを持つAESは機密情報に対し十分な保護を提供します。より重要度の高い機密情報を保護するには256ビットのキーを持つAESが必要です。このオプションが選択されていない場合は、AES-256暗号化が使用されます。

表10-2で、「ODIオプション」画面で選択できるオプションと選択できないオプションの組合せについて説明します。

表10-2 「ODIオプション」画面で選択できる組合せ

ナレッジ・モジュールを必須更新で置換

GUIDを使用するようにリポジトリをアップグレード

12cマッピングを使用するようにインタフェースをアップグレード

説明

はい

はい

はい

これが最もよく使用される組合せで、新しい12cリポジトリの作成時に使用する構成です。この組合せでは、すべてのオブジェクトで新しいGUID識別が使用され、すべてのインタフェースが完全な12cマッピングに変換されます(ODI Studioエディタで変更可能)。

はい

いいえ

はい

この組合せでは、リポジトリはID互換性モードのままとなり、従来の数字の識別子を使用するodiRef APIが引き続き機能します。数字のIDを引数とするodiRef APIを使用するカスタム・ナレッジ・モジュールまたはプロシージャが多数ある場合は、この組合せを使用してください。

いいえ

いいえ

はい

この選択では、リポジトリに存在するナレッジ・モジュールは保持され、新しい12cの更新で上書きされません。また、リポジトリはID互換性モードのままとなります。デフォルトのナレッジ・モジュールを変更したが、完全12cマッピングを使用する場合は、この組合せを使用してください。

はい

はい

いいえ

この組合せでは、11gインタフェースが11g互換性マッピングに変換されます(11gインタフェースSDKを介してアクセスおよび変更可能)。これらのマッピングは、ODI Studioエディタでは読取り専用です。11gインタフェースSDKを使用するプログラムまたはスクリプトへの投資が大きい場合は、この組合せを使用してください。

はい

いいえ

いいえ

この選択では、リポジトリはID互換性モードのままとなり、従来の数字の識別子を使用するodiRef APIが引き続き機能します。また、11gインタフェースが11g互換性マッピングに変換されます(11g SDKを介してアクセスおよび変更可能)。ただし、これらはODI Studioエディタでは読取り専用です。数字のIDを引数とするodiRef APIを使用するカスタム・ナレッジ・モジュールまたはプロシージャが多数あり、11gインタフェースSDKを使用するプログラムまたはスクリプトへの投資が大きい場合は、この組合せを使用してください。

いいえ

いいえ

いいえ

いずれのオプションも選択しない場合、リポジトリに存在するナレッジ・モジュールは保持され、新しい12cの更新で上書きされません。これらのマッピングの読取りまたは変更を行うODI 11g SDKを使用するアプリケーションが存在するが、自身の目的でOracle提供のナレッジ・モジュールを変更していない場合は、この組合せを使用してください。

表10-3で、「ODIオプション」画面の無効な組合せについて説明します。

表10-3 「ODIオプション」画面の無効な組合せ

ナレッジ・モジュールを必須更新で置換

GUIDを使用するようにリポジトリをアップグレード

12cマッピングを使用するようにインタフェースをアップグレード

説明

いいえ

はい

いいえ

この選択では、従来の数字のIDを使用する非推奨のodiRef APIが使用されるため、ほとんどのナレッジ・モジュールは正しく機能しません。

いいえ

はい

はい

この組合せでは、従来の数字のIDを使用する非推奨のodiRef APIが使用されるため、ほとんどのナレッジ・モジュールは正しく機能しません。

注意:

「トポロジおよびセキュリティ・メタデータのアップグレード」オプションは、他のすべてのオプションとは関係なく選択または非選択にすることができ、他のオプションには影響しません。

また、「AES-128暗号化アルゴリズムの使用」オプションは、他のすべてのオプションとは関係なく選択または非選択にすることができ、他のオプションには影響しません。

親トピック: トラブルシューティングおよび高度な構成

A 代替API

GUIDをアップグレードすると、パラメータとして内部IDを使用する一部の代替APIメソッドに影響を及ぼします。

表A-1に、新しい代替APIメソッドをリストします。

表A-1 新しい代替APIメソッド

影響を受けるODIRefメソッド

以前のODIRefメソッド

新しいODIRefメソッド

getAK()メソッド

getAK("ID")

getAK("GUID") /* Return the Alternate Key GUID */

getCK()メソッド

getCK("ID")

getCK("GUID") /* Return the Check GUID */

getContext()メソッド

getContext("ID")

getContext("GLOBAL_ID") /* Return the Context GUID*/

getFK()メソッド

getFK("ID")

getFK("GUID") /* Return the Foreign Key GUID */

getFK()メソッド

getFK("ID_TABLE_PK")

getFK("GUID_TABLE_PK") /* Return the Primary Table GUID */

getFK()メソッド

getFK("PK_I_MOD")

getFK ("PK_MOD_GUID") /* Return the Model GUID of Primary Key table */

getInfo()メソッド

getInfo("I_SRC_SET")

getInfo("GUID_SRC_SET") /* Return the SourceSet GUID */

getInfo()メソッド

getInfo("CT_ERR_ID")

getInfo("CT_ERR_GUID") /* Return the Checked Source GUID (a datastore for Static Check or a Mapping for a Flow Check) */

getInfo()メソッド

getInfo("DEST_I_CONNECT")

getInfo("DEST_ CONNECT_GUID") /* Return the Destination connection GUID */

getInfo()メソッド

getInfo("SRC_I_CONNECT")

getInfo("SRC _CONNECT _GUID") /* Return the Source connection GUID */

getInfo()メソッド

getInfo("DEST_I_PSCHEMA")

getInfo("DEST _PSCHEMA _GUID") /* Return the Destination Physical Schema GUID */

getInfo()メソッド

getInfo("SRC_I_PSCHEMA")

getInfo("SRC _PSCHEMA _GUID") /* Return the Source Physical Schema GUID */

getInfo()メソッド

getInfo("DEST_I_LSCHEMA")

getInfo("DEST _LSCHEMA _GUID") /* Return the Destination Logical Schema GUID */

getInfo()メソッド

getInfo("SRC_I_LSCHEMA")

getInfo("SRC _LSCHEMA _GUID") /* Return the Source Logical Schema GUID */

getInfo()メソッド

getInfo("DEST_I_TECHNO")

getInfo("DEST _TECHNO _GUID") /* Return the Destination Technology GUID */

getInfo()メソッド

getInfo("SRC_I_ TECHNO")

getInfo("SRC _ TECHNO _GUID") /* Return the Source Technology GUID */

getLoadPlanInstance() method

getLoadPlanInstance("BATCH_ID")

getLoadPlanInstance("BATCH_GUID") /* Return the batch GUID*/

getNotNullCol() method

getNotNullCol("ID")

getNotNullCol("GLOBAL_ID") /* Return the Attribute GUID */

getModel() method

getModel ("ID")

getModel ("GLOBAL_ID") /* Return the Model GUID */

getPackage() method

getPackage("I_PACKAGE")

getPackage("PACKAGE_ GUID ") /* Return the Package GUID */

getPK() method

getPK("ID")

getPK("GLOBAL_ID") /* Return the Primary Key GUID */

getPrevStepLog() method

getPrevStepLog("SESS_NO")

getPrevStepLog("SESS_GUID") /* Return the Session GUID */

getSession() method

getSession("SESS_NO")

getSession("SESS_GUID") /* Return the Session GUID */

getSrcTablesList() method

getSrcTablesList("I_TABLE")

getSrcTablesList("TABLE_ GUID") /* Return the Source Table GUID */

getStep() method

getStep("SESS_NO")

getStep("SESS_GUID") /* Return the Session GUID */

getTable() method

getTable("ID")

getTable("GLOBAL_ID") /* Return the target Table GUID */

getTargetTable() method

getTargetTable("I_TABLE")

getTargetTable("TABLE_GUID") /* Return the target table GUID */

getUser() method

getUser("I_USER")

getUser("USER_GUID") /* Return the User GUID */