Oracle® Fusion Middleware

Oracle Data Integratorのアップグレード

12c (12.2.1.1)

E77371-02(原本部品番号:E71491-02)

2016年7月

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

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

E77371-02

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

原本著者: Ingrid Snedecor

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

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

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

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.1)へのアップグレードの概要

- 1.1 Oracle Data Integratorの標準アップグレード・トポロジの理解

- 1.1.1 WebLogicドメインに登録されていないスタンドアロン・エージェントのOracle Data Integrator標準アップグレード・トポロジ

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

- 1.1.3 WebLogicドメインに登録されたスタンドアロン・エージェントのOracle Data Integrator標準アップグレード・トポロジ

- 1.2 Oracle Data Integratorをアップグレードする際の有効な開始ポイントの理解

- 1.3 Oracle Data Integrator 11gとOracle Data Integrator 12cの重要な相違点

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

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

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

2 Oracle Data Integratorのアップグレードの準備

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

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

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

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

- 2.3 アップグレードのテストのためのOracle Data Integrator本番環境のクローニング

- 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 DB2データベースを使用する場合のトランザクション・ログ・ファイルのサイズの増加

- 2.10 アップグレードするリポジトリのバックアップの作成

- 2.10.1 作業リポジトリのJDBC URLの更新

- 2.10.2 作業リポジトリが正しいスキーマにアタッチされていることの確認

- 2.11 ODIの外部認証の構成

第II部 11gから12c (12.2.1.1)へのOracle Data Integratorのアップグレード

3 Oracle Data Integratorスタンドアロン・エージェント環境(WebLogicドメインなし)の11gからのアップグレード

- 3.1 Oracle Data Integratorスタンドアロン・エージェント(WebLogicドメインなし)のアップグレード・プロセスの理解

- 3.2 Oracle Data Integratorスタンドアロン環境(WebLogicドメインなし)のインストール

- 3.3 マスターおよび作業リポジトリ・スキーマのアップグレード

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

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

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

- 3.4 スタンドアロン・エージェント環境(WebLogicドメインなし)のアップグレード

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

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

- 3.5 アップグレードの実行および確認

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

- 4.1 Oracle Data Integrator Java EEエージェントのアップグレード・プロセスの理解

- 4.2 Oracle Data Integrator Java EEエージェント環境のインストール

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

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

- 4.5 マスターおよび作業リポジトリ・スキーマのアップグレード

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

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

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

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

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

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

- 4.6.3 ODIドメインの再構成

- 4.7 JRFコンポーネントのアップグレード

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

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

- 4.8 アップグレードの実行および確認

- 4.8.1 ノード・マネージャの構成および起動

- 4.8.2 管理サーバーの再起動

- 4.8.3 管理対象サーバーの起動

5 Oracle Data Integratorスタンドアロン・エージェント環境(WebLogic Domainあり)の11gからのアップグレード

- 5.1 Oracle Data Integratorスタンドアロン・エージェント(WebLogicドメインあり)のアップグレード・プロセスの理解

- 5.2 Oracle Data Integratorスタンドアロン・エージェント環境(WebLogicドメインあり)のインストール

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

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

- 5.5 マスターおよび作業リポジトリ・スキーマのアップグレード

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

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

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

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

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

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

- 5.6.3 ODIドメインの再構成

- 5.7 スタンドアロン・エージェント環境(WebLogicドメインあり)のアップグレード

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

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

- 5.8 アップグレードの実行および確認

- 5.8.1 ノード・マネージャの構成および起動

- 5.8.2 管理サーバーの再起動

- 5.8.3 スタンドアロン・コロケート・エージェントの起動

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

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

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

8 Oracle Data Integratorスタンドアロン・エージェント環境(WebLogic Domainあり)の前の12cリリースからのアップグレード

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

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

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

A 代替API

はじめに

このマニュアルでは、既存のOracle Data Integrator 11g環境を12cにアップグレードする方法について説明します。Oracle Data Integratorアップグレードの有効な開始ポイントについて理解するには、「Oracle Data Integratorをアップグレードする際の有効な開始ポイントの理解」を参照してください。

- 対象読者

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

- 関連ドキュメント

- 表記規則

対象読者

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

- 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 Fusion Middlewareの理解

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

- Oracle Fusion Middlewareのインストールのプランニング

表記規則

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

表記規則

意味

太字

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

斜体

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

固定幅フォント

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

第I部 概要

『Oracle Data Integratorのアップグレード』のこの部では、Oracle Data Integratorについて紹介し、12c (12.2.1.1)にアップグレードするための準備として実行すべき手順を示します。

- Oracle Data Integratorの12c (12.2.1.1)へのアップグレードの概要
Oracle Data Integrator 12c (12.2.1.1)へのアップグレードを開始する前に、標準的なアップグレード・トポロジおよびドメインのアップグレード・パスを理解していることを確認します。

- Oracle Data Integratorのアップグレードの準備
Oracle Data Integrator 12c (12.2.1.1)へのアップグレードを開始する前に、既存のドメインをバックアップし、リポジトリをクローニングし、システムが認定された要件を満たすことを確認する必要があります。

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

Oracle Data Integrator 12c (12.2.1.1)へのアップグレードを開始する前に、標準的なアップグレード・トポロジおよびドメインのアップグレード・パスを理解していることを確認します。

概要の情報および準備の手順の次に、このガイドの手順は2つの項に分かれます。使用するドメイン用の正しい手順を参照することが重要です。

- 11gからのアップグレード、11gから12c (12.2.1.1)へのOracle Data Integratorのアップグレードに記載

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

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

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

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

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

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

- Oracle Data Integratorの標準アップグレード・トポロジの理解
Oracle Data Integratorを12cにアップグレードする手順は、11gに実装されている本番トポロジによって異なります。

- Oracle Data Integratorをアップグレードする際の有効な開始ポイントの理解
このガイドでは、サポートされている11gおよび12cリリースからアップグレードするための情報を提供します。

- Oracle Data Integrator 11gとOracle Data Integrator 12cの重要な相違点
Oracle Data Integrator 11gと12cの間でいくつかの変更が行われました。

親トピック: はじめに

1.1 Oracle Data Integratorの標準アップグレード・トポロジの理解

Oracle Data Integratorを12cにアップグレードする手順は、11gに実装されている本番トポロジによって異なります。

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

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

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

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

このガイドでは、次の特定のアップグレード・トポロジをアップグレードする方法について順を追って説明しています。

- WebLogicドメインに登録されていないスタンドアロン・エージェントのOracle Data Integrator標準アップグレード・トポロジ

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

- WebLogicドメインに登録されたスタンドアロン・エージェントのOracle Data Integrator標準アップグレード・トポロジ

1.1.1 WebLogicドメインに登録されていないスタンドアロン・エージェントのOracle Data Integrator標準アップグレード・トポロジ

11gでは、次のスタンドアロン・エージェント構成(WebLogicドメインに登録されていない)が可能です。

- OPMNで管理されないスタンドアロンOracleインスタンスとしてのスタンドアロン・エージェント

- OPMNで管理されるスタンドアロン・エージェント

図1-1に、(WebLogicドメインに登録されていない)スタンドアロン・エージェントの11g Oracle Data Integrator標準アップグレード・トポロジと、このガイドのアップグレード手順実行後のOracle Fusion Middleware 12cトポロジを示します。

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

図1-1 WebLogicドメインに登録されていないスタンドアロン・エージェントのOracle Data Integrator標準アップグレード・トポロジ

このトポロジ図の共通の要素については、表1-2で説明しています。

追加要素と図1-2の要素とは異なるものを次の表1-1に示します。

表1-1 WebLogicドメインに登録されていないスタンドアロン・エージェントのスタンドアロン・エージェント標準アップグレード・トポロジの要素の説明

要素

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

11g Oracle Data Integratorスタンドアロン・トポロジ

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

これは、1台のマシン上の単一スタンドアロン・エージェント(OracleDIAgent1)で構成されます。スタンドアロン・エージェントはOPMNで管理される場合とそうでない場合があり、アップグレード手順は、11gスタンドアロン・エージェントがOPMNで管理されるかどうかによって多少異なります。

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

このマニュアルでは、このトポロジを12cの同等のトポロジにアップグレードする方法について順を追って説明します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

表1-2 Oracle Data Integrator 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の同等のトポロジにアップグレードする方法について順を追って説明します。

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ドキュメントで使用される標準用語。

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

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

WebLogicドメイン

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

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

管理サーバー

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

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

Enterprise Manager

Oracle Enterprise Manager Fusion Middleware Control。

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

クラスタ

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

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

マシン

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

管理対象サーバー

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

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

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 Application Developer Framework (ADF)

- Oracle Web Services Manager(OWSM)

1.1.3 WebLogicドメインに登録されたスタンドアロン・エージェントのOracle Data Integrator標準アップグレード・トポロジ

Oracle Data Integrator 11gでは、WebLogicドメイン内にOPMNで管理されるスタンドアロン・エージェントを構成することが可能でした。

図1-3に、(WebLogicドメインに登録されている)スタンドアロン・エージェントの11g Oracle Data Integrator標準アップグレード・トポロジと、このガイドのアップグレード手順実行後のOracle Fusion Middleware 12cトポロジを示します。

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

図1-3 WebLogicドメインに登録されたスタンドアロン・エージェントのOracle Data Integrator標準アップグレード・トポロジ

このトポロジ図の共通の要素については、表1-2および表1-1で説明しています。

追加要素と前の図の要素とは異なるものを次の表に示します。

表1-3 WebLogicドメインに登録されたスタンドアロン・エージェントの標準アップグレード・トポロジの要素の説明

要素

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

11g Oracle Data Integratorスタンドアロン・トポロジ

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

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

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

このマニュアルでは、このトポロジを12cの同等のトポロジにアップグレードする方法について順を追って説明します。

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

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

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

1.2 Oracle Data Integratorをアップグレードする際の有効な開始ポイントの理解

このガイドでは、サポートされている11gおよび12cリリースからアップグレードするための情報を提供します。

次の開始ポイントから、Oracle Data Integrator 12c (12.2.1.1)にアップグレードできます。

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

- Oracle Data Integrator 12c (12.1.2、12.1.3および12.2.1)

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

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

- 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.3 Oracle Data Integrator 11gとOracle Data Integrator 12cの重要な相違点

Oracle Data Integrator 11gと12cの間でいくつかの変更が行われました。

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

使用している環境にOracle WebLogic ServerとOracle ADFが含まれている場合は、Application Developer 11gとInfrastructure 12cの主な違いに関する項を参照してください。

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

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

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

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

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

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

詳細は、『Oracle Fusion Middlewareの理解』のWebLogic Management Frameworkの概要に関する項を参照してください。

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

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

詳細は、『Oracle Data Integratorのインストールと構成』のスタンドアロン・エージェントの標準インストール・トポロジの理解に関する項を参照してください。

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

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

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

- インタフェース

- フォルダ

- プロシージャ/KM

注意:

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

- パッケージ

- プロファイル

2 Oracle Data Integratorのアップグレードの準備

Oracle Data Integrator 12c (12.2.1.1)へのアップグレードを開始する前に、既存のドメインをバックアップし、リポジトリをクローニングし、システムが認定された要件を満たすことを確認する必要があります。

この項のタスクは、ユーザーが「Oracle Fusion Middlewareのアップグレードのプランニング」の情報を確認したことを前提としています。

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

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

- アップグレードのテストのためのOracle Data Integrator本番環境のクローニング
Oracle Data Integrator (ODI)本番環境のクローニングは、クローニングおよびクローニングした環境でのアップグレードのテストという2つのプロセスで構成されます。

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

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

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

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

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

- DB2データベースを使用する場合のトランザクション・ログ・ファイルのサイズの増加
DB2データベースを使用する場合、ODIアップグレード時にデータベース・トランザクション・ログがいっぱいになることがあります。

- アップグレードするリポジトリのバックアップの作成
Oracle Data Integratorのマスター・リポジトリおよび作業リポジトリそれぞれのバックアップを作成することをお薦めします。

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

親トピック: はじめに

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

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

アップグレードはサーバーが停止している間に実行されます。このチェックリストでは、停止時間を少なくするためにアップグレードの前に実行できる、重要な(多くの場合時間のかかる)アップグレード前タスクを識別します。アップグレード・プロセスの開始前に多くの準備をすればするほど、オフラインの時間は短くなります。

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

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

タスク

説明

ドキュメント

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

必須

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

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

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

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

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

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

オプション

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

アップグレードのテストのためのOracle Data Integrator本番環境のクローニング

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

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

必須

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

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

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

また、12c製品ディストリビューションをインストールする前に、サポートされているJDKバージョンを使用していることを確認します。

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

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

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

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

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

オプション

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

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

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

オプション

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

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

未使用データのパージ

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

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

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

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

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

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

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

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

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

スキーマ・アップグレードを実行する前に完全なデータベース・バックアップを実行することは、アップグレード・アシスタントを実行するための前提条件です。バックアップにSYSTEM.SCHEMA_VERSION_REGISTRY$表が含まれている必要があります。

実際のアップグレードに進む前に、バックアップが実行されていることを確認する必要があります。詳細は、データベースのドキュメントを参照してください。

Oracle Databaseユーザーは次を参照してください。

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

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

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

- スキーマ・バージョン・レジストリ表のバックアップ
アップグレードの前にシステム・バックアップについて理解しておくことが重要です。システム・バックアップにはSYSTEM.SCHEMA_VERSION_REGISTRY$表を含める必要があります。

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

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

アップグレードの前にシステム・バックアップについて理解しておくことが重要です。システム・バックアップにはSYSTEM.SCHEMA_VERSION_REGISTRY$表を含める必要があります。

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

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

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

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

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

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

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

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

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

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

注意:

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

2.3 アップグレードのテストのためのOracle Data Integrator本番環境のクローニング

Oracle Data Integrator (ODI)本番環境のクローニングは、クローニングおよびクローニングした環境でのアップグレードのテストという2つのプロセスで構成されます。

アップグレードをテストするには、次のタスクを実行します。

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

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

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

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

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

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

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

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

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

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

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

5. ODIエクスポート機能を使用して、本番環境からODIマスター・リポジトリおよび作業リポジトリをエクスポートします。「マスター・リポジトリのエクスポートおよびインポート」を参照してください。

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

7. (オプション)リポジトリのエクスポート/インポートでは作業リポジトリの接続は上書きまたは移動されませんが、接続を確認する場合は、「作業リポジトリが正しいスキーマにアタッチされていることの確認」を参照してください。

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

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

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

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

3. アップグレード・アシスタントでアップグレード前の準備状況チェックを実行します。「アップグレード前の準備状況チェックの実行」を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

この手順は、32ビット環境を実行している場合にのみ必要です。32ビットOSの場合は、アップグレード前に、32ビット環境を64ビット・ソフトウェア環境に移行する必要があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 11gドメイン・ホーム

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

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

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

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

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

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

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

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

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

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

12cディストリビューションを取得する手順の詳細は、製品ディストリビューションについての理解および取得に関する項を参照してください。インストール・ユーザーを特定するには、「インストール・ユーザーの選択」を参照してください。インストールおよび構成のディレクトリ構造について理解するには、「インストールおよび構成のためのディレクトリの理解」を参照してください。インストールするコンポーネントの詳細は、コンポーネント固有のインストール・ガイドを参照してください。

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

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

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

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

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

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

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

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

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

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

必要なJDKをダウンロードするには、ブラウザで次のURLにアクセスしてJava SE JDKをダウンロードします。

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

JDKは、Oracleホームの外部にインストールしてください。Oracle Universal Installerにより指定されたOracleホーム・ディレクトリが空であることが検証され、空のディレクトリが指定されていなければインストールは行われません。JDKをOracleホームにインストールした場合、今後の操作で問題が発生することがあります。したがって、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 SOA SuiteおよびOracle Business Process Management Suiteの管理』の次の情報を参照してください。

- パージおよびパーティション化の方法の開発

- データベース増分管理戦略の策定

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

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

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

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

エディションベースの再定義を使用すると、アプリケーションの使用中にアプリケーションのデータベース・オブジェクトをアップグレードできるため、停止時間を最小限に抑えることや解消することが可能です。これは、エディションと呼ばれるプライベート環境でデータベース・オブジェクトを変更(再定義)することにより実行します。すべての変更が実行およびテストされている場合のみ、アプリケーションの新バージョンをユーザーが使用できるようにしてください。

注意:
このタスクは、DBA権限を持つOracle Databaseユーザーが実行する必要があります。

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

データベース・サーバーにエディションを作成するには、SYSユーザー(またはDBA権限のある別のOracleユーザー)としてログインし、次のコマンドを入力します。

create edition Oracle_FMW_12_2_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;

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

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

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

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

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

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

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

注意:

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

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

2.9 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'

2.10 アップグレードするリポジトリのバックアップの作成

Oracle Data Integratorのマスター・リポジトリおよび作業リポジトリそれぞれのバックアップを作成することをお薦めします。

バックアップにより、必要時にアップグレード前の状態にリストアできます。詳細は、『Oracle Fusion Middlewareのアップグレードのプランニング』のアップグレードのバックアップ計画に関する項を参照してください。

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

アップグレード・アシスタントの前提条件の画面ではODIリポジトリのバックアップが完了したかどうかを確認されます。ただし、アップグレード・アシスタントではバックアップが完了したことが検証されない点に注意してください。

注意:

これは、特にリポジトリをクローニングしていない場合には、アップグレード・プロセスの重要な手順です。アップグレードの結果に問題がある場合、リポジトリはロックされ、使用できません。

ODIリポジトリのバックアップ・コピーを作成することで、重要なデータを失うことがなくなるだけでなく、アップグレード失敗後にリストアする唯一の手段となります。失敗した状態からアップグレードを再開することはできません。

バックアップの作成の詳細は、データベースのバックアップおよびリカバリのドキュメントを参照してください。

- 作業リポジトリのJDBC URLの更新

- 作業リポジトリが正しいスキーマにアタッチされていることの確認

2.10.1 作業リポジトリのJDBC URLの更新

Oracle Data Integratorリポジトリをクローニングすると、クローニングされたマスター・リポジトリには、元のソース・リポジトリの作業リポジトリ接続詳細が埋め込まれます。クローニングする際は、必ずクローニングされるリポジトリのマスター・リポジトリに接続してください。各作業リポジトリを開いて、スキーマ名とパスワード、およびJDBC URL(あるいはその両方)を変更します。

この手順を行わないと、意図せずに元のスキーマがアップグレードされる可能性があります。

例1: CUST1という名前のソース・リポジトリ・スキーマ、CUST1 (workrep1)という名前の作業リポジトリ・スキーマ、およびCUST2 (workrep2)という名前の作業リポジトリ・スキーマを、すべて同じデータベース・インスタンスにリストアします。

作業リポジトリのJDBC URLを更新するには、次の手順を実行します。

1. 次のコマンドでスキーマCUST1およびCUST2をエクスポートすることにより、Oracle Datapumpを使用して単純なクローンを実行します。

Expdb System/Password Directory=Dumpdir Schemas=cust1,cust2 Dumpfile=Filename.dmp

2. CUST1およびCUST2をクローニングして、新しいスキーマ(NEWCUST1、NEWCUST2)を作成します。

Impdp System/Password Directory=Dumpdir Schemas=cust1,cust2 Remap_schemas=cust1:newcust1, cust2:newcust2 Dumpfile=Filename.dmp

3. NEWCUST1のみのマスター・リポジトリに接続します。
ODI Studioを使用して作業リポジトリの接続を確認し、クローニング/バックアップ・スキーマに従ってリポジトリの接続(URL)を更新します。詳細は、『Oracle Data Integratorの管理』のリポジトリの管理のための高度なアクションに関する項を参照してください。

4. ODI Studioを使用して作業リポジトリの接続を確認し、クローニングまたはバックアップ・スキーマに従ってリポジトリの接続(URL)を更新します。詳細は、リポジトリの管理のための高度なアクションに関する項を参照してください。

5. workrep1を開いて、schema_nameをCUST1からNEWCUST1に更新します。

6. workrep2を開いて、schema_nameをCUST2からNEWCUST2に更新します。

例2: CUST1という名前のソース・リポジトリ・スキーマ、CUST1 (workrep1)という名前の作業リポジトリ・スキーマ、およびCUST2 (workrep2)という名前の作業リポジトリ・スキーマがあります。この例では、スキーマの名前変更を行いません。すべてのスキーマを別々のデータベース・インスタンスにリストアします。

スキーマを新しいデータベース・インスタンスにリストアするには、次の手順を実行します。

1. 次のコマンドを実行します。

Impdp System/Password Directory=Dumpdie Schemas=cust1,cust2 Dumpfile=Filename.dmp

2. CUST1のみのマスター・リポジトリに接続します。

3. workrep1を開いて、新しいデータベース・インスタンスを指すようにJDBC URLを更新します。

4. workrep2を開いて、新しいデータベース・インスタンスを指すようにJDBC URLを更新します。

スキーマを新しいデータベース・インスタンスにリストアし、同時にスキーマ名も変更する場合は、schema_namesとJDBC_URLの両方を更新します。

2.10.2 作業リポジトリが正しいスキーマにアタッチされていることの確認

リポジトリをクローニングした後で、リポジトリ接続を確認し、クローニングされたマスター・リポジトリがクローニングされた正しい作業リポジトリ・スキーマを指していることを確認する必要があります。アップグレード・プロセスでは、作業リポジトリ情報がそのマスター・リポジトリから取得されます。作業リポジトリを正常にアップグレードするために、アップグレードの前に、リポジトリが正しいスキーマおよびホストにアタッチされていることを確認する必要があります。

これを確認する手順は、次のとおりです。

注意:

この項のドキュメント・リンクは、11g リリース1 (11.1.1.7)のドキュメントを参照しています。

1. 既存のODIクライアント(アップグレード前のバージョン)を使用してODIマスター・リポジトリに接続します。

詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』のマスター・リポジトリへの接続に関する項を参照してください。

2. 作業リポジトリが正しい作業リポジトリのスキーマおよびホストにアタッチされていることを検証します。

詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』の作業リポジトリへの接続に関する項と作業リポジトリのアタッチおよび削除に関する項を参照してください。

2.11 ODIの外部認証の構成

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

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

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

『Oracle Data Integratorの管理』の次の各項を参照してください。

- 外部認証の構成

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

第II部 11gから12c (12.2.1.1)へのOracle Data Integratorのアップグレード

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

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

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

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

3 Oracle Data Integratorスタンドアロン・エージェント環境(WebLogicドメインなし)の11gからのアップグレード

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

次のアップグレード・シナリオについて説明します。

- OPMNで管理されていない11gスタンドアロン・エージェントの12c (12.2.1.1)へのアップグレード。

- OPMNで管理されている11gスタンドアロン・エージェントの12c (12.2.1.1)へのアップグレード。

次の各項の手順に従って、アップグレードを実行します。

- Oracle Data Integratorスタンドアロン・エージェント(WebLogicドメインなし)のアップグレード・プロセスの理解
WebLogicドメインに登録されていないOracle Data Integratorスタンドアロン・エージェントのアップグレード・プロセスの概要を示すプロセス・フローチャートを確認します。

- Oracle Data Integratorスタンドアロン環境(WebLogicドメインなし)のインストール
アップグレードを開始する前に、Oracle Universal Installerを使用して、WebLogicドメインに登録されていないOracle Data Integratorスタンドアロン・エージェントの12cバージョンをインストールします。

- マスターおよび作業リポジトリ・スキーマのアップグレード
サーバーとプロセスを停止した後、アップグレード・アシスタントを使用してマスターおよび作業リポジトリ・スキーマをアップグレードします。

- スタンドアロン・エージェント環境(WebLogicドメインなし)のアップグレード
リポジトリ・スキーマをアップグレードした後、スタンドアロン・エージェント(WebLogicドメインなし)環境でスタンドアロン・システム・コンポーネント構成をアップグレードできます。

- アップグレードの完了および確認
アップグレード手順がすべて完了したら、アップグレードが成功したことを確認します。

親トピック: 11gから12c (12.2.1.1)へのOracle Data Integratorのアップグレード

3.1 Oracle Data Integratorスタンドアロン・エージェント(WebLogicドメインなし)のアップグレード・プロセスの理解

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

図3-1 ODIスタンドアロン・エージェント(WebLogicドメインなし)のアップグレード・プロセス・フローチャート

フローチャートの最初のタスクは、次で説明します。

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

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

この章の残りの各項では、WebLogicドメインに登録されていないOracle Data Integratorスタンドアロン・エージェントのアップグレードに固有の手順について説明します。

3.2 Oracle Data Integratorスタンドアロン環境(WebLogicドメインなし)のインストール

アップグレードを開始する前に、Oracle Universal Installerを使用して、WebLogicドメインに登録されていないOracle Data Integratorスタンドアロン・エージェントの12cバージョンをインストールします。

「12c Oracle Fusion Middleware製品ディストリビューションのダウンロードとインストール」の一般情報を確認した後、『Oracle Data Integratorのインストールと構成』の手順に従ってください。

1. 「Oracle Data Integratorインストールの計画」では、Oracle Data Integratorのインストール・トポロジに関する重要な情報を理解します。
この項では、12cの重要な概念の一部を説明し、必要な製品ディストリビューションの入手場所に関する情報も提供します。

2. 「Oracle Data Integratorのインストール」では、Oracle Data Integratorスタンドアロン・エージェント環境をインストールします。

注意:
構成ウィザードで新規のOracle Data Integratorインストールを構成しないでください。アップグレード中にアップグレード・アシスタントでスタンドアロン・エージェント環境の構成が行われます。

3.3 マスターおよび作業リポジトリ・スキーマのアップグレード

サーバーとプロセスを停止した後、アップグレード・アシスタントを使用してマスターおよび作業リポジトリ・スキーマをアップグレードします。

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

- アップグレード・アシスタントの起動
アップグレード・アシスタントはOracle Data Integrator 11gリポジトリ・スキーマをOracle Data Integrator 12cへアップグレードします。

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

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

アップグレード・アシスタントを実行してスキーマをアップグレードする前に、管理サーバーや管理対象サーバーを含め、すべてのプロセスとサーバーをシャットダウンします。

詳細は、『Oracle Fusion Middlewareの管理』のOracle Fusion Middlewareの起動と停止に関する項を参照してください。

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

3.3.2 Upgrade Assistantの起動

アップグレード・アシスタントはOracle Data Integrator 11gリポジトリ・スキーマをOracle Data Integrator 12cへアップグレードします。

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

再定義のためのサーバーでのエディション作成の詳細は、『Oracle Fusion Middlewareのアップグレードのプランニング』のエディションベースの再定義のためのサーバーでのエディション作成に関する項を参照してください。

注意:
外部認証を使用している場合は、外部認証が内部認証に設定されていることを確認してください。詳細は、「ODIの外部認証の構成」を参照してください

必須ではありませんが、アップグレード・アシスタントを実行するには、非SYSDBAユーザーを作成することをお薦めします。非SYSDBAユーザーをまだ作成してない場合は、「非SYSDBAユーザーの作成」を参照してください。

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

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

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

ORACLE_HOME/oracle_common/upgrade/bin

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

ORACLE_HOME\oracle_common\upgrade\bin

2. Upgrade Assistantを起動します。

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

./ua

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

ua.bat

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

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

注意:

アップグレード・アシスタントは、ODIマスター・リポジトリのデータおよび構造を使用して、リポジトリがすでにアップグレード済でないかどうかを判定します。アップグレード・アシスタントは、次の状況の場合には、リポジトリがアップグレード済であることを示すメッセージを返します。

- スキーマ・バージョン・レジストリが有効な状態で、リポジトリのバージョンを保持している

- リポジトリが12cである

- リポジトリのバージョンが、アップグレード・アシスタントが使用するODI SDKのバージョン以上である

リポジトリ・カタログ情報をデバッグまたは表示するには、(ODIスキーマ/リポジトリ内ではなく)Adminユーザーに格納されているschema_version_registry表に対して次の問合せを使用します。

Oracleデータベースでは、この表の名前はSYSTEM.SCHEMA_VERSION_REGISTRY$であり、SYSTEMスキーマに格納されています。また、SYSTEM.SCHEMA_VERSION_REGISTRYというビューと、このビューを示すパブリック・シノニムSCHEMA_VERSION_REGISTRYがあります。

SELECT COMP_ID,COMP_NAME,MRC_NAME,OWNER,VERSION,STATUS,UPGRADED FROM schema_version_registry;

DB2/400オペレーティング・システムの場合、AdminユーザーはQSECOFRで、schema_version_registry表はスキーマ'NULLID'内に配置されています。

ODIコンポーネントの行は、ODIリポジトリの追跡に使用されます。

1. アップグレード・アシスタントの導入

「ようこそ」画面には、アップグレードに進む前に考慮する重要な注意事項が含まれています。これらに目を通し、作業を進める準備が整っていることを確認します。

2. アップグレード操作の選択

「スキーマ」画面で、実行するスキーマ・アップグレード操作を選択します。

- 「個別に選択されたスキーマ」では、「使用可能なコンポーネント」画面にアップグレード可能なスキーマがあるインストール済みOracle Fusion Middlewareコンポーネントのリストが表示されます。マスターおよび作業リポジトリ・スキーマをアップグレードするには、「Oracle Data Integrator」を選択します。依存スキーマは自動的に選択されることに注意してください。

- ドメインで使用されるすべてのスキーマでは、すべてのスキーマ・コンポーネントのリスト画面にアップグレードに含まれる特定のドメイン・ディレクトリ内のすべてのコンポーネントおよびスキーマが表示されます。

3. 前提条件の検証

「前提条件」画面で、アップグレードの前提条件が満たされていることを確認してチェックを外します。

続行する前にボックスを確認してください。Upgrade Assistantでは前提条件が満たされていることを確認できません。

4. データベースおよびスキーマ資格証明の指定

ODIスキーマ画面で、アップグレードするスキーマが含まれるデータベースの接続資格証明を入力して「接続」をクリックします。

5. ODIアップグレード・オプションの選択

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

次の表で、各オプションを説明します。

表3-1 ODIのオプション

オプション

説明

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

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

ODIのアップグレードを行わない場合は、『Oracle Data Integratorでの統合プロジェクトの開発』の互換性モードの使用に関する項を参照してください。

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

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

手動でのアップグレード方法の詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』を参照してください。

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

6. スーパーバイザ・アカウント資格証明の指定

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

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

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

7. ODIアップグレード・キーの選択

11gから12cへのアップグレードのみ。 「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)を持つプロジェクトが含まれている可能性があります。この場合、誤ったオブジェクトの一致によるメタデータの破損を防ぐため、そのファイルをリポジトリにインポートする際には、別のカスタム・アップグレード・キーを使用する必要があります。

8. アップグレードの検証の完了

「調査」画面では、アップグレード・アシスタントにより、選択したコンポーネントをアップグレードする前に、一連の検証が実行されます。すべての検証が成功していることを確認します。

9. アップグレードの開始と完了

「アップグレード・サマリー」画面で「アップグレード」をクリックし、アップグレードを開始します。「アップグレードの進行状況」の各画面には、アップグレードの進行状況に関する情報が示され、「アップグレード成功」画面にアップグレードが要約されます。

10. スキーマ・バージョンの確認

スキーマがアップグレードされたことを確認するには、データベース・ホストからSQL*Plusを実行し、次のコマンドを使用します。

select owner, version, status from schema_version_registry where owner = 'prefix_ODI_REPO';

prefixを、RCUで作成されたリポジトリ・スキーマのカスタム接頭辞で置き換えます。次に、例を示します。

select owner, version, status from schema_version_registry where owner = DEV1221_ODI_REPO
OWNER                          VERSION                        STATUS
------------------------------ ------------------------------ -----------
DEV1221_ODI_REPO               12.2.1.1.0                     VALID

出力で、VERSION列においてスキーマ・バージョン番号が12.2.1.1.0であることを確認します。

3.4 スタンドアロン・エージェント環境(WebLogicドメインなし)のアップグレード

リポジトリ・スキーマをアップグレードした後、スタンドアロン・エージェント(WebLogicドメインなし)環境でスタンドアロン・システム・コンポーネント構成をアップグレードできます。

- アップグレード・アシスタントの起動
アップグレード・アシスタントを再度実行して、コンポーネント構成を12cにアップグレードします。

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

3.4.1 Upgrade Assistantの起動

アップグレード・アシスタントを再度実行して、コンポーネント構成を12cにアップグレードします。

アップグレード・アシスタントを起動するには、ORACLE_HOME/oracle_common/upgrade/binディレクトリに移動し、次のコマンドを入力します。

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

./ua

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

ua.bat

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

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

1. アップグレード・アシスタントの導入

「ようこそ」画面には、アップグレードに進む前に考慮する重要な注意事項が含まれています。これらに目を通し、作業を進める準備が整っていることを確認します。

2. アップグレード操作の選択

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

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

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

ヒント:

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

3. アップグレード対象のコンポーネントの確認

「コンポーネント・リスト」画面には、アップグレード対象のコンポーネントが表示されます。

- システム・コンポーネント・インフラストラクチャ

- Oracle Data Integrator

4. 前提条件の検証

「前提条件」画面には、先に進む前に確認が必要な項目がリストされます。

続行する前にボックスを確認してください。Upgrade Assistantでは前提条件が満たされていることを確認できません。

5. インスタンス・ディレクトリの指定

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

6. ノード・マネージャの作成

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

7. アップグレードの検証の完了

すべての検証が成功していることを確認します。

8. アップグレードの開始と完了

「アップグレード・サマリー」画面で「アップグレード」をクリックし、アップグレードを開始します。「アップグレードの進行状況」の各画面には、アップグレードの進行状況に関する情報が示され、「アップグレード成功」画面にアップグレードが要約されます。

3.5 アップグレードの実行および確認

アップグレード手順がすべて完了したら、アップグレードが成功したことを確認します。

次のタスクを実行します。

- ノード・マネージャを起動します。
詳細は、『Oracle Data Integratorのインストールと構成』のノード・マネージャの起動に関する項を参照してください。

- Oracle Data Integratorスタンドアロン・エージェントを起動します。
詳細は、『Oracle Data Integratorのインストールと構成』のノード・マネージャでのスタンドアロン・エージェントの起動に関する項を参照してください。

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

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

次の各項の手順に従って、アップグレードを実行します。

- Oracle Data Integrator Java EEエージェントのアップグレード・プロセスの理解
Oracle Data Integrator Java EEエージェント環境のアップグレード・プロセスの概要を示すプロセス・フローチャートを確認します。

- Oracle Data Integrator Java EEエージェント環境のインストール
アップグレードを開始する前に、Oracle Universal Installerを使用してOracle Data Integratorの12cバージョンをインストールします。

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

- アップグレード前の準備状況チェックの実行
アップグレード・アシスタントを-readinessモードで実行することにより、実際にアップグレードを実行する前にアップグレードの潜在的な問題を特定できます。

- マスターおよび作業リポジトリ・スキーマのアップグレード
サーバーとプロセスを停止した後、アップグレード・アシスタントを使用してマスターおよび作業リポジトリ・スキーマをアップグレードします。

- 再構成ウィザードを使用したドメインの再構成
スキーマをアップグレードした後、再構成ウィザードを実行して、ドメイン・コンポーネント構成を12cに再構成します。

- JRFコンポーネントのアップグレード
WebLogicドメイン内のOracle Java Required Files (JRF)コンポーネントをアップグレードできます。

- アップグレードの完了および確認
アップグレード手順がすべて完了したら、アップグレードが成功したことを確認します。

親トピック: 11gから12c (12.2.1.1)へのOracle Data Integratorのアップグレード

4.1 Oracle Data Integrator Java EEエージェントのアップグレード・プロセスの理解

Oracle Data Integrator Java EEエージェント環境のアップグレード・プロセスの概要を示すプロセス・フローチャートを確認します。

図4-1 ODI Java EEエージェントのアップグレード・プロセス・フローチャート

フローチャートの最初のタスクは、次で説明します。

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

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

この章の残りの各項では、Oracle Data Integrator Java EEエージェントのアップグレードに固有の手順について説明します。

4.2 Oracle Data Integrator Java EEエージェント環境のインストール

アップグレードを開始する前に、Oracle Universal Installerを使用して、Oracle Data Integratorの12cバージョンをインストールします。

「12c Oracle Fusion Middleware製品ディストリビューションのダウンロードとインストール」の一般情報を確認した後、『Oracle Data Integratorのインストールと構成』の手順に従ってください。

1. 「Oracle Data Integratorインストールの計画」では、Oracle Data Integratorのインストール・トポロジに関する重要な情報を理解します。
この項では、12cの重要な概念の一部を説明し、必要な製品ディストリビューションの入手場所に関する情報も提供します。Java EEエージェント環境の場合、Oracle Data Integratorをインストールするための前提条件として、Oracle Fusion Middleware Infrastructureも必要です。

2. 「Oracle Data Integratorのインストール」では、特定の環境向けのOracle Data Integratorをインストールします。

注意:
構成ウィザードで新規の12c WebLogicドメインを構成しないでください。かわりに、スキーマのアップグレード後に再構成ウィザードを使用してドメインを構成します。WebLogicドメイン内のいずれかのOracle Java Required Files (JRF)コンポーネントを更新する必要がある場合は、再構成ウィザードの後にオプションでアップグレード・アシスタントを実行できます。

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

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

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

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_APPENDおよび_IAU_VIEWERを必ず選択します。これらを選択したときに、アップグレード・アシスタントによって自動的に作成されます。

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_HOME環境変数を設定し、$PATHに$JAVA_HOME/binを追加します。現在サポートされているJDKバージョンは、jdk1.8.0_77.です

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

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

ORACLE_HOME/oracle_common/upgrade/bin

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

ORACLE_HOME\oracle_common\upgrade\bin

4. RCUを起動します。

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

./rcu

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

rcu.bat

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

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

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

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

オプション

説明および例

ホスト名

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

examplehost.exampledomain.com

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

ポート

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

サービス名

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

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

examplehost.exampledomain.com

ユーザー名

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

パスワード

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

ロール

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

「標準」またはSYSDBA

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

オプション

説明および例

ホスト名

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

ポート

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

データベース名

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

ユーザー名

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

パスワード

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

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

オプション

説明および例

Unicodeのサポート

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

サーバー名

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

ポート

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

データベース名

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

ユーザー名

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

パスワード

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

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

オプション

説明および例

サーバー名

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

ポート

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

データベース名

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

ユーザー名

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

パスワード

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

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

8. 「コンポーネントの選択」画面で、「既存の接頭辞の選択」を選択し、ドロップダウン・メニューから既存の11gスキーマの作成に使用した接頭辞(たとえば、DEV11G)を選択します。この接頭辞は、スキーマをこのドメインで使用するために論理的にまとめてグループ化するために使用されます。

注意: デフォルトで、Common Infrastructure Services Table (prefix_STB)およびOPSS (prefix_OPSS)スキーマが選択されます(それらがまだ作成されていない場合)。

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

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

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

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

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

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

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

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

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

準備状況チェックは、既存のドメインまたはデータベース・スキーマをスキャンし、スキャンの結果が記載されたテキスト・ファイルを生成する読取り専用操作です。アップグレード前の環境に問題がある場合、アップグレードする前にこれらの問題を修正してから、準備状況チェックを再実行できます。

デフォルトで、準備状況チェック・レポート・ファイルはOracle 12cディレクトリ(ORACLE_HOME/oracle_common/upgrade/logs)に配置されます。

注意:
準備状況チェックは、システムがオンライン中に実行できます。チェックの複雑さによっては、準備状況チェックが終わるまでにしばらく時間がかかります。パフォーマンスの低下を回避するために、準備状況チェックはオフピーク時に実行することをお薦めします。

アップグレード前の環境に対して準備状況チェックを実行するには、-readinessモードでアップグレード・アシスタントを起動します。

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

ORACLE_HOME/oracle_common/upgrade/bin

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

ORACLE_HOME\oracle_common\upgrade\bin

2. Upgrade Assistantを起動します。
UNIXオペレーティング・システムの場合:

./ua -readiness

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

ua.bat -readiness

次のUNIXの例に示すように、ロギング・パラメータを使用してアップグレード・アシスタントを起動することもできます。

./ua [-logLevel log_level] [-logDir log_directory]

ここでlog_levelは次のいずれかになります。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

log_levelのデフォルト値はNOTIFICATIONです。

トラブルシューティングする場合、log_levelをTRACEに設定すると、より多くの情報がロギングされます。-logLevel TRACEが使用されると、アップグレード・アシスタントのログ・ファイルは非常に大きくなる可能性があるため、別の情報が必要ない場合は、log_level値を変更してください。

注意:
サービス表スキーマを作成していない場合、エラー・メッセージUPGAST-00328: スキーマ・バージョン・レジストリ表がこのデータベースに存在しません。これが発生した場合、アップグレード・アシスタントを実行するためにサービス表スキーマを作成する必要があります。が表示されます。
これが発生した場合、リポジトリ作成ユーティリティ(RCU)を使用して必要な12c スキーマを作成する必要があります。

表4-5 Upgrade Assistant画面: 準備状況チェック

画面

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

説明

ようこそ

常時。

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

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

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

- ドメイン・ベース

常時。

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

- 「個別に選択されたスキーマ」オプションを使用すると、アップグレードする前に確認するスキーマを選択できます。

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

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

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

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

すべてのスキーマのコンポーネント・リスト

スキーマの準備状況チェックが実行されるたび。

この画面は、スキーマの準備状況チェックが実行されるたびに表示されます。これは、「すべてのスキーマのチェックを含める」オプションを使用して「個別に選択されたスキーマ」または「ドメイン・ベース」を選択する場合です。

スキーマ資格証明

常時。

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

DBAユーザー名: SYSDBAではなくFMWとしてUpgrade Assistantを実行することをお薦めします。まだFMWユーザーを作成していない場合は、「Upgrade Assistantを実行するための非SYSDBAユーザーの作成」を参照してください

準備状況サマリー

常時。

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

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

準備状況チェック

常時。

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

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

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

準備状況成功

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

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

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

デフォルトで、準備状況チェック・レポート・ファイルは次のOracle 12cディレクトリに配置されます。

ORACLE_HOME/oracle_common/upgrade/logs

4.5 マスターおよび作業リポジトリ・スキーマのアップグレード

サーバーとプロセスを停止した後、アップグレード・アシスタントを使用してマスターおよび作業リポジトリ・スキーマをアップグレードします。

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

- アップグレード・アシスタントの起動
アップグレード・アシスタントはOracle Data Integrator 11gリポジトリ・スキーマをOracle Data Integrator 12cへアップグレードします。

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

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

アップグレード・アシスタントを実行してスキーマをアップグレードする前に、管理サーバーや管理対象サーバーを含め、すべてのプロセスとサーバーをシャットダウンします。

詳細は、『Oracle Fusion Middlewareの管理』のOracle Fusion Middlewareの起動と停止に関する項を参照してください。

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

4.5.2 Upgrade Assistantの起動

アップグレード・アシスタントはOracle Data Integrator 11gリポジトリ・スキーマをOracle Data Integrator 12cへアップグレードします。

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

再定義のためのサーバーでのエディション作成の詳細は、『Oracle Fusion Middlewareのアップグレードのプランニング』のエディションベースの再定義のためのサーバーでのエディション作成に関する項を参照してください。

注意:
外部認証を使用している場合は、外部認証が内部認証に設定されていることを確認してください。詳細は、「ODIの外部認証の構成」を参照してください

必須ではありませんが、アップグレード・アシスタントを実行するには、非SYSDBAユーザーを作成することをお薦めします。非SYSDBAユーザーをまだ作成してない場合は、「非SYSDBAユーザーの作成」を参照してください。

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

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

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

ORACLE_HOME/oracle_common/upgrade/bin

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

ORACLE_HOME\oracle_common\upgrade\bin

2. Upgrade Assistantを起動します。

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

./ua

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

ua.bat

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

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

注意:

アップグレード・アシスタントは、ODIマスター・リポジトリのデータおよび構造を使用して、リポジトリがすでにアップグレード済でないかどうかを判定します。アップグレード・アシスタントは、次の状況の場合には、リポジトリがアップグレード済であることを示すメッセージを返します。

- スキーマ・バージョン・レジストリが有効な状態で、リポジトリのバージョンを保持している

- リポジトリが12cである

- リポジトリのバージョンが、アップグレード・アシスタントが使用するODI SDKのバージョン以上である

リポジトリ・カタログ情報をデバッグまたは表示するには、(ODIスキーマ/リポジトリ内ではなく)Adminユーザーに格納されているschema_version_registry表に対して次の問合せを使用します。

Oracleデータベースでは、この表の名前はSYSTEM.SCHEMA_VERSION_REGISTRY$であり、SYSTEMスキーマに格納されています。また、SYSTEM.SCHEMA_VERSION_REGISTRYというビューと、このビューを示すパブリック・シノニムSCHEMA_VERSION_REGISTRYがあります。

SELECT COMP_ID,COMP_NAME,MRC_NAME,OWNER,VERSION,STATUS,UPGRADED FROM schema_version_registry;

DB2/400オペレーティング・システムの場合、AdminユーザーはQSECOFRで、schema_version_registry表はスキーマ'NULLID'内に配置されています。

ODIコンポーネントの行は、ODIリポジトリの追跡に使用されます。

1. アップグレード・アシスタントの導入

「ようこそ」画面には、アップグレードに進む前に考慮する重要な注意事項が含まれています。これらに目を通し、作業を進める準備が整っていることを確認します。

2. アップグレード操作の選択

「スキーマ」画面で、実行するスキーマ・アップグレード操作を選択します。

- 「個別に選択されたスキーマ」では、「使用可能なコンポーネント」画面にアップグレード可能なスキーマがあるインストール済みOracle Fusion Middlewareコンポーネントのリストが表示されます。マスターおよび作業リポジトリ・スキーマをアップグレードするには、「Oracle Data Integrator」を選択します。依存スキーマは自動的に選択されることに注意してください。

- ドメインで使用されるすべてのスキーマでは、すべてのスキーマ・コンポーネントのリスト画面にアップグレードに含まれる特定のドメイン・ディレクトリ内のすべてのコンポーネントおよびスキーマが表示されます。

3. 前提条件の検証

「前提条件」画面で、アップグレードの前提条件が満たされていることを確認してチェックを外します。

続行する前にボックスを確認してください。Upgrade Assistantでは前提条件が満たされていることを確認できません。

4. データベースおよびスキーマ資格証明の指定

ODIスキーマ画面で、アップグレードするスキーマが含まれるデータベースの接続資格証明を入力して「接続」をクリックします。

5. ODIアップグレード・オプションの選択

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

次の表で、各オプションを説明します。

表4-6 ODIのオプション

オプション

説明

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

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

ODIのアップグレードを行わない場合は、『Oracle Data Integratorでの統合プロジェクトの開発』の互換性モードの使用に関する項を参照してください。

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

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

手動でのアップグレード方法の詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』を参照してください。

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

6. スーパーバイザ・アカウント資格証明の指定

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

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

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

7. ODIアップグレード・キーの選択

11gから12cへのアップグレードのみ。 「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)を持つプロジェクトが含まれている可能性があります。この場合、誤ったオブジェクトの一致によるメタデータの破損を防ぐため、そのファイルをリポジトリにインポートする際には、別のカスタム・アップグレード・キーを使用する必要があります。

8. アップグレードの検証の完了

「調査」画面では、アップグレード・アシスタントにより、選択したコンポーネントをアップグレードする前に、一連の検証が実行されます。すべての検証が成功していることを確認します。

9. アップグレードの開始と完了

「アップグレード・サマリー」画面で「アップグレード」をクリックし、アップグレードを開始します。「アップグレードの進行状況」の各画面には、アップグレードの進行状況に関する情報が示され、「アップグレード成功」画面にアップグレードが要約されます。

10. スキーマ・バージョンの確認

スキーマがアップグレードされたことを確認するには、データベース・ホストからSQL*Plusを実行し、次のコマンドを使用します。

select owner, version, status from schema_version_registry where owner = 'prefix_ODI_REPO';

prefixを、RCUで作成されたリポジトリ・スキーマのカスタム接頭辞で置き換えます。次に、例を示します。

select owner, version, status from schema_version_registry where owner = DEV1221_ODI_REPO
OWNER                          VERSION                        STATUS
------------------------------ ------------------------------ -----------
DEV1221_ODI_REPO               12.2.1.1.0                     VALID

出力で、VERSION列においてスキーマ・バージョン番号が12.2.1.1.0であることを確認します。

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

スキーマをアップグレードした後、再構成ウィザードを実行して、ドメイン・コンポーネント構成を12cに再構成します。

再構成ウィザードを実行して、WebLogic Serverドメインを再構成する場合は、ドメインのアプリケーションによって、次の項目が自動的に更新されます。

- WLSコア・インフラストラクチャ

- ドメイン・バージョン

注意:
再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。

具体的には、ドメインを再構成すると、次のようになります。

- ドメインのconfig.xmlファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンに更新されます。

- すべてのインストール済Oracle製品の再構成テンプレートは、自動的に選択されてドメインに適用されます。これらのテンプレートは、WebLogicドメインが現在のWebLogic Serverバージョンと互換性を持つために必要な再構成タスクを定義します。

- 起動スクリプトが更新されます。

注意:
ドメインの再構成プロセスを開始すると、元に戻すことはできません。再構成ウィザードを実行する前に、「ドメインのバックアップ」の説明に従ってドメインをバックアップしていることを確認してください。再構成ウィザードの実行中にエラーその他の中断が発生した場合は、バックアップの場所から元のドメイン・ディレクトリにファイルとディレクトリをコピーして、ドメインをリストアする必要があります。これは、再構成前にドメインを確実に元の状態に戻す唯一の方法です。

再構成ウィザードを使用して既存のドメインを再構成する手順に従います。ドメインの再構成に関する一般的な情報は、WebLogicドメインの再構成に関する項を参照してください。

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

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

- ODIドメインの再構成

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

再構成ウィザードを実行する前に、ドメイン・ディレクトリのバックアップ・コピーを作成します。

1. コンテンツを保持するには、ソース・ドメインを別の場所にコピーします。
たとえば、C:\domains\mydomain to C:\domains\mydomain_backupにコピーします。

2. 各リモート管理対象サーバーのドメインを更新する前に、各リモート・マシンのドメイン・ディレクトリのバックアップ・コピーを作成します。

3. ドメインのバックアップしたバージョンが完全であることを確認します。

ドメインの再構成がなんらかの理由で失敗した場合は、再構成を実行する前に、すべてのファイルおよびディレクトリをバックアップ・ディレクトリから元のドメイン・ディレクトリにコピーしてドメインを完全に元の状態に戻す必要があります。

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

再構成ウィザードをグラフィカル・モードで起動する手順は次のとおりです。

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

2. コマンド・シェル(UNIXオペレーティング・システムの場合)またはコマンド・プロンプト・ウィンドウ(Windowsオペレーティング・システムの場合)を開きます。

3. エディション・ベースのデータベース・ユーザーのみ: スキーマがEBRデータベースを使用して構成されている場合、再構成ウィザードを実行する前に、手動でデフォルトのエディション名を設定する必要があります。

次のSQLコマンドを実行して、デフォルト・エディションを設定します。

ALTER DATABASE DEFAULT EDITION = edition_name;

ここで、edition_nameは、子エディションの名前です。

4. binディレクトリに移動します。

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

ORACLE_HOME/oracle_common/upgrade/bin

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

ORACLE_HOME\oracle_common\upgrade\bin

5. 再構成ウィザードをロギング・オプションとともに起動します。

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

./reconfig.sh -log=log_file -log_priority=ALL

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

reconfig.cmd -log=log_file -log_priority=ALL

log_fileは、ドメイン再構成セッション用に作成するログ・ファイルの絶対パスです。これは、再構成処理をトラブルシューティングする必要がある場合に役立つことがあります。

パラメータ -log_priority=ALLは、ログを詳細モードで出力します。

注意:

このコマンドを実行すると、デフォルトのキャッシュ・ディレクトリが無効であることを示す次のエラー・メッセージが表示される場合があります。

*sys-package-mgr*: can't create package cache dir

環境変数CONFIG_JVM_ARGSを設定することでキャッシュ・ディレクトリを変更できます。次に例を示します。

CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

4.6.3 ODIドメインの再構成

再構成ウィザードの各画面で、必要なアクションを実行します。下の表に示す画面は、いくつかが表示されないこともあります。また、使用する環境の設定に基づいた追加の画面を完了する必要がある場合もあります。詳細は、『Oracle WebLogic Serverのアップグレード』のWebLogicドメインの再構成に関する項を参照してください。

表4-7 再構成ウィザードの画面

再構成ウィザードの画面

説明および必要なアクション

ドメインの選択

既存のドメイン・ディレクトリの絶対パスを入力するか、「参照」をクリックしてドメイン・ディレクトリを選択します。

再構成セットアップの進行状況

再構成テンプレートの適用の進行状況が表示されます。

ドメイン・モードおよびJDK

ドメイン・モードは変更できません。

ドメインで使用するJDKを選択するか、「参照」をクリックして使用するJDKに移動します。

Oracle Fusion Middleware 12cにはJava SE 7が必要であることに注意してください。詳細は、『Oracle Fusion Middlewareのインストールのプランニング』の動作保証とシステム要件の検証に関する項を参照してください。

データベース構成タイプ

「RCUデータ」オプションを使用して、Server Table (_STB)スキーマを収集します。Repository Creation Utility (RCU)はサービス表スキーマを自動的に使用して、他の12cスキーマ資格証明を自動的にロードします。後続JDBC画面のデータを常に確認してください。

注意: 既存の11gデータ・ソースの場合、再構成では既存の値が保存されます。スキーマが12c RCUで作成された新しいデータ・ソースの場合、デフォルトの接続データは_STBスキーマから取得されます。特定のスキーマの接続データが_STBスキーマにない場合は、デフォルトの接続データが使用されます。

詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のデータベース構成タイプに関する項を参照してください。

JDBCデータ・ソース

この画面は、11gでデータベースベースのOPSSセキュリティ・ストアまたは監査データ・ストア用にカスタム・データ・ソースを作成していた場合に表示されます。

この画面では、ドメイン・ソースで定義したJDBCデータ・ソースを構成します。

このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のJDBCデータ・ソースに関する項を参照してください。

JDBCデータ・ソース・テスト

「JDBCデータ・ソース」画面で構成したデータ・ソース接続をテストします。

このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のJDBCデータ・ソースのテストに関する項を参照してください。

JDBCコンポーネント・スキーマ

各スキーマ名の横のチェック・ボックスを選択して、画面に表示された各スキーマのデータソース設定を指定します。

注意:

- アップグレードしたスキーマに、11gスキーマの詳細を指定する必要があります。それ以外については、12c (12.2.1.1)スキーマの詳細を指定します。

- このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のJDBCコンポーネント・スキーマに関する項を参照してください。

JDBCコンポーネント・スキーマ・テスト

前の画面でデータ・ソースに指定した構成をテストします。テストするスキーマ名の横のチェック・ボックスを選択し、「選択された接続のテスト(T)」をクリックします。

テストの結果は、「ステータス」列に表示されます。すべてのスキーマでテストに成功した場合、「次へ」をクリックします。

ノード・マネージャ

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

ドメインごとおよびホストごとのノード・マネージャの構成の詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャのデフォルトの構成に関する項を参照してください。

拡張構成

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

管理対象サーバー

ドメインの各管理対象サーバーに対し、リスニング・アドレスの実際のホスト名を指定する必要があります。

デフォルトのlocalhostまたはAll Local Addressesオプションは使用しないでください。

実際のホスト名を、hostname.company.comのように指定する必要があります。

サーバーのマシンへの割当て

アップグレード・プロセスの一部としてサーバーを作成した場合は、「サーバー」リスト・ボックスでサーバー名を選択して、適切なノード・マネージャ・マシンにターゲット設定します。

そうでない場合は、ドメインのアップグレード時または再構成時にこの画面で操作は必要ありません。

サーバーのクラスタへの割当て

クラスタのアップグレードのみ: クラスタをアップグレードする場合は、この画面を使用して管理対象サーバーをクラスタに割り当てます。

「サーバー」リスト・ボックスには管理対象サーバーのみが表示されます。管理サーバーは、クラスタに割り当てることができないので、リストに表示されません。

構成のサマリー

構成のサマリーを確認します。

「再構成」をクリックしてドメインを再構成するか、「戻る」をクリックして構成を変更します。

再構成の進行状況

再構成の進行状況を確認します。処理が完了したら「次へ」をクリックします。

再構成に成功しました

再構成処理の最終的なステータスを確認します。「終了(F)」をクリックして再構成ウィザードを終了します。

4.7 JRFコンポーネントのアップグレード

WebLogicドメイン内のOracle Java Required Files (JRF)コンポーネントをアップグレードできます。

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

WebLogicドメイン内のいずれかのJRFコンポーネントを更新する必要がある場合は、再構成ウィザードの後にアップグレード・アシスタントを再度実行します。

- アップグレード・アシスタントの起動
アップグレード・アシスタントを再度実行して、コンポーネント構成を12cにアップグレードします。

- アップグレード・アシスタントを使用したWebLogicドメイン・コンポーネント構成のアップグレード
アップグレード・アシスタントを起動した後、各画面を移動してWebLogicドメイン・コンポーネント構成をアップグレードできます。

4.7.1 Upgrade Assistantの起動

アップグレード・アシスタントを再度実行して、コンポーネント構成を12cにアップグレードします。

アップグレード・アシスタントを起動するには、ORACLE_HOME/oracle_common/upgrade/binディレクトリに移動し、次のコマンドを入力します。

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

./ua

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

ua.bat

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

アップグレード・アシスタントを起動した後、各画面を移動してWebLogicドメイン・コンポーネント構成をアップグレードできます。

1. アップグレード・アシスタントの導入

「ようこそ」画面には、アップグレードに進む前に考慮する重要な注意事項が含まれています。これらに目を通し、作業を進める準備が整っていることを確認します。

2. アップグレード操作の選択

管理対象WebLogic Serverドメインのコンポーネント構成をアップグレードするには、「WebLogicコンポーネント構成」を選択します。求められたら、ドメインを管理しているWebLogic Administration Serverに接続するために必要な接続詳細を入力します。

ヒント:

この画面の詳細は、『Upgrade Assistantによるアップグレード』のWebLogicコンポーネント構成に関する項を参照してください。

3. アップグレード対象のコンポーネントの確認

「コンポーネント・リスト」画面には、アップグレード対象のコンポーネントが表示されます。

4. 前提条件の検証

「前提条件」画面には、先に進む前に確認が必要な項目がリストされます。

続行する前にボックスを確認してください。Upgrade Assistantでは前提条件が満たされていることを確認できません。

5. アップグレードの検証の完了

「調査」画面では、アップグレード・アシスタントにより、選択したコンポーネントをアップグレードする前に、一連の検証が実行されます。すべての検証が成功していることを確認します。

ヒント:

この画面のオプションの詳細は、『Upgrade Assistantによるアップグレード』の調査に関する項を参照してください。

6. アップグレードの開始と完了

「アップグレード・サマリー」画面で「アップグレード」をクリックし、アップグレードを開始します。「アップグレードの進行状況」の各画面には、アップグレードの進行状況に関する情報が示され、「アップグレード成功」画面にアップグレードが要約されます。

4.8 アップグレードの実行および確認

アップグレード手順がすべて完了したら、アップグレードが成功したことを確認します。

次のタスクを実行します。

- ノード・マネージャの構成および起動

- 管理サーバーの再起動

- 管理対象サーバーの起動

4.8.1 ノード・マネージャの構成および起動

ノード・マネージャを構成および起動するには、次を参照してください。

- 『Oracle WebLogic Serverのアップグレード』のノード・マネージャ構成の完了に関する項。

- 『Oracle Fusion Middlewareの管理』のノード・マネージャの起動と停止に関する項。

4.8.2 管理サーバーの再起動

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

- 管理コンソールのURL:

http://administration_server_host:administration_server_port/console

- Fusion Middleware Control:

http://administration_server_host:administration_server_port/em

注意:

アップグレード後に、11g Oracleホームではなく、新しい12c Oracleホームから管理ツールを実行する必要があります。

4.8.3 管理対象サーバーの起動

ドメイン内の管理対象サーバーを起動するには、『Oracle Data Integratorのインストールと構成』の管理対象サーバーの起動に関する項を参照してください。

5 Oracle Data Integratorスタンドアロン・エージェント環境(WebLogic Domainあり)の11gからのアップグレード

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

次の特定のアップグレード・シナリオについて説明します。

- OPMNで管理され、WebLogicドメインに登録されている11gスタンドアロン・エージェントから12c (12.2.1.1)へのアップグレード。

次の各項の手順に従って、アップグレードを実行します。

- Oracle Data Integratorスタンドアロン・エージェント(WebLogicドメインあり)のアップグレード・プロセスの理解
OPMNで管理され、WebLogicドメインに登録されているOracle Data Integratorスタンドアロン・エージェントのアップグレード・プロセスの概要を示すプロセス・フローチャートを確認します。

- Oracle Data Integratorスタンドアロン・エージェント環境(WebLogicドメインあり)のインストール
アップグレードを開始する前に、Oracle Universal Installerを使用して、OPMNで管理されWebLogicドメインに登録されているOracle Data Integratorスタンドアロン・エージェントの12cバージョンをインストールします。

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

- アップグレード前の準備状況チェックの実行
アップグレード・アシスタントを-readinessモードで実行することにより、実際にアップグレードを実行する前にアップグレードの潜在的な問題を特定できます。

- マスターおよび作業リポジトリ・スキーマのアップグレード
サーバーとプロセスを停止した後、アップグレード・アシスタントを使用してマスターおよび作業リポジトリ・スキーマをアップグレードします。

- 再構成ウィザードを使用したドメインの再構成
スキーマをアップグレードした後、再構成ウィザードを実行して、ドメイン・コンポーネント構成を12cに再構成します。

- スタンドアロン・エージェント環境(WebLogicドメインあり)のアップグレード
リポジトリ・スキーマをアップグレードした後、スタンドアロン・エージェント環境でWebLogicドメイン・コンポーネント構成をアップグレードできます。

- アップグレードの完了および確認
アップグレード手順がすべて完了したら、アップグレードが成功したことを確認します

親トピック: 11gから12c (12.2.1.1)へのOracle Data Integratorのアップグレード

5.1 Oracle Data Integratorスタンドアロン・エージェント(WebLogicドメインあり)のアップグレード・プロセスの理解

OPMNで管理され、WebLogicドメインに登録されているOracle Data Integratorスタンドアロン・エージェントのアップグレード・プロセスの概要を示すプロセス・フローチャートを確認します。

図5-1 ODIスタンドアロン・エージェント(WebLogicドメインあり)のアップグレード・プロセス・フローチャート

フローチャートの最初のタスクは、次で説明します。

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

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

この章の残りの各項では、WebLogicドメインに登録されているOracle Data Integratorスタンドアロン・エージェントのアップグレードに固有の手順について説明します。

5.2 Oracle Data Integratorスタンドアロン・エージェント環境(WebLogicドメインあり)のインストール

アップグレードを開始する前に、Oracle Universal Installerを使用して、OPMNで管理されWebLogicドメインに登録されているOracle Data Integratorスタンドアロン・エージェントの12cバージョンをインストールします。

「12c Oracle Fusion Middleware製品ディストリビューションのダウンロードとインストール」の一般情報を確認した後、『Oracle Data Integratorのインストールと構成』の手順に従ってください。

1. 「Oracle Data Integratorインストールの計画」では、Oracle Data Integratorのインストール・トポロジに関する重要な情報を理解します。
この項では、12cの重要な概念の一部を説明し、必要な製品ディストリビューションの入手場所に関する情報も提供します。WebLogicドメインに登録されているOracle Data Integratorスタンドアロン・エージェント環境の場合、Oracle Data Integratorをインストールするための前提条件として、Oracle Fusion Middleware Infrastructureも必要です。

2. 「Oracle Data Integratorのインストール」では、Oracle Data Integratorスタンドアロン・エージェント環境をインストールします。

注意:
構成ウィザードで新規の12c WebLogicドメインまたはOracle Data Integratorインストールを構成しないでください。かわりに、スキーマのアップグレード後に再構成ウィザードを使用してドメインを構成します。アップグレード中にアップグレード・アシスタントでスタンドアロン・エージェント環境の構成が行われます。

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

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

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

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_APPENDおよび_IAU_VIEWERを必ず選択します。これらを選択したときに、アップグレード・アシスタントによって自動的に作成されます。

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_HOME環境変数を設定し、$PATHに$JAVA_HOME/binを追加します。現在サポートされているJDKバージョンは、jdk1.8.0_77.です

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

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

ORACLE_HOME/oracle_common/upgrade/bin

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

ORACLE_HOME\oracle_common\upgrade\bin

4. RCUを起動します。

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

./rcu

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

rcu.bat

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

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

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

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

オプション

説明および例

ホスト名

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

examplehost.exampledomain.com

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

ポート

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

サービス名

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

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

examplehost.exampledomain.com

ユーザー名

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

パスワード

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

ロール

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

「標準」またはSYSDBA

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

オプション

説明および例

ホスト名

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

ポート

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

データベース名

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

ユーザー名

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

パスワード

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

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

オプション

説明および例

Unicodeのサポート

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

サーバー名

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

ポート

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

データベース名

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

ユーザー名

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

パスワード

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

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

オプション

説明および例

サーバー名

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

ポート

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

データベース名

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

ユーザー名

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

パスワード

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

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

8. 「コンポーネントの選択」画面で、「既存の接頭辞の選択」を選択し、ドロップダウン・メニューから既存の11gスキーマの作成に使用した接頭辞(たとえば、DEV11G)を選択します。この接頭辞は、スキーマをこのドメインで使用するために論理的にまとめてグループ化するために使用されます。

注意: デフォルトで、Common Infrastructure Services Table (prefix_STB)およびOPSS (prefix_OPSS)スキーマが選択されます(それらがまだ作成されていない場合)。

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

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

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

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

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

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

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

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

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

準備状況チェックは、既存のドメインまたはデータベース・スキーマをスキャンし、スキャンの結果が記載されたテキスト・ファイルを生成する読取り専用操作です。アップグレード前の環境に問題がある場合、アップグレードする前にこれらの問題を修正してから、準備状況チェックを再実行できます。

デフォルトで、準備状況チェック・レポート・ファイルはOracle 12cディレクトリ(ORACLE_HOME/oracle_common/upgrade/logs)に配置されます。

注意:
準備状況チェックは、システムがオンライン中に実行できます。チェックの複雑さによっては、準備状況チェックが終わるまでにしばらく時間がかかります。パフォーマンスの低下を回避するために、準備状況チェックはオフピーク時に実行することをお薦めします。

アップグレード前の環境に対して準備状況チェックを実行するには、-readinessモードでアップグレード・アシスタントを起動します。

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

ORACLE_HOME/oracle_common/upgrade/bin

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

ORACLE_HOME\oracle_common\upgrade\bin

2. Upgrade Assistantを起動します。
UNIXオペレーティング・システムの場合:

./ua -readiness

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

ua.bat -readiness

次のUNIXの例に示すように、ロギング・パラメータを使用してアップグレード・アシスタントを起動することもできます。

./ua [-logLevel log_level] [-logDir log_directory]

ここでlog_levelは次のいずれかになります。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

log_levelのデフォルト値はNOTIFICATIONです。

トラブルシューティングする場合、log_levelをTRACEに設定すると、より多くの情報がロギングされます。-logLevel TRACEが使用されると、アップグレード・アシスタントのログ・ファイルは非常に大きくなる可能性があるため、別の情報が必要ない場合は、log_level値を変更してください。

注意:
サービス表スキーマを作成していない場合、エラー・メッセージUPGAST-00328: スキーマ・バージョン・レジストリ表がこのデータベースに存在しません。これが発生した場合、アップグレード・アシスタントを実行するためにサービス表スキーマを作成する必要があります。が表示されます。
これが発生した場合、リポジトリ作成ユーティリティ(RCU)を使用して必要な12c スキーマを作成する必要があります。

表5-5 アップグレード・アシスタントの画面: 準備状況チェック

画面

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

説明

ようこそ

常時。

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

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

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

- ドメイン・ベース

常時。

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

- 「個別に選択されたスキーマ」オプションを使用すると、アップグレードする前に確認するスキーマを選択できます。

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

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

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

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

すべてのスキーマのコンポーネント・リスト

スキーマの準備状況チェックが実行されるたび。

この画面は、スキーマの準備状況チェックが実行されるたびに表示されます。これは、「すべてのスキーマのチェックを含める」オプションを使用して「個別に選択されたスキーマ」または「ドメイン・ベース」を選択する場合です。

スキーマ資格証明

常時。

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

DBAユーザー名: SYSDBAではなくFMWとしてUpgrade Assistantを実行することをお薦めします。まだFMWユーザーを作成していない場合は、「Upgrade Assistantを実行するための非SYSDBAユーザーの作成」を参照してください

準備状況サマリー

常時。

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

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

準備状況チェック

常時。

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

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

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

準備状況成功

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

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

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

デフォルトで、準備状況チェック・レポート・ファイルは次のOracle 12cディレクトリに配置されます。

ORACLE_HOME/oracle_common/upgrade/logs

5.5 マスターおよび作業リポジトリ・スキーマのアップグレード

サーバーとプロセスを停止した後、アップグレード・アシスタントを使用してマスターおよび作業リポジトリ・スキーマをアップグレードします。

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

- アップグレード・アシスタントの起動
アップグレード・アシスタントはOracle Data Integrator 11gリポジトリ・スキーマをOracle Data Integrator 12cへアップグレードします。

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

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

アップグレード・アシスタントを実行してスキーマをアップグレードする前に、管理サーバーや管理対象サーバーを含め、すべてのプロセスとサーバーをシャットダウンします。

詳細は、『Oracle Fusion Middlewareの管理』のOracle Fusion Middlewareの起動と停止に関する項を参照してください。

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

5.5.2 Upgrade Assistantの起動

アップグレード・アシスタントはOracle Data Integrator 11gリポジトリ・スキーマをOracle Data Integrator 12cへアップグレードします。

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

再定義のためのサーバーでのエディション作成の詳細は、『Oracle Fusion Middlewareのアップグレードのプランニング』のエディションベースの再定義のためのサーバーでのエディション作成に関する項を参照してください。

注意:
外部認証を使用している場合は、外部認証が内部認証に設定されていることを確認してください。詳細は、「ODIの外部認証の構成」を参照してください

必須ではありませんが、アップグレード・アシスタントを実行するには、非SYSDBAユーザーを作成することをお薦めします。非SYSDBAユーザーをまだ作成してない場合は、「非SYSDBAユーザーの作成」を参照してください。

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

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

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

ORACLE_HOME/oracle_common/upgrade/bin

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

ORACLE_HOME\oracle_common\upgrade\bin

2. Upgrade Assistantを起動します。

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

./ua

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

ua.bat

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

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

注意:

アップグレード・アシスタントは、ODIマスター・リポジトリのデータおよび構造を使用して、リポジトリがすでにアップグレード済でないかどうかを判定します。アップグレード・アシスタントは、次の状況の場合には、リポジトリがアップグレード済であることを示すメッセージを返します。

- スキーマ・バージョン・レジストリが有効な状態で、リポジトリのバージョンを保持している

- リポジトリが12cである

- リポジトリのバージョンが、アップグレード・アシスタントが使用するODI SDKのバージョン以上である

リポジトリ・カタログ情報をデバッグまたは表示するには、(ODIスキーマ/リポジトリ内ではなく)Adminユーザーに格納されているschema_version_registry表に対して次の問合せを使用します。

Oracleデータベースでは、この表の名前はSYSTEM.SCHEMA_VERSION_REGISTRY$であり、SYSTEMスキーマに格納されています。また、SYSTEM.SCHEMA_VERSION_REGISTRYというビューと、このビューを示すパブリック・シノニムSCHEMA_VERSION_REGISTRYがあります。

SELECT COMP_ID,COMP_NAME,MRC_NAME,OWNER,VERSION,STATUS,UPGRADED FROM schema_version_registry;

DB2/400オペレーティング・システムの場合、AdminユーザーはQSECOFRで、schema_version_registry表はスキーマ'NULLID'内に配置されています。

ODIコンポーネントの行は、ODIリポジトリの追跡に使用されます。

1. アップグレード・アシスタントの導入

「ようこそ」画面には、アップグレードに進む前に考慮する重要な注意事項が含まれています。これらに目を通し、作業を進める準備が整っていることを確認します。

2. アップグレード操作の選択

「スキーマ」画面で、実行するスキーマ・アップグレード操作を選択します。

- 「個別に選択されたスキーマ」では、「使用可能なコンポーネント」画面にアップグレード可能なスキーマがあるインストール済みOracle Fusion Middlewareコンポーネントのリストが表示されます。マスターおよび作業リポジトリ・スキーマをアップグレードするには、「Oracle Data Integrator」を選択します。依存スキーマは自動的に選択されることに注意してください。

- ドメインで使用されるすべてのスキーマでは、すべてのスキーマ・コンポーネントのリスト画面にアップグレードに含まれる特定のドメイン・ディレクトリ内のすべてのコンポーネントおよびスキーマが表示されます。

3. 前提条件の検証

「前提条件」画面で、アップグレードの前提条件が満たされていることを確認してチェックを外します。

続行する前にボックスを確認してください。Upgrade Assistantでは前提条件が満たされていることを確認できません。

4. データベースおよびスキーマ資格証明の指定

ODIスキーマ画面で、アップグレードするスキーマが含まれるデータベースの接続資格証明を入力して「接続」をクリックします。

5. ODIアップグレード・オプションの選択

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

次の表で、各オプションを説明します。

表5-6 ODIのオプション

オプション

説明

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

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

ODIのアップグレードを行わない場合は、『Oracle Data Integratorでの統合プロジェクトの開発』の互換性モードの使用に関する項を参照してください。

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

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

手動でのアップグレード方法の詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』を参照してください。

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

6. スーパーバイザ・アカウント資格証明の指定

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

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

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

7. ODIアップグレード・キーの選択

11gから12cへのアップグレードのみ。 「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)を持つプロジェクトが含まれている可能性があります。この場合、誤ったオブジェクトの一致によるメタデータの破損を防ぐため、そのファイルをリポジトリにインポートする際には、別のカスタム・アップグレード・キーを使用する必要があります。

8. アップグレードの検証の完了

「調査」画面では、アップグレード・アシスタントにより、選択したコンポーネントをアップグレードする前に、一連の検証が実行されます。すべての検証が成功していることを確認します。

9. アップグレードの開始と完了

「アップグレード・サマリー」画面で「アップグレード」をクリックし、アップグレードを開始します。「アップグレードの進行状況」の各画面には、アップグレードの進行状況に関する情報が示され、「アップグレード成功」画面にアップグレードが要約されます。

10. スキーマ・バージョンの確認

スキーマがアップグレードされたことを確認するには、データベース・ホストからSQL*Plusを実行し、次のコマンドを使用します。

select owner, version, status from schema_version_registry where owner = 'prefix_ODI_REPO';

prefixを、RCUで作成されたリポジトリ・スキーマのカスタム接頭辞で置き換えます。次に、例を示します。

select owner, version, status from schema_version_registry where owner = DEV1221_ODI_REPO
OWNER                          VERSION                        STATUS
------------------------------ ------------------------------ -----------
DEV1221_ODI_REPO               12.2.1.1.0                     VALID

出力で、VERSION列においてスキーマ・バージョン番号が12.2.1.1.0であることを確認します。

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

スキーマをアップグレードした後、再構成ウィザードを実行して、ドメイン・コンポーネント構成を12cに再構成します。

再構成ウィザードを実行して、WebLogic Serverドメインを再構成する場合は、ドメインのアプリケーションによって、次の項目が自動的に更新されます。

- WLSコア・インフラストラクチャ

- ドメイン・バージョン

注意:
再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。

具体的には、ドメインを再構成すると、次のようになります。

- ドメインのconfig.xmlファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンに更新されます。

- すべてのインストール済Oracle製品の再構成テンプレートは、自動的に選択されてドメインに適用されます。これらのテンプレートは、WebLogicドメインが現在のWebLogic Serverバージョンと互換性を持つために必要な再構成タスクを定義します。

- 起動スクリプトが更新されます。

注意:
ドメインの再構成プロセスを開始すると、元に戻すことはできません。再構成ウィザードを実行する前に、「ドメインのバックアップ」の説明に従ってドメインをバックアップしていることを確認してください。再構成ウィザードの実行中にエラーその他の中断が発生した場合は、バックアップの場所から元のドメイン・ディレクトリにファイルとディレクトリをコピーして、ドメインをリストアする必要があります。これは、再構成前にドメインを確実に元の状態に戻す唯一の方法です。

再構成ウィザードを使用して既存のドメインを再構成する手順に従います。ドメインの再構成に関する一般的な情報は、WebLogicドメインの再構成に関する項を参照してください。

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

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

- ODIドメインの再構成

5.6.1 ドメインのバックアップ

再構成ウィザードを実行する前に、ドメイン・ディレクトリのバックアップ・コピーを作成します。

1. コンテンツを保持するには、ソース・ドメインを別の場所にコピーします。
たとえば、C:\domains\mydomain to C:\domains\mydomain_backupにコピーします。

2. 各リモート管理対象サーバーのドメインを更新する前に、各リモート・マシンのドメイン・ディレクトリのバックアップ・コピーを作成します。

3. ドメインのバックアップしたバージョンが完全であることを確認します。

ドメインの再構成がなんらかの理由で失敗した場合は、再構成を実行する前に、すべてのファイルおよびディレクトリをバックアップ・ディレクトリから元のドメイン・ディレクトリにコピーしてドメインを完全に元の状態に戻す必要があります。

5.6.2 再構成ウィザードの起動

再構成ウィザードをグラフィカル・モードで起動する手順は次のとおりです。

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

2. コマンド・シェル(UNIXオペレーティング・システムの場合)またはコマンド・プロンプト・ウィンドウ(Windowsオペレーティング・システムの場合)を開きます。

3. エディション・ベースのデータベース・ユーザーのみ: スキーマがEBRデータベースを使用して構成されている場合、再構成ウィザードを実行する前に、手動でデフォルトのエディション名を設定する必要があります。

次のSQLコマンドを実行して、デフォルト・エディションを設定します。

ALTER DATABASE DEFAULT EDITION = edition_name;

ここで、edition_nameは、子エディションの名前です。

4. binディレクトリに移動します。

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

ORACLE_HOME/oracle_common/upgrade/bin

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

ORACLE_HOME\oracle_common\upgrade\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.6.3 ODIドメインの再構成

再構成ウィザードの各画面で、必要なアクションを実行します。下の表に示す画面は、いくつかが表示されないこともあります。また、使用する環境の設定に基づいた追加の画面を完了する必要がある場合もあります。詳細は、『Oracle WebLogic Serverのアップグレード』のWebLogicドメインの再構成に関する項を参照してください。

表5-7 再構成ウィザードの画面

再構成ウィザードの画面

説明および必要なアクション

ドメインの選択

既存のドメイン・ディレクトリの絶対パスを入力するか、「参照」をクリックしてドメイン・ディレクトリを選択します。

再構成セットアップの進行状況

再構成テンプレートの適用の進行状況が表示されます。

ドメイン・モードおよびJDK

ドメイン・モードは変更できません。

ドメインで使用するJDKを選択するか、「参照」をクリックして使用するJDKに移動します。

Oracle Fusion Middleware 12cにはJava SE 7が必要であることに注意してください。詳細は、『Oracle Fusion Middlewareのインストールのプランニング』の動作保証とシステム要件の検証に関する項を参照してください。

データベース構成タイプ

「RCUデータ」オプションを使用して、Server Table (_STB)スキーマを収集します。Repository Creation Utility (RCU)はサービス表スキーマを自動的に使用して、他の12cスキーマ資格証明を自動的にロードします。後続JDBC画面のデータを常に確認してください。

注意: 既存の11gデータ・ソースの場合、再構成では既存の値が保存されます。スキーマが12c RCUで作成された新しいデータ・ソースの場合、デフォルトの接続データは_STBスキーマから取得されます。特定のスキーマの接続データが_STBスキーマにない場合は、デフォルトの接続データが使用されます。

詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のデータベース構成タイプに関する項を参照してください。

JDBCデータ・ソース

この画面は、11gでデータベースベースのOPSSセキュリティ・ストアまたは監査データ・ストア用にカスタム・データ・ソースを作成していた場合に表示されます。

この画面では、ドメイン・ソースで定義したJDBCデータ・ソースを構成します。

このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のJDBCデータ・ソースに関する項を参照してください。

JDBCデータ・ソース・テスト

「JDBCデータ・ソース」画面で構成したデータ・ソース接続をテストします。

このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のJDBCデータ・ソースのテストに関する項を参照してください。

JDBCコンポーネント・スキーマ

各スキーマ名の横のチェック・ボックスを選択して、画面に表示された各スキーマのデータソース設定を指定します。

注意:

- アップグレードしたスキーマに、11gスキーマの詳細を指定する必要があります。それ以外については、12c (12.2.1.1)スキーマの詳細を指定します。

- このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のJDBCコンポーネント・スキーマに関する項を参照してください。

JDBCコンポーネント・スキーマ・テスト

前の画面でデータ・ソースに指定した構成をテストします。テストするスキーマ名の横のチェック・ボックスを選択し、「選択された接続のテスト(T)」をクリックします。

テストの結果は、「ステータス」列に表示されます。すべてのスキーマでテストに成功した場合、「次へ」をクリックします。

ノード・マネージャ

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

ドメインごとおよびホストごとのノード・マネージャの構成の詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャのデフォルトの構成に関する項を参照してください。

拡張構成

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

管理対象サーバー

ドメインの各管理対象サーバーに対し、リスニング・アドレスの実際のホスト名を指定する必要があります。

デフォルトのlocalhostまたはAll Local Addressesオプションは使用しないでください。

実際のホスト名を、hostname.company.comのように指定する必要があります。

サーバーのマシンへの割当て

アップグレード・プロセスの一部としてサーバーを作成した場合は、「サーバー」リスト・ボックスでサーバー名を選択して、適切なノード・マネージャ・マシンにターゲット設定します。

そうでない場合は、ドメインのアップグレード時または再構成時にこの画面で操作は必要ありません。

サーバーのクラスタへの割当て

クラスタのアップグレードのみ: クラスタをアップグレードする場合は、この画面を使用して管理対象サーバーをクラスタに割り当てます。

「サーバー」リスト・ボックスには管理対象サーバーのみが表示されます。管理サーバーは、クラスタに割り当てることができないので、リストに表示されません。

構成のサマリー

構成のサマリーを確認します。

「再構成」をクリックしてドメインを再構成するか、「戻る」をクリックして構成を変更します。

再構成の進行状況

再構成の進行状況を確認します。処理が完了したら「次へ」をクリックします。

再構成に成功しました

再構成処理の最終的なステータスを確認します。「終了(F)」をクリックして再構成ウィザードを終了します。

5.7 スタンドアロン・エージェント環境(WebLogicドメインあり)のアップグレード

リポジトリ・スキーマをアップグレードした後、スタンドアロン・エージェント環境でWebLogicドメイン・コンポーネント構成をアップグレードできます。

- アップグレード・アシスタントの起動
アップグレード・アシスタントを再度実行して、コンポーネント構成を12cにアップグレードします。

- アップグレード・アシスタントを使用したWebLogicドメイン・コンポーネント構成のアップグレード
アップグレード・アシスタントを起動した後、各画面を移動してWebLogicドメイン・コンポーネント構成をアップグレードできます。

5.7.1 Upgrade Assistantの起動

アップグレード・アシスタントを再度実行して、コンポーネント構成を12cにアップグレードします。

アップグレード・アシスタントを起動するには、ORACLE_HOME/oracle_common/upgrade/binディレクトリに移動し、次のコマンドを入力します。

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

./ua

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

ua.bat

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

アップグレード・アシスタントを起動した後、各画面を移動してWebLogicドメイン・コンポーネント構成をアップグレードできます。

1. アップグレード・アシスタントの導入

「ようこそ」画面には、アップグレードに進む前に考慮する重要な注意事項が含まれています。これらに目を通し、作業を進める準備が整っていることを確認します。

2. アップグレード操作の選択

管理対象WebLogic Serverドメインのコンポーネント構成をアップグレードするには、「WebLogicコンポーネント構成」を選択します。求められたら、ドメインを管理しているWebLogic Administration Serverに接続するために必要な接続詳細を入力します。

ヒント:

この画面の詳細は、『Upgrade Assistantによるアップグレード』のWebLogicコンポーネント構成に関する項を参照してください。

3. アップグレード対象のコンポーネントの確認

「コンポーネント・リスト」画面には、アップグレード対象のコンポーネントが表示されます。

4. 前提条件の検証

「前提条件」画面には、先に進む前に確認が必要な項目がリストされます。

続行する前にボックスを確認してください。Upgrade Assistantでは前提条件が満たされていることを確認できません。

5. アップグレードの検証の完了

「調査」画面では、アップグレード・アシスタントにより、選択したコンポーネントをアップグレードする前に、一連の検証が実行されます。すべての検証が成功していることを確認します。

ヒント:

この画面のオプションの詳細は、『Upgrade Assistantによるアップグレード』の調査に関する項を参照してください。

6. アップグレードの開始と完了

「アップグレード・サマリー」画面で「アップグレード」をクリックし、アップグレードを開始します。「アップグレードの進行状況」の各画面には、アップグレードの進行状況に関する情報が示され、「アップグレード成功」画面にアップグレードが要約されます。

5.8 アップグレードの実行および確認

アップグレード手順がすべて完了したら、アップグレードが成功したことを確認します

- ノード・マネージャの構成および起動

- 管理サーバーの再起動

- スタンドアロン・コロケート・エージェントの起動

5.8.1 ノード・マネージャの構成および起動

ノード・マネージャを構成および起動するには、次を参照してください。

- 『Oracle WebLogic Serverのアップグレード』のノード・マネージャ構成の完了に関する項。

- 『Oracle Fusion Middlewareの管理』のノード・マネージャの起動と停止に関する項。

5.8.2 管理サーバーの再起動

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

- 管理コンソールのURL:

http://administration_server_host:administration_server_port/console

- Fusion Middleware Control:

http://administration_server_host:administration_server_port/em

注意:

アップグレード後に、11g Oracleホームではなく、新しい12c Oracleホームから管理ツールを実行する必要があります。

5.8.3 スタンドアロン・コロケート・エージェントの起動

アップグレードを検証するには、WebLogicドメインにコロケートされているOracle Data Integratorスタンドアロン・エージェントを起動する必要があります。

詳細は、『Oracle Data Integratorのインストールと構成』のスタンドアロン・コロケート・エージェントのドメインの構成に関する項を参照してください。

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

『Oracle Data Integratorのアップグレード』のこの部では、Oracle Data Integratorの前の12cリリース(12.1.2、12.1.3、12.2.1など)からのアップグレードに関する情報を提供します。

- Oracle Data Integratorスタンドアロン・エージェント環境(WebLogic Domainなし)の前の12cリリースからのアップグレード
WebLogicドメインに含まれないOracle Data Integratorスタンドアロン・エージェント環境を前のOracle Fusion Middleware 12cリリースから12c (12.2.1.1)にアップグレード・アシスタントを使用してアップグレードするには、次の手順に従います。

- Oracle Data Integrator Java EEエージェント環境の前の12cリリースからのアップグレード
Oracle Data Integrator Java EEエージェント環境を前のOracle Fusion Middleware 12cリリースから12c (12.2.1.1)にアップグレード・アシスタントを使用してアップグレードするには、次の手順に従います。

- Oracle Data Integratorスタンドアロン・エージェント環境(WebLogic Domainあり)の前の12cリリースからのアップグレード
WebLogicドメインに含まれるOracle Data Integratorスタンドアロン・エージェント環境を前のOracle Fusion Middleware 12cリリースから12c (12.2.1.1)にアップグレード・アシスタントを使用してアップグレードするには、次の手順に従います。

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

WebLogicドメインに含まれないOracle Data Integratorスタンドアロン・エージェント環境を前のOracle Fusion Middleware 12cリリースから12c (12.2.1.1)にアップグレード・アシスタントを使用してアップグレードするには、次の手順に従います。

表6-1 Oracle Data Integratorスタンドアロン・エージェントのアップグレード・プロセス

タスク

説明

詳細情報

アップグレードの準備を行います。

アップグレードを開始する前に、既存のドメインをバックアップし、リポジトリをクローニングし、システムが認定された要件を満たすことを確認する必要があります。

Oracle Data Integratorのアップグレードの準備

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

- Oracle Data Integrator 12c (12.2.1.1)のインストール

- アップグレード・アシスタントを実行して、Oracle Data Integratorマスター・リポジトリおよび作業リポジトリ・スキーマをアップグレード。

- 再構成ウィザードを実行してドメインを再構成。

- アップグレード・アシスタントを再度実行して、スタンドアロン・システム・コンポーネント構成をアップグレード。

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

Oracle Data Integrator Java EEエージェント環境を前の12cリリース(12.1.2、12.1.3および12.2.1)から12c (12.2.1.1)にアップグレードする手順は、11gからアップグレードする手順とほぼ同じです。

Oracle Data Integratorスタンドアロン・エージェント環境(WebLogicドメインなし)の11gからのアップグレード

親トピック: Oracle Data Integratorの前の12cリリースからのアップグレード

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

Oracle Data Integrator Java EEエージェント環境を前のOracle Fusion Middleware 12cリリースから12c (12.2.1.1)にアップグレード・アシスタントを使用してアップグレードするには、次の手順に従います。

表7-1 Oracle Data Integrator Java EEのアップグレード・プロセス

タスク

説明

詳細情報

アップグレードの準備を行います。

アップグレードを開始する前に、既存のドメインをバックアップし、リポジトリをクローニングし、システムが認定された要件を満たすことを確認する必要があります。

Oracle Data Integratorのアップグレードの準備

Oracle WebLogic Server 12c (12.2.1.1)を新しいOracleホームにインストールします(構成はしません)。

WebLogic ServerドメインがOracle Data Integratorコンポーネントとともにアップグレードされます。

Oracle WebLogic Serverのアップグレード

Oracle Data Integrator Java EEエージェント環境のアップグレード:

- Oracle Data Integrator 12c (12.2.1.1)のインストール

- アップグレード・アシスタントを実行して、Oracle Data Integratorマスター・リポジトリおよび作業リポジトリ・スキーマをアップグレード。

- 再構成ウィザードを実行してドメインを再構成。

- (オプション)アップグレード・アシスタントを再度実行して、Oracle Java Required Files (JRF)コンポーネントをアップグレードします(必要に応じて)。

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

Oracle Data Integrator Java EEエージェント環境を前の12cリリース(12.1.2、12.1.3および12.2.1)から12c (12.2.1.1)にアップグレードする手順は、11gからアップグレードする手順とほぼ同じです。

必要な12cスキーマがすでに存在する場合は、リポジトリ作成ユーティリティ(RCU)を実行して作成する必要はありません。

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

親トピック: Oracle Data Integratorの前の12cリリースからのアップグレード

8 Oracle Data Integratorスタンドアロン・エージェント環境(WebLogic Domainあり)の前の12cリリースからのアップグレード

WebLogicドメインに含まれるOracle Data Integratorスタンドアロン・エージェント環境を前のOracle Fusion Middleware 12cリリースから12c (12.2.1.1)にアップグレード・アシスタントを使用してアップグレードするには、次の手順に従います。

表8-1 Oracle Data Integratorスタンドアロン・コロケートのアップグレード・プロセス

タスク

説明

詳細情報

アップグレードの準備を行います。

アップグレードを開始する前に、既存のドメインをバックアップし、リポジトリをクローニングし、システムが認定された要件を満たすことを確認する必要があります。

Oracle Data Integratorのアップグレードの準備

Oracle Data Integrator Java EEエージェント環境のアップグレード:

- Oracle Data Integrator 12c (12.2.1.1)のインストール

- アップグレード・アシスタントを実行して、Oracle Data Integratorマスター・リポジトリおよび作業リポジトリ・スキーマをアップグレード。

- 再構成ウィザードを実行してドメインを再構成。

- アップグレード・アシスタントを再度実行して、WebLogicドメイン・コンポーネント構成をアップグレード。

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

Oracle Data Integrator Java EEエージェント環境を前の12cリリース(12.1.2、12.1.3および12.2.1)から12c (12.2.1.1)にアップグレードする手順は、11gからアップグレードする手順とほぼ同じです。

必要な12cスキーマがすでに存在する場合は、リポジトリ作成ユーティリティ(RCU)を実行して作成する必要はありません。

Oracle Data Integratorスタンドアロン・エージェント環境(WebLogic Domainあり)の11gからのアップグレード

親トピック: Oracle Data Integratorの前の12cリリースからのアップグレード

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

『Oracle Data Integratorのアップグレード』のこの部では、アップグレードの問題のトラブルシューティングおよび高度なアップグレード構成用のオプションに関する情報を提供します。

- アップグレードのトラブルシューティング
アップグレード・プロセスが失敗した場合は、アップグレード・アシスタントを閉じて問題を修正し、アップグレード・アシスタントを再起動する必要があります。

- 高度なアップグレード・オプション
Oracle Data Integratorをアップグレードするための、追加のオプションを設定できます。

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

アップグレード・プロセスが失敗した場合は、アップグレード・アシスタントを閉じて問題を修正し、アップグレード・アシスタントを再起動する必要があります。

アップグレード・プロセスの起動後にアップグレード・プロセスが失敗した場合は、クローニングされたリポジトリを削除して、根本的な問題を修正してから、新たにクローニングしたリポジトリで起動する必要があります。失敗したアップグレード・プロセスを再起動することはできません。

トラブルシューティングの詳細は、『Upgrade Assistantによるアップグレード』のアップグレードのトラブルシューティングに関する項を参照してください。

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

アップグレード・アシスタント・ログ・ファイルに<#>, 11g interfaces are converted with errors.が含まれている場合は、アップグレード・アシスタント・ログでインタフェース名およびIDをチェックし、11gリポジトリでODI Studioを使用して問題を修正してください。インタフェース変換中のエラーは、11gインタフェースの検証の失敗(式のカッコが一致しないなど)により発生することがあります。変換エラーがある場合、結果のマッピングが不完全になることがありますが、他の変換に影響を与えることはありません。

このようなインタフェース・アップグレード・エラーが発生した場合の対処方法は次のとおりです。

- アップグレード・アシスタント・ログ・ファイルで強調表示されているインタフェースが使用されておらず、無視できる場合は、アップグレード済の12cリポジトリを引き続き使用できます。

- インタフェースを有効な12cマッピングに変換する場合は、エラーのある各インタフェースを11g環境で修正し、次の2つの方法のいずれかを使用して再変換する必要があります。

- これらのインタフェースのみエクスポートし、アップグレード済の12cリポジトリにインポートします。インポート・プロセスによって、内部的に11gインタフェースが12cマッピングにアップグレードされます。12cリポジトリへのインタフェースのインポートの詳細は、『Oracle Data Integratorの管理』を参照してください。

- 修正したインタフェースを使用してアップグレード全部を再度実行します。エラーのあるインタフェースが多数ある場合は、この方法をお薦めします。

アップグレードのパフォーマンス・エラーのトラブルシューティング

リポジトリに存在するセッションの数が、アップグレードのパフォーマンスに影響します。アップグレードのパフォーマンス向上を図るには、セッションのログをアーカイブしてパージすることをお薦めします。

親トピック: トラブルシューティングおよび高度な構成

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

Oracle Data Integratorをアップグレードするための、追加のオプションを設定できます。

これらの追加のオプションは12c (12.1.3)アップグレード・アシスタントでは表示されていましたが、12c (12.2.1.1)アップグレード・アシスタントでは非表示になっています。これらのオプションが必要な場合は、サイレント・モードで使用するレスポンス・ファイルで設定します。

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

12c (12.1.3)でのオプション名

12c (12.2.1.1)レスポンス・ファイルのオプション名

想定される値(デフォルト＝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 */

オラクルの法律上の注意点について

コピーライトについて

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

ライセンス制約の保証と結果的に生じる損害の免責

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

保証免責

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

制限付権利について

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

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

危険な用途への使用について

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

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

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

第三者のコンテンツ、製品、サービスに対する免責事項

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

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

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

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。