Kan iemand uitleggen wat de implicaties zijn van het gebruik van with (nolock)voor zoekopdrachten, wanneer je het wel/niet moet gebruiken?
Als u bijvoorbeeld een banktoepassing heeft met hoge transactietarieven en veel gegevens in bepaalde tabellen, voor welke soorten zoekopdrachten zou nolock dan geschikt zijn? Zijn er gevallen waarin u het altijd/nooit moet gebruiken?
Antwoord 1, autoriteit 100%
MET (NOLOCK) is het equivalent van het gebruik van READ UNCOMMITED als een transactie-isolatieniveau. U loopt dus het risico een niet-vastgelegde rij te lezen die vervolgens wordt teruggedraaid, d.w.z. gegevens die nooit in de database zijn terechtgekomen. Dus hoewel het kan voorkomen dat het lezen vastloopt door andere bewerkingen, brengt het een risico met zich mee. In een bankapplicatie met hoge transactietarieven zal het waarschijnlijk niet de juiste oplossing zijn voor het probleem dat je ermee probeert op te lossen IMHO.
Antwoord 2, autoriteit 36%
De vraag is wat erger is:
- een impasse, of
- een verkeerde waarde?
Voor financiële databases zijn deadlocks veel erger dan verkeerde waarden. Ik weet dat dat achterstevoren klinkt, maar luister naar me. Het traditionele voorbeeld van DB-transacties is dat u twee rijen bijwerkt, van de ene aftrekt en bij de andere optelt. Dat is fout.
In een financiële database maak je gebruik van zakelijke transacties. Dat betekent dat er één rij aan elk account moet worden toegevoegd. Het is van het grootste belang dat deze transacties worden voltooid en dat de rijen met succes worden geschreven.
Het is niet erg om het rekeningsaldo tijdelijk verkeerd te krijgen, daar is de eindafrekening voor. En een rood staan van een rekening is veel waarschijnlijker omdat er twee geldautomaten tegelijk worden gebruikt dan vanwege een niet-vastgelegde uitlezing uit een database.
Dat gezegd hebbende, SQL Server 2005 heeft de meeste insecten vastgesteld die nolocknoodzakelijk zijn gemaakt. Dus tenzij u SQL Server 2000 of eerder gebruikt, moet u het niet nodig hebben.
Verder lezen
rij-level versioning
Antwoord 3, Autoriteit 12%
Helaas gaat het niet alleen over het lezen van niet-gecommitteerde gegevens. Op de achtergrond kunt u inderdaad om pagina’s twee keer te lezen (in het geval van een pagina SPLIT), of misschien mis je de pagina’s helemaal. Dus uw resultaten kunnen schromelijk scheef zijn.
Uitchecken Itzik Ben-Gan’s artikel . Hier is een fragment:
“met de nolock-hint (of het instellen van de
Isolatie-niveau van de sessie om te lezen
Ongecommitteerd) Vertel je SQL-server dat
Je verwacht geen consistentie, dus daar
zijn geen garanties. Houd echter in gedachten
dat “inconsistente gegevens” niet alleen
bedoel dat je niet bent gecontroleerd
veranderingen die later werden gerold,
of gegevensveranderingen in een tussenproduct
Staat van de transactie. het ook
betekent dat in een eenvoudige vraag die
scant alle tabel / indexgegevens SQL Server
kan de scanpositie of u verliezen
kan uiteindelijk dezelfde rij krijgen
twee keer . “
Antwoord 4, Autoriteit 11%
Het voorbeeld van het tekstboek voor het legitieme gebruik van de Nolock-hint is een rapportbemonstering tegen een hoge update OLTP-database.
Om een actueel voorbeeld te nemen. Als een grote Amerikaanse high street bank elk uur een rapport wilde opstellen op zoek naar de eerste tekenen van een run op stadsniveau op de bank, zou een nolock-query transactietabellen kunnen scannen waarin contante stortingen en geldopnames per stad worden opgeteld. Voor een dergelijk rapport zou het kleine foutpercentage veroorzaakt door teruggedraaide updatetransacties de waarde van het rapport niet verminderen.
Antwoord 5, autoriteit 7%
Ik weet niet zeker waarom u financiële transacties niet in databasetransacties verpakt (zoals wanneer u geld van de ene rekening naar de andere overboekt – u legt niet één kant van de transactie tegelijk vast – daarom bestaan er expliciete transacties) . Zelfs als uw code hersendood is voor zakelijke transacties, zoals het klinkt, hebben alle transactiedatabases het potentieel om impliciete rollbacks uit te voeren in het geval van fouten of storingen. Ik denk dat deze discussie je ver te boven gaat.
Als je vergrendelingsproblemen hebt, implementeer dan versiebeheer en ruim je code op.
Geen slot retourneert niet alleen verkeerde waarden, het retourneert ook spookrecords en duplicaten.
Het is een algemene misvatting dat query’s er altijd sneller door worden uitgevoerd. Als er geen schrijfvergrendelingen op een tafel staan, maakt het geen verschil. Als er sloten op de tafel liggen, kan het de zoekopdracht sneller maken, maar er is een reden waarom sloten in de eerste plaats zijn uitgevonden.
Eerlijk gezegd zijn hier twee speciale scenario’s waarin een nolock-hint nuttig kan zijn
1) SQL-serverdatabase van vóór 2005 die lange query’s moet uitvoeren tegen live OLTP-database, dit is misschien de enige manier
2) Slecht geschreven applicatie die records vergrendelt en controle teruggeeft aan de gebruikersinterface en lezers worden voor onbepaalde tijd geblokkeerd. Nolock kan hier nuttig zijn als de applicatie niet kan worden gerepareerd (derde partij enz.) en de database van vóór 2005 is of versiebeheer niet kan worden ingeschakeld.
Antwoord 6, autoriteit 5%
nolockis gelijk aan READ UNCOMMITTED, maar Microsoft zegt dat je het niet moet gebruiken voor UPDATEof DELETEuitspraken:
Voor UPDATE- of DELETE-instructies: deze functie wordt verwijderd in een toekomstige versie van Microsoft SQL Server. Vermijd het gebruik van deze functie in nieuw ontwikkelingswerk en plan om applicaties aan te passen die deze functie momenteel gebruiken.
http://msdn.microsoft.com/en-us/library/ ms187373.aspx
Dit artikel is van toepassing op SQL Server 2005, dus de ondersteuning voor nolockbestaat als je die versie gebruikt. Om je code toekomstbestendig te maken (ervan uitgaande dat je hebt besloten om dirty reads te gebruiken), kun je dit gebruiken in je opgeslagen procedures:
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
Antwoord 7, autoriteit 4%
U kunt het gebruiken wanneer u alleen gegevens leest en het u niet echt uitmaakt of u gegevens terugkrijgt die nog niet zijn vastgelegd.
Het kan sneller zijn bij een leesbewerking, maar ik kan niet echt zeggen met hoeveel.
Over het algemeen raad ik het gebruik ervan af – het lezen van niet-vastgelegde gegevens kan op zijn best een beetje verwarrend zijn.
Antwoord 8, autoriteit 4%
Een ander geval waarin het meestal goed gaat, is in een rapportagedatabase, waar gegevens misschien al verouderd zijn en schrijven gewoon niet gebeurt. In dit geval moet de optie echter door de beheerder op database- of tabelniveau worden ingesteld door het standaardisolatieniveau te wijzigen.
In de algemene zaak: u kunt het gebruiken wanneer u zeer zeker bent dat het goed is om oude gegevens te lezen. Het belangrijkste om te onthouden is dat het zijn heel gemakkelijk om die verkeerde te krijgen. Zelfs als het in orde is op het moment dat u de query schrijft, weet u zeker dat iets in de toekomst niet in de database zal veranderen om deze updates belangrijker te maken?
Ik zal ook het idee dat het waarschijnlijk is, niet een goed idee in de bank-app. Of inventaris-app. Of overal denk je aan transacties.
Antwoord 9, Autoriteit 3%
Eenvoudig antwoord – Telkens wanneer uw SQL geen gegevens wijzigen, en u hebt een query die de andere activiteit (via vergrendeling) kan verstoren.
Het is de moeite waard om te overwegen voor eventuele vragen die voor rapporten worden gebruikt, vooral als de query meer dan, zeg 1 seconde.
Het is vooral handig als u OLAP-type rapporten heeft die u tegen een OLTP-database gebruikt.
De eerste vraag om te vragen, is “Waarom ben ik me hier zorgen over?” In mijn ervaring, fudging het standaardvergrendelingsgedrag vindt vaak plaats wanneer iemand in “PROBEER ALLES” -modus is en dit is één geval waar onverwachte consequenties niet onwaarschijnlijk zijn. Te vaak is het een geval van voortijdige optimalisatie en kan te gemakkelijk achtergelaten worden in een toepassing “voor het geval dat”. Het is belangrijk om te begrijpen waarom je het doet, welk probleem het oplost, en of je eigenlijk het probleem hebt.
Antwoord 10, Autoriteit 3%
kort antwoord:
Gebruik alleen WITH (NOLOCK)in geselecteerde instructie op tabellen met een geclusterde index.
Long Antwoord:
Met (nolock) wordt vaak geëxploiteerd als een magische manier om database te versnellen.
De resultatenset kan rijen bevatten die nog niet zijn gepleegd, die vaak later worden teruggewerkt.
Als WITH(NOLOCK) wordt toegepast op een tabel die een niet-geclusterde index heeft, kunnen rij-indexen worden gewijzigd door andere transacties terwijl de rijgegevens naar de resultatentabel worden gestreamd. Dit betekent dat de resultatenset rijen kan missen of dezelfde rij meerdere keren kan weergeven.
READ COMMITTED voegt een extra probleem toe waarbij gegevens beschadigd zijn binnen een enkele kolom waar meerdere gebruikers dezelfde cel tegelijkertijd wijzigen.
Antwoord 11, autoriteit 2%
Mijn 2 cent – het is logisch om WITH (NOLOCK) te gebruiken wanneer u rapporten moet genereren. Op dit moment zouden de gegevens niet veel veranderen & je zou die records niet willen vergrendelen.
Antwoord 12, autoriteit 2%
Als u financiële transacties afhandelt, zult u nolocknooit willen gebruiken. nolockwordt het best gebruikt om te kiezen uit grote tabellen die veel updates hebben en het maakt je niet uit of het record dat je krijgt mogelijk verouderd is.
Voor financiële records (en bijna alle andere records in de meeste toepassingen) zou nolockgrote schade aanrichten omdat u mogelijk gegevens terug zou kunnen lezen van een record waarnaar werd geschreven en niet de juiste gegevens zou krijgen.
Antwoord 13, autoriteit 2%
Ik heb altijd een “volgende batch” opgehaald om dingen te doen. Het maakt in dit geval niet uit welk item precies, en ik heb veel gebruikers die dezelfde zoekopdracht uitvoeren.
Antwoord 14
Gebruik nolock als je akkoord gaat met de “vuile” gegevens. Wat betekent dat nolock ook gegevens kan lezen die worden gewijzigd en/of niet-vastgelegde gegevens.
Het is over het algemeen geen goed idee om het te gebruiken in een omgeving met veel transacties en daarom is het geen standaardoptie bij zoekopdrachten.
Antwoord 15
Ik gebruik met (nolock) hint, met name in SQLSERVER 2000-databases met een hoge activiteit. Ik ben niet zeker dat het echter nodig is in SQL Server 2005. Ik voegde onlangs die hint in een SQL Server 2000 toe op verzoek van de DBA van de klant, omdat hij veel spedrecordsloten opmerkte.
Alles wat ik kan zeggen is dat het gebruik van de hint ons geen pijn heeft en het vergrendelingsprobleem lijkt op te lossen. De DBA bij die specifieke klant drong er in principe aan vast dat we de hint gebruiken.
Trouwens, de databases waarmee ik ermee omgaat, zijn back-ends aan Enterprise Medical Claims-systemen, dus we hebben het over miljoenen records en 20+ tafels in vele joins. Ik voegt meestal een (nolock) hint toe voor elke tafel in de join (tenzij het een afgeleide tabel is, in welk geval u die specifieke hint niet kunt gebruiken)
Antwoord 16
Het eenvoudigste antwoord is een eenvoudige vraag – heb je je resultaten nodig om herhaalbaar te zijn? Zo ja, dan is NOLOCKS niet geschikt onder geen enkele omstandigheden
Als u geen herhaalbaarheid nodig hebt, kunnen nolocks nuttig zijn, vooral als u geen controle hebt over alle processen die verbinding maken met de doeldatabase.