the sequential number (IDENTITY column) used to reference claims
This is a common misconception about IDENTITY
columns. They are not intended to be a sequential number column per se. Groups of 1,000 or 10,000 identity values can be generated at once and cached based on data type, server version, and server settings. This cache can be lost / skipped / discarded in various circumstances (server restart, AG or cluster failover).
For your specific situation, it sounds like 10,000 values were cached, 93 got used, and then the cache was lost, resulting in the gap of 9,907.
You can disable this caching mechanism at the database level by setting the database scoped configuration option IDENTITY_CACHE
to OFF
.
However, as already mentioned in another answer, IDENTITY
values generated by a T-SQL statement that is then rolled back are also lost. So just disabling the cache won't solve the problem of gaps completely.
If your application requires truly sequential numbers without gaps, you should consider using a SEQUENCE
and coding with that goal in mind.
By the way, a similar misconception around IDENTITY
values is that they are unique - this is not true. They can be reset and thus re-generate existing values. If that claim reference needs to be unique, ensure that there is a unique constraint / index / primary key defined on the column.