Oracle® Fusion Middleware

Oracle Data Integratorのアップグレード

12c (12.2.1.0)

E72515-01(原本部品番号:E55860-03)

2016年2月

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

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

E72515-01

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

原本主著者: Carlos Subi

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

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

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

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

目次

例一覧

図一覧

表一覧

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

はじめに

- 対象者

- 関連ドキュメント

- 表記規則

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.2.1へのリポジトリ・アップグレードでオブジェクト名の一意性が検証される

- 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標準アップグレード・トポロジ

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

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

- 2.1 完全なバックアップの作成(必須)

- 2.2 テストのための本番環境のクローニング (推奨)

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

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

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

- 2.3.3 Oracle Fusion Middlewareをホストするデータベースがサポートされているかどうかの確認。

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

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

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

- 2.4.2 管理サーバー、管理対象サーバー、ノード・マネージャなどすべてのプロセスの停止

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

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

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

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

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

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

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

- 2.7 ファイルベース・ポリシー・ストアのデータベース・ベース・ポリシー・ストアへの再関連付け(必須)

- 2.7.1 11g OPSSおよびIAUスキーマの作成

- 2.7.2 11gポリシー・ストアのデータベース・ベース・ポリシー・ストアとOPSSスキーマへの再関連付け

- 2.7.3 ポリシー・ストアの再関連付けの成功の確認

- 2.8 OIDベースのセキュリティ・ストアのための12c OPSSスキーマの作成

- 2.9 セキュリティ・ストアの最新バージョンへのアップグレード

- 2.10 非SYSDBAユーザーの作成

- 2.11 強化された暗号化(AES 256)の使用

- 2.12 エディション・ベースの再定義のためのサーバー上でのエディションの作成(オプション)

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

- 2.14 12c Oracle Fusion Middleware製品ディストリビューションのダウンロードとインストール

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

- 2.16 コンポーネント固有のアップグレード・ドキュメントの検索

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

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

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

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

- 3.2.2 管理サーバーの起動

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

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

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

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

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

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

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

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

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

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

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

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

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

- 6.3 スタンドアロン・コロケート・エージェント環境を前の12cリリースからアップグレードする

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

7 既存のOracle Data Integrator環境のアップグレード

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 7.4.1.3 ドメインの再構成

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

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

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

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

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

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

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

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

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

A 代替API

例の一覧

図一覧

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

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

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

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

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

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

表一覧

- 1-1 Oracle Data Integrator Java EE標準アップグレード・トポロジの要素の説明

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

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

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

- 2-2 コンポーネント固有のアップグレード・ドキュメント

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

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

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

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

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

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

- 7-1 ODIのオプション

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

- 7-3 高度なアップグレード・オプション

- 7-4 「ODIオプション」画面で選択できる組合せ

- 7-5 「ODIオプション」画面の無効な組合せ

- A-1 新しい代替APIメソッド

はじめに

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

- 対象読者

- 関連ドキュメント

- 表記規則

対象読者

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

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

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

関連ドキュメント

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をアップグレードする前に目を通して理解する必要がある項目をまとめています。

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

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

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

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

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

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

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

- 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 12c (12.1.3)

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

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

- 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.2.1)へのアップグレードは、11gリリース1 (11.1.1.6.0)、11gリリース1 (11.1.1.7.0)または12c (12.1.3)でのみサポートされます。

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

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

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

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

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

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

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

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.2.1へのリポジトリ・アップグレードでオブジェクト名の一意性が検証される

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

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

- インタフェース

- フォルダ

- プロシージャ/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トポロジを示します。

このトポロジのアップグレード・ロードマップおよび手順は、Oracle Data Integrator Java EEエージェント環境の11gから12.2.1へのアップグレードにあります。

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

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

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

WebLogicドメイン

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

詳細は、「Oracle WebLogic Serverドメインとは」を参照してください。

管理サーバー

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

詳細は、管理サーバーとは何かに関する項を参照してください。

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.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トポロジを示します。

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

図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で管理されるスタンドアロン・エージェントに対応しています。

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

詳細は、「スタンドアロン・ドメイン」を参照してください。

1.3.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から12.2.1へのアップグレードにあります。

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

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

Upgrade Assistantを-readinessモードで実行することにより、実際にアップグレードを実行する前にアップグレードの潜在的な問題を特定できます。準備状況チェックは、システムがオンライン中に実行できます。準備状況チェックは、既存のドメインまたはデータベース・スキーマをスキャンし、スキャンの結果が記載されたテキスト・ファイルを生成する読取り専用操作です。準備状況チェックでは、スキーマが特定のドメインの一部である必要はありません。アップグレード前の環境に問題がある場合、アップグレードする前にこれらの問題を修正してから、準備状況チェックを再実行できます。

注意:
Upgrade Assistantによってのみ実行可能なアップグレード手順は、準備状況チェック機能によってチェックされます。

または、準備状況チェックを-responseモードで実行して、レスポンス・ファイルを使用してサイレント準備状況チェックを実行することもできます。

アップグレード・プロセスの調査フェーズは別の操作です。通常、調査フェーズ中に実行されるチェックより、準備状況チェックの方が徹底しています。準備状況チェックは、実際のアップグレードを開始する前に実行する読取り専用プロセスです。調査フェーズは「アップグレード」をクリックする直前に移行し、スキーマおよび構成問題に関する潜在的な問題を特定します。

注意:
準備状況チェックは、実際にアップグレードを開始する前にのみ実行する必要があります。すでにアップグレード手順を実行した場合、準備状況チェックを実行しないでください。実行しても結果が正しくない可能性があります。

注意: アップグレードを実行した際に、アップグレードの正常な実行を妨げる問題が発生した場合、バックアップを使用してアップグレード前の環境に戻し、アップグレードを再実行する必要がある場合があります。準備状況チェックを実行すると、これらの問題の一部を特定し、システムのダウンタイムが延長されることを回避できます。

アップグレード・アシスタントの準備状況チェックと、その他のアップグレード前タスクの詳細は、「Oracle Fusion Middlewareのアップグレード前チェックリスト」を参照してください。

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

アップグレード・プロセスを実行する前に、該当するタスクをすべて完了する必要があります。これを行わないと、アップグレードが失敗する場合があります。

このアップグレード前チェックリストで説明されているタスクでは、『Oracle Fusion Middleware 12cのアップグレードのプランニング』を読んで、このアップグレードの要件を理解してください。

注意:

実行する手順は、既存のシステムの構成、アップグレードするコンポーネントおよびアップグレードと構成プロセスの最後に作成する環境によって異なります。

ここで説明する共通のアップグレード前手順に加えて、コンポーネント固有のタスクを実行する必要があります。その他の手順は、コンポーネント固有のアップグレード・ドキュメントを参照してください。

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

タスク

説明

ドキュメント

アップグレード前環境の完全なバックアップを作成します。

すべてのアップグレードで必須です。

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

アップグレードに失敗した場合は、アップグレード前の環境をリストアして、アップグレードを再試行する必要があります。

完全なバックアップの作成(必須)

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

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

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

アップグレードを開始する前に、動作保証要件が変更されていないかどうか、この情報を再確認してください。

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

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

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

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

未使用データのパージ

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

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

テストのための本番環境のクローニング(推奨)

64ビットのオペレーティング・システムを実行していることを確認します。Oracle Fusion Middleware 12cのほとんどのコンポーネントには、64ビットのオペレーティング・システムが必要です。

現在32ビットのオペレーティング・システムを実行している場合にのみ必要です。

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

アップグレードの開始点によって、アップグレードする前に新しい12cスキーマの作成が必要になる場合があります。

Oracle Fusion Middleware 12cでは、既存の環境をアップグレードする前に、リポジトリ作成ユーティリティ(RCU)を使用して新しいスキーマを作成する必要があります。

アップグレード前の必要なコンポーネントの作成

ファイルベースのポリシー・ストアを使用している場合、それをデータベース・ベースのポリシー・ストアに再関連付けする必要があります。

以前の12cリリースからアップグレードする場合、この手順は必要ありません。

ファイルベースのポリシー・ストアからデータベース・ベースのポリシー・ストアへの再関連付け(必須)

OIDベースのセキュリティ・ストアを使用するときのスキーマの要件を理解します。

OIDベースのセキュリティ・ストアを使用している場合、アップグレード前に12cのOPSSスキーマを作成する必要があります。

OIDベースのセキュリティ・ストア用の12c OPSSスキーマの作成

Fusion Middlewareのすべてのセキュリティ・ストアで最高位のセキュリティ・レベルを保持することをお薦めします。

アップグレード前に既存のセキュリティ・ストアをバックアップし、セキュリティ・ストア固有の手順に従いそれらをアップグレードします。

セキュリティ・ストアの最新バージョンへのアップグレード

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

強化した暗号化(AES 256など)の使用を計画している場合にのみ必要です。アップグレード前に、JDKに必要なポリシー・ファイルを適用することをお薦めします。

強化された暗号化(AES 256)の使用

新しい非SYSDBAユーザーを作成し、アップグレードをSYS AS SYSDBAとして実行することを回避します。

fmwという名前の非SYSDBAユーザーを作成し、アップグレード・アシスタントで必要な権限のみを付与してアップグレード・アシスタントを実行することをお薦めします。

SYSDBA以外のユーザーの作成

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

この手順は、エディション・ベースの再定義(EBR)データベースを使用している場合にのみ必要です。

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

アップグレード前に、新しい12c製品をダウンロードして、新しいOracleホームにインストールします。

アップグレード前の環境内にすでに存在する製品の12c (12.2.1)バージョンをインストールします。12c (12.2.1)用にリリースされていない製品がありますが、将来のリリースで使用可能になる予定です。

12c Oracle Fusion Middleware製品ディストリビューションのダウンロードおよびインストール

製品環境に対する準備状況チェックは、アップグレード前に実行してください。

アップグレード・アシスタントを -readinessモードで実行すると、正常なアップグレードの妨げとなる問題の可能性が検出されます。

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

アップグレードを完了するためのコンポーネント固有のアップグレード・ドキュメントを使用します。

ドキュメントでは、アップグレードで必要なコンポーネント固有のタスクについて説明します。これらのタスクには、アップグレード前に実行するものと、アップグレード後に実行するものがあります。常にOracle Fusion Middlewareのアップグレード・ドキュメントを参照し、正常にアップグレードされていることを確認します。

コンポーネント固有のアップグレード・ドキュメントの検索

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

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

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

- 32ビットから64ビット・オペレーティング・システムへの移行
Oracle Fusion Middleware 12cのほとんどのコンポーネントは、64ビットのオペレーティング・システムが必要です。32ビットの環境を実行している場合は、アップグレード前に、32ビット環境を64ビット・ソフトウェア環境に移行する必要があります。

- 未使用データのパージ
アップグレード前に未使用データをパージすると、アップグレード・プロセスを最適化できます。一部のコンポーネントについては、自動パージ・スクリプトを使用でき、アップグレード前に実行して、使用されていないデータや古いデータをパージすることができます。

- アップグレード前の必要なスキーマの作成
アップグレードする前に、12cデプロイメント用の新しいスキーマを作成する必要がある場合があります。12c用として作成する必要がある追加のスキーマを確認するには、既存の環境にあるコンポーネント・スキーマとアップグレードに必要なスキーマを比較します。

- ファイルベース・ポリシー・ストアのデータベース・ベース・ポリシー・ストアへの再関連付け(必須)
Oracle Fusion Middleware 12cでは、データベース・ベースのポリシー・ストアを使用します。データベース・ベースのポリシー・ストアは、本番環境で推奨されます。ファイルベースまたはOIDベースのポリシー・ストアを使用している場合、アップグレードの前に、ストアをデータベース・ベースのストアに再関連付けする必要があります。

- OIDベースのセキュリティ・ストアのための12c OPSSスキーマの作成
LDAPベースのOPSSセキュリティ・ストアでサポートされているのは、Oracle Internet Directory (OID)のみです。LDAPベースのポリシー・ストアは、通常、本番環境で使用します。11gでOIDベースのセキュリティ・ストアを使用している場合、リポジトリ作成ユーティリティ(RCU)を使用して、新しい12cスキーマを作成する必要があります。

- セキュリティ・ストアの最新バージョンへのアップグレード
最新バージョンのOPSSセキュリティ・ストアにアップグレードすると、強化された機能と修正を利用できます。OPSSセキュリティ・ストアは、Oracle Fusion Middleware製品インストールの一部なので、アップグレード・アシスタントを使用して直接、OPSSスキーマをアップグレードできます。

- 非SYSDBAユーザーの作成
アップグレード・アシスタントを実行するには、非SYSDBAを作成することをお薦めします。この手順で作成したユーザーには、アップグレードの完了に必要な権限が付与されます。

- 強化された暗号化(AES 256)の使用
Javaプラットフォームでは、暗号化、公開鍵インフラストラクチャ、認証、安全な通信、アクセス制御など、主要なセキュリティ分野に渡る一連のAPIが定義されています。このAPIを使用すると、開発者はセキュリティ・メカニズムを簡単にアプリケーション・コードに組み込むことができます。強化された暗号化(AES 256など)を使用する予定がある場合は、アップグレードの前に、これらのポリシー・ファイルをJDKに適用することをお薦めします。

- エディション・ベースの再定義のためのサーバー上でのエディションの作成(オプション)
エディション・ベースの再定義を使用すると、アプリケーションの使用中にそのOracleデータベース・コンポーネント、たとえばPL/SQLオブジェクトやビュー、シノニムをアップグレードでき、停止時間を最小化あるいは排除することができます。

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

- 12c Oracle Fusion Middleware製品ディストリビューションのダウンロードおよびインストール
Oracle Fusion Middleware製品ディストリビューションは、Oracle Technology Network (OTN)とOracle Software Delivery Cloudでダウンロードできます。

- アップグレード前の準備状況チェックの実行
Upgrade Assistantを-readinessモードで実行すると、読取り専用のアップグレード前チェックをドメインで実行できます。問題が検出された場合は、実際にアップグレードを開始する前にそれらを修正できます。

- コンポーネント固有のアップグレード・ドキュメントの検索
コンポーネント固有のアップグレード・ドキュメントには、Oracle WebLogic Server、Oracle Fusion Middleware Infrastructure、Oracle HTTP Server、Oracle SOA Suite and Oracle Business Process Management、Oracle Webcenter、User Messaging Service、Oracle Data Integratorなど個々のコンポーネントごとのアップグレード手順と情報が記載されています。

2.1 完全なバックアップの作成(必須)

新しい12cディストリビューションのインストールと、Oracle Fusion Middleware 11gまたは12cデプロイメントのアップグレードを始める前に、Oracle Fusion Middlewareスキーマをホストしているデータベースすべてを含めて、システムに重要なすべてのファイルを必ずバックアップしてください。

詳細は、「Oracle Fusion Middleware環境のバックアップ」と「12c用のOracleデータベースのアップグレードと準備」を参照してください

2.2 テストのための本番環境のクローニング(推奨)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3.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 11gソフトウェアのインストールおよび構成に使用したものと同じユーザー・アカウントを使用する必要があります。UNIXオペレーティング・システムでは、これによって、正しい所有者とグループが新しいOracle Fusion Middleware 12cのファイルおよびディレクトリに確実に適用されます。

2.3.3 Oracle Fusion Middlewareをホストするデータベースがサポートされているかどうかの確認。

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

アップグレード時のOracle Databaseの要件を理解し、Oracle Fusion Middlewareをホストするデータベースがサポートされており、アップグレードの実行に十分な領域が用意されていることを確認しているものとします。

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

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

JDKは、Oracleホームの外部にインストールしてください。Oracle Universal Installerにより指定されたOracleホーム・ディレクトリが空であることが検証され、空のディレクトリが指定されていなければインストールは行われません。JDKをOracleホームにインストールした場合、今後の操作で問題が発生することがあります。したがって、JDKのインストール環境は、/home/oracle/products/jdkディレクトリに指定することをお薦めします。java -jarコマンドを使用して、インストーラJARファイルを実行できます。

汎用インストーラとプラットフォーム固有のインストーラの相違点の詳細は、Oracle Fusion Middlewareのダウンロード、インストールおよび構成のREADMEファイルの汎用とプラットフォーム固有のディストリビューションとの相違点の理解に関する項を参照してください。

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

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

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

Oracle Fusion Middleware 12cのほとんどのコンポーネントには、64ビットのオペレーティング・システムが必要です。32ビットの環境を実行している場合は、アップグレード前に、32ビット環境を64ビット・ソフトウェア環境に移行する必要があります。

注意:
動作保証、システム要件および相互運用性情報を確認する場合、特に32ビットまたは64ビットのシステム要件を確認するようにしてください。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で使用したものと同じディレクトリ構造を使用して、タスク3でバックアップしたファイルをリストアします。ターゲット・マシンのディレクトリ構造は、ホスト・マシンのディレクトリ構造と同じである必要があります。

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

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

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

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

2.4.2 管理サーバー、管理対象サーバー、ノード・マネージャなどすべてのプロセスの停止

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

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

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

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

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

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

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

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

- 11gドメイン・ホーム

- MW_HOME/wlserver_10.3/common/にある11g /nodemanagerディレクトリ

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

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

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

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

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

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

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

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

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

12cディストリビューションの入手、インストール・ユーザーの指定、インストールと構成のディレクトリ構造の理解などについては、『Oracle Fusion Middlewareのインストールのプランニング』を参照してください。インストールするコンポーネントの詳細は、コンポーネント固有のインストール・ガイドを参照してください。

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

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

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

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

2.5 未使用データのパージ

アップグレード前に未使用データをパージすると、アップグレード・プロセスを最適化できます。一部のコンポーネントについては、自動パージ・スクリプトを使用でき、アップグレード前に実行して、使用されていないデータや古いデータをパージすることができます。

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

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

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

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

注意:
大量のデータをパージする必要がある場合は、表のパーティション化や、その他のデータ最適化戦略の採用について検討してください。大量のデータを削除するスクリプトを使用すると、パフォーマンスに影響を与えることがあります。

「パージおよびパーティショニング方法の開発」と「データベース増分管理戦略の策定」を参照してください

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

アップグレードする前に、12cデプロイメント用の新しいスキーマを作成する必要がある場合があります。12c用として作成する必要がある追加のスキーマを確認するには、既存の環境にあるコンポーネント・スキーマとアップグレードに必要なスキーマを比較します。

コンポーネントに必要なスキーマを特定するには、コンポーネント固有のアップグレード・ガイドを参照してください。アップグレード・アシスタントは、アップグレードできるすべてのスキーマを識別し、アップグレードにすべてのスキーマを含めます。アップグレードが必要なスキーマを選択することもできます。詳細は、「アップグレード・アシスタントでアップグレードできるスキーマの識別」を参照してください。

11gからアップグレードする場合は、次の点に注意してください。

- 12c,では、11gからアップグレードする前に新しいスキーマを作成する必要があります。新しいサービス表スキーマ(prefix_STB)には、ドメイン作成時に他のOracle Fusion Middlewareコンポーネントがアクセスして使用できる基本的なスキーマ構成情報が格納されます。詳細は、「サービス表スキーマの理解」を参照してください。

注意:
サービス表スキーマを作成していない場合、エラー・メッセージ「UPGAST-00328: スキーマ・バージョンのレジストリ表はこのデータベースに存在しません。」が発生することがあります。その場合、Upgrade Assistantを実行するには、サービス表スキーマを作成する必要があります。

- 11g環境でまだOPSSスキーマを使用していない場合にも、12cでOPSSスキーマが必要です。

- 監査スキーマには、12cを実行する前に作成する必要がある2つのスキーマが追加されました。監査サービス(_IAU)をアップグレードする場合、_IAUに加えて、_IAU_APPENDおよび_IAU_VIEWERを必ず選択します。

2.7 ファイルベース・ポリシー・ストアのデータベース・ベース・ポリシー・ストアへの再関連付け(必須)

Oracle Fusion Middleware 12cでは、データベース・ベースのポリシー・ストアを使用します。データベース・ベースのポリシー・ストアは、本番環境で推奨されます。ファイルベースまたはOIDベースのポリシー・ストアを使用している場合、アップグレードの前に、ストアをデータベース・ベースのストアに再関連付けする必要があります。

ファイルベースのポリシー・ストアをデータベース・ベースのポリシー・ストアに再関連付けるには、データベースでOPSSスキーマを作成し、WebLogicサーバーにデータ・ソースを作成する必要があります。

データベース・ベースのポリシー・ストアを使用している場合、これらのタスクを実行する必要はありません。

- 11g OPSSおよびIAUスキーマの作成
Oracle Platform Security Services (OPSS)セキュリティ・ストアにデータベース・リポジトリを使用するには、まずOracle Fusion Middleware Repository Creation Utility (RCU)を使用して必要なスキーマを作成し、一部の初期データをシードする必要があります。この設定は、OPSSセキュリティ・ストアをDBベースのセキュリティ・ストアに再関連付けする前にも必要です。

- 11gポリシー・ストアとデータベース・ベースのポリシー・ストアおよびOPSSスキーマの再関連付け
OPSSセキュリティ・ストアは、システムやアプリケーションに固有のポリシー、証明資格、キーおよび監査サービスが格納されるリポジトリです。OPSSは、WebLogicサーバーで構成されているアイデンティティ・プロバイダにアイデンティティ・ストア・サービスを委譲します。追加設定なしですぐに使用できるOPSSセキュリティ・ストアはファイルベースです。データベース・ベースのセキュリティ・ストアに再関連付けする必要があります。

- ポリシー・ストアの再関連付けの成功の確認
再関連付けによって、ドメイン構成ファイルDOMAIN_HOME/config/fmwconfig/jps-config.xmlが変更されます。古いストア・プロバイダの構成は削除され、新しいストア・プロバイダの構成が挿入されて、ポリシーと資格証明情報は、ソースからターゲットのストアに移動されます。

2.7.1 11g OPSSとIAUスキーマの作成

Oracle Platform Security Services (OPSS)セキュリティ・ストアにデータベース・リポジトリを使用するには、まずOracle Fusion Middleware Repository Creation Utility (RCU)を使用して必要なスキーマを作成し、一部の初期データをシードする必要があります。この設定は、OPSSセキュリティ・ストアをDBベースのセキュリティ・ストアに再関連付けする前にも必要です。

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

11gスキーマの作成の詳細は、11gバージョンの『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』のリポジトリ作成ユーティリティの取得および実行に関する項を参照してください。

2.7.2 11gポリシー・ストアのデータベース・ベース・ポリシー・ストアとOPSSスキーマへの再関連付け

OPSSセキュリティ・ストアは、システムやアプリケーションに固有のポリシー、証明資格、キーおよび監査サービスが格納されるリポジトリです。OPSSは、WebLogicサーバーで構成されているアイデンティティ・プロバイダにアイデンティティ・ストア・サービスを委譲します。追加設定なしですぐに使用できるOPSSセキュリティ・ストアはファイルベースです。データベース・ベースのセキュリティ・ストアに再関連付けする必要があります。

11g OPSSスキーマとデータベース・ベース・リポジトリとの再関連付けの詳細は、「OPSSセキュリティ・ストアの再関連付け」を参照してください。

2.7.3 ポリシー・ストアの再関連付けの成功の確認

再関連付けによって、ドメイン構成ファイルDOMAIN_HOME/config/fmwconfig/jps-config.xmlが変更されます。古いストア・プロバイダの構成は削除され、新しいストア・プロバイダの構成が挿入されて、ポリシーと資格証明情報は、ソースからターゲットのストアに移動されます。

ポリシー・ストアの再関連付けの成功を確認する手順:

1. Enterprise Manager Fusion Middleware Controlにログインします。

2. 「ドメイン」→ 「セキュリティ」→「セキュリティ・プロバイダ構成」に移動します。

3. 「監査サービス」→「構成」をクリックします。

4. 「プロバイダ・タイプ」が「Oracle Database」に設定されていることを確認します。「プロバイダ・タイプ」に「ファイル」と表示されている場合、再関連付けは成功していません。

2.7.3.1

あるいは、jps-config.xmlファイルを確認する方法もあります。credstore.db、policystore.db、keystore.dbの各サービス・インスタンスは、props.db.1プロパティを介してデータベースを参照します。
再関連付け後、jps-config.xmlファイルには次のように表示される必要があります。

<jpsContext name="default"
<serviceInstanceRef ref="credstore.db"/>
<serviceInstanceRef ref="keystore.db"/>
<serviceInstanceRef ref="policystore.db"/>
<serviceInstanceRef ref="audit"/>
<serviceInstanceRef ref="idstore.ldap"/>
<serviceInstanceRef ref="trust"/>
<serviceInstanceRef ref="pdp.service"/>
</jpsContext>

<serviceInstance provider="policystore.provider" name="policystore.db"
<property value="DB_ORACLE" name="policystore.type"/>
<propertySetRef ref="props.db.1"/>
</serviceInstance>

<propertySet name="props.db.1">
<property value="cn=soa_domain" name="oracle.security.jps.farm.name"/>
<property value="cn=jpsroot" name="oracle.security.jps.ldap.root.name"/>
<property value="jdbc/opss" name="datasource.jndi.name"/>
</propertySet>

2.8 OIDベースのセキュリティ・ストアのための12c OPSSスキーマの作成

LDAPベースのOPSSセキュリティ・ストアでサポートされているのは、Oracle Internet Directory (OID)のみです。LDAPベースのポリシー・ストアは、通常、本番環境で使用します。11gでOIDベースのセキュリティ・ストアを使用している場合、リポジトリ作成ユーティリティ(RCU)を使用して、新しい12cスキーマを作成する必要があります。

アップグレード前に、OIDベースのセキュリティ・ストアを再関連付けする必要はありません。アップグレード・アシスタントの実行中に、OPSSスキーマを選択します。アップグレード・アシスタントは、OIDベースのセキュリティ・ストアを自動的にアップグレードします。

注意:

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

2.9 セキュリティ・ストアの最新バージョンへのアップグレード

最新バージョンのOPSSセキュリティ・ストアにアップグレードすると、強化された機能と修正を利用できます。OPSSセキュリティ・ストアは、Oracle Fusion Middleware製品インストールの一部なので、アップグレード・アシスタントを使用して直接、OPSSスキーマをアップグレードできます。

OPSSセキュリティ・ストアをアップグレードする前に、アップグレードに失敗した場合にリカバリできるようバックアップを作成することが重要です。セキュリティ・ストアのバックアップの詳細は、「OPSSセキュリティ・ストアのバックアップとリカバリ」を参照してください。

schema_name
システムに存在するOPSSスキーマのバージョンを確認するには、データベースに対して次の問合せを実行します。

SELECT VERSION, STATUS, UPGRADED
FROM SCHEMA_VERSION_REGISTRY
WHERE OWNER=’schema_name’;

ここで、schema_nameはOPSSスキーマの名前です。たとえば、DEV_OPSSなどです。

アップグレード・アシスタントを使用してOPSSスキーマをアップグレードする手順:

1. 次のコマンドを入力してアップグレード・アシスタントを起動します。
cd oracle_common/upgrade/bin

./ua

2. 左ペインで「スキーマ」を選択し、「次」をクリックします。

3. 「スキーマ」ページで「スキーマ」を選択し、「次」をクリックします。

4. 「使用可能なコンポーネント」ページで「Oracle Platform Security Services」を選択し、「次」をクリックします。

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

6. 正しいIAUおよびOPSSスキーマの詳細を慎重に入力します。

7. 左ペインで「アップグレード・サマリー」をクリックします。「アップグレード・サマリー」ページに、アップグレードするスキーマが表示されます。

8. 「アップグレード」をクリックします。「アップグレードの進行状況」ページに、アップグレードの進行状況と最終的なステータスが表示されます。
アップグレードが完了したら、「終了」をクリックしてインストーラを終了します。

すでにドメインを作成している場合は、「アップグレード・アシスタントによるスキーマのアップグレード」のトピックで使用できる手順に従ってください。

2.10 非SYSDBAユーザーの作成

アップグレード・アシスタントを実行するには、非SYSDBAを作成することをお薦めします。この手順で作成したユーザーには、アップグレードの完了に必要な権限が付与されます。

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.11 強化された暗号化(AES 256)の使用

Javaプラットフォームでは、暗号化、公開鍵インフラストラクチャ、認証、安全な通信、アクセス制御など、主要なセキュリティ分野に渡る一連のAPIが定義されています。このAPIを使用すると、開発者はセキュリティ・メカニズムを簡単にアプリケーション・コードに組み込むことができます。強化された暗号化(AES 256など)を使用する予定がある場合は、アップグレードの前に、これらのポリシー・ファイルをJDKに適用することをお薦めします。

Fusion Middleware 12cで使用されているセキュリティ・アルゴリズムには、JDK用の追加のポリシー・ファイルが必要になるものがあります。詳細は、Java暗号化アーキテクチャOracleプロバイダのドキュメントを参照してください。

アップグレードの開始前に、これらのポリシー・ファイルをJDKに適用していないと、アップグレードに失敗することがあります。その場合は、アップグレード前環境全体をリストアして、アップグレードを最初からやりなおす必要があります。

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

エディション・ベースの再定義を使用すると、アプリケーションの使用中にそのOracleデータベース・コンポーネント、たとえばPL/SQLオブジェクトやビュー、シノニムをアップグレードでき、停止時間を最小化あるいは排除することができます。

注意:
このタスクは、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.13 カスタム・ドメイン環境設定のメンテナンス

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

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

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

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

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

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

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

注意:

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

2.14 12c Oracle Fusion Middleware製品ディストリビューションのダウンロードとインストール

Oracle Fusion Middleware製品ディストリビューションは、Oracle Technology Network (OTN)とOracle Software Delivery Cloudでダウンロードできます。

ディストリビューションを取得するためにアクセスする必要のあるサイトの詳細な情報は、「Oracle Fusion Middlewareダウンロード、インストールおよび構成のReadmeファイル」ページを参照してください。

必要なソフトウェアをダウンロードしたら、ソフトウェアのインストールと構成を続行できます。

インストールを開始するには、OTN上のOracle Fusion Middleware 12c (12.2.1)のドキュメント・ライブラリのインストール、パッチおよびアップグレード共通タスク・ページを参照してください。

注意:
コンポーネント固有のディストリビューションをインストールする前に、Fusion Middleware Infrastructureディストリビューションをインストールする必要があります。

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

アップグレード・アシスタントを-readinessモードで実行すると、読取り専用のアップグレード前チェックをドメインで実行できます。問題が検出された場合は、実際にアップグレードを開始する前にそれらを修正できます。

注意:
準備状況チェックは、システムがオンライン中に実行できます。チェックの複雑さによっては、準備状況チェックが終わるまでにしばらく時間がかかります。

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

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

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

./ua -readiness

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

ua.bat -readiness

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

2.16 コンポーネント固有のアップグレード・ドキュメントの検索

コンポーネント固有のアップグレード・ドキュメントには、Oracle WebLogic Server、Oracle Fusion Middleware Infrastructure、Oracle HTTP Server、Oracle SOA Suite and Oracle Business Process Management、Oracle Webcenter、User Messaging Service、Oracle Data Integratorなど個々のコンポーネントごとのアップグレード手順と情報が記載されています。

12cアップグレードで、アップグレード固有のどのタスクを完了する必要があるか、次の表を利用して確認してください。

表2-2 コンポーネント固有のアップグレード・ドキュメント

製品領域

アップグレードする内容

使用するアップグレード・ドキュメント

Oracle WebLogic Server - スタンドアロン

既存のFusion Middleware 11gドメインによって管理されていない、またはドメインに登録されていないOracle WebLogic Server。

Oracle WebLogic Serverのアップグレード

Oracle WebLogic Server (12cではInfrastructureと呼ばれる)を使用したカスタムOracle Application Developer Frameworkアプリケーション

カスタムOracle Application Developer Frameworkアプリケーションのセットを使用してデプロイされた管理対象11g WebLogic Serverドメイン。

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

Oracle HTTP Server - 管理対象またはスタンドアロン

管理機能のためにWebLogicドメインと連携するよう構成されているOracle HTTP Serverは、管理対象サーバーです。

Oracle WebLogicドメインによって管理されていない、またはOracle WebLogicドメインに登録されていないOracle HTTP Serverは、スタンドアロン・サーバーです。

Oracle HTTP Serverのアップグレード

Oracle SOA SuiteおよびBPM

Business Process Management (BPM)、Oracle Service Bus (OSB)、Enterprise Security Services (ESS)、Managed File Transfer (MFT)、Business Activity Monitoring (BAM)およびワークフロー・インスタンス・データなどのSOA Suiteコンポーネント。

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

ユーザー・メッセージング・サービス

ユーザー・メッセージング・サービス。

Oracle User Messaging Serviceの管理

Oracle Data Integrator

Data Integrator。

Oracle Data Integratorのアップグレード

Oracle WebCenter

WebCenterスイート・コンポーネントには、コンテンツ、ポータル、サイトが含まれています。

Oracle WebCenterのアップグレード

Oracle Business Intelligence

Oracle Business Intelligenceには、BI Enterprise Edition、BI Publisher、Essbaseが含まれています。

Oracle Business Intelligenceのアップグレード

Oracle Forms

Oracle Forms。

Oracle Formsのアップグレード

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

これ以降の項では、11g Oracle Data Integrator Java EEエージェント環境をOracle Fusion Middleware 12cにアップグレードする際に必要なタスクについて説明します(有効な11gの開始ポイントについては、「Oracle Data Integratorをアップグレードする際の有効な開始ポイントの理解」を参照してください)。

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

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

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

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

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

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

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

タスク

説明

詳細

アップグレード前の環境の完全なバックアップを作成します。

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

アップグレードに失敗した場合は、アップグレード前の環境をリストアして、アップグレードを再試行する必要があります。

環境のバックアップ

アップグレード前の必須のタスクをすべて完了します。

アップグレード前に実行が必要なタスクの詳細は、Oracle Fusion Middlewareのアップグレード前チェックリストを参照してください。
これらのタスクを完了していない場合は、アップグレードに失敗する可能性があります。

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

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

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

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

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

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

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

再構成ウィザードを使用して、Java EE環境をアップグレードします。

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

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

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

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

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

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

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

- 管理サーバーの起動

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

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

- 管理サーバーの起動

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

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

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

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

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

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

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

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

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

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

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

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

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

- アップグレードの確認

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

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

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

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

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

タスク

説明

詳細

アップグレード・プロセスを確認して理解します。

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

Oracle Data Integratorアップグレードの概要

「Oracle Fusion Middlewareのアップグレード前チェックリスト」の必要なタスクをすべて完了します。

必須のアップグレード前タスクを完了しなかった場合、アップグレードが失敗することがあります。

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

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

アップグレードが失敗してスキーマが破損した場合には、クローンしたコピーから元の状態をリストアできるので、リポジトリ・スキーマのクローニングが重要です。

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

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

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

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

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

リポジトリ・スキーマをクローンしていない場合、データベースのバックアップの作成は必須です。バックアップの実行は、アップグレードに失敗し、スキーマ・コンテンツが破損した場合には特に重要です。バックアップがあれば、壊れたスキーマを削除してオリジナルを再クローニングできます。

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

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

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

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

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

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

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

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

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

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

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

4.2 アップグレードの確認

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

- ノード・マネージャを起動します。
ノード・マネージャの起動の詳細は、「ノード・マネージャの起動」を参照してください。

- スタンドアロン・エージェントの起動。
スタンドアロン・エージェントの起動の詳細は、「ノード・マネージャでのスタンドアロン・エージェントの起動」を参照してください。

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

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

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

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

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

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

- アップグレードの確認

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

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

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

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

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

タスク

説明

詳細

アップグレードの概念を確認して理解します。

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

Oracle Data Integratorアップグレードの概要

アップグレード前の必須のタスクをすべて完了します。

必須のアップグレード前タスクをすべて完了しなかった場合、アップグレードが失敗することがあります。

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

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

アップグレードが失敗してスキーマが破損した場合には、クローンしたコピーから元の状態をリストアできるので、リポジトリ・スキーマのクローニングが重要です。

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

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

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

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

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

リポジトリ・スキーマをクローンしていない場合、データベースのバックアップの作成は必須です。バックアップの実行は、アップグレードに失敗し、スキーマ・コンテンツが破損した場合には特に重要です。バックアップがあれば、壊れたスキーマを削除してオリジナルを再クローニングできます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.2 アップグレードの確認

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

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

- 管理サーバーの再起動

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

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

- 管理サーバーの再起動

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

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

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

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

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

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

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

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

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

これは、Oracle Data Integrator 12c環境をこのリリースの12cにアップグレードするために必要な作業であり、次のタスクがあります。

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

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

- スタンドアロン・コロケート・エージェント環境を前の12cリリースからアップグレードする

- アップグレードの確認

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

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

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

タスク

説明

詳細

アップグレード前の必須のタスクをすべて完了します。

すべてのアップグレードに必要です

アップグレード前に実行が必要なタスクの詳細は、Oracle Fusion Middlewareのアップグレード前チェックリストを参照してください。
これらのタスクを完了していない場合は、アップグレードに失敗する可能性があります。

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

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

アップグレードが失敗してスキーマが破損した場合には、クローンしたコピーから元の状態をリストアできるので、リポジトリ・スキーマのクローニングが重要です。

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

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

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

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

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

リポジトリ・スキーマをクローンしていない場合、データベースのバックアップの作成は必須です。バックアップの実行は、アップグレードに失敗し、スキーマ・コンテンツが破損した場合には特に重要です。バックアップがあれば、壊れたスキーマを削除してオリジナルを再クローニングできます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

タスク

説明

詳細

アップグレードの概念を確認して理解します。

アップグレード・プロセスを開始する前に、基本的なトポロジとアップグレードの要件を読んで理解してください。

Oracle Data Integratorアップグレードの概要

アップグレード前の必須のタスクをすべて完了します。

必須のアップグレード前タスクを完了しなかった場合、アップグレードが失敗することがあります。

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

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

アップグレードが失敗してスキーマが破損した場合には、クローンしたコピーから元の状態をリストアできるので、リポジトリ・スキーマのクローニングが重要です。

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

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

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

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

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

リポジトリ・スキーマをクローンしていない場合、データベースのバックアップの作成は必須です。バックアップの実行は、アップグレードに失敗し、スキーマ・コンテンツが破損した場合には特に重要です。バックアップがあれば、壊れたスキーマを削除してオリジナルを再クローニングできます。

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

Oracle WebLogic Server 12c (12.2.1)を新しいOracleホームにインストールして構成します。

Oracle Data Integratorコンポーネントをアップグレードする前に、WebLogicサーバー・ドメインをアップグレードする必要があります。

Oracle WebLogic Serverのアップグレード

Oracle Data Integrator 12c (12.2.1)のインストールと構成。

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

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

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

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

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

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

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

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

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

6.3 スタンドアロン・コロケート・エージェント環境を前の12cリリースからアップグレードする

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

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

タスク

説明

詳細

Oracle Data IntegratorとOracle Fusion Middlewareのアップグレードについて概念を確認して理解します。

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

Oracle Data Integratorアップグレードの概要

アップグレード前の必須のタスクをすべて完了します。
ODI固有のアップグレード前タスクに加えて、これらの標準的なアップグレード前タスクを完了してください。

必須のアップグレード前タスクをすべて完了しなかった場合、アップグレードが失敗することがあります。

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

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

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

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

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

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

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

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

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

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

Oracle Data Integrator 12cをインストールします。

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

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

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

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

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

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

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

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

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

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

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

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

6.4 アップグレードの確認

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

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

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

7 既存のOracle Data Integrator環境のアップグレード

この手順では、既存のOracle Data Integrator環境を、このリリースのOracle Data Integratorにアップグレードする際の具体的な手順について説明します。

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

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

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

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

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

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

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

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

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

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

注意:
「Oracle Fusion Middlewareのアップグレード前チェックリスト」で説明されているアップグレード前に必要な全タスクを完了してください

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

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

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

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

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

アップグレード・プロセスの開始前にオリジナルのODIマスターおよび作業リポジトリのそれぞれをコピー(クローニング)することをお薦めします。マスター・リポジトリのアップグレード・プロセスの間に、アップグレードするマスター・リポジトリをアップグレード・アシスタントで選択できます。

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

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

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

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

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

注意:

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

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

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

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

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

7.1.1.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パラメータはオプションです。

7.1.1.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'

7.1.1.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を使用して、次の手順を実行します。

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

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

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

例:

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

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

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

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

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

注意:

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

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

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

7.1.1.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

7.1.1.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. 新しい場所にエクスポートされたファイルが転送されます。

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

b. 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

7.1.2 作業リポジトリの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の両方を更新します。

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

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

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

注意:

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

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

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

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

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

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

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

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

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

注意:

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

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

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

7.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をインストールします。

注意:

12.1.2または12.1.3からアップグレードする場合は、Oracle Data Integratorを新しいORACLE_HOMEにインストールする必要があります。

必ず特定の環境に合ったインストール手順に従ってください。

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

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

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

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

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

- Upgrade Assistantの起動

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

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

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

詳細は、「Oracle Fusion Middlewareの起動と停止」を参照してください。

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

7.3.2 Upgrade Assistantの起動

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

注意:
アップグレード・アシスタントを起動する前に、外部認証から内部認証に戻していることを確認してください。詳細は、パスワード記憶域の切替えに関する項を参照してください。

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

./ua

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

ua.bat

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

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

注意:

アップグレード・アシスタントは、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. コンポーネント・スキーマの選択

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

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

ヒント:

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

4. WebLogicディレクトリの指定

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

5. 前提条件の検証

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

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

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

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

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

ヒント:

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

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

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

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

表7-1 ODIのオプション

オプション

説明

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

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

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

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

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

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

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

ヒント:

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

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

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

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

ヒント:

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

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

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

注意:

このタスクは、ODI 11gからODI 12.2.1へのアップグレードのみに適用されます

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 = DEV1221_ODI_REPO
OWNER                          VERSION                        STATUS
------------------------------ ------------------------------ -----------
DEV1221_ODI_REPO               12.2.1.0.0                     VALID

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

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

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

- 再構成ウィザードを使用したドメインの再構成
再構成ウィザードは、12cの新しいツールです。ドメインを12cにアップグレードするとき、アップグレード・アシスタントとともに実行します。

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

再構成ウィザードは12cの新しいツールです。ドメインを12cにアップグレードするとき、アップグレード・アシスタントとともに実行します。

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

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

- ドメイン・バージョン

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

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

- ドメインのconfig.xmlファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンのメジャーおよびマイナー・バージョン番号(たとえば、12.2.1.1)に更新されます。

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

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

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

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

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

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

- ドメインを再構成します。

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

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

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

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

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

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

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

次の手順を実行して、再構成ウィザードをグラフィカル・モードで起動します。

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

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

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

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

ALTER DATABASE DEFAULT EDITION = edition_name;

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

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

(UNIXオペレーティング・システムの場合) ORACLE_HOME/oracle_common/common/bin

(Windowsオペレーティング・システムの場合) ORACLE_HOME\oracle_common\common\bin

ORACLE_HOMEはOracleホーム・ディレクトリです。

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

(UNIX Operating Systems) ./reconfig.sh -log=<log_file> -log_priority=ALL
(Windows Operating Systems) reconfig.cmd -log=<log_file> -log_priority=ALL

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

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

注意:

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

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

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

CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

7.4.1.3 ドメインの再構成

再構成ウィザードでは表7-2 に示す一連の画面が表示されます。各画面でそれぞれの操作を実行します。次に示す画面は、いくつかが表示されないこともあります。また、使用する環境の設定に基づいた追加の画面を完了する必要がある場合もあります。詳細は、WebLogicドメインの再構成に関する項を参照してください。

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

再構成ウィザードの画面

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

ドメインの選択

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

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

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

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

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

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

Oracle Fusion Middleware 12cにはJava SE 7が必要であることに注意してください。詳細は、「動作保証要件とシステム要件の確認」を参照してください。

データベース構成タイプ

「RCUデータ」オプションを使用して、Server Table (_STB)スキーマを収集します。Repository Creation Utility (RCU)はサービス表スキーマを自動的に使用して、他の12cスキーマ資格証明を自動的にロードします。後続JDBC画面のデータを常に確認してください。

注意: 既存の11gデータ・ソースの場合、再構成では既存の値が保存されます。スキーマが12c RCUで作成された新しいデータ・ソースの場合、デフォルトの接続データは_STBスキーマから取得されます。特定のスキーマの接続データが_STBスキーマにない場合は、デフォルトの接続データが使用されます。

詳細は、「ヘルプ」をクリックするか、データベース構成タイプに関する項を参照してください。

JDBCデータ・ソース

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

この画面では、ドメイン・ソースで定義したJDBCデータ・ソースを構成します。

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

JDBCデータ・ソース・テスト

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

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

JDBCコンポーネント・スキーマ

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

注意:

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

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

JDBCコンポーネント・スキーマ・テスト

前の画面でデータ・ソースに指定した構成をテストします。テストするスキーマ名の横のチェック・ボックスを選択し、「選択された接続のテスト(T)」をクリックします。

テストの結果は、「ステータス」列に表示されます。すべてのスキーマでテストに成功した場合、「次へ」をクリックします。

ノード・マネージャ

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

ドメインごととホストごとのノード・マネージャの構成の詳細は、「ノード・マネージャのデフォルト構成」を参照してください。

拡張構成

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

たとえば、SOA SuiteおよびBPMテンプレートをドメインに適用するときに、次の事項が1つ以上当てはまる場合は、「管理対象サーバー、クラスタおよびCoherence」を選択します。

- 単一のドメイン(たとえば、soa_server1やbam_server1)に複数の管理対象サーバーがある

- クラスタまたはCoherenceのデータを変更する必要がある

「ノード・マネージャ」、「デプロイメントとサービス」、「ドメイン・フロントエンド・ホストのキャプチャ」、「JMSファイル・ストア」など、その他の拡張構成オプションの使用の詳細は、オンライン・ヘルプを参照してください。

管理対象サーバー

ドメインの各管理対象サーバーに対し、リスニング・アドレスの実際のホスト名を指定する必要があります。

デフォルトのlocalhostまたはAll Local Addressesオプションは使用しないでください。

実際のホスト名を、hostname.company.comのように指定する必要があります。

12.1.3から12.2.1にアップグレードするときは、適切なサーバー・グループにサーバーを割り当てる必要があります。

サーバーのマシンへの割当て

アップグレード・プロセスの一部としてサーバーを作成した場合は、「サーバー」リスト・ボックスでサーバー名を選択して、適切なノード・マネージャ・マシンにターゲット設定します。

そうでない場合は、ドメインのアップグレード時または再構成時にこの画面で操作は必要ありません。

サーバーのクラスタへの割当て

クラスタのアップグレードのみ: クラスタをアップグレードする場合は、この画面を使用して管理対象サーバーをクラスタに割り当てます。

「サーバー」リスト・ボックスには管理対象サーバーのみが表示されます。管理サーバーは、クラスタに割り当てることができないので、リストに表示されません。

注意:
SOA UPGRADES ONLY: OWSMPMが独自のクラスタにあり、SOAまたはOSBクラスタの一部でない場合、SOAクラスタにはSOA-MGD-SVRS-ONLYユーザー拡張可能サーバー・グループのみをターゲットし、OSBクラスタにはOSB-MGD-SVRS-ONLYをターゲットし、OWSMにはWSMPM-MAN-SVERサーバー・グループのみをターゲットする必要があります。12.1.3から12.2.1にアップグレードするときは、BAMクラスタにBAM-MGD-SVRS-ONLYをターゲットする必要もあります。

構成のサマリー

構成のサマリーを確認します。

「再構成」をクリックしてドメインを再構成するか、「戻る」をクリックして構成を変更します。

再構成の進行状況

再構成の進行状況を確認します。処理が完了したら「次へ」をクリックします。

再構成に成功しました

再構成処理の最終的なステータスを確認します。「終了(F)」をクリックして再構成ウィザードを終了します。

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

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

- Upgrade Assistantの起動

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

7.5.1 Upgrade Assistantの起動

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

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

./ua

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

ua.bat

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

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

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

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

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

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

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

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

ヒント:

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

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

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

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

- Oracle Data Integrator

4. 前提条件の検証

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

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

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

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

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

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

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

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

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

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

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

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

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

- Upgrade Assistantの起動

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

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

「Java EEエージェント環境のアップグレード」の手順に従い、再構成ウィザードを使用して11g、12.1.2または12.1.3ドメインを再構成します。

7.6.2 Upgrade Assistantの起動

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

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

./ua

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

ua.bat

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

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

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

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

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

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

ヒント:

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

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

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

4. 前提条件の検証

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

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

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

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

ヒント:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

アップグレードのパフォーマンス・エラーのトラブルシューティング

リポジトリに存在するセッションの数が、アップグレードのパフォーマンスに影響します。アップグレードのパフォーマンス向上を図るには、セッションのログをアーカイブしてパージすることをお薦めします。

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

これらは12.1.3アップグレード・アシスタントで表示されていた追加のオプションですが、12.2.1アップグレード・アシスタントでは非表示になっています。これらのオプションが必要な場合は、サイレント・モードで使用するレスポンス・ファイルで設定します。

表7-3 高度なアップグレード・オプション

12.1.3でのオプション名

12.2.1レスポンス・ファイルのオプション名

想定される値(デフォルト＝yes)

説明

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

ODI_GUID.option

yesまたはno

これを選択すると、リポジトリが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モードだった場合、このオプションは無効です。

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

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

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

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

ODI_AES.option

yesまたはno

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

表7-4で、「ODIオプション」画面で選択できるオプションと選択できないオプションの組合せについて説明します。

表7-4 「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提供のナレッジ・モジュールを変更していない場合は、この組合せを使用してください。

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

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

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

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

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

×

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

×

×

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

注意:

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

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

A 代替API

この章では、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() 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-2016, Oracle and/or its affiliates.All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

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

保証免責

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

制限付権利について

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

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

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

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

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

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

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

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。