[]{class="badge informative"}
維持するテーブル 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
Largest
挿入、更新、削除
これはシステムで最大のテーブルです。 送信されるメッセージごとに1つのレコードがあり、これらのレコードは挿入され、配信ステータスを追跡するために更新され、履歴が消去されたときに削除されます。
NmsTrackingLog
大
挿入、削除
トラッキングログは、履歴が消去されたときに挿入および削除されますが、更新されません。
NmsBroadlogMsg
小
更新
この表には、SMTP エラーの選定に使用される情報が含まれています。 このテーブルのインデックスは非常に小さいですが、大幅に更新されるので、このテーブルのインデックスは急速にフラグメント化される傾向があります。
NmsEmailErrorStat
Medium
挿入、更新、削除
このテーブルには、ドメイン別に並べ替えられたSMTP エラーの集計が含まれています。 最初は、クリーンアップタスクが古くなると、クリーンアップタスクによって集計される詳細な情報が含まれます。
NmsBroadLogMid （ミッドソーシングインスタンス上）
大
挿入、更新、削除
5.10 （またはそれ以降）のインスタンスがミッドソーシングインスタンスとして使用されている場合のみ。 これはデータベースで最大のテーブルの1つです。 送信されるメッセージごとに1つのレコードがあり、これらのレコードは挿入され、配信ステータスを追跡するために更新され、履歴が消去されたときに削除されます。 ミッドソーシングを使用する場合、履歴を制限することをお勧めします（通常は2か月未満）。そのため、この表はサイズで合理的なままです（6000万行、data+indexの場合は30 Go未満）。ただし、時間をかけて再構築することが非常に重要です。
NmsBroadLogRcp （NmsRecipient テーブルが使用されている場合）
大
挿入、更新、削除
これはシステムで最大のテーブルです。 送信されるメッセージごとに1つのレコードがあり、これらのレコードは挿入され、配信ステータスを追跡するために更新され、履歴が消去されたときに削除されます。 5.10では、SMTP メッセージ テキストは5.10 バージョンのNmsBroadLogMsg テーブルで因数分解されるので、このテーブルは4.05 （NmsBroadLog）の同等のテーブルよりも小さくなることに注意してください。 ただし、このテーブルのインデックスを定期的に（開始する週ごとに）再び作成し、時間ごとに（月に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によって更新されます。 削除はパージ中に実行されます。 このテーブルのインデックスを定期的に再作成し、再構築することをお勧めします。
NmsEventHisto （Message Center コントロール インスタンス）
大
挿入、更新、削除
NmsRtEventと同様です。 このテーブルは、すべての実行インスタンスのすべてのイベントをアーカイブします。 リアルタイム プロセスではなく、レポートでのみ使用されます。
NmsMobileApp
非常に小さい
挿入、更新、削除
モバイルアプリケーションとその設定を含むテーブル。
NmsAppSubscriptionRcp
大
挿入、更新
通知の送信に使用されるモバイル デバイス （アドレス）の識別子を含むテーブル （受信者テーブルと同様）。
NmsBroadLogAppSubRcp
大
挿入、更新、削除
他のブロードログテーブルと同様ですが、NmsRecipientの代わりにNmsappSubscriptionRcpを使用します。
NmsTrackingLogAppSubRcp
大
挿入、削除
他のtrackingLog テーブルと同様ですが、NmsRecipientの代わりにNmsappSubscriptionRcp テーブルを使用します。
XtkSessionInfo
小
挿入、削除
ユーザーセッションを含むテーブル。 挿入と削除の数は非常に重要です。
顧客テーブル customer-tables
上記のリストに加えて、プラットフォームのセットアップ中に（Adobe Campaign データモデルに存在しない）お客様が作成したテーブルも、特にデータの読み込み中または同期中に頻繁に更新される場合、断片化の対象になる可能性があります。 これらのテーブルは、デフォルトのAdobe Campaign データモデル（NmsRecipientなど）の一部にできます。 この場合、これらのカスタムテーブルを見つけるには、特定のデータベースモデルの監査を実施するのは、Adobe Campaign プラットフォームの管理者の役割です。 これらの表は、必ずしもメンテナンス手順で明示的に言及されているわけではありません。
recommendation-more-help
campaign-classic-help