The SQL Product team makes a continuous change in the product which sometimes causes unpredictable behaviors in the SQL Server engine. One of such change was done in SQL Server 2012 which caused the behavior which I just said in the subject line Identity Column.
Here are steps to simulate the behavior. I did it on SQL 2012.
--Create a test database. CREATE DATABASE TestIdentityDB --Create a test table in above database with auto identity column USE TestIdentityDB GO CREATE TABLE MyTable ( id INT identity ,name VARCHAR(10) ) GO --Insert a row in the table INSERT INTO MyTable (name) VALUES ('Pinal') SELECT * FROM MyTable --Restart SQL Server service and once completed, insert another record. INSERT INTO MyTable (name) VALUES ('Dave') --Let's select data from table now. SELECT * FROM MyTable
You would expect the value to be in order, but as you can see there is a jump in the identity value.
I searched on the Web and as per Microsoft documentation, identity is not guaranteed to give sequential value. In SQL Server 2012 the implementation of the identity property has been changed to accommodate investments into other features. This is what they have mentioned in a connect item, “In previous versions of SQL Server the tracking of identity generation relied on transaction log records for each identity value generated. In SQL Server 2012 we generate identity values in batches and log only the max value of the batch. This reduces the amount and frequency of information written to the transaction log improving insert scalability.”
Above means that this is expected behavior because identity values are cached and destroyed on restart/failover.
As per Microsoft documentation we should use SEQUENCE object with NOCACHE option. You can refer below blog for more details.
Another option which we have is to use trace flag 272 by adding -T272 as SQL Server Startup Parameter in the configuration manager.
Here are the reference articles.
Reference: Pinal Dave (https://blog.sqlauthority.com)