Jeg er virkelig forvirret over, hvordan man kan fordøje det faktum, at en transaktion er atomær. Hvis en transaktion er sat med “forespørgsler”, hvordan vil den så være atomær. Jeg relaterer ordet “forespørgsler” til en generel SQL-forespørgsel. Derfor bliver en transaktion intet andet end et sæt SQL-forespørgsler, der udføres på samme tid. Men det faktum, at hver forespørgsel flere operationer, jeg virkelig ikke får, hvordan de tidligere udførte forespørgsler (i samme sæt) rulle tilbage, hvis der opstår en fejl i en senere forespørgsel. Hvad mangler jeg her? Tak!
Svar
TL; DR; Transaktionsloggen indeholder alle nødvendige oplysninger for at genskabe eller fortryde hver transaktion, afhængigt af om den indeholder en forpligtelsespost for den pågældende transaktion eller ej.
I SQL-databaser implementeres transaktionens atomicitet oftest ved hjælp af forudgående logning (hvilket betyder, at transaktionslogposter er skrevet før de faktiske tabeller og indekser opdateres).
Forespørgsler i ordets strenge betydning, det vil sige SELECT udsagn og andre læseoperationer, der ikke ændrer databasetilstanden, er ikke logget, da der ikke er noget at begå eller rulle tilbage, og som sådan gælder ikke begrebet atomicitet her, i det mindste på DBMS-niveau. Det program, der forbruger forespørgselsresultater, skal muligvis håndhæve atomicitet ved at kassere resultaterne af tidligere forespørgsler, hvis en af de efterfølgende forespørgsler mislykkes og forårsager tilbageførsel.
Når DML-sætninger (INSERT, UPDATE, DELETE, MERGE) og andre udsagn, der ændrer databasetilstanden, får udføres, bliver de ændringer, de foretager, først skrevet i log-forudskrivningsloggen (WAL). Hvis alle udsagn lykkes, og en forpligtelse (eksplicit eller implicit) udstedes, registreres denne kendsgerning også i WAL, og loggen er vedvarende. Dette gør ændringerne holdbare. De kan blive skrevet ud til den aktuelle tabel og indekssegmenter på et senere tidspunkt under et kontrolpunkt eller en logafspilning.
Men hvis et af udsagnene mislykkes, ville der ikke være nogen forpligtelsesregistrering i loggen for denne transaktion, og DBMS vil fortryde tabel- og indeksændringer, der hidtil er foretaget ved hjælp af de foregående logposter for den pågældende transaktion.
Tilsvarende, hvis DBMS-processen går ned, eller strømmen går ud, vil der ikke være enten en forpligtelsespost for transaktionen under flyvning, og de ændringer i tabellen eller indekset, der muligvis allerede er vedvarende, fortrydes under gentagelse af log.
Kommentarer
- Dette er ikke ' t korrekt: " Forespørgsler i ordets strenge forstand, dvs. SELECT-sætninger og andre læseoperationer der ikke ændrer databasetilstanden, er ikke logget, da der ikke er noget at begå eller rulle tilbage " – afhængigt af dine databaseindstillinger kan selv en SELECT starte en implicit tr ansaktion. brentozar.com/archive/2018/02/…
- I ' jeg siger ikke, at de ' ikke er under transaktionskontrol, jeg ' siger det, da de er ændrer ikke noget, de er ikke logget.
Svar
En transaktion er atomær, når den er indkapslet som dette:
BEGIN TRAN UPDATE dbo.Users SET Reputation = Reputation + 1 WHERE Id = 26837; UPDATE dbo.Posts SET Score = Score + 1 WHERE Id = 227563; COMMIT I så fald vil begge opdateringer på de to separate tabeller forpligte sig sammen, eller de vil rulle tilbage (mislykkes) sammen. Atomicitet betyder dette er den mindste enhed i en transaktion, der vil begå.
Men hvis du senere prøver at køre en separat forespørgsel uden for dette omfang, ville det være en separat transaktion.
Hvis du prøver noget som dette:
BEGIN TRAN UPDATE dbo.Users SET Reputation = Reputation + 1 WHERE Id = 26837; Og derefter i din applikation udfører du andre former for arbejde, som C # -kode, og kommer derefter tilbage til databasen senere og gør dette:
UPDATE dbo.Posts SET Score = Score + 1 WHERE Id = 227563; COMMIT Så både den tidligere brugeropdatering og din efterfølgende Posts-opdatering vil begge lykkes eller mislykkes sammen.
I det virkelige liv kan du dog ikke holde en transaktion åben som det i en længere periode, fordi du vil blokere andre mennesker for at udføre arbejde i databasen. Derfor vil du ofte se råd som “Hold din transaktion kort og sød”, hvilket betyder, kom ind, få dit arbejde udført og kom ud igen. Hold ikke eksplicit transaktioner åbne.
Kommentarer
- En transaktion er altid atomisk, er ikke ' ikke det?
- Ja, men afhængigt af dine databaseindstillinger kan du muligvis have aktiveret implicitte transaktioner – hvilket betyder, at du ' at få en BEGIN TRAN, selvom du ikke ' ikke beder om det. Det varierer fra leverandør – for eksempel hører jeg Oracle som standard er implicitte transaktioner, mens SQL Server ikke gør det.Du TÆNKER måske, at du ' kun får en transaktion, hvis du kommer fra en Oracle-baggrund, når du muligvis får flere forskellige transaktioner i SQL Server – hver af dem ville være atomare.