JohnBoyerとMikeNorrisによるブログ。
概要
Cognos監査機能を使用して、ユーザーコミュニティでCognosがどのように使用されているかを把握および理解し、次のような質問に答えることが重要です。
-
- 誰がシステムを使用していますか？
- 彼らはどのようなレポートを実行していますか？
- レポートの実行時間はどのくらいですか？
- のような他のツールの助けを借りて MotioCI、どのコンテンツが未使用ですか？
健全なCognosAnalytics環境を維持することがいかに重要であるかを考えると、驚くべきことに、標準の製品ドキュメント以外に監査データベースについて書かれたものはほとんどありません。 おそらくそれは当然のことですが、それを使用する組織は、監査データベーステーブルのクエリが時間の経過とともに遅くなり始めることを知っています。特に、組織に多くのレポートを実行する多くのユーザーがいて、多くの履歴がある場合はそうです。 さらに、監査アクティビティのログ自体は、データベースに十分な速度で追加できない場合などにキューに入れられるため、遅延する可能性があります。 そのとき、レポート要件のある運用データベースの場合と同じように、データベースのパフォーマンスについて考え始めます。
通常、テーブルが大きいとクエリのパフォーマンスが低下します。 テーブルが大きいほど、挿入とクエリに時間がかかります。 これらのテーブルと監査データベースは基本的に運用データベースであることに注意してください。 データマートの場合のように読み取り操作のみに焦点を合わせることができないため、書き込みは頻繁に発生し、私たちに不利に働きます。
コンテンツストアと同様に、Cognos環境の状態も監査データベースの状態を考慮に入れる必要があります。 監査データベースの無制限の拡張は、時間の経過とともに問題になる可能性があり、最終的にはCognos環境の全体的なパフォーマンスに影響を与える可能性があります。 外部規制が課せられている多くの組織では、完全な監査記録がないと、コンプライアンス違反の状況に陥り、大きな影響を与える可能性があります。 では、履歴監査の目的で（場合によっては最大10年）大量のデータを維持する必要があるにもかかわらず、環境を維持し、ユーザーがパフォーマンスに満足できるようにするために必要なレポートを取得するにはどうすればよいでしょうか。
チャレンジ
-
- 監査データベースの無制限の増加は、Cognos環境の健全性に悪影響を及ぼしています
- 監査データベースからのレポートが遅くなったり、使用できなくなったりしました
- Cognosで、監査データベースへのレコードの書き込みが遅れる
- 監査データベースのディスク容量が不足しています
これはすべて、監査データベースに依存するレポートだけでなく、多くの場合システム全体が影響を受けることを意味します。 監査データベースがCognosContent Storeと同じサーバー上にある場合、Cognosのすべてのパフォーマンスがその環境で影響を受けます。
セットアップ
私たちは仮定します：
-
- CognosAnalyticsがインストールされて実行されている
- Cognosは、監査データベースにログを記録するように構成されています
-
- 監査データベースを設置する
- Cognos管理で適切な監査ログレベルを設定する
- レコードはCognosによってデータベースに書き込まれています
- 監査データベースはXNUMX年以上使用されています
- 環境はユーザーと実行で非常にアクティブです
- 監査パッケージは、Cognosの使用状況データを表示するために使用されています
- 監査データベースのレポートパフォーマンスの向上を目指しています
- 古いレコードを最初からやり直したり削除したりすることは、常にオプションであるとは限りません。
Cognos Auditをまだインストールおよび構成していない場合は、Lodestar Solutions、 Motio パートナー、優れた 役職 Cognos BI / CAでの監査の有効化について。
ソリューション
すぐに現れるいくつかの可能な解決策があります：
-
- 次の方法でデータの量を減らします。
-
- 古いデータの一部を別のデータベースに移動する
- 古いデータの一部を同じデータベース内の別のテーブルに移動する
- 削除またはアークするだけhive 一部のデータについては心配しないでください
- それと一緒に暮らす。 缶を蹴り落とす road パフォーマンスのためにデータベース管理者をプッシュします
スキーマの変更を許可しないことによる手錠をかけながらの改善または
インデックス
オプション3については扱いません。オプション2、データの削除は適切なオプションではないため、少なくとも18か月分の価値を維持することをお勧めします。 しかし、もしあなたがそんなに傾いているなら、IBMはユーティリティを提供します、 AuditDBクリーンアップ （Cognos BI）または スクリプト （Cognos Analytics）これはまさにそれを行います。 Cognos BIのユーティリティはタイムスタンプに基づいてレコードを削除しますが、CognosAnalyticsのスクリプトはインデックスとテーブルを削除するだけです。
これに関して以前にクライアントに対して行った推奨事項は、XNUMXつのデータベースに分割することでした。
-
- 監査–ライブ：直近のXNUMX週間分のデータが含まれています
- 監査–履歴：履歴データが含まれます（最大N年）
つまり、プロセスは毎週実行され、最新のレコードをAuditLiveからAuditHistoricalに移動します。 このプロセスが実行された後、AuditLiveは白紙の状態で最初からやり直します。
-
- Live DBは高速でタイトなため、挿入を可能な限り高速に行うことができます
- 監査クエリは、履歴DBにのみ送信されます
このアプローチを使用すると、ライブデータと履歴データの暗黙的な「ステッチ」はありません。 私はあなたがおそらくそれをそのように保ちたいと思うだろうと主張するでしょう。
Cognos Administrationでは、監査データソースにXNUMXつの異なる接続を追加できます。 ユーザーがAuditパッケージに対してレポートを実行すると、使用する接続の入力を求められます。
過去の監査データではなくライブ監査データを確認したい場合は、プロンプトが表示されたら「監査-ライブ」接続を選択するだけです（これは例外であり、標準ではありません）。
ライブと履歴の両方の統合ビューも本当に提供したい場合は、そうすることもできますが、パフォーマンスに影響を与えます。
たとえば、「Audit – Consolidated View」という3番目のデータベースを作成してから、Auditスキーマのテーブルごとに次のようにします。ライブDBのテーブルとライブDBのテーブルの間のSQLユニオンである同じ名前のビューを作成します。履歴DB。 同様に、これはFramework Managerモデルでも実現できますが、やはりパフォーマンスが重要な考慮事項になります。
一部のクライアントは、統合されたビューを作成しました。 これはおそらくやり過ぎだと私たちは考えています。 この統合ビューではパフォーマンスが常に低下し、ライブデータセットと履歴の両方を使用する多くのユースケースに遭遇したことはありません。 トラブルシューティングに使用されているライブとトレンドレポートの履歴。
Cognos Analytics 11.1.7の時点で、監査データベースは21テーブルに拡張されています。 詳細については、監査データベース、サンプル監査レポート、およびFrameworkManagerモデルを参照してください。 デフォルトのログレベルは最小ですが、次のレベルである基本を使用して、使用要求、ユーザーアカウント管理、および実行時の使用状況をキャプチャすることをお勧めします。 システムパフォーマンスを維持するXNUMXつの方法は、ログレベルを必要な最低レベルに維持することです。 明らかに、サーバーによって実行されるロギングが多いほど、サーバー全体のパフォーマンスに影響を与える可能性があります。
ほとんどの管理者が関心を持つ重要なテーブルは、システム内のユーザーアクティビティとレポートアクティビティをログに記録する6つのテーブルです。
- COGIPF_USERLOGON：ユーザーのログオン（ログオフを含む）情報を保存します
- COGIPF_RUNREPORT：レポートの実行に関する情報を格納します
- COGIPF_VIEWREPORT：レポートビュー要求に関する情報を格納します
- COGIPF_EDITQUERY：クエリの実行に関する情報を格納します
- COGIPF_RUNJOB：ジョブリクエストに関する情報を格納します
- COGIPF_ACTION：ユーザーアクションをCognosに記録します（このテーブルは他のテーブルよりもはるかに急速に大きくなる可能性があります）
すぐに使用できる構成は次のようになります。
推奨される構成：
Cognos Audit Database – Liveには、1週間の監査データが含まれています。 1週間より古いデータは、Cognos Audit Database –Historicalに移動されます。
図のCognosAudit Database –LiveからCognosAudit Database –Historicalまでの行は次の役割を果たします。
- ライブ監査から履歴監査へのデータのコピー
- 1週間より古いライブ監査のすべての行を削除します
- x年より古い履歴監査のすべての行を削除します
- 6か月より古いCOGIPF_ACTIONのすべての行を削除します
インデックス
データベースの種類が異なれば、インデックスの種類も異なります。 データベースインデックスは、テーブル（またはビュー）に関連付けられたデータ構造であり、そのテーブル（またはビュー）からデータを取得するときにクエリの実行時間を改善するために使用されます。 DBAと協力して、最適な戦略を作成します。 インデックスを作成する列について最善の決定を下すために、このような質問に対する回答を知りたいと思うでしょう。 明らかに、データベース管理者はあなたの助けなしにこれらの質問のいくつかまたはすべてに対する答えを見つけることができますが、それはいくつかの調査と時間がかかります：
- テーブルにはいくつのレコードがあり、どのくらいのサイズになると思いますか？ （テーブルに多数のレコードがない限り、テーブルのインデックス付けは役に立ちません。）
- どの列が一意であるか知っていますか？ NULL値を許可しますか？ どの列のデータ型が整数または大きな整数ですか？ （数値データ型を持ち、UNIQUEおよびNOT NULLである列は、索引キーに参加する有力な候補です。）
- 今日の主なパフォーマンスの問題はどこにありますか？ 彼らはデータを取得していますか？ より問題となる特定のクエリやレポートはありますか？ （これにより、データベース管理者は、最適化できる特定の列に移動する可能性があります。）
- レポート用のテーブルの結合に使用されるフィールドは何ですか？
- フィルタリング、並べ替え、グループ化、および集計に使用されるフィールドは何ですか？
当然のことながら、これらはデータベーステーブルのパフォーマンスを向上させるために回答する必要があるのと同じ質問です。
IBMサポート お勧めする パフォーマンスを向上させるために、次のテーブルの列「COGIPF_REQUESTID」、「COGIPF_SUBREQUESTID」、および「COGIPF_STEPID」にインデックスを作成します。
- COGIPF_NATIVEQUERY
- COGIPF_RUNJOB
- COGIPF_RUNJOBSTEP
- COGIPF_RUNREPORT
- COGIPF_EDITQUERY
さらに、他のあまり使用されていないテーブル：
- COGIPF_POWERPLAY
- COGIPF_HUMANTASKSERVICE
- COGIPF_HUMANTASKSERVICE_DETAIL
これを出発点として使用できますが、上記の質問に答える演習を行って、組織にとって最良の答えに到達します。
その他の考慮事項
- FMモデルを監査します。 IBMが提供するFrameworkManagerモデルは、デフォルトの表とフィールドに基づいてモデル化されていることに注意してください。 レポートテーブルに加えた変更は、モデルに反映する必要があります。 これらの変更の容易さや複雑さ、またはこれらの変更を行う組織の能力は、選択するソリューションに影響を与える可能性があります。
- 追加のフィールド。 これを行う場合は、監査レポートを改善するために、コンテキストデータまたは参照データのフィールドを追加するときが来ました。
- 要約表。 データを履歴テーブルにコピーするだけでなく、圧縮します。 データを日レベルに集約して、レポート作成をより効率的にすることができます。
- テーブルの代わりにビュー。 他の人は、「したがって、「現在の」データベースと「履歴」データベースを使用する代わりに、データベースをXNUMXつだけ作成し、その中のすべてのテーブルの前に「履歴」を付ける必要があります。 次に、「現在」として表示するテーブルごとにXNUMXつずつ、一連のビューを作成し、各ビューで、表示したくない履歴行を除外して、現在の行のみを通過させる必要があります。」
https://softwareengineering.stackexchange.com/questions/276395/two-database-architecture-operational-and-historical/276419#276419
まとめ
結論として、ここで提供される情報を使用すると、DBAと生産的な会話をする準備ができているはずです。 彼女が以前に同様の問題を解決した可能性は十分にあります。
Cognos Audit Databaseアーキテクチャで提案されている変更により、直属の部下とそれに依存するサードパーティアプリケーションの両方のパフォーマンスが向上します。 Motioさん ReportCard および在庫。
ちなみに、DBAとそのような会話をしたことがあるなら、ぜひ聞いてみてください。 また、監査データベースのパフォーマンスが低いという問題を解決したかどうか、およびその方法についてもお聞かせください。
