重複を防ぐために CMDB/Asset の Serial Number フィールドを Unique に設定することが推奨されない理由Summary CMDB または Asset テーブルの Serial Number フィールドを Unique に設定することは、CI と資産の重複を防ぐために良いアイデアに見えるかもしれませんが、実際にはそうではありません。これが設計上一意ではなく、そのままにする必要があるいくつかの理由を以下に記載します。 シリアル番号は一意ではありません。シリアル番号のブロックを発行する ISO のような中央組織はありません。ネットワーク MAC アドレスとパブリック IP アドレスにはそのような組織があり、一意の識別に適していますが、シリアル番号にはありません。同じシステム内の複数のコンポーネントは、同じシリアル番号を共有するか、少なくとも管理インターフェイスを介して照会されたときに同じシリアル番号を報告する可能性があります。たとえば、スタック構成のスイッチ、ストレージエンクロージャ、ブレードシャーシ、クローンされた仮想マシンなどです。ディクショナリの一意性制約の設定は、フォームまたはアプリケーションレベルではなく、SQL Database レベルで適用されます。つまり、別のレコードに既に存在するシリアル番号を設定しようとすると、データベース例外が発生し、その時点でトランザクションがクラッシュし、安全な方法でエラーを処理することはできません。システムログには次のようなエラーが出力されます。 FAILED TRYING TO EXECUTE ON CONNECTION xx: INSERT INTO cmdb (,...,`serial_number`,...) VALUES(...,'123456',...),INSERT INTO cmdb$par1 (...) VALUES(...)java.sql.BatchUpdateException: Duplicate entry '123456' for key 'serial_number' Unique を最初に設定する時点で重複する値が既に存在している場合、データ損失が発生します。[一意] チェックボックスが設定された時点で、SQL データベースはフィールドの一意のインデックスを構築します。SQL データは列/インデックス設定と一致するように、新しい制約に適合しないレコードはすべて削除されます。一意のフィールドが CMDB の 1 つのパーティションでのみ定義されている場合、レコードの一部のみが削除され、他のテーブルパーティションに孤立した sys_id が残り、CMDB 全体が破損します。メイン CI の [Serial Number] フィールドは、識別のためのプライマリフィールドではありません。これは、デバイスが複数の IP アドレスを持つ場合と同様に、CI が複数の異なるシリアル番号を持つ可能性があるためです。cmdb_serial_number テーブルを使用して、これらすべての異なるシリアル番号をタイプ別に格納します。 多くの場合、それらは同じです。たとえば、システムのシリアル番号は BIOS のシリアル番号と同じである場合があります。2 つの CI でメインの CI シリアル番号フィールドに同じシリアル番号が正しく入力されている場合、デバイスの個別のシリアル番号テーブルレコードには一意の識別のために異なるレコードが含まれるため、通常は問題ありません。標準コードは、他の CI と同じシリアル番号を持つ CI を作成できることを前提としています。これは機能の設計であり、シリアル番号を Unique に設定すると、その機能は正常に動作しなくなります。たとえば、Discovery Sensor のコードは、レコードが正常に挿入されたと見なして実行を継続し、作成された他のレコードの参照フィールドで作成したと思われる sys_id を使用し、他の CI やサービスマップとの関係などを破壊する可能性があります。CI の挿入が中止された場合でも、リンクされた資産の挿入が行われる可能性があります。挿入時に資産を作成するビジネスルールは、CI の挿入前に実行され、CI の 参照フィールドに存在することが意図されている sys_id を使用します。CI の挿入が中止された結果、実際には存在しない CI への無効な参照を持つ Asset レコードが残ります。識別および調整のルールと API を正しく使用することで、同じ目標を達成できます。その API を介した挿入および更新中に、重複 CI が検出され、適切なアクションが自動的に実行されます。いくつかの識別フィールドに基づいて既存の CI が同じであると思われる場合は、重複排除タスクが作成され、CMDB 健全性ダッシュボードで重複 CI が報告される可能性があります。この機能の主な目的は、挿入および更新中に既存のレコードを正しく識別して重複を防止することです。 これらのポイントのほとんどは、名前、資産タグ、相関 ID など、CMDB の他のフィールドにも適用されます。 Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } 任意。 Instructions CMDB または資産テーブルのシリアル番号を一意にする必要がある会社のポリシーまたはその他の技術的な理由がある場合、より害の少ないワークアラウンドは、Abort action Business Rulesを使用して同じことを達成することです。これらは挿入または更新時に実行でき、一意性が絶対的に必要な CI クラスにのみ適用する条件を設定できます。CMDB 管理者が「不適切な」挿入/更新の原因を特定して修正し、その発生を回避できるように、カスタムビジネスルールロジックにログ記録とレポートを含めることもできます。 Unique 制約を Import Sets の回避策として使用している場合は、Transform で Identification Engine を使用する方が適切な解決策です。Documentation: Apply CI Identification and Reconciliation to Import Sets API reference: CMDBTransformUtil - Global 既に CMDB フィールドを一意に設定していて、問題が発生している場合は、ServiceNow テクニカルサポートに連絡する必要があります。admin ロールのユーザーは、一意のインデックスが作成されると削除できないためです。 Related Links CMDB 識別および調整機能のメインランディングページ：Documentation: CMDB Identification and Reconciliation KB2583244 Using the IP Address/DNS name/MAC Address/Serial Number fields on the Main CMDB CI is problematic