Introductie
Vanaf de releases van SQL Server 2012, wanneer de SQL Server-instantie wordt herstart, springt de waarde van de auto-groeikolom van de tabel en wordt de specifieke sprongwaarde bepaald door het datatype van de groeikolom. Als het datatype int is, is de sprongwaarde 1000, en als het datatype bigint is, is de sprongwaarde 10000. Vanuit ons project is dit soort springproblemen onacceptabel, vooral als het aan de klantzijde wordt getoond. Dit vreemde probleem komt alleen voor in SQL Server 2012 en later, en bestaat niet in versies vóór SQL Server 2012.
achtergrond
Een paar dagen geleden stelde een collega van ons QA-team voor: De waarde van de zelfverhogende kolom van onze tafel steeg op onverklaarbare wijze met 10.000. Met andere woorden, de laatste waarde van de zelfverhogende kolom in onze tabel was 2200, maar nu we een nieuw record hebben toegevoegd, is de waarde van de zelf-incrementele kolom 12200 geworden. In onze bedrijfslogica zijn situaties als deze niet toegestaan voor de klant, dus we moeten dit probleem oplossen.
Codegebruik
In het begin waren we allemaal heel vreemd, hoe is dit gebeurd? We voegen meestal geen waarden handmatig in zelfverhogende kolommen in (handmatig waarden invoegen in zelfverhogende kolommen is prima), en de waarden van zelfverhogende kolommen worden door de database zelf bijgehouden. Een lid van ons kernteam begon deze vraag te onderzoeken en vond het antwoord. Nu wil ik dit probleem in detail uitleggen en de oplossing die mijn collega heeft gevonden.
Hoe reproduceer je deze bug
Je zult SQL Server 2012 moeten installeren en vervolgens een testdatabase aanmaken. Maak vervolgens een tabel met zelfgroeiende kolommen:
Voeg nu twee gegevens in:
Bekijk de resultaten:
Op dat moment was het resultaat hetzelfde als we hadden verwacht. Start nu je SQL Server Service opnieuw op. Er zijn verschillende manieren om SQL Service opnieuw te starten, en hier gebruiken we de SQL Server Manager om het opnieuw te starten:
Na het herstarten voegen we zojuist nog 2 gegevens in de tabel in:
Bekijk de resultaten:
Nu zie je de resultaten na het herstarten van SQL Server 2012, en de zelfverhogende kolomwaarden beginnen bij 1002. Dat wil zeggen, 1000 sprongen. Zoals eerder vermeld, als het datatype dat we toevoegen bigint is, zal de sprongwaarde 10.000 zijn.
Is het echt een BUG?
Microsoft stelt dat dit een functie is, geen bug, en dat het in veel scenario's nuttig is. Maar in ons geval hebben we zo'n functie niet nodig, omdat deze zelf-incrementele data bedoeld is om aan klanten getoond te worden, en klanten zullen zich vreemd voelen als ze zulke springende data zien. En de jumpwaarde wordt bepaald door het aantal keren dat je SQL Server opnieuw opstart. Als deze gegevens niet aan klanten worden getoond, kan het acceptabel zijn. Daarom is deze functie meestal alleen geschikt voor intern gebruik.
oplossing
Als we niet geïnteresseerd zijn in deze "functie" die Microsoft aanbiedt, zijn er twee manieren om deze uit te schakelen.
1. Gebruik van Sequenties
2. Registreer de opstartparameter -t272 voor SQL Server
Gebruik sequenties
Eerst moeten we de zelfverhogende kolommen van de tabel verwijderen. Maak vervolgens een reeks zonder caching, waaruit de numerieke waarden worden ingevoegd. Hier is de voorbeeldcode:
Registreer de opstartparameter -t272
Open SQL Server Configuration Manager. Selecteer je SQL Server 2012-instantie, klik met de rechtermuisknop en selecteer het menu Eigenschappen. Zoek de lanceerparameters in het pop-up venster en registreer -t272. Na voltooiing herstart je SQL Server (SQLSERVER2012) in de onderstaande figuur opnieuw en voer je vervolgens de bugreproductie uit om te controleren of het probleem is opgelost.
Aanvullende opmerkingen:
Als je veel zelfopblazende tabellen in je database hebt en ze hebben allemaal numerieke sprongproblemen, dan is het beter om de tweede optie te gebruiken. Omdat het heel simpel is en de scope serverniveau is. Het adopteren van de tweede oplossing zal alle databases op deze service-instantie beïnvloeden.
|
Geplaatst op 23-08-2018 12:03:06
|
|
|
|
Huisbaas|
Geplaatst op 08-07-2020 15:15:52
|
