Oracle® Fusion Middleware

Oracle Data Integratorのアップグレード

12c (12.1.3)

E59407-01(原本部品番号:E49725-01)

2014年6月

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

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

E59407-01

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

原本主著者: Kevin Hwang

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

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

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

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

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

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

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

目次

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

はじめに

- 対象者

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

- 関連ドキュメント

- 表記規則

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

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

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

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

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

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

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

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

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

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

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

- 2.1 Java EEエージェント環境のアップグレード・ロードマップの理解

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

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

- 2.2.2 管理サーバーの起動

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

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

- 3.1 スタンドアロン・エージェントのアップグレード・プロセスの理解

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

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

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

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

- 4.1 スタンドアロン・エージェントのアップグレード・プロセスの理解

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

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

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

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

5 12.1.2から12.1.3へのOracle Data Integratorのアップグレード

- 5.1 Oracle Data Integratorスタンドアロン・エージェント環境のアップグレード

- 5.2 Oracle Data Integrator Java EEエージェント環境のアップグレード

- 5.3 Oracle Data Integratorコロケート・スタンドアロン・エージェント環境のアップグレード

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

6 既存のOracle Data Integrator 11g環境のアップグレード

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

- 6.1.1 アップグレードのプランニング

- 6.1.2 既存の11g環境のバックアップ

- 6.1.3 ODIリポジトリを含むデータベースのアップグレード

- 6.1.4 ファイルベースのセキュリティ・ストアの再関連付け

- 6.1.5 既存のマスターおよび作業リポジトリのクローニング

- 6.1.5.1 Oracle Databaseでのスキーマのクローニング・プロセス

- 6.1.5.2 MySQLデータベースでのスキーマのクローニング・プロセス

- 6.1.5.3 Microsoft SQL Serverデータベースでのスキーマのクローニング・プロセス

- 6.1.5.4 IBM DB2 Universal Databaseでのスキーマのクローニング・プロセス

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

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

- 6.1.8 アップグレードするODIリポジトリのデータベース・バックアップの作成

- 6.2 Oracle Fusion Middleware 12c製品のインストール

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

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

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

- 6.3.3 アップグレード・アシスタント画面のナビゲート

- 6.4 Java EEエージェント環境のアップグレード

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

- 6.4.2 再構成ウィザード画面のナビゲートによるドメインの再構成

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

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

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

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

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

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

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

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

A 付録

はじめに

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

対象読者

このマニュアルは、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サポートへのアクセス

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の理解
このマニュアルには重要な概念が含まれており、アップグレードを開始する前に理解することが重要となる12cの新機能について説明します。

- 『Oracle Fusion Middlewareのアップグレードのプランニング』
このマニュアルには、アップグレードのプランニングに役立つ重要な情報が含まれています。

- 『Oracle Fusion Middlewareのインストールのプランニング』
このマニュアルには、Oracle Fusion Middlewareソフトウェアの最新リリース用にシステムを準備することに関する重要な情報が含まれています。

表記規則

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

規則

意味

太字

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

イタリック体

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

固定幅フォント

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

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

この章では、Oracle Data Integratorをアップグレードする前に目を通して理解する必要がある項目をまとめています。

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

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

- 第1.2項「Oracle Data Integrator 11gとOracle Data Integrator 12cの重要な相違点」

- 第1.3項「Oracle Data Integratorの標準アップグレード・トポロジの理解」

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

サポートされている次の開始ポイントから、Oracle Data Integrator 12c (12.1.3)にアップグレードできます。

- Oracle Data Integrator 11g リリース1 (11.1.1.6.0)

- Oracle Data Integrator 11g リリース1 (11.1.1.7.0)

- Oracle Data Integrator 12c (12.1.2)

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

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

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

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

注意:

現在の開始ポイントが11.1.1.6である場合、まず11.1.1.7にアップグレードしてから12cにアップグレードすることをお薦めします。

注意:

12c (12.1.3)には、11gリリース1 (11.1.1.6.0)または11gリリース1 (11.1.1.7.0)からのアップグレードのみサポートされています。

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

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

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

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

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

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

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

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

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

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

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

12cでは、スタンドアロン・エージェントはその他のODIコンポーネントとは別のディレクトリにインストールされます。

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

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

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

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

- インタフェース

- フォルダ

- プロシージャ/KM

注意:

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

- パッケージ

- プロファイル

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

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

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

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

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

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

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

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

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

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

このトポロジのアップグレード・ロードマップおよび手順は、第2章に示しています。

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

このトポロジの図にあるすべての要素については、表1-1に説明があります。

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

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

Repository Creation Utilityを使用して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と同様)。

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

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

- Oracle Application Developer Framework (ADF)

- Oracle Web Services Manager (OWSM)

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

11g リリース1 (11.1.1.6.0)および11g リリース1 (11.1.1.7.0)では、次の(WebLogicドメインに登録されていない)スタンドアロン・エージェント構成が可能でした。

- スタンドアロンOracleインスタンスとしてのスタンドアロン・エージェント

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

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

このトポロジのアップグレード・ロードマップおよび手順は、第3章に示しています。

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

このトポロジ図の大部分の要素を表1-1に示します。

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

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

要素

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

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.3.3 WebLogicドメインに登録されたスタンドアロン・エージェントのOracle Data Integrator標準アップグレード・トポロジ

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

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

このトポロジのアップグレード・ロードマップおよび手順は、第3章に示しています。

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

このトポロジ図の大部分の要素を表1-1および表1-2に示します。

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

表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)と、マスターおよび作業リポジトリのリレーショナル・データベースで構成されます。

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

この章では、Oracle Data Integrator Java EEエージェントの11g環境をOracle Fusion Middleware 12cにアップグレードするために必要なタスクについて説明します(有効な11g開始ポイントについては第1.1項を参照)。

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

- 第2.1項「Java EEエージェント環境のアップグレード・ロードマップの理解」

- 第2.2項「アップグレードの実行および確認」

2.1 Java EEエージェント環境のアップグレード・ロードマップの理解

図2-1では、Java EEエージェント・トポロジのアップグレード・プロセスの概要を示します。

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

表2-1は、アップグレード・プロセスのフローチャート(図2-1を参照)に示されている各手順について説明しています。この表には、プロセスの各手順について、詳細情報の参照先も示されています。

表2-1 Oracle Data Integrator J2EEエージェントのアップグレード・プロセス

タスク

説明

詳細

このマニュアルの第1章に含まれるトピックの確認と理解

この章では、アップグレード・プロセスを開始する前に目を通して理解する必要がある重要な情報を示します。

第1章

アップグレードのプランニング

アップグレードをプランニングする際の重要な概念およびタスクについて理解します。

第6.1.1項

既存の11g環境のバックアップ

アップグレードを開始する前に、既存の11g環境の完全バックアップを実行します。

第6.1.2項

(必要時)サポートされているデータベース・バージョンへのリポジトリ・データベースのアップグレード

Oracle Data Integratorリポジトリは、データベース・スキーマに格納されます。スキーマをアップグレードする前に、データベースがサポート対象のバージョンであることを確認してください。

第6.1.3項

(必要時)ファイルベースのセキュリティ・ストアの再関連付け。

11g環境でファイルベースのセキュリティ・ストアを使用している場合、ファイルベースのストアをデータベースベースのリポジトリおよびOPSSスキーマに再関連付けします。

第6.1.4項

アップグレード・アシスタントの実行前に既存のマスターおよび作業リポジトリをコピー(クローニング)

クローニングされたリポジトリ・スキーマに対してリポジトリのアップグレードを実行することをお薦めします。

第6.1.5項

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

アップグレード・アシスタントはマスター・リポジトリにアタッチされるすべての作業リポジトリをアップグレードします。アップグレードを実行する前に、作業リポジトリのそれぞれが正しいマスター・リポジトリのスキーマおよびホストにアタッチされている必要があります。

第6.1.7項

アップグレードするODIスキーマのデータベース・バックアップを作成

リポジトリ・スキーマがクローン済でなく、非クローン済スキーマをアップグレードしようとしている場合は、バックアップの作成は必須です。ODIスキーマのバックアップの実行は、アップグレードに失敗し、コンテンツが破損した場合には特に重要です。バックアップによって、壊れたスキーマを削除し、アップグレードを完了するためにオリジナルを再クローニングできます。

第6.1.8項

必要なOracle Fusion Middleware 12c製品のインストールと構成

Oracle Fusion Middleware InfrastructureおよびOracle Data Integrator 12cをインストールします。

また、製品インストールの一部として、手順に従ってRCUを実行し、新規12cスキーマ(サービス表など)を作成する必要があります。

12c製品のインストールではアップグレード・アシスタントを利用できます。

第6.2項

Oracle Data Integratorマスター・リポジトリおよび作業リポジトリ・スキーマをアップグレードするためのアップグレード・アシスタントの実行

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

第6.3項

Java EE環境のアップグレード

11gスキーマのアップグレード後に、再構成ウィザードを実行して、11gドメインを再構成します。

再構成ウィザードを実行すると、Java EEエージェント環境のアップグレード・プロセスが終了します。

注意: JRFコンポーネントのアップグレードが必要な場合は、再構成ウィザードの後にアップグレード・アシスタントを再度実行してください。

第6.4項

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

アップグレードを実行して確認するには、この項のタスクを実行します。

- 第2.2.1項「ノード・マネージャの構成および起動」

- 2.2.2「管理サーバーの起動」

- 第2.2.3項「管理対象サーバーの起動」

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

ノード・マネージャを構成および起動するには、次を参照してください。

- ノード・マネージャの構成の詳細は、『Oracle WebLogic Serverのアップグレード』のノード・マネージャ構成の実行に関する項を参照してください。

- ノード・マネージャの起動の詳細は、『Oracle Fusion Middlewareの管理』のノード・マネージャの起動と停止に関する項を参照してください。

2.2.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ホームから管理ツールを実行する必要があります。

2.2.3 管理対象サーバーの起動

ドメインの管理対象サーバーの起動方法は、『Oracle Data Integratorのインストールと構成』の管理対象サーバーの起動に関する項を参照してください。

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

この章では、11g Oracle Data Integratorスタンドアロン・エージェント環境をOracle Fusion Middleware 12cにアップグレードするために必要なタスクについて説明します(有効な11g開始ポイントについては第1.1項を参照)。

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

- OPMNによって管理されていない11g リリース1 (11.1.1.6.0)または11g リリース1 (11.1.1.7.0)スタンドアロン・エージェントから12cへのアップグレード

- OPMNによって管理されている11g リリース1 (11.1.1.6.0)または11g リリース1 (11.1.1.7.0)スタンドアロン・エージェントから12cへのアップグレード

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

- 第3.1項「スタンドアロン・エージェントのアップグレード・プロセスの理解」

- 第3.2項「アップグレードの確認」

3.1 スタンドアロン・エージェントのアップグレード・プロセスの理解

図3-1では、スタンドアロン・エージェント・トポロジのアップグレード・プロセスの概要を示します。

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

表3-1は、アップグレード・プロセスのフローチャート(図3-1を参照)に示されている各手順について説明しています。この表には、プロセスの各手順について、詳細情報の参照先も示されています。

表3-1 Oracle Data Integratorスタンドアロン・エージェントのアップグレード・プロセス

タスク

説明

詳細

このマニュアルの第1章に含まれるトピックの確認と理解

この章では、アップグレード・プロセスを開始する前に目を通して理解する必要がある重要な情報を示します。

第1章

アップグレードのプランニング

アップグレードをプランニングする際の重要な概念およびタスクについて理解します。

第6.1.1項

既存の11g環境のバックアップ

アップグレードを開始する前に、既存の11g環境の完全バックアップを実行します。

第6.1.2項

(必要時)サポートされているデータベース・バージョンへのリポジトリ・データベースのアップグレード

Oracle Data Integratorリポジトリは、データベース・スキーマに格納されます。スキーマをアップグレードする前に、データベースがサポート対象のバージョンであることを確認してください。

第6.1.3項

アップグレード・アシスタントの実行前に既存のマスターおよび作業リポジトリをコピー(クローニング)

クローニングされたリポジトリ・スキーマに対してリポジトリのアップグレードを実行することをお薦めします。

第6.1.5項

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

アップグレード・アシスタントはマスター・リポジトリにアタッチされるすべての作業リポジトリをアップグレードします。アップグレードを実行する前に、作業リポジトリのそれぞれが正しい作業リポジトリのスキーマおよびホストにアタッチされている必要があります。

第6.1.7項

アップグレードするODIスキーマのデータベース・バックアップを作成

リポジトリ・スキーマがクローン済でなく、非クローン済スキーマをアップグレードしようとしている場合は、バックアップの作成は必須です。ODIスキーマのバックアップの実行は、アップグレードに失敗し、コンテンツが破損した場合には特に重要です。バックアップによって、壊れたスキーマを削除し、アップグレードを完了するためにオリジナルを再クローニングできます。

第6.1.8項

Oracle Data Integrator 12cのインストールと構成

Oracle Data Integrator 12cをインストールします。この手順には、必要なデータベース・スキーマの作成が含まれます。

ODI製品のインストールではアップグレード・アシスタントを利用できます。

第6.2項

Oracle Data Integratorマスター・リポジトリおよび作業リポジトリ・スキーマをアップグレードするためのアップグレード・アシスタントの実行

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

第6.3項

スタンドアロン・エージェントがOPMNによって管理されている場合、アップグレード・アシスタントを再度実行してOracle Data Integratorスタンドアロン・エージェントをアップグレード

この手順では、11gスタンドアロン・エージェント・インフラストラクチャを12cに構成します。

第6.5項

3.2 アップグレードの確認

この項のタスクを実行して、アップグレードが成功したことを確認します。

- 第3.2.1項「ノード・マネージャの起動」

- 3.2.2項「スタンドアロン・エージェントの起動」

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

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

3.2.2 スタンドアロン・エージェントの起動

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

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

この章では、11g Oracle Data Integratorスタンドアロン・エージェント環境をOracle Fusion Middleware 12cにアップグレードするために必要なタスクについて説明します(有効な11g開始ポイントについては第1.1項を参照)。

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

- OPMNによって管理され、WebLogicドメインに登録されている11g リリース1 (11.1.1.7.0)スタンドアロン・エージェントから12cへのアップグレード

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

- 第4.1項「スタンドアロン・エージェントのアップグレード・プロセスの理解」

- 第4.2項「アップグレードの確認」

4.1 スタンドアロン・エージェントのアップグレード・プロセスの理解

図4-1では、OPMNによって管理され、WebLogicドメインに登録されているスタンドアロン・エージェントのアップグレードに必要なタスクのロードマップを示しています。

図4-1 OPMNによって管理され、WebLogicドメインに登録されているスタンドアロン・エージェントのアップグレード・プロセス

表4-1は、アップグレード・プロセスのフローチャート(図4-1を参照)に示されている各手順について説明しています。この表には、プロセスの各手順について、詳細情報の参照先も示されています。

表4-1 Oracle Data Integratorのアップグレード・プロセス

タスク

説明

詳細

このマニュアルの第1章に含まれるトピックの確認と理解

この章では、アップグレード・プロセスを開始する前に目を通して理解する必要がある重要な情報を示します。

第1章

アップグレードのプランニング

アップグレードをプランニングする際の重要な概念およびタスクについて理解します。

第6.1.1項

既存の11g環境のバックアップ

アップグレードを開始する前に、既存の11g環境の完全バックアップを実行します。

第6.1.2項

(必要時)サポートされているデータベース・バージョンへのリポジトリ・データベースのアップグレード

Oracle Data Integratorリポジトリは、データベース・スキーマに格納されます。スキーマをアップグレードする前に、データベースがサポート対象のバージョンであることを確認してください。

第6.1.3項

アップグレード・アシスタントの実行前に既存のマスターおよび作業リポジトリをコピー(クローニング)

クローニングされたリポジトリ・スキーマに対してリポジトリのアップグレードを実行することをお薦めします。

第6.1.5項

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

アップグレード・アシスタントはマスター・リポジトリにアタッチされるすべての作業リポジトリをアップグレードします。アップグレードを実行する前に、作業リポジトリのそれぞれが正しいマスター・リポジトリのスキーマおよびホストにアタッチされている必要があります。

第6.1.7項

アップグレードするODIスキーマのデータベース・バックアップを作成

リポジトリ・スキーマがクローン済でなく、非クローン済スキーマをアップグレードしようとしている場合は、バックアップの作成は必須です。ODIスキーマのバックアップの実行は、アップグレードに失敗し、コンテンツが破損した場合には特に重要です。バックアップによって、壊れたスキーマを削除し、アップグレードを完了するためにオリジナルを再クローニングできます。

第6.1.8項

必要なOracle Fusion Middleware 12c製品のインストールと構成

Oracle Fusion Middleware InfrastructureおよびOracle Data Integrator 12cをインストールします。

12c製品のインストールではアップグレード・アシスタントを利用できます。

第6.2項

Oracle Data Integratorマスター・リポジトリおよび作業リポジトリ・スキーマをアップグレードするためのアップグレード・アシスタントの実行

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

第6.3項

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

11gスキーマのアップグレード後に、スタンドアロン・エージェント環境(WebLogicドメインあり)をアップグレードできます。

そのためのタスクは次のとおりです。

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

- アップグレード・アシスタントの実行による、管理対象WebLogicドメインのコンポーネント構成のアップグレード

第6.6項

4.2 アップグレードの確認

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

- 第4.2.1項「ノード・マネージャの構成および起動」

- 第4.2.2項「管理サーバーの再起動」

- 第4.2.3項「コロケート・スタンドアロン・エージェントの起動」

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

ノード・マネージャを構成および起動するには、次を参照してください。

- ノード・マネージャの構成の詳細は、『Oracle WebLogic Serverのアップグレード』のノード・マネージャ構成の実行に関する説明を参照してください。

- ノード・マネージャの起動の詳細は、『Oracle Fusion Middlewareの管理』のノード・マネージャの起動と停止に関する項を参照してください。

4.2.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.2.3 コロケート・スタンドアロン・エージェントの起動

アップグレードを確認するには、コロケート・スタンドアロン・エージェントを起動する必要があります。詳細は、『Oracle Data Integratorのインストールと構成』の「コロケート・スタンドアロン・エージェントのドメインの構成」を参照してください。

5 12.1.2から12.1.3へのOracle Data Integratorのアップグレード

この章では、Oracle Data Integratorの12.1.2環境を12.1.3にアップグレードするために必要なタスクについて説明します。

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

- 第5.1項「Oracle Data Integratorスタンドアロン・エージェント環境のアップグレード」

- 第5.2項「Oracle Data Integrator Java EEエージェント環境のアップグレード」

- 第5.3項「Oracle Data Integratorコロケート・スタンドアロン・エージェント環境のアップグレード」

- 第5.4項「アップグレードの確認」

5.1 Oracle Data Integratorスタンドアロン・エージェント環境のアップグレード

アップグレード・アシスタントを使用して、Oracle Data Integratorスタンドアロン・エージェント環境を12.1.2から12.1.3にアップグレードします。

Oracle Data Integratorスタンドアロン・エージェントをアップグレードするには、次の手順を実行します。

表5-1 Oracle Data Integratorスタンドアロン・エージェントのアップグレード・プロセス

タスク

説明

詳細

このマニュアルの第1章に含まれるトピックの確認と理解

この章では、アップグレード・プロセスを開始する前に目を通して理解する必要がある重要な情報を示します。

第1章

アップグレードのプランニング

アップグレードをプランニングする際の重要な概念およびタスクについて理解します。

第6.1.1項

既存の12.1.2環境のバックアップ。

アップグレードを開始する前に、既存の12.1.2環境の完全バックアップを実行します。

第6.1.2項

(必要時)サポートされているデータベース・バージョンへのリポジトリ・データベースのアップグレード。

Oracle Data Integratorリポジトリは、データベース・スキーマに格納されます。スキーマをアップグレードする前に、データベースがサポート対象のバージョンであることを確認してください。

第6.1.3項

アップグレード・アシスタントの実行前に既存のマスターおよび作業リポジトリをコピー(クローニング)

クローニングされたリポジトリ・スキーマに対してリポジトリのアップグレードを実行することをお薦めします。

第6.1.5項

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

アップグレード・アシスタントはマスター・リポジトリにアタッチされるすべての作業リポジトリをアップグレードします。アップグレードを実行する前に、作業リポジトリのそれぞれが正しい作業リポジトリのスキーマおよびホストにアタッチされている必要があります。

第6.1.7項

アップグレードするODIスキーマのデータベース・バックアップを作成

リポジトリ・スキーマがクローン済でなく、非クローン済スキーマをアップグレードしようとしている場合は、バックアップの作成は必須です。ODIスキーマのバックアップの実行は、アップグレードに失敗し、コンテンツが破損した場合には特に重要です。バックアップによって、壊れたスキーマを削除し、アップグレードを完了するためにオリジナルを再クローニングできます。

第6.1.8項

Oracle Data Integrator 12.1.3のインストールと構成。

Oracle Data Integrator 12.1.3をインストールします。この手順には、必要なデータベース・スキーマの作成が含まれます。

ODI製品のインストールではアップグレード・アシスタントを利用できます。

第6.2項

Oracle Data Integratorマスター・リポジトリおよび作業リポジトリ・スキーマをアップグレードするためのアップグレード・アシスタントの実行

アップグレード・アシスタントによって、Oracle Data Integrator 12.1.2リポジトリ・スキーマがOracle Data Integrator 12.1.3にアップグレードされます。

第6.3項

「構成のサマリー」画面で構成のサマリーを確認し、「再構成」をクリックしてドメインを再構成します。

再構成ウィザードによってドメインが再構成されます。

第6.5項

5.2 Oracle Data Integrator Java EEエージェント環境のアップグレード

アップグレード・アシスタントを使用して、Oracle Data Integrator Java EEエージェント環境を12.1.2から12.1.3にアップグレードします。

Oracle Data Integratorスタンドアロン・エージェントをアップグレードするには、次の手順を実行します。

表5-2 Oracle Data Integrator Java EEのアップグレード・プロセス

タスク

説明

詳細

このマニュアルの第1章に含まれるトピックの確認と理解

この章では、アップグレード・プロセスを開始する前に目を通して理解する必要がある重要な情報を示します。

第1章

アップグレードのプランニング

アップグレードをプランニングする際の重要な概念およびタスクについて理解します。

第6.1.1項

既存の12.1.2環境のバックアップ。

アップグレードを開始する前に、既存の12.1.2環境の完全バックアップを実行します。

第6.1.2項

(必要時)サポートされているデータベース・バージョンへのリポジトリ・データベースのアップグレード。

Oracle Data Integratorリポジトリは、データベース・スキーマに格納されます。スキーマをアップグレードする前に、データベースがサポート対象のバージョンであることを確認してください。

第6.1.3項

アップグレード・アシスタントの実行前に既存のマスターおよび作業リポジトリをコピー(クローニング)

クローニングされたリポジトリ・スキーマに対してリポジトリのアップグレードを実行することをお薦めします。

第6.1.5項

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

アップグレード・アシスタントはマスター・リポジトリにアタッチされるすべての作業リポジトリをアップグレードします。アップグレードを実行する前に、作業リポジトリのそれぞれが正しい作業リポジトリのスキーマおよびホストにアタッチされている必要があります。

第6.1.7項

アップグレードするODIスキーマのデータベース・バックアップを作成

リポジトリ・スキーマがクローン済でなく、非クローン済スキーマをアップグレードしようとしている場合は、バックアップの作成は必須です。ODIスキーマのバックアップの実行は、アップグレードに失敗し、コンテンツが破損した場合には特に重要です。バックアップによって、壊れたスキーマを削除し、アップグレードを完了するためにオリジナルを再クローニングできます。

第6.1.8項

Oracle Data Integrator 12.1.3のインストールと構成。

Oracle Data Integrator 12.1.3をインストールします。この手順には、必要なデータベース・スキーマの作成が含まれます。

ODI製品のインストールではアップグレード・アシスタントを利用できます。

第6.2項

Oracle Data Integratorマスター・リポジトリおよび作業リポジトリ・スキーマをアップグレードするためのアップグレード・アシスタントの実行

アップグレード・アシスタントによって、Oracle Data Integrator 12.1.2リポジトリ・スキーマがOracle Data Integrator 12.1.3にアップグレードされます。

第6.3項

「構成のサマリー」画面で構成のサマリーを確認し、「再構成」をクリックしてドメインを再構成します。

再構成ウィザードによってドメインが再構成されます。

第6.4項

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

アップグレード・アシスタントを使用して、Oracle Data Integratorコロケート・スタンドアロン・エージェント環境を12.1.2から12.1.3にアップグレードします。

Oracle Data Integratorコロケート・スタンドアロン・エージェントをアップグレードするには、次の手順を実行します。

表5-3 Oracle Data Integratorコロケート・スタンドアロンのアップグレード・プロセス

タスク

説明

詳細

このマニュアルの第1章に含まれるトピックの確認と理解

この章では、アップグレード・プロセスを開始する前に目を通して理解する必要がある重要な情報を示します。

第1章

アップグレードのプランニング

アップグレードをプランニングする際の重要な概念およびタスクについて理解します。

第6.1.1項

既存の12.1.2環境のバックアップ。

アップグレードを開始する前に、既存の12.1.2環境の完全バックアップを実行します。

第6.1.2項

(必要時)サポートされているデータベース・バージョンへのリポジトリ・データベースのアップグレード。

Oracle Data Integratorリポジトリは、データベース・スキーマに格納されます。スキーマをアップグレードする前に、データベースがサポート対象のバージョンであることを確認してください。

第6.1.3項

アップグレード・アシスタントの実行前に既存のマスターおよび作業リポジトリをコピー(クローニング)

クローニングされたリポジトリ・スキーマに対してリポジトリのアップグレードを実行することをお薦めします。

第6.1.5項

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

アップグレード・アシスタントはマスター・リポジトリにアタッチされるすべての作業リポジトリをアップグレードします。アップグレードを実行する前に、作業リポジトリのそれぞれが正しい作業リポジトリのスキーマおよびホストにアタッチされている必要があります。

第6.1.7項

アップグレードするODIスキーマのデータベース・バックアップを作成

リポジトリ・スキーマがクローン済でなく、非クローン済スキーマをアップグレードしようとしている場合は、バックアップの作成は必須です。ODIスキーマのバックアップの実行は、アップグレードに失敗し、コンテンツが破損した場合には特に重要です。バックアップによって、壊れたスキーマを削除し、アップグレードを完了するためにオリジナルを再クローニングできます。

第6.1.8項

Oracle Data Integrator 12.1.3のインストールと構成。

Oracle Data Integrator 12.1.3をインストールします。この手順には、必要なデータベース・スキーマの作成が含まれます。

ODI製品のインストールではアップグレード・アシスタントを利用できます。

第6.2項

Oracle Data Integratorマスター・リポジトリおよび作業リポジトリ・スキーマをアップグレードするためのアップグレード・アシスタントの実行

アップグレード・アシスタントによって、Oracle Data Integrator 12.1.2リポジトリ・スキーマがOracle Data Integrator 12.1.3にアップグレードされます。

第6.3項

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

11gスキーマのアップグレード後に、スタンドアロン・エージェント環境(WebLogicドメインあり)をアップグレードできます。

第6.6項

「構成のサマリー」画面で構成のサマリーを確認し、「再構成」をクリックしてドメインを再構成します。

再構成ウィザードによってドメインが再構成されます。

第6.6.1項

5.4 アップグレードの確認

- Oracle Data Integrator Java EEエージェント環境の12.1.2から12.1.3へのアップグレードを実行および確認するには、第2.2項「アップグレードの実行および確認」を参照してください。

- Oracle Data Integratorスタンドアロン・エージェント環境(WebLogicドメインなし)の12.1.2から12.1.3へのアップグレードを実行および確認するには、第3.2項「アップグレードの確認」を参照してください。

- Oracle Data Integratorスタンドアロン・エージェント環境(WebLogicドメインあり)の12.1.2から12.1.3へのアップグレードを実行および確認するには、第4.2項「アップグレードの確認」を参照してください。

6 既存のOracle Data Integrator 11g環境のアップグレード

この章では、既存のOracle Data Integrator 11g環境をOracle Data Integrator 12cにアップグレードする場合のタスクの具体的な手順について説明します(有効な11g開始ポイントについては第1.1項を参照)。

既存の11g環境を新しい11gバージョンのOracle Data Integratorにアップグレードする場合は、11gドキュメント・ライブラリの『Oracle Fusion Middlewareパッチ適用ガイド』を参照してください。

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

- 第6.1項「Oracle Data Integratorのアップグレードの準備」

- 第6.2項「Oracle Fusion Middleware 12c製品のインストール」

- 第6.3項「マスターおよび作業リポジトリ・スキーマのアップグレード」

- 第6.4項「Java EEエージェント環境のアップグレード」

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

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

- 第6.7項「アップグレードのトラブルシューティング」

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

この項では、Oracle Data Integrator 12c (12.1.3)へのアップグレードを開始する前に実行する必要がある重要なタスクを説明します。

- 第6.1.1項「アップグレードのプランニング」

- 第6.1.2項「既存の11g環境のバックアップ」

- 第6.1.3項「ODIリポジトリを含むデータベースのアップグレード」

- 第6.1.4項「ファイルベースのセキュリティ・ストアの再関連付け」

- 第6.1.5項「既存のマスターおよび作業リポジトリのクローニング」

- 第6.1.6項「作業リポジトリのJDBC URLの更新」

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

- 第6.1.8項「アップグレードするODIリポジトリのデータベース・バックアップの作成」

6.1.1 アップグレードのプランニング

始める前に、Oracle Fusion Middleware 12cへのアップグレードをプランニングおよび準備する方法の大まかな概要が記載されている『Oracle Fusion Middlewareのアップグレードのプランニング』に目を通す必要があります。

6.1.2 既存の11g環境のバックアップ

始める前に、11g環境の完全バックアップを実行する必要があります。詳細は、『Oracle Fusion Middlewareのアップグレードのプランニング』のアップグレードのためのバックアップおよびリカバリ計画に関する項を参照してください。

6.1.3 ODIリポジトリを含むデータベースのアップグレード

Oracle Data Integratorリポジトリを含むデータベースは、Oracle Fusion Middleware 12cによってサポートされている必要があります。動作保証されたデータベースの最新のリストについては、「Oracle Fusion Middlewareのサポートされるシステム構成」ページのOracle Fusion Middleware 12c (12.1.3)のシステム要件およびサポート対象プラットフォームを参照してください。

OracleデータベースがOracle Fusion Middleware 11gの要件を満たしているかどうかを確認する手順については、『Oracle Fusion Middlewareのアップグレードのプランニング』の「12c (12.1.3)のためのOracle Databaseアップグレードおよび準備」を参照してください。関連情報として、データベース独自のアップグレードに関するドキュメントを参照することをお薦めします。

注意:

使用していたデータベースがOracle Data Integrator 11gでサポートされていたが、Oracle Data Integrator 12cでサポートされなくなった場合は、アップグレードする前にODI 11gバージョンで、次の手順を実行します。

1. サポートされていないデータベース・システム/バージョンからODI 11gリポジトリをエクスポートします。

2. サポート対象のデータベース・システム/バージョンに、新しい11gバージョンのリポジトリを作成し、マスターおよび作業リポジトリをインポートします。

詳細は、『Oracle Data Integrator開発者ガイド』のリポジトリレベルのエクスポート/インポートに関する項を参照してください。

6.1.4 ファイルベースのセキュリティ・ストアの再関連付け

既存の11g環境でファイルベースのセキュリティ・ストアを使用している場合、アップグレード・プロセスを開始する前に、次のタスクを実行する必要があります。

タスク1   11g OPSSおよびIAUスキーマの作成

11g Repository Creation Utilityを使用して、サポートされているDatabaseで新しい11g Oracle Platform Security Services (OPSS)および監査スキーマ(IAU)のスキーマを作成します。

11gスキーマ作成の詳細は、11gリリース1 (11.1.1.7.0)の『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』のRepository Creation Utilityの入手と実行に関する説明を参照してください。

タスク2   11gセキュリティ・ストアとデータベースベースのセキュリティ・ストアおよびOPSSスキーマとの再関連付け

11g環境でファイルベースのセキュリティ・ストアを使用している場合、ファイルベースのストアをデータベースベースのリポジトリおよびOPSSスキーマに再関連付けします。

OPSSスキーマとデータベースベースのリポジトリの再関連付けの詳細は、11gリリース1 (11.1.1.7.0)ドキュメント・ライブラリのOracle Fusion Middlewareアプリケーション・セキュリティ・ガイドのDBベースのOPSSセキュリティ・ストアの使用に関する項を参照してください。

タスク3   監査データ・ストアの構成

監査データ・ストアがファイルベースである場合、データベースで監査ロードを有効にし、監査レコードをファイルに格納する方式からデータベース監査データ・ストアを使用する方式に変更する必要があります。

監査ロードの有効化の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』の監査データ・ストアおよびバスストップ・ストレージの構成に関する項を参照してください。

6.1.5 既存のマスターおよび作業リポジトリのクローニング

アップグレード・プロセスの開始前にオリジナルのODIマスターおよび作業リポジトリのそれぞれをコピー(クローニング)することをお薦めします。マスター・リポジトリのアップグレード・プロセスの間に、アップグレード・アシスタントによって、クローニングされたマスター・リポジトリおよび作業リポジトリの場所と資格証明が要求されます。

次の項では、ODIリポジトリのホストをサポートするデータベースについて、基本的なスキーマのクローニング手順を説明します。詳細は、各データベースのドキュメントを参照してください。

- Oracle Databaseでのスキーマのクローニング・プロセス

- MySQLデータベースでのスキーマのクローニング・プロセス

- Microsoft SQL Serverデータベースでのスキーマのクローニング・プロセス

- IBM DB2 Universal Databaseでのスキーマのクローニング・プロセス

注意:

この項の目的は、アップグレード・プロセスの開始前に11gリポジトリのそれぞれをクローニング(コピー)することの重要性について強調することです。この項に記載されているクローニング手順は、11gでサポートされているデータベースごとのサンプルの手順です。これらの手順は制限なく使用できます。常に、要求に合ったクローニング手順を使用してください。

6.1.5.1 Oracle Databaseでのスキーマのクローニング・プロセス

ODI用にOracle Databaseスキーマをクローニングするには、次の手順を実行します。

1. Oracleエクスポート・ユーティリティ(exp)を使用して、ODI 11gのマスターおよび作業スキーマをエクスポートします。次に例を示します。

exp userid=odi_master_11g/odi_master_11g file=/tmp/odi_master_11g.dmp
exp userid=odi_work_11g/odi_work_11g file=/tmp/odi_work_11g.dmp
exp userid=odi_work1_11g/odi_work1_11g file=/tmp/odi_work1_11g.dmp

Datapumpユーティリティ(expdp)を使用して、ODI 11gのマスターおよび作業スキーマをエクスポートします。次に例を示します。

expdp odi_tmp/odi_tmppwd schemas=odiw11117 dumpfile=odiw11117.dmp

2. SQL*Plusを使用して、クローンのマスターおよび作業スキーマを作成し、接続権限とリソース権限を付与します。次に例を示します。

create user odi_master_11g_cp identified by odi_master_11g_cp;
create user odi_work_11g_cp identified by odi_work_11g_cp;
create user odi_work1_11g_cp identified by odi_work1_11g_cp;
grant connect,resource to odi_master_11g_cp, odi_work_11g_cp, odi_work1_11g_cp;

3. Oracleインポート(imp)を使用して、ODI 11gのマスターおよび作業スキーマ・ダンプをクローニングされたマスターおよび作業スキーマにインポートします。次に例を示します。

imp userid='system/manager' touser=odi_master_11g_cp fromuser=odi_master_11g file=/tmp/odi_master_11g.dmp
imp userid='system/manager' touser=odi_work_11g_cp fromuser=odi_work_11g file=/tmp/odi_work_11g.dmp
imp userid='system/manager' touser=odi_work1_11g_cp fromuser=odi_work1_11g file=/tmp/odi_work1_11g.dmp

Datapumpユーティリティ(impdp)を使用して、ODI 11gのマスターおよび作業スキーマをインポートします。次に例を示します。

impdp ODI_TMP/ODI_TMPPWD dumpfile=odim11117 remap_tablespace=repo11117:odi11g remap_schema=odim11117:odim1113

impdpを使用して、データ・ストレージのスキーマ名と表領域を変更することもできます。remap_xxパラメータはオプションです。

6.1.5.2 MySQLデータベースでのスキーマのクローニング・プロセス

次の手順は、MySQLデータベース・スキーマをクローニングするために使用できます。

1. mysqldumpを使用して、ODI 11gのマスターおよび作業スキーマをエクスポートします。次に例を示します。

mysqldump -h localhost -u root -p DEV_ODI_REPO > /scratch/dump.sql

2. mysqlを使用して、ODIスキーマを新しいスキーマにリストアします。次に例を示します。
最初に、クローニングされたスキーマを作成します。

mysql -h localhost -u root -p
create schema NEW_ODI_REPO default character set=utf8 default collate=utf8_bin;

その後、ODIスキーマをクローニングされたスキーマにインポートします。

mysql -h localhost -u root -p NEW_ODI_REPO < /scratch/dump.sql

3. mysqlを使用して、クローニングされたスキーマのログインを作成します。次に例を示します。

mysql -h localhost -u root -p
grant all on NEW_ODI_REPO.* to NEW_ODI_REPO1@'localhost' identified by 'password';
grant process on *.* to NEW_ODI_REPO1@'localhost'

6.1.5.3 Microsoft SQL Serverデータベースでのスキーマのクローニング・プロセス

Microsoft SQL 2005/2008データベース・スキーマをクローニングするには、次の手順を実行します。

1. SQL Management Studioを使用して、ODI 11gのマスターおよび作業スキーマをエクスポートします。
次に例を示します。

BACKUP DATABASE [odi_11g] TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\odi_11g.bak' WITH INIT, NOSKIP;

2. SQL Management Studioを使用して、マスターおよび作業スキーマを新しいデータベースでリストアします。
SQL Management Studio Expressを使用して、次の手順を実行します。

1. マスターおよび作業スキーマをリストアします。

2. データベースを格納するために使用するファイルの論理名を出力します。

3. データベースを格納するために使用するファイルを移動します。

次に例を示します。

RESTORE DATABASE [odi_11g_cp] FROM DISK = N'C:\Program Files\Microsoft SQL
Server\MSSQL.1\MSSQL\Backup\odi_11g.bak'
WITH FILE = 1, MOVE N'odi_11g' TO N'C:\Program Files\Microsoft SQL
Server\MSSQL.1\MSSQL\DATA\odi_11g_cp.mdf',
MOVE N'odi_11g_log' TO N'C:\Program Files\Microsoft SQL
Server\MSSQL.1\MSSQL\DATA\odi_11g_cp_log.ldf', NOUNLOAD;
go

3. SQL Management Studioを使用して、クローニングされたマスターおよび作業スキーマ用のログインとユーザーを作成します。
SQL Management Studio Expressを使用して、クローニングされたマスターおよび作業スキーマにアクセスするログインとユーザーを作成します。SQL Management Studio Expressで適切なデータベース・インスタンスを選択します。これらのコマンドが選択したデータベース・インスタンスに適用されます。

次に例を示します。

create login odi_11g_cp with password=N'odi_11g_cp',
default_database=odi_11g_cp,  check_expiration = off, check_policy = off;
go
USE odi_11g_cp
go
create user odi_11g_cp  for login odi_11g_cp;
go
USE odi_11g_cp
go

4. 古いスキーマを新しいスキーマの場所に移動するには、次のSQLスクリプトを実行します。
注意: 次の例では古いスキーマの名前がodi_11gで、新しいスキーマの名前がodi_11g_cpです。

CREATE SCHEMA [odi_11g_cp] AUTHORIZATION odi_11g_cp
go
.
DECLARE @OldSchema AS varchar(255)
DECLARE @NewSchema AS varchar(255)
.
SET @OldSchema = 'odi_11g'
SET @NewSchema = 'odi_11g_cp'
.
DECLARE @sql AS varchar(MAX)
SET @sql = CHAR(13) + CHAR(10)
.
SELECT @sql = @sql + 'ALTER SCHEMA [' + @NewSchema + '] TRANSFER [' +
TABLE_SCHEMA + '].[' + TABLE_NAME + ']' + CHAR(13) + CHAR(10)
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = @OldSchema
.
EXEC (@sql)
go

5. スキーマの移動を完了するには、次のSQLクエリを実行します。

DROP SCHEMA [odi_11g]
go
drop user odi_11g;
go
alter user odi_11g_cp with default_schema = odi_11g_cp;
go
grant create table, create view, create procedure,create function to
odi_11g_cp;
go

6.1.5.4 IBM DB2 Universal Databaseでのスキーマのクローニング・プロセス

次のいずれかの手順を選択して、IBMのDB2 Universal Databaseスキーマをクローニングします。

- ODI 11gマスターおよび作業スキーマに対する共通のホストのクローニング・プロセス

- ODI 11gマスターおよび作業スキーマに対する異なるホストのクローニング・プロセス

注意:

データベースのページ・サイズは32768 (32K)に設定する必要があります。さらに、オペレーティング・システム・ユーザーのODI_MASTER_11G_CPおよびODI_WORK_11G_CPを手動で作成する必要があります。

6.1.5.4.1 ODI 11gマスターおよび作業スキーマに対する共通のホストのクローニング・プロセス

次の手順は、IBM DB2スキーマを同じホストまたはプラットフォームでクローニングするために使用できます。

1. コマンド・ライン・プロセッサを使用してDB2データベースを作成します。
次に例を示します。

db2 CREATE DATABASE ODI12 AUTOMATIC STORAGE YES  ON 'C:\' DBPATH ON 'C:\' USING CODESET IBM-1252 TERRITORY US COLLATE USING SYSTEM PAGESIZE 32768

2. DB2 Database Movement Toolを使用して、ODI 11gのマスターおよび作業スキーマを新しいスキーマにコピーします。
マスター・スキーマの例:

db2move ODI11G COPY -sn odi_master_11g -co TARGET_DB ODI11GCP USER db2admin USING welcome SCHEMA_MAP ((odi_master_11g,odi_master_11g_cp)) TABLESPACE_MAP ((USERSPACE1,USERSPACE1),SYS_ANY) owner odi_master_11g_cp

作業スキーマの例:

db2move ODI11G COPY -sn odi_work_11g -co TARGET_DB ODI11GCP USER db2admin USING welcome SCHEMA_MAP ((odi_work_11g,odi_work_11g_cp)) TABLESPACE_MAP ((USERSPACE1,USERSPACE1),SYS_ANY) owner odi_work_11g_cp

6.1.5.4.2 ODI 11gマスターおよび作業スキーマに対する異なるホストのクローニング・プロセス

次の手順は、IBM DB2スキーマを異なるホストまたはプラットフォームでクローニングするために使用できます。

1. DB2 Database Movement ToolおよびDDL抽出ツールを使用して、マスターおよび作業スキーマからDDLおよびデータをエクスポートします。
DB2 Database Movement Toolは、PC/IXFファイルとデータ、およびdb2move.lstファイルと表のリストを生成します。ファイルは、このツールが呼び出したフォルダに生成されます。DDL Extracting Toolは、SQL問合せによってdb2master.sqlおよびdb2work.sqlを生成し、データベース構造を再作成します。

次に例を示します。

db2move ODI11G export -sn odi_master_11g,odi_work_11g
db2look -d ODI11G -z odi_master_11g -e -o c:/db2master.sql
db2look -d ODI11G -z odi_work_11g -e -o c:/db2work.sql

2. 新しい場所にエクスポートされたファイルが転送されます。

1. PC/IXFがバイナリ・モードで転送され、db2move.lstファイルとdb2master.sqlおよびdb2work.sqlファイルがASCIIモードで転送されたことを確認します。

2. PC/IXFファイルをDB2 Database Movement Toolが配置されている場所に配置します。

3. コマンド・ライン・プロセッサを使用してDB2データベースを作成します。
次に例を示します。

db2 CREATE DATABASE ODI11G AUTOMATIC STORAGE YES  ON 'C:\' DBPATH ON 'C:\' USING CODESET IBM-1252 TERRITORY US COLLATE USING SYSTEM PAGESIZE 32768

4. コマンド・ライン・プロセッサを使用してエクスポート済のDDLを新しいデータベースにインポートします。
次に例を示します。

db2 -tvf c:/db2backup/db2master.sql
db2 -tvf c:/db2backup/db2work.sql

5. DB2 Database Movement Toolを使用してエクスポート済のデータを新しいデータベースにインポートします。
次に例を示します。

db2move ODI11G load

6. クローニングされたスキーマが完全であることを確認します。一部の表は、チェック・ペンディング状態になる場合があります(チェック制約が原因)。
set integrityコマンドを使用して通常状態に移行します。

次に例を示します。

db2 set integrity for table_name immediate checked

6.1.6 作業リポジトリの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のみのマスター・リポジトリに接続します。

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

5. 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の両方を更新します。

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

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

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

注意:

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

1. 既存のODIクライアント(アップグレード前のバージョン)を使用してODIマスター・リポジトリに接続します。
詳細は、『Oracle Data Integrator開発者ガイド』のマスター・リポジトリへの接続に関する項を参照してください。

2. 作業リポジトリが正しい作業リポジトリのスキーマおよびホストにアタッチされていることを検証します。
詳細は、『Oracle Data Integrator開発者ガイド』の作業リポジトリへの接続に関する項と作業リポジトリのアタッチおよび削除に関する項を参照してください。

6.1.8 アップグレードするODIリポジトリのデータベース・バックアップの作成

ODIマスターおよび作業リポジトリのそれぞれのバックアップを作成することをお薦めします。バックアップにより、必要時にアップグレード前の状態にリストアできます。詳細は、『Oracle Fusion Middlewareのアップグレードのプランニング』のアップグレードのバックアップ計画に関する項を参照してください。

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

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

警告:

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

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

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

6.2 Oracle Fusion Middleware 12c製品のインストール

アップグレードを開始する前に、Oracle Universal Installerを使用して、12cバージョンのOracle Fusion Middleware製品をインストールします。『Oracle Data Integratorのインストールと構成』の次の項の手順に従います。

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

2. 「Oracle Data Integratorのインストール」では、環境にあわせてOracle Data Integratorをインストールします。
必ず特定の環境に合ったインストール手順に従ってください。

3. 「Oracle Data Integratorマスター・リポジトリおよび作業リポジトリ・スキーマの作成」では、RCUを実行し、12cの新規スキーマ(サービス表スキーマなど)を作成します。

新規ドメインの構成には構成ウィザードを実行する必要はありません。アップグレード・シナリオでは、アップグレード・アシスタントによって自動的に処理されます。

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

アップグレード・アシスタントを使用してマスターおよび作業リポジトリ・スキーマをアップグレードするには、この項の手順に従います。

- 第6.3.1項「サーバーとプロセスの停止」

- 第6.3.2項「アップグレード・アシスタントの起動」

- 第6.3.3項「アップグレード・アシスタント画面のナビゲート」

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

アップグレード・アシスタントを実行してスキーマをアップグレードする前に、ドメインのすべてのサーバーおよびプロセスが停止していることを確認してください。

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

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

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

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

./ua

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

ua.bat

6.3.3 アップグレード・アシスタント画面のナビゲート

アップグレード・アシスタントを起動(第6.3.2項)した後、この項の手順に従ってアップグレード・アシスタントの各画面を移動し、製品スキーマをアップグレードします。

注意:

アップグレード・アシスタントは、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「アップグレード操作の選択」

- タスク3「コンポーネント・スキーマの選択」

- タスク4「Weblogicディレクトリの指定」

- タスク5「前提条件の確認」

- タスク6「データベースおよびスキーマ資格証明の指定」

- タスク7「ODIアップグレード・オプションの選択」

- タスク8「スーパーバイザ・アカウント資格証明の指定」

- タスク9「ODIアップグレード・キーの選択」

- タスク10「アップグレードの検証の完了」

- タスク11「アップグレードの開始と完了」

- タスク12「スキーマ・バージョンの検証」

タスク1   アップグレード・アシスタントの概要

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

タスク2   アップグレード操作の選択

「スキーマ」を選択します。次の画面でアップグレード・アシスタントにより、アップグレード可能なスキーマがリストされます。

「スキーマ」を選択すると、画面のタイトルが「スキーマ」に変わります。

タスク3   コンポーネント・スキーマの選択

「使用可能なコンポーネント」画面には、アップグレード可能なスキーマがリストされます。

マスターおよび作業リポジトリ・スキーマをアップグレードするには、「Oracle Data Integrator」を選択します。依存スキーマは自動的に選択されることに注意してください。

ヒント:

この画面の詳細は、『Upgrade Assistantによるアップグレード』の使用可能なコンポーネントに関する項を参照してください。

タスク4 Weblogicディレクトリの指定

ドメイン・ディレクトリ画面で、アップグレードするドメイン用のWebLogicディレクトリを入力します。

タスク5 前提条件の確認

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

続行する前にボックスを確認してください。アップグレード・アシスタントでは前提条件が満たされていることを確認できません。

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

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

その後、マスターおよび作業リポジトリのスキーマ・ユーザー名とパスワードを指定します。

ヒント:

この画面の詳細は、『Upgrade Assistantによるアップグレード』のスキーマの選択に関する項を参照してください。

タスク7 ODIアップグレード・オプションの選択

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

各オプションについて次の表で説明します。

オプション

説明

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

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

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

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

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

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

GUIDを使用するようにリポジトリをアップグレード

これを選択すると、リポジトリが12c完全モードに設定されます。すべてのオブジェクトが、内部IDではなく12c GUIDを使用して参照されます。

Oracle Data Integrator 12c全体で真に一意の識別スキームを利用するには、このオプションを選択しておく必要があります。

注意: このオプションは、11gリポジトリからアップグレードする場合にのみ適用されます。12.1.2リポジトリの場合、このオプションは無視され、リポジトリはアップグレード前と同じモードのままになります。

odiRef代替APIを使用するカスタム・ナレッジ・モジュールおよびプロシージャがある場合、これらは内部識別子をパラメータとみなすため(getFlexFieldValue()など)、このオプションを選択せずに、リポジトリを11g互換性モードにしておくことができます。こうしたナレッジ・モジュールおよびプロシージャを使用してオブジェクトから生成されたシナリオは、引き続き11g互換性モードで動作しますが、12c完全モードでは動作しません。11g互換性モードを使用することで、新しいodiRef代替API (GUIDをパラメータとみなすAPI)を使用するようカスタム・ナレッジ・モジュールおよびプロシージャをスムーズに遷移できます。すべてのカスタム・ナレッジ・モジュールおよびプロシージャが新しいodiRef代替APIを使用するよう変更された後で、リポジトリを12c完全モードに切り替えることができます。

アップグレード後にリポジトリを完全GUIDモードに変更するには(アップグレード中にアップグレード・アシスタントでオプションを選択していない場合)、Studioに移動し、ODIドロップダウン・メニューでオプション「リポジトリ互換性モードの切替え」を選択します。これによって、完全GUIDモードに切り替えるためのオプションが表示されます。すでにリポジトリが完全GUIDモードになっている場合、そのオプションはグレー表示されます。

12cマッピングを使用するようにインタフェースをアップグレードします - 11g SDKの互換性が失われます

この選択により、すべての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リポジトリからアップグレードする場合にのみ適用されます。12.1.2リポジトリの場合、このオプションは無視され、リポジトリはアップグレード前と同じモードのままになります。

注意: この移行が正しく機能するためには、11gリポジトリのすべてのインタフェースが有効である必要があります(11g Studioからの検証時にエラーを返さないなど)。11gインタフェースが無効である場合、アップグレード・アシスタントは12cマッピングへの移行を試行しますが、結果は保証されません。インタフェースの移行が失敗したり、例外がログ・ファイルに出力される場合があります。いずれの場合も、結果のマッピングが無効になります。スムーズにアップグレードする最良の方法は、最初に11gリポジトリのすべてのインタフェースが有効であることを確認することです。

移行中に一部の11gインタフェースで失敗があっても、アップグレード・プロセスは停止しません。すべてのインタフェースが処理されるまでアップグレードは続行されます。

AES-128暗号化アルゴリズムの使用

128ビットのキーを持つAESは機密情報に対し十分な保護を提供します。より重要度の高い機密情報を保護するには256ビットのキーを持つAESが必要です。このオプションが選択されていない場合は、AES-256暗号化が使用されます。

ヒント:

この画面の詳細は、『Upgrade Assistantによるアップグレード』のODIオプションに関する項を参照してください。

表6-1で、この画面で選択できるオプションと選択できないオプションの組合せについて説明します。

表6-1 「ODIオプション」画面で選択できる組合せ

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

GUIDを使用するようにリポジトリをアップグレード

12cマッピングを使用するようにインタフェースをアップグレード

X

X

X

これが最もよく使用される組合せで、新しい12cリポジトリの作成時に使用する構成です。この組合せでは、すべてのオブジェクトで新しいGUID識別が使用され、すべてのインタフェースが完全な12cマッピングに変換されます(OID Studioエディタで変更可能)。

X

X

この組合せでは、リポジトリはID互換性モードのままとなり、従来の数字の識別子を使用するodiRef APIが引き続き機能します。数字のIDを引数とするodiRef APIを使用するカスタム・ナレッジ・モジュールまたはプロシージャが多数ある場合は、この組合せを使用してください。

X

この選択では、リポジトリに存在するナレッジ・モジュールは保持され、新しい12cの更新で上書きされません。また、リポジトリはID互換性モードのままとなります。デフォルトのナレッジ・モジュールを変更したが、完全12cマッピングを使用する場合は、この組合せを使用してください。

X

X

この組合せでは、11gインタフェースが11g互換性マッピングに変換されます(11gインタフェースSDKを介してアクセスおよび変更可能)。これらのマッピングは、ODI Studioエディタでは読取り専用です。11gインタフェースSDKを使用するプログラムまたはスクリプトへの投資が大きい場合は、この組合せを使用してください。

X

この選択では、リポジトリはID互換性モードのままとなり、従来の数字の識別子を使用するodiRef APIが引き続き機能します。また、11gインタフェースが11g互換性マッピングに変換されます(11g SDKを介してアクセスおよび変更可能)。ただし、これらはODI Studioエディタでは読取り専用です。数字のIDを引数とするodiRef APIを使用するカスタム・ナレッジ・モジュールまたはプロシージャが多数あり、11gインタフェースSDKを使用するプログラムまたはスクリプトへの投資が大きい場合は、この組合せを使用してください。

いずれのオプションも選択しない場合、リポジトリに存在するナレッジ・モジュールは保持され、新しい12cの更新で上書きされません。これらのマッピングの読取りまたは変更を行うODI 11g SDKを使用するアプリケーションが存在するが、自身の目的でOracle提供のナレッジ・モジュールを変更していない場合は、この組合せを使用してください。

表6-2で、「ODIオプション」画面の無効な組合せについて説明します。

表6-2 「ODIオプション」画面の無効な組合せ

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

GUIDを使用するようにリポジトリをアップグレード

12cマッピングを使用するようにインタフェースをアップグレード

X

この選択では、従来の数字のIDを使用する非推奨のodiRef APIが使用されるため、ほとんどのナレッジ・モジュールは正しく機能しません。

X

X

この組合せでは、従来の数字のIDを使用する非推奨のodiRef APIが使用されるため、ほとんどのナレッジ・モジュールは正しく機能しません。

注意:

「トポロジおよびセキュリティ・メタデータのアップグレード」オプションは、他のすべてのオプションとは関係なく選択または非選択にすることができ、他のオプションには影響しません。

また、「AES-128暗号化アルゴリズムの使用」オプションは、他のすべてのオプションとは関係なく選択または非選択にすることができ、他のオプションには影響しません。

タスク8 スーパーバイザ・アカウント資格証明の指定

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

インストールされているスーパーバイザ・アカウントはSUPERVISOR (すべて大文字)です。正しいアカウント名およびパスワードについては、ODI管理者に確認してください。

ヒント:

この画面の詳細は、『Upgrade Assistantによるアップグレード』のODIスーパーバイザに関する項を参照してください。

タスク9 ODIアップグレード・キーの選択

アップグレード・キーは、リポジトリ・オブジェクトの11g IDを一意のGUIDに変換する際に使用します。

注意:

このタスクは、ODI 12.1.2からODI 12.1.3へのアップグレードには適用されません。

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

ヒント:

詳細は、『Upgrade Assistantによるアップグレード』のODIアップグレード・キーに関する項を参照してください。

タスク10 アップグレードの検証の完了

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

ヒント:

この画面のオプションの詳細は、『Upgrade Assistantによるアップグレード』の調査に関する項を参照してください。

タスク11 アップグレードの開始と完了

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

タスク12 スキーマ・バージョンの検証

スキーマがアップグレードされたことを確認するには、データベース・ホストから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 = DEV1213_ODI_REPO
OWNER                          VERSION                        STATUS
------------------------------ ------------------------------ -----------
DEV1213_ODI_REPO               12.1.3.0.0                     VALID

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

6.4 Java EEエージェント環境のアップグレード

リポジトリ・スキーマをアップグレードした後、再構成ウィザードを実行して、Java EEエージェント環境のアップグレードを完了します。

- 第6.4.1項「再構成ウィザードの起動」

- 第6.4.2項「再構成ウィザード画面のナビゲートによるドメインの再構成」

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

再構成ウィザードを起動する手順は、次のとおりです。

1. 12c Oracle Data Integratorソフトウェアがインストールされたシステムにログインします。

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

ORACLE_HOME/oracle_common/common/bin

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

ORACLE_HOME\oracle_common\common\bin

ORACLE_HOMEは、Oracle Data Integratorがインストールされている場所です。

3. 再構成ウィザードを起動します。
UNIXオペレーティング・システムの場合:

./reconfig.sh -log=log_file

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

reconfig.cmd -log=log_file

log_fileのかわりにフルパスおよびファイル名を指定します。このログ・ファイルを作成すると、再構成プロセスのトラブルシューティングが必要な場合に非常に役立ちます。

注意:

再構成ウィザードを実行すると、デフォルトのキャッシュ・ディレクトリが有効ではないことを示す、次のエラー・メッセージが表示される場合があります。

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

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

CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

6.4.2 再構成ウィザード画面のナビゲートによるドメインの再構成

この項の手順を実行して、再構成ウィザードの各画面を移動します。

- タスク1「11gドメインの選択」

- タスク2「「再構成セットアップの進行状況」の表示」

- タスク3「ドメイン・モードとJDKの選択」

- タスク4「JDBCデータ・ソースの構成」

- タスク5「JDBCデータ・ソースのテスト」

- タスク6「データベース構成タイプの選択」

- タスク7「JDBCコンポーネント・スキーマの構成」

- タスク8「ノード・マネージャの構成」

- タスク9「資格証明の構成」

- タスク10「キーストアの構成」

- タスク11「ODIサーバーの構成」

- タスク12「ドメイン再構成の完了」

タスク1   11gドメインの選択

「ドメインの選択」画面を使用して、11g Oracle Data Integratorドメインの場所へのフルパスを指定します。また、「参照」をクリックし、ファイル・マネージャのウィンドウを使用してドメインの場所を選択できます。

タスク2   「再構成セットアップの進行状況」の表示

「再構成セットアップの進行状況」画面では、再構成テンプレートの適用の進行状況が表示されます。

タスク3   ドメイン・モードとJDKの選択

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

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

注意:

Oracle Fusion Middleware 12cにはJava SE 7が必要です。詳細は、『Oracle Fusion Middlewareのインストールのプランニング』の動作保証とシステム要件の検証に関する項を参照してください。

タスク4 JDBCデータ・ソースの構成

「JDBCデータ・ソース」画面は、11gでデータベースベースのOPSSセキュリティ・ストアまたは監査データ・ストア用にカスタム・データ・ソースを作成していた場合に表示されます。

この画面では、ドメイン・ソースに定義されているJDBCデータ・ソースを構成します。

このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のJDBCデータ・ソースに関する項を参照してください。

タスク5 JDBCデータ・ソースのテスト

「JDBCデータ・ソース・テスト」画面を使用して、構成したデータ・ソース接続をテストします。

このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のJDBCデータ・ソース・テストに関する項を参照してください。

タスク6 データベース構成タイプの選択

「手動構成」を選択して「次へ」をクリックします。

まだ選択していない場合、「RCUデータ」を選択します。

ドメインに含まれるアップグレード可能スキーマのスキーマ情報を取得するためのデータベース資格証明を指定します。このオプションを選択すると、この画面のフィールドがアクティブになります。リポジトリ作成ユーティリティ(RCU)でSTBコンポーネントに指定した接続情報を使用して、各フィールドに入力します。

注意:

以前のインストールで、ODI Studioを使用してODIリポジトリを作成した場合、STBスキーマを作成する必要はありません。『Oracle Data Integratorのインストールと構成』のリポジトリ作成ユーティリティの起動に関する項を参照してください。RCUで最初にODIスキーマを選択すると、すべての依存スキーマが選択されるため、これによりODIの依存スキーマを作成します。ODIスキーマの選択を解除し、この手順からカスタムODIリポジトリ接続を指定します。

接続情報を入力した後、「RCU構成の取得」をクリックしてスキーマ情報を取得します。

詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のデータベース構成タイプに関する項を参照してください。

タスク7   JDBCコンポーネント・スキーマの構成

各スキーマ名の横のチェック・ボックスを選択して、「JDBCコンポーネント・スキーマ」画面に表示された各スキーマのデータ・ソース設定を指定します。

注意:

第6.3項でアップグレードしたスキーマに対して11gスキーマ詳細を指定する必要があります。それ以外については、12cスキーマの詳細を指定します。

このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のJDBCコンポーネント・スキーマに関する項を参照してください。

タスク8 ノード・マネージャの構成

「ノード・マネージャ」画面は、再構成するドメインで、ドメインごとのデフォルトの場所のノード・マネージャが使用されている場合にのみ表示されます。

「既存の構成を移行」を選択して、ドメインごとのデフォルトの場所の場所を指定します。

「Oracle推奨デフォルトの適用」を有効にします。

ノード・マネージャ資格証明を指定します。これは、ノード・マネージャを管理するために作成される、新しい「ユーザー」です。ノード・マネージャにより処理されるようになったコンポーネント(OHSを含む)には、起動時にパスワードが要求されます。

注意:ドメインをアップグレードしてホストごとのノード・マネージャ構成からドメインごとのノード・マネージャ構成に変更する際に、カスタム・スクリプトを使用してWebLogic Server環境を起動および停止する場合、手動でスクリプトを更新してノード・マネージャ・ホームの場所を新しいドメインベースの場所に変更する必要があります。

ノード・マネージャの構成の詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のデフォルトのノード・マネージャの構成に関する項を参照してください。

タスク9 資格証明の構成

この画面を使用して、ドメイン内の各キーの資格証明を提供します。ドメインで以前に定義された資格証明は、表にすでに含まれています。

資格証明の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のアイデンティティ、ポリシー、資格証明、キー、証明書および監査の理解に関する項を参照してください。

タスク10 キーストアの構成

「キーストア」画面を使用して、各キーストアの信頼する証明書へのパス、各キーストアの秘密鍵へのパス、秘密鍵のパスワード、および秘密鍵のアイデンティティ証明書へのパスを指定します。

信頼できる証明書、「秘密鍵」またはアイデンティティ証明書フィールドをクリックすると、フィールドの右側に参照アイコンが表示されます。このアイコンをクリックして、適切なファイルを参照します。

タスク11 ODIサーバーの構成

ODIサーバー構成画面を使用して、ドメイン内のコロケートODIエージェントを構成します。

表6-3 ODIサーバー構成画面のフィールド

フィールド

説明

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

このドロップダウン・リストから、構成するODIエージェントを選択します。

サーバー・リスニング・アドレス

このエージェントが存在するホスト・システムのホスト名またはIPアドレスを入力します。localhostを使用しないでください。

サーバー・リスニング・ポート

ODIエージェントに使用するリスニング・ポートを入力します。

スーパーバイザ名

スーパーバイザ権限を持つODIユーザー名を入力します。

スーパーバイザ・パスワード

スーパーバイザ・ユーザーのパスワードを入力します。

優先データソース

このドロップダウン・リストから、選択したODIエージェントに使用するデータソースを選択します。

タスク12 ドメイン再構成の完了

「構成のサマリー」画面で構成のサマリーを確認し、「再構成」をクリックしてドメインを再構成します。

再構成が終了したら、「終了(F)」をクリックして再構成ウィザードを終了します。

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

リポジトリ・スキーマをアップグレードした後、この項の手順に従って、スタンドアロン・エージェント(WebLogicドメインなし)環境をアップグレードします。

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

- 第6.5.2項「スタンドアロン・システム・コンポーネント構成のアップグレード」

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

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

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

./ua

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

ua.bat

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

アップグレード・アシスタントを起動した後(第6.5.1項)、この項の手順に従ってアップグレード・アシスタントの各画面を移動し、スタンドアロン・システム・コンポーネント構成をアップグレードします。

- タスク1「アップグレード・アシスタントの概要」

- タスク2「アップグレード操作の選択」

- タスク3「アップグレード対象のコンポーネントの表示」

- タスク4「前提条件の確認」

- タスク5「11gインスタンス・ディレクトリの指定」

- タスク6「ノード・マネージャの作成」

- タスク7「アップグレードの検証の完了」

- タスク8「アップグレードの開始と完了」

タスク1   アップグレード・アシスタントの概要

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

タスク2   アップグレード操作の選択

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

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

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

ヒント:

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

この画面の詳細は、『Upgrade Assistantによるアップグレード』のスタンドアロン・コンポーネントに関する項を参照してください。

タスク3   アップグレード対象のコンポーネントの表示

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

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

- Oracle Data Integrator

タスク4   前提条件の確認

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

続行する前にボックスを確認してください。アップグレード・アシスタントでは前提条件が満たされていることを確認できません。

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

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

タスク6   ノード・マネージャの作成

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

ヒント:

この画面のオプションの詳細は、『Upgrade Assistantによるアップグレード』のノード・マネージャに関する項を参照してください。

タスク7   アップグレードの検証の完了

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

ヒント:

この画面のオプションの詳細は、『Upgrade Assistantによるアップグレード』の調査に関する項を参照してください。

タスク8   アップグレードの開始と完了

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

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

リポジトリ・スキーマをアップグレードした後、この項の手順に従って、スタンドアロン・エージェント(WebLogicドメインあり)環境をアップグレードします。

- 第6.6.1項「再構成ウィザードを使用したドメインの再構成」

- 第6.6.2項「アップグレード・アシスタントの起動」

- 第6.6.3項「WebLogicドメイン・コンポーネント構成のアップグレード」

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

第6.4項の手順に従って、再構成ウィザードを使用して11gまたは12.1.2ドメインを再構成します。

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

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

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

./ua

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

ua.bat

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

アップグレード・アシスタントを起動した後(第6.6.2項)、この項の手順に従ってアップグレード・アシスタントの各画面を移動し、WebLogicドメイン・コンポーネント構成をアップグレードします。

- タスク1「アップグレード・アシスタントの概要」

- タスク2「アップグレード操作の選択」

- タスク3「アップグレード対象のコンポーネントの表示」

- タスク4「前提条件の確認」

- タスク5「アップグレードの検証の完了」

- タスク6「アップグレードの開始と完了」

タスク1   アップグレード・アシスタントの概要

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

タスク2   アップグレード操作の選択

管理対象WebLogic Serverドメインのコンポーネント構成をアップグレードするには、「WebLogicコンポーネント構成」オプションを選択します。ドメインを管理しているWebLogic Administration Serverに接続するために必要な接続詳細の入力を求められます。

ヒント:

この画面の詳細は、『Upgrade Assistantによるアップグレード』のWebLogicコンポーネント構成に関する項を参照してください。

タスク3   アップグレード対象のコンポーネントの表示

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

タスク4   前提条件の確認

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

続行する前にボックスを確認してください。アップグレード・アシスタントでは前提条件が満たされていることを確認できません。

タスク5   アップグレードの検証の完了

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

ヒント:

この画面のオプションの詳細は、『Upgrade Assistantによるアップグレード』の調査に関する項を参照してください。

タスク6   アップグレードの開始と完了

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

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

アップグレード・プロセスが失敗した場合は、アップグレード・アシスタントを閉じて問題を修正し、アップグレード・アシスタントを再起動する必要があります。

アップグレード・プロセスの起動後にアップグレード・プロセスが失敗した場合は、クローニングされたリポジトリを削除して、根本的な問題を修正してから、新たにクローニングしたリポジトリで起動する必要があります。失敗したアップグレード・プロセスを再起動することはできません。

トラブルシューティングの詳細は、『Upgrade Assistantによるアップグレード』のアップグレードのトラブルシューティングに関する項を参照してください。

アップグレード・アシスタント・ログ・ファイルに<#> 11g interfaces are converted with errors.が含まれている場合は、アップグレード・アシスタント・ログでインタフェース名およびIDをチェックし、11gリポジトリでODI Studioを使用して問題を修正してください。インタフェース変換中のエラーは、11gインタフェースの検証の失敗(式のカッコが一致しないなど)により発生することがあります。変換エラーがある場合、結果のマッピングが不完全になることがありますが、他の変換に影響を与えることはありません。

このようなインタフェース・アップグレード・エラーが発生した場合は、次の操作を実行してください。

- UAログ・ファイルで強調表示されているインタフェースが使用されておらず、無視できる場合は、アップグレード済の12cリポジトリを引き続き使用できます。

- インタフェースを有効な12cマッピングに変換する必要がある場合は、エラーのある各インタフェースを11g環境で修正し、次の2つの方法のいずれかを使用して再変換する必要があります。

- これらのインタフェースのみエクスポートし、アップグレード済の12cリポジトリにインポートします。インポート・プロセスによって、内部的に11gインタフェースが12cマッピングにアップグレードされます。

- 修正したインタフェースを使用してアップグレード全部を再度実行します。エラーのあるインタフェースが多数ある場合は、この方法をお薦めします。

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

アップグレード・アシスタント・ログ・ファイルに<#>, 11g interfaces are converted with errors.が含まれている場合は、アップグレード・アシスタント・ログでインタフェース名およびIDをチェックし、11gリポジトリでODI Studioを使用して問題を修正してください。インタフェース変換中のエラーは、11gインタフェースの検証の失敗(式のカッコが一致しないなど)により発生することがあります。変換エラーがある場合、結果のマッピングが不完全になることがありますが、他の変換に影響を与えることはありません。

このようなインタフェース・アップグレード・エラーが発生した場合の対処方法は次のとおりです。

- アップグレード・アシスタント・ログ・ファイルで強調表示されているインタフェースが使用されておらず、無視できる場合は、アップグレード済の12cリポジトリを引き続き使用できます。

- インタフェースを有効な12cマッピングに変換する場合は、エラーのある各インタフェースを11g環境で修正し、次の2つの方法のいずれかを使用して再変換する必要があります。

- これらのインタフェースのみエクスポートし、アップグレード済の12cリポジトリにインポートします。インポート・プロセスによって、内部的に11gインタフェースが12cマッピングにアップグレードされます。12cリポジトリへのインタフェースのインポートの詳細は、『Oracle Data Integratorの管理』を参照してください。

- 修正したインタフェースを使用してアップグレード全部を再度実行します。エラーのあるインタフェースが多数ある場合は、この方法をお薦めします。

A 付録

この章では、GUIDの変更の影響を受ける代替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(”ID_TABLE_PK”)

getFK(”GUID_TABLE_PK”) /* Return the Primary Table GUID */

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(”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(”DEST_I_CONNECT”)

getInfo(”DEST_ CONNECT_GUID”) /* Return the Destination connection GUID */

getInfo(”SRC_I_CONNECT”)

getInfo(”SRC _CONNECT _GUID”) /* Return the Source connection GUID */

getInfo(”DEST_I_PSCHEMA”)

getInfo(”DEST _PSCHEMA _GUID”) /* Return the Destination Physical Schema GUID */

getInfo(”SRC_I_PSCHEMA”)

getInfo(”SRC _PSCHEMA _GUID”) /* Return the Source Physical Schema GUID */

getInfo(”DEST_I_LSCHEMA”)

getInfo(”DEST _LSCHEMA _GUID”) /* Return the Destination Logical Schema GUID */

getInfo(”SRC_I_LSCHEMA”)

getInfo(”SRC _LSCHEMA _GUID”) /* Return the Source Logical Schema GUID */

getInfo(”DEST_I_TECHNO”)

getInfo(”DEST _TECHNO _GUID”) /* Return the Destination Technology GUID */

getInfo(”SRC_I_ TECHNO”)

getInfo(”SRC _ TECHNO _GUID”) /* Return the Source Technology GUID */

getLoadPlanInstance()メソッド

getLoadPlanInstance(”BATCH_ID”)

getLoadPlanInstance(”BATCH_GUID”) /* Return the batch GUID*/

getNotNullCol()メソッド

getNotNullCol(”ID”)

getNotNullCol(”GLOBAL_ID”) /* Return the Attribute GUID */

getModel()メソッド

getModel ("ID")

getModel (”GLOBAL_ID”) /* Return the Model GUID */

getPackage()メソッド

getPackage(”I_PACKAGE”)

getPackage(”PACKAGE_ GUID ") /* Return the Package GUID */

getPK()メソッド

getPK(”ID”)

getPK(”GLOBAL_ID”) /* Return the Primary Key GUID */

getPrevStepLog()メソッド

getPrevStepLog(”SESS_NO”)

getPrevStepLog(”SESS_GUID”) /* Return the Session GUID */

getSession()メソッド

getSession(”SESS_NO”)

getSession(”SESS_GUID”) /* Return the Session GUID */

getSrcTablesList()メソッド

getSrcTablesList(”I_TABLE”)

getSrcTablesList(”TABLE_ GUID”) /* Return the Source Table GUID */

getStep()メソッド

getStep(”SESS_NO”)

getStep(”SESS_GUID”) /* Return the Session GUID */

getTable()メソッド

getTable("ID")

getTable(”GLOBAL_ID”) /* Return the target Table GUID */

getTargetTable()メソッド

getTargetTable(”I_TABLE”)

getTargetTable(”TABLE_GUID”) /* Return the target table GUID */

getUser()メソッド

getUser(”I_USER”)

getUser(”USER_GUID”) /* Return the User GUID */

オラクル社の法律上の注意点について

コピーライトについて

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

商標と登録商標について

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の登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

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

保証免責

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

制限付権利

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

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）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

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

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。