Sunt foarte confuz cu privire la modul de digerare a faptului că o tranzacție este atomică. Dacă o tranzacție este setată de „interogări” atunci cum va fi atomică. Relat cuvântul „interogări” cu o interogare SQL generală. Prin urmare, o tranzacție nu devine altceva decât un set de interogări SQL executate în același timp. Însă faptul că fiecare interogare a mai multor operațiuni, nu mă pricep la modul în care interogările executate anterior (în același set) revin dacă apare o eroare într-o interogare ulterioară. Ce îmi lipsește aici? Mulțumesc!
Răspuns
TL; DR; Jurnalul de tranzacții conține toate informațiile necesare pentru a re-crea sau a anula fiecare tranzacție, în funcție de faptul că conține o înregistrare de validare pentru acea tranzacție sau nu.
În bazele de date SQL atomicitatea tranzacției este implementată cel mai frecvent folosind jurnal de scriere anticipată (ceea ce înseamnă că intrările din jurnalul de tranzacții sunt scrise înainte tabelele și indexurile efective sunt actualizate).
Interogări în sensul strict al cuvântului, adică SELECT și alte operații de citire care nu modifică starea bazei de date, nu sunt înregistrate deoarece nu există nimic de comis sau redat și, ca atare, conceptul de atomicitate nu se aplică cu adevărat aici, cel puțin la nivelul SGBD. Aplicația care consumă rezultatele interogării ar putea fi necesară pentru a impune atomicitatea, eliminând rezultatele interogărilor anterioare, dacă una dintre interogările ulterioare eșuează și provoacă retrocedarea. >, UPDATE, DELETE, MERGE) și alte declarații care modifică starea bazei de date obțin executate, modificările pe care le fac sunt scrise mai întâi în jurnalul de scriere înainte (WAL). Dacă toate declarațiile au succes și se emite un commit (explicit sau implicit), acest fapt este înregistrat și în WAL și jurnalul este persistat. Acest lucru face ca modificările să fie durabile. Acestea pot fi scrise în tabelul actual și în segmentele indexate ulterior, în timpul unui punct de control sau al unei reluări a jurnalului.
Cu toate acestea, dacă una dintre instrucțiuni eșuează, nu ar exista nicio înregistrare de validare în jurnal pentru această tranzacție, iar SGBD va anula modificările de tabel și index efectuate până acum folosind înregistrările jurnal precedente ale acelei tranzacții.
În mod similar, dacă procesul SGBD se blochează sau se oprește, nu va exista fie o înregistrare de confirmare pentru tranzacția în zbor, iar modificările la tabel sau la index care ar fi putut fi persistate vor fi anulate în timpul redării jurnalului.
Comentarii
- Acest lucru nu este ' t corect: " Interogări în sensul strict al cuvântului, adică instrucțiuni SELECT și alte operații de citire care nu modifică starea bazei de date, nu sunt înregistrate, deoarece nu există nimic de comis sau derulat înapoi " – în funcție de setările bazei de date, chiar și un SELECT poate începe un tr implicit ansaction. brentozar.com/archive/2018/02/…
- I ' nu spun că ' nu sunt sub control tranzacție, ' spun că, din moment ce sunt nu schimbă nimic, nu sunt înregistrate.
Răspuns
O tranzacție este atomică atunci când este încapsulată ca aceasta:
BEGIN TRAN UPDATE dbo.Users SET Reputation = Reputation + 1 WHERE Id = 26837; UPDATE dbo.Posts SET Score = Score + 1 WHERE Id = 227563; COMMIT În acest caz, ambele actualizări de pe cele două tabele separate se vor comite împreună sau vor reveni (eșuează) împreună. Atomicitate înseamnă aceasta este cea mai mică unitate a unei tranzacții care va fi comisă.
Cu toate acestea, dacă mai târziu, încercați să executați o interogare separată în afara domeniului respectiv, aceasta ar fi o tranzacție separată.
Dacă încercați așa ceva:
BEGIN TRAN UPDATE dbo.Users SET Reputation = Reputation + 1 WHERE Id = 26837; Și apoi în aplicația dvs., faceți alte tipuri de muncă, cum ar fi codul C #, și apoi reveniți la baza de date mai târziu și faceți acest lucru:
UPDATE dbo.Posts SET Score = Score + 1 WHERE Id = 227563; COMMIT Apoi, atât actualizarea anterioară a utilizatorilor, cât și actualizarea postării ulterioare vor avea succes sau vor eșua împreună.
Cu toate acestea, în viața reală, nu puteți ține o tranzacție deschisă, cum ar fi asta pentru o perioadă lungă de timp, deoarece veți bloca alte persoane să nu lucreze în baza de date. Acesta este motivul pentru care veți vedea deseori sfaturi de genul „Păstrați tranzacția scurtă și plăcută”, adică intrați, terminați munca și reveniți. Nu țineți în mod explicit tranzacțiile deschise.
Comentarii
- O tranzacție este întotdeauna atomică, nu ' nu?
- Da, dar în funcție de setările bazei de date, este posibil să aveți tranzacții implicite activate – ceea ce înseamnă că ' re obținerea unui BEGIN TRAN chiar dacă nu ' nu o solicitați. Asta variază în funcție de furnizor – de exemplu, aud Oracle implicit pentru tranzacții implicite, în timp ce SQL Server nu.S-ar putea să credeți că ' primiți o singură tranzacție dacă proveniți dintr-un fundal Oracle, când s-ar putea să primiți mai multe tranzacții diferite în SQL Server – fiecare dintre acestea ar fi atomică.