A tranzakció sorozatos műveletek csoportja egy adatbázissal , amely az adatokkal végzett munka logikai egysége. A tranzakció vagy sikeresen lezárható, az adatok integritásának tiszteletben tartása mellett és független más egyidejű tranzakcióktól, vagy egyáltalán nem fejeződik be, ebben az esetben nincs hatása. A tranzakciókat tranzakciós rendszerek dolgozzák fel , melynek során tranzakciós előzmények készülnek .
A szekvenciális (normál), párhuzamos és elosztott tranzakciók megkülönböztetése . Az elosztott tranzakciók egynél több tranzakciós rendszer használatát foglalják magukban, és sokkal összetettebb logikát igényelnek (például kétfázisú véglegesítés - kétfázisú tranzakció-végrehajtási protokoll ). Ezenkívül egyes rendszerek autonóm tranzakciókat vagy résztranzakciókat valósítanak meg, amelyek a szülőtranzakció autonóm részét képezik.
Példa: az 5-ös bankszámláról a 7-es számlaszámra 10 pénzegységet kell átutalnia . Ez például a következő műveletsorokkal érhető el:
Ezek a műveletek egy logikai munkaegységet képviselnek, amely „összeg átvitele a számlák között”, így egy tranzakció. Ha ezt a tranzakciót például középen megszakítják, és nem törölnek minden változást, akkor az 5-ös számla tulajdonosát könnyen 10 egység nélkül hagyhatja, míg a 7-es számla tulajdonosa nem kapja meg azokat.
A tranzakciókkal és tranzakciós rendszerekkel szemben támasztott egyik legelterjedtebb követelményrendszer az ACID (Atomicity, Consistency, Isolation, Durability) készlet. Az ACID követelményeket főleg az 1970-es évek végén Jim Gray fogalmazta meg [1] . Ugyanakkor vannak gyengített tranzakciós tulajdonságokkal rendelkező speciális rendszerek [2] .
Ideális esetben a különböző felhasználók tranzakcióit úgy kell végrehajtani, hogy az az illúzió keltsen, hogy az aktuális tranzakció felhasználója az egyetlen. A valóságban azonban a teljesítmény okokból és néhány speciális feladat elvégzése érdekében a DBMS különféle szintű tranzakciói elkülönítést biztosít.
A szintek leírása a tranzakciók izoláltságának és ennek megfelelően az adatokkal való munka megbízhatóságának növelése érdekében történik.
Minél magasabb az izolációs szint, annál több erőforrásra van szükség annak biztosításához. Ennek megfelelően a növekvő elszigeteltség a párhuzamos tranzakciók sebességének csökkenéséhez vezethet, ami a megbízhatóság növelésének „fizetése”.
A DBMS-ben a tranzakció elkülönítési szint mind az összes tranzakcióhoz egyszerre, mind egy adott tranzakcióhoz kiválasztható. Alapértelmezés szerint a legtöbb adatbázis 1. szintet (Read Committed) használ. A 0-s szintet elsősorban a hosszan tartó tranzakciók változásainak nyomon követésére vagy a ritkán változó adatok olvasására használják. A 2. és 3. szint a tranzakciók elkülönítésének fokozott követelményeihez használatos.
Az elkülönítési szintek és az ACID tulajdonságok teljes megvalósítása nem triviális feladat. A bejövő adatok feldolgozása sok apró változtatáshoz vezet, beleértve maguknak a tábláknak és az indexeknek a frissítését is. Ezek a változtatások meghiúsulhatnak: elfogy a lemezterület, a művelet túl sokáig tart (időtúllépés), stb. Hiba esetén a rendszernek megfelelően vissza kell állítania az adatbázist a tranzakció előtti állapotba.
A korai kereskedelmi DBMS-ek (például az IBM DB2 ) kizárólag adathozzáférési zárolást használtak az ACID tulajdonságok biztosítására. De a nagyszámú zár a teljesítmény jelentős csökkenéséhez vezet. Két népszerű megoldáscsalád létezik erre a problémára, amelyek csökkentik a blokkolást:
Mindkét esetben zárolni kell az összes frissítés alatt álló információt. Az elkülönítési szinttől és a megvalósítástól függően az írási zárak a tranzakció által beolvasott információkon is el vannak helyezve.
A 2005-ös verzió előtt a Sybase és az MS SQL Server rendszerben használt proaktív naplózással minden változtatás a naplóba kerül, és csak a sikeres befejezés után az adatbázisba. Ez lehetővé teszi, hogy a DBMS visszatérjen működőképes állapotba egy váratlan rendszerösszeomlás után. Az árnyékoldalak azon adatbázis-oldalak másolatait tartalmazzák a tranzakció elején, amelyben változások történtek. Ezek a másolatok a sikeres befejezés után aktiválódnak. Míg az árnyékoldalakat könnyebb megvalósítani, a proaktív naplózás hatékonyabb [4] .
Az adatbázis-kezelési technológiák továbbfejlesztése a blokkmentes technológiák megjelenéséhez vezetett. Kidolgozták az időbélyeg-alapú párhuzamosság-vezérléssel történő párhuzamosság-vezérlés ötletét, amely egy többverziós MVCC architektúra megjelenéséhez vezetett . Ezek a technológiák nem igényelnek változásnaplózást vagy árnyékoldalakat. Az Oracle 7.x -ben és újabb verziókban megvalósított architektúra az oldalak régebbi verzióit egy speciális visszagörgetési szegmensbe írja, de azok továbbra is olvashatók. Ha a tranzakció olvasás közben olyan oldalra érkezik, amelynek időbélyege újabb, mint az olvasás kezdete, akkor az adatokat a visszagörgetési szegmensből veszik (vagyis a "régi" verziót használják). E munka támogatására tranzakciós naplót vezetünk, de a "proaktív naplózással" ellentétben ez nem tartalmaz adatokat. A vele való munka három logikai lépésből áll:
A tranzakciós napló a visszagörgetési szegmenssel (az a terület, amely a tranzakció során megváltozott összes adat másolatát tárolja) kombinálva garantálja az adatok sértetlenségét. Meghibásodás esetén helyreállítási eljárás indul, amely az alábbiak szerint tekinti át az egyes rekordokat:
A Firebirdnek egyáltalán nincs változásnaplója vagy visszagörgetési szegmense, hanem úgy valósítja meg az MVCC -t, hogy a táblázatsorok új verzióit közvetlenül az aktív adattérbe írja. Ugyanezt teszi az MS SQL 2005. Elméletileg ez ad maximális hatékonyságot az adatokkal párhuzamosan végzett munka során, de az ára a "szemétgyűjtés" igénye, vagyis az adatok régi és már nem szükséges verzióinak eltávolítása.
A tranzakciófeldolgozás célja a számítógépes rendszer (általában egy adatbázis vagy néhány modern fájlrendszer ) ismert, konzisztens állapotban tartása, biztosítva, hogy a rendszeren végzett műveletek kölcsönösen függjenek egymástól, és vagy mindegyik sikeresen befejeződött, vagy teljesen és sikeresen törölve legyen. [5]
Vegyünk például egy tipikus banki tranzakciót, amely 700 USD áthelyezését jelenti az ügyfél megtakarítási számlájáról az ügyfél csekkszámlájára. Ez a tranzakció egyetlen tranzakció a bank számára, de számítógépes értelemben legalább két különálló tranzakciót tartalmaz: 700 dollárt írnak jóvá a betétszámlán, 700 dollárt pedig a folyószámlán. Ha a terhelési tranzakciók sikeresek és a jóváírási tranzakciók nem (vagy fordítva), akkor a bank könyveiben a nap végén nem lesz egyenleg. Ezért biztosítani kell, hogy mindkét művelet sikeres legyen vagy kudarc legyen, hogy soha ne legyen inkonzisztencia a bank adatbázisának egészében. A tranzakciófeldolgozás célja ennek biztosítása.
A tranzakciófeldolgozás lehetővé teszi több különálló tranzakció automatikus összekapcsolását egyetlen, oszthatatlan tranzakcióként. A tranzakciófeldolgozó rendszerek biztosítják, hogy egy tranzakcióban vagy minden művelet hibamentesen befejeződjön, vagy egyik sem. Ha a műveletek egy része hibásan befejeződött, mások pedig anélkül, a tranzakciófeldolgozó rendszer utasítja a tranzakció összes tranzakciójának „visszagörgetését” (beleértve a sikereseket is), ami a művelet összes nyomának törlését és a rendszer visszaállítását jelenti. konzisztens ismert állapot, amely a tranzakciós folyamat megkezdése előtt volt. Ha a tranzakció minden művelete sikeresen megtörtént, akkor a tranzakció véglegesítésre kerül a rendszerben, és az adatbázisban végrehajtott összes változás "állandóvá" válik ( véglegesítve ) ; a tranzakciókat nem lehet visszavonni, ha azokat már végrehajtották.
A tranzakciófeldolgozás védelmet nyújt az olyan hardver- és szoftverhibák ellen, amelyek miatt a tranzakció részben befejeződött, és a rendszer ismeretlen, inkonzisztens állapotban marad. Ha egy számítógépes rendszer meghibásodik egy tranzakció közepén, a tranzakciófeldolgozás biztosítja, hogy a nem véglegesített (vagyis nem teljesen feldolgozott) tranzakciók minden tranzakciója visszakerüljön.
A tranzakciók szigorú időrendi sorrendben zajlanak. Ha az N+1 tranzakció az adatbázis ugyanazt a részét kívánja érinteni, mint az N tranzakció, akkor az N+1 tranzakció nem indul el addig, amíg meg nem történik N. Bármely tranzakció előtt minden más, ugyanazt a rendszerrészt érintő tranzakciót is végre kell hajtani; a korábbi tranzakciók sorrendjében nem lehetnek "lyukak". [6] [5]
Az összes tranzakciófeldolgozó rendszer alapelvei ugyanazok. A terminológia azonban tranzakciófeldolgozó rendszerenként változhat, és az alábbiakban használt kifejezések nem feltétlenül univerzálisak. [7]
Rollback ( eng. rollback )A tranzakciófeldolgozó rendszerek biztosítják az adatbázis integritását azáltal, hogy rögzítik az adatbázis köztes állapotát a módosítás előtt, majd ezekkel a rekordokkal visszaállítják az adatbázist egy ismert állapotba, ha a tranzakció nem véglegesíthető. Például az adatbázisban lévő információk másolatait, mielőtt azokat egy tranzakció megváltoztatta, a rendszer a tranzakció előtt készíti el, amely bármilyen változtatást végrehajthat (néha kép előtt hívják ). Ha a tranzakció bármely része meghiúsul a véglegesítés előtt, akkor ezekkel a másolatokkal állítja vissza az adatbázist a tranzakció megkezdése előtti állapotba ( visszaállítás ). [6]
Futás ( angol görgetés előre )Az adatbázis-változásokról külön naplót is vezethet (néha képek után nevezik ); ez nem igényli a sikertelen műveletek visszaállítását, de hasznos az adatbázis frissítéséhez adatbázishiba esetén, ezért egyes tranzakciófeldolgozó rendszerek biztosítják ezt a funkciót. Ha az adatbázis teljesen meghibásodik, vissza kell állítani az utolsó biztonsági másolatból. A biztonsági másolatok nem tükrözik a létrehozásuk után végrehajtott műveleteket. Az adatbázis visszaállítása után azonban az utóképek naplója alkalmazható az adatbázisra ( görgetés előre), hogy frissítse azt. A hiba idején folyamatban lévő tranzakciók visszaállíthatók. Az eredmény egy ismert konzisztens állapotú adatbázis, amely tartalmazza az összes tranzakció eredményét a meghibásodásig. [6]
Kölcsönös blokkolás ( angol holtpontok )Bizonyos esetekben előfordulhat, hogy feldolgozásuk során két tranzakció egyszerre próbál meg hozzáférni az adatbázis ugyanahhoz a részéhez, oly módon, hogy megakadályozza azok befejezését. Például az A tranzakció elérheti az adatbázis X részét, és a B tranzakció elérheti az adatbázis Y részét. Ha ezen a ponton az A tranzakció megpróbál hozzáférni az adatbázis Y részéhez, míg B tranzakció az X részhez, akkor holtpont következik be, és nem lehet tranzakciót folytatni. A tranzakciófeldolgozó rendszereket az ilyen helyzetek észlelésére tervezték. Általában mindkét tranzakció visszavonásra és visszagörgetésre kerül, majd automatikusan más sorrendben indul el, hogy a holtpont ne forduljon elő újra. Előfordulhat, hogy a holtponton lévő tranzakciók közül csak az egyik kerül visszaállításra, visszagörgetésre, és rövid késleltetés után automatikusan újrapróbálkozik.
Holtpont három vagy több tranzakció között fordulhat elő. Minél több tranzakció kapcsolódik, annál nehezebb észlelni őket. A tranzakciófeldolgozó rendszerek még gyakorlati korlátokat is szabtak az észlelhető holtpontoknak.
| Adatbázis | |
|---|---|
| Fogalmak |
|
| Objektumok |
|
| Kulcsok | |
| SQL |
|
| Alkatrészek | |