データベースクリーンアップのワークフロー 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」フィールドの値が Yes または Recycled で、削除日がデプロイメントウィザードの「削除済み配信 （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）では、20,000 件のレコードに対してバッチで一括削除が実行されます。

• オファーの提案テーブル（NmsPropositionXxx）では、一括削除が 20,000 件のレコードに対してバッチで実行されます。

• トラッキングログテーブル（NmsTrackinglogXxx）では、20,000 件のレコードに対してバッチで一括削除が実行されます。

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

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

• ミラーページ検索テーブル（NmsMirrorPageSearch）では、20,000 件のレコードに対して一括削除が実行されます。 このテーブルは、NmsMirrorPageInfo テーブルに格納されているパーソナライゼーション情報へのアクセスを提供する検索インデックスです。

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

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

未使用のテーブルはすべて削除されます。 この目的のために、以下のクエリ（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'

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

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) は wkfhito% マスクに一致するテーブルのリストです。

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

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

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

start 変数は、ループを終了するために前のプロセスの値で更新されます。

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

SELECT iSimulationId FROM NmsSimulation WHERE iSimulationId<>0

削除するテーブルの名前は、wkSimu_ プレフィックスとシミュレーションの識別子で構成されます（例：wkSimu_456831_aggr）。

DROP TABLE wkSimu_456831_aggr