維持するテーブル

保持するテーブルのリストは、Adobe Campaignのバージョン、使用方法、データモデル設定によって異なります。

次のリストには、断片化の対象として最も多いテーブルのみが表示されます。 影響は次のとおりです。

  • ディスク領域の過剰消費により、データベース・アクセスに影響を与える
  • 定期的に更新されていないインデックスがあり、クエリのパフォーマンスが低下します。

Adobe Campaignテーブル

テーブル名
サイズ
 アクティビティの主なタイプ
 コメント
NmsDelivery
 小
アップデート
 配信アクションごとに 1 つのレコードがあります。 1 つのレコードは、配信の進行状況を反映するために複数回更新できるので、このテーブルのインデックスは急速にフラグメント化する傾向があります。
NmsDeliveryPart
 中
 挿入、更新、削除
配信の準備中にレコードが挿入される作業用テーブル。 その後、配信中に更新され、配信が完了すると最後に削除されます。
このテーブルは、平均サイズがかなり限られているにもかかわらず、急速にフラグメント化する傾向があります。
NmsMirrorPageInfo
 大
 挿入、削除
この表には、パーソナライズされたミラーページの生成に必要な情報が含まれています。 メモ (CLOB) フィールドが含まれているので、非常に大きい傾向があります。 ボリュームは、保持するミラーページの履歴に正比例します。
NmsDeliveryStat
 中
 挿入、更新、削除
このテーブルには、配信プロセスに関する統計情報が含まれています。 レコードは定期的に更新されます。
NmsAddress
 中
 更新、挿入
このテーブルには、E メールアドレスに関する情報が含まれます。 この値は、強制隔離プロセスの一環として頻繁に更新されます（最初の配信エラー時にレコードが作成され、配信が正常に完了するとカウンターが変更および削除されます）。
XtkWorkflow
 小
アップデート
 ワークフローインスタンスごとに 1 つのレコードがあるので、レコードはほとんどありません。 ただし、テーブルは定期的に更新され、ステータスと進行状況を反映します。
XtkWorkflowTask
 小
挿入、更新、削除
ワークフローアクティビティを実行するたびに、このテーブルにレコードが作成されます。 パージメカニズムは、期限切れになると削除します。
XtkWorkflowEvent
 小
挿入、更新、削除
ワークフロー内のタスク間でアクティブ化された各トランジションは、このテーブル内にレコードを作成します。 パージメカニズムは、期限切れになると削除します。
XtkWorkflowJob
 非常に小さい
挿入、更新、削除
このテーブルはワークフローエンジンに固有です。 ワークフローへのコマンドの送信（開始、停止、一時停止など）が可能です。 このテーブルは小さいですが、ワークフローにリンクされたトランザクションテーブルのパージ中にこのテーブルが考慮されます。
NmsBroadLog
 最大
挿入、更新、削除
これはシステム内で最も大きなテーブルです。 送信されるメッセージごとに 1 つのレコードがあり、これらのレコードが挿入され、配信ステータスを追跡するように更新され、履歴がパージされると削除されます。
NmsTrackingLog
 大
 挿入、削除
履歴がパージされると、トラッキングログは挿入および削除されますが、更新はされません。
NmsBroadlogMsg
小
アップデート
 この表は、SMTP エラーの検証に使用する情報を示しています。 この値はかなり小さいですが、大量に更新されるので、このテーブルのインデックスは急速にフラグメント化する傾向があります。
NmsEmailErrorStat
 中
 挿入、更新、削除
この表には、SMTP エラーの集計がドメイン別に並べ替えられています。 最初は、クリーンアップタスクが期限切れになった後にクリーンアップタスクによって集計される詳細な情報が含まれます。
NmsBroadLogMid（ミッドソーシングインスタンスの場合）
 大
 挿入、更新、削除
5.10 以降のインスタンスがミッドソーシングインスタンスとして使用される場合のみ。 これは、データベース内で最も大きいテーブルの 1 つです。 送信されるメッセージごとに 1 つのレコードがあり、これらのレコードが挿入され、配信ステータスを追跡するように更新され、履歴がパージされると削除されます。 ミッドソーシングを使用する場合は、履歴を制限することをお勧めします（通常は 2 ヶ月未満）。この表は、サイズの面では妥当ですが（6,000 万行、データ+インデックスの場合は 30 Go 未満）、時々再構築することが非常に重要です。
NmsBroadLogRcp （NmsRecipient テーブルを使用する場合）
大
 挿入、更新、削除
これはシステム内で最も大きなテーブルです。 送信されるメッセージごとに 1 つのレコードがあり、これらのレコードが挿入され、配信ステータスを追跡するように更新され、履歴がパージされると削除されます。 5.10 では、SMTP メッセージテキストが 5.10 バージョンの NmsBroadLogMsg テーブルに組み込まれるので、このテーブルは 4.05(NmsBroadLog) の同等のテーブルよりも小さいことに注意してください。 ただし、このテーブルを定期的に（最初は 1 週間おきに）再インデックス化し、時々（月に 1 回、またはパフォーマンスに影響が出た場合）完全に再構築する必要があります。
YyyBroadLogXxx （外部の受信者テーブルを使用する場合）
 大
 挿入、更新、削除
NmsBroadLogRcp と同じですが、外部の受信者テーブルがあります。 Yyy および Xxx は、配信マッピングの値に合わせて調整してください。
NmsTrackingLogRcp （NmsRecipient テーブルを使用する場合）
大
 挿入、削除
履歴がパージされると、トラッキングログは挿入および削除されますが、更新はされません。 ボリュームは、データ保持の長さによって異なります。
YyyTrackingLogXxx （外部の受信者テーブルを使用する場合）
 大
 挿入、削除
NmsTrackingLogRcp と同じですが、外部の受信者テーブルがあります。 Yyy および Xxx は、配信マッピングで使用する値に合わせて調整してください。
NmsBroadLogRtEvent（Message Center 実行インスタンス）
 大
 挿入、更新、削除
他の broadLog テーブルと同様ですが、NmsRecipient.
ではなく NmsRtEvent を使用します。
NmsTrackingLogRtEvent（ Message Center 実行インスタンス）
 大
 挿入、削除
他の trackingLog テーブルと同様ですが、NmsRecipient.
ではなく NmsRtEvent テーブルを使用します。
NmsRtEvent（Message Center 実行インスタンス）
 大
 挿入、更新、削除
Message Center のイベントキューを含む表。 これらのイベントのステータスは、処理時に Message Center によって更新されます。 削除はパージ中に実行されます。 このテーブルのインデックスを定期的に再作成し、再構築することをお勧めします。
NmsEventHisto（Message Center コントロールインスタンス）
 大
 挿入、更新、削除
NmsRtEvent と同様です。 この表は、すべての実行インスタンスのすべてのイベントをアーカイブします。 リアルタイムのプロセスではなく、レポートでのみ使用されます。
NmsMobileApp
 非常に小さい
挿入、更新、削除
モバイルアプリケーションとその設定を含む表。
NmsAppSubscriptionRcp
 大
 挿入、更新
通知の送信に使用するモバイルデバイス（アドレス）の識別子を含む表（受信者の表と同様）。
NmsBroadLogAppSubRcp
 大
 挿入、更新、削除
他の broadLog テーブルと同様ですが、NmsRecipient.
ではなく NmsappSubscriptionRcp を使用します。
NmsTrackingLogAppSubRcp
 大
 挿入、削除
他の trackingLog テーブルと同様ですが、NmsRecipient.
ではなく NmsappSubscriptionRcp テーブルを使用します。
XtkSessionInfo
 小
挿入、削除
ユーザーセッションを含むテーブル。 挿入と削除の数は非常に重要です。

顧客テーブル

上記のリストに加えて、(Adobe Campaignデータモデルに存在しない ) プラットフォームの設定時に顧客が作成したテーブルも、断片化の対象になる場合があります。特に、データの読み込みや同期の手順時に頻繁に更新される場合があります。 これらのテーブルは、デフォルトのAdobe Campaignデータモデルの一部にすることができます（例：NmsRecipient）。 この場合、Adobe Campaignプラットフォームの管理者が、特定のデータベースモデルを監査して、これらのカスタムテーブルを見つけます。 これらの表は、必ずしもメンテナンス手順で明示的に言及されているわけではありません。

このページ