MID Server とクローンDetails この KB 記事では、インスタンスクローンによる MID Server の影響に関する一般的な情報と、留意する必要がある事項について説明します。 目次 MID Server はクローンされますか?MID Serverのログイン資格情報 問題レコード:MID Serverに関連付けられていないmid_serverロールのユーザー x。レポート期間内にログイン試行はありません。 MID Serverの相互認証証明書インスタンス認証情報テーブル クラウドサービスアカウントレコード MID Server 独自のレコード拡張コンテキスト暗号化キーMID Server を参照するレコードと設定 デフォルトのオーケストレーション MID サーバー 添付ファイルインスタンスのバージョンを変更するクローン ダウングレードを試行中の MID サーバーファイルの保持によるコードの不一致 エージェントクライアントコネクタ検出とサービスマッピングパターン アップロード済みファイルの添付ファイルがありませんパターンが完全に欠落している Health Log Analytics (ヘルスログアナリティクス)フルクローン 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 では同じユーザー名/パスワードが使用されます。 詳細については、次を参照してください: アクティブな クローン資格情報の問題 既知の問題: ソースインスタンスのクローン履歴ログ、および 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。不足しているロールをこのユーザーに追加します。詳細情報 Error MessageLogged in user 'XXX' is missing the following roles: mid_server. Add the missing roles to this user. More Info これを解決するには、ユーザーのuser_idが見つからない新しいユーザーを作成し、MDI サーバーのインストール時に使用したものと同じパスワードを設定します。mid_serverロールも忘れずに追加してください。 問題レコード:MID Serverに関連付けられていないmid_serverロールのユーザー x。レポート期間内にログイン試行はありません。 ソースインスタンスの MID Server ロールのユーザーがクローンにコピーされると、「MID Server に関連付けられていないmid_serverロールのユーザー x」の問題レコードが残る可能性があります。これらは、Event Management のセルフ健全性モニタリング機能でイベントやアラートとして表示されることもあります。 ターゲットインスタンスで使用されていないmid_serverロールを持つユーザーを削除すると、それらのアラートを回避することができます。 MID Serverの相互認証証明書 Quebec 以降のインスタンスでは、MID Server はオプションで、ユーザー名 + パスワードの代わりに 相互認証 (mTLS) を使用して インスタンスで認証できます。MID Server インストールにインポートされた証明書は、MID Server がインスタンスで認証するために、インスタンステーブル「User Client Certificates」 [sys_user_certificate] にインポートされた証明書と一致する必要があります。 クローンソースとターゲットの間で異なるユーザーと証明書が使用されている場合は、これらのレコードとその添付ファイルをクローンで保持し、除外する必要があります。 インスタンス認証情報テーブル New York リリースより前は、資格情報テーブル [discovery_credentials] はクローンのソースのレコードでクローンによって置き換えられていました。New York 以降、準本番インスタンスはクローン作成前の資格情報レコードを保持するため、このテーブルはクローンで [Excluded] と [Reserved] の両方になります。 このテーブルは、MID Server からの検出/サービス マッピング プローブによって使用されますが、MID Server を使用しない可能性のある他の最近の統合機能によっても使用されます。 デフォルト設定を使用したくない場合は、この動作を自分で設定できます。詳細については、以下を参照してください。クローン作成からテーブルを除外するクローン作成ターゲットインスタンスのデータ保持 注:これらの除外/保持者 (すぐに利用可能なものを含む) は、クローンの要求時に [除外リストで指定されたテーブルを除外] および [監査およびログデータを除外] オプションがオンになっている場合にのみ有効になります。 クローンエンジンのデータプリザーバーと除外コードに問題があり、拡張テーブルのすべての子テーブルが自動的に保持されません。これにより、New York の discovery_credentials の OOTB 除外設定とカスタム設定が壊れ、破損した資格情報レコードがターゲットに残ります。詳細と回避策については、以下を参照してください。KB0717208: 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、除外ではなくプリザーバーに関連する同じ破損を引き起こします。これは今すぐ修正する必要があります。 ソースとターゲットのインスタンスに異なるプラグインがインストールされている場合は、資格情報レコードが破損する可能性もあります。例： クラウド管理を準本番インスタンスにインストールすると、クラウド機能に固有の検出資格情報テーブルに拡張テーブルが追加されます。例: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が欠落し、レコードが破損したままになるため、後でプラグインをインストールしても役に立ちません。リストとフォームの下位レベルで削除されるため、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 レコードです。 不幸なことに、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 のレコードは保持する必要があります。 これには、MID Server ダッシュボードのプロパティ、パラメーター、クラスター、機能、IP 範囲、アプリケーション、問題などの関連レコードとレコードが含まれます。 警告: 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_paramsa_patternその他.. これらはほとんどがecc_agent_sync_fileを拡張するテーブルであり、MID Server に同期され、MID Server で実行されているプローブで使用できるようにするコードです。クローン後にこれらが失われると、実質的にすべての MID Server 関連の機能または統合からのさまざまなプローブが、依存関係がないために失敗します。 注:これらの除外/保持者 (すぐに利用可能なものを含む) は、クローンの要求時に [除外リストで指定されたテーブルを除外] および [監査およびログデータを除外] オプションがオンになっている場合にのみ有効になります。 拡張コンテキスト ecc_agent_ext_context は discovery_credentials と同様に TPC 拡張テーブルであり、孤立/ゴースト レコードでも同じ問題が発生します。 既知の問題 - 既知のエラー記事で、修正ターゲットと修復/ワークアラウンド情報を確認してください。 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を参照してください。 暗号化キー Key Management Framework テーブル (名前が sys_kmf_...これらはすべてインスタンス固有であるため、保持して除外する必要があります。インスタンス内のレコードの password2 フィールドなどが対象です。過去にも問題がありましたが、今ではこれらのレコードはクローンで適切に処理されるはずです。 ただし、インスタンスと MID Server 間で送信されるデータの暗号化に固有の別のテーブルがあり、ecc_encryption_key内のレコードが使用されます。そのテーブルは Paris で追加されたもので、Quebec 以降は、すぐに利用可能なクローンプリザーバーと除外が含まれているはずです。これらが欠落している場合、MID Server データの暗号化は解除されます。 Vancouver 以降、そのキーは 3DES ではなく AES を使用して暗号化され、Washington DC 以降は、初期設定の DES3 レコードはアップグレード (PRB1678069) で削除されます。この変更の詳細については、以下を参照してください。KB0862631 MID Server and Credentials Encryption/Decryption - Symmetrical Keys AES256 and 3DES questions JDBCProbe ペイロードのパスワードなど、暗号化された値を持つecc_queueレコードを作成するコードを実行すると、レコードが欠落していたり、キーが空のレコードがあったりすると、インスタンス側エラーが発生する可能性があります。例えば。 AbstractProgressWorker SEVERE *** ERROR *** com.glide.db.impex.JDBCProbeLoaderjava.lang.RuntimeException:com.snc.automation_common.integration.exceptions.EncryptionException:暗号化キーを指定する必要があります 通常、(バックアップ後に)削除してから新しいレコードを挿入すると、この問題を解決できます。 MID Server を参照するレコードと設定 MID Server を使用するすべての機能の設定に、特定の MID Server Sys ID への参照が存在する可能性があります。例えば。 特定の MID サーバーまたは MID サーバークラスターを使用するように設定されたディスカバリースケジュール特定の MID Server を使用するように設定されたデータソースのインポート特定の MID Server に制限された認証情報レコードなど これらの設定の多くはクローンとともにコピーされますが、MID Server はターゲットインスタンスに存在しません。そのため、これらの機能の多くは機能しないか、予期しないことになり、ターゲットインスタンスの MID Server を使用するように再構成する必要があります。 クローン後のクリーンアップスクリプト を使用して、クローン後にこれらの設定の多くを修正または防止できます。例:KB0789119 A Post-Clone script to Deactivate and Cancel Discovery Schedules 本番 MID Server と同じsys_idになるように MID Server を構成することができます。インストールが同じホストサーバー上にある場合、名前は異なる必要がありますが、sys_idsは同じにすることができます。このプロセスと長所と短所については、以下で詳しく説明しています。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 に設定されたディスカバリースケジュールがクローンの後に予期せず実行される場合があります。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 デフォルトのオーケストレーション MID サーバー オーケストレーションに使用するデフォルトの MID Server を設定する場所が 2 か所あり、これらのテーブルには値を同期させる 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 サーバーにアサインしている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年に「Working as Expected」として閉鎖。2023:PRB1673771 mid.server.rba_default システムプロパティとオーケストレーションecc_agent_applicationレコードのクローンプリザーバーがありません (IntegrationHub にも適用されます)2023年に「This is the intended.動作なので欠陥として修正されません」 添付ファイル 多くの場合、すべてのレコード添付ファイル、または大きな添付ファイルのみがクローンから除外されます。これらはすべてデータではなく、すぐに使用できるコードの一部にすることもできます。これらはクローンでコピーする必要がありますが、多くの場合はコピーされず、その症状は明らかではないかもしれません。 アップロードされたファイル [sa_uploaded_file]検出パターンの中には、EC2 や Oracle パターンなどの添付ファイルからのスクリプトを実行するものがあります。参照: 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) プラグイン (Sensu 資産) は、インスタンスから MID Server、次に MID Server からそれらを必要とするすべての ACC に同期され、キャッシュフォルダーに抽出されて実行されます。添付ファイルがない場合、それらのアセットを使用したチェックは失敗します。ecc_queue入力には次のようなエラーがあります。「endpoint_discovery.rb」は内部コマンドまたは外部コマンドとして認識されません参照: 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 サーバー クローン後、既存の準本番 MID Server は突然、そのインスタンスの以前の化身と比較して「異なる」インスタンスと通信していることに気付くでしょう。接続は引き続き試行され、インスタンスの現在のバージョンと一致するようにアップグレード/ダウングレードが試行されます。 アップグレードはうまくいくはずであり、それが機能することを確認するために、リリースごとに多くの回帰テストが行われます。 ただし、インスタンスが以前のバージョンになり (たとえば、準本番インスタンスをアップグレードテストに使用し、再度クローンを作成するなど)、MID Server に問題が発生する可能性があります。インスタンスと比較して将来のバージョンを実行している MID Server は、将来のインスタンスバージョンにのみ存在する API および暗号化/検証機能を使用してインスタンスと適切に通信できなくなります。 署名済み ZIP ファイルを使用するバージョンからそうでないバージョンにダウングレードする場合、ダウングレードを機能させるには、MID Server を再起動する必要があります。instanceinfo がキャッシュされるため、MID Server は署名済み ZIP ファイルバージョンから署名されていないバージョンへのアップグレードに失敗します。例:MP10 HF1bからNP8、またはNP9からOP2 Quebec では、新しい MID Server 統一キーストア (MID Server Unified Keystore) を使用します。これは Quebec へのアップグレードの一部として置き換えられますが、ダウングレード時に古い方法には戻されません。 ダウングレードの状況、特にメジャーバージョン間では、MID Server を手動で再インストールする準備が必要になります。この修復プロセスの詳細については、以下を参照してください。KB0713557 How to manually Upgrade and/or Restore a MID server after a failed Upgrade エージェントログまたは問題レコードに「復号化できません」というメッセージが表示された場合は、リキー(キーの再作成)だけで済む場合があります。これは、Rome から Quebec へのダウングレード後に機能するようです。 ファイルの保持によるコードの不一致 以前のバージョンのインスタンス、または同じプラグインがすべてインストールされていないインスタンスが、新しいバージョンのソースインスタンスからクローンで上書きされた場合は、すべての「コード」ファイルをそのクローンでコピーする必要があります。 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 : 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 はデータではなくコードであるため、決して除外/保持してはならないと説明しました。これらのテーブルのもう 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 から見て [Class is Discovery Patterns] のフィルターを追加すると、レコードがリストされますが、開こうとすると /sa_pattern.do フォームに「Record Not Found」と表示されます。 アプリケーションレベルで動作するプラグイン修復コードは、SQL レベルで破損しているレコードを更新できないため、プラグイン/アプリを修復してレコードを取り戻そうとしても機能しません。 ソリューション： この状況では、ソースインスタンスのクローン除外およびプリザーバーからecc_agent_sync_fileとそれを拡張するテーブルを削除してクローン設定を修正し、再度クローンを作成する必要があります。 ゴーストレコードを削除してから、パターンレコードを含むさまざまなプラグイン/アプリを修復することは可能ですが、これはトリッキーで時間がかかり、SQLレベルで変更を行うにはサポートケースが必要になります。 Health Log Analytics (ヘルスログアナリティクス) MID Server 経由で Occultus インスタンスにログをストリーミングするための MID Server 拡張はクローンの影響を受けます。これに関する主な情報源は次の KB です。KB0867530 System Clone - Health Log Analytics | HLA Quebec フルクローン クローンの要求時に [除外リストに指定されたテーブルを除外] および [監査およびログデータを除外] オプションがオフになっている場合クローンの除外および保存の設定は無視されます。これをフルクローンと呼び、クローン後にすべての MID Server 関連を再度設定する必要があります。 フルクローンの観点からはこれは「期待どおりに機能」していますが、MID Server は引き続き壊れているため、この動作に対する問題チケットは存在します。これによって引き起こされたサポートケースは、現在動作の変更が計画されていない場合でも、引き続きリンクする必要があります。PRB1251951 / KB0677995 Clone fails to exclude tables like ecc_agent when unchecking the boxes "Exclude audit and log data" and "Exclude large attachment data"