維持するテーブルのリストは、Adobe Campaignのバージョン、使用方法、データモデル設定によって異なります。
次のリストには、フラグメントの対象となるテーブルのみが含まれています。 影響は次のとおりです。
テーブル名 |
サイズ |
アクティビティの主なタイプ |
コメント |
---|---|---|---|
NmsDelivery |
小 |
アップデート |
配信の操作ごとに1つのレコードがあります。 1つのレコードは配信の進行状況を反映するために複数回更新できるので、このテーブルのインデックスは急速にフラグメント化する傾向があります。 |
NmsDeliveryPart |
中 |
挿入、更新、削除 |
配信の準備中に挿入されるレコードの作業テーブル。 その後、配信中に更新され、配信が完了すると、最後に削除されます。 このテーブルは、平均サイズがかなり制限されているにもかかわらず、速くフラグメント化される傾向があります。 |
NmsMirrorPageInfo |
大 |
挿入、削除 |
次の表に、パーソナライズされたミラーページを生成するために必要な情報を示します。 メモ型(CLOB)フィールドが含まれているので、非常に大きくなりがちです。 ボリュームは、保存されるミラーページの履歴に正比例します。 |
NmsDeliveryStat |
中 |
挿入、更新、削除 |
次の表に、配信プロセスの統計を示します。 レコードは定期的に更新されます。 |
NmsAddress |
中 |
アップデート、挿入 |
次の表に、電子メールアドレスに関する情報を示します。 このレポートは、強制隔離処理の一環として頻繁に更新されます(最初の配信エラー時にレコードが作成され、カウンターが変更され、配信が成功すると削除されます)。 |
XtkWorkflow |
小 |
アップデート |
ワークフローインスタンスごとに1つのレコードがあるので、レコードはほとんどありません。 しかし、テーブルは定期的に更新され、状態と進行状況が反映されます。 |
XtkWorkflowTask |
小 |
挿入、更新、削除 |
ワークフローアクティビティを実行するたびに、このテーブルにレコードが作成されます。 パージメカニズムは、有効期限が切れると削除します。 |
XtkWorkflowEvent |
小 |
挿入、更新、削除 |
ワークフロー内のタスク間でアクティブ化された各トランジションは、このテーブル内にレコードを作成することになります。 削除メカニズムは、有効期限が切れると削除します。 |
XtkWorkflowJob |
非常に小さい |
挿入、更新、削除 |
この表はワークフローエンジンに固有です。 ワークフロー(開始、停止、一時停止など)に対するコマンドの送信を有効にします。 小さいが、ワークフローにリンクされたトランザクションテーブルを削除する際に、このテーブルが考慮されます。 |
NmsBroadLog |
最大 |
挿入、更新、削除 |
これはシステム内で最も大きなテーブルです。 送信されたメッセージごとに1つのレコードがあり、これらのレコードが挿入され、配信のステータスを追跡するために更新され、履歴が削除されると削除されます。 |
NmsTrackingLog |
大 |
挿入、削除 |
トラッキングログは、履歴が削除されると挿入および削除されますが、更新はされません。 |
NmsBroadlogMsg |
小 |
アップデート |
このテーブルには、SMTPエラーの適用に使用される情報が含まれています。 この値は非常に小さいですが、大幅に更新されるので、この表のインデックスは急速にフラグメント化しがちです。 |
NmsEmailErrorStat |
中 |
挿入、更新、削除 |
次の表に、SMTPエラーの集計をドメイン順に並べ替えます。 最初は、古くなった後にクリーンアップタスクによって集計された詳細情報が含まれます。 |
NmsBroadLogMid (ミッドソーシングインスタンス上) |
大 |
挿入、更新、削除 |
5.10(以降)インスタンスがミッドソーシングインスタンスとして使用される場合のみ。 これは、データベース内で最も大きいテーブルの1つです。 送信されたメッセージごとに1つのレコードがあり、これらのレコードが挿入され、配信のステータスを追跡するために更新され、履歴が削除されると削除されます。 ミッドソーシングを使用する場合、履歴を制限することを推奨します(通常は2か月未満)。したがって、この表は妥当なサイズ(6,000万行、data+indexについて30Go未満)ですが、時折再構築することが非常に重要です。 |
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実行インスタンス) |
大 |
挿入、更新、削除 |
他のブロードローグテーブルと同様ですが、NmsRecipientではなくNmsRtEventを使用します。 |
NmsTrackingLogRtEvent(Message Center実行インスタンス) |
大 |
挿入、削除 |
他のtrackingLogテーブルと同様ですが、NmsRecipientではなくNmsRtEventテーブルを使用します。 |
NmsRtEvent (Message Center実行インスタンス) |
大 |
挿入、更新、削除 |
Message Centerイベントキューを含む表。 これらのイベントのステータスは、処理されるとMessage Centerによって更新されます。 削除は、削除中に実行されます。 このテーブルのインデックスを定期的に再作成し、再構築することをお勧めします。 |
NmsEventHisto (Message Centerコントロールインスタンス) |
大 |
挿入、更新、削除 |
NmsRtEventと同様です。 この表は、すべての実行インスタンスのすべてのイベントをアーカイブします。 リアルタイムの処理を行わない場合、レポートでのみ使用されます。 |
NmsMobileApp |
非常に小さい |
挿入、更新、削除 |
モバイルアプリケーションとその設定を含む表。 |
NmsAppSubscriptionRcp |
大 |
挿入、更新 |
通知の送信に使用されるモバイルデバイス(アドレス)の識別子を含む表(受信者表と同様)。 |
NmsBroadLogAppSubRcp |
大 |
挿入、更新、削除 |
他のブロードローグテーブルと同様ですが、NmsRecipientではなくNmsappSubscriptionRcpを使用します。 |
NmsTrackingLogAppSubRcp |
大 |
挿入、削除 |
他のtrackingLogテーブルと同様ですが、NmsRecipientではなくNmsappSubscriptionRcpテーブルを使用します。 |
XtkSessionInfo |
小 |
挿入、削除 |
ユーザーセッションを含むテーブル。 挿入と削除の数は非常に重要です。 |
上記のリストに加えて、プラットフォームの設定時にお客様が作成した(Adobe Campaignデータモデルに存在しない)テーブルも、フラグメントの対象となります。特に、データの読み込みや同期の手順時に頻繁に更新される場合があります。 これらのテーブルは、デフォルトのAdobe Campaignデータモデルの一部にすることができます(例:NmsRecipient)。 この場合、特定のAdobe Campaignモデルの監査を実行して、これらのカスタム表を見つけるのは、データベースプラットフォームの管理者次第です。 これらのテーブルは、メンテナンス手順で明示的に説明されているわけではありません。