| Oracle® Fusion Middleware Oracle Business Intelligence Publisher管理者ガイド 12c (12.2.1.3.0) E80600-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Business Intelligence Publisher管理者ガイド 12c (12.2.1.3.0) E80600-02 |
|
|
前 |
次 |
内容は次のとおりです。
11g BI Publisherスケジューラの最新のアーキテクチャでは、Java Messaging Service(JMS)キュー技術を使用しています。
このアーキテクチャを使用して、複数のBI Publisherサーバーをクラスタに追加してから各サーバーを特定の機能専用のサーバーに指定することができます(レポート生成、ドキュメント生成、特定の配信チャンネルなど)。
BI Publisherスケジューラのアーキテクチャでは、JMSキューおよびトピックを使用して、高スケーラブルかつ高性能で強固なレポート・スケジューリングおよび配信システムを提供します。
次の図は、スケジューラ・アーキテクチャを示しています。
ジョブの発行時にスケジューラによって実行されるタスクは、次のとおりです。
ジョブの発行
クォーツ・テーブルにジョブ情報とトリガーを格納します
ジョブ・プロセッサ
クォーツ・トリガーが発動したときに、スケジューラ・ジョブ・キューにジョブ情報を配置します
バースティング・エンジン/バッチ・ジョブ・プロセス
バースティング・エンジン・リスナー
キューからスケジュールされたジョブ情報を取得します
データソースからデータを抽出します
バースティング分割の定義に従ってデータを分割します
一時フォルダにデータを一時的に格納します
レポート・キューにレポート・メタデータを配置します
バッチ・ジョブ・プロセス
キューからスケジュールされたジョブ情報を取得します
データソースからデータを抽出します
一時フォルダにデータを一時的に格納します
レポート・キューにレポート・メタデータを配置します
FOレポート・プロセッサ
レポートQをリスニングします
メタデータに基づいてレポートを生成します
共有された一時ディレクトリにレポートを格納します
配信キューにレポート配信情報を配置します
配信(電子メール、ファイル、FTP)プロセッサ
配信キューをリスニングします
配信APIを呼び出して異なるチャネルに配信します
BI Publisher(BIP)システム・トピック
BIPシステム・トピックは、スケジューリング・エンジンの実行時間のステータスと状態を公開します。このトピックは、すべてのインスタンスのステータス、JMSキュー内のメッセージのスレッド・ステータス、すべてのスケジューラ構成(データベース構成、JMSキューのJNDI構成など)のステータスを公開します。
BI Publisherクラスタリング・サポートを使用すると、サーバー・インスタンスをオンデマンドで追加して、処理と配信の負荷に対応することができます。
次の図はOracle WebLogic Serverのクラスタリングを示しています。レポート・リポジトリとスケジューラ・データベースが複数のインスタンスで共有されることにに注意してください。また、スケジューリング用のJMSキューと診断情報公開用のJMSトピックは、JMSキューとJMSトピックをJNDIサービス経由で登録することにより、サーバー全体で共有されます。
各管理対象サーバー・インスタンスは、同じレポート・リポジトリをポイントします。管理対象サーバー・インスタンスごとに、すべてのプロセス(ジョブ・プロセッサ、レポート・プロセッサ、電子メール・プロセッサ、FTPプロセッサ、FAXプロセッサ、ファイル・プロセッサ、印刷プロセッサおよびWebDavプロセッサ)が構成されます。このため、同じリポジトリをポイントするサーバー・インスタンスがデプロイされるとただちに、クラスタに追加され、このインスタンス内のすべてのプロセッサの実行準備が整います。
有効にするプロセスを任意のサーバー・インスタンスで選択できるので、リソースを最適に使用することができます。さらに、大量のジョブの処理が要求される場合には、レポート処理用のインスタンスを追加できます。同様に、電子メールの配信が最優先の配信チャネルの場合、インスタンスを追加して、電子メール配信をスケールアップできます。
『高可用性ガイド』を参照してください。
BI Publisherは強固なフェイルオーバー・メカニズムを備えているので、サーバーを使用できないことが原因でレポートが配信できなくなることはありません。
これを実現するには、クラスタ内の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プラットフォーム・インストーラを使用してBI Publisherをインストールしてから、サーバーを起動すると、BI Publisherスケジューラの実行が開始され、特定の構成が行われます。
インストール前の手順として、リポジトリ作成ユーティリティによってスケジューラ・スキーマがデータベースにインストールされます。
JMSが、サーバー内でBI Publisher用に構成されます。
WebLogic JNDI URLが構成されます。
デフォルトでは、1つのプロセッサ当たりのスレッド数が5に設定されています。
『Oracle Business Intelligenceのインストールと構成』を参照してください。
この構成は、「スケジューラ構成」ページ(「管理」ページの「システム・メンテナンス」で、「スケジューラ構成」をクリック)で参照できます。次の図は、「スケジューラ構成」ページの「データベース接続」および「JMS構成」リージョンを示しています。
共有ディレクトリは、ジョブの実行中にスケジューラで使用されるデータやファイルを一時的に保存する目的で使用されます。
ジョブが完了すると、ジョブの一時データは削除されます。BI Publisherスケジューラが様々なノードやマシンで実行されるように構成されている場合は、このディレクトリを定義する必要があります。このディレクトリは、BI Publisherの全ノードの間でデータやドキュメント情報の交換に使用されるため、すべてのBI Publisherのノードからアクセスできる必要があります。ディレクトリのサイズは、ジョブ・データの合計サイズ、出力ドキュメントおよび現在のジョブ数に依存します。このディレクトリは、パラレルで実行されるすべてのジョブのすべてのXMLデータおよびドキュメントを格納するのに十分なサイズにする必要があります。このディレクトリが構成されずにBI Publisherが様々なマシンで実行される場合は、スケジューラが失敗する可能性があります。
BI Publisherが単一のマシンで実行される場合は、共有ディレクトリの設定は任意です。BI Publisherはアプリケーション・サーバーの一時ディレクトリを使用してこのデータを保存します。
構成したクラスタ・インスタンスごとに、プロセッサ構成表が表示されます。この表を使用して、プロセッサの有効化と無効化を行い、プロセッサごとにスレッドを指定します。
各プロセッサのデフォルトのスレッド数は、次の図に示すように、「JMS構成」の「JMSプロセッサ当たりのスレッド」プロパティで設定されます。「クラスタ・インスタンス」リージョンで特定のプロセッサのスレッドを編集するには、「スレッド数」設定を更新します。デフォルト設定を使用するプロセッサの場合は、表にエントリが表示されないことに注意してください。特定のプロセッサに対してデフォルト値と異なるスレッド数を設定する場合にのみ、「スレッド数」の値を入力します。
プロセッサ当たりの最適なスレッド数は、システムの要件によって異なります。「スケジューラ診断」ページを使用して、システムの負荷を評価できます。「スケジューラ診断」を参照してください。
システムに管理対象サーバーを追加するには、「管理対象サーバーの追加」を参照してください。
Oracle WebLogic管理コンソールで管理対象サーバーを追加して、BI Publisherの「管理」ページでクラスタ・インスタンスを構成します。
Oracle WebLogic管理コンソールでサーバーを管理します。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプおよび『Oracle Fusion Middlewareの管理』を参照してください。
管理対象サーバーを追加する手順は次のとおりです。
次の図に示すように、新しいサーバーが「サーバー」表に表示されます。
このトピックでは、ジョブ優先度の設定とクリティカル・ジョブの処理について説明します。
12.2.1.3より前のリリースのBI Publisherでは、クリティカル・ジョブ、クリティカルでないジョブおよびオンデマンド問合せがリソースを取り合っていました。次の理由で、クリティカル・ジョブが遅れたり、ジョブが完了しないことがありました。
メモリー不足
外部システムを使用できない
すべてのジョブが先入れ先出し(FIFO)順である
BI Publisher 12.2.1.3の内容:
レポート優先度の設定
中断されたジョブのリカバリ
ジョブの優先度
「レポート・プロパティ」ページで、クリティカル、標準または低優先度をレポートに割り当てることができます。BI Publisherは、JMS優先度を設定し、優先度に基づいてスケジュール・レポート・ジョブをソートするので、優先度の高いレポート・ジョブをクリティカルでないジョブの前に実行できます。『Oracle Business Intelligence Publisherレポート・デザイナーズ・ガイド』のレポート・プロパティの設定に関する項を参照してください。
「レポート・ジョブ履歴」ページでは、クリティカル・ジョブを簡単に特定して、各ジョブのステータスを表示できます。『Oracle Business Intelligence Publisherユーザーズ・ガイド』のレポート・ジョブ履歴と保存された出力の表示に関する項を参照してください。
ジョブ・リカバリ
Oracle BI管理対象サーバーまたはBI Publisherが停止すると、長時間実行中のジョブが中断されることがあります。Oracle BI管理対象サーバーが再起動すると、BI Publisherは中断されたすべてのジョブを再開します。ジョブが回復されると、BI Publisherは中断前に完了していた論理ポイントからジョブを再開し、中断前にジョブによってフェッチされたデータを使用します。
BI Publisherでは、中断されたジョブを再開できない場合、そのジョブを新規ジョブとして再実行します。BI PublisherはOracle BI Serverの再起動前に失敗したジョブを回復できません。この場合は、失敗したジョブの手動による再発行が必要となる場合があります。
「レポート・ジョブ履歴」ページで、ジョブのステータス・アイコンにポインタを重ねると、リカバリの詳細が表示されます。
「スケジューラ診断」ページはスケジューラの実行時のステータスを提供します。また、その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として構成されているデータソースが使用可能かどうかを確認します。「スケジューラ構成」ページで、「接続のテスト」をクリックして接続が機能していることを確認します。