Divari imprevisti nella colonna IDENTITÀ

Sto provando a generare numeri di ordine di acquisto univoci che iniziano da 1 e aumentano di 1. Ho una tabella PONumber creata usando questo script:

CREATE TABLE [dbo].[PONumbers]
(
  [PONumberPK] [int] IDENTITY(1,1) NOT NULL,
  [NewPONo] [bit] NOT NULL,
  [DateInserted] [datetime] NOT NULL DEFAULT GETDATE(),
  CONSTRAINT [PONumbersPK] PRIMARY KEY CLUSTERED ([PONumberPK] ASC)    
);

E una procedura memorizzata creata usando questo script:

CREATE PROCEDURE [dbo].[GetPONumber] 
AS
BEGIN
    SET NOCOUNT ON;

    INSERT INTO [dbo].[PONumbers]([NewPONo]) VALUES(1);
    SELECT SCOPE_IDENTITY() AS PONumber;
END

Al momento della creazione, funziona perfettamente. Quando viene eseguita la procedura memorizzata, inizia con il numero desiderato e aumenta di 1.

La cosa strana è che, se spengo o iberno il mio computer, la prossima volta che la procedura viene eseguita, la sequenza è avanzata di quasi 1000.

Vedi i risultati qui sotto:

Puoi vedere che il numero è passato da 8 a 1002!

• Perché sta succedendo?
• Come posso garantire che i numeri non vengano saltati in quel modo?
• Tutto ciò di cui ho bisogno è che SQL generi numeri che sono:
  • a) Unico garantito.
  • b) incremento della quantità desiderata.

Ammetto di non essere un esperto di SQL. Posso fraintendere cosa fa SCOPE_IDENTITY ()? Dovrei usare un approccio diverso? Ho esaminato le sequenze in SQL 2012+, ma Microsoft afferma che non sono garantite per essere uniche per impostazione predefinita.

Questo è un problema noto e previsto: il modo in cui le colonne IDENTITY sono gestite da SQL Server è cambiato in SQL Server 2012 ( alcuni retroscena ); per impostazione predefinita memorizzerà nella cache 1000 valori e se riavvii SQL Server, riavvii il server, esegui il failover, ecc. dovrà eliminare quei 1000 valori, perché non avrà un modo affidabile per sapere quanti di essi fossero effettivamente rilasciato. Questo è documentato qui . Esiste un flag di traccia che modifica questo comportamento in modo tale che ogni assegnazione IDENTITY venga registrata *, impedendo quegli spazi specifici (ma non spazi vuoti da rollback o eliminazioni); tuttavia, è importante notare che questo può essere piuttosto costoso in termini di prestazioni, quindi non parlerò nemmeno del flag di traccia specifico qui.

* (Personalmente, penso che questo sia un problema tecnico che potrebbe essere risolto in modo diverso, ma dal momento che non scrivo il motore, non posso cambiarlo.)

Per essere chiari su come funzionano IDENTITÀ e SEQUENZA:

• Nessuno dei due è garantito per essere univoco (è necessario imporlo a livello di tabella, utilizzando una chiave primaria o un vincolo univoco)
• Nessuno dei due è garantito come gapless (qualsiasi rollback o eliminazione, ad esempio, produrrà un gap, nonostante questo specifico problema)

L'unicità è facile da applicare. Evitare le lacune non lo è. Devi determinare quanto sia importante per te evitare queste lacune (in teoria, non dovresti preoccuparti affatto delle lacune, poiché i valori IDENTITÀ / SEQUENZA dovrebbero essere chiavi surrogate insignificanti). Se è molto importante, non dovresti usare nessuna delle due implementazioni, ma piuttosto lanciare il tuo generatore di sequenze serializzabile (vedi alcune idee qui , qui e qui ) - nota solo che ucciderà la concorrenza.

Un sacco di informazioni su questo "problema":

• L'incremento dell'identità della colonna di SQL Server 2012 passa da 6 a 1000+ alla settima voce
• l'incremento dell'identità sta saltando nel database del server sql
• Il valore della colonna Identity passa improvvisamente a 1001 nel server sql

Questo è un problema di SQL Server. Tutto ciò che puoi fare è ridimensionare la colonna.

elimina le voci con ID colonna errato. Ridistribuito l'identità della colonna. E quindi la voce successiva ha l'ID corretto.

Reseed Identity usando il seguente comando sql: DBCC CHECKIDENT ('YOUR_TABLE_NAME', RESEED, 9)- 9 è l'ultimo ID corretto