Införandet
Från och med SQL Server 2012-versionerna, när SQL Server-instansen startas om, hoppar värdet på tabellens automatiska tillväxtkolumn och det specifika hoppvärdet bestäms av datatypen i tillväxtkolumnen. Om datatypen är int, är hoppvärdet 1000, och om datatypen är bigint, är hoppvärdet 10000. Från vårt projekt är den här typen av hoppproblem oacceptabelt, särskilt när det visas på kundsidan. Detta märkliga problem finns endast i SQL Server 2012 och senare, och det finns inte i versioner före SQL Server 2012.
bakgrund
För några dagar sedan föreslog en kollega från vårt QA-team: Värdet av den självförökande kolumnen i vårt bord ökade oförklarligt med 10 000. Med andra ord var det sista värdet i den självinkrementerande kolumnen i vår tabell 2200, men nu när vi har lagt till en ny post har värdet på den självinkrementerande kolumnen blivit 12200. I vår affärslogik är sådana situationer inte tillåtna på klienten, så vi måste lösa detta problem.
Kodanvändning
Till en början var vi alla väldigt konstiga, hur kunde det här hända? Vi brukar vanligtvis inte manuellt infoga några värden i självförstärkande kolumner (att manuellt infoga värden i självförstärkande kolumner är okej), och värdena på självförstärkande kolumner underhålls av databasen själv. En medlem i vårt kärnteam började undersöka denna fråga och hittade svaret. Nu vill jag förklara detta problem i detalj och lösningen min kollega hittade.
Hur man återskapar denna bugg
Du behöver installera SQL Server 2012 och sedan skapa en testdatabas. Skapa sedan en tabell med självväxande kolumner:
Nu infogar vi två data:
Gå igenom resultaten:
Vid det här laget var resultatet detsamma som vi förväntade oss. Starta nu om din SQL Server Service. Det finns flera sätt att starta om SQL Service, och här använder vi SQL Server Manager för att starta om den:
Efter omstart lägger vi just nu in två ytterligare databitar i tabellen:
Gå igenom resultaten:
Nu ser du resultaten efter att ha startat om SQL Server 2012, och dess självinkrementerande kolumnvärden börjar på 1002. Det vill säga, hoppade 1000. Som nämnts tidigare, om datatypen vi lägger till är bigint, kommer dess hoppvärde att vara 10 000.
Är det verkligen en BUGG?
Microsoft säger att detta är en funktion, inte en bugg, och är användbart i många situationer. Men i vårt fall behöver vi inte en sådan funktion, eftersom denna självinkrementella data är tänkt att visas för kunder, och kunder kommer att känna sig konstiga om de ser sådan hoppande data. Och hoppvärdet bestäms av hur många gånger du startar om SQL Server. Om denna data inte visas för kunderna kan den vara acceptabel. Därför är denna funktion vanligtvis endast lämplig för intern användning.
lösning
Om vi inte är intresserade av denna "funktion" som Microsoft erbjuder, finns det två sätt vi kan stänga av den på.
1. Användning av sekvenser
2. Registrera startparametern -t272 för SQL Server
Använd sekvenser
Först måste vi ta bort de självinkrementerande kolumnerna i tabellen. Skapa sedan en sekvens utan caching, från vilken de numeriska värdena infogas. Här är exempelkoden:
Registrera startparametern -t272
Öppna SQL Server Configuration Manager. Välj din SQL Server 2012-instans, högerklicka och välj menyn Egenskaper. Hitta startparametrarna i popupfönstret och registrera -t272. Efter slutförande, starta om SQL Server (SQLSERVER2012) i figuren nedan och utför sedan buggenåtergivningsoperationen för att verifiera att problemet har lösts.
Ytterligare anteckningar:
Om du har många självuppblåsande tabeller i din databas och de alla har numeriska hoppproblem, är det bättre att använda det andra alternativet. För det är väldigt enkelt och omfattningen är servernivå. Att anta den andra lösningen kommer att påverka alla databaser på denna tjänsteinstans.
|
Publicerad på 2018-08-23 12:03:06
|
|
|
|
Hyresvärd|
Publicerad på 2020-07-08 15:15:52
|
