El incremento de identidad está saltando en la base de datos de SQL Server

Este comportamiento se debe a una mejora del rendimiento desde SQL Server 2012.

Ahora, de forma predeterminada, utiliza un tamaño de caché de 1000 al asignar IDENTITYvalores para una intcolumna 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 una falla de la base de datos o un reinicio del servidor. Esto puede dar lugar a lagunas en el valor de identidad al insertarlo. Si las lagunas no son aceptables, entonces la aplicación debería utilizar su propio mecanismo para generar valores clave. El uso de un generador de secuencia con la NOCACHEopción puede limitar las brechas a las transacciones que nunca se confirman.

Además, esta brecha aparentemente puede ocurrir después de algunos tipos de transacciones revertidas. Violín .

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 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 - 1208305visible en las entradas del día 28.

A menos que reinicie el servicio con una frecuencia inusual, es poco probable que los valores "perdidos" afecten significativamente el rango de valores permitidos 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...

1. Puede usar una SEQUENCEcolumna de identidad en lugar de una y definir un tamaño de caché más pequeño, por ejemplo, y usarlo NEXT VALUE FORen una columna predeterminada.
2. O aplique el indicador de seguimiento 272, que hace que la IDENTITYasignación se registre como en las versiones hasta 2008 R2. Esto se aplica globalmente a todas las bases de datos.
3. O, para versiones recientes, ejecútelo ALTER DATABASE SCOPED CONFIGURATION SET IDENTITY_CACHE = OFFpara 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 lagunas. Esto nunca ha sido garantizado, IDENTITYya que solo sería posible serializando las inserciones en la tabla (sin dicha serialización, los valores de identidad se pueden asignar a una declaración de inserción que termina fallando, por ejemplo, debido a una violación de restricciones. O a una transacción que simplemente se revierte). Si necesita una columna realmente sin espacios, deberá utilizar una solución diferente a IDENTITYo SEQUENCE( ejemplo )

Jan 03 '2013 19:01 Martin Smith