[オンプレミス／ハイブリッドのみ]{class="badge yellow" title="オンプレミスデプロイメントとハイブリッドデプロイメントにのみ適用されます"}
維持するテーブル tables-to-maintain
管理するテーブルのリストは、Adobe Campaignのバージョン、使用方法およびデータモデル設定によって異なります。
次のリストは、断片化の影響が最も大きいテーブルのみを示しています。 影響は次のとおりです。
- ディスク領域の過剰消費。データベースへのアクセスに影響する。
- 定期的に更新されていないインデックス。クエリパフォーマンスが低下します。
Adobe Campaign テーブル adobe-campaign-tables
テーブル名
サイズ
アクティビティの主なタイプ
コメント
NmsDelivery
小
更新
配信アクションごとに 1 つのレコードがあります。 単一のレコードを複数回更新して配信の進行状況を反映させることができるので、このテーブルのインデックスは迅速にフラグメント化される傾向があります。
NmsDeliveryPart
Medium
挿入、更新、削除
配信の準備中に挿入されるレコードのワークテーブル。 その後、配信中に更新され、配信が完了すると最後に削除されます。
このテーブルは、平均サイズがかなり限られていても、急速にフラグメント化される傾向があります。
このテーブルは、平均サイズがかなり限られていても、急速にフラグメント化される傾向があります。
NmsMirrorPageInfo
大
挿入、削除
この表には、パーソナライズされたミラーページを生成するために必要な情報が含まれています。 メモ （CLOB） フィールドが含まれているため、サイズが非常に大きくなる傾向があります。 ボリュームは、保持されるミラーページの履歴に正比例します。
NmsDeliveryStat
Medium
挿入、更新、削除
このテーブルには、配信プロセスに関する統計が含まれています。 そのレコードは定期的に更新されます。
NmsAddress
Medium
更新、挿入
このテーブルには、メールアドレスに関する情報が含まれています。 これは、強制隔離プロセスの一環として頻繁に更新されます（レコードは最初の配信エラーで作成され、カウンターが変更されると更新され、配信が成功すると削除されます）。
XtkWorkflow
小
更新
ワークフローインスタンスごとに 1 つのレコードがあるので、レコードはほとんどありません。 ただし、テーブルは定期的に更新され、ステータスと進行状況が反映されます。
XtkWorkflowTask
小
挿入、更新、削除
ワークフローアクティビティを実行するたびに、このテーブルにレコードが作成されます。 パージのメカニズムによって、有効期限が切れたら削除されます。
XtkWorkflowEvent
小
挿入、更新、削除
ワークフローのタスク間でアクティブ化された各トランジションによって、このテーブルにレコードが作成されます。 パージメカニズムは、有効期限が切れたらそれらを削除します。
XtkWorkflowJob
非常に小さい
挿入、更新、削除
このテーブルは、ワークフローエンジンに固有のテーブルです。 ワークフローへのコマンドの送信を有効にします（開始、停止、一時停止など）。 小さいテーブルですが、ワークフローにリンクされたトランザクションテーブルのパージ時には、このテーブルが考慮されます。
NmsBroadlog
最大
挿入、更新、削除
これはシステム最大のテーブルです。 送信されたメッセージごとに 1 つのレコードがあり、これらのレコードは、配信ステータスを追跡するために挿入、更新され、履歴がパージされると削除されます。
NmsTrackingLog
大
挿入、削除
トラッキングログは、履歴がパージされると挿入および削除されますが、更新されません。
NmsBroadlogMsg
小
更新
このテーブルには、SMTP エラーの検証に使用する情報が含まれています。 かなり小さいですが、大幅に更新されるので、このテーブルのインデックスは急速にフラグメント化される傾向があります。
NmsEmailErrorStat
Medium
挿入、更新、削除
このテーブルには、SMTP エラーの集計がドメイン別に並べ替えられています。 最初に含まれる詳細情報は、古くなった後にクリーンアップタスクによって集計されます。
NmsBroadLogMid （ミッドソーシングインスタンス上）
大
挿入、更新、削除
5.10 （またはそれ以降）インスタンスがミッドソーシングインスタンスとして使用される場合のみ。 これはデータベースで最大のテーブルの 1 つです。 送信されたメッセージごとに 1 つのレコードがあり、これらのレコードは、配信ステータスを追跡するために挿入、更新され、履歴がパージされると削除されます。 ミッドソーシングを使用する場合、履歴を制限することをお勧めします（通常は 2 か月未満）。そのため、このテーブルはサイズの面で妥当ですが（6,000 万行に対して 30 未満、data+index）、時々再構築することが非常に重要です。
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 を持ちます。
の代わりに NmsRtEvent を持ちます。
NmsTrackingLogRtEvent （Message Center 実行インスタンス）
大
挿入、削除
他の trackingLog テーブルと同様ですが、NmsRecipient.
の代わりに NmsRtEvent テーブルを使用します。
の代わりに NmsRtEvent テーブルを使用します。
NmsRtEvent （Message Center 実行インスタンス）
大
挿入、更新、削除
Message Center のイベントキューを含むテーブル。 これらのイベントのステータスは、処理されると Message Center によって更新されます。 削除はパージ中に実行されます。 このテーブルのインデックスを定期的に再作成し、再構築することをお勧めします。
NmsEventHisto （Message Center コントロールインスタンス）
大
挿入、更新、削除
NmsRtEvent と同様です。 このテーブルは、すべての実行インスタンスのすべてのイベントをアーカイブします。 リアルタイムプロセスでは使用されず、レポートでのみ使用されます。
NmsMobileApp
非常に小さい
挿入、更新、削除
モバイルアプリケーションとその設定を含むテーブル。
NmsAppSubscriptionRcp
大
挿入、更新
通知の送信に使用されるモバイルデバイスの識別子（アドレス）を含むテーブル （受信者テーブルと同様）。
NmsBroadLogAppSubrcp
大
挿入、更新、削除
他の broadlog テーブルと同様ですが、NmsRecipient.
の代わりに NmsappSubscriptionRcp を使用します。
の代わりに NmsappSubscriptionRcp を使用します。
NmsTrackingLogAppSubRcp
大
挿入、削除
他の trackingLog テーブルと同様ですが、NmsRecipient.
の代わりに NmsappSubscriptionRcp テーブルを使用します。
の代わりに NmsappSubscriptionRcp テーブルを使用します。
XtkSessionInfo
小
挿入、削除
ユーザーセッションを含むテーブル。 挿入と削除の数は非常に重要です。
顧客テーブル customer-tables
上記のリストに加えて、プラットフォームをセットアップする際に（Adobe Campaign データモデルに存在しない）お客様が作成したテーブルも、特にデータの読み込みや同期手順の際にテーブルが頻繁に更新される場合、断片化の影響を受ける可能性があります。 これらのテーブルは、デフォルトのAdobe Campaign データモデル（例：NmsRecipient）の一部にすることができます。 この場合、カスタムテーブルを見つけるには、Adobe Campaign プラットフォームの管理者が個々のデータベースモデルの監査を実施する必要があります。 これらのテーブルは、アドビのメンテナンス手順で必ずしも明示的に言及されているわけではありません。
recommendation-more-help
601d79c3-e613-4db3-889a-ae959cd9e3e1