Introducere
Începând cu versiunile SQL Server 2012, când instanța SQL Server este repornită, valoarea coloanei de creștere automată a tabelului sare, iar valoarea specifică este determinată de tipul de date al coloanei de creștere. Dacă tipul de date este int, valoarea saltului este 1000, iar dacă tipul de date este bigint, valoarea saltului este 10000. Din proiectul nostru, acest tip de problemă de salt este inacceptabilă, mai ales când este prezentată pe partea clientului. Această problemă ciudată apare doar în SQL Server 2012 și versiunile ulterioare, și nu există în versiunile anterioare SQL Server 2012.
fond
Acum câteva zile, un coleg din echipa noastră QA a sugerat: Valoarea rubricii auto-incrementante a tabelului nostru a crescut inexplicabil cu 10.000. Cu alte cuvinte, ultima valoare a coloanei auto-incrementante din tabelul nostru a fost 2200, dar acum că am adăugat un nou record, valoarea coloanei auto-incrementate a devenit 12200. În logica noastră de afaceri, astfel de situații nu sunt permise clientului, așa că trebuie să rezolvăm această problemă.
Utilizarea codului
La început am fost cu toții foarte ciudați, cum s-a întâmplat asta? De obicei nu inserăm manual valori în coloane auto-încrezătoare (inserarea manuală a valorilor în coloane auto-umflătoare este în regulă), iar valorile coloanelor auto-umflătoare sunt menținute chiar de baza de date. Un membru al echipei noastre de bază a început să cerceteze această întrebare și a găsit răspunsul. Acum, aș dori să explic această problemă în detaliu și soluția pe care a găsit-o colegul meu.
Cum să reproduci acest bug
Va trebui să instalezi SQL Server 2012 și apoi să creezi o bază de date de testare. Apoi creează un tabel cu coloane care cresc singure:
Acum introduceți două date:
Revizuiește rezultatele:
În acest moment, rezultatul a fost același cum ne așteptam. Acum repornește serviciul SQL Server. Există mai multe moduri de a reporni SQL Service, iar aici folosim SQL Server Manager pentru a-l reporni:
După repornire, introducem încă 2 date în tabel chiar acum:
Revizuiește rezultatele:
Acum vezi rezultatele după repornirea SQL Server 2012, iar valorile coloanelor sale auto-incrementante încep de la 1002. Adică, a sărit cu 1000. După cum am menționat anterior, dacă tipul de date pe care îl adăugăm este bigint, valoarea sa de salt va fi 10.000.
Este cu adevărat un BUG?
Microsoft afirmă că aceasta este o caracteristică, nu un bug, și este utilă în multe situații. Dar în cazul nostru, nu avem nevoie de o astfel de funcție, pentru că aceste date auto-incrementale sunt menite să fie arătate clienților, iar aceștia se vor simți ciudat dacă văd astfel de date în creștere rapidă. Iar valoarea saltului este determinată de numărul de ori când repornești SQL Server. Dacă aceste date nu sunt prezentate clienților, pot fi acceptabile. Prin urmare, această caracteristică este de obicei potrivită doar pentru uz intern.
soluție
Dacă nu suntem interesați de această "funcție" oferită de Microsoft, există două moduri prin care o putem dezactiva.
1. Utilizarea secvențelor
2. Înregistrarea parametrului de pornire -t272 pentru SQL Server
Folosirea secvențelor
Mai întâi, trebuie să eliminăm coloanele auto-incrementante ale tabelului. Apoi se creează o secvență fără caching, din care se inserează valorile numerice. Iată codul exemplu:
Înregistrează parametrul de pornire -t272
Deschide SQL Server Configuration Manager. Selectați instanța SQL Server 2012, faceți clic dreapta și selectați meniul Proprietăți. Găsește parametrii de lansare în fereastra pop-up și înregistrează -t272. După finalizare, reporniți SQL Server (SQLSERVER2012) în figura de mai jos, apoi efectuați operația de reproducere a erorilor pentru a verifica dacă problema a fost rezolvată.
Note suplimentare:
Dacă ai multe tabele auto-umflate în baza ta de date și toate au probleme de salt numeric, atunci e mai bine să folosești a doua opțiune. Pentru că este foarte simplu și scopul este la nivel de server. Adoptarea celei de-a doua soluții va afecta toate bazele de date din această instanță de serviciu.
|
Postat pe 23.08.2018 12:03:06
|
|
|
|
Proprietarul|
Postat pe 08.07.2020 15:15:52
|
