| Oracle® Fusion Middleware Oracle Business Intelligence Publisher管理者ガイド 12c (12.2.1.4.0以降) E96098-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Business Intelligence Publisher管理者ガイド 12c (12.2.1.4.0以降) E96098-02 |
|
|
前 |
次 |
更新されたスケジューラのアーキテクチャでは、Java Messaging Service (JMS)キュー・テクノロジを使用します。
このアーキテクチャでは、複数の公開サーバーをクラスタに追加し、各サーバーを特定の機能(レポート生成、ドキュメント生成、または特定のデリバリ・チャネル)専用とすることができます。
スケジューラのアーキテクチャでは、JMSキューおよびトピックを使用して、非常にスケーラブルでパフォーマンスが高い、強力なレポート・スケジューリング配信システムを提供します。
次の図は、スケジューラ・アーキテクチャを示しています。
ジョブの発行時にスケジューラによって実行されるタスクは、次のとおりです。
ジョブの発行
クォーツ・テーブルにジョブ情報とトリガーを格納します
ジョブ・プロセッサ
クォーツ・トリガーが発動したときに、スケジューラ・ジョブ・キューにジョブ情報を配置します
バースティング・エンジン/バッチ・ジョブ・プロセス
バースティング・エンジン・リスナー
キューからスケジュールされたジョブ情報を取得します
データソースからデータを抽出します
バースティング分割の定義に従ってデータを分割します
一時フォルダにデータを一時的に格納します
レポート・キューにレポート・メタデータを配置します
バッチ・ジョブ・プロセス
キューからスケジュールされたジョブ情報を取得します
データソースからデータを抽出します
一時フォルダにデータを一時的に格納します
レポート・キューにレポート・メタデータを配置します
FOレポート・プロセッサ
レポートQをリスニングします
メタデータに基づいてレポートを生成します
共有された一時ディレクトリにレポートを格納します
配信キューにレポート配信情報を配置します
配信プロセッサ
配信キューをリスニングします
配信APIを呼び出して異なるチャネルに配信します
BI Publisher(BIP)システム・トピック
BIPシステム・トピックは、スケジューリング・エンジンの実行時間のステータスと状態を公開します。このトピックは、すべてのインスタンスのステータス、JMSキュー内のメッセージのスレッド・ステータス、すべてのスケジューラ構成(データベース構成、JMSキューのJNDI構成など)のステータスを公開します。
クラスタリングにより、サーバー・インスタンスをオンデマンドで追加して、処理および配信ロードに対応できます。
次の図はOracle WebLogic Serverのクラスタリングを示しています。レポート・リポジトリとスケジューラ・データベースが複数のインスタンスで共有されることにに注意してください。また、スケジューリング用のJMSキューと診断情報公開用のJMSトピックは、JMSキューとJMSトピックをJNDIサービス経由で登録することにより、サーバー全体で共有されます。
各管理対象サーバー・インスタンスは、同じレポート・リポジトリをポイントします。管理対象サーバーの各インスタンスで、ジョブ・プロセッサ、レポート・プロセッサ、電子メール・プロセッサ、FTPプロセッサ、FAXプロセッサおよび印刷プロセッサなどのすべてのプロセスが構成されます。このため、同じリポジトリをポイントするサーバー・インスタンスがデプロイされるとただちに、クラスタに追加され、このインスタンス内のすべてのプロセッサの実行準備が整います。
有効にするプロセスを任意のサーバー・インスタンスで選択できるので、リソースを最適に使用することができます。さらに、大量のジョブの処理が要求される場合には、レポート処理用のインスタンスを追加できます。同様に、電子メールの配信が最優先の配信チャネルの場合、インスタンスを追加して、電子メール配信をスケールアップできます。
フェイルオーバーのメカニズムでは、サーバーが使用できないためにレポートが配信に失敗しないようにします。
これを実現するには、クラスタ内の2つ以上のノードを使用してスケジューラの各プロセスのバランスを調整します。これにより、いずれかのノードで障害が発生しても、2つ目のノードでバックアップされるため、データが失われることはありません。たとえば、ジョブ・プロセッサを2つのノードで有効にすることにより、1つのノードで障害が発生しても、2つ目のノードでジョブを処理できます。
ノート:
1つのノードが停止した場合、他のノードがそのキューへのサービス提供を続行します。ただし、レポート・ジョブが、データ取得、データの書式設定またはレポートの配信のいずれかの実行の段階にある場合は、そのジョブは失敗としてマークされるため、手動で再発行する必要があります。
スケジューラを設定する前に考慮する必要のある特定のトピックがあります。
Oracle Business Intelligence Schedulerデータベース表を含むデータベースには最小ディスク領域が必要です。
最小ディスク領域要件は次のようになります。
スタンドアロンおよびBusiness Intelligenceアプリケーションとデプロイメントを使用するOracleデータベースおよびMicrosoft SQL Serverデータベースの場合、500MB。
スタンドアロン・デプロイメントを使用するIBM DB2データベースの場合、500MB。
レポートを格納するために、会社の使用目的に合った適切な量の領域を計算する必要があります。多数で大量なレポートの生成およびアーカイブ、たとえば、会社が1か月平均で合計2GBのファイル・サイズのレポートを生成し、1年分のXMLデータを保存する場合、ディスク上の要件は(2GB x 2 x 12 = 48GB)です。データベースにおけるBLOBおよびCLOBのサイズは、ファイル・システムのサイズと異なる場合がありますが、この計算により要件が概算できます。
デフォルトでは、BIプラットフォーム・インストーラによりWebLogic JNDI接続URLが構成されます。
JDBCは、本番用途にはお薦めされません。JDBCは、ローカルの低容量テストに対してのみ使用してください。
BI Publisherをインストールすると、WebLogic JMSを使用するようにスケジューラが自動的に構成されます。
かわりにActiveMQを使用するようにBI Publisherを構成するには、「ActiveMQ用のBI Publisherの構成」を参照してください。
ジョブの処理順序を構成できます。
複数のジョブを同時に実行する場合は、ジョブの優先度を設定し、優先度の高いレポート・ジョブを重要でないジョブの前に実行するようにできます。「レポート・プロパティ」ページの「一般」タブで、ジョブの優先度を「クリティカル」、「標準」または「低」の優先度に設定できます。ジョブがキューに待機しているときは、ジョブのレポートに指定されている優先度によってジョブの実行が決まります。ジョブの優先度を設定しないと、クリティカルなジョブとクリティカルでないジョブ、およびオンデマンド問合せの間でリソースの競合が発生してクリティカルなジョブに遅延が発生する可能性があります。「レポート・ジョブ履歴」ページで、クリティカルなジョブを識別するとともに各ジョブのステータスを表示できます。
BI Publisherでは、中断されたジョブをリカバリできます。
Oracle BIサーバーまたはBI Publisherが停止すると、長時間実行中のジョブが中断されることがあります。Oracle BIサーバーが再起動すると、BI Publisherは中断されたすべてのジョブを再開します。
ジョブがリカバリされると、BI Publisherは中断前に完了していた論理ポイントからジョブを再開し、中断前にジョブによってフェッチされたデータを使用します。
BI PublisherはOracle BI Serverの再起動前に失敗したジョブを回復できません。この場合は、失敗したジョブの手動による再発行が必要となる場合があります。
「レポート・ジョブ履歴」ページで、ジョブのステータス・アイコンにポインタを重ねると、リカバリの詳細が表示されます。
スケジューラが自動的に起動されると、特定の構成が行われます。
リポジトリ作成ユーティリティにより、スケジューラ・スキーマがデータベースにインストールされます。
JMSが公開用にサーバーに構成されます。
WebLogic JNDI URLが構成されます。
デフォルトでは、1つのプロセッサ当たりのスレッド数が5に設定されています。
構成は「スケジューラ構成」ページで「システム・メンテナンス」に表示されます。
共有ディレクトリは、ジョブの実行中にスケジューラで使用されるデータやファイルを一時的に保存する目的で使用されます。
ジョブが完了すると、ジョブの一時データは削除されます。BI Publisherスケジューラが様々なノードやマシンで実行されるように構成されている場合は、このディレクトリを定義する必要があります。このディレクトリは、BI Publisherの全ノードの間でデータやドキュメント情報の交換に使用されるため、すべてのBI Publisherのノードからアクセスできる必要があります。ディレクトリのサイズは、ジョブ・データの合計サイズ、出力ドキュメントおよび現在のジョブ数に依存します。このディレクトリは、パラレルで実行されるすべてのジョブのすべてのXMLデータおよびドキュメントを格納するのに十分なサイズにする必要があります。このディレクトリが構成されずにBI Publisherが様々なマシンで実行される場合は、スケジューラが失敗する可能性があります。
BI Publisherが単一のマシンで実行される場合は、共有ディレクトリの設定は任意です。BI Publisherはアプリケーション・サーバーの一時ディレクトリを使用してこのデータを保存します。
構成したクラスタ・インスタンスごとに、プロセッサ構成表が表示されます。この表を使用して、プロセッサの有効化と無効化を行い、プロセッサごとにスレッドを指定します。
各プロセッサのデフォルトのスレッド数は、次の図に示すように、「JMS構成」の「JMSプロセッサ当たりのスレッド」プロパティで設定されます。「クラスタ・インスタンス」リージョンで特定のプロセッサのスレッドを編集するには、「スレッド数」設定を更新します。デフォルト設定を使用するプロセッサの場合は、表にエントリが表示されないことに注意してください。特定のプロセッサに対してデフォルト値と異なるスレッド数を設定する場合にのみ、「スレッド数」の値を入力します。プロセッサ当たりの最適なスレッド数は、システムの要件によって異なります。
「スケジューラ診断」ページを使用して、システムの負荷を評価できます。「スケジューラ診断」を参照してください。
Oracle WebLogic Administration Consoleで管理対象サーバーを追加し、「管理」ページでクラスタ・インスタンスを構成します。
Oracle WebLogic管理コンソールでサーバーを管理します。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプおよび『Oracle Fusion Middlewareの管理』を参照してください。
管理対象サーバーを追加するには:
次の図に示すように、新しいサーバーが「サーバー」表に表示されます。
「スケジューラ診断」ページはスケジューラの実行時のステータスを提供します。また、そのJMS構成、JMSキュー、クラスタ・インスタンス・ステータス、スケジューラ・データベース・ステータス、Toplinkステータスおよびスケジューラ(クォーツ)ステータスを提供します。
診断ページには、JMSキューがそれまでに受信したスケジュール済レポート・リクエスト数と、その中で失敗したリクエスト数および実行中のリクエスト数が表示されます。JMSステータスをクラスタ・インスタンスのレベルで表示できるので、インスタンスを追加して1つ以上のJMSプロセッサを増やし、スケールアップするべきかどうかを判断できます。
たとえば、キューに待機している電子メール・プロセッサに対する要求数が1つのインスタンスでは多すぎる場合、電子メールの処理に対処できるようにするためにもう1つのインスタンスを追加することを検討できます。同様に、非常に多くのレポートが処理中になっており、レポート・プロセス・キューで実行中ステータスで表示されている場合、もう1つのインスタンスを追加してレポート・プロセス機能をスケールアップできます。
また、「スケジューラ診断」ページには各コンポーネントのステータスが反映され、ダウンしたコンポーネントがあるかどうかが示されます。データベースへの接続文字列またはJNDI名、どのクラスタ・インスタンスがどの管理対象サーバー・インスタンスに関連付けられているか、Toplink接続プール構成などを確認できます。
特定のインスタンスが失敗ステータスを示している場合は、インスタンスの回復ができます。その場合も、クラスタのJMS設定のフェイルオーバー・メカニズムがあるため、発行済のジョブが失われることはありません。サーバー・インスタンスが元の状態に戻ると、そのインスタンスはすぐにクラスタ内でサービスに使用できる状態になります。インスタンスの削除と追加は診断ページに動的に反映されます。
クラスタにインスタンスを追加すると、「スケジューラ診断」ページではただちにその新しいインスタンスが認識され、新しいインスタンスのステータスとそのインスタンス上で実行されているすべてのスレッドが表示されます。これは、管理者に強力な監視機能を提供し、いずれかのインスタンスまたはスケジューラのコンポーネントで問題が発生した場合にその問題を追跡して解決することができます。
「スケジューラ診断」ページには、次のコンポーネントに関する情報が表示されます。
JMS
クラスタ
データベース
スケジューラ・エンジン
「JMS」セクションは、次に項目に関する情報を提供します。
JMSクラスタ構成: このセクションは、JMS設定の構成情報を提供します。
プロバイダ・タイプ(WebLogic/ActiveMQ)
WebLogicのバージョン
WebLogic JNDIファクトリ
JMS用のJNDI URL
キュー名
一時ディレクトリ
JMSランタイム: 次の表に示すように、これはすべてのJMSキューおよびトピックの実行時ステータスを示します。
「クラスタ」セクションは、次の図に示すように、クラスタ・インスタンスに関する詳細情報を提供します。この情報を使用して、各プロセッサの負荷を把握します。
JMSインスタンス構成
JMS Wrapper
JMS Client – System - BIPのSystemトピックのステータスを提供します。「スケジューラ診断」ページは、このトピックに対するサブスクライバです。
JMS Client_producer: このリリースでは使用されません。
JMS Client_schedule: ジョブ・プロセッサとレポート・プロセッサのステータスを示します。プロセッサごとに、アクティブなスレッド数、受信したメッセージ数、失敗したメッセージ数および実行中のメッセージ数が表示されます。
JMS Client_delivery: リスナーとしての様々な配信プロセッサのステータスを示します。配信プロセッサごとに、アクティブなスレッド数、受信したメッセージ数、失敗したメッセージ数および実行中のメッセージ数が表示されます。
「データベース」セクションは、次の図に示すように、これらのコンポーネントに関する情報を提供します。
データベース構成: 接続タイプ、JNDI名、または接続文字列
Toplink構成: 接続プーリング、ロギング・レベル
データベース・スキーマ
Quartzセクションは、次の図に示すように、これらのコンポーネントに関する情報を提供します。
Quartz構成
Quartz初期化
「スケジューラ診断」ページでよく見られるQuartz構成のエラーを次に示します。
エラーの説明と解決
BI Publisherの起動中(WebLogic管理対象サーバーまたは管理サーバーの起動時)に、jdbc/bip_datasourceとして構成されたJNDIデータソースが使用できない場合、Quartzの初期化が失敗します。「スケジューラ診断」ページには、Quartz構成のエラーが表示されます。
これが発生した場合は、次の手順を実行します。
jdbc/bip_datasourceとして構成されているデータソースが使用可能かどうかを確認します。「スケジューラ構成」ページで、「接続のテスト」をクリックして接続が機能していることを確認します。