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

はじめに

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

設定

データベースのクリーンアップは次の2つのレベルで構成されます。」をクリックします。

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

メモ

スケジューラーについて詳しくは、この節を参照してください。

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

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

重要

データベースクリーンアップ​ワークフローをスケジューラーで定義された日時に開始するには、ワークフローエンジン(wfserver)を起動する必要があります。 そうでない場合、データベースのクレンジングは、次回ワークフローエンジンが起動するまで行われません。

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

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

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

Database cleanup​ワークフローで実行されるすべてのタスクについて、次の節で説明します。

Database cleanupワークフローによって実行されるタスク

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

重要

これらのタスクの1つが失敗した場合、次のエラーは実行されません。
LIMIT​属性を持つSQLクエリは、すべての情報が処理されるまで繰り返し実行されます。

メモ

データベースのクリーンアップ・ワークフローで実行されるタスクについては、以下の節で説明します。データベース管理者またはSQL言語に詳しいユーザ向けに用意されています。

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

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

  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. 操作で回復した​タイプのリストをすべて選択すると、次のクエリが使用されて削除されます。

    DELETE FROM NmsGroup WHERE iGroupId=$(l)

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

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

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

  1. Database cleanup​ワークフローは、deleteStatus​フィールドの値が​Yes​または​Recycled​で、削除日が​Deleted配信 (<a10/)より前の配信を選択します。>NmsCleanup_RecycledDeliveryPurgeDelay )の展開ウィザードのフィールド。​詳しくは、展開ウィザードを参照してください。 この期間は、現在のサーバーの日付に関連して計算されます。

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

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

  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)​は配信の識別子です。

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

Database cleanup​ワークフローは、ミッドソーシングサーバー上の配信も削除します。

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

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

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

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

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

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

  1. Database cleanup​ワークフローは、有効期限が切れた配信のリストを作成します。 このリストには、完了​以外のステータスを持つ期限切れの配信がすべて含まれます。また、未処理のメッセージが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)​はデータベースID、配信ステータス6​は​保留​ステータスと一致します10/>配信ステータス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​は​停止​ステータス、$(cur9/>は現在のサーバー日付に一致します。

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

このタスクは、配信が使用するWebリソース(ミラーページ)を削除します。

  1. まず、次のクエリを使用して、パージする配信のリストをリカバリします。

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

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

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

    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%）もすべて削除されます。

メモ

履歴の削除頻度は、「History in days」フィールド（デフォルト値は30 days）の各ワークフローに対して指定されます。 このフィールドは、ワークフロープロパティの「実行」タブにあります。 詳しくは、こちらの節を参照してください。

  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))

    ここで、$(workflow)​はワークフローの識別子、$(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​オプションの定義日付です（Deployment wizardを参照）。

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

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

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

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

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

  • 開始日:次のプロセスの日付で、NmsLastErrorStatCoalesceoptionまたはテー ​​ブル内の最新の日付と一致します。
  • 終了日:現在のサーバーの日付。

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

開始日が終了日より前の場合、NmsEmailErrorStat​テーブルはクリーンアップされます。

NmsEmailErrorStat​テーブル内の開始日から終了日までのエラーの合計数は、次のクエリを使用して回復されます。

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

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

合計が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. 開始​変数が更新され、前のプロセスの値が使用されてループが終了します。

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

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

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

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

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

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

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

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

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

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

提案のクリーンアップ

Interaction​モジュールがインストールされている場合、このタスクは​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_​プレフィックスの後にシミュレーションのIDが続く(例：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上で冗長モード(VACUM 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)

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

ブロードローグスキーマのリストを回復するには、次のクエリを使用します。

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

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

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

クレンジングセッション情報

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

 DELETE FROM XtkSessionInfo WHERE tsexpiration < $(curdate)

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

このタスクは、実行インスタンスに受け取って保存されたイベントと、コントロールインスタンスにアーカイブされたイベントを消去します。

クレンジング反応

このタスクは、仮説自体が削除されたリアクション（テーブル​NmsRemaMatchRcp）をクリーンアップします。

このページ