一時テーブルの肥大化によりキャンペーンワークフローが停止する
この記事では、ワークフローの一時テーブルがデータベースから削除されず、プラットフォームが全体的に遅くなる理由を説明します。
説明 description
ハイブリッド顧客（オンプレミスのマーケティングインスタンス）では、一時的なテーブルの過度な使用により、Campaign ワークフローが常に停止し、データベースの使用率が高くなり、ワークフローが中断するという問題が発生していました。
データベースのクリーンアップのテクニカルワークフローが実行されていましたが、一時テーブルが必要に応じてドロップされませんでした。
解決策 resolution
詳細なモードでクリーンアップワークフローを実行しても、明確な根本原因が得られず、R&Dが関与していました。 お客様には、（Campaign DB ユーザーとして） psql データベースで次のコマンドを実行し、出力を共有するように求められました。
-
ワークフローの状態：
SELECT iWorkflowId, sInternalName, sLabel, iState FROM XtkWorkflow WHERE iWorkflowId IN （id1, id2, id3）; -
接続スキーマ / search_path:
SELECT current_user, current_schema （）, current_setting （'search_path'） AS search_path; -
スキーマごとのワークフロー作業テーブル：
SELECT schemaname, COUNT AS table_count FROM pg_tables WHERE tablename LIKE 'wkf%' GROUP BY schemaname ORDER BY table_count DESC;
結果を共有した後、顧客データベースのセットアップでは、データベースのログインユーザー名UserNameABCとは異なるカスタムスキーマ「XYZ」が使用されていることが確認されました。 具体的：
current_user = UserNameABC
current_schema （） / search_path = XYZ
すべてのワークフロー一時テーブルがスキーマ「XYZ」にありました。
標準設定では、すべてのテーブルが公開スキーマに格納されます。 db クリーンアップワークフローでは、データベースのログイン名（UserNameABC）およびパブリックから派生したスキーマをフィルタリングして、ドロップするテーブルを一覧表示します。 テーブルが「XYZ」スキーマにあったため、クリーンアップでそれらを見つけることはなく、ワークフローテーブルを削除することはありませんでした。
この問題を解決するために、お客様はServerConf.xmlの< dbcnx>要素に対してdbSchema属性を編集するように求められました
< dbcnx … dbSchema="XYZ" …>
次に、nlserver/apache restartを実行し、クリーンアップワークフローを実行します。