Oracle Business Activity Monitoring 12cのチューニング

3.1 スキーマ設計のチューニング

Oracle BAM 12cはスター・スキーマをサポートしています。論理データ・オブジェクト(LDO)を介して結合をサポートしています。LDOを使用すると、1つのファクト表を複数のDIM、つまりディメンション表に結合でき、LDO上で、問合せを実行できます。

アーカイブされたリレーションがあるLDOの上部でアクティブ・データが使用されている場合、最高のパフォーマンスを実現するには、いくつかの点を考慮する必要があります。これらの条件の概要は、次のとおりです。これらは、12cに切り替えたときのパフォーマンスの強化に役立つベスト・プラクティスであり、推奨事項として扱う必要があることに注意してください。

DIMへの変更が少ない場合(1日1回など)は、DIM表を「緩やかに変化するディメンション」としてマークすることをお薦めします。「緩やかに変化するディメンション」でマークすると、結合メモリー拡張機能が作用して、必要なヒープ容量が減少し、問合せ起動時間も増加します。
DIM表を「緩やかに変化するディメンション」としてマークできるように、適切なDIM表のサイズ(たとえば、10k未満 – ルックアップのみに使用)を維持し、DIM表へのバッチ更新を行って頻繁な更新を回避することをお薦めします。DIM表がファクト表と同じペースで増加している場合は、ファクト表のディメンション列を維持することをお薦めします。
複数のDIMには複雑な結合が必要であるため、必要なDIMがあるファクト表のみを結合することをお薦めします。DIM表を統合して、結合の数を減らします。
フィルタを使用してLDOを設計し、戻されるデータの量を減らすことをお薦めします。これにより、アーカイバ問合せの実行に必要なTEMP表領域が減少します。
問合せで計算済フィールドを使用して、FACT DOで必要な列数を減らすことをお薦めします。ファクト表の列として必要な内容のみを維持します。これにより、メモリーへの列の追加が不要になるため、アクティブな問合せおよびCQLテンプレート問合せがさらに効率的になります。
11g Oracle DBを使用している場合、パフォーマンスを向上させるには、セキュア・ファイルを使用することをお薦めします。詳細は、セキュア・ファイルの使用に関する項を参照してください。
キー・フィールドに対して索引を作成することをお薦めします。BAMデータ・オブジェクトを使用して、索引を作成できます。詳細は、索引方針の選択に関する項を参照してください。

3.2 ダッシュボード設計とデプロイメントのチューニング

Oracle Business Activity Monitoring 12cは、最適なパフォーマンスのための強化されたダッシュボード機能を備えています。

最適なパフォーマンスを保証するために、次のベスト・プラクティスが推奨されます。最適なダッシュボード・パフォーマンスのために、次のベスト・プラクティスを推奨事項として扱ってください。

特定のユーザー・グループ用のダッシュボードが設計されていることを確認します。汎用のダッシュボードは作成しないようにしてください。
「例外による管理」のレポートを作成します。
様々なユーザー・ロールを処理するユーザーが操作の状態を一目で理解できるようにし、ドリルダウンを提供します。
論理データ・オブジェクトのフィルタ・パラメータおよびダッシュボード・パラメータを使用して、ダッシュボードのロード前にデータをフィルタします。
1つのダッシュボードを、4から6のビューに限定するか、複数のタブがある1つのビューに限定します。
各ダッシュボードのセルにある「ダッシュボード・アクション」ボタンを効率的に使用します。

多数の詳細レコードを回避するには、できるだけ要約や集計を使用し、そこから詳細レコードへのドリルダウンを提供します。
表ビューおよびリスト・ビューには、パフォーマンスの制限がいくつかあります。Oracle BAMシステムの上限は10420レコードですが、リスト・ビューのリスト数は2000レコードに制限することをお薦めします。該当する場合、ドリルダウン可能なディメンションまたは時間階層は、詳細レコードを戻すノードに達するまで定義します。また、多数のレコードを取得しているときは、BAMサーバー用のメモリー設定を増加する(最大6GBを推奨)ようにします。
設計およびベスト・プラクティスについては、Oracle Tech Networkのデモを使用してください。
アクティブ・データの間隔およびスロットルは、メモリーの影響があるため、注意して選択してください。

3.3 問合せ設計のチューニング

Oracle BAM 12cでは、アクティブな問合せと非アクティブな問合せが、ベスト・プラクティスの対象となります。

ビジネス問合せの最適なパフォーマンスのために、次のベスト・プラクティスをお薦めします。

戦略的(非アクティブ)な問合せの場合は、ビジネス問合せによって生成された問合せ文字列を調査し、DB AWRレポートを実行して索引をチューニングするか、問合せを変更してパフォーマンスを向上させます。
アクティブな問合せの場合は、必要なメモリーの量が減少するため、常にウィンドウ・サイズ(範囲)を指定します。また、出力ウィンドウ(スライディング)を慎重に使用して、ダッシュボードへの負荷がないように結果を縮小します。
集計問合せを使用して、その問合せをチャートにバインドします。次に、詳細レコードへのドリルダウンを実行します。これによって、データがより小さいチャンクに編成され、パフォーマンスが向上します。
本番のデータ・セットを使用して問合せをテストし、パフォーマンスが適切であることを確認します。
スケジュールされた問合せとリアルタイムのアクティブな問合せの相違をよく理解し、これらの問合せを適切に使用します。

3.4 データのアーカイブとパージのチューニング

Oracle BAM 12cでは、最適なパフォーマンスのためにデータをアーカイブおよびパージするベスト・プラクティスをお薦めします。

必要なデータのみをデータ・オブジェクトに保持します。操作モニタリングおよびアクションの実行に関連するすべてのデータは、データ・オブジェクト・ストレージの候補になります。
履歴目的で古いデータを同じデータ・オブジェクトに保持しないでください。履歴データを使用可能にする必要がある場合は、特定のレポートに使用される別のデータ・オブジェクトにそのデータを転送します。
データ保持は、アラートを使用して、ピーク時間外にスケジュールします。このタスクにおいて管理者である場合、すべてのBAMビューセットおよび連続した問合せは、状態がメモリーに保持されているため、停止できます。
パージの前にデータをアーカイブすることが要件である場合、Oracle Data IntegratorサービスをBAM 12cとともに使用します。
アラートを使用して、フィルタ・ベースのパージを制御します。カスタム・アクションをアラートに指定して、さらにカスタマイズされたパージを実行することもできます。
パージとデータ・インジェクションが同時に発生する場合、データベース・パーティション機能を使用して、パフォーマンスを向上させます。詳細は、Oracle Database VLDBおよびパーティショニング・ガイドのパーティション化の概念を参照してください。

3.5 スケーラビリティとパフォーマンスのチューニング

Oracle BAM 12cでは、最適なパフォーマンスとスケーラビリティについて、ベスト・プラクティスをお薦めします。

Oracle BAM 12cは、高可用性およびスケーラビリティに対応するように設計されています。高可用性およびスケーラビリティは、サーバーを追加することで増やすことができます。あるサーバーに障害が発生した場合、より状態のよいサーバーを提供してフェイルオーバーすることで、追加サーバーによる高可用性が増加します。1つのBAMサーバーが実行されているかぎり、BAMは継続して機能します。追加サーバーによって、BAMクラスタ内の使用可能なすべてのサーバー間で作業がロード・バランスされるため、より優れたスループットが実現します。詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』を参照してください。
入力スケーラビリティについては、異なるサーバーで複数のEMSを起動して、スループットを改善できます。
顧客は、パフォーマンスを向上させるためにバッチ機能の使用を検討する必要があります。詳細は、「複数のイベントを単一の操作にグループ化するバッチング操作」を参照してください。
CQL問合せは、プロジェクトをベースとして使用して、ロード・バランスされます。特定のプロジェクトに対するすべての問合せは、同じサーバー上に存在します。CQL問合せは、サーバーがクラッシュすると他のサーバーに移動されます。
CQL問合せは、大量のヒープ・メモリーが必要になる傾向があるため、その数を制限します。
Oracle BAMが、専用マシンのそれ自体のクラスタ内に存在することを確認します。ソリューションにBPELまたはBPMが含まれている場合、BPELとそのストレージ用に別のマシンを使用して、競合を回避します。
高可用性ソリューションの場合、サーバーが同じネットワーク上にあることを確認します。
BAMへのデータのプッシュにWebサービス・インタフェースが使用されている場合、アプリケーション・コンテキストがOracle BAM Webサービスのものと同じであることを確認します。
索引、日単位パーティション表、パラレル実行の追加を含めて、データベースを完全にチューニングし、DBIM (Database In-Memory)を使用します。DBIMでは、必要な列(列型ストレージ)のみがアクセスの対象となるため、データへのアクセスが高速化されます。さらに、フィルタリングは発生するがフィルタが選択的ではない場合、DBIMは、列ごとに索引があるようなものになります。簡単な集計を実行する問合せの場合、DBIMでは集計を加速させることもできます。

3.6 Oracle BAMのリアルタイム・データ・ソース

Oracle BAMには、Oracle WebLogic Server (WLS)で使用できるリアルタイム・データ・ソースが用意されています。

これらのデータ・ソースは次のとおりです。

Oracle BAMアダプタ
Oracle Webサービス
Java Message Service
Oracle® Data Integrator
Enterprise Java Beans

3.7 本番ロールアウトのチューニング

提案された構成を使用して本番前にテスト・チェックリストをロードすることをお薦めします。

チェックリストでは、いくつかの構成およびロード・テストについて概説します。

Javaメッセージング・サービスと自動サービス管理の構成がOracleのエンタープライズ・デプロイメント・ガイドに従っていることを確認してください。

図jms-server.gifの説明
ロード・バランサの構成が正しいことを確認します。「WebLogicプラグインの有効化」に正しい値を設定します。クラスタがプロキシ・プラグインまたはHttpClusterServletからのリクエストを受信する場合、「はい」を選択します。getRemoteAddrを呼び出すと、Webサーバーではなく、独自のWL-Proxy-Client-IPヘッダーからブラウザ・クライアントのアドレスが戻されます。config.xmlファイルのweblogic-plugin-enabledパラメータを無効にする(weblogic-plugin-enabled=false)場合、「いいえ」を選択します。このクラスタがドメインの「WebLogicプラグインの有効化」に選択した値を継承する場合、「継承」を選択します。
Enterprise Messaging Service (EMS)で永続性構成を確認します。スレッドが多すぎると、競合の原因になる場合があります。少なすぎると、スループットが低下する場合があります。20スレッドから開始し、スループットに基づいてチューニングすることをお薦めします。
アプリケーション・ロールが正しく定義されていることを確認してください。
JVMパラメータが適切にチューニングされていることを確認してください。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverのパフォーマンスのチューニング』を参照してください。
ダッシュボードが、異なるデバイス上の高い本番ロードでも正しく表示されることを確認してください。

ロード・テスト

ロード・テストに使用する指針は、次のとおりです。

Oracle Enterprise Single Sign-on Logon Managerを使用して、ログインするユーザーをシミュレートします。これを行うには、大まかに次のテストを使用します。
- 30秒ごとに2人の頻度で、20人の仮想ユーザーを開始し、これを20分間実行します。
- 次に、すべての仮想ユーザーを、5秒ごとに2人の頻度で停止します。
- ビューセットの監視機能を使用して、このアクティビティを監視します。
EMSクライアントを使用して、システムへのデータ・ポンプを実行します。複数のEMSサーバーを起動します。各EMSサーバーが異なる管理対象サーバーにデプロイされていることを確認します。
スループットを監視します。データ・オブジェクトの作成日付列に基づいて、x軸上に時系列を作成することによって、BAMビジネス問合せを使用します。
Java VisualVMツールを使用すると、ヒープ、メモリーおよびCPUの使用率を監視できます。
自動ワークロード・リポジトリ・レポートを使用して、デッドロックの有無を確認します。SQL実行時間も確認して、索引の作成や変更が必要かどうかを判断します。
寿命テストを実行します。EMSを使用して、システムを最低5日間実行します。システムを連続的なロードの対象とし、毎日パージを実行し、仮想ユーザーの出入りを確認します。
フェイルオーバー時には、1つのサーバーを停止してパフォーマンスを監視し、パフォーマンスに関するすべての問題が検出されて修正された後、そのサーバーをバックアップにします。再起動時には、サービスを手動でサーバーに移行して戻します。