MID Server とクローンDetails この KB 記事では、インスタンスクローンが MID Server に与える影響に関する一般的な情報と、留意すべき事項について説明します。 目次 MID Server はクローンされていますか?MID Server のログイン資格情報 問題レコード:mid_serverロールを持つユーザー x が MID Serverに関連付けられていません。レポート期間内にログイン試行はありません。 MID Server の相互認証証明書インスタンス資格情報テーブル クラウドサービスアカウントレコード MID Server 独自のレコード拡張コンテキストMID Server を参照するレコードと設定 デフォルトのオーケストレーション MID Server 添付ファイルインスタンスのバージョンを変更するクローン ダウングレードしようとしている MID Serverファイルの保存によるコードの不一致 エージェントクライアントコネクタ検出とサービスマッピングパターン アップロードされた添付ファイルがありませんパターンが完全に欠落している ヘルスログアナリティクスフル クローン MID Server はクローンされていますか? いいえ。本番インスタンスが準本番インスタンスに対してクローン作成される場合、本番インスタンスの MID Serverは複製またはコピーされず、準本番インスタンスは最終的に本番と同じ MID Serverになりません。 MID Server のインストールは、そのインスタンスが実際に別のインスタンスのコピーであるかどうかに関係なく、常にそのインストールのconfig.xmlファイルに設定されている同じ単一インスタンス URL を指します。 インスタンスごとに少なくとも 1 つの MID Server のインストールが必要です。MID Server 名が異なる限り、同じホストサーバーに複数の MID Server をインストールしてこれを行うことができます。 準本番インスタンスで MID Server の機能を効果的にテストできるようにするには、本番 MID Server の構成をミラーリングし、同じネットワーク環境内に MID Server をインストールすることをお勧めします。 MID Server のログイン資格情報 クローンが新しい構成、データ、さらには異なるバージョンでターゲットインスタンスを上書きした後も、そのターゲットインスタンスの既存の MID Server は、最初に MID Server 用に構成されたものと同じユーザー名とパスワードを使用して、そのインスタンスに接続しようとします。 インスタンス内のユーザーテーブルは、ソースインスタンスのユーザーテーブルのコピーになるため、MID Serverは、現在インスタンスに存在しないユーザーまたは別のパスワードを持つユーザーでログインしようとしている可能性があります。この動作は、クローンを要求するときのオプションの [ユーザーおよび関連テーブルを保存] チェックボックスによって制御されます。 この可能性を回避するには、すべてのインスタンスの MID Server に同じユーザー名とパスワードを使用することをお勧めします。異なる機能に対する異なる MID Server は異なるパスワードを持つことができますが、特定の機能 (特定のリージョン/データセンターの検出など) 用の MID Server では同じユーザー名/パスワードが使用されます。 詳細については、以下を参照してください。 アクティブな MID Server の投稿 資格情報のクローンの問題 既知の問題: ソースインスタンスのクローン履歴ログと ServiceNow サポートポータルの変更要求レコードのコメントに次のテキストが表示される場合があります。これは、MID Server ログインユーザーを保持していない可能性が高いことを意味する問題を示しています。 PRB1391196によりsys_user関連テーブル機能の保存がオフになっています。ユーザーおよび関連テーブルを保持する必要がある場合は、次の KB 記事をご参照ください。 https://hi.service-now.com/kb_view.do?sysparm_article=KB0817569 これにより、クローン後に MID Server がダウンし、MID Server フォームの上部に次のエラーが表示される可能性があります。言及されたユーザーは実際には存在しない可能性があります: エラーメッセージログインユーザー「XXX」に次のロールがありません:mid_server。不足しているロールをこのユーザーに追加します。詳細情報 この問題を解決するには、ユーザーのuser_idが見つからない新しいユーザーを作成し、MDI サーバーのインストール時に使用したものと同じパスワードを設定します。mid_serverロールも忘れずに追加してください。 問題レコード:mid_serverロールを持つユーザー x が MID Serverに関連付けられていません。レポート期間内にログイン試行はありません。 ソース インスタンスの MID Server ロール ユーザーがクローンでコピーされた場合、「MID Serverに関連付けられていないmid_serverロールを持つユーザー x」の問題レコードが発生する可能性があります。これらは、最終的にイベント管理のセルフ健全性モニタリング機能でイベントやアラートに分類されることもあります。 ターゲットインスタンスで使用されていないmid_serverロールを持つユーザーを削除すると、これらのアラートを回避するために削除できます。 MID Server の相互認証証明書 Quebec 以降のインスタンスでは、MID Server はオプションで、ユーザー名 + パスワードの代わりに ) を使用してインスタンスで認証できます。MID Server インストールにインポートされた証明書は、MID Server がインスタンスで認証するために、インスタンステーブル「ユーザークライアント証明書」 [sys_user_certificate] にインポートされた証明書と一致する必要があります。 クローンソースとターゲットの間で異なるユーザーと証明書が使用されている場合は、これらのレコードとその添付ファイルをクローンで保持して除外する必要があります。 インスタンス資格情報テーブル New York リリースより前は、資格情報テーブル [discovery_credentials] がクローンのソースからのレコードに置き換えられていました。New York 以降では、このテーブルはクローンで除外および保持されるため、準本番インスタンスはクローン前に存在していた資格情報レコードを保持します。 このテーブルは、MID Server からの Discovery/Service Mapping プローブによって使用されますが、MID Server を使用しない可能性がある他のいくつかの最近の統合機能によっても使用されます。 デフォルト設定を使用しない場合は、この動作を自分で構成できます。詳細については、以下を参照してください。クローン作成からテーブルを除外するクローン作成ターゲットインスタンスのデータ保持 注:これらの除外/プリザーバー(すぐに利用可能なものを含む)は、クローンの要求時に[除外リストで指定されたテーブルを除外する]および[監査およびログデータを除外する]オプションがオンになっている場合にのみ有効になります。 クローンエンジンのデータプリザーバーと除外コードに問題があり、拡張テーブルのすべての子テーブルが自動的に保持されません。これにより、New York の discovery_credentials の OOTB 除外設定とカスタム設定が解除され、ターゲットに破損した資格情報レコードが残ります。詳細と回避策については、以下を参照してください。KB0717208/PRB1305469 クローンから table-per-class (TPC) 拡張テーブルを除外すると、孤立した検出資格情報が発生し、開こうとしたときに「レコードが見つかりません」というエラーが発生することがあるそれは修正され、PRB1403259によって再び壊れました。より最近の問題PRB1391898、除外するのではなくプリザーバーに関連して同じ破損を引き起こします。これは今すぐ修正する必要があります。 ソースインスタンスとターゲットインスタンスに異なるプラグインがインストールされている場合、破損した資格情報レコードも取得できます。例: 準本番インスタンスにクラウド管理をインストールします。これにより、クラウド機能に固有の検出資格情報テーブルに拡張テーブルが追加されます。例:sn_cmp_ssh_credentials sn_cmp_ssh_credentials資格情報を作成します。拡張テーブルであるため、discovery_credentialsテーブルとsn_cmp_ssh_credentialsテーブルの両方で同じsys_idを使用できます。Cloud Management がインストールされていない本番環境からクローンを作成すると、準本番インスタンスインスタンスには Cloud Management プラグインまたはそのテーブルが存在しなくなります。既定の除外/プリザーバーは、開発インスタンスのdiscovery_credentialsテーブルが保持されることを意味します。sys_class_name=sn_cmp_ssh_credentials のレコードはまだ開発インスタンスに存在しますが、sn_cmp_ssh_credentialsテーブルは存在しなくなります。つまり、破損したレコードを開いたり、編集したり、削除したりすることはできません。また、資格情報を読み込もうとしている MID Server が破損する可能性もあります。 これらのレコードの破損を回避するには、クローンの前に同じプラグインを本番環境にインストールするか、クローンの前にそれらの資格情報レコードを削除する必要があります。この原因でレコードが壊れた場合、子テーブルからsys_idが失われ、レコードが破損したままになるため、後でプラグインをインストールしても役に立ちません。テーブルクリーンアップ [sys_auto_flush] ジョブを使用して削除する必要があります。このジョブは、リストとフォームの下位レベルで削除されます。その方法については、以下で説明されています。KB0723549 クローン後にアクセスできないディスカバリー資格情報を修復する方法 2021年末の時点で、TPC拡張テーブルに関連するクローンエンジンの問題のほとんどは解決されていますが、これは例外です。PRB1542851 クローンによってターゲットインスタンスのdiscovery_credentialsテーブルが破損し、孤立/ゴーストレコードが存在しなくなったクラスが残り、MID Server がすべての資格情報を使用できなくなる可能性がある クラウドサービスアカウントレコード これらは、Discovery の資格情報を保存する点で資格情報レコードに似ていますが、CMDB の CI レコードです。 残念ながら、TPPとクローンに関連して、常に少なくとも1つの既知の問題が常にあり、基本的に、cmdb_ci_cloud_service_accountなどの個々の子クラスの保存および/または除外が機能する可能性は低いです。表示、開く、更新、または削除できない破損したレコードが残る可能性があります。 壊れたレコードは残されます。通常は、sys_idが cmdb にありますが、cmd$par1 または cmdb$par2 のレコードの部分が欠落しています。 レコードは保持されるため、クローン後にsys_class_path値が一致しない場合がありますが、クラスパスシンボルを定義するレコードは、sys_db_objectレコードのサワーインスタンスからコピーされます。 account_idは一意のフィールドでもあり、SQL レベルで一意の制約があることを意味します。破損したレコードが存在する場合、ほとんどの場合は表示されません。これらはまだテーブルに存在しますが、同じアカウント ID に対して適切なレコードが再度挿入されるのを防ぎます。 ソリューション:クローンでクラウドサービスアカウントレコードを除外して保持しようとしないでください。CI クラスを除外して保持せずに再クローンすると、CMDB テーブルが修復されます。 MID Server 独自のレコード MID Server のインストールは、1 つのインスタンスでのみ使用できます。本番 MID Server は引き続き本番を指しているため、これらの MID Server のレコードはコピーする必要がないため、クローンから除外されます。準本番インスタンスの MID Server は引き続きそれを指しているため、これらの MID Server のレコードは保持する必要があります。 これには、プロパティ、パラメーター、クラスター、機能、IP 範囲、アプリケーション、問題などの関連レコードと、MID Server ダッシュボードのレコードが含まれます。 警告:Madrid より前は、これが適切に行われていないことを意味する既知の問題がありました。また、アップグレードされたインスタンスでは、固定の除外/保持リストを取得できず、手動で修正する必要がある場合があります。この問題の修正は、Madrid リリースの一部として提供されています。 MID Server プロパティは難しいテーブルです。すべての MID Server 用のものもあれば、特定の MID Server 用のものもあります。クローンはこれらのレコードを削除して上書きします。デフォルト以外の MID Server プロパティを使用する特定の MID Server は、クローン (PRB1388744) 後に手動で再構成する必要がある場合があります。 いくつかのecc_agentがあります...バージョン固有のコードが含まれているため、クローンで除外してはならないテーブル。これらを除外すると、クローン後のコードが失われたり不一致になったりする可能性があり、MID Server は期待どおりに動作しなくなります。 ecc_agent_jarecc_agent_mibecc_agent_scriptecc_agent_script_fileecc_agent_script_includeecc_agent_script_paramその他.. 注:これらの除外/プリザーバー(すぐに利用可能なものを含む)は、クローンの要求時に[除外リストで指定されたテーブルを除外する]および[監査およびログデータを除外する]オプションがオンになっている場合にのみ有効になります。 拡張コンテキスト ecc_agent_ext_contextはdiscovery_credentialsと同様にTPC拡張テーブルであり、孤立/ゴーストレコードと同じ問題があります。 既知の問題 - 既知のエラー記事で修正ターゲットと修復/回避策の情報を確認してください。 PRB1628241/KB1212634 SNMP トラップおよび vCenter イベントベースの検出 MID Server 拡張コンテキストのクローン除外/プリザーバーがない (ecc_agent_ext_context_trap/ecc_agent_ext_context_vcenter)測定基準インテリジェンス MID Server 拡張コンテキスト (ecc_agent_ext_context_metric) のPRB1628236/KB1212633クローン除外/プリザーバーがないPRB1628223/KB1212632 Event Management MID Server 拡張コンテキストのクローン除外/プリザーバーがない (ecc_agent_ext_context_event/eif_listener_context) ACC に固有の詳細については、「KB1002549 Agent Client Collector とクローン」を参照してください 。 MID Server を参照するレコードと設定 MID Server を使用するすべての機能の設定で、特定の MID Server Sys ID への参照が存在する可能性があります。例えば。 特定の MID Server または MID Server クラスターを使用するように設定された検出スケジュール特定の MID Server を使用するように設定されたデータソースのインポート特定の MID Server に制限された資格情報レコードなど これらの設定の多くはクローンとともにコピーされますが、MID Server はターゲットインスタンス上には存在しなくなります。そのため、これらの機能の多くは動作しないか、予期しない処理を行い、ターゲットインスタンスの MID Server を使用するには再構成する必要があります。 クローン後のクリーンアップスクリプト を使用すると、クローン後にこれらの設定の多くを修正または防止できます。例:検出スケジュールを非アクティブ化およびキャンセルするためのクローン後スクリプトKB0789119 本番 MID Server と同じsys_idになるように MID Server を構成することができます。インストールが同じホスト サーバー上にある場合は、異なる名前にする必要がありますが、sys_idsは同じにすることができます。このプロセスと長所と短所については、以下で詳しく説明します。KB0719301 インスタンスクローン後に、準本番インスタンスで別の MID Server を使用するようにすべての統合機能を再構成する必要がないように、MID Server を手動でクローンする方法 警告:New York より前は、特定の本番 MID Server に設定された検出スケジュールがクローン後に予期せず実行されることがありました:PRB1311068/KB0788922 クローンの後、ターゲットインスタンスに存在せず、現在は破損した参照となっている特定の MID Server の検出スケジュールは、引き続きランダムな MID Server で実行されます。 デフォルトのオーケストレーション MID Server オーケストレーションに使用するデフォルトの MID Server を設定する場所は 2 か所あり、これらのテーブルには値の同期を維持するビジネス ルールのペアがあります。sys_properties では [ORC のデフォルト MID frm sys_propertyを更新] ビジネスルール、ecc_agent_applicationでは [ORC のデフォルト MID frm ecc_agent_appを更新] ビジネスルール。 システムプロパティレコード「mid.server.rba_default」 [sys_properties]/sys_properties.do?sys_id=b7c4086d0a0005957b2ebc930bc717bdMID Server「オーケストレーション」アプリケーション レコード。[ecc_agent_application]/ecc_agent_application.do?sys_id=b5f91a57d7002200bdbaee5b5e6103ec 特定のシステムプロパティのプリザーバーはありません。「オーケストレーション」ecc_agent_applicationレコードのプリザーバーはありませんが、オーケストレーション アプリケーションを特定の MID Serverに割り当てるecc_agent_application_m2mレコードは保持され、除外されます。 これは、プロパティの値とアプリケーションレコードから参照される MID Server がクローン内でコピーされ、クローンターゲットの MID Server ではなくクローンソースであるため、無効な MID Server 名になることを意味します。 これに対処するために、クローン後のクリーンアップスクリプト「存在しない MID をアプリケーションから消去」もあります。これらのレコードは両方ともソースからクローンされている場合、コピーされたレコード内の MID Server はターゲットではなくクローン ソースのものであるため、存在しない MID Server 名が必ず含まれます。ecc_agent_applicationレコードのみを調べて消去した後、ビジネスルールによって関連付けられたプロパティが消去されます。 このKBの作成者は、これがサポートケースを引き起こし続け、2つのレコードはおそらく将来すぐにそのまま保持されるべきであり、それを変更しようとしているため、それは間違った解決策であると考えています。ワークアラウンドとして、クローンプリザーバーをソースインスタンスに手動で追加して、2 つのレコードを保持できます。クローン後のクリーンアップスクリプトも非アクティブ化できます。 関連する問題: 2018年: PRB1254284 デフォルトの MID 選択を修正 - London バージョンにクローン後のクリーンアップ スクリプトを追加しました。2019年: PRB1378067 クローン後、「ecc_agent_app から orc のデフォルト MID を更新 (Update orc default MID from )」ビジネスルールにより、ソースインスタンスでは保持されていても、クローン後、プロパティmid.server.rba_defaultがターゲットインスタンスで空白に設定されます。 2019年に「想定どおりに動作」としてクローズされました。2023年: PRB1673771 mid.server.rba_defaultシステムプロパティとオーケストレーションecc_agent_applicationレコード (IntegrationHub にも適用) のクローンプリザーバーがない 2023年に「想定通りの動作のため、不具合として修正は行われません。」としてクローズされました。 添付ファイル 多くの場合、すべてのレコード添付ファイル、または大きな添付ファイルのみがクローンから除外されます。これらはすべてのデータではなく、すぐに使用できるコードの一部にすることもできます。これらはクローンでコピーする必要がありますが、そうではないことが多く、これの症状は明らかではない場合があります。 アップロード済みファイル [sa_uploaded_file]一部の検出パターンは、EC2 パターンや Oracle パターンなどの添付ファイルから取得されたスクリプトを実行します。次を参照してください。 PRB1507034 [添付ファイルを除外] が true の場合、クローンはテーブルに関連する添付ファイルsa_uploaded_file除外し、Oracle / EC2 検出が中断される2021-07-13以降の新しいクローン用に修正されました。Agent Client Collector プラグイン [sn_agent_asset]Agent Client Collector (ACC) プラグイン (Sensu Assets) は、インスタンスから MID Server に同期し、次に MID Server からそれらを必要とするすべての ACC に同期し、キャッシュフォルダーに抽出されて実行されます。添付ファイルがない場合、それらのアセットを使用したチェックは失敗します。ecc_queue入力には次のようなエラーがあります。'endpoint_discovery.rb' は内部コマンドまたは外部コマンドとして認識されません参照先: sn_agent_asset PRB1550798 で ACC プラグインレコードに添付された tar/gz ファイルを削除すると、大きな添付ファイルを除外するクローンによって Agent Client Collector が壊れる インスタンスのバージョンを変更するクローン ダウングレードしようとしている MID Server クローンの後、既存の準本番 MID Server は突然、そのインスタンスの以前の化身と比較して「異なる」インスタンスと通信していることに気付くでしょう。引き続き接続が試行され、インスタンスの現在のバージョンと一致するようにアップグレード/ダウングレードが試行されます。 アップグレードは機能するはずであり、リリースごとに多くの回帰テストが行われ、機能することを確認します。 ただし、インスタンスが以前のバージョンで終了し (たとえば、準本番インスタンスがアップグレードテストに使用され、その後再度クローンされます)、MID Server で問題が発生する可能性があります。インスタンスと比較して将来のバージョンを実行している MID Server は、将来のインスタンスバージョンにのみ存在する API および暗号化/検証機能を使用して、インスタンスと適切に通信できなくなります。 署名済み ZIP ファイルを使用するバージョンからそうでないバージョンにダウングレードする場合、ダウングレードが機能する前に MID Server を再起動する必要があります。instanceinfo がキャッシュされているため、MID Server は署名済み ZIP ファイルバージョンから非署名バージョンへのアップグレードに失敗します。例: MP10 HF1b から NP8、または NP9 から OP2 Quebec では新しい が使用されます。これは Quebec へのアップグレードの一環として置き換えられますが、ダウングレード時に古い方法に戻されません。 ダウングレードの状況では、特にメジャーバージョン間で、MID Server を手動で再インストールする必要があります。その修復プロセスの詳細については、以下を参照してください。KB0713557 アップグレードの失敗後に MID Server を手動でアップグレードまたは復元する方法 エージェントログまたは問題レコードに「復号化できません」というメッセージが表示される場合は、 リキー のみで十分な可能せがあります。これは、ローマからケベックへのダウングレード後に機能するようです。 ファイルの保存によるコードの不一致 以前のバージョンのインスタンス、または同じプラグインがインストールされていないインスタンスが、新しいバージョンのソースインスタンスからのクローンで上書きされた場合は、すべての「コード」ファイルをそのクローンにコピーする必要があります。 Scripted SOAP Service [sys_web_service] などのテーブルがクローンで保持/除外されている場合、以前のターゲットインスタンスバージョンのレコードのみが残ります (そもそも存在していた場合)。コードバージョンがインスタンスのバージョンと一致しなかったり、プラグインがインストールされていなかったためにレコードが欠落していたりすると、破損する可能性があります。 すぐに使用できるスクリプトとカスタムスクリプトを含むコードテーブルは保持/除外しないでください。更新セットをエクスポートし、クローン後に再度インポートすることをお勧めします。これを行う必要があると思われる場合は、通常、クローンの前にターゲットインスタンスをソースインスタンスと同じバージョンにアップグレードし、最初に同じプラグインとアプリもすべてインストールされていることを確認すると、問題を回避できます。 たとえば、スクリプト化された SOAP サービス「GetMIDInfo」は、起動時に MID Server によってインスタンスのさまざまなデータと設定に使用され、アップグレードで変更されることがよくあります。インスタンスアプリノードの localhost ログに次のようなエラーがある場合は、古いバージョンのレコードを使用することになります: 2023-01-26 01:44:18 (078) API_INT-thread-6 63952EBA972CE15044E7FC000153AFE4 txid=30c52636972c *** Start #104311 /GetMIDInfo.do, user: xxx2023-01-26 01:44:18 (086) SOAPProcessorThreadf4c562fa972ce15044e7fc000153afb8 63952EBA972CE15044E7FC000153AFE4 txid=fcc5eefa972c *** Script: Unsupported request type: xxx エージェントクライアントコネクタ 各 Agent Client Collector インストールは、特定の MID Server で実行されている MID Web サーバー拡張と通信するため、特定のインスタンス名 ACC Websocket エンドポイントと MID Web サーバーコンテキストは、クローン後に同じポートと資格情報の設定で存在している必要があります。存在しないと、Agent Client Collector は MID Server およびインスタンスと通信できなくなります。 バージョン 2.1.41 (cGTM/202009) では、これらの除外/保存設定が含まれていました (PRB1408738)。 また、Agent Client Collector プラグイン [sn_agent_asset] の添付ファイルの問題については、上記の「添付ファイル」セクションを参照してください。 検出とサービスマッピングパターン アップロードされた添付ファイルがありません Oracle や Amazon EC2 などの検出パターンは、アップロードされたファイル [sa_uploaded_file] テーブル内の一部の同期済みファイルに依存します。 一部の添付ファイル (sys_attachment/sys_attachment_doc) が除外されて保存されない場合、一部の検出パターンが機能しなくなります。これは、クローンソースからsa_uploaded_fileレコードをXMLとしてエクスポートすることで解決できます。これにより、エクスポートに添付ファイルが自動的に含まれ、クローンターゲットにインポートされて欠落している添付ファイルが修復されます。 検索可能にするため、添付ファイル名とsa_uploaded_file sys_idsは次のとおりです。 getEC2Detailsv3.ps1 fef7f75e1bfcd0107e02fc078b4bcb16Oracle_PDBS.sql ee37ed860f02001003bea6f6bc767e66Oracle_CDB.sql 95c66d860f02001003bea6f6bc767e4aoptions_packs_usage_statistics.sql 06f603f2db0500104d2f9eb5db9619e7Oracle_instance_size.sql bc515611dbdff34003a05561ca961992 ファイル同期に関する詳細情報:KB0852276:MID Server のファイル同期の仕組み。トラブルシューティングに役立ちます パターンが完全に欠落している Discovery ログに次の警告が表示された場合は、クローンが原因である可能性があります。 Script error in sensor: ReferenceError: "pattern" is not defined. 上記の「MID Server 独自のレコード」セクションでは、テーブル ecc_agent_jar/ecc_agent_mib/ecc_agent_script_file はデータではなくコードであるため、除外/保存しないことについて説明しました。これらのテーブルのもう 1 つの重要な点は、すべてのテーブルがecc_agent_sync_file拡張され、パターンテーブルのsa_patternも拡張されることです。 ecc_agent_sync_file およびこれらの子テーブルは、sys_metadata Table-Per-Class 拡張テーブル、つまりテーブルの大規模なツリー構造の一部であり、インスタンス内のほとんどのコードテーブルを網羅しています。これらすべてのレコードには、レコードがどのアプリケーションレベルのテーブルに属するかを定義するクラスフィールドがあります。SQL レベルでは、レコードのsys_idがsys_metadataに配置され、さらにすべての中間テーブルと子テーブルがあり、各レベルのフィールドを追加すると、フォームに表示されるアプリケーションレベルのレコードが構成されます。 クローンエンジンが Table-Per-Class 拡張テーブルを処理する方法が原因で、すべての子テーブルも除外/保持しないと、一部の SQL テーブルで部分的/破損/ゴースト/孤立したレコードがsys_ids欠落する可能性があります。 たとえば、顧客がecc_agent_script_fileとecc_agent_sync_fileを除外して保持している場合、ecc_agent_script_fileレコードは正しく除外および保持されます。ただし、子テーブル内の他のクラスのファイルは、部分的にのみ保持/除外されます。 緑色は、除外/保持する予定のものと、クローン設定に追加したものです。黄色は、クローンの除外/保存設定にecc_agent_sync_fileが含まれているため、誤って除外/保持されたものでもあります。赤は今欠けているものです。 sys_metadata -> ecc_agent_sync_file -> ecc_agent_script_file sys_metadata -> ecc_agent_sync_file -> ecc_agent_jar sys_metadata -> ecc_agent_sync_file -> sa_pattern パターンのリスト (/sa_pattern_list.do) を見ると、レコードは表示されません。最上位の [/sys_metadata_list.do] から参照し、[クラス] が [Discovery Patterns] のフィルターを追加すると、レコードが一覧表示されますが、レコードを開こうとすると、[Record Not Found] という /sa_pattern.do フォームが表示されます。 アプリケーションレベルで機能するプラグイン修復コードはSQLレベルで破損したレコードを更新できないため、レコードを取り戻すためにプラグイン/アプリを修復しても機能しません。 ソリューション: この状況では、ソースインスタンスのクローン除外とプリザーバーからecc_agent_sync_fileとそれを拡張するテーブルを削除してクローン設定を修正し、再度クローンを作成する必要があります。 ゴーストレコードを削除してから、パターンレコードを含むさまざまなプラグイン/アプリを修復することは可能ですが、これはトリッキーで時間がかかり、SQLレベルで変更が行われるようにするにはサポートケースが必要になります。 ヘルスログアナリティクス MID Server を介して Occultus インスタンスにログをストリーミングするための MID Server 拡張はクローンの影響を受けます。これに関する主な情報源は、次の KB です。KB0867530システムクローン - Health Log Analytics |HLA Quebec フル クローン クローンの要求時に [除外リストで指定されたテーブルを除外する] および [監査およびログデータを除外する] オプションをオフにすると、クローンの除外および設定の保持に関連する すべての設定が無視 されます。これをフルクローンと呼んでいます。クローンの後に、MID Server に関連するすべてのものを再度設定する必要があります。 この動作には問題チケットが存在します。MID Server がまだ壊れているため、完全クローンの観点からは「期待どおりに動作」しています。これによって引き起こされたサポートケースは、現在動作の変更が計画されていない場合でも、リンクする必要があります。するPRB1251951/KB0677995 [監査およびログデータを除外する] および [大きな添付ファイルデータを除外する] チェックボックスをオフにすると、クローンがecc_agentなどのテーブルの除外に失敗する