Cognosを使用していて、現行Compatible Query Mode (CQM)で動いているCognosのプロジェクトをDynamic Qeury Mode (DQM)に切り替えた際、なにがどう変わってどこに影響があるのか？が綺麗にまとまった資料がなかったのでまとめてみました。
CQM→DQMでの変更点は大きくサマリーすると下記5点になります。
- レポート作成エンジン
- データベース接続
- キャッシュの使用
- 監査ログ
- ガバナーの設定
それぞれについて影響範囲と検証方法を見て行きたいと思います。
1. レポート作成エンジン
Queryモードを変更しているので変わって当たり前の部分ではありますがCQM→DQMの一番大きな変更点となります。
変更点
- CQM：32bitのBIBusTKServerMainプロセス
- DQM：64bitのjavaプロセス
影響範囲ごとの考慮点
1-1. レポートサービスの使用可能なメモリー容量
CQMのBIBUSプロセスは32bitプロセスなのでメモリー容量に1プロセスあたり2GBまでの制限がありました。
DQMでは64bitプロセスなので2GBの制限が無くなり、Query Serviceに割り当てられたJVMのヒープサイズの上限の中で利用可能になっています。そのため、CQMでは扱えなったや大量データを使用するレポートや、グラフやオブジェクトを多くレンダリングするようなレポートでも実行可能となっています。
ただし、メモリーの使われ方が変わるのでOut of Memory (OOM)発生時の影響範囲に注意が必要となります。
1-2. レポートサービスOOM時の影響範囲
- CQM：OOMを発生させたBIBUSプロセスで作成中のレポートにのみエラーが返っていました。他のBIBUSプロセスを使用しているレポートや新規にリクエストされたレポートは実行可能です。 このBIBUSプロセスはレポートリクエスト時に起動されるプロセスのため自然復旧が可能でした
- DQM：Query Serviceが使用するJVMでOOMが発生するため、他のレポートおよび新規リクエストのレポートも実行不可になります。復旧にはQuery Serviceの再起動が必要ですが、Cognosサービスを再起動する運用を検討するほうが望ましいです。
(検証方法/解決方法)
まずは、OOMが発生しないようなチューニングを検討します。Queryサービス用のJVM ヒープ・サイズ制限を引き上げますが、Cognosサービスに割り当てられるメモリーの上限を超えないように設定する必要があります。
また、Cognosサービスの再起動の担当者や実施方法などOOM発生時の運用方法についても検討しておくことが望ましいです。
1-3. 発行されるSQL文
集計や結合を頻繁に行う複雑なモデルやレポートではクエリーエンジンの解釈の違いにより生成されるSQLが変化することがあります。その結果、レポート実行時の値に影響を与えることがあります。
(検証方法/解決方法)
CQMで実行したレポートとDQMで実行したレポートで表示される値を見比べて検証する必要があります。
1-4. 検証の厳格化
DQMではCQMに比べて検証時の確認が厳格になります。CQMではエラーがなかったレポート定義でもDQMでレポート検証を実施するとエラーになる場合もあります。また、FMモデルにおいても同様になります。
(検証方法/解決方法)
エラーが発生した場合はメッセージに従い、レポート定義やFMモデルの修正が必要になります。
1-5. レポートの見栄え
レポート作成エンジンの違いによりレポートのレイアウトが崩れる発生する可能性があります。
レポートレイアウトを細かく指定しているレポートでは注意が必要です。
(検証方法/解決方法)
CQMで実行したレポートとDQMで実行したレポートでレイアウトを見比べて検証する必要があります。
※1-3, 1-5の検証時、目視による検証のほかにLCMを使った検証方法も検討するのもいいかもしれません。
LCM: (Cognos LifeCycle Manager) : Cognosのバージョンアップ時のレポートの出力結果を比較して同じ結果が生成されるかを検証する機能を提供している。環境さえあればCQM→DQMの前後比較にも使用可能です。
2. データベース接続
変更点
- CQM：NativeClient接続 または ODBC接続
- DMQ：JDBC接続
影響範囲ごとの考慮点
2-1. 基盤構成
<Cognos Install Directory>配下にJDBCドライバーの配置が必要になる
Cognos Analyticsの場合：<Analytics>/drivers
Cognos BIの場合：<c10_64>/webapps/p2pd/WEB-INF/lib および <C10_64>/v5dataserver
2-2. データソース接続定義
JDBCでのデータソース接続定義が無い場合は作成が必要になる
3. キャッシュの使用
変更点
DQMはキャッシュの再利用が可能になる
考慮点
キャッシュの再利用によりパフォーマンスの向上が見込まれる一方で、データ更新が頻繁な環境ではキャッシュの利用をOFFにするなどを検討する必要がある
4. 監査ログ
変更点
DQMではクエリーステートメントが監査ログに記録されない
考慮点
Audit DBを構築し、監査ログに出力されるクエリーステートメントを監査する運用を実施している場合、監査の運用方式の見直しが必要になる
5. ガバナーの設定
変更点
DQMではFramework Managerのガバナーの設定が適用されないものがある
考慮点
取得する行の最大数の制限などはQuery ServiceにTupleの上限数を設定するなど個別に対応が必要になる
レポート担当者や基盤担当者、運用担当などいろんな立場の視点からのお話をごちゃ混ぜに記載してしまいましたが、以上、CQMからDQMに切り替えた時の変更点と検証のポイントでした。
==============================================
個別事象 紹介
(2018.2.5 追記)
CQMからDQMに変更した際に遭遇した個別事象についてもまとめていますのでご紹介します。