データベースクリーンアップのワークフロー 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)

操作によって復元された​ Select ​型リストは、次のクエリを使用して削除されます。

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

ステータスの値が​Start pending、In progress、Recovery pending、Recovery in progress、Pause requested、Pause in progress、または​Paused （値51、55、61、62、71、72、75）の場合、配信は停止され、タスクはリンクされた情報をパージします。

データベースのクリーンアップ ワークフローは、有効期限が切れた配信のリストを作成します。 このリストには、Finished​以外のステータスを持つ期限切れの配信と、最近停止した配信のうち、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は​Finished ステータスと一致し、$(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は​Finished ステータスに、delivery state 85は​Stopped ステータスに一致し、$(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)は、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))

各変数が前のクエリで取得した値と一致する場所。

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

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

SELECT iSimulationId FROM NmsSimulation WHERE iSimulationId<>0

削除するテーブルの名前は、wkSimu_​接頭辞に続くシミュレーションの識別子で構成されます（例：wkSimu_456831_aggr）。

DROP TABLE wkSimu_456831_aggr