重複を防ぐために [CMDB/資産シリアル番号] フィールドを [一意] に設定することが推奨されない理由SummaryCMDB または資産テーブルの [Serial Number] フィールドを設定することは、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' 一意の設定が最初に行われている際に重複する値が既に存在すると、データを損失します。[一意] チェックボックスが設定された時点で、SQL データベースはフィールドの一意のインデックスを構築します。SQL データは列/インデックス設定と一致するように、新しい制約に適合しないレコードはすべて削除されます。一意のフィールドが CMDB の 1 つのパーティションでのみ定義されている場合、レコードの一部のみが削除され、他のテーブルパーティションに孤立した sys_id が残り、CMDB 全体が破損します。メイン CI の [Serial Number] フィールドは、識別のためのプライマリフィールドではありません。これは、デバイスが複数の IP アドレスを持つ場合と同様に、CI に複数の異なるシリアル番号を設定できるためです。cmdb_serial_number テーブルを使用して、これらすべての異なるシリアル番号をタイプ別に格納します。 多くの場合、それらは同じです。たとえば、システムのシリアル番号は BIOS のシリアル番号と同じである場合があります。2 つの CI でメインの CI シリアル番号フィールドに同じシリアル番号が正しく入力されている場合、デバイスの個別のシリアル番号テーブルレコードには一意の識別のために異なるレコードが含まれるため、通常は問題ありません。すぐに利用可能なコードは、他の CIと同じシリアル番号を持つ CI を作成できることを想定しています。これは機能の設計であり、シリアル番号を一意に設定すると、その機能が失われます。たとえば、Discovery Sensor のコードは、レコードが正常に挿入されたと見なして実行を継続し、作成された他のレコードの参照フィールドで作成したと思われる sys_id を使用し、他の CI やサービスマップとの関係などを破壊する可能性があります。CI の挿入が中止された場合でも、リンクされた資産の挿入が行われる可能性があります。挿入時に資産を作成するビジネスルールは、CI の挿入前に実行され、CI の 参照フィールドに存在することが意図されている sys_id を使用します。CI の挿入が中断されたため、存在しなかった CI への破損した参照を含む資産レコードが残ります。識別および調整のルールと API を正しく使用することで、同じ目標を達成できます。その API を介した挿入および更新中に、重複 CI が検出され、適切なアクションが自動的に実行されます。いくつかの識別フィールドに基づいて既存の CI が同じであると思われる場合は、重複排除タスクが作成され、CMDB 健全性ダッシュボードで重複 CI が報告される可能性があります。この機能の主な目的は、挿入および更新中に既存のレコードを正しく識別して重複を防止することです。 これらのポイントのほとんどは、名前、資産タグ、相関 ID など、CMDB の他のフィールドにも適用されます。Release任意。InstructionsCMDB または資産テーブルのシリアル番号を一意にする必要がある会社のポリシーまたはその他の技術的な理由がある場合、より害の少ないワークアラウンドは、アクションの中止ビジネスルールを使用して同じことを達成することです。これらは挿入または更新時に実行でき、一意性が絶対に必要な CI クラスにのみ適用される条件があります。CMDB 管理者が「不適切な」挿入/更新の原因を特定して修正し、その発生を回避できるように、カスタムビジネスルールロジックにログ記録とレポートを含めることもできます。 一意の制約が Import Sets のワークアラウンドである場合は、変換で識別エンジンを使用することをお勧めしますDocumentation: Apply CI Identification and Reconciliation to Import Sets API 参照：CMDBTransformUtil - グローバル 既に CMDB フィールドを一意に設定していて、問題が発生している場合は、ServiceNow テクニカルサポートに連絡する必要があります。admin ロールのユーザーは、一意のインデックスが作成されると削除できないためです。Related LinksCMDB 識別および調整機能のメインランディングページ：ドキュメント：CMDB 識別および調整