データベースクリーンアップのワークフロー database-cleanup-workflow

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

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

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

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

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

リストが「リスト」タイプのリストの場合、以下のクエリを使用して、関連テーブルが削除されます。

DROP TABLE grp$(l)

ごと を選択 操作によって復元されたタイプ リストは、次のクエリを使用して削除されます：

DELETE FROM NmsGroup WHERE iGroupId=$(l)

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

この データベースのクリーンアップ ワークフローは、に該当するすべての配信を選択します deleteStatus フィールドの値が はい または 再利用済み 削除日がで定義された期間より前のもの 削除された配信 （NmsCleanup_RecycledDeliveryPurgeDelay）フィールドに入力します。 詳しくは、次を参照してください 配置ウィザード. この期間は、現在のサーバーの日付を基準に計算されます。

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

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

配信を削除する前に、リンクされている情報が次の表から削除されます。

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

  code language-sql
  DELETE FROM NmsDlvExclusion WHERE iDeliveryId=$(l)

  ここで、 $（l） は配信の識別子です。

• クーポンテーブル（NmsCouponValue）を選択すると、次のクエリが使用されます（複数削除を使用）。

  code language-sql
  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）に設定した場合は、2 万件のレコードに相当するバッチで一括削除が実行されます。

• オファーの提案テーブル（NmsPropositionXxx）に設定した場合は、2 万件のレコードに相当するバッチで一括削除が実行されます。

• トラッキングログテーブル（NmsTrackinglogXxx）に設定した場合は、2 万件のレコードに相当するバッチで一括削除が実行されます。

• 配信フラグメントテーブル（NmsDeliveryPart）に設定した場合、50 万件のレコードに相当するバッチで一括削除が実行されます。 この表には、配信される残りのメッセージに関するパーソナライゼーション情報が含まれています。

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

• ミラーページの検索テーブル（NmsMirrorPageSearch）に設定した場合は、2 万件のレコードに相当するバッチで一括削除が実行されます。 このテーブルは、に格納されたパーソナライゼーション情報へのアクセスを提供する検索インデックスです。 NmsMirrorPageInfo テーブル。

• バッチ処理ログテーブル（XtkJobLog）に設定した場合は、2 万件のレコードに相当するバッチで一括削除が実行されます。 この表には、削除される配信のログが含まれています。

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

  code language-sql
  DELETE FROM NmsTrackingUrl WHERE iDeliveryId=$(l)

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

  この表には、トラッキングを有効にするために削除する配信で見つかった URL が含まれています。

配信が配信テーブルから削除されます（NmsDelivery）:

DELETE FROM NmsDelivery WHERE iDeliveryId = $(l)

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

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

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

ここで、 $（l） は配信の識別子です。

ステータスの値がの場合 開始を保留中 , 処理中 , 回復を保留中 , リカバリ中 , 一時停止がリクエストされました , 一時停止中 、または 一時停止 （値 51、55、61、62、71、72、75）、配信が停止され、タスクによってリンクされた情報がパージされます。

この データベースのクリーンアップ ワークフローは、有効期限が切れた配信のリストを作成します。 このリストには、ステータスが以外の、期限切れの配信がすべて含まれます 完了 、および 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 ))

ここで、 delivery mode 1 次に一致 一括配信 モード、 state 51 次に一致 開始を保留中 都道府県、 state 85 次に一致 停止 状態の場合、配信サーバー上の一括更新される配信ログの最大数は 10,000 に等しくなります。

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

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

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

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

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

期限切れ配信のリストで、ステータスが「」の配信ログ 保留中 、切り替え先 配信がキャンセルされました に変更すると、このリスト内のすべての配信がに切り替わります 完了 .

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

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

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

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

ここで、 delivery state 95 次に一致 完了 ステータス、 $(dl) は配信の識別子です。

すべてのフラグメント （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)

ここで、 delivery state 95 次に一致 完了 ステータス、 delivery state 85 次に一致 停止 ステータス、 $(curDate) は、現在のサーバーの日付です。

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

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

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

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

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

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

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

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

で始まる名前のテーブルのリスト 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'

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

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

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

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

DROP TABLE wkDlv_15487_1;

一括削除は次の場所で実行されます。 XtkReject 次のクエリを含むテーブル：

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

ここで、 $(curDate) は、に定義された期間を引く現在のサーバーの日付です。 NmsCleanup_RejectsPurgeDelay オプション（を参照 配置ウィザード）および $(l) は、一括削除されるレコードの最大数です。

すべての孤立した却下は、次のクエリを使用して削除されます。

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

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

SELECT iWorkflowId, iHistory FROM XtkWorkflow WHERE iWorkflowId<>0

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

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) は履歴の識別子です。

未使用のテーブルはすべて削除されます。 この目的のために、すべてのテーブルは wkf% 次のクエリ（postgresql）を使用してマスクを入力します。

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

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

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

次に、各ワークフロー識別子が復元され、実行中のワークフローで使用されているテーブルの名前が検索されます。 これらの名前は、以前にリカバリしたテーブルのリストから除外されます。

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

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% マスク。

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

DROP TABLE wkf15487_12;

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

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

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

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

ここで、 $(tsDate) は、に定義された期間を引く現在のサーバーの日付です。 NmsCleanup_TrackingLogPurgeDelay オプション。

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

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

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

この目的のために、次のクエリを使用して配信ログスキーマのリストを復元します。

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

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

この データベースのクリーンアップ 次に、ワークフローは、以前にリカバリされたテーブルから古いデータをパージします。 次のクエリが使用されます。

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

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

最後に、ワークフローによって NmsProviderMsgId テーブルが存在します。 その場合は、次のクエリを使用して、古いデータがすべて削除されます。

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

ここで、 $(option) 次に対して定義された日付に一致 NmsCleanup_BroadLogPurgeDelay オプション（を参照 配置ウィザード）に設定します。

特定のしきい値（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

この coalescingErrors メッセージが表示されます。

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

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

各エラーは、 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))

各変数は、前のクエリで復元された値と一致します。

この 開始 変数は、前のプロセスの値で更新され、ループが終了します。

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

SELECT iSimulationId FROM NmsSimulation WHERE iSimulationId<>0

削除するテーブルの名前は、 wkSimu_ プレフィックスの後にシミュレーションの識別子（例： wkSimu_456831_aggr）:

DROP TABLE wkSimu_456831_aggr