Está encontrando este comportamiento debido a una mejora en el rendimiento desde SQL Server 2012.
Ahora, de forma predeterminada, utiliza un tamaño de caché de 1000 al asignar IDENTITY
valores para un int
y reiniciar el servicio puede "perder" valores no utilizados (el tamaño de caché es 10,000 para bigint
/numeric
).
Esto se menciona en la documentación
SQL Server puede almacenar en caché los valores de identidad por motivos de rendimiento y algunos de los valores asignados pueden perderse durante un error de la base de datos o un reinicio del servidor. Esto puede dar como resultado lagunas en el valor de identidad al momento de la inserción. Si las brechas no son aceptables, la aplicación debe usar su propio mecanismo para generar valores clave. Usando un generador de secuencias con el NOCACHE
La opción puede limitar las brechas a las transacciones que nunca se comprometen.
Según los datos que ha mostrado, parece que esto sucedió después de la entrada de datos del 22 de diciembre y luego, cuando se reinició, SQL Server reservó los valores 1206306 - 1207305
. Después de la entrada de datos del 24 al 25 de diciembre, se realizó otro reinicio y SQL Server reservó el siguiente rango 1207306 - 1208305
visible en las entradas del día 28.
A menos que esté reiniciando el servicio con una frecuencia inusual, es poco probable que los valores "perdidos" hagan mella significativa en el rango de valores permitido por el tipo de datos, por lo que la mejor política es no preocuparse por eso.
Si por alguna razón esto es un problema real para usted, algunas posibles soluciones son...
- Puedes usar una
SEQUENCE
en lugar de una columna de identidad y defina un tamaño de caché más pequeño, por ejemplo, y useNEXT VALUE FOR
en una columna predeterminada. - O aplique la marca de rastreo 272 que hace que la
IDENTITY
Asignación registrada como en versiones hasta 2008 R2. Esto se aplica globalmente a todas las bases de datos. - O, para versiones recientes, ejecute
ALTER DATABASE SCOPED CONFIGURATION SET IDENTITY_CACHE = OFF
para deshabilitar el almacenamiento en caché de identidad para una base de datos específica.
Debe tener en cuenta que ninguna de estas soluciones garantiza que no haya brechas. Esto nunca ha sido garantizado por IDENTITY
ya que solo sería posible mediante la serialización de inserciones en la tabla. Si necesita una columna sin espacios, deberá usar una solución diferente a IDENTITY
o SEQUENCE