Oracle® Fusion Middleware

Oracle Enterprise Data Qualityの理解

12c (12.2.1.2.0)

E88271-01(原本部品番号:E78154-02)

2016年10月

Oracle Fusion Middleware Oracle Enterprise Data Qualityの理解、12c (12.2.1.2.0)

E88271-01

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

原本著者:  Oracle Corporation

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

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

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

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社およびその関連会社は一切の責任を負いかねます。

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 Enterprise Data Qualityの概要

- 1.1 Oracle Fusion Middlewareの概要

- 1.2 Oracle Enterprise Data Qualityについて

- 1.3 ソフトウェア・コンポーネントについて

- 1.3.1 クライアント・アプリケーションについて

- 1.3.1.1 データの格納場所

- 1.3.1.2 ネットワーク通信

- 1.3.2 データのEDQリポジトリへの格納方法

- 1.3.2.1 Configスキーマについて

- 1.3.2.2 Resultsスキーマについて

- 1.3.3 EDQによる作業データのディスク上の格納場所

- 1.3.4 ビジネス・レイヤーについて

2 Enterprise Data Qualityの主要概念について

- 2.1 EDQの用語について

- 2.2 データ・キャプチャについて

- 2.2.1 ネットワーク通信とCPU負荷について

- 2.3 一般的なデータ処理について

- 2.3.1 ストリーミングについて

- 2.3.2 作業の分担について

- 2.3.3 レコード・セット全体の処理について

- 2.3.4 実行ラベルについて

- 2.4 照合処理について

- 2.5 リアルタイム処理について

3 EDQの高可用性

- 3.1 テクノロジ要件

- 3.2 WebLogicクラスタにおけるEDQ

- 3.2.1 WebLogic ClusterにおけるEDQの特徴

- 3.2.2 クラスタで実行する場合のジョブの定義

- 3.2.3 EDQ Webサービスの監視

- 3.2.4 UIの動作

- 3.2.5 チューニング

- 3.2.6 Oracle Web Services Managerの使用

- 3.2.7 管理ポート

- 3.2.8 前提

- 3.2.9 制限事項および例外

はじめに

このガイドには、Oracle Fusion Middlewareを使用するための概要、主な用語、データ処理、および基本手順が示されています。

対象読者

このマニュアルは、Oracle Fusion Middlewareの主要な概念とアーキテクチャの概要に関心があるすべての方を対象としています。

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

Oracleのアクセシビリティについての詳細情報は、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)を参照してください。

関連ドキュメント

詳細は、http://docs.oracle.com/middleware/12212/edq/index.htmlにあるOracle Fusion Middlewareのドキュメント・セットを参照してください

EDQドキュメント・ライブラリ

次の刊行物がEDQのインストールおよび使用に役立てるために提供されます。

- 『Oracle Fusion Middleware Enterprise Data Qualityリリース・ノート』

- Oracle Fusion Middleware Enterprise Data Qualityのインストールと構成

- 『Oracle Fusion Middleware Enterprise Data Qualityの管理』

- 『Oracle Fusion Middleware Enterprise Data Qualityの理解』

- Oracle Fusion Middleware Enterprise Data Qualityの外部システムとの統合

- Oracle Fusion Middleware Oracle Enterprise Data Qualityの保護

- Oracle Enterprise Data Qualityアドレス検証サーバーのインストレーションおよびアップグレード・ガイド

- Oracle Enterprise Data Qualityアドレス検証サーバー・リリース・ノート

次の場所で、これらのガイドおよびすべてのOracle製品ドキュメントの最新バージョンを検索してください。

https://docs.oracle.com

オンライン・ヘルプ

オンライン・ヘルプは、すべてのOracle Fusion Middlewareユーザー・アプリケーションに提供されています。各アプリケーションで、[F1]キーを押すか、「ヘルプ」アイコンをクリックすることで表示できます。ディレクタのプロジェクト・ブラウザの主なノードには、ヘルプ・ページに統合されたリンクが含まれます。それらにアクセスするには、ノードを選択して[F1]を押すか、またはプロジェクト・ブラウザでオブジェクトを右クリックして「ヘルプ」を選択します。ディレクタ・ツール・パレットのEDQプロセッサには、統合されたヘルプ・トピックも含まれます。これにアクセスするには、キャンバスでプロセッサを右クリックして「プロセッサ・ヘルプ」を選択するか、キャンバスかツール・パレットでプロセッサを左クリックして[F1]を押します。

表記規則

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

規則

意味

太字

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

イタリック体

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

固定幅フォント

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

1 Oracle Enterprise Data Qualityの概要

この章では、Oracle Fusion MiddlewareおよびOracle Enterprise Data Qualityの概要について説明します。

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

- Oracle Fusion Middlewareの概要

- Oracle Enterprise Data Qualityについて

- ソフトウェア・コンポーネントについて

1.1 Oracle Fusion Middlewareの概要

Oracle Fusion Middlewareは規格に基づくソフトウェア製品の集まりで、Java EEや開発ツールから統合サービス、ビジネス・インテリジェンスおよびコラボレーションまで、様々なツールやサービスが含まれます。Oracle Fusion Middlewareは、アプリケーションの開発、デプロイおよび管理を完全にサポートします。Oracle Fusion Middlewareコンポーネントは、Oracle Enterprise Manager Fusion Middleware Controlコンソールを使用して実行時にモニターされます。

1.2 Oracle Enterprise Data Qualityについて

EDQでは、データ品質の把握、改善、保護および制御に使用される、包括的なデータ品質管理環境を提供します。EDQは、ベスト・プラクティスのマスター・データ管理、データ統合、ビジネス・インテリジェンスおよびデータ移行イニシアティブを容易にします。EDQは、カスタマ・リレーションシップ・マネジメントおよび他のアプリケーションに統合されたデータ品質を提供します。

EDQの主な機能は次のとおりです。

- 統合されたデータ・プロファイリング、監査、クレンジングおよび照合

- ブラウザベースのクライアント・アクセス

- すべてのタイプのデータを処理できる機能(たとえば、顧客、製品、資産、会計、操作)

- Java Database Connectivity (JDBC)準拠データ・ソースおよびターゲットへの接続

- マルチユーザーのプロジェクト・サポート(ロールベースのアクセス、問題追跡、プロセス注釈、およびバージョン制御)

- サービスとして外部アプリケーションに公開される可能性のある、設計プロセスのためのServices Oriented Architecture (SOA)サポート

- 大量のデータの処理用に設計

- 共有アクセスを使用した、収集された統計とプロジェクト追跡情報とともにデータを保持する単一リポジトリ

- 実際の情報品質の問題を迅速に解決するために設計された直観的なグラフィカル・ユーザー・インタフェース

- 検証および変換ルールの、容易でデータ主導の作成および拡張

- 必要なカスタム処理を挿入できる、完全に拡張可能なアーキテクチャ

1.3 ソフトウェア・コンポーネントについて

EDQは、Javaサーブレット・エンジン、Java Web Startグラフィカル・ユーザー・インタフェース、およびStructured Query Language (SQL)を利用したリレーショナル・データベース管理システム(RDBMS)によるデータ・ストレージを使用するJava Webアプリケーションです。

EDQはクライアント・サーバー・アーキテクチャです。グラフィカル・ユーザー・インタフェース(GUI)、1つのデータ・リポジトリおよび1つのビジネス・レイヤーである複数のクライアント・アプリケーションから構成されます。この項では、これらのコンポーネントのアーキテクチャ、そのデータ・ストレージ、データ・アクセスおよびI/O要件について、詳細に説明します。

1.3.1 クライアント・アプリケーションについて

EDQでは、この製品を構成および操作するために使用される多くのクライアント・アプリケーションを提供します。そのほとんどはJava Web Startアプリケーションであり、それ以外は簡単なWebページです。次の表に、すべてのクライアント・アプリケーションとその開始方法およびそれぞれの機能をリストします。

アプリケーション名

開始

目的

ディレクタ

Web開始

データ品質処理を設計し、テストします

サーバー・コンソール

Web開始

ジョブを操作し、監視します

一致レビュー

Web開始

一致結果をレビューして、手動で一致を決定します

ダッシュボード

ブラウザ

データ品質のキー・パフォーマンス・インジケータおよびトレンドを監視します

ケース管理

Web開始

構成可能なワークフローを通じてデータの問題を詳細に調査します

ケース管理の管理

Web開始

ケース管理のワークフローおよび権限を構成します

Webサービス・テスター

ブラウザ

EDQ Webサービスをテストします

構成分析

Web開始

構成に関するレポートを作成し、複数のバージョンの構成の差分を取得します

問題マネージャ

Web開始

DQの問題のリストを管理します

管理

ブラウザ

EDQサーバーを管理します(ユーザー、グループ、拡張機能、Launchpadの構成)

パスワードの変更

ブラウザ

パスワードの変更

構成分析

Web開始

プロジェクトの構成を分析し、差分を報告します

クライアント・アプリケーションには、EDQサーバーのEDQ Launchpadからアクセスできます。クライアントがJava Web Startアプリケーションのいずれか(ディレクタなど)を起動すると、そのアプリケーションはクライアント・マシンにダウンロードされ、インストールされて実行されます。アプリケーションはEDQサーバーと通信して、変更をインスタンス化し、サーバーからのメッセージを受信します(実行中のタスクに関する情報、他のユーザーによる変更など)。

EDQは拡張可能なシステムであるため、特定のユースケースに対応するために、インストール時にさらにユーザー・アプリケーションを追加して拡張することができます。たとえば、Oracle Watchlist ScreeningでEDQを拡張すると、監視リストに関してデータをスクリーニングするユーザー・アプリケーションが追加されます。

注意:
多くのクライアント・アプリケーションは、個別で使用する(専用の用途)ことも、別のアプリケーション内で使用することもできます。たとえば、構成分析、一致レビューおよび問題マネージャ・アプリケーションは、ディレクタ内からでも使用できます。

1.3.1.1 データの格納場所

クライアント・コンピュータには、クライアント・アプリケーションを表示するためのユーザー・プリファレンスのみが格納され、その他のすべての情報はEDQサーバーに格納されます。

1.3.1.2 ネットワーク通信

クライアント・アプリケーションは、起動時のアプリケーション構成により決定される、ハイパーテキスト転送プロトコル(HTTP)またはセキュアなハイパーテキスト転送プロトコル(HTTPS)接続のいずれかで通信します。このドキュメントではこれ以降、説明を簡単にするために、この接続を「HTTP接続」と呼びます。

1.3.2 データのEDQリポジトリへの格納方法

EDQは、2つのデータベース・スキーマ(ConfigスキーマおよびResultsスキーマ)を含むリポジトリを使用します。

注意:
各EDQサーバーは、そのサーバー専用のConfigスキーマおよびResultsスキーマを持つ必要があります。複数のサーバーを高可用性アーキテクチャにデプロイする場合に、2つのサーバーが同一のスキーマをポイントするようにして構成を共有することはできません。

1.3.2.1 Configスキーマについて

Configスキーマは、EDQの構成データを格納します。通常は、多くのWebアプリケーションに共通の一般的なトランザクション方式で使用されます(問合せを実行して少数のレコードにアクセスし、必要に応じて更新します)。

通常、このスキーマには少量のデータのみが保持されます。簡単な実装の場合は、数MB程度であることがほとんどです。例外的に大規模なEDQシステムでは、特にケース管理の使用頻度が高い場合は、ストレージ要件が10GBに達する可能性があります。

Configスキーマに保持されたデータへのアクセスは、他のリレーショナル・データベース管理システム(RDBMS)アプリケーションでの構成データの典型です。ほとんどのデータベース・アクセスは読取りリクエストの形式であり、それに比較的少量のデータ更新および挿入リクエストも付随します。

1.3.2.2 Resultsスキーマについて

Resultsスキーマには、スナップショット・データ、ステージング済データおよび結果データが格納されます。これは高度に動的で、サーバーで動作中のプロセッサで処理されるデータを格納するために、必要に応じて表が作成および削除されます。プロセス実行中に、使用可能なメモリーに保持できない作業データを格納するために、一時的な作業表も作成および削除されます。

Resultsスキーマに保持されるデータ量は時間とともに大幅に変化し、データのキャプチャおよび処理ではデータが数GBに及ぶ可能性があります。また、プロセスまたはジョブの実行中に、データが一時的に結果データベースに格納されることもあります。ジョブについては、処理中に複数のバージョンのデータがデータベースに書き込まれる場合があります。

Resultsスキーマは、Configスキーマとはまったく異なるデータ・アクセス・プロファイルを持ち、従来のWebベースのデータベース・アプリケーションとは大きく異なります。通常、Resultsスキーマの表は次の特徴を持ちます。

- オンデマンドでの作成

- バルクJDBCアプリケーション・プログラミング・インタフェース(API)を使用したデータの移入

- プロセス実行をサポートするために、完全表スキャンを使用して問合せが実行されます。

- Indexed

- クライアント・アプリケーションでのユーザーの対話に応答して、複雑なSQL文を使用した問合せの実行

- 関連付けられているプロセスまたはスナップショットが再度実行されると削除されます。

このような動的性質を持つため、このスキーマは慎重に取り扱う必要があります。たとえば、REDOログ・ファイルを別のディスクにマウントすることをお薦めします。

1.3.3 EDQによる作業データのディスク上の格納場所

EDQでは、プログラム・ファイルが含まれるインストール・ディレクトリとは別の、2つの構成ディレクトリを使用します。そのディレクトリは次のとおりです。

- ベース構成ディレクトリ: このディレクトリにはデフォルトの構成データが含まれます。このディレクトリの名前は、Oracle WebLogicインストールではoedq.homeですが、Apache Tomcatインストールでは任意の名前にすることができます。

- ローカル構成ディレクトリ: このディレクトリには、拡張パック用のデータやデフォルト設定のオーバーライドなど、ベース構成のオーバーライドが含まれます。EDQは最初にこのディレクトリでオーバーライドがあるかどうかを調べて、ローカル・ディレクトリで必要なデータが検出されない場合は、ベース・ディレクトリを調べます。ローカル・ディレクトリの名前は、Oracle WebLogicインストールではoedq.local.homeですが、Apache Tomcatインストールでは任意の名前にすることができます。

ファイルベースのデータ・ストアとの間でデータが処理されるときに、構成ディレクトリのいくつかのファイルが使用されます。その他のファイルは、どの機能パックが有効になるか、EDQのリポジトリ・データベースへの接続方法、およびその他の重要な情報などの、サーバーの構成プロパティを格納するために使用されます。

ホームおよびローカル・ホーム・ディレクトリの名前と場所は、テンプレートまたはその他の個別のコンポーネントへの手動更新を実行する必要があることをイベントで知るために重要です。

これらのディレクトリはEDQのインストール時に作成されます。詳細は、『Oracle Fusion Middleware Enterprise Data Qualityのインストールと構成』を参照してください。

1.3.4 ビジネス・レイヤーについて

ビジネス・レイヤーでは、主に次の3つの機能があります。

- クライアント・アプリケーションがシステムの他の部分とやり取りするために使用するAPIを提供します。

- クライアント・アプリケーションにクライアント・アプリケーションの更新が必要なサーバー・イベントを通知します。

- データをキャプチャして処理するプロセスを実行します。

ビジネス・レイヤーはConfigスキーマに構成データを格納し、Resultsスキーマに作業データと結果を格納します。

クライアント・アプリケーションとの間でデータの受け渡し中に、ビジネス・レイヤーは、従来のJava Webアプリケーションの大部分に共通な方法で動作します。ビジネス・レイヤーは小規模なデータベース・トランザクションを作成し、HTTP接続を使用してフロントエンドに少量の情報を送信します。このアプリケーション・フロントエンドの大部分がブラウザよりも豊富なGUIを持つという点において、これは幾分変わっています。そのため、このクライアント・アプリケーションに送信されるデータのほとんどは、従来のHTMLではなく、シリアライズJavaオブジェクトで構成されます。

ただし、プロセスの実行時およびスナップショットの作成時には、このビジネス・レイヤーの動作は従来のバッチ・アプリケーションに近づきます。デフォルト構成では、非常に大規模なデータ量でも処理できるように、複数のスレッドおよびデータベース接続を生成し、使用可能なCPUコアおよびデータベースI/O容量をすべて使用します。

使用可能なリソースの使用を制限するようにEDQを構成できますが、明らかにパフォーマンスに影響を与えます。詳細は、EDQのインストレーション・ガイドおよびEDQの管理者ガイドを参照してください。

2 Enterprise Data Qualityの主要概念について

この章では、EDQの主要な概念について説明します。

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

- EDQの用語について

- データ・キャプチャについて

- 一般的なデータ処理について

- 照合処理について

- リアルタイム処理について

2.1 EDQの用語について

EDQで使用される最も重要な用語は次のとおりです。

プロジェクト

共有される参照データを使用する、データの共通セットで動作する関連プロセスのグループ。

データ・ストア

データがデータベースに格納されているか、1つまたは複数のファイルに格納されているかにかかわらず、データのストアへの接続。データ・ストアはプロセス用のデータのソースとして使用することができ、プロセスの書き込まれたステージング済データ結果をデータ・ストアにエクスポートすることも、またはその両方をすることもできます。

プロセス

特定のデータに対して実行するアクションのセットを示します。これは一連のプロセッサで構成され、プロセッサのそれぞれでデータの処理方法、および適用されるルールが指定されています。プロセスでは次のものが生成されることがあります。

- ステージング済データ: 入力データを処理することによって、および結果データベースへの出力データの書込みを選択することによって生成されるデータまたはメトリック。

- 結果データ: プロセスの結果をまとめたメトリック情報。たとえば、簡単な検証プロセスで、不合格のレコード数、および合格したレコード数を記録できます。

プロセッサ

データに対し操作を実行する論理要素。プロセッサは、統計分析、監査チェック、変換、照合などの操作を実行できます。複数のプロセッサが連鎖することによって、プロセスを形成します。

公開されたプロセッサ

Extension Pack (Customer Dataパックなど)からインストールされた、またはEDQユーザーによりサーバーに公開された、追加のプロセッサです(プロセッサ・ライブラリ内のプロセッサに追加)。他のオブジェクトのようにパッケージ化できるようにプロジェクト・ブラウザに含まれます。公開されたプロセッサには、テンプレート、参照、およびロックされた参照の3つのタイプがあります。

参照データ

プロセッサがチェック、照合、変換などの実行に使用できるリストおよびマップで構成されます。参照データは、EDQの一部として、またはサード・パーティによって提供されることも、ユーザーが定義することも可能です。

ステージング済データ

データ・スナップショットおよびプロセスによって書き込まれたデータで構成され、Resultsスキーマ内に格納されます。

スナップショット

EDQリポジトリに格納された外部データのキャプチャされたコピーです。

ジョブ

EDQまたは外部によって実行される可能性のある、構成され、順序付けられた一連のタスクです。タスクの例としては、ファイル・ダウンロード、スナップショット、プロセスおよびエクスポートの実行があります。

イメージ

プロセッサに関連するアイコンをカスタマイズします。

エクスポート

エクスポートには次の2つのタイプがあります。

- 保存された構成を使用する準備されたエクスポート(ステージング済データのエクスポートまたは結果ブック・エクスポート)。

- 結果ブラウザからExcelファイルへの現在の結果の非定型エクスポート。

Webサービス

デプロイ・プロセスに使用され(ディレクタでの構成のとおり)、リアルタイムのデータ監査、クレンジング、照合(リアルタイムの重複防止など)のための、ソース・システムとの容易な統合を提供します

実行プロファイル

デフォルトのジョブ実行設定をオーバーライドするために使用できる構成設定を指定するオプションのテンプレートです。

問題

ユーザーがデータの分析時の主要な発見を記録することができ、複数のユーザー間で割当ておよび追跡されるプロジェクトでの作業方法も提供します。

プロジェクト・メモ

プロジェクトと関連するすべての情報のための明示的なリポジトリとして、ディレクタを使用することができます。プロジェクトの進行全体で、プロジェクトで作業中のすべてのユーザーに使用可能にする必要のあるあらゆる情報を、メモとして追加することができます。

2.2 データ・キャプチャについて

データ・キャプチャ・プロセスは、外部データ・ソースからキャプチャされるデータの取得で始まります。データは、データベース、テキスト・ファイル、XMLファイルなどからキャプチャできます。可能なデータ・ソース・タイプのすべてのリストについては、オンライン・ヘルプのコンセプトに関する項で、データ・ストアのトピックを参照してください。

データ・ソースのタイプによっては、データ・キャプチャで次の操作が行われる場合があります。

- ソース・システムでの単一のSQL問合せの実行。

- 区切り文字付きファイル、または固定形式ファイルの順次処理。

- データのストリームを生成するための、XMLファイルの処理。

データが取得されると、単一のスレッドで処理されます。内容は次のとおりです。

- 各入力レコードに内部的な順序番号が割り当てられます。通常、これは各行に対して単調に増分される番号です。

- 行を作業ユニットにバッチングします。作業ユニットが一杯になると、結果データベースの作業キューに渡されます。

データベースの作業キューは、データベースで実行される作業リクエストで構成され、そのほとんどはデータ挿入または索引付けリクエストです。キューはスレッドのプールによって処理されます(キューから作業ユニットが取得され、適切なデータベースへのデータベース接続が取得され、作業が実行されます)。スナップショットの場合、作業の内容は、レコードのグループを表にロードするためのJDBCバッチAPIを使用することです。

すべてのデータが1つの表に挿入されると、スナップショット・プロセスは1つ以上の索引付けリクエストを作成し、それらをデータベース作業キューに追加します。一意の行識別子に索引を付けるために、表ごとに1つ以上の索引付けリクエストが作成されますが、スナップショット内のデータ量およびスナップショット・プロセスの構成によっては、キャプチャされたデータ内の他の列もスナップショット・データへの索引生成に使用されます。

図2-1 データ・キャプチャ・プロセス

2.2.1 ネットワーク通信とCPU負荷について

スナップショットでは、次のことが予想されます。

- データの読取り中に、データ・ソースをホストするマシンでI/OおよびCPU負荷が生成される

- スナップショット・プロセスがデータの読取りを行い、挿入用にそのデータのグループ化を行うことによって、Webアプリケーション・サーバーで、CPU負荷が生成される

- データベース作業ユニットのエグゼキュータ・スレッドによって、Webアプリケーション・サーバーで、I/OおよびCPU負荷が生成される

- データが新しい表に挿入されるときに、EDQ結果データベースをホストするマシンで、相当量のI/Oが生成される

- データに索引付けされるときに、結果データベースをホストするマシンで、相当量のI/OとCPU負荷が生成される

たとえば、4コア・サーバーでのデフォルトのEDQインストールの場合に、10列にわたって10,000行のデータのスナップショットを作成する場合、次の形式のSQLが生成されます。

DROP TABLE DN_1;
CREATE TABLE DN_1 (record-id, column1, column2, ..., column10);

100の一括挿入文は次のようになります。

INSERT INTO DN_1 (record_id, column1, column2, ..., column10) VALUES ( ?, ?, ..., ? )

それぞれ100個の一連のパラメータをとります。一括挿入は、4つのデータベース接続(CPUコアごとに1つ)でパラレルに実行されます。

ANALYZE TABLE DN_1 ESTIMATE STATISTICS SAMPLE 10 PERCENT

また、最後に、11個のCREATE INDEX...文によって、新しい表の各列に索引付けされます(元の10個の列に追加のrecord_id列)。CREATE INDEX文も、4つのデータベース接続でパラレルに実行されます。

2.3 一般的なデータ処理について

データがキャプチャされると、処理の準備ができます。リーダー・プロセッサは、ダウンストリーム・プロセッサにデータへの管理されたアクセスを提供し、ダウンストリーム・プロセッサは結果データを生成します。ライター・プロセッサが存在する場合、処理の結果をステージング済データ・リポジトリに書き戻します。

プロセスを実行すると、Webアプリケーション・サーバーは多数のプロセス実行スレッドを開始します。EDQのデフォルト構成では、EDQアプリケーション・サーバー・マシンに存在するコア数と同数のスレッドを開始します。

2.3.1 ストリーミングについて

スナップショット内のデータをキャプチャし、結果データベースに格納するかわりに(照合中の一時的なもの以外で)、ソースからプルして、ストリームとしてターゲットにプッシュできます。

2.3.2 作業の分担について

各プロセスの実行スレッドには、処理するデータのサブセットが割り当てられます。プロセスの入力データが、スナップショット、ステージング済データなどの既知のサイズのデータ・セットの場合、各スレッドはデータのサブセットを取得する問合せを実行します(データのサブセットの識別は、スナップショット作成中に割り当てられた一意の行IDで行われます)。4コア・マシンでの10,000レコードのデータの処理について説明している2.2.1項「ネットワーク通信とCPU負荷について」のシナリオ例では、4つの問合せがResultsスキーマに対して発行されます。この問合せは、次の形式になります。

SELECT record_id, column1, column2, … , column10

FROM DN_1

WHERE record_id > 0 AND record_id <= 2500;

プロセスの実行対象が既知のサイズのデータ・セットではない場合(データ・ソースに対して直接実行するようにスケジュールされているジョブなど)、すべてのレコードを1つのキューに読み取ることでプロセス実行スレッド間でレコードが共有され、複数のプロセス実行スレッドによって消費されます。

各プロセス実行スレッドは、プロセスを構成するプロセッサのシーケンスを認識するようにもなっています。このプロセス実行スレッドは、それぞれの適切なプロセッサを通じてレコードを渡します。プロセッサが動作すると、Resultsスキーマに格納する必要がある結果を蓄積しますが、ライター・プロセッサの場合は、ステージング済データに書き込む必要があるデータも蓄積することがあります。このデータはすべて挿入グループに蓄積され、データベースの作業ユニットに追加され、4.1項「データ・キャプチャ」の説明どおりに処理されます。

実行スレッドが割り当てられたすべてのレコードを処理すると、他のすべてのプロセス実行スレッドが完了するまで待機します。その後、プロセス実行スレッドは照合フェーズに入り、その間にプロセスの複数のコピーからのサマリー・データが蓄積され、データベースの作業キューによって結果データベースに書き込まれます。

バッチ処理中は、次の動作が予想されます。

- キャプチャされたデータが読み取られる際に、Resultsスキーマでの読取り負荷。

- データが処理される際に、Webアプリケーション・サーバーでのCPU負荷。

- 結果およびステージング済データがスキーマに書き込まれる際に、Resultsスキーマでの著しい書込み負荷。

- 照合フェーズに入った際のCPU負荷の減少。

- 未処理のデータベース作業ユニットが処理され、蓄積された結果が書き込まれた際の、それ以降の少量のデータベース作業。

- 必要に応じて、照合フェーズの最後でのResultsスキーマでのさらなる書込み負荷(結果およびステージング済データ表に索引を付けるためのリクエストの形式で)。索引付けリクエストのサイズと数は、データ量とシステム構成に応じて変わります。

クリーニングおよび検証操作を中心として重厚に構築されたプロセスは、データベースのI/O容量によって制限される傾向があります。一部のプロセッサは著しくCPUリソースを消費しますが、通常、処理速度を決めるのは、Resultsスキーマからのデータの提供速度、Resultsスキーマへの書込み速度です。

2.3.3 レコード・セット全体の処理について

レコード重複プロファイラ・プロセッサや重複チェック・プロセッサなど、機能するためにはレコード・セット全体にアクセスする必要のあるプロセッサが多数あります。これらのプロセッサがデータのサブセットにしかアクセスできない場合、重複レコードを正確に検出することはできなくなります。これらのプロセスは、複数のスレッドを使用して入力レコードを取り込み、一時表を構築します。すべてのレコードの検証が完了すると、レコードを様々なプロセス実行スレッド間で配分することによって、再放出します。レコードを取り込んだときと同じプロセス実行スレッドで放出されるとはかぎりません。

2.3.4 実行ラベルについて

プロジェクトの設計フェーズでは、通常、プロセスとジョブはディレクタを使用して対話的に実行されます。ジョブをディレクタ内で実行すると、通常は、ユーザーによる調査用に結果が書き込まれ、範囲内のデータで最適に動作するようにプロセスおよびジョブの構成を繰り返すことができるようになっています。書き込むデータ量は、ディレクタで制御できます。

ただし、ジョブを本番環境にデプロイした場合、通常はこのような詳細な結果は必要なく、ジョブは実行ラベル付きでサーバー・コンソールまたはコマンドラインから実行されます。実行ラベル付きで実行されると、ユーザーがジョブでステージングされるように構成したステージング済データと結果のビューのみがジョブによって書き込まれるため、パフォーマンス効率が向上します。

注意:
ジョブは、データの特定のソースまたはターゲットとは独立して設計することができます。このようなジョブは、通常は、一連のコマンドライン・パラメータとともに、または同じパラメータを設定する格納済の実行プロファイルとともに実行されます(これによって、読み取るデータの物理ソース、主要な処理オプション、書き込むデータの物理ソースなど、主要な構成オプションが動的に変更されます)。このようなジョブは実行ラベル付きで実行して、書き込まれるデータおよび結果が、同じジョブを異なるデータで実行した場合とは明確に分離されるようにする必要があります。サーバー・コンソールでは、ユーザーが実行ラベル別に結果を調査できます。

2.4 照合処理について

EDQ照合プロセッサは、これよりも単純なプロセッサとは大幅に異なる方法で処理されます。照合プロセッサで実行される作業の性質上、データを通して複数回のパスが必要になります。

照合プロセッサは、一連のサブプロセスとして取り扱うことで実行されます。たとえば、顧客のデータ・スナップショットを、禁止人物のリストと照合するように設計されたプロセスを考えます。このプロセスには、顧客参照番号と関連する禁止人物の識別子のリストを生成するように構成された照合プロセッサが含まれています。照合プロセッサに入力される(または出力される)各データ・ストリームは、照合プロセッサのサブプロセスとみなされます。そのため、この例には3つのサブプロセスがあります(顧客データ入力ストリーム、禁止人物入力ストリームおよび照合プロセッサの出力データ・ストリームを表します)。照合プロセッサ自体は4つ目のサブプロセスを形成し、効率的にデータの入力と出力を対にします。各サブプロセスにはプロセス実行スレッドの通常の割当て量が割り当てられるため、4コア・マシンでは、各サブプロセスが4つのプロセス実行スレッドを持つことになります。

図2-2 照合プロセス・スレッド

照合プロセッサの実行が開始されると、入力データ・サブプロセッサが最初に実行され、入力データを処理します。この時点では、照合または照合出力サブプロセスの作業はなく、休止状態のままです。入力データ・サブプロセスはデータ・ストリームのクラスタ値を生成し、通常のデータベース作業ユニット・メカニズムを使用して、クラスタ値および受信レコードをResultsスキーマに格納します。

入力データ・サブプロセスがすべての使用可能なレコードを処理すると、そのサブプロセスは終了し、サブプロセスの結果の照合を開始します。その一方で、照合サブプロセスがアクティブになります。照合サブプロセスは一連のステージを通過し、各プロセス実行スレッドは、他のすべてのプロセス実行スレッドが各ステージを完了するまで待機してから、次に進みます。新しいステージが開始されるたびに、作業はそのステージに適した形でプロセッサ・エグゼキュータ・スレッド間でさらに分割されます。処理ステージは次のとおりです。

フェーズ

説明

比較フェーズ

顧客データと禁止人物データが取得され、クラスタ値で並べ替えられます。データは、クラスタ値が等しいグループに集められ、キューに入れられ、レコードを比較するための照合プロセス・スレッドに渡されます。レコード間に関係が検出された場合、その関係情報がResultsスキーマに書き込まれます。

暫定グループ化フェーズ

比較フェーズで検出された関係情報は、チャンクで取得され、関連するレコードの暫定グループが形成されます。関係チャンクは、照合プロセッサ・スレッドによってパラレルに処理されます。これらの暫定グループは、結果データベースに書き戻されます。

最終グループ化フェーズ

単一のスレッドが暫定グループ表を検査して、チャンクの境界によって人為的に分割されたグループを確認します。チャンクを横断するグループが検出された場合は、1つのグループにマージされます。

マージ済の出力フェーズ

照合プロセッサ・スレッドのそれぞれが、照合グループの独立したサブセットを取得し、マージした出力を作成します(複数のレコードが1つの出力レコードにマージされます)。

これで照合サブプロセスは完了し、照合プロセッサ実行スレッドは照合フェーズへと移行します。

この時点で、照合データの出力に関連付けられるサブプロセスがアクティブになります。出力データは出力サブプロセスのプロセス実行スレッド間で分割され、照合プロセッサからのプロセッサ・ダウン・ストリームに渡されます。この後、データは通常のバッチ処理の方法で処理されます。

ベンチマークおよび本番での経験から、照合プロセッサの比較フェーズは、CPUバウンドになる可能性がある数少ないEDQ操作の1つであることがわかっています。非常に簡単な比較操作以外のものを実行した場合、CPUが比較負荷を処理する能力によって、プロセスが制限されます。比較操作の規模は適切に拡大縮小され、EDQ Webアプリケーション・サーバーで使用可能なすべてのCPUサイクルを完全に使用できます。

ヒント:
オンライン・ヘルプの「拡張機能: 照合コンセプト・ガイド」に記載されている内容をよく理解することをお薦めします。

2.5 リアルタイム処理について

EDQは、メッセージをリアルタイムに処理できます。現在、EDQでサポートされているメッセージングの手段は次のとおりです。

- Webサービス

- JMS対応メッセージング・ソフトウェア

リアルタイム・メッセージ処理用に構成すると、サーバーはメッセージの受信時にメッセージを処理するために、複数のプロセス実行スレッドを開始します。受信メッセージは、空いているプロセス実行スレッドに渡されるか、キューに入れられて次のプロセス実行スレッドが空くのを待機します。メッセージが処理されるとステージング済データはすべて結果データベースに書き込まれ、プロセス実行スレッドは、キューから次のメッセージを取り出すか(存在する場合)、または次の受信メッセージに使用可能になります。

データをリアルタイムに処理する場合、プロセスは間隔モードで実行できます。間隔モードでは、プロセスが設定された間隔で結果を保存可能になり、その結果をユーザーが確認し、EDQダッシュボードに公開できるようになります。間隔は、処理されるレコード数、または時間制限によって決定できます。間隔の上限に達すると、EDQはそのプロセスに対して新しいプロセス実行スレッドのセットを開始します。新しいプロセス実行スレッドすべてが必要な初期化を完了すると、新しい受信メッセージはこの新しいスレッドに渡されます。古いプロセス実行スレッドのセットが未処理のメッセージの処理を完了すると、システムはこれらのスレッドに照合フェーズに移行して、すべての結果を保存するように指示します。その後に古いプロセス実行スレッドは終了され、データは参照可能になります。

3 EDQの高可用性

EDQは様々な方法でデプロイして、高可用性要件をサポートできます。可用性の高いEDQシステムをサポートするうえで、最も一般的で推奨されるのは、WebLogicクラスタリングを使用する方法です。WebLogicクラスタリングでは、複数のEDQサーバーで同じインストールと構成を共有することが可能で、組込みの冗長性を使用すれば、これらを1つのシステムとして管理して操作できます。ただし、EDQリアルタイム・サービスでシンプルな高可用性を実現できるのは、各サーバーの構成が同一で、リアルタイム・サービスとロード・バランシング・リクエストがサーバー間でサポートされている場合のみです。どちらの場合も、データベース層の高可用性を保証するにはOracle Real Application Clusters (RAC)が推奨されますが、ほとんどのEDQリアルタイム・サービスは一度実行されれば、データベースの可用性は必要ありません。

この章では、EDQをWebLogicクラスタにデプロイするとどのように動作するかについて説明します。内容は次のとおりです。

- テクノロジ要件

- WebLogicクラスタにおけるEDQ

3.1 テクノロジ要件

EDQクラスタリングはWebLogicとCoherenceのテクノロジをベースとしており、WebLogicとCoherenceのクラスタリングを使用する適切なライセンスが必要です。データベース層の高可用性では、Oracle Real Application Clusters (RAC)が使用されるため、RACを使用する適切なライセンスが必要です。

3.2 WebLogicクラスタにおけるEDQ

EDQでは、WebLogicクラスタの操作がすべてサポートされます。クラスタにEDQをインストールする方法の詳細は、『Oracle Fusion Middleware Enterprise Data Qualityのインストールと構成』の「Oracle WebLogic Serverを使用したEnterprise Data Qualityの構成」の章を参照してください。

WebLogicクラスタの構成および管理の詳細は、高可用性ガイドを参照してください。

図3-1に、WebLogicクラスタにおけるEDQを示します。

図3-1 WebLogicクラスタにおけるEDQ

3.2.1 WebLogic ClusterにおけるEDQの特徴

クラスタにデプロイされたEDQには、次のような一般的な特徴があります。

- クラスタのすべてのサーバーが、リポジトリ・データベースの同じスキーマ(EDQ構成、EDQ結果およびEDQステージング)を共有します。WebLogicでは、これらのスキーマへの接続は、JNDIデータ・ソースとして定義されます。これらのデータ・ソースをOracle RAC用に構成し、複数のデータベース・ノードを使用したり、接続をロード・バランシングしたりすることも可能で、可用性を高めるために推奨されています。

- ステートレス・リアルタイム・ジョブが、クラスタのすべての管理対象サーバーで実行されます。システムでステートレス・リアルタイム・ジョブが検出される仕組みの詳細は、「クラスタで実行する場合のジョブの定義」を参照してください。

- クラスタ内の管理対象サーバーの1つ(通常は、最も余裕のあるサーバー)でバッチ・ジョブが実行されます。たとえば、2つのサーバーで構成されるクラスタにおいて、サーバーAでバッチ・ジョブを実行中に、別のバッチ・ジョブが発行された場合、新しいバッチ・ジョブはサーバーBで実行されます。

- Oracle RACが使用されていて、いずれかのノードが停止した場合、または障害が発生した場合は、次のようになります。

- 実行中のリアルタイム・ジョブは、通常、正常に処理が続行されます。

- 実行中のバッチ・ジョブで、障害が発生したノードへの接続が使用されている場合、そのジョブは失敗しますが、新しく発行されたバッチ・ジョブとして再開することが可能で、アクティブなノードへの新しい接続がリクエストされます。

- システムがアイドルな場合、影響はありません。

- Oracle RACが使用されておらず、データベースを使用できない場合は、次のようになります。

- 実行中のリアルタイム・ジョブは、通常、正常に処理が続行されます。

- 実行中のバッチ・ジョブは失敗し、データベースが再度使用可能になるまで、正常に再開できません。

- システムがアイドルな場合、影響はありません。

- データベースが再度使用可能になれば、JNDI接続プールは中断されないため、EDQアプリケーション・サーバーを再起動する必要はありません。

- クラスタの管理対象サーバーで障害が発生すると、ロード・バランサによって検出され、リクエスト・ルーター(Oracle HTTP Serverなど)が、この管理対象サーバーにリクエストをルーティングしなくなります。バッチ・ジョブは、稼働中のサーバーのいずれかで処理されます。

3.2.2 クラスタで実行する場合のジョブの定義

EDQでは、ジョブが、クラスタのすべてのサーバーで実行可能なステートレス・リアルタイム本番ジョブであるか、バッチ処理または結果の書込みが含まれ、クラスタ内の1つのサーバーで実行する必要があるジョブかどうかが自動的に検出されます。

クラスタのすべてのサーバーで実行するリアルタイム・ジョブとして検出されるには、ジョブに次の特性が必要です。

- 単一フェーズのみであること。

- すべてのプロセス・チェーンが、リアルタイム・マッピングを使用するよう構成された、リアルタイム・リーダーまたはデータ・インタフェース・リーダーに接続されていること。

- ステージングされたデータまたは参照データへの書込みを行わないこと。

注意:
ランディング領域にのみ書込みを行うジョブは、データ・インタフェース経由でデータをエクスポートするものとみなされ、ステージングされたデータを書き込んでいるとはみなされません。ジョブの実行中に無効化されている間、ジョブは、ジョブ定義や実行プロファイルなどに、そのようなライターを含んでいる場合があります。

- ステージングされたデータに結果を公開しないこと。

- 実行ラベルを使用して実行すること。

注意:
結果データの書込み、一致レビューのレビュー結果の書込み、またはダッシュボードへの公開に間隔モードを使用するジョブを、すべてのサーバーで実行することはできません。

理論的には、次のようなタイプのジョブが考えられます。すべてのサーバーでの実行が試行されますが、どのサーバーでも正常に実行されません。

- バッチ・ジョブを実行する'before'フェーズ・トリガーを含むリアルタイム・ジョブ。このタイプのジョブは、リアルタイム・ジョブがバッチ・ジョブの最後にトリガーされるように再構成する必要があります。

- 参照データまたはステージングされたデータへの書込みを行うリアルタイム・ジョブ。このタイプのジョブは、1つのサーバーでは正常に実行されますが、その他のサーバーでは、すでにロックされているというメッセージが表示されて失敗します。本番では、このタイプのジョブを使用しないでください。実行ラベルを使用しての実行をやめ、1つのサーバーで実行することにより、結果データや書き込まれるデータを確認できます。すべてのサーバーで実行される本番のステートレス・リアルタイム・ジョブからデータを書き出す必要がある場合は、追加モードで実行され、データ・インタフェースを介してエクスポートに書き込むライターを使用して実行してください。

- 同時に複数回実行されるリアルタイム・ジョブ。ジョブの最初のインスタンスはすべてのサーバーで実行されますが、後続のインスタンスは失敗します。

結果を書き込んだり、実行ラベルがないバッチ・ジョブやリアルタイム・ジョブなど、その他すべてのタイプのジョブは、クラスタの最も余裕のある管理対象サーバーで実行されます。つまり、12.2.1より前のバージョンのEDQで作成されたものや、現在リアルタイム・ジョブとして扱われているものなど、一部のタイプのジョブは、すべてのサーバーで実行可能とみなされません。これは特に、最初のフェーズにおいて、一括でデータ(リアルタイム照合処理の参照データなど)を準備し、後続のフェーズでリアルタイム処理を行うジョブに当てはまります。すべてのサーバーでそのようなジョブのリアルタイム・フェーズを実行する必要がある場合は、参照データを準備するバッチ・ジョブと、前述の要件を満たすリアルタイム・ジョブの2つにジョブを分割する必要があります。バッチ・ジョブには、リアルタイム・ジョブを開始する最終フェーズの終了トリガーが必要です。これにより、バッチ・ジョブは1つのサーバーで実行され、リアルタイム・ジョブはすべてのサーバーで実行されます。

3.2.3 EDQ Webサービスの監視

ほとんどのロード・バランサで、管理対象サーバーが実行中かどうかを把握できますが、そのことが、アプリケーションのサービスの準備ができているということかどうかを把握する必要があるわけではありません。WebサービスをサポートしているEDQリアルタイム・ジョブは、通常は、管理対象サーバーが稼働しているときには必ず実行されているものであるため、サーバーの起動時に開始されるようスケジュールします。これは、自動実行処理の使用で可能になります。ここに、クラスタ環境の強みがあります。ステートレス・リアルタイム・ジョブはクラスタのすべてのサーバーで実行されるため、実行中のリアルタイム・ジョブは、手動で操作しなくても、クラスタに新しく追加された管理対象サーバーで自動的に起動されます。

また、EDQはFusion Middlewareの準備完了アプリケーション機能と統合できるため、アプリケーションでWebサービス・リクエストを受信する準備ができているかどうかを確認するために、URLをチェックすることが可能です。

準備ができているかどうかを確認するURLは[http://server:port/weblogic/ready]であるため、EDQ管理対象サーバーの場合は、[http://host234:8001/weblogic/ready]のようになります。

サーバーがリクエストに対応する準備ができている場合、URLはステータス200を戻します。サーバーの準備ができていない場合は、503が戻されます。これにより、ロード・バランサはサービスの可用性を簡単に検出できます。

EDQサーバーが起動されると、自動実行が使用されること、または必要なリアルタイム・ジョブをすぐに開始するスケジュールが想定されます。ただし、なんらかの理由でそれらのジョブが停止または失敗した場合(さらに、管理対象サーバーが稼働し続けている場合)は、トリガーの使用により、準備ができていないことをEDQサーバー自身が宣言できます。準備完了アプリケーション統合のEDQのデフォルト実装では、顧客データ・サービス・パックのリアルタイム・サービスすべての可用性を監視するよう設定されていますが、ユーザーが選択したリアルタイム・サービスを監視するよう変更可能です。これは、EDQのホーム構成ディレクトリにあるEDQトリガーを使用して実装します。

[domain home]/edq/config/fmwconfig/edq/oedq.home/triggers/readyappjobfail.groovy

たとえばこれを、指定されたジョブの別のセットが失敗したら、準備ができていないことをEDQサーバー自身が宣言するよう変更するには、[oedq.local.home]ディレクトリのトリガー・ディレクトリにファイルをコピーし、プロジェクトとミッション・リストを監視するEDQプロジェクトおよびジョブに対応するように変更します。

3.2.4 UIの動作

EDQをクラスタにデプロイすると、Oracle HTTP Serverなどのフロントエンドのロード・バランサを使用して、クラスタ全体のユーザー・セッションをロード・バランシングすることが可能です。このシナリオでは、ロード・バランシングされたURLを使用してシステムにアクセスしているユーザーは、いずれかの管理対象サーバーに接続され、その後のアクションはすべてそのサーバーで処理されます。構成と結果データベースは同じであるため、ほとんどの場合、接続先のサーバーはユーザーには重要ではありません。どの管理対象サーバーに接続されているかに関係なく、Director and Server Consoleのユーザーに、クラスタでアクティブなジョブとタスクが表示されます。それぞれのジョブを実行しているサーバーが、UIに表示されます。

LaunchpadなどのEDQ Webページをカスタマイズして、ユーザー・セッションが接続されている管理対象サーバーの名前をヘッダーに表示するには、EDQのローカル・ホーム・ディレクトリにあるdirector.propertiesに次の行を追加します。

[expr]adf.headerextra = ': ' || weblogic.Name

WebStartアプリケーションとEDQ LaunchpadのどちらのUIセッションも、自動的にはフェイルオーバーされません。管理対象サーバーで障害が発生した場合、その管理対象サーバーに接続されているユーザーは、再度ログインする必要があります。少なくとももう1つの管理対象サーバーが使用可能であるならば、ログインは成功するため、ユーザーはアクティブな管理対象サーバーに接続されます。

3.2.5 チューニング

EDQクラスタリングではCoherenceを使用するため、Coherenceのパラメータを調整することで、システムの特定項目のチューニングを必要とする場合があります。詳細は、『Oracle Coherenceでのアプリケーションの開発』のパフォーマンス・チューニングに関する項を参照してください。

クラスタ内の前に障害が発生したサーバーを再起動する際は、クライアントが(別の管理対象サーバーに)接続できないという問題の原因になる可能性があり、潜在的な問題を回避するために、WebLogicコンソールを使用して、クラスタの「メンバーのウォームアップ・タイムアウト」プロパティを、(デフォルト値の0に対して)「30」(秒)に設定することをお薦めします。この設定は、クラスタの「一般」設定にあります。

3.2.6 Oracle Web Services Managerの使用

ドメイン内にOracle Web Services Managerポリシー・マネージャ('wsm-pm')を使用している別の管理対象サーバーがある場合は、デフォルトで作成されているEDQ管理対象サーバーの起動グループだけでなく、WebLogicドメイン構成ウィザードで、WSMPM-MAN-SVRサーバーの起動グループも参照して、すべてのEDQ管理対象サーバーを作成する必要があります。

3.2.7 管理ポート

EDQを単一の管理対象サーバーとして実行し、WebLogicクラスタを使用していない場合、デフォルトの管理ポートは8090です。EDQをWebLogicクラスタで実行している場合、EDQには、サーバーの起動時に割り当てられるランダム・ポートが使用されます。サーバー・アクセスMBeanを調べれば、現在のポートを確認できますが、EDQサーバーが再起動されると、それらのポートも変わることに注意してください。

標準のEDQ JMXクライアントは、管理サーバーのMBeanサーバーを使用して、これらのサーバー・アクセスBeanを自動的に問い合せるように更新されました。管理サーバーのホスト名とポートを指定すると、コネクタ・コードにより、適切なポートの管理対象サーバーのいずれかにリクエストがリダイレクトされます。

$ java -jar jmxtools.jar runjob ... adminhost:7001

WebLogicおよびEDQで、jmxtoolsのユーザー名とパスワードが有効になっている必要があります。OPSSに設定されている認証プロバイダのユーザーを使用してください。単一のEDQサーバーを使用している場合は、クラスタで実行してもメリットはありません。クラスタからサーバーを削除すると、デフォルト・ポートの8090が使用されます。

クラスタ内のサーバーごとに、管理ポートを変えたり、固定にしたりできます。(複数のサーバーが別々のマシンで実行されている場合は、同じポートを使用できます)。director.propertiesのoedq.local.homeバージョンを編集し、現在の管理ポートの設定を次の内容に置き換えます。

[expr]management.port = 8090 + servernum - 1

ここで、servernumは事前に計算された値で、edq_server1は1、edq_server2は2のようになります。この例では、edq_server1の管理ポートは8090で、edq_server2のポートは8091というようになります。

特定の管理対象サーバーのポートを使用するには、dnd.propertiesでのSiebel構成が必要になります。EDQを単一の管理対象サーバーとして実行し、WebLogicクラスタを使用していない場合、デフォルトの管理ポートは8090です。

任意の管理対象サーバーの管理(JMX)ポートを検出するには、Enterprise Manager Fusion Middleware Controlを使用して、次のようにします。

1. ドメインをクリックして、オプションのドロップダウン・リストを表示し、「システムMBeanブラウザ」を選択します。

2. 「アプリケーション定義のMBean」 > 「EDQ」 > 「サーバー: servername」 > 「ServerAccess」 > 「ServerAccess」に移動します。

3.2.8 前提

EDQは、指定されたサーバーのファイル・システムで多数のファイルを使用します。ほとんどの場合、たとえば、EDQ構成ディレクトリの大部分のファイルは、読取り専用でアクセスされ、変更されることはありません。そのため、複数のマシンでWebLogicドメインを圧縮および解凍することが可能です。

ただし、一部のタイプのEDQジョブ(特にバッチ・ジョブ)は、実行するために、EDQファイルのランディング領域にアクセスする必要があります。クラスタ・システムを適切に運用するには、別々のマシン上の管理対象サーバーがアクセスできるように、このファイルのランティング領域が共有ファイル記憶域(NFSなど)でマウントされている必要があります。つまり、ランディング領域のファイルによってジョブがトリガーされた場合、そのジョブはどのマシンのどの管理対象サーバーでも実行可能であり、あるEDQジョブが別のジョブで消費されるファイルをランディング領域に書き込んだ場合は、両方のジョブでランディング領域へのアクセスを共有しているため、どちらのジョブもどのマシンでも実行できるということです。

Fusion Middleware高可用性のベスト・プラクティスは、共有ファイル記憶域でドメイン全体をマウントすることで、そうすることにより、明示的にランディング領域を移動しなくても、この要件が満たされます。詳細は、Oracle高可用性ベスト・プラクティスを参照してください。

ランティング領域を明示的に共有記憶域に移動した場合、EDQアプリケーション・サーバーを実行するオペレーティング・システムのユーザー・アカウントに、その記憶域に対する読取りおよび書込みアクセス権が必要で、EDQローカル・ホーム・ディレクトリのdirector.propertiesを更新して、その記憶域を指すように次のプロパティを追加する必要があります。

landingarea=[path]

3.2.9 制限事項および例外

前に述べたように、通常の運用やほとんどのユースケースで、リポジトリ・データベースの可用性が中断しても、EDQリアルタイム・ジョブは稼働し続けます。これは、顧客データ・サービス・パックで提供されているすべてのリアルタイム・ジョブと、大部分のカスタム構成のリアルタイム・ジョブに当てはまります。

ただし、次の制限事項に注意してください。

- リアルタイム・ジョブが1つ以上の照合プロセッサを使用し、参照データまたはステージングされたデータの参照データ・ポートに対する入力との参照データ照合を実行する場合、プロセスで使用される照合プロセッサは、準備された参照データをメモリーにキャッシュするよう構成されている必要があります。これは、照合プロセッサの「拡張オプション」にあるシンプルなチェック・ボックスを使用して有効にします。

- リアルタイム・ジョブがケース管理にデータを公開する場合、データベースが再度使用可能になるまでメッセージが送信されません。リアルタイム・ジョブ自体は実行し続けます。

- リアルタイム・ジョブが、通常はメモリーにキャッシュされるステージングされたデータや参照データではなく、外部データベースを直接ルックアップする外部ルックアップを行う場合、ルックアップが失敗し、ルックアップ中のデータベースが再度使用可能になるまで、メッセージが送信されません。

- 同様に、リアルタイム・ジョブに、ステージングされたデータや参照データを使用した大規模な参照データ・セットが使用される場合、構成可能なキャッシュ制限を超え、メモリーにキャッシュできないと、ルックアップが失敗し、データベースが再度使用可能になるまでメッセージが送信されません。参照データ・セットをキャッシュできるデフォルトの最大行制限は100,000行ですが、EDQローカル・ホームのdirector.propertiesに次の行を追加することで変更できます。

resource.cache.maxrows = [rowlimit]

ここで、[rowlimit]は最大行数で、100000などです。

- リアルタイム・ジョブで外部レルムのユーザー・アカウントが使用される場合は、ユーザー詳細をルックアップするために接続可能なLDAPサーバーに依存します。

Oracleの法律上の注意点

コピーライト

Copyright © 1994-2017, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

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

保証免責

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

制限付権利について

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

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

危険な用途への使用について

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

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

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

Pre-General Availability (一般提供前)版のドキュメントについて

このドキュメントがPre-General Availability (一般提供前)版の場合:

このドキュメントはPre-General Availability (一般提供前)版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のPre-General Availability (一般提供前)版のドキュメントについて

このドキュメントが非公開のPre-General Availability (一般提供前)版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のPre-General Availability Trial Agreement (Pre-GAトライアル契約)のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle Partner Network 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)を参照してください。