IDENTITY列の予期しないギャップ

1から始まり1ずつ増加する一意の注文番号を生成しようとしています。このスクリプトを使用してPONumberテーブルを作成しています。

CREATE TABLE [dbo].[PONumbers]
(
  [PONumberPK] [int] IDENTITY(1,1) NOT NULL,
  [NewPONo] [bit] NOT NULL,
  [DateInserted] [datetime] NOT NULL DEFAULT GETDATE(),
  CONSTRAINT [PONumbersPK] PRIMARY KEY CLUSTERED ([PONumberPK] ASC)    
);

このスクリプトを使用して作成されたストアドプロシージャ：

CREATE PROCEDURE [dbo].[GetPONumber] 
AS
BEGIN
    SET NOCOUNT ON;

    INSERT INTO [dbo].[PONumbers]([NewPONo]) VALUES(1);
    SELECT SCOPE_IDENTITY() AS PONumber;
END

作成時に、これは正常に機能します。ストアドプロシージャが実行されると、目的の数から始まり、1ずつ増加します。

奇妙なことは、コンピューターをシャットダウンまたは休止状態にした場合、次にプロシージャを実行すると、シーケンスがほぼ1000ずつ進んだことです。

以下の結果を参照してください。

数字が8から1002にジャンプしたことがわかります。

• なんでこんなことが起こっているの？
• そのように番号がスキップされないようにするにはどうすればよいですか？
• 必要なのは、SQLが次の数値を生成することだけです。
  • a）一意の保証。
  • b）必要な量だけ増加します。

私はSQLの専門家ではありません。SCOPE_IDENTITY（）の機能を誤解していますか？別のアプローチを使用する必要がありますか？SQL 2012+でシーケンスを調べましたが、Microsoftはデフォルトでシーケンスが一意であるとは限らないと言っています。

これは既知の予想される問題です-SQL ServerによるIDENTITY列の管理方法は、SQL Server 2012で変更されました（背景）。デフォルトでは1000個の値をキャッシュします。SQLServerの再起動、サーバーの再起動、フェイルオーバーなどを行う場合、それらの1000個の値を破棄する必要があります。発行済み。これはここに文書化されています。すべてのIDENTITY割り当てがログに記録されるようにこの動作を変更するトレースフラグがあり、それらの特定のギャップを防止します（ただし、ロールバックまたは削除によるギャップは防止しません）。ただし、これはパフォーマンスの点で非常にコストがかかる可能性があることに注意することが重要です。したがって、ここでは特定のトレースフラグについても言及しません。

* （個人的には、これは別の方法で解決できる技術的な問題だと思いますが、エンジンを記述していないので、それを変更することはできません。）

IDENTITYとSEQUENCEの仕組みを明確にするには：

• どちらも一意であることが保証されていません（主キーまたは一意制約を使用して、テーブルレベルで強制する必要があります）
• どちらもギャップがないことが保証されていません（たとえば、ロールバックまたは削除はギャップを生成しますが、この特定の問題にもかかわらず）

一意性を強制するのは簡単です。ギャップを避けることはできません。これらのギャップを避けることの重要性を判断する必要があります（理論的には、IDENTITY / SEQUENCEの値は無意味な代理キーであるため、ギャップをまったく気にする必要はありません）。非常に重要な場合は、どちらの実装も使用せずに、独自のシリアル化可能なシーケンスジェネレーターをロールする必要があります（こちら、こちら、こちら、こちらのアイデアをご覧ください）。

この「問題」に関する多くの背景：

• 7番目のエントリでSQL Server 2012の列IDの増分が6から1000以上にジャンプする
• SQL ServerデータベースでIDの増分がジャンプしています
• SQL ServerでID列の値が突然1001にジャンプする

これはSQL Serverの問題です。できることは、列を再シードすることだけです。

間違った列IDを持つエントリを削除します。列IDを再シードします。そして、次のエントリには適切なIDがあります。

次のsqlコマンドを使用した再シードID： DBCC CHECKIDENT ('YOUR_TABLE_NAME', RESEED, 9)-9は最後の正しいIDです