Indførelsen
Fra og med SQL Server 2012-udgivelser, når SQL Server-instansen genstartes, hopper værdien af den automatiske vækstkolonne i tabellen, og den specifikke springværdi bestemmes af datatypen i vækstkolonnen. Hvis datatypen er int, er springværdien 1000, og hvis datatypen er bigint, er springværdien 10000. Fra vores projekt er denne slags hoppeproblem uacceptabelt, især når det vises på klientsiden. Dette mærkelige problem findes kun i SQL Server 2012 og senere, og det findes ikke i versioner før SQL Server 2012.
baggrund
For et par dage siden foreslog en kollega fra vores QA-team: Værdien af den selv-ømenende kolonne i vores bord steg uforklarligt med 10.000. Med andre ord var den sidste værdi af den selv-inkrementerende kolonne i vores tabel 2200, men nu hvor vi har tilføjet en ny post, er værdien af den selv-inkrementerede kolonne blevet 12200. I vores forretningslogik er sådanne situationer ikke tilladt på klienten, så vi er nødt til at løse dette problem.
Kodeanvendelse
I starten var vi alle meget mærkelige, hvordan kunne det ske? Vi indsætter normalt ikke manuelt værdier i selv-inkrementerende kolonner (manuelt at indsætte værdier i selv-oppustende kolonner er fint), og værdierne for selv-inkrementerende kolonner vedligeholdes af selve databasen. Et medlem af vores kerneteam begyndte at undersøge dette spørgsmål og fandt svaret. Nu vil jeg gerne forklare dette problem i detaljer og den løsning, min kollega fandt.
Sådan genskaber du denne fejl
Du skal installere SQL Server 2012 og derefter oprette en testdatabase. Opret derefter en tabel med selvvoksende kolonner:
Indsæt nu to datastykker:
Gennemgå resultaterne:
På dette tidspunkt var resultatet det samme, som vi havde forventet. Genstart nu din SQL Server Service. Der er flere måder at genstarte SQL Service på, og her bruger vi SQL Server Manager til at genstarte den:
Efter genstart indsætter vi lige nu 2 flere datastykker i tabellen:
Gennemgå resultaterne:
Nu ser du resultaterne efter genstart af SQL Server 2012, og dens selv-ømenende kolonneværdier starter ved 1002. Det vil sige, sprang 1000. Som nævnt tidligere, hvis den datatype, vi tilføjer, er bigint, vil dens springværdi være 10.000.
Er det virkelig en FEJL?
Microsoft oplyser, at dette er en funktion, ikke en fejl, og at det er nyttigt i mange situationer. Men i vores tilfælde behøver vi ikke sådan en funktion, fordi disse selv-inkrementelle data er beregnet til at blive vist til kunderne, og kunderne vil føle sig mærkelige, hvis de ser sådanne springende data. Og jump-værdien bestemmes af, hvor mange gange du genstarter SQL Server. Hvis disse data ikke vises til kunderne, kan de være acceptable. Derfor er denne funktion som regel kun egnet til intern brug.
opløsning
Hvis vi ikke er interesserede i denne "funktion" fra Microsoft, er der to måder, vi kan slå den fra på.
1. Brug af sekvenser
2. Registrer opstartsparameteren -t272 for SQL Server
Brug sekvenser
Først skal vi fjerne de selv-inkrementerende kolonner i tabellen. Opret derefter en sekvens uden caching, hvorfra de numeriske værdier indsættes. Her er eksempelkoden:
Registrer opstartsparameteren -t272
Åbn SQL Server Configuration Manager. Vælg din SQL Server 2012-instans, højreklik og vælg Egenskaber-menuen. Find opsendelsesparametrene i pop-up-vinduet og registrer -t272. Efter afslutningen genstart du SQL Server (SQLSERVER2012) i figuren nedenfor, og udfør derefter fejlgengivelsesoperationen for at verificere, om problemet er løst.
Yderligere bemærkninger:
Hvis du har mange selvoppustende tabeller i din database, og de alle har numeriske springproblemer, er det bedre at bruge den anden mulighed. Fordi det er meget simpelt, og omfanget er serverniveau. At anvende den anden løsning vil påvirke alle databaser på denne serviceinstans.
|
Opslået på 23/08/2018 12.03.06
|
|
|
|
Udlejer|
Opslået på 08/07/2020 15.15.52
|
