データベースクリーンアップのワークフロー

はじめに

管理／プロダクション／テクニカルワークフロー​ノードからアクセスできる​データベースクリーンアップ​ワークフローを使用すると、古いデータを削除して、データベースの急激な増加を回避できます。ワークフローは、ユーザーの操作なしで自動的にトリガーされます。

設定

データベースのクリーンアップは、次の2つのレベルで設定します。（ワークフロースケジューラー）と、デプロイウィザードで、

ワークフロースケジューラ

デフォルトでは、データベースクリーンアップ​ワークフローは、毎日午前4時に開始するように設定されています。 スケジューラーを使用すると、ワークフローのトリガー頻度を変更できます。 次の頻度を使用できます。

• 1 日に数回
• 毎日
• 毎週
• 1 回

デプロイメントウィザード

デプロイウィザード（ツール/詳細​メニューからアクセス）を使用して、データの保存期間を設定できます。 値は日数で表します。 これらの値が変更されない場合、ワークフローはデフォルト値を使用します。

データのパージ​ウィンドウのフィールドは、次のオプションと一致します。 これらは、データベースクリーンアップ​ワークフローで実行されるタスクの一部で使用されます。

• 統合されたトラッキング：NmsCleanup_TrackingStatPurgeDelay（トラッキングログのクリーンアップを参照）

• 配信ログ：NmsCleanup_BroadLogPurgeDelay（配信ログのクリーンアップを参照）

• トラッキングログ：NmsCleanup_TrackingLogPurgeDelay（トラッキングログのクリーンアップを参照）

• 削除された配信：NmsCleanup_RecycledDeliveryPurgeDelay（削除またはリサイクルする配信のクリーンアップを参照）

• 却下をインポート：NmsCleanup_RejectsPurgeDelay（インポートによって生成された却下のクリーンアップを参照）

• 訪問者プロファイル：NmsCleanup_VisitorPurgeDelay（訪問者のクリーンアップを参照）

• オファーの提案：NmsCleanup_PropositionPurgeDelay（提案のクリーンアップを参照）

  メモ

  オファーの提案​フィールドは、インタラクション​モジュールがインストールされている場合にのみ使用できます。

• イベント：NmsCleanup_EventPurgeDelay（期限切れのイベントのクレンジングを参照）

• アーカイブしたイベント：NmsCleanup_EventHistoPurgeDelay（期限切れのイベントのクレンジングを参照）

  メモ

  イベント​および​アーカイブされたイベント​フィールドは、Message Center​モジュールがインストールされている場合にのみ使用できます。

• 監査記録：XtkCleanup_AuditTrailPurgeDelay（監査記録のクリーンアップを参照）

データベースクリーンアップ​ワークフローで実行されるすべてのタスクについて、以下の節で説明します。

データベースクリーンアップワークフローによって実行されるタスク

ワークフロースケジューラーで定義された日時（スケジューラーを参照）に、ワークフローエンジンがデータベースのクリーンアッププロセスを開始します。 データベースクリーンアップは、データベースに接続し、以下に示す順序でタスクを実行します。

クリーンアップを削除するリスト

データベースクリーンアップ​ワークフローで最初に実行されたタスクは、deleteStatus != NmsGroup の0​属性。 これらのグループにリンクされ、他のテーブルに存在するレコードも削除されます。

1. 削除するリストは、次のSQLクエリを使用して復元されます。

   SELECT iGroupId, sLabel, iType FROM NmsGroup WHERE iDeleteStatus <> 0 OR tsExpirationDate <= GetDate() 
   

2. 各リストは、他のテーブルへのリンクを複数持ちます。 次のクエリを使用して、これらのリンクがすべて一括削除されます。

   DELETE FROM $(relatedTable) WHERE iGroupId=$(l) IN (SELECT iGroupId FROM $(relatedTable) WHERE iGroupId=$(l) LIMIT 5000) 
   

   ここで、 $(relatedTable)​は​NmsGroup​に関連するテーブルで、 $(l)​はリスト識別子です。

3. リストが「リスト」タイプのリストの場合、次のクエリを使用して関連付けられたテーブルが削除されます。

   DROP TABLE grp$(l)
   

4. 操作で復元された​Select​タイプリストは、次のクエリを使用して削除されます。

   DELETE FROM NmsGroup WHERE iGroupId=$(l) 
   

   ここで、$(l)​はリスト識別子です。

削除またはリサイクルする配信のクリーンアップ

このタスクは、削除またはリサイクルするすべての配信を削除します。

1. データベースクリーンアップ​ワークフローは、deleteStatus​フィールドの値が​Yes​または​Recycled​で、削除日が​Deleted deliveries（デプロイウィザードのnmsCleanup_RecycledDeliveryPurgeDelay）フィールド。 詳しくは、デプロイウィザードを参照してください。 この期間は、現在のサーバーの日付に基づいて計算されます。

2. タスクでは、ミッドソーシングサーバーごとに、削除する配信のリストを選択します。

3. データベースクリーンアップ​ワークフローは、配信ログ、添付ファイル、ミラーページ情報およびその他すべての関連データを削除します。

4. 配信を適切に削除する前に、ワークフローは次のテーブルからリンクされた情報を削除します。

   • 配信の除外テーブル(NmsDlvExclusion)では、次のクエリが使用されます。

     DELETE FROM NmsDlvExclusion WHERE iDeliveryId=$(l)
     

     $(l)​は配信の識別子です。

   • クーポンテーブル(NmsCouponValue)では、次のクエリが使用されます（一括削除を含む）。

     DELETE FROM NmsCouponValue WHERE iMessageId IN (SELECT iMessageId FROM NmsCouponValue WHERE EXISTS (SELECT B.iBroadLogId FROM $(BroadLogTableName) B WHERE B.iDeliveryId = $(l) AND B.iBroadLogId = iMessageId ) LIMIT 5000)
     

     $(l)​は配信の識別子です。

   • 配信ログテーブル(NmsBroadlogXxx)では、大量削除は20,000件のレコードのバッチで実行されます。

   • オファーの提案テーブル(NmsPropositionXxx)では、大量削除は20,000件のレコードのバッチで実行されます。

   • トラッキングログテーブル(NmsTrackinglogXxx)では、大量削除は20,000件のレコードのバッチで実行されます。

   • 配信フラグメントテーブル(NmsDeliveryPart)では、500,000件のレコードのバッチで一括削除が実行されます。 この表には、配信される残りのメッセージに関するパーソナライゼーション情報が含まれます。

   • ミラーページデータフラグメントテーブル(NmsMirrorPageInfo)では、期限切れの配信部分と完了またはキャンセルされた配信部分に対して、20,000件のレコードのバッチで一括削除が実行されます。 この表には、ミラーページの生成に使用されるすべてのメッセージに関するパーソナライゼーション情報が含まれます。

   • ミラーページ検索テーブル(NmsMirrorPageSearch)では、20,000レコードのバッチで大量削除が実行されます。 このテーブルは、NmsMirrorPageInfo​テーブルに格納されたパーソナライゼーション情報にアクセスできる検索インデックスです。

   • バッチ処理ログテーブル(XtkJobLog)では、20,000件のレコードのバッチで一括削除が実行されます。 このテーブルには、削除する配信のログが含まれます。

   • 配信URLトラッキングテーブル(NmsTrackingUrl)では、次のクエリが使用されます。

     DELETE FROM NmsTrackingUrl WHERE iDeliveryId=$(l)
     

     $(l)​は配信の識別子です。

     このテーブルには、削除される配信内の、トラッキングを有効にするURLが含まれています。

5. 配信が配信テーブル(NmsDelivery)から削除されます。

   DELETE FROM NmsDelivery WHERE iDeliveryId = $(l)
   

   $(l)​は配信の識別子です。

ミッドソーシングを使用する配信

データベースクリーンアップ​ワークフローは、ミッドソーシングサーバー上の配信も削除します。

1. これをおこなうには、ワークフローで、（ステータスに基づいて）各配信が非アクティブであることを確認します。 アクティブな配信は、削除される前に停止されます。 チェックは、次のクエリを実行して実行されます。

   SELECT iState FROM NmsDelivery WHERE iDeliveryId = $(l) AND iState <> 100;
   

   $(l)​は配信の識別子です。

2. ステータスの値が​開始保留中 、 処理中 、 回復待ち 、 回復中 、 一時停止要求 、 進行中​の場合または​一時停止（値51、55、61、62、71、72、75）、配信が停止し、タスクがリンクされた情報を削除します。

期限切れの配信のクリーンアップ

このタスクは、有効期間が切れた配信を停止します。

1. データベースクリーンアップ​ワークフローは、期限切れの配信のリストを作成します。 このリストには、ステータスが​完了​以外の期限切れの配信と、処理されていないメッセージが10,000件を超える最近停止された配信が含まれます。 次のクエリが使用されます。

   SELECT iDeliveryId, iState FROM NmsDelivery WHERE iDeleteStatus=0 AND iIsModel=0 AND iDeliveryMode=1 AND ( (iState >= 51 AND iState < 85 AND tsValidity IS NOT NULL AND tsValidity < $(currentDate) ) OR (iState = 85 AND DateMinusDays(15) < tsLastModified AND iToDeliver - iProcessed >= 10000 ))
   

   配信モード1​は​一括配信​モード、状態51​は​開始保留​状態、状態85​は​停止​状態、配信サーバー上で一括更新された配信ログの最大数が10,000に等しい。

2. 次に、ミッドソーシングを使用する最近期限切れの配信のリストがワークフローに含まれます。 ミッドソーシングサーバー経由で配信ログがまだ復元されていない配信は除外されます。

   次のクエリが使用されます。

   SELECT iDeliveryId, tsValidity, iMidRemoteId, mData FROM NmsDelivery WHERE (iDeliveryMode = 4 AND (iState = 85 OR iState = 95) AND tsValidity IS NOT NULL AND (tsValidity < SubDays(GetDate() , 15) OR tsValidity < $(DateOfLastLogPullUp)) AND tsLastModified > SubDays(GetDate() , 15))
   

3. 次のクエリは、日付で配信をフィルタリングするために、外部アカウントがアクティブかどうかを検出するために使用します。

   SELECT iExtAccountId FROM NmsExtAccount WHERE iActive<>0 AND sName=$(providerName)
   

4. 期限切れの配信のリストで、ステータスが​保留中​の配信ログを​配信がキャンセル​に切り替え、このリストにあるすべての配信を​完了​に切り替えます。

   次のクエリが使用されます。

   UPDATE $(BroadLogTableName) SET tsLastModified=$(curdate), iStatus=7, iMsgId=$(bl) WHERE iDeliveryId=$(dl) AND iStatus=6
   

   $(curdate)​はデータベースサーバーの現在の日付、$(bl)​は配信ログメッセージの識別子、$(dl)​は配信識別子、配信ステータス6​は​保留​ステータスと​配信ステータス7​は、「配信がキャンセルされました」ステータスに一致します。

   UPDATE NmsDelivery SET iState = 95, tsLastModified = $(curdate), tsBroadEnd = tsValidity WHERE iDeliveryId = $(dl)
   

   配信状態95​は​完了​ステータスと一致し、$(dl)​は配信の識別子です。

5. 古い配信のすべてのフラグメント(deliveryParts)が削除され、進行中の通知配信の古いフラグメントがすべて削除されます。 一括削除は、両方のタスクに使用されます。

   次のクエリが使用されます。

   DELETE FROM NmsDeliveryPart WHERE iDeliveryPartId IN (SELECT iDeliveryPartId FROM NmsDeliveryPart WHERE iDeliveryId IN (SELECT iDeliveryId FROM NmsDelivery WHERE iState=95 OR iState=85) LIMIT 5000)
   

   DELETE FROM NmsDeliveryPart WHERE iDeliveryPartId IN (SELECT iDeliveryPartId FROM NmsDeliveryPart WHERE tsValidity < $(curDate) LIMIT 500000)
   

   配信状態95​は​完了​ステータスに、配信状態85​は​停止​ステータスに、$(curDate)​は現在のサーバー日に一致します。

ミラーページのクリーンアップ

このタスクでは、配信で使用されているWebリソース（ミラーページ）を削除します。

1. まず、パージされる配信のリストは、次のクエリを使用して復元します。

   SELECT iDeliveryId, iNeedMirrorPage FROM NmsDelivery WHERE iWebResPurged = 0 AND tsWebValidity IS NOT NULL AND tsWebValidity < $(curdate)"
   

   ここで、$(curDate)​は現在のサーバーの日付です。

2. 必要に応じて、以前に復元した配信の識別子を使用して、 NmsMirrorPageInfo​テーブルがパージされます。 一括削除は、次のクエリを生成するために使用されます。

   DELETE FROM NmsMirrorPageInfo WHERE iMirrorPageInfoId IN (SELECT iMirrorPageInfoId FROM NmsMirrorPageInfo WHERE iDeliveryId = $(dl)) LIMIT 5000)
   

   DELETE FROM NmsMirrorPageSearch WHERE iMessageId IN (SELECT iMessageId FROM NmsMirrorPageSearch WHERE iDeliveryId = $(dl)) LIMIT 5000)
   

   $(dl)​は配信の識別子です。

3. エントリが配信ログに追加されます。

4. パージされた配信は識別され、後で再処理する必要がなくなります。 次のクエリが実行されます。

   UPDATE NmsDelivery SET iWebResPurged = 1 WHERE iDeliveryId IN ($(strIn))
   

   ここで、$(strIn)​は配信識別子のリストです。

作業用テーブルのクリーンアップ

このタスクは、ステータスが​編集中 、 停止​または​削除​の配信に一致するすべての作業用テーブルをデータベースから削除します。

1. 名前が​wkDlv_​で始まるテーブルのリストは、まず次のクエリ(postgresql)を使用して復元されます。

   SELECT relname FROM pg_class WHERE relname LIKE Lower('wkDlv_') ESCAPE E'\\' AND relkind IN ('r','v') AND pg_get_userbyid(relowner)<>'postgres'
   

2. その後、進行中のワークフローで使用されるテーブルが除外されます。 これをおこなうには、進行中の配信のリストを、次のクエリを使用して復元します。

   SELECT iDeliveryId FROM NmsDelivery WHERE iDeliveryId<>0 AND iDeleteStatus=0 AND iState NOT IN (0,85,100);
   

   ここで、0は​編集中の​配信ステータスに一致する値、85は​停止中の​ステータス、100は​削除済みの​ステータスに一致します。

3. 使用されなくなったテーブルは、次のクエリを使用して削除されます。

   DROP TABLE wkDlv_15487_1;
   

インポートによって生成された却下のクリーンアップ

この手順を使用すると、インポート中にすべてのデータが処理されなかったレコードを削除できます。

1. 一括削除は、次のクエリを使用して​XtkReject​テーブルに対して実行されます。

   DELETE FROM XtkReject WHERE iRejectId IN (SELECT iRejectId FROM XtkReject WHERE tsLog < $(curDate)) LIMIT $(l))
   

   ここで、 $(curDate)​は、NmsCleanup_RejectsPurgeDelay​オプションに定義した期間を差し引いた現在のサーバー日付です（Deployment wizardを参照）。$(l)​は、質量の最大レコード数削除されました。

2. すべてのオーファン却下は、次のクエリを使用して削除されます。

   DELETE FROM XtkReject WHERE iJobId NOT IN (SELECT iJobId FROM XtkJob)
   

ワークフローインスタンスのクリーンアップ

このタスクは、識別子(lWorkflowId)と履歴(lHistory)を使用して各ワークフローインスタンスを削除します。 作業用テーブルのクリーンアップタスクを再実行すると、非アクティブなテーブルが削除されます。 また、削除されたワークフローの孤立した作業用テーブル（wkf%とwkfhisto%）もすべて削除されます。

1. 削除するワークフローのリストを復元するには、次のクエリを使用します。

   SELECT iWorkflowId, iHistory FROM XtkWorkflow WHERE iWorkflowId<>0
   

2. このクエリは、次のクエリを使用して、リンクされたすべてのログ、完了したタスクおよび完了したイベントを削除するために使用されるワークフローのリストを生成します。

   DELETE FROM XtkWorkflowLog WHERE iWorkflowId=$(lworkflow) AND tsLog < DateMinusDays($(lhistory))
   

   DELETE FROM XtkWorkflowTask WHERE iWorkflowId=$(lworkflow) AND iStatus<>0 AND tsCompletion < DateMinusDays($(lhistory)) 
   

   DELETE FROM XtkWorkflowEvent WHERE iWorkflowId=$(l) AND iStatus>2 AND tsProcessing < DateMinusDays($(lHistory))
   

   ここで、 $(lworkflow)​はワークフローの識別子、 $(lhistory)​は履歴の識別子です。

3. 未使用のテーブルはすべて削除されます。 この目的のために、次のクエリ(postgresql)を使用する​wkf%​タイプのマスクを使用して、すべてのテーブルを収集します。

   SELECT relname FROM pg_class WHERE relname LIKE Lower('wkf%') ESCAPE E'\\' AND relkind IN ('r','v') AND pg_get_userbyid(relowner)<>'postgres'
   

4. その後、保留中のワークフローインスタンスで使用されるすべてのテーブルが除外されます。 アクティブなワークフローのリストは、次のクエリを使用して復元されます。

   SELECT iWorkflowId FROM XtkWorkflow WHERE iWorkflowId<>0 AND iState<>20
   

5. 各ワークフロー識別子が復元され、進行中のワークフローで使用されるテーブルの名前が確認されます。 これらの名前は、以前に復元したテーブルのリストから除外されます。

6. 「増分処理クエリ」タイプのアクティビティ履歴テーブルは、次のクエリを使用して除外されます。

   SELECT relname FROM pg_class WHERE relname LIKE Lower('wkfhisto%') ESCAPE E'\\' AND relkind IN ('r','v') AND pg_get_userbyid(relowner)<>'postgres'
   

   SELECT iWorkflowId FROM XtkWorkflow WHERE iWorkflowId IN ($(strCondition))
   

   ここで、$(strcondition)​は、wkfhisto%​マスクに一致するテーブルのリストです。

7. 残りのテーブルは、次のクエリを使用して削除されます。

   DROP TABLE wkf15487_12;
   

ワークフローログインのクリーンアップ

このタスクでは、次のクエリを使用してワークフローログインを削除します。

DELETE FROM XtkWorkflowLogin WHERE iWorkflowId NOT IN (SELECT iWorkflowId FROM XtkWorkflow)

孤立した作業用テーブルのクリーンアップ

このタスクは、グループにリンクされた孤立した作業用テーブルを削除します。 NmsGroup​テーブルには、クレンジング対象のグループ（0とは異なる型）が格納されます。 テーブル名のプレフィックスは​grp​です。 クレンジング対象のグループを識別するには、次のクエリを使用します。

SELECT iGroupId FROM NmsGroup WHERE iType>0"

訪問者のクリーンアップ

このタスクでは、一括削除を使用して、古いレコードを訪問者テーブルから削除します。 古いレコードは、最後の変更がデプロイウィザードで定義された保存期間より前のものです（デプロイウィザードを参照）。 次のクエリが使用されます。

DELETE FROM NmsVisitor WHERE iVisitorId IN (SELECT iVisitorId FROM NmsVisitor WHERE iRecipientId = 0 AND tsLastModified < AddDays(GetDate(), -30) AND iOrigin = 0 LIMIT 20000)

ここで、$(tsDate)​は現在のサーバーの日付です。この日付から、NmsCleanup_VisitorPurgeDelay​オプションに定義した期間を引きます。

NPAIのクリーンアップ

このタスクを実行すると、有効なアドレスと一致するレコードを​NmsAddress​テーブルから削除できます。 一括削除の実行には、次のクエリが使用されます。

DELETE FROM NmsAddress WHERE iAddressId IN (SELECT iAddressId FROM NmsAddress WHERE iStatus=2 AND tsLastModified < $(tsDate1) AND tsLastModified >= $(tsDate2) LIMIT 5000)

status 2​は​有効な​ステータスに一致し、$(tsDate1)​は現在のサーバーの日付に一致します。$(tsDate2)​は​NmsCleanup_LastCleanup​オプションに一致します。

購読のクリーンアップ

このタスクは、一括削除を使用して、ユーザーが​NmsSubscription​テーブルから削除したすべてのサブスクリプションを削除します。 次のクエリが使用されます。

DELETE FROM NmsSubscription WHERE iDeleteStatus <>0

トラッキングログのクリーンアップ

このタスクは、トラッキングおよびWebトラッキングログテーブルから古いレコードを削除します。 古いレコードは、デプロイウィザードで定義された保存期間より前のレコードです（デプロイウィザードを参照）。

1. まず、次のクエリを使用して、トラッキングログテーブルのリストを復元します。

   SELECT distinct(sTrackingLogSchema) FROM NmsDeliveryMapping WHERE sTrackingLogSchema IS NOT NULL;
   

2. 一括削除は、以前に復元したテーブルのリスト内のすべてのテーブルをパージするために使用します。 次のクエリが使用されます。

   DELETE FROM XtkTrackingLogRcp WHERE iTrackingLogId IN (SELECT iTrackingLogId FROM XtkTrackingLogRcp WHERE tsLog < $(tsDate) LIMIT 5000) 
   

   ここで、 $(tsDate)​は、NmsCleanup_TrackingLogPurgeDelay​オプションに定義した期間を差し引いた現在のサーバー日です。

3. トラッキング統計テーブルは、一括削除を使用してパージされます。 次のクエリが使用されます。

   DELETE FROM NmsTrackingStats WHERE iTrackingStatsId IN (SELECT iTrackingStatsId FROM NmsTrackingStats WHERE tsStart < $(tsDate) LIMIT 5000) 
   

   ここで、 $(tsDate)​は、NmsCleanup_TrackingStatPurgeDelay​オプションに定義した期間を差し引いた現在のサーバー日付です。

配信ログのクリーンアップ

このタスクでは、様々なテーブルに保存されている配信ログをパージできます。

1. この目的で、配信ログスキーマのリストは、次のクエリを使用して復元されます。

   SELECT distinct(sBroadLogSchema) FROM NmsDeliveryMapping WHERE sBroadLogSchema IS NOT NULL UNION SELECT distinct(sBroadLogExclSchema) FROM NmsDeliveryMapping WHERE sBroadLogExclSchema IS NOT NULL
   

2. ミッドソーシングを使用する場合、NmsBroadLogMid​テーブルは配信マッピングで参照されません。 nms:broadLogMid​スキーマが、前のクエリで復元されたリストに追加されます。

3. 次に、データベースのクリーンアップ​ワークフローは、以前に復元したテーブルから古いデータを削除します。 次のクエリが使用されます。

   DELETE FROM $(tableName) WHERE iBroadLogId IN (SELECT iBroadLogId FROM $(tableName) WHERE tsLastModified < $(option) LIMIT 5000) 
   

   ここで、 $(tableName)​はスキーマのリスト内の各テーブルの名前で、 $(option)​は​NmsCleanup_BroadLogPurgeDelay​オプション用に定義された日付です（ デプロイウィザードを参照）。

4. 最後に、ワークフローは、NmsProviderMsgId​テーブルが存在するかどうかを確認します。 その場合、古いデータはすべて次のクエリを使用して削除されます。

   DELETE FROM NmsProviderMsgId WHERE iBroadLogId IN (SELECT iBroadLogId FROM NmsProviderMsgId WHERE tsCreated < $(option) LIMIT 5000)
   

   ここで、 $(option)​は、 NmsCleanup_BroadLogPurgeDelay​オプションに定義された日付と一致します（デプロイウィザードを参照）。

NmsEmailErrorStatテーブルのクリーンアップ

このタスクは、NmsEmailErrorStat​テーブルをクレンジングします。 メインプログラム(coalesceErrors)は、次の2つの日付を定義します。

• 開始日:NmsLastErrorStatCoalesceオプションまたはテー ​​ブル内の最新の日付に一致する次のプロセスの日付。
• 終了日:現在のサーバーの日付。

開始日が終了日以上の場合、処理はおこなわれません。 この場合、 coalesceUpToDate​メッセージが表示されます。

開始日が終了日より前の場合は、NmsEmailErrorStat​テーブルがクレンジングされます。

NmsEmailErrorStat​テーブル内の開始日と終了日の間のエラーの合計数は、次のクエリを使用して復元します。

"SELECT COUNT(*) FROM NmsEmailErrorStat WHERE tsDate>= $(start) AND tsDate< $(end)"

ここで、 $end​と​$start​は、前に定義した開始日と終了日です。

合計が0より大きい場合：

1. 特定のしきい値（20に等しい）を超えるエラーのみを保持するために、次のクエリが実行されます。

   "SELECT iMXIP, iPublicId, SUM(iTotalConnections), SUM(iTotalErrors), SUM(iMessageErrors), SUM(iAbortedConnections), SUM(iFailedConnections), SUM(iRefusedConnections), SUM(iTimeoutConnections) FROM NmsEmailErrorStat WHERE tsDate>=$(start ) AND tsDate<$(end ) GROUP BY iMXIP, iPublicId HAVING SUM(iTotalErrors) >= 20"
   

2. coalescingErrors​メッセージが表示されます。

3. 開始日と終了日の間に発生したすべてのエラーを削除する新しい接続が作成されます。 次のクエリが使用されます。

   "DELETE FROM NmsEmailErrorStat WHERE tsDate>=$(start) AND tsDate<$(end)"
   

4. 各エラーは、次のクエリを使用して​NmsEmailErrorStat​テーブルに保存されます。

   "INSERT INTO NmsEmailErrorStat(iMXIP, iPublicId, tsDate, iTotalConnections, iTotalErrors, iTimeoutConnections, iRefusedConnections, iAbortedConnections, iFailedConnections, iMessageErrors) VALUES($(lmxip ), $(lpublicId ), $(tsstart ), $(lconnections ), $(lconnectionErrors ),$(ltimeoutConnections ), $(lrefusedConnections ), $(labortedConnections ), $(lfailedConnections ), $(lmessageErrors))"
   

   各変数は、前のクエリで取得した値と一致します。

5. start​変数が、前のプロセスの値で更新され、ループが終了します。

ループとタスクが停止します。

クリーンアップは、NmsEmailError​テーブルと​cleanupNmsMxDomain​テーブルで実行されます。

NmsEmailErrorテーブルのクリーンアップ

次のクエリが使用されます。

DELETE FROM NmsEmailError WHERE iMXIP NOT IN (SELECT DISTINCT iMXIP FROM NmsEmailErrorStat)

このクエリは、NmsEmailErrorStat​内のリンクされたレコードを持たない行を​NmsEmailError​テーブルからすべて削除します。

NmsMxDomainテーブルのクリーンアップ

次のクエリが使用されます。

DELETE FROM NmsMxDomain WHERE iMXIP NOT IN (SELECT DISTINCT iMXIP FROM NmsEmailErrorStat)

このクエリは、NmsEmailErrorStat​テーブル内のリンクされたレコードを持たない行を、NmsMxDomain​テーブルからすべて削除します。

提案のクリーンアップ

インタラクション​モジュールがインストールされている場合、このタスクが実行され、NmsPropositionXxx​テーブルがパージされます。

提案テーブルのリストが復元され、次のクエリを使用して、各提案テーブルに対して一括削除が実行されます。

DELETE FROM NmsPropositionXxx WHERE iPropositionId IN (SELECT iPropositionId FROM NmsPropositionXxx WHERE tsLastModified < $(option) LIMIT 5000) 

ここで、 $(option)​は、 NmsCleanup_PropositionPurgeDelay​オプション用に定義された日付です（デプロイウィザードを参照）。

シミュレーションテーブルのクリーンアップ

このタスクは、孤立したシミュレーションテーブル（オファーのシミュレーションや配信のシミュレーションにリンクされなくなったテーブル）を消去します。

1. クリーンアップが必要なシミュレーションのリストを復元するには、次のクエリを使用します。

   SELECT iSimulationId FROM NmsSimulation WHERE iSimulationId<>0
   

2. 削除するテーブルの名前は、 wkSimu_​プレフィックスに続くシミュレーションの識別子で構成されます(例：wkSimu_456831_aggr):

   DROP TABLE wkSimu_456831_aggr
   

監査記録のクリーンアップ

次のクエリが使用されます。

DELETE FROM XtkAudit WHERE tsChanged < $(tsDate)

ここで、 $(tsDate)​は、XtkCleanup_AuditTrailPurgeDelay​オプションに定義した期間が停止される現在のサーバーの日付です。

Nmsaddressのクリーンアップ

次のクエリが使用されます。

DELETE FROM NmsAddress WHERE iAddressId IN (SELECT iAddressId FROM NmsAddress WHERE iStatus=STATUS_QUARANTINE AND tsLastModified < $(NmsCleanup_AppSubscriptionRcpPurgeDelay + 5d) AND iType IN (MESSAGETYPE_IOS, MESSAGETYPE_ANDROID ) LIMIT 5000)

このクエリは、iOSとAndroidに関連するすべてのエントリを削除します。

統計の更新とストレージの最適化

XtkCleanup_NoStats​オプションを使用すると、クリーンアップワークフローのストレージ最適化手順の動作を制御できます。

XtkCleanup_NoStats​オプションが存在しない場合、またはその値が0の場合は、PostgreSQLの詳細モード(VACUUM VERBOSE ANALYZE)でストレージの最適化が実行され、他のすべてのデータベースの統計が更新されます。 このコマンドが実行されることを確認するには、PostgreSQLのログを確認します。 VACUUMは、次の形式で行を出力します。INFO: vacuuming "public.nmsactivecontact"とANALYZEは、次の形式で行を出力します。INFO: analyzing "public.nmsactivecontact".

このオプションの値が1の場合、統計の更新はどのデータベースでも実行されません。 次のログ行がワークフローログに表示されます。Option 'XtkCleanup_NoStats' is set to '1'.

オプションの値が2の場合、PostgreSQLの詳細モード(ANALYZE VERBOSE)でストレージ分析が実行され、他のすべてのデータベースの統計が更新されます。 このコマンドが実行されることを確認するには、PostgreSQLのログを確認します。 ANALYZEは、次の形式で行を出力します。INFO: analyzing "public.nmsactivecontact".

サブスクリプションクリーンアップ(NMAC)

このタスクは、削除されたサービスまたはモバイルアプリケーションに関連する購読をすべて削除します。

broadlogスキーマのリストを復元するには、次のクエリを使用します。

SELECT distinct(sBroadLogSchema) FROM NmsDeliveryMapping WHERE sBroadLogSchema IS NOT NULL

次に、このタスクは、appSubscription​リンクにリンクされたテーブルの名前を復元し、これらのテーブルを削除します。

また、このクリーンアップワークフローでは、NmsCleanup_AppSubscriptionRcpPurgeDelay​オプションで設定された時間以降に更新されていない無効= 1のエントリもすべて削除します。

セッション情報をクレンジングする

このタスクは、sessionInfo​テーブルから情報をクレンジングします。次のクエリが使用されます。

 DELETE FROM XtkSessionInfo WHERE tsexpiration < $(curdate) 

有効期限切れのイベントのクレンジング

このタスクは、実行インスタンスで受信および保存されたイベントと、コントロールインスタンスでアーカイブされたイベントをクレンジングします。

クレンジング反応

このタスクは、仮説自体が削除された反応（テーブル​NmsRemaMatchRcp）をクレンジングします。