キャッシュの更新のトラブルシューティング方法

多くの場合、キャッシュの更新がスケジュールされたTDV実装では、キャッシュが必要になります。これらの更新アクティビティは、さまざまな理由で失敗またはハングする可能性があります。ユーザー受け入れテストや本番環境などの厳密に制御された環境では、障害の診断が難しい場合があります。

このトピックでは、一般的な実稼働ログレベルを想定しています。また、TDVの再起動が必要な場合は、デバッグ設定を変更することは現実的ではないと想定しています。

キャッシュリフレッシュを実行するとき、TDVはいくつかのステップを実行します。

•キャッシュプロセスを呼び出す—スケジュールまたはイベントごとに、キャッシュの更新はどのように開始されますか？

•結果セットを計算します—結果セットを生成するためにTDVはどのような計算を実行しますか？フェデレーション結合アルゴリズムが使用されていますか？

•キャッシュターゲットへの書き込み—TDVはどのようにして結果セットをキャッシュデータベースに書き込みますか？ SQL INSERTまたはいくつかの高度なメカニズムを使用していますか？

•更新プロセスを完了します-キャッシュテーブルが完全に更新されると、TDVは新しいデータにカットオーバーします。トランザクションの整合性は維持されていますか？

キャッシュの更新が失敗していると思われる場合は、これらの手順の中から問題を特定してみてください。キャッシュ関連のエラーを含む2つの主要なログファイルは、cs_server.logとcs_server_task.logです。

最新のキャッシュ更新に関する情報を表示するには、次のようにします。

•左側にあるStudioの[Manager]タブをクリックし、リストから[キャッシュされたリソース]を選択します。このウィンドウには、最近のすべての更新の名前と、それらがいつ起動されたかが一覧表示されます。

•左側にあるStudioのModelerタブをクリックし、リソースツリーでComposite Data Services> Databases> Systemに移動して、SYS_CACHESシステムテーブルを見つけます。

SYS_CACHESテーブルのフィールドのリストについては、TDVリファレンスマニュアルのTDVシステムテーブルの章を参照してください。

•SYS_CACHESテーブルでは、INITIAL_TIMEは更新がいつ開始されたかを示しているため、更新が期待どおりにトリガーされたかどうかを確認できます。このテーブルは、NUM_SUCCESSとNUM_FAILも追跡します。

•オープンソースのKPIモジュール（https://github.com/TIBCOSoftware/ ASAssets_KPI）などのTDV実装に拡張ログ機能がある場合は、キャッシュをログに記録できます。履歴を更新します。これにより、各キャッシュの更新処理時間の記録が提供されます。

TDVは、データソースからデータをフェッチするために1つ以上のSQLステートメントを発行します。通常のログ設定では、これらのフェッチはログに記録されません。それらを表示するには、ビューの実行プランを開き、FETCHノードを探します。データソースの1つが正常に応答していないように見える場合は、FETCHノードのSQLをコピーして、データベースにネイティブなクライアント（Oracle SQL Developerなど）で実行できます。

注：この手法は、クラスター化されたデータソースでは信頼できません。これは、問題が発生してからシステムが変更された可能性があるため（不良ノードがサービスを停止するなど）、何を確実に再構築できないかを意味します。 TDVが検出されました。

まれに、データソース接続の問題にcache_statusテーブルが含まれる場合、キャッシュの更新がハングすることがあります。解決策については、TDVユーザーガイドのTDVキャッシングの章の「キャッシュステータステーブルのプローブ行の競合の管理」セクションを参照してください。

ソースデータが取得された後、TDVは、SQLステートメント、手続き型ロジック（キャッシュされたビューの場合でも）などを使用して、要求された結果セットを計算します。長時間のCPUスパイクは、スレッドの暴走などの計算問題を示している可能性があります。残念ながら、CPUスパイクを特定のリクエストまたはクエリに関連付けることはできません。ただし、特定のリクエストのメモリの消費量を確認できます。リクエストのメモリ消費量が多く、リクエストのライフサイクル全体を通じて高いままである場合は、何かが間違っている可能性があります。

•左側にあるStudioの[Manager]タブをクリックし、リストから[リクエスト]を選択します。このウィンドウには、最近のすべてのリクエストの名前と、それらがいつ起動されたかが一覧表示されます。 [キャッシュ]列の開始時刻とTRUEを使用して、キャッシュの更新に関連するリクエストを見つけることができます。

•リクエストをダブルクリックし、その完全なSQLを調べて、正しいリクエストが見つかったことを確認できます。

キャッシュされたリソースへの完全修飾パス（最適な識別子）は提供されませんが、通常は自信を持って推測できます。リクエストを特定すると、そのメモリと最大メモリ消費量を確認できます。

キャッシュの更新のトラブルシューティングを行うときは、常に書き込み手順を確認してください。

結果セットが計算されると、TDVはキャッシュデータベースへの書き込みを開始します。設計上、TDVは常に要求の完了を待つわけではありません。代わりに、TDVは、部分的な結果が利用可能になるとすぐに、キャッシュデータベースへのストリーミングを開始する場合があります。

レコードの最初のバッチがキャッシュテーブルに挿入されているかどうかを確認できます。 cache_trackingテーブルとcache_statusテーブルを使用して、正しいターゲットテーブルを決定します。（マルチテーブルキャッシングの場合は、適切なバケットを選択します。）このテーブルをクエリするときは、TDV Studioまたはネイティブデータベースクライアントのいずれかから、トランザクション分離をREADUNCOMMITTEDに設定します。

•ターゲットテーブルが完全に設定されているように見えても、キャッシュの更新がハングする場合、TDVは古いキャッシュデータから新しいキャッシュデータに切り替わっていない可能性があります。更新プロセスの完了を参照してください。

•テーブルスペースが最大値に達したことに関連するエラーを常にチェックします。これはよくあることです。これが発生すると、トランザクションをコミットできないため、TDVがハングします。

•マルチテーブルキャッシングが構成されている場合、TDVは挿入前にインデックスを削除し、後で再作成します。

キャッシュテーブルが完全に入力された後、TDVはカットオーバーを実行します。 cache_trackingテーブルとcache_statusテーブルを更新して、新しいキャッシュデータの使用を開始します。古いキャッシュデータが現在リクエストの処理に使用されている場合は、引き続き使用されます。カットオーバー後に発行されたリクエストのみが新しいキャッシュデータを使用します。 TDVは、古いキャッシュデータが不要であると判断すると、古いキャッシュを削除します。