Introduzione
A partire dalle release di SQL Server 2012, quando l'istanza di SQL Server viene riavviata, il valore della colonna di crescita automatica della tabella salta e il valore specifico del salto è determinato dal tipo di dato della colonna di crescita. Se il tipo di dato è int, il valore di salto è 1000, e se il tipo di dato è bigint, il valore di salto è 10000. Dal nostro progetto, questo tipo di problema di salto è inaccettabile, soprattutto se mostrato dal lato del cliente. Questo strano problema è presente solo in SQL Server 2012 e successivi, e non esiste nelle versioni precedenti a SQL Server 2012.
sfondo
Qualche giorno fa, un collega del nostro team QA ha suggerito: Il valore della colonna auto-incrementante della nostra tabella è saltato inspiegabilmente di 10.000. In altre parole, l'ultimo valore della colonna auto-incrementante nella nostra tabella era 2200, ma ora che abbiamo aggiunto un nuovo record, il valore della colonna auto-incrementata è diventato 12200. Nella nostra logica di business, situazioni come questa non sono consentite al cliente, quindi dobbiamo risolvere questo problema.
Uso del codice
All'inizio eravamo tutti molto strani, come è successo? Di solito non inseriamo manualmente valori nelle colonne auto-incrementanti (inserire manualmente valori in colonne auto-gonfianti va bene), e i valori delle colonne auto-gonfianti sono mantenuti direttamente dal database. Un membro del nostro team centrale ha iniziato a ricercare questa domanda e ha trovato la risposta. Ora, vorrei spiegare questo problema in dettaglio e la soluzione che il mio collega ha trovato.
Come riprodurre questo bug
Dovrai installare SQL Server 2012 e poi creare un database di test. Poi crea una tabella con colonne che crescono da sole:
Ora inserisci due dati:
Rivedi i risultati:
A questo punto, il risultato è stato lo stesso che ci aspettavamo. Ora riavvia il tuo servizio SQL Server. Ci sono diversi modi per riavviare SQL Service, e qui usiamo SQL Server Manager per riavviarlo:
Dopo aver riavviato, inseriamo ora altri 2 dati nella tabella:
Rivedi i risultati:
Ora vedi i risultati dopo aver riavviato SQL Server 2012, e i valori delle colonne auto-incrementanti partono da 1002. Cioè, sono saltato di 1000. Come detto prima, se il tipo di dato che aggiungiamo è bigint, il suo valore di salto sarà 10.000.
È davvero un BUG?
Microsoft afferma che questa è una caratteristica, non un bug, ed è utile in molti scenari. Ma nel nostro caso, non abbiamo bisogno di una funzione del genere, perché questi dati auto-incrementali sono pensati per essere mostrati ai clienti, e i clienti si sentiranno strani se vedranno dati così saltanti. E il valore del salto è determinato dal numero di volte che riavvii SQL Server. Se questi dati non vengono mostrati ai clienti, potrebbero essere accettabili. Pertanto, questa caratteristica è solitamente adatta solo all'uso interno.
soluzione
Se non siamo interessati a questa "funzione" offerta da Microsoft, ci sono due modi per disattivarla.
1. Uso delle sequenze
2. Registrare il parametro di avvio -t272 per SQL Server
Uso delle sequenze
Per prima cosa, dobbiamo rimuovere le colonne auto-incrementanti della tabella. Poi si crea una sequenza senza caching, da cui vengono inseriti i valori numerici. Ecco il codice di esempio:
Registra il parametro di avvio -t272
Apri SQL Server Configuration Manager. Seleziona la tua istanza SQL Server 2012, clicca con il tasto destro e seleziona il menu Proprietà. Trova i parametri di lancio nella finestra pop-up e registra -t272. Dopo il completamento, riavviare SQL Server (SQLSERVER2012) nella figura sottostante, e poi eseguire l'operazione di riproduzione dei bug per verificare se il problema è stato risolto.
Note aggiuntive:
Se hai molte tabelle auto-gonfianti nel tuo database e tutte hanno problemi di salto numerico, allora è meglio usare la seconda opzione. Perché è molto semplice e l'ambito è a livello server. L'adozione della seconda soluzione influenzerà tutti i database su questa istanza di servizio.
|
Pubblicato su 23/08/2018 12:03:06
|
|
|
|
Padrone di casa|
Pubblicato su 08/07/2020 15:15:52
|
