Olen todella hämmentynyt siitä, miten sulattaa tapahtuma on atominen. Jos tapahtuma on asetettu ”kyselyiksi”, miten se on atominen. Yhdistän sanan ”kyselyt” yleiseen SQL-kyselyyn. Siksi tapahtumasta tulee tällöin vain joukko samanaikaisesti suoritettuja SQL-kyselyitä. Mutta tosiasia, että jokainen kysely on useita operaatioita, en todellakaan tiedä, miten aiemmin suoritetut kyselyt (samassa sarjassa) palautuvat, jos myöhemmässä kyselyssä tapahtuu virhe. Mitä minulta puuttuu täällä? Kiitos!
Vastaa
TL; DR; Tapahtumaloki sisältää kaikki tiedot, jotka tarvitaan jokaisen tapahtuman uudelleen luomiseen tai kumoamiseen, riippuen siitä, sisältääkö se tapahtumalle sitoutumistietueen vai ei.
SQL-tietokannoissa tapahtumien atomisuus toteutetaan useimmiten käyttämällä eteenpäin kirjaaminen (eli tapahtumalokimerkinnät kirjoitetaan ennen todelliset taulukot ja hakemistot päivitetään).
Kyselyt sanan tarkassa merkityksessä, eli div id = ”14e025338e”>
-lausekkeet ja muut lukutoiminnot, jotka eivät muuta tietokannan tilaa, eivät ole kirjautuneet sisään, koska ei ole mitään tekemistä tai palauttamista, ja sellaisenaan atomiteetin käsite ei todellakaan sovellu tähän, ainakin DBMS: n tasolla. Kyselytuloksia kuluttavan sovelluksen täytyy joutua pakottamaan atomiteetti hylkäämällä aiempien kyselyjen tulokset, jos jokin seuraavista kyselyistä epäonnistuu ja aiheuttaa palautuksen.
Kun DML-käskyt (INSERT, UPDATE, DELETE, MERGE) ja muut tietokannan tilaa muuttavat käskyt Suoritettuaan muutokset, ne kirjataan ensin eteenpäin kirjoitettavaan lokiin (WAL). Jos kaikki lauseet onnistuvat ja sitoutuminen (eksplisiittinen tai implisiittinen) annetaan, tämä tosiasia kirjataan myös WAL: iin ja loki pysyy voimassa. Tämä tekee muutoksista kestäviä. Ne voidaan kirjoittaa todellisiin taulukko- ja hakemistosegmentteihin myöhemmin myöhemmin, tarkistuspisteen tai lokin uusinnan aikana.
Jos jokin lauseista epäonnistuu, lokissa ei kuitenkaan ole sitoutumistietueita Tämä tapahtuma, ja DBMS-järjestelmä kumoaa tähän mennessä tehdyt taulukko- ja hakemistomuutokset kyseisen tapahtuman edellisten lokitietueiden avulla.
Vastaavasti, jos DBMS-prosessi kaatuu tai virta katkeaa, sitä ei tule joko lennon sisäisen tapahtuman sitoutumistietue, ja taulukon tai hakemiston muutokset, jotka ovat saattaneet olla jo voimassa, kumotaan lokin uusinnan aikana.
Kommentit
- Tämä ei ole ' oikea: " Kyselyt sanan tiukassa merkityksessä, eli SELECT-lauseet ja muut lukutoiminnot jotka eivät muuta tietokannan tilaa, ei kirjata, koska ei ole mitään tekemistä tai palauttamista " – tietokannan asetuksista riippuen jopa SELECT voi aloittaa implisiittisen tr toimia. brentozar.com/archive/2018/02/…
- I ' en sano, etteivät he ' ole transaktiovalvonnan alaisia, sanon sen, koska he ovat eivät muuta mitään, niitä ei kirjata sisään.
Vastaus
Tapahtuma on atominen, kun se kapseloidaan kuten tämä:
BEGIN TRAN UPDATE dbo.Users SET Reputation = Reputation + 1 WHERE Id = 26837; UPDATE dbo.Posts SET Score = Score + 1 WHERE Id = 227563; COMMIT Tällöin molempien erillisten taulukoiden päivitykset sitoutuvat yhteen tai ne rullaavat takaisin (epäonnistuvat) yhdessä. tämä on tapahtuman pienin yksikkö, joka sitoutuu.
Jos kuitenkin yrität myöhemmin suorittaa erillisen kyselyn kyseisen laajuuden ulkopuolella, se olisi erillinen tapahtuma.
Jos yrität jotain tällaista:
BEGIN TRAN UPDATE dbo.Users SET Reputation = Reputation + 1 WHERE Id = 26837; Ja sitten sovelluksessasi teet muita töitä, kuten C # -koodia, ja palaat sitten takaisin tietokantaan myöhemmin ja tee tämä:
UPDATE dbo.Posts SET Score = Score + 1 WHERE Id = 227563; COMMIT Tällöin sekä aiemmat käyttäjien päivitykset että myöhempi Posts-päivityksesi onnistuvat tai epäonnistuvat yhdessä.
Tosielämässä et kuitenkaan voi pitää tapahtumaa auki kuten että pitkäksi ajaksi, koska estät muita ihmisiä tekemästä työtä tietokannassa. Siksi näet usein neuvoja, kuten ”Pidä tapahtumasi lyhyt ja suloinen”, mikä tarkoittaa, että pääset sisään, saat työsi tehtyä ja palaat takaisin. Älä pidä tapahtumia nimenomaisesti avoimina.
Kommentit
- Tapahtuma on aina atominen, ei ' onko se?
- Kyllä, mutta tietokannan asetuksista riippuen implisiittiset tapahtumat saattavat olla päällä – eli ' BEGIN TRAN -palvelun saaminen, vaikka et kysy sitä '. Se vaihtelee toimittajan mukaan – esimerkiksi kuulen Oraclen oletuksena implisiittisten tapahtumien olevan, kun taas SQL Server ei.Saatat ajatella, että ' saat vain yhden tapahtuman, jos olet tullut Oracle-taustalta, kun saatat saada useita eri tapahtumia SQL Serverissä – joista jokainen olisi atominen.