przeskakujący autoincrement MSSQL

Witam,
zauważyłem ostatnio dziwne zachowanie w mojej bazie mssql 2012.
W polach unikalnego ID rekordu z autoincrementem 1 od pewnego momentu wartości zwiększyły się około 1000 (dla niektórych tabel o równo 1000 a dla innych o około 1000 ).
Przykładowo w jednej z tabel miałem kolejne ID rekordów 318,319,1299 albo inna tabela 15,16,1016.
W jednej z tabel taki przyrost nastąpił kilkukrotnie:
317,318,319,1299,1300[...tutaj dalej jest dobrze...]1540,1541,2509,2510[...tutaj dalej jest dobrze...]2532,3529
Nic nie zmieniałem w ustawieniach. W każdej z tabel użytkownik sam dodaje rekord poprzez interfejs z użyciem ASP.NET i LINQ. Czy ktoś wie czym to może być spowodowane? Może jakiś pomysł jak dojść do źródła występowania?

A czy przypadkiem Twoi użytkownicy nie mają możliwości kasowania rekordów i stąd te "dziury" w numeracji?

Użytkownik klika dodaj, jest pobierana wartość generatora a następnie użytkownik klika anuluj i licznik jest zwiększony bez dodania rekordu?

Niestety to nie ten trop.
W tabelach, w których to występuje użytkownik nie ma możliwości usuwania rekordu.

A moze próbujesz dodawać tam rekordy które są wycinane na ograniczeniach, w efekcie wiersz się nie dodaje, ale licznik się podbija?

No właśnie nie ma żadnych ograniczeń.. Po prostu tutaj jak coś się doda to tam jest i nic tego nie ruszy.

Zobaczyłem teraz, że podobny problem występuje w innej, zupełnie niezależnej bazie z innym interfejsem. Obydwie bazy i interfejsy są hostowane u tego samego zewnętrznego dostawcy. Może tam leży przyczyna. Np. został wykonany jakiś recover bazy w związku z zatrzymaniem servera..

No dobra, ale właściwie jakie to ma znaczenie? Boisz się że ci się id skończą? ;)

Pokaż skrypt DDL definiujący tę tabelę.

Ma to bardzo istotne znaczenie. Jak coś się dzieje to chcę wiedzieć dlaczego :)

Skrypt definiujący tabelę nie ma nic szczególnego:

CREATE TABLE [dbo].[TabelaA] (
    [idLogu] INT           IDENTITY (1, 1) NOT NULL,
    [opis]   VARCHAR (255) NOT NULL,
    CONSTRAINT [PK_TabelaA] PRIMARY KEY CLUSTERED ([idLogu] ASC)
);

Jak widać opis jest not null, więc masz ograniczenie, a przed chwilą twierdziłeś, że nie masz. Powód podany przez @Shalom może być zatem prawidłowy.

Nie było to spowodowane ograniczeniami.

Tutaj jest opis przyczyny:
http://connect.microsoft.com/SQLServer/feedback/details/739013/alwayson-failover-results-in-reseed-of-identity#tabs

Wygląda na to, że sql server 2012 rezerwuje przestrzeń na ID po restarcie servera.

insert w anulowanej transakcji powoduje przeskok identity.