MID Server とクローンSummary この KB 記事では、インスタンスクローンによる MID Server の影響に関する一般的な情報と、留意する必要がある事項について説明します。 目次 MID Server はクローンされますか？MID Server のログイン資格情報 Issue record: User x with mid_server role not associated with a MID Server. No login attempts within reporting period. MID Server の相互認証証明書インスタンス認証情報テーブル クラウドサービスアカウントレコード MID Server 独自のレコード MID Server Cluster 拡張コンテキスト暗号化キーMID Server を参照するレコードと設定 デフォルトの Orchestration MID Server 添付ファイルインスタンスのバージョンを変更するクローン ダウングレードを試行する MID Serverファイルの保持によるコードの不一致 Agent Client ConnectorDiscovery および Service Mapping パターン Uploaded File の添付ファイルが見つからないパターンが完全に欠落している場合 Health Log Analytics (ヘルスログアナリティクス)フルクローン MID Server はクローンされますか？ いいえ。本番インスタンスをサブプロダクションインスタンスにクローンする場合、本番インスタンスの MID Server は複製またはコピーされず、サブプロダクションインスタンスに本番環境と同じ MID Server が設定されることはありません。 MID Server のインストールは、そのインスタンスが実際に別のインスタンスのコピーになっているかどうかに関係なく、常にそのインストールの config.xml ファイルで設定された同じ 1 つのインスタンス URL を参照します。 インスタンスごとに少なくとも 1 つの MID Server のインストールが必要です。同じホストサーバーに複数の MID Server をインストールすることで、それらの MID Server 名が異なっている限り、これを実現できます。 サブプロダクションインスタンスで MID Server の機能を効果的にテストできるようにするには、本番環境の MID Server 構成をミラーリングし、同じネットワーク環境内に MID Server をインストールすることをお勧めします。 MID Server のログイン資格情報 クローンによってターゲットインスタンスが新しい構成、データ、さらには別のバージョンで上書きされた後も、そのターゲットインスタンスの既存の MID Server は、最初に MID Server 用に設定されたものと同じユーザー名とパスワードを使用して接続を試行します。 インスタンス内のユーザーテーブルはソースインスタンスのユーザーテーブルのコピーになるため、MID Server はインスタンスに存在しないユーザー、またはパスワードが異なるユーザーとしてログインを試行する可能性があります。この動作は、クローンのリクエスト時に指定する Preserve users and related tables チェックボックスによって制御されます。 この可能性を回避するには、すべてのインスタンスの MID Server に同じユーザー名とパスワードを使用することをお勧めします。機能ごとに異なる MID Server に異なるパスワードを設定できますが、特定の機能 (特定のリージョン／データセンターの Discoveryなど) の MID Server では同じユーザー名／パスワードが使用されます。 詳細については、次を参照してください: クローン後のアクティブな MID Server の資格情報の問題 既知の問題: ソースインスタンスの Clone History ログおよび ServiceNow Support ポータルの Change Request レコードのコメントに、次のテキストが表示される場合があります。このテキストは、MID Server のログインユーザーが保持されていない可能性が高いことを示しています。 Preserve sys_user related table feature is turned off due to PRB1391196. If you need to preserve the users and related tables,you can follow the following KB article: https://hi.service-now.com/kb_view.do?sysparm_article=KB0817569 これにより、クローン後に MID Server が Down 状態になり、MID Server フォームの上部に次のエラーが表示される可能性があります。記載されているユーザーは実際には存在しない可能性があります: Error MessageLogged in user 'XXX' is missing the following roles: mid_server. Add the missing roles to this user. More Info これを解決するには、エラーに記載されている存在しないユーザーと同じ user_id を持つ新しいユーザーを作成し、MID Server のインストール時に使用したものと同じパスワードを設定します。mid_server ロールも忘れずに追加してください。 Issue record: User x with mid_server role not associated with a MID Server. No login attempts within reporting period. ソースインスタンスの mid_server ロールを持つユーザーがクローンでコピーされると、User x with mid_server role not associated with a MID Server という Issue レコードが複数作成される場合があります。これらのレコードは、Event Management の Self-Health Monitoring 機能でイベントやアラートとして表示されることもあります。 ターゲットインスタンスで使用されていないmid_server ロールを持つユーザーを削除することで、それらのアラートを回避できます。 MID Server の相互認証証明書 Quebec 以降のインスタンスでは、MID Server はオプションで、ユーザー名 + パスワードの代わりに Mutual Authentication (mTLS) を使用して インスタンスに対して認証できます。MID Server のインストールにインポートされた証明書は、MID Server がインスタンスに対して認証を行うために、インスタンスの User Client Certificates [sys_user_certificate] テーブルにインポートされた証明書と一致する必要があります。 クローン元とクローン先で異なるユーザーと証明書を使用している場合、これらのレコードとその添付ファイルをクローンで Preserve および Exclude する必要があります。 インスタンス認証情報テーブル New York リリースより前は、クローンを実行すると、Credentials [discovery_credentials] テーブルがクローン元のレコードで置き換えられていました。New York 以降、このテーブルはクローンで Exclude および Preserve の対象となるため、サブプロダクションインスタンスではクローン前の Credential レコードが保持されます。 このテーブルは、MID Server からのDiscovery／Service Mapping のプローブによって使用されますが、MID Server を使用しない可能性のある他の最近の統合機能によっても使用されます。 デフォルト設定を使用したくない場合は、この動作を自分で設定できます。詳細については、以下を参照してください。クローン作成からテーブルを除外するクローン作成ターゲットインスタンスのデータ保持 注：これらの Excludes／Preservers（標準提供のものを含む）は、クローンのリクエスト時に Exclude tables specified in Exclusion List および Exclude audit and log data オプションがオンになっている場合にのみ有効になります。 Clone Engine の Data Preserver および Exclude のコードには、拡張テーブルのすべての子テーブルが自動的に Preserve されないという問題があります。これにより、New York の discovery_credentials に対する標準提供の Exclude 設定とカスタム設定が機能せず、破損した Credential レコードがクローン先に残ります。詳細と回避策については、以下を参照してください。KB0717208/PRB1305469 Excluding table-per-class (TPC) extended tables from a clone can cause orphaned Discovery Credentials with the 'Record not found' error when trying to open themこの問題は修正されましたが、PRB1403259 によって再発しました。より新しい問題である PRB1391898 でも、Exclude ではなく Preserver に関連して同じ破損が発生します。現在は修正されているはずです。 クローン元インスタンスとクローン先インスタンスに異なるプラグインがインストールされている場合、Credential レコードが破損する可能性もあります。例： サブプロダクションインスタンスに Cloud Management をインストールすると、Cloud 機能に固有の拡張テーブルが Discovery Credentials テーブルに追加されます。例:sn_cmp_ssh_credentials。 sn_cmp_ssh_credentials資格情報を作成します。拡張テーブルであるため、discovery_credentialsテーブルとsn_cmp_ssh_credentialsテーブルの両方に同じsys_idがあります。Cloud Management がインストールされていない本番環境からクローンを実行すると、サブプロダクションインスタンスには Cloud Management プラグインもそのテーブルも存在しなくなります。デフォルトの Excludes／Preservers により、dev インスタンスの discovery_credentials テーブルは Preserve されます。sys_class_name=sn_cmp_ssh_credentials のレコードは引き続きdev インスタンスに存在しますが、sn_cmp_ssh_credentialsテーブルには存在しません。つまり、破損したレコードを開いたり、編集したり、削除したりすることはできません。また、MID Server による資格情報の読み込みが失敗する可能性もあります。 これらのレコードの破損を回避するには、クローンの前に同じプラグインを本番環境にインストールするか、クローンの前にそれらの資格情報レコードを削除する必要があります。この原因でレコードが破損している場合、子テーブルには対応する sys_id のレコードが存在せず、破損した状態が続くため、後からプラグインをインストールしても解決しません。リストやフォームよりも下位のレベルで削除されるため、Table Cleanup [sys_auto_flush] ジョブを使用して削除する必要がある可能性があります。この方法については、以下で説明します。KB0723549 How to repair Discovery Credentials not accessible after clone 2021 年末の時点で、TPC 拡張テーブルに関連するクローンエンジンの問題のほとんどは解決されていますが、次の問題は未解決です。KB1000116 A clone can corrupt the discovery_credentials table on the target instance, leaving orphan/ghost records with a class that no longer exists, preventing MID Server using all credentials クラウドサービスアカウントレコード これらは、Discovery の資格情報を保存する点で資格情報レコードと似ていますが、CMDB 内の CI レコードです。 残念ながら、TPC とクローンに関連する既知の問題が常に少なくとも 1 つは未解決であるため、cmdb_ci_cloud_service_account などの個々の子クラスを Preserve または Exclude しても、正常に機能しない可能性が高くなります。表示、開く、更新、または削除できない破損したレコードが残る可能性があります。 通常、sys_id は cmdb テーブルに存在しますが、cmdb$par1 または cmdb$par2 に対応するレコードが存在しないため、破損したレコードが残ります。 レコード自体は保持されますが、クラスパスのシンボルを定義する sys_db_object レコードはソースインスタンスからコピーされるため、クローン後に sys_class_path の値が一致しなくなる可能性があります。 また、account_idは一意のフィールドであるため、SQL レベルで一意の制約があります。破損したレコードが存在する場合、ほとんどの場合、それらは表示されません。これらはまだテーブルに存在しますが、同じアカウント ID に対して適切なレコードが再度挿入されるのを防ぎます。 解決策:クローンでは、Cloud Service Account レコードを Exclude または Preserve しないでください。いずれの CI クラスも Exclude／Preserve せずに再度クローンを実行すると、CMDB テーブルが修復されます。 MID Server 独自のレコード MID Server のインストールは、1 つのインスタンスでのみ使用できます。本番 MID Server は引き続き本番環境を参照するため、それらの MID Server のレコードをコピーする必要はなく、クローンでは Exclude されます。サブプロダクションインスタンスの MID Server は引き続きそのインスタンスを参照するため、それらの MID Server のレコードは Preserve する必要があります。 これには、Properties、Parameters、Clusters、Capabilities、IP Ranges、Applications、Issues、および MID Server Dashboard のレコードなどの関連レコードが含まれます。 警告：Madrid より前には、これらのレコードが正しく Exclude／Preserve されない既知の問題がありました。アップグレードされたインスタンスは、修正済みの Exclude／Preserve リストを取得できない場合があり、手動で修正する必要があります。この問題の修正は、Madrid リリースの一部として利用可能です。 すべての MID Server 用もあれば、特定の MID Server 用もあるため、MID Server Properties は扱いが難しいテーブルです。クローンはこれらのレコードを削除して上書きします。デフォルト以外の MID Server プロパティを持つ特定の MID Server は、クローン後に手動で再設定する必要がある場合があります (PRB1388744)。 バージョン固有のコードが格納されているため、クローンで決して Exclude してはならない ecc_agent... テーブルがいくつかあります。これらを除外すると、クローン後にコードの欠落や不一致が発生し、MID Server が期待どおりに動作しなくなる可能性があります。 ecc_agent_jarecc_agent_mibecc_agent_scriptecc_agent_script_fileecc_agent_script_includeecc_agent_script_paramsa_patternその他... これらの大部分は ecc_agent_sync_file を拡張するテーブルであり、MID Server に同期された後、MID Server 上で実行されるプローブが使用するコードを格納しています。クローン後にこれらが失われると、実質的にすべての MID Server 関連の機能または統合からのさまざまなプローブが、依存関係が欠落するために失敗します。 注：これらの Excludes／Preservers（標準提供のものを含む）は、クローンのリクエスト時に Exclude tables specified in Exclusion List および Exclude audit and log data オプションがオンになっている場合にのみ有効になります。 MID Server Cluster MID Server Cluster は、それに含まれる MID Server に固有であり、その MID Server はインスタンスに固有であるため、Preserve および Exclude の対象になります。ただし、Discovery Schedules や IntegrationHub 接続など、MID Server Cluster を指定する可能性のある機能設定はクローンによってコピーされるため、Cluster への参照が壊れる可能性があります。 ただし、クローン後に Discovery Schedules などのジョブ内の参照が壊れるのを防ぐ便利な方法があります。これにより、クローン元からコピーされたジョブは、再設定することなく引き続き実行できるようになります。 本番環境／クローン元に MID Server Cluster レコードを作成します。これを XML としてエクスポートし、サブプロダクション環境/クローン先のインスタンスにインポートします。次に、各サブプロダクション環境／クローン先インスタンスで、そのインスタンスに関連する MID Server をその Cluster にリンクします。 拡張コンテキスト ecc_agent_ext_context は discovery_credentials と同様に TPC 拡張テーブルであり、孤立/ゴースト レコードでも同じ問題が発生します。 既知の問題：修正対象バージョンおよび修復／回避策の情報については、Known Error 記事を確認してください。 PRB1628241 / KB1212634 Clone Excludes/Preservers are missing for SNMP Trap and vCenter Event based Discovery MID Server extension contexts (ecc_agent_ext_context_trap / ecc_agent_ext_context_vcenter)PRB1628236 / KB1212633 Clone Excludes/Preservers are missing for Metric Intelligence MID Server extension contexts (ecc_agent_ext_context_metric)PRB1628223 / KB1212632 Clone Excludes/Preservers are missing for Event Management MID Server extension contexts (ecc_agent_ext_context_event / eif_listener_context) ACC に固有の詳細については、KB1002549 Agent Client Collector and Clones を参照してください。 暗号化キー 名前が sys_kmf_... で始まる Key Management Framework テーブルはすべてインスタンス固有であるため、Preserve および Exclude の対象にする必要があります。インスタンス内のレコードの password2 フィールドなどが対象です。過去にも問題がありましたが、今ではこれらのレコードはクローンで適切に処理されるはずです。 ただし、インスタンスと MID Server の間で送信されるデータの暗号化に使用される、ecc_encryption_key という別のテーブルがあります。このテーブルは Paris で追加され、Quebec 以降では標準提供の Clone Preservers および Excludes に含まれている必要があります。これらの Clone Preservers または Excludes が欠落している場合、MID Server のデータ暗号化が機能しなくなります。 Vancouver 以降、そのキーは 3DES ではなく AES を使用して暗号化され、Washington DC 以降は、標準提供の DES3 レコードはアップグレード (PRB1678069) で削除されます。この変更の詳細については、以下を参照してください。KB0862631 MID Server and Credentials Encryption/Decryption - Symmetrical Keys AES256 and 3DES questions ecc_encryption_key レコードが欠落している場合、またはそのレコードのキーが空の場合、JDBCProbe ペイロード内のパスワードなど、暗号化された値を含む ecc_queue レコードを作成するコードの実行時に、インスタンス側でエラーが発生する可能性があります。例： AbstractProgressWorker SEVERE *** ERROR *** com.glide.db.impex.JDBCProbeLoaderjava.lang.RuntimeException: com.snc.automation_common.integration.exceptions.EncryptionException: Encryption key must be specified 通常、(バックアップ後に)削除してから新しいレコードを挿入すると、この問題を解決できます。 MID Server を参照するレコードと設定 MID Server を使用するすべての機能の設定に、特定の MID Server の sys_id への参照が存在する可能性があります。例： 特定の MID Server または MID Server Cluster を使用するように設定された Discovery Schedules特定の MID Server を使用するように設定された Import Data Sources特定の MID Server に制限された認証情報レコードなど これらの設定の多くはクローンとともにコピーされますが、MID Server はターゲットインスタンスに存在しません。そのため、これらの機能の多くは機能しないか、予期しない動作をし、ターゲットインスタンスの MID Server を使用するように再設定する必要があります。 Post-Clone Cleanup Scripts を使用すると、クローン後にこれらの設定の多くを修正したり、これらの設定に起因する問題を防止したりできます。例:KB0789119 A Post-Clone script to Deactivate and Cancel Discovery Schedules MID Server に、対応する本番 MID Server と同じ sys_id を設定できます。インストールが同じホストサーバー上にある場合、MID Server 名は異なる必要がありますが、sys_id は同じにできます。このプロセスと利点と欠点については、以下で詳しく説明しています。KB0719301 How to manually Clone a MID Server so that you don't have to reconfigure all integrations features to use a different MID Server on the sub-prod instance after an Instance Clone 警告: New York より前は、特定の本番 MID Server に設定されたDiscovery Schedulesがクローンの後に予期せず実行される場合があります。PRB1311068 / KB0788922 After a Clone, a Discovery Schedule for a Specific MID Server, which does not exist in the target instance and so is now a broken reference, will still run in a random MID Server デフォルトの Orchestration MID Server Orchestration で使用するデフォルトの MID Server を設定する場所は 2 か所あり、これらの値を同期する Business Rule が各テーブルに 1 つずつあります。sys_properties には Update orc default MID frm sys_property、ecc_agent_application には Update orc default MID frm ecc_agent_app という Business Rule があります。 System Propertyレコード「mid.server.rba_default」 [sys_properties]/sys_properties.do?sys_id=b7c4086d0a0005957b2ebc930bc717bdMID Server Orchestration Application レコード。[ecc_agent_application]/ecc_agent_application.do?sys_id=b5f91a57d7002200bdbaee5b5e6103ec 特定の System Property に対する Preserver はありません。Orchestration の ecc_agent_application レコードに対する Preserver もありませんが、Orchestration アプリケーションを特定の MID Server に割り当てる ecc_agent_application_m2m レコードは Preserve および Exclude の対象になります。 これは、プロパティの値とアプリケーションレコードから参照される MID Server がクローンによってコピーされることを意味します。コピーされる MID Server はクローン先ではなくクローン元の MID Server であるため、クローン先では無効な MID Server 名になります。 これに対処するため、Post Clone Cleanup script の Clean Non-Existent MIDs From Application も用意されています。両方のレコードはソースからクローンされるため、クローン先に存在しない MID Server 名が設定されることになります。このスクリプトは ecc_agent_application レコードのみを確認して MID Server の値をクリアし、その後、Business Rule が関連する Property の値をクリアします。 この KB の作成者は、この対応によってサポートケースが継続的に発生しているため、適切な解決策ではないと考えています。また、将来的には、この 2 つのレコードを標準で Preserve するよう変更を試みています。回避策として、ソースインスタンスに Clone Preservers を手動で追加して、この 2 つのレコードを Preserve できます。Post Clone Cleanup script を無効にすることもできます。 関連する問題: 2018: PRB1254284 Fix default MID selection - London バージョンで post clone cleanup script が追加されました。2019: PRB1378067 クローン後、mid.server.rba_default Property がクローン元インスタンスで Preserve されているにもかかわらず、Update orc default MID from ecc_agent_app Business Rule によってクローン先インスタンスでは空白に設定されます。2019 年に Working as Expected としてクローズされました。2023: PRB1673771 mid.server.rba_default System Property および Orchestration ecc_agent_application レコードに対する Clone Preserver がありません（IntegrationHub にも適用されます）。2023 年に This is the intended behavior so will not fix as a defect としてクローズされました。 添付ファイル 多くの場合、すべてのレコード添付ファイル、または大容量の添付ファイルのみがクローンで Exclude されます。これらの添付ファイルがすべてデータであるとは限らず、標準提供コードの一部である場合もあります。これらはクローンでコピーする必要がありますが、多くの場合はコピーされず、その症状は明らかではないかもしれません。 Uploaded File [sa_uploaded_file]EC2 や Oracle Patterns など、一部の Discovery Patterns は添付ファイルに含まれるスクリプトを実行します。参照: PRB1507034 Clone excludes attachments related to sa_uploaded_file table when "Exclude Attachments" is true, breaking Oracle/EC2 Discovery2021-07-13 以降の新しいクローンでは修正されました。Agent Client Collector プラグイン [sn_agent_asset]Agent Client Collector (ACC) Plugins（Sensu Assets）は、インスタンスから MID Server に同期され、さらに MID Server からそれらを必要とするすべての ACC に同期されます。その後、キャッシュフォルダーに展開されて実行されます。添付ファイルがない場合、それらのアセットを使用したチェックは失敗します。ecc_queue の inputには次のようなエラーがあります。'endpoint_discovery.rb' is not recognized as an internal or external command参照: PRB1550798 Clones that exclude large attachments break Agent Client Collector, by deleting the tar/gz files attached to ACC Plugin records in sn_agent_asset インスタンスのバージョンを変更するクローン ダウングレードを試行する MID Server クローン後、既存のサブプロダクション MID Server は、それまで接続していたインスタンスとは内容が異なるインスタンスと通信することになります。MID Server は引き続き接続を試行し、インスタンスの現在のバージョンに合わせてアップグレードまたはダウングレードを試行します。 アップグレードはうまくいくはずであり、それが機能することを確認するために、リリースごとに多くの回帰テストが行われます。 ただし、インスタンスが以前のバージョンになり (たとえば、サブプロダクションインスタンスをアップグレードテストに使用し、再度クローンを作成するなど)、MID Server に問題が発生する可能性があります。インスタンスと比較して新しいバージョンを実行している MID Server は、新しいインスタンスバージョンにのみ存在する API および暗号化/検証機能を使用してインスタンスと適切に通信できなくなります。 Signed ZIP ファイルを使用するバージョンから、Signed ZIP ファイルを使用しないバージョンにダウングレードする場合、ダウングレードを機能させるには、MID Server を再起動する必要があります。instanceinfo がキャッシュされるため、MID Server は署名済み ZIP ファイルバージョンから未署名バージョンへのアップグレードに失敗します。例:MP10 HF1bからNP8、またはNP9からOP2 Quebec では、新しい MID Server Unified Keystore が使用されます。これは Quebec へのアップグレードの一部として置き換えられますが、ダウングレード時に古い方法には戻されません。 ダウングレードの状況、特にメジャーバージョン間では、MID Server を手動で再インストールする準備が必要になります。この修復プロセスの詳細については、以下を参照してください。KB0713557 How to manually Upgrade and/or Restore a MID server after a failed Upgrade agent log または Issue レコードに unable to decrypt というメッセージが表示された場合は、rekey だけで解決できる可能性があります。これは、Rome から Quebec へのダウングレード後に機能するようです。 ファイルの保持によるコードの不一致 以前のバージョンのインスタンス、または同じプラグインがすべてインストールされていないインスタンスが、新しいバージョンのソースインスタンスからクローンで上書きされた場合は、すべての「コード」ファイルをそのクローンでコピーする必要があります。 Scripted SOAP Service [sys_web_service] などのテーブルがクローンで Preserve／Exclude されている場合、以前のターゲットインスタンスのバージョンに存在していたレコードだけが残ります。コードのバージョンがインスタンスのバージョンと一致しない場合や、プラグインが一度もインストールされていないためにレコードが欠落している場合は、機能が正常に動作しなくなる可能性が高くなります。 標準提供スクリプトとカスタムスクリプトの両方を含むコードテーブルは Preserve／Exclude しないでください。Update Sets をエクスポートし、クローン後に再度インポートすることをお勧めします。これを行う必要があると感じた場合は、クローン作成前にターゲットインスタンスをソースインスタンスと同じバージョンにアップグレードし、最初に同じプラグインとアプリがすべてインストールされていることを確認すると、通常は問題を回避できます。 たとえば、Scripted SOAP Service「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 Connector 各 Agent Client Collector のインストールは、特定の MID Server 上で実行される MID Web Server Extension と通信するため、特定のインスタンス名に関連付けられています。クローン後も、ACC Websocket Endpoint および MID Web Server Contexts が、同じポートおよび資格情報の設定で存在している必要があります。そうしないと、Agent Client Collector は MID Server およびインスタンスと通信できなくなります。 バージョン 2.1.41（cGTM/202009）では、これらの Exclude／Preserve 設定が含まれていました（PRB1408738）。 また、 Agent Client Collector プラグイン [sn_agent_asset] 添付ファイルの問題については、上記の「添付ファイル」セクションも参照してください。 Discovery および Service Mapping パターン Uploaded File の添付ファイルが見つからない Oracle や Amazon EC2 などの Discovery Patterns は、Uploaded File [sa_uploaded_file] テーブル内の一部の同期ファイルに依存します。 一部の添付ファイル（sys_attachment／sys_attachment_doc）が Exclude され、Preserve されない場合、一部の Discovery Patterns が機能しなくなります。この問題は、sa_uploaded_file レコードをクローン元から XML としてエクスポートし、その XML をクローン先にインポートすることで解決できます。エクスポートには添付ファイルも自動的に含まれるため、欠落した添付ファイルを復元できます。 検索しやすいように、添付ファイルの名前とsa_uploaded_file の sys_idは次のとおりです。 getEC2Detailsv3.ps1 fef7f75e1bfcd0107e02fc078b4bcb16Oracle_PDBS.sql ee37ed860f02001003bea6f6bc767e66Oracle_CDB.sql 95c66d860f02001003bea6f6bc767e4aoptions_packs_usage_statistics.sql 06f603f2db0500104d2f9eb5db9619e7Oracle_instance_size.sql bc515611dbdff34003a05561ca961992 ファイル同期の詳細: KB0852276 : How MID Server File Synchronisation works, to help when Troubleshooting パターンが完全に欠落している場合 Discovery ログに次の警告が表示された場合は、クローンが原因である可能性があります。 Script error in sensor: ReferenceError: "pattern" is not defined. 上記の「MID Server 独自のレコード」セクションでは、ecc_agent_jar／ecc_agent_mib／ecc_agent_script_file テーブルはデータではなくコードであるため、決して Exclude／Preserve してはならないと説明しました。これらのテーブルに関するもう 1 つの重要な点は、すべてが ecc_agent_sync_file を拡張しており、Patterns テーブルである sa_pattern も同様であることです。 ecc_agent_sync_file とその子テーブルは、sys_metadata を基底とする Table-Per-Class 拡張テーブル構造の一部です。これは大規模なツリー構造のテーブルであり、インスタンス内のほとんどのコードテーブルを網羅しています。これらすべてのレコードには、レコードがどのアプリケーションレベルのテーブルにあるかを定義するクラスフィールドがあり、SQL レベルでは、そのレコードの sys_id は sys_metadata に存在し、さらにすべての中間テーブルと子テーブルがあり、各レベルでフィールドが追加され、結合されると、フォームに表示されるアプリケーションレベルのレコードが構成されます。 Clone Engine による Table-Per-Class 拡張テーブルの処理方法により、すべての子テーブルも Exclude／Preserve の対象にしない場合、一部の SQL テーブルに sys_id が存在しない、部分的に破損したゴーストレコードまたは孤立レコードが残る可能性があります。 たとえば、お客様が ecc_agent_script_file と ecc_agent_sync_file を Exclude および Preserve の対象にすると、ecc_agent_script_file レコードは正しく Exclude および Preserve されます。ただし、子テーブル内の他のクラスのファイルは部分的にしか Exclude／Preserve されません。 緑色は、意図的に Exclude／Preserve するためにクローン設定へ追加したものです。黄色は、Exclude／Preserve のクローン設定に ecc_agent_sync_file を含めたため、意図せず Exclude／Preserve されたものです。赤色は、欠落することになるものです。 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 Patterns のリスト（/sa_pattern_list.do）を表示しても、レコードは表示されません。最上位の /sys_metadata_list.do を開き、Class is Discovery Patterns をフィルター条件として追加すると、レコードは表示されますが、開こうとすると /sa_pattern.do フォームに Record Not Found と表示されます。 アプリケーションレベルで動作するプラグイン修復コードは、SQL レベルで破損しているレコードを更新できないため、プラグイン/アプリを修復してレコードを取り戻そうとしても機能しません。 解決策： この状況では、ソースインスタンスの Clone Excludes および Preservers から ecc_agent_sync_file とその拡張テーブルを削除してクローン設定を修正し、再度クローンを実行する必要があります。 ゴーストレコードを削除し、その後、Pattern レコードを含む各種 Plugins／Apps を修復できる可能性はありますが、この方法は複雑で時間がかかります。また、SQL レベルで変更を行うには Support Case が必要です。 Health Log Analytics (ヘルスログアナリティクス) MID Server を介して Occultus インスタンスにログをストリーミングする MID Server Extensions は、インスタンスクローンの影響を受けます。これに関する主な情報源は次の KB です。KB0867530 System Clone - Health Log Analytics | HLA Quebec フルクローン Clone Excludes および Preservers の設定は、クローンのリクエスト時に Exclude tables specified in Exclusion List および Exclude audit and log data オプションがオフになっている場合は無視されます。この処理を Full Clone と呼びます。Full Clone の後は、MID Server に関連するすべての項目を再設定する必要があります。 Full Clone の観点では、この動作は Working as Expected ですが、MID Server は引き続き正常に動作しないため、この動作に関する Problem レコードが存在します。これによって引き起こされたサポートケースは、現在動作の変更が計画されていない場合でも、引き続きリンクする必要があります。PRB1251951 / KB0677995 Clone fails to exclude tables like ecc_agent when unchecking the boxes "Exclude audit and log data" and "Exclude large attachment data"