Vous rencontrez ce comportement en raison d'une amélioration des performances depuis SQL Server 2012.
Il utilise désormais par défaut une taille de cache de 1 000 lors de l'allocation de IDENTITY
valeurs pour un int
colonne et le redémarrage du service peut "perdre" les valeurs inutilisées (la taille du cache est de 10 000 pour bigint
/numeric
).
Ceci est mentionné dans la documentation
SQL Server peut mettre en cache les valeurs d'identité pour des raisons de performances et certaines des valeurs attribuées peuvent être perdues lors d'une défaillance de la base de données ou du redémarrage du serveur. Cela peut entraîner des écarts dans la valeur d'identité lors de l'insertion. Si les écarts ne sont pas acceptables, l'application doit utiliser son propre mécanisme pour générer des valeurs clés. Utiliser un générateur de séquence avec le
NOCACHE
L'option peut limiter les écarts aux transactions qui ne sont jamais validées.
D'après les données que vous avez montrées, il semble que cela se soit produit après la saisie des données du 22 décembre, puis lors du redémarrage de SQL Server, les valeurs ont été réservées 1206306 - 1207305
. Après la saisie des données du 24 au 25 décembre, un autre redémarrage a été effectué et SQL Server a réservé la plage suivante 1207306 - 1208305
visible dans les entrées du 28.
À moins que vous ne redémarriez le service avec une fréquence inhabituelle, il est peu probable que les valeurs "perdues" fassent une entaille significative dans la plage de valeurs autorisées par le type de données, donc la meilleure politique est de ne pas s'en soucier.
S'il s'agit pour une raison quelconque d'un véritable problème pour vous, certaines solutions de contournement possibles sont...
- Vous pouvez utiliser une
SEQUENCE
au lieu d'une colonne d'identité et définissez une taille de cache plus petite par exemple et utilisezNEXT VALUE FOR
dans une colonne par défaut. - Ou appliquez l'indicateur de trace 272 qui rend l'
IDENTITY
allocation enregistrée comme dans les versions jusqu'à 2008 R2. Cela s'applique globalement à toutes les bases de données. - Ou, pour les versions récentes, exécutez
ALTER DATABASE SCOPED CONFIGURATION SET IDENTITY_CACHE = OFF
pour désactiver la mise en cache d'identité pour une base de données spécifique.
Vous devez savoir qu'aucune de ces solutions de contournement ne garantit l'absence de lacunes. Cela n'a jamais été garanti par IDENTITY
car cela ne serait possible qu'en sérialisant les insertions dans la table. Si vous avez besoin d'une colonne sans espace, vous devrez utiliser une solution différente de IDENTITY
ou SEQUENCE