Sporočite, da je vaša transakcija uspešno zaključena. Kaj je transakcija z bančno kartico. Prepoved operacije. Tako imenovana "samodejna objava"

Sistem za nadzor transakcij v teku deluje na sb-opknt.online. Z obiskom tega spletnega mesta boste izvedeli za nedokončano transakcijo v višini 131.269 rubljev. Denar je treba ukrepati in dvigniti v nekaj urah, sicer bo plačilo preklicano. Preverili smo, ali projekt izvaja plačilo.

Vam bo sistem za nadzor transakcij v teku res poslal denar?

Spletno mesto je zagotovilo le e-poštni naslov za komunikacijo z določenim PJSC "OPK NT". Podatkov o tem PJSC nismo našli, podrobnosti na spletnem mestu pa niso bile navedene. Podjetje je bilo očitno izmišljeno. Izjava o omejitvi odgovornosti je bila težko berljiva in je bila postavljena na dno spletnega mesta. Toda vsak obiskovalec bi ga moral prebrati, saj so bile izjave o obljubljenih prihodkih objavljene kot predpostavke brez jamstva za plačilo.

Ni bilo smisla upati, da bi prejeli denar iz sistema za nadzor čakajočih transakcij. Sporočilo na spletnem mestu, številka transakcije in osebni račun ter znesek - vse bo enako za vse obiskovalce. Dejstvo o možnem preklicu denarja je kazalo na vprašljivo naravo mesta.

Preusmerjeni smo bili na naslednjo stran, ki je menda osebni račun. V obrazec smo vnesli več številk in naročili dvig denarja. Podatki so preverjeni in sredstva so poslana. Malo verjetno je, da bi bilo mogoče poslati plačilo na naše napačne podatke, vendar zoper nas ni bilo nobenih pritožb. Za izbrano metodo prenosa so nam ponudili le 496 ali 396 rubljev. Plačilo je bilo zagotovljeno na storitvi E-Pay, ki služi promociji prevar, ki so na določen način zaznamovale testirano stran.

Po plačilu 396 rubljev se je nakazilo nadaljevalo. Po pričakovanjih se je pojavila nova ovira - banka prejemnice je transakcijo zavrnila. Goljuf, ki je ustvaril preizkušeno spletno mesto, se ni ustavil pri enem plačilu in je zahteval naslednje, 720 rubljev za storitve priprave dokumentacije. Dokumenti tukaj niso nikogar zanimali, šlo je le za pretvezo za zahtevanje denarja. Spet smo bili poslani na E-Pay.

Razumeli smo, da nam obljubljenih 131.269 rubljev ne bodo izplačali. Sprva smo bili prevarani. Izjava, da so vsa dejanja na spletnem mestu zaščitena, se je izkazala za napačno: spletno mesto ni imelo protokola https, ki bi ščitil podatke, znani protivirusni programi pa so bili predstavljeni z nesmiselnimi slikami.

Rezultati o sistemu nadzora nedokončanih transakcij:

podatki na navedenem spletnem mestu so napačni;
ne bi smeli obiskati tega vira.

Za podroben pregled si oglejte videoposnetek:

objavljamo preverjene načine zaslužka.

Goljufi postanejo ustvarjalni, ko najdejo razloge za plačila. Toda delati jih v upanju, da boste plačani, je nesmiselno. Z našega poštnega seznama lahko izveste o prevarah, ki so nastale na internetu, če se naročite. Kontakti naše ekipe -. Pošljite nam svoje predloge za testiranje spletnih mest.

Obstajajo različni modeli transakcij, ki jih je mogoče razvrstiti glede na različne lastnosti, vključno s strukturo transakcije, sočasnostjo znotraj transakcije, trajanjem itd.

Trenutno ločimo naslednje vrste transakcij: pavšalne ali klasične transakcije, verižne transakcije in ugnezdene transakcije.

Za ravne ali tradicionalne transakcije so značilne štiri klasične lastnosti: atomičnost, doslednost, izolacija, trajnost (moč) - ACID (Atomicity, Consistency, Isolation, Durability). Tradicionalne transakcije se včasih imenujejo transakcije ACID. Zgoraj omenjene lastnosti pomenijo naslednje:

Lastnost atomičnosti (Atomicity) se izraža v tem, da je treba transakcijo izvesti kot celoto ali pa sploh ne.

Lastnost Consistency zagotavlja, da se med napredovanjem transakcij podatki premikajo iz enega skladnega stanja v drugo – transakcija ne krši medsebojne doslednosti podatkov.

Lastnost Isolation pomeni, da se konkurenčne transakcije za dostop do baze podatkov fizično obdelujejo zaporedno, ločeno ena od druge, uporabnikom pa se zdi, kot da se izvajajo vzporedno.

Lastnost Trajnost se razlaga takole: če je transakcija uspešno zaključena, potem sprememb podatkov, ki jih je naredila, pod nobenim pogojem (tudi v primeru kasnejših napak) ni mogoče izgubiti.

Obstajata dve možnosti za dokončanje transakcije. Če so vsi stavki uspešni in med transakcijo ni prišlo do napak strojne ali programske opreme, je transakcija potrjena.

Potrditev transakcije je dejanje zapisovanja na disk sprememb v bazi podatkov, ki so bile narejene med izvajanjem transakcije.

Dokler transakcija ni potrjena, je dovoljeno razveljaviti te spremembe, obnoviti bazo podatkov v stanje, v katerem je bila v času, ko se je transakcija začela. Objava transakcije pomeni, da so vsi rezultati transakcije konstantni. Drugim transakcijam bodo vidne šele po potrditvi trenutne transakcije. Do te točke bodo vsi podatki, na katere vpliva transakcija, "vidni" uporabniku v stanju na začetku trenutne transakcije.

Če se med izvajanjem transakcije zgodi nekaj, zaradi česar je nemogoče normalno dokončati, je treba bazo podatkov vrniti v prvotno stanje. Povrnitev transakcije je dejanje, ki povrne vse spremembe podatkov, ki so bile izvedene z stavki SQL, v telo trenutne čakajoče transakcije.

Vsak stavek v transakciji opravi svoj del dela, vendar se morajo vsi njegovi stavki brezpogojno zaključiti, da se celotno delo uspešno zaključi. Združevanje stavkov v transakciji pove DBMS, da mora biti celotna skupina izvedena kot celota in to izvajanje mora biti podprto samodejno.

Standard ANSI / ISO SQL opredeljuje transakcijski model in funkcije stavkov COMMIT in ROLLBACK. Standard določa, da se transakcija začne s prvim stavkom SQL, ki ga sproži uporabnik ali je vsebovan v programu, ki spremeni trenutno stanje baze podatkov. Vsi naslednji stavki SQL sestavljajo telo transakcije. Transakcija se konča na enega od štirih možnih načinov (slika 11.1):

stavek COMMIT pomeni uspešen zaključek transakcije; njegova uporaba omogoča trajne spremembe baze podatkov v okviru trenutne transakcije;

stavek ROLLBACK prekine transakcijo in prekliče spremembe v bazi podatkov kot del te transakcije; nova transakcija se začne takoj po uporabi ROLLBACK;

uspešen zaključek programa, v katerem je bila sprožena trenutna transakcija, pomeni uspešen zaključek transakcije (kot da bi bil uporabljen stavek COMMIT);

napačna prekinitev programa prekine transakcijo (kot da bi bil uporabljen stavek ROLLBACK).

V tem modelu se vsak stavek, ki spremeni stanje baze podatkov, šteje za transakcijo, zato po uspešnem zaključku tega stavka baza preide v novo stabilno stanje.

Prve različice komercialnih DBMS so izvajale transakcijski model ANSI/ISO. Kasneje je bil v SYBASE DBMS implementiran razširjen transakcijski model, ki vključuje številne dodatne operacije. Model SYBASE uporablja naslednje štiri operaterje:

Stavek BEGIN TRANSACTION poroča o začetku transakcije. Za razliko od modela ANSI/ISO, kjer je začetek transakcije implicitno določen s prvim stavkom za spremembo podatkov, je v modelu SYBASE začetek transakcije določen eksplicitno z uporabo stavka za začetek transakcije.

Stavek COMMIT TRANSACTION poroča o uspešnem zaključku transakcije. To je enakovredno stavku COMMIT v standardnem modelu ANSI / ISO. Ta operater, tako kot operater COMMIT, potrdi vse spremembe, ki so bile narejene v bazi podatkov med izvajanjem transakcije.

Stavek SAVE TRANSACTION ustvari točko shranjevanja znotraj transakcije, ki ustreza vmesnemu stanju baze podatkov, shranjene v času izvajanja tega stavka. Stavek SAVE TRANSACTION lahko vsebuje ime točke shranjevanja. Zato je med izvajanjem transakcije lahko shranjenih več shranjevalnih točk, ki ustrezajo več vmesnim stanjem.

Stavek ROLLBACK ima dve spremembi. Če je ta stavek uporabljen brez dodatnega parametra, se razlaga kot stavek za povrnitev celotne transakcije, torej je v tem primeru enakovreden stavku ROLLBACK v modelu ANSI/ISO. Če ima stavek za povrnitev parameter in je zapisan kot ROLLBACK B, se razlaga kot delni stavek za povrnitev transakcije na točko shranjevanja B.

Načela izvajanja transakcij v razširjenem transakcijskem modelu so prikazana na sl. 11.2. Na sliki so operaterji označeni s številkami, tako da nam je bolj priročno spremljati potek transakcije v vseh možnih primerih.

Transakcija se začne z eksplicitnim operatorjem začetka transakcije, ki ima v naši shemi številko 1. Sledi operator 2, ki je iskalni operator in ne spreminja trenutnega stanja baze podatkov, in naslednja operaterja 3 in 4 bazo podatkov prenesite v novo stanje. Stavek 5 shrani to novo vmesno stanje baze podatkov in ga označi kot vmesno stanje v točki A. Nato sledita stavki 6 in 7, ki bazo preneseta v novo stanje. In operater 8 to stanje shrani kot vmesno stanje v točki B. Operater 9 izvede nov vnos podatkov, operater 10 pa izvede nekaj preverjanja pogoja 1; če je pogoj 1 izpolnjen, se izvede stavek 11, ki vrne transakcijo v vmesno stanje B To pomeni, da so posledice dejanj stavka 9 tako rekoč izbrisane in se baza podatkov vrne v vmesno stanje B, čeprav je bil po izvedbi stavka 9 že v novem stanju In po vrnitvi transakcije se namesto stavka 9, ki je bil predhodno izveden iz stanja V bazi podatkov, se izvede stavek 13 vnosa novih podatkov, nato pa nadzor se prenese na stavek 14 Stavek 14 znova preveri pogoj, vendar že nek nov pogoj 2, če je pogoj izpolnjen, se nadzor prenese na operaterja 15, ki vrne transakcijo nazaj v vmesno stanje A, torej vse stavki, ki so spremenili bazo podatkov, ki se začnejo s 6 in končajo s 13, se štejejo za neizvedene, to pomeni, da so rezultati njihovega izvajanja izginili in smo spet v stanju A, saj se po izvedbi stavka 4. nadzor prenese na operater 17, ki posodablja vsebino baze podatkov, po katerem se izvede kontrol Odločitev se prenese na operaterja 18, ki je povezan s preverjanjem pogoja 3. Preverjanje se konča bodisi s prenosom nadzora na operaterja 20, ki izvrši transakcijo, in baza podatkov preide v novo stabilno stanje in je nemogoče spremeniti znotraj ali, če se nadzor prenese na operaterja 19, se transakcija povrne na začetek in DB se vrne v začetno stanje, vsa vmesna stanja pa so bila tukaj že preverjena in je nemogoče izvesti operacijo povrnitve na ta vmesna stanja po izvedbi izjave 19

Seveda razširjeni transakcijski model SYBASE podpira veliko bolj prilagodljiv mehanizem izvajanja transakcije. Točke shranjevanja omogočajo nastavitev oznak znotraj transakcije, tako da je mogoče razveljaviti le del dela, opravljenega v transakciji, možnost razveljavitve sprememb za določene operaterje. to pomeni dodatne stroške za sistemske vire - operater opravi delo, spremembe pa se nato prekinejo, običajno so izboljšave v logiki obdelave morda boljša rešitev

1. Transakcijein blokiranje

2. Koncept transakcije

Pri delu z bazami podatkov niso izključene napake in okvare. Lahko jih povzročijo napake uporabnikov pri interakciji s DBMS ali nestabilno delovanje računalnikov. Zato DBMS uporablja posebne metode za preklic dejanj, ki so povzročila takšne napake. Ukaz SQL, ki vpliva na vsebino in strukturo baze podatkov, ni nepovraten. Uporabnik lahko določi, kaj se bo zgodilo po koncu njegovih dejanj: ali bodo spremembe v bazi podatkov ostale ali bodo prezrte. Za to je zaporedje operacij v bazi podatkov združeno v skupine - transakcije.

S transakcijoje zaporedje operacij, ki se izvajajo nad bazo podatkov in jo prenašajo iz enega skladnega stanja v drugo konsistentno stanje.

Transakcija se obravnava kot neko nedeljivo dejanje v bazi podatkov, smiselno z vidika uporabnika, torej je logična enota dela sistema. Transakcija se začne vsakič, ko pride do seje baze podatkov.

Primer transakcije bi bil denarni prenos na bankomatu. Znesek 100 tr. se prenese s tekočega računa na račun kartice. Program odšteje znesek od tekočega računa in ga nato doda na račun kartice. Ko se program izvaja, po prvi spremembi pride do izpada električne energije in račun kartice se ne poveča. Da bi se izognili tej situaciji, je treba obe ekipi združiti v transakcijo. V primeru, da se vsi ukazi transakcije ne izvedejo, se transakcija povrne nazaj.

Določimo transakcijo za vnos podatkov o novo prejetih knjigah v knjižnico. To operacijo lahko razdelimo na 2 zaporedni: najprej vnos podatkov o knjigi je nova vrstica v tabeli knjige... Nato morate vnesti podatke o vseh izvodih knjige - to je vnos niza novih vrstic v tabelo Primeri.Če je to zaporedje dejanj prekinjeno, baza podatkov ne bo ustrezala resničnemu objektu, zato je zaželeno, da jo izvedete kot eno samo delo v bazi podatkov.

3. Lastnosti transakcije. Metode zaključka transakcije

Obstajajo različni modeli transakcij, ki jih je mogoče razvrstiti glede na različne lastnosti, vključno s strukturo transakcije, sočasnostjo znotraj transakcije, trajanjem itd.

Trenutno ločimo naslednje vrste transakcij: pavšalne ali klasične transakcije, verižne transakcije in ugnezdene transakcije.

Za ravne transakcije so značilne klasične lastnosti atomičnosti, doslednosti, izolacije in trajnosti.

· Lastnost atomičnosti se izraža v tem, da mora biti transakcija izvedena kot celota ali pa sploh ne.

· Lastnost doslednosti zagotavlja, da med nadaljevanjem transakcije podatki prehajajo iz enega skladnega stanja v drugo konsistentno stanje – transakcija ne krši medsebojne skladnosti podatkov.

· Lastnost izolacije pomeni, da se transakcije, ki tekmujejo za dostop do baze podatkov, fizično obdelajo zaporedno, ločeno druga od druge, vendar je uporabnikom videti, kot da se izvajajo vzporedno.

· Lastnost trajnosti pomeni, da če je transakcija uspešno zaključena, se spremembe podatkov, ki jih je naredila, v nobenem primeru ne morejo izgubiti, tudi v primeru kasnejših napak.

Obstajata 2 možnosti za dokončanje transakcije:

· če so vsi stavki uspešni in med transakcijo ni prišlo do okvar strojne ali programske opreme, je transakcija potrjena. (Potrditev je zapis na disk sprememb v bazi podatkov, ki so bile narejene med izvajanjem transakcije). Dokler transakcija ni potrjena, se te spremembe lahko povrnejo in baza podatkov se lahko vrne v stanje, v katerem je bila, ko se je transakcija začela. Objava transakcije pomeni, da so vsi rezultati transakcije konstantni. Drugim transakcijam bodo vidne šele po potrditvi trenutne transakcije.

· Če med izvajanjem transakcije pride do napake, je treba bazo podatkov vrniti v prvotno stanje. Povrnitev transakcije je dejanje, ki povrne vse spremembe podatkov, ki so bile izvedene z stavki SQL, v telo trenutne čakajoče transakcije.

4. OperaterjiTransactSQLza delo s transakcijami

ANSI / ISO definirani operaterji ZAVEZ in ROLLBACK, v standardu je začetek transakcije implicitno določen s prvim operaterjem spremembe podatkov; Operater ZAVEZ pomeni uspešen zaključek transakcije, rezultati transakcije so zabeleženi v zunanjem pomnilniku; ko operater zaključi transakcijo VRANJE rezultati transakcije se razveljavijo. Uspešen zaključek programa, v katerem je bila transakcija sprožena, pomeni uspešen zaključek transakcije (kot da bi operaterZAVEZ ), neuspešen zaključek - prekine transakcijo (kot da bi bil uporabljen operaterVRANJE ). V tem modelu se vsak stavek, ki spremeni stanje podatkov, šteje za transakcijo. Ta model je bil implementiran v prvih različicah komercialnih DBMS. Nato je bil v SYBASE DBMS implementiran razširjen transakcijski model.

V razširjenem transakcijskem modelu (na primer v DBMS SQL SERVER) so na voljo številne dodatne operacije:

· operaterja ZAČNI TRANSAKCIJO obvešča o začetku transakcije;

· operaterja OBVESTI TRANSAKCIJO poroča o uspešnem zaključku transakcije. Ta operater, kot tudi COMMIT v standardnem modelu ANSI/ISO, popravi vse spremembe, ki so bile narejene v bazi podatkov med izvajanjem transakcije;

· operaterja SHRANI TRANSAKCIJO ustvari točko shranjevanja znotraj transakcije, ki ustreza vmesnemu stanju baze podatkov, shranjene v času izvajanja tega stavka. V operaterju SHRANI TRANSAKCIJO lahko obstaja ime točke shranjevanja, zato je med izvajanjem transakcije lahko shranjenih več shranjevalnih točk, ki ustrezajo več vmesnim stanjem;

· operaterja VRANJE ima 2 modifikacije. Če se uporablja brez dodatnega parametra, se razlaga kot operater za povrnitev celotne transakcije, če ima parameter ROLLBACK n, potem se to razlaga kot operater za delno povrnitev transakcije na točko shranjevanja n.

Točke shranjevanja so uporabne pri dolgih in zapletenih transakcijah, da zagotovijo možnost razveljavitve sprememb, ki jih naredijo posebni stavki.

V večini primerov lahko nastavite parameter, ki se imenuje SAMOODVAJ , ki si bo samodejno zapomnil vse izvedene ukaze, dejanja, ki so privedla do napake, pa bodo vedno samodejno preklicana. Običajno je ta način nastavljen z ukazom, kot je:

SET SAMOODVAJ VKLOPLJENO ;

in vrnitev v običajno dialogno obdelavo zahtev:

SET SAMOODVAJ IZKLOPLJENO ;

Poleg tega je možno namestiti SAMOODVAJ , ki ga bo DBMS samodejno izvedel ob registraciji.Če se je uporabniška seja nenormalno končala – na primer pride do okvare sistema, bo trenutna transakcija samodejno povrnila spremembe. Ni priporočljivo organizirati dela tako, da posamezne transakcije vsebujejo veliko ukazov, še posebej ne povezanih med seboj. To lahko privede do dejstva, da bo ob preklicu sprememb izvedenih preveč dejanj, vključno s tistimi, ki so nujna in niso povzročila napak. Najboljša možnost je, če je transakcija sestavljena iz enega ukaza ali več tesno povezanih ukazov.

Prožilec se izvede kot implicitno definirana transakcija, zato so ukazi za nadzor transakcij dovoljeni znotraj sprožilca. Zlasti, če ugotovite kršitev omejitev integritete, morate uporabiti ukaz TRANSAKCIJA ZA PREVZEM ... Če se sprožilec uspešno zaključi, lahko uporabite ukaz ZAVEZ TRANSAKCIJA .
Izvajanje ukaza TRANSAKCIJA ZA PREVZEM oz ZAVEZ TRANSAKCIJA ne prekine sprožilca, zato morate skrbno spremljati poskuse večkratnega povrnitve transakcije, ko so izpolnjeni različni pogoji.

Primer transakcije:

ZAČNI TRAN

POSODOBITE račun

NASTAVI ravnotežje = ravnovesje - 100

Če je @@ napaka = 0

ZAČETI

ROLLBACK TRAN

NAZAJ

KONEC

POSODOBITE card_account

NASTAVI ravnotežje = ravnotežje + 100

KJE [email protected] _račun

Če je @@ napaka = 0

ZAČETI

ROLLBACK TRAN

NAZAJ

KONEC

OBVEŽI TRAN

Ukaz ZAČETI TRAN obvesti strežnik o začetku transakcije. To pomeni, da preden strežnik prejme ukazZAVEZ TRAN vse spremembe so začasne. Torej, če se strežnik po prvi posodobitvi zruši, bo transakcija povrnjena. Noben proces ne more dostopati do podatkov, dokler transakcija ni zaključena.

5. Dnevnik transakcij.

Izvajanje načela ohranjanja vmesnih stanj, potrditve ali povrnitve transakcije je zagotovljeno s posebnim mehanizmom, za podporo katerega je bila ustvarjena sistemska struktura, imenovan dnevnik transakcij. Dnevnik transakcij vsebuje zaporedje zapisov sprememb baze podatkov. Zasnovan je tako, da zagotavlja zanesljivo shranjevanje podatkov v bazi podatkov. To pomeni zmožnost obnovitve doslednega stanja baze podatkov po kakršni koli okvari strojne in programske opreme. Splošna načela beleženja in obnovitve:

· rezultate sprejetih transakcij je treba shraniti v obnovljeno stanje baze podatkov;

· rezultati nepovezanih transakcij ne bi smeli biti prisotni v obnovljenem stanju baze podatkov.

To pomeni, da se obnovi zadnje dosledno stanje baze podatkov.

Možne so naslednje situacije, v katerih je potrebno obnoviti stanje baze podatkov:

· Obnovitev po nenadni izgubi vsebine RAM-a (mehka napaka). Ta situacija se lahko zgodi v naslednjih primerih: med izklopom v sili ali ko pride do usodne okvare procesorja. Za situacijo je značilna izguba tistega dela baze podatkov, ki je bil v času okvare v medpomnilniku RAM.

· Obnovitev po okvari glavnega zunanjega medija baze podatkov (težka okvara).

Sistem bi moral biti sposoben obnoviti tako po manjših motnjah (na primer neuspešne transakcije) kot tudi po večjih motnjah (na primer izpadi električne energije, hude okvare).

V primeru mehke napake je potrebno obnoviti vsebino baze podatkov iz vsebine dnevnikov transakcij, shranjenih na diskih. V primeru hude okvare je potrebno obnoviti vsebino baze podatkov iz arhivskih kopij in dnevnikov transakcij, ki so shranjeni na nepoškodovanih zunanjih medijih.

Obstajata dve glavni možnosti za vzdrževanje podatkov dnevnika. Pri 1. možnosti se za vsako transakcijo s to transakcijo vzdržuje ločen dnevnik sprememb lokalne baze podatkov. Ti dnevniki se imenujejo lokalni dnevniki. Uporabljajo se za lokalne povrnitve transakcij. Poleg tega se vzdržuje splošni dnevnik sprememb baze podatkov, ki se uporablja za obnovitev baze podatkov po mehkih in trdih okvarah.

Ta pristop vam omogoča hitro izvedbo povratnih sprememb posameznih transakcij, vendar ima za posledico podvojene informacije v lokalnih in skupnih dnevnikih. Zato se pogosteje uporablja druga možnost - vzdrževanje samo splošnega dnevnika sprememb baze podatkov, ki se uporablja tudi pri izvajanju posameznih povrnitev.

Splošno strukturo dnevnika lahko predstavimo v obliki zaporedne datoteke, v kateri je zabeležena vsaka sprememba baze podatkov, ki se pojavi med izvajanjem transakcije. Vse transakcije imajo interne številke, tako da so vse spremembe, ki jih naredijo vse transakcije, zabeležene v dnevniku transakcij.

Vsak vnos v dnevnik je označen s številko transakcije, ki ji pripada, in vrednostmi atributov, ki jih spreminja, poleg tega se za vsako transakcijo v dnevnik zapiše ukaz za začetek in konec transakcije.

Za večjo zanesljivost se dnevnik transakcij pogosto podvaja s sistemskimi orodji DBMS, zato je količina zunanjega pomnilnika večkrat večja od dejanske količine podatkov v bazi podatkov.

Obstajata dve možnosti za beleženje transakcij: protokol za odloženo posodobitev in protokol takojšnje posodobitve.

Leno beleženje posodobitev predpostavlja naslednji mehanizem izvajanja transakcij:

1. Ko se transakcija T1 začne, se zapis vnese v protokol

T1 Začeti Transakcija

2. Med izvajanjem transakcije se za vsak spremenjen zapis v protokol vpiše nova vrednost.

T1. ID _ RECORD , atribut, nova vrednost

(ID _ RECORD - edinstvena številka zapisa)

3. Če so vsa dejanja, ki sestavljajo transakcijo, uspešno zaključena, se transakcija delno zabeleži in v protokol se vnese naslednje:

T 1 COMMT

4. Po potrditvi transakcije se zapisi protokola, povezani s T1, uporabljajo za spreminjanje baze podatkov.

5. Če pride do napake, DBMS pogleda v dnevnik in ugotovi, katere transakcije je treba ponoviti. Transakcijo T1 je treba ponoviti, če protokol vsebuje oba zapisa T1 Začeti Transakcija in T 1 COMMT . Baza podatkov je lahko v neskladnem stanju, vendar so vse nove vrednosti spremenjenih podatkovnih postavk vsebovane v dnevniku, kar zahteva ponovno izvedbo transakcije. Za to se uporablja sistemski postopek.REDO(), ki zamenja vse vrednosti elementov z novimi s prečkanjem dnevnika v naslednjem vrstnem redu.

6. Če dnevnik ne vsebuje ukaza za objavo transakcije Z IZPUSTI, potem ni potrebno nobeno dejanje in transakcija se znova zažene.

Alternativni mehanizem s takojšnjo izvedbo omogoča spreminjanje neposredno v bazo podatkov, pri čemer se v protokol ne vnesejo samo nove, temveč tudi vse stare vrednosti spremenjenih atributov, zato je vsak zapis videti takole:

T1. ID _ RECORD , atribut, nova vrednost stara vrednost

V tem primeru je pisanje v dnevnik pred neposredno izvedbo operacije v bazi podatkov. Ko je transakcija potrjena, torej naleti na ukaz T1 OBVEZA, in se izvede, potem so vse spremembe že narejene v bazi podatkov in v zvezi s to transakcijo ni potrebno nadaljnje ukrepanje.

Ko se transakcija povrne nazaj, se izvede sistemski postopek RAZVELJAJ (), ki vrne vse stare vrednosti v preklicani transakciji, zaporedoma gre skozi protokol, začenši z ukazom ZAČNI TRANSAKCIJO.

Za preklop se uporablja naslednji mehanizem:

· Če transakcija vsebuje ukaz za zagon transakcije, vendar ne vsebuje ukaza potrditve s potrditvijo njegove izvedbe, se zaporedje dejanj izvede tako, kot ko se transakcija povrne nazaj, to pomeni, da se stare vrednosti obnovijo.

Dejansko okrevanje poteka po bolj zapletenih algoritmih, saj spremembe, tako v dnevniku kot v bazi podatkov, se ne zabeležijo takoj, ampak so medpomnjene. Beleženje sprememb je tesno povezano ne le z upravljanjem transakcij, ampak tudi s shranjevanjem strani baze podatkov v RAM-u. Če bi zapis o spremembi baze podatkov, ki bi moral iti v dnevnik ob izvajanju kakršne koli operacije spreminjanja baze podatkov, dejansko takoj zapisan v zunanji pomnilnik, bi to povzročilo znatno upočasnitev sistema. Zato so tudi zapisi dnevnika medpomnjeni: med normalnim delovanjem se naslednja stran potisne v zunanji pomnilnik dnevnika šele, ko je polna zapisov.

6. Ključavnice.

V sistemih z več uporabniki se lahko več uporabnikov ali aplikacij izvaja hkrati z isto bazo podatkov. Ena od glavnih nalog DBMS je zagotoviti izolacijo uporabnikov, torej ustvarjanje takšnega načina delovanja, da bi vsak od uporabnikov mislil, da dela z bazo podatkov sam. Takšna naloga DBMS se običajno imenuje paralelizem transakcij.

Pri vzporedni obdelavi baze podatkov obstajajo tri glavne težave:

§ Manjkajoče spremembe ... Ta situacija se zgodi, ko 2 transakciji hkrati spremenita isti zapis v bazi podatkov. Na primer, 2 operaterja delata na sprejemanju naročil, prvi operater je prevzel naročilo za 30 monitorjev. Ko je šel v skladišče, je bilo 40 monitorjev, on pa je po potrditvi naročnika izdal prodajo 30 monitorjev od 40. Vzporedno z njim deluje drugi operater, ki sprejme naročilo za 20 monitorjev. isti nadzoruje, nato pa se obrne na skladišče, dobi enako vrednost 40 in odda naročilo za svojo stranko. Ko konča delo s podatki, izvede ukaz Nadgradnja, kar doda 20 kot preostanek monitorjev v skladišču. Po tem prvi operater konča delo s svojo stranko in tudi izvede ukaz Osveži, ki beleži preostanek 10 kot število monitorjev na zalogi. Prodali so skupno 50 monitorjev od 40, z 10 monitorji na zalogi.

§ Težave z vmesnimi podatki ... Povezano z možnostjo dostopa do vmesnih podatkov. Recimo, da je prvi operater, ki se pogaja s svojo stranko, vnesel naročenih 30 monitorjev, vendar je kupec želel pred zaključkom naročila izvedeti še nekaj značilnosti izdelka. Aplikacija, s katero dela 1. operater, je že spremenila preostale monitorje v skladišču in tam so zdaj shranjeni podatki o 10 preostalih monitorjih. Drugi operater trenutno poskuša od svoje stranke prevzeti naročilo za naročilo 20 monitorjev, vendar njegova aplikacija kaže, da je v skladišču le še 10 monitorjev in je operater prisiljen zavrniti svojo stranko. V tem trenutku se stranka prvega operaterja odloči, da ne bo kupila monitorjev, operater odvrne transakcijo in spet je v skladišču 40 monitorjev. Ta situacija je postala mogoča, ker je imela aplikacija drugega operaterja dostop do vmesnih podatkov, ki jih je oblikovala prva aplikacija.

§ Težave z nedoslednimi podatki. Povezano z možnostjo spreminjanja podatkov x, že prebrano x z drugo aplikacijo. Oba operaterja začneta delati skoraj istočasno, prejeta začetno stanje skladišča 40 monitorjev, nato pa prvi operater svoji stranki proda 30 monitorjev. Zapusti svojo aplikacijo in ta izvede ukaz za potrditev transakcije COMMIT. Stanje baze podatkov je dosledno. V tem trenutku se stranka drugega operaterja odloči za oddajo naročila in drugi operater ob ponovnem dostopu do podatkov vidi, da se je število monitorjev spremenilo. Drugi operater meni, da je kršena integriteta transakcije, ker pri enem delu je prejel 2 različni skladiščni državi. Ta situacija je nastala, ker je aplikacija 1. operaterja lahko spremenila podatkovni niz, ki ga je aplikacija 2. operaterja že prebrala.

Če povzamemo naštete težave, lahko ločimo naslednje vrste konfliktov med dvema vzporednima transakcijama:

· W-W - transakcija 2 poskuša spremeniti predmet, ki ga je spremenila transakcija 1, ki se ni končala;

· R-W - transakcija 2 poskuša spremeniti objekt, ki ga je prebrala transakcija 1, ki se ni končal;

· Transakcija W-R 2 poskuša prebrati objekt, ki ga je spremenila nezaključena transakcija 1;

7. Serializacija transakcij

Da bi se izognili takšnim konfliktom, je treba razviti nekaj postopkov za dosledno izvajanje sočasnih transakcij. Ta postopek mora biti v skladu z naslednjimi pravili:

1. Med izvajanjem transakcije uporabnik vidi le konsistentne podatke. Uporabnik ne bi smel videti neskladnih vmesnih podatkov.

2. Ko se v DB 2 transakcije izvajajo vzporedno, bi morali biti rezultati izvajanja transakcij enaki, kot če bi bila izvedena transakcija 1 in nato transakcija 2 ali obratno.

Postopek izvajanja teh načel se imenuje serializacija transakcij. Zagotavlja, da vsak uporabnik, ki dostopa do baze podatkov, deluje z njo, kot da ni drugih uporabnikov, ki hkrati dostopajo do istih podatkov. Rezultat skupne izvedbe transakcije je enakovreden rezultatu nekega zaporednega izvajanja istih transakcij.

Najpreprostejši izhod bi bilo zaporedno izvajanje transakcij, vendar tak izhod časovno ni optimalen, obstajajo bolj prilagodljive metode za nadzor vzporednega dostopa do baze podatkov. Najpogostejši mehanizem za reševanje teh težav je zaklepanje predmeta (na primer tabele) za celotno trajanje transakcije. Če transakcija dostopa do zaklenjenega predmeta, ostane v čakanju, dokler se predmet ne odklene, nato pa ga lahko začne obdelati. Vendar blokiranje ustvarja nove težave – zakasnitev transakcij zaradi blokiranja.

Tako lahko ključavnice, imenovane tudi sinhronizirani zajemi objektov, uporabimo za različne vrste predmetov. Največji objekt blokiranja je lahko celotna baza podatkov, vendar bo zaradi te vrste blokiranja baza podatkov nedostopna vsem drugim aplikacijam, ki delujejo s to bazo podatkov. Naslednja vrsta predmeta zaklepanja so tabele. Transakcija, ki deluje na tabeli, jo zaklene za celotno trajanje transakcije. Ta vrsta zaklepanja je boljša od prejšnje, ker omogoča sočasne transakcije, ki delujejo na drugih tabelah.

Številni DBMS izvajajo zaklepanje na ravni strani. V tem primeru DBMS zaklene samo posamezne strani na disku, ko transakcija dostopa do njih. Ta vrsta zaklepanja je še mehkejša in omogoča, da različne transakcije delujejo na isti tabeli, če dostopajo do različnih podatkovnih strani.

V nekaterih DBMS je možno zaklepanje na ravni vrstic, vendar tak mehanizem zaklepanja zahteva dodatne stroške za njegovo podporo. SQL Server si prizadeva nastaviti zaklepanje na ravni zapisa, da bi povečal sočasnost. Ko se število zaklepanja vrstic poveča, se strežnik lahko premakne na zaklepanje strani, če število zapisov preseže prag.

8. Preglasite ključavnice na ravni zahteve. Vrste zaklepanja

Če za imenom tabele v stavku IZ sledi ena od naslednjih ključnih besed, zahteva posega v upravitelja zaklepanja in uporabljena je določena vrsta zaklepanja:

· NOLOCK - omogoča umazano branje;

· PAGLOCK - zaklepanje na ravni strani;

· ROWLOCK - blokiranje na ravni zapisov;

· TABLOCK - zaklepanje skupne mize;

· TABLOCKX - ekskluzivna ključavnica za mizo

Trenutno je problem blokiranja predmet velikega števila študij.

Obstajata dve osnovni vrsti ključavnic (sinhronizacijski ročaji):

Skupne (nehardirane) ključavnice – ta način pomeni skupni zajem predmeta in se uporablja za izvajanje operacije branja na objektu. Tako zaklenjeni objekti se med izvajanjem transakcije ne spreminjajo in so na voljo drugim transakcijam, vendar le v načinu branja;

Ekskluzivne (trde) ključavnice – ne dovolite nikomur drugemu razen lastniku te ključavnice dostop do podatkov. Te ključavnice se uporabljajo za ukaze, ki spreminjajo vsebino ali strukturo tabele in so veljavne do konca transakcije.

Zajemi objektov z več transakcijami branja so združljivi, to pomeni, da je več transakcij dovoljeno brati isti objekt. Zajem predmeta z eno transakcijo branja ni združljiv z drugo transakcijo istega predmeta s pisanjem. Zajemi istega predmeta z različnimi transakcijami pisanja niso združljivi.

Vendar pa uporaba različnih vrst ključavnic vodi do problema zastoja. Problem zastoja se je pojavil ob upoštevanju izvajanja vzporednih procesov v operacijskih okoljih in je bil povezan tudi z upravljanjem skupnih (skupnih) objektov. Primer zaklepanja: Recimo, da transakcija A trdo zaklene tabelo 1 in nato trdo zaklene tabelo 2. Transakcija B na drugi strani trdo zaklene tabelo 2 in nato trdo zaklene tabelo 1.

Če sta obe transakciji začeli delovati hkrati, potem bosta po izvedbi operacij spreminjanja prve tabele obe končali v neskončnem čakanju: transakcija A bo počakala, da se transakcija B zaključi in odklene tabelo 2, in transakcija B bo zaman čakal, da se transakcija A zaključi in tabela 1 odklene.

Situacije so lahko veliko bolj zapletene. Število medsebojno blokiranih transakcij je lahko veliko večje. Vsaka transakcija te situacije ne more zaznati sama. Rešiti ga mora DBMS. Večina komercialnih DBMS ima mehanizem za odkrivanje takšnih zastojev.

Zaznavanje zastoja temelji na izdelavi (ali vzdrževanju) grafa čakajoče transakcije. Čakalni graf je lahko usmerjen graf, na vrhovih katerega se nahajajo imena transakcij. Če transakcija T1 čaka na konec transakcije T2, gre puščica od vrha T1 do vrha T2. Poleg tega lahko puščice označite z imeni blokiranih objektov in vrsto blokiranja.

Mehanizem zaklepanja uporablja koncept ravni izolacije zaklepanja, da določi, koliko tabel bo zaklenjenih. Tradicionalno se uporabljajo tri stopnje izolacije:

· Raven izolacije, imenovana ponovno branje, izvaja strategijo, tako da v dani transakciji vseh zapisov, pridobljenih s poizvedbami, ni mogoče spremeniti. Teh zapisov ni mogoče spremeniti, dokler se transakcija ne zaključi.

· Raven izolacije, imenovana kazalec stabilnosti, preprečuje spreminjanje vsakega zapisa v času branja ali branje, medtem ko se spreminja.

· Tretja stopnja stabilnosti se imenuje samo za branje. Samo za branje zaklene celotno tabelo in ga zato ni mogoče uporabiti z ukazi za posodobitev. Tako samo branje zagotavlja, da je izhod poizvedbe interno skladen s podatki tabele.

Torej orodje za nadzor sočasnosti v DBMS določa, v kolikšni meri bodo istočasno izdani ukazi motili drug drugega. V sodobnih DBMS je prilagodljivo orodje, ki samodejno poišče optimalno rešitev ob upoštevanju zagotavljanja maksimalne zmogljivosti baze podatkov in razpoložljivosti podatkov za operativne ekipe.

9. KONTROLNA VPRAŠANJA

1. Določite transakcijo. Navedite primere transakcij.

2. Navedite in okarakterizirajte lastnosti transakcij.

3. Kakšne so možne možnosti za dokončanje transakcij.

4. Kateri so operaterji jezika SQL služijo za delo s transakcijami v razširjenem transakcijskem modelu?

5. Ali lahko uporabljam ukaze za nadzor transakcij v sprožilcih?

6. Za kaj je dnevnik transakcij?

7. V katerih primerih se obnovitev baze podatkov izvede iz dnevnika transakcij?

8. Kakšne so možnosti za beleženje transakcij?

9. Kakšne so razlike med možnostmi beleženja transakcij: protokolom za odloženo posodobitev in protokolom takojšnje posodobitve.

10. Kakšne težave nastanejo, ko uporabniki delajo vzporedno z bazo podatkov?

11. Katere objekte baze podatkov je mogoče zakleniti za izvajanje načela izolacije uporabnikov?

12. Ali je mogoče nastaviti vrsto blokiranja v poizvedbah?

13. Katere vrste zajemanja objektov z več transakcijami obstajajo? Kateri so združljivi?

14. Kaj je problem slepih ulic?

Obstajajo različni modeli transakcij, ki jih je mogoče razvrstiti glede na različne lastnosti, vključno s strukturo transakcije, sočasnostjo znotraj transakcije, trajanjem itd.

Trenutno ločimo naslednje vrste transakcij: pavšalne ali klasične transakcije, verižne transakcije in ugnezdene transakcije.

· Lastnost atomičnosti(Atomičnost) se izraža v tem, da je treba transakcijo dokončati kot celoto ali pa sploh ne.

· Lastnost doslednosti(Doslednost) zagotavlja, da med napredovanjem transakcij podatki prehajajo iz enega konsistentnega stanja v drugo – transakcija ne krši vzajemne doslednosti podatkov.

· Lastnost izolacije(Izolacija) pomeni, da se konkurenčne transakcije za dostop do baze podatkov fizično obdelujejo zaporedno, ločeno ena od druge, uporabnikom pa se zdi, kot da se izvajajo vzporedno.

· Lastnost trajnosti(Trajnost) se razlaga takole: če je transakcija uspešno zaključena, potem sprememb podatkov, ki jih je naredila, pod nobenim pogojem (tudi v primeru kasnejših napak) ni mogoče izgubiti.

Obstajata dve možnosti za dokončanje transakcije. Če so vsi stavki uspešni in med transakcijo ni prišlo do napak strojne ali programske opreme, je transakcija potrjena.

Potrditev transakcije je dejanje zapisovanja na disk sprememb v bazi podatkov, ki so bile narejene med izvajanjem transakcije.

1. stavek COMMIT pomeni uspešen zaključek transakcije; njegova uporaba omogoča trajne spremembe baze podatkov v okviru trenutne transakcije;

2. stavek ROLLBACK prekine transakcijo in prekliče spremembe v bazi podatkov kot del te transakcije; nova transakcija se začne takoj po uporabi ROLLBACK;

3. uspešen zaključek programa, v katerem je bila sprožena trenutna transakcija, pomeni uspešen zaključek transakcije (kot da bi bil uporabljen stavek COMMIT);

4. napačna prekinitev programa prekine transakcijo (kot da bi bil uporabljen stavek ROLLBACK).

V tem modelu se vsak stavek, ki spremeni stanje baze podatkov, šteje za transakcijo, zato po uspešnem zaključku tega stavka baza preide v novo stabilno stanje.

· Stavek BEGIN TRANSACTION označuje začetek transakcije. Za razliko od modela ANSI/ISO, kjer je začetek transakcije implicitno določen s prvim stavkom za spremembo podatkov, je v modelu SYBASE začetek transakcije določen eksplicitno z uporabo stavka za začetek transakcije.

· Stavek COMMIT TRANSACTION poroča o uspešnem zaključku transakcije. To je enakovredno stavku COMMIT v standardnem modelu ANSI / ISO. Ta operater, tako kot operater COMMIT, potrdi vse spremembe, ki so bile narejene v bazi podatkov med izvajanjem transakcije.

· Stavek SAVE TRANSACTION ustvari točko shranjevanja znotraj transakcije, ki ustreza vmesnemu stanju baze podatkov, shranjene v času izvajanja tega stavka. Stavek SAVE TRANSACTION lahko vsebuje ime točke shranjevanja. Zato je med izvajanjem transakcije lahko shranjenih več shranjevalnih točk, ki ustrezajo več vmesnim stanjem.

· Operater ROLLBACK ima dve spremembi. Če je ta stavek uporabljen brez dodatnega parametra, se razlaga kot stavek za povrnitev celotne transakcije, torej je v tem primeru enakovreden stavku ROLLBACK v modelu ANSI/ISO. Če ima stavek za povrnitev parameter in je zapisan kot ROLLBACK B, se razlaga kot delni stavek za povrnitev transakcije na točko shranjevanja B.

riž. 11.1.Transakcijski model ANSI/ISO

riž. 11.2.Primeri izvajanja transakcij v razširjenem modelu

Transakcija se začne z eksplicitnim operatorjem začetka transakcije, ki ima v naši shemi številko 1. Sledi operator 2, ki je iskalni operator in ne spreminja trenutnega stanja baze podatkov, in naslednja operaterja 3 in 4 bazo podatkov prenesite v novo stanje. Stavek 5 shrani to novo vmesno stanje baze podatkov in ga označi kot vmesno stanje v točki A. Nato sledita stavki 6 in 7, ki bazo preneseta v novo stanje. In operater 8 to stanje shrani kot vmesno stanje v točki B. Operater 9 izvede nov vnos podatkov, operater 10 pa izvede nekaj preverjanja pogoja 1; če je pogoj 1 izpolnjen, se izvede stavek 11, ki vrne transakcijo nazaj v vmesno stanje B. To pomeni, da so posledice dejanj stavka 9 tako rekoč izbrisane in se baza podatkov spet vrne v vmesno stanje B, čeprav je bil po izvedbi izjave 9 že v novem stanju. In po vrnitvi transakcije, namesto stavka 9, ki je bil izveden prej iz stanja V bazi, se izvede stavek 13 vnosa novih podatkov, nato pa se nadzor prenese na stavek 14. Stavek 14 znova preveri pogoj, vendar že nekaj novo stanje 2; če je pogoj izpolnjen, se nadzor prenese na operaterja 15, ki vrne transakcijo nazaj v vmesno stanje A, to pomeni, da se vsi operaterji, ki so spremenili bazo podatkov, začenši s 6 in končajo s 13, štejejo za neizpolnjene, tj. , rezultati njihovega izvajanja so izginili in spet smo v stanju In, kot po izvajanju operaterja 4. Nato se nadzor prenese na operaterja 17, ki posodobi vsebino baze podatkov, nato pa se nadzor prenese na operaterja 18, ki je povezan s pogojem preverjanja 3. Preverjanje se konča bodisi s prenosom nadzora na operaterja 20, ki potrdi transakcijo, in baza podatkov preide v novo stabilno stanje in je ni mogoče spremeniti znotraj trenutne transakcije. Ali pa, če se nadzor prenese na operaterja 19, se transakcija povrne na začetek in baza podatkov se vrne v začetno stanje, vsa vmesna stanja pa so bila tukaj že preverjena in je nemogoče izvesti operacijo povrnitve na ta vmesna stanja po izvajanju operaterja 19.

Seveda razširjeni transakcijski model SYBASE podpira veliko bolj prilagodljiv mehanizem izvajanja transakcij. Točke shranjevanja omogočajo nastavitev oznak znotraj transakcije, tako da je mogoče razveljaviti le del dela, opravljenega v transakciji. Priporočljivo je, da uporabite točke shranjevanja v dolgih in zapletenih transakcijah, da zagotovite funkcionalnost razveljavitve za določene stavke. Vendar to vodi do dodatnih stroškov sistemskih virov - operater opravi delo, spremembe pa se nato prekinejo; ponavadi so izboljšave v logiki obdelave lahko boljša rešitev.

Dnevnik transakcij

Izvedbo v DBMS načela ohranjanja vmesnih stanj, potrditve ali povrnitve transakcije zagotavlja poseben mehanizem, za podporo katerega se ustvari določena sistemska struktura, imenovana Dnevnik transakcij.

Vendar je namen dnevnika transakcij veliko širši. Zasnovan je tako, da zagotavlja zanesljivo shranjevanje podatkov v bazi podatkov.

In ta zahteva pomeni zlasti možnost obnovitve skladnega stanja baze podatkov po kakršni koli okvari strojne in programske opreme. Očitno je za izvedbo obnove potrebnih nekaj dodatnih informacij. V veliki večini sodobnih relacijskih DBMS se takšne odvečne dodatne informacije hranijo v obliki dnevnika sprememb baze podatkov, ki se najpogosteje imenuje Dnevnik transakcij.

Splošni cilj beleženja sprememb baze podatkov je torej zagotoviti, da se lahko baza podatkov po kakršni koli napaki obnovi v dosledno stanje. Ker je osnova za ohranjanje celovitosti baze podatkov transakcijski mehanizem, sta beleženje in obnovitev tesno povezana s konceptom transakcije. Splošna načela okrevanja so naslednja:

· Rezultati sprejetih transakcij morajo biti shranjeni v obnovljenem stanju baze podatkov;

· Rezultati nepovezanih transakcij ne smejo biti prisotni v obnovljenem stanju baze podatkov.

To dejansko pomeni, da se obnavlja najnovejše dosledno stanje baze podatkov.

Možne so naslednje situacije, v katerih morate obnoviti stanje baze podatkov.

· Posamezni povrnitev transakcije. Ta povrnitev je treba uporabiti v naslednjih primerih:

o standardna situacija za povrnitev transakcije je njeno izrecno dokončanje s stavkom ROLLBACK;

o nenormalno prenehanje aplikacijskega programa, ki je logično enakovredno izvajanju stavka ROLLBACK, vendar ima fizično drugačen mehanizem izvajanja;

o prisilni povrnitev transakcije v primeru zastoja pri vzporednem izvajanju transakcij. V takem primeru lahko za prekinitev zastoja to transakcijo izberemo kot "žrtev" in njeno izvajanje s strani jedra DBMS prisilno prekinemo.

· Obnovitev po nenadni izgubi vsebine RAM-a (mehka napaka). To stanje se lahko pojavi v naslednjih primerih:

o v primeru izklopa napajanja v sili;

o v primeru nepopravljive okvare procesorja (na primer delovanje krmilnika RAM-a) itd. Za situacijo je značilna izguba tistega dela baze podatkov, ki je bil v času okvare v medpomnilniku RAM.

· Obnovitev po okvari glavnega zunanjega medija baze podatkov (težka okvara). Ta situacija se ob dovolj visoki zanesljivosti sodobnih zunanjih pomnilniških naprav lahko zgodi razmeroma redko, a kljub temu mora biti DBMS sposoben obnoviti bazo podatkov tudi v tem primeru. Osnova obnovitve je arhivska kopija in dnevnik sprememb baze podatkov.

Če želite obnoviti dosledno stanje baze podatkov, ko posamezno povrnete transakcijo, morate odpraviti učinke stavkov za spremembo baze podatkov, ki so bili izvedeni v tej transakciji. Za obnovitev skladnega stanja baze podatkov v primeru mehke napake je potrebno obnoviti vsebino baze podatkov iz vsebine dnevnikov transakcij, shranjenih na diskih. Za obnovitev skladnega stanja baze podatkov v primeru hude okvare je potrebno obnoviti vsebino baze podatkov iz arhivskih kopij in dnevnikov transakcij, ki so shranjeni na nepoškodovanih zunanjih medijih.

V vseh treh primerih je odvečno shranjevanje podatkov temelj obnovitve. Ti odvečni podatki so shranjeni v dnevniku, ki vsebuje zaporedje zapisov sprememb baze podatkov.

Obstajata dve glavni možnosti za vzdrževanje podatkov dnevnika. Pri prvi možnosti se za vsako transakcijo s to transakcijo vzdržuje ločen dnevnik sprememb lokalne baze podatkov. Ti dnevniki se imenujejo lokalni dnevniki. Uporabljajo se za posamezne povrnitve transakcij in jih je mogoče vzdrževati v RAM-u (pravilneje, v virtualnem) pomnilniku. Poleg tega se vzdržuje splošni dnevnik sprememb baze podatkov, ki se uporablja za obnovitev stanja baze podatkov po mehkih in trdih napakah.

Ta pristop vam omogoča hitro izvedbo povratnih sprememb posameznih transakcij, vendar ima za posledico podvojene informacije v lokalnih in skupnih dnevnikih. Zato se pogosteje uporablja druga možnost - vzdrževanje le splošnega dnevnika sprememb baze podatkov, ki se uporablja tudi pri izvajanju posameznih povrnitev. Nato razmislimo o tej posebni možnosti.

Splošno strukturo dnevnika lahko pogojno predstavimo v obliki zaporedne datoteke, ki beleži vsako spremembo baze podatkov, ki se pojavi med izvajanjem transakcije. Vse transakcije imajo svoje interne številke, zato so vse spremembe, ki jih naredijo vse transakcije, zabeležene v enem samem dnevniku transakcij.

Vsak vnos v dnevnik transakcij je označen s številko transakcije, ki ji pripada, in vrednostmi atributov, ki jih spreminja. Poleg tega se za vsako transakcijo v dnevnik zapiše ukaz za začetek in konec transakcije (glej sliko 11.3).

Za večjo zanesljivost se dnevnik transakcij pogosto podvaja s sistemskimi orodji komercialnih DBMS, zato je količina zunanjega pomnilnika večkrat večja od dejanske količine podatkov, shranjenih v pomnilniku.

Obstajata dve možnosti za beleženje transakcij: protokol za odloženo posodobitev in protokol takojšnje posodobitve.

Dnevnik sprememb v čakanju predvideva naslednji mehanizem za izvajanje transakcij:

1. Ko se transakcija T1 začne, se zapis vnese v protokol

<Т1 Begin transaction>

2. Med izvedbo transakcije se za vsak spremenjen zapis v protokol vpiše nova vrednost: ... Tukaj je ID_RECORD edinstvena številka zapisa.

3. Če so vsa dejanja, ki sestavljajo transakcijo T1, uspešno zaključena, se transakcija delno zabeleži in vnese v protokol.<Т1 СОММIТ>.

4. Po potrditvi transakcije se zapisi protokola, povezani s T1, uporabijo za ustrezne spremembe v bazi podatkov.

5. Če pride do napake, DBMS pogleda v dnevnik in ugotovi, katere transakcije je treba ponoviti. Transakcijo T1 je treba ponoviti, če protokol vsebuje oba zapisa<Т1 BEGIN TRANSACTION и <Т1 СОММIТ>... Baza podatkov je lahko v neskladnem stanju, vendar so vse nove vrednosti spremenjenih podatkovnih postavk vsebovane v dnevniku, kar zahteva ponovno izvedbo transakcije. Za to se uporablja nekakšen sistemski postopek REDOQ, ki zamenja vse vrednosti podatkovnih postavk z novimi, pri čemer gleda na protokol v neposrednem vrstnem redu.

6. Če protokol ne vsebuje ukaza za potrditev transakcije COMMIT, ni potrebno nobeno dejanje in transakcija se znova zažene.

riž. 11.3.Dnevnik transakcij

Alternativni mehanizem s takojšnjo izvedbo omogoča takojšnje spremembe baze podatkov, pri čemer se v protokol ne vnesejo le nove, temveč tudi vse stare vrednosti spremenjenih atributov, tako da je vsak zapis videti tako<Т1, ID_RECORD, атрибут новое значение старое значение...>... V tem primeru je pisanje v dnevnik pred neposredno izvedbo operacije v bazi podatkov. Ko je transakcija potrjena, torej naleti na ukaz<Т1 СОММIТ>in se izvede, potem so vse spremembe že narejene v bazi podatkov in v zvezi s to transakcijo ni potrebno nadaljnje ukrepanje.

Ko se transakcija povrne nazaj, se izvede sistemska procedura UNDO (), ki vrne vse stare vrednosti v preklicani transakciji, ki se zaporedoma nadaljuje po protokolu, ki se začne z ukazom BEGIN TRANSACTION.

Za preklop se uporablja naslednji mehanizem:

· Če je do napake prišlo po izvedbi zadnjega ukaza za spremembo DB, vendar pred izvedbo ukaza potrditve, se izvede ukaz za objavo in v bazi podatkov ni nobenih sprememb. Delo poteka samo na ravni protokola.

· Vendar je treba opozoriti, da so težave pri obnovitvi videti veliko bolj zapletene kot prej podani algoritmi, glede na to, da spremembe tako v dnevniku kot v bazi podatkov niso takoj zabeležene, temveč medpomnjene. Temu je namenjen naslednji razdelek.

Beleženje in medpomnjenje

Beleženje sprememb je tesno povezano ne le z upravljanjem transakcij, ampak tudi s shranjevanjem strani baze podatkov v pomnilnik.

Če bi bil zapis o spremembi baze podatkov, ki bi moral iti v dnevnik za vsako operacijo spreminjanja baze podatkov, dejansko takoj zapisan v zunanji pomnilnik, bi to bistveno upočasnilo sistem. Zato so tudi zapisi dnevnika medpomnjeni: med normalnim delovanjem se naslednja stran potisne v zunanji pomnilnik dnevnika šele, ko je polna zapisov.

Izziv je oblikovati neko splošno politiko potiskanja, ki bo zagotovila, da je zbirko podatkov mogoče obnoviti po zrušitvi.

Težava ne nastane pri posameznih povrnitvah transakcij, saj se v teh primerih vsebina glavnega pomnilnika ne izgubi in se lahko uporabi vsebina tako dnevnika kot medpomnilnika strani baze podatkov. Če pa pride do mehke napake in je vsebina medpomnilnikov izgubljena, morate imeti neko dosledno stanje dnevnika in baze podatkov v zunanjem pomnilniku, da lahko obnovite bazo podatkov.

Osnovno načelo doslednega pravilnika za izpiranje medpomnilnika dnevnika in medpomnilnikov strani baze podatkov je, da je treba spremembo objekta baze podatkov zapisati v zunanji pomnilnik dnevnika, preden je spremenjeni objekt v zunanjem pomnilniku baze podatkov. Ustrezni protokol beleženja (in upravljanja medpomnilnika) se imenuje Write Ahead Log (WAL) - "najprej piši v dnevnik" in je sestavljen iz dejstva, da če želite zapisati spremenjen objekt baze podatkov v zunanji pomnilnik, morate najprej zagotoviti, da dnevnik transakcij se zapiše v zunanji pomnilnik zapisov njegove spremembe.

Z drugimi besedami, če je v zunanjem pomnilniku baze podatkov nek objekt baze podatkov, v zvezi s katerim je bila izvedena operacija spreminjanja, potem je v zunanjem pomnilniku dnevnika nujno zapis, ki ustreza tej operaciji. Nasprotno ne drži, se pravi, če zunanji pomnilnik dnevnika vsebuje zapis o neki operaciji spreminjanja objekta baze podatkov, potem spremenjeni objekt morda ni prisoten v zunanjem pomnilniku baze podatkov.

Dodaten pogoj za potiskanje medpomnilnikov nalaga zahteva, da mora biti vsaka uspešno zaključena transakcija dejansko predana zunanjemu pomnilniku. Ne glede na to, katera napaka se zgodi, mora biti sistem sposoben obnoviti stanje baze podatkov, ki vsebuje rezultate vseh transakcij, izvedenih v času napake.

Enostavna rešitev bi bila izpis medpomnilnika dnevnika, ki mu sledi množični izpis medpomnilnikov strani baze podatkov, ki jih je spremenila transakcija. To se izvaja precej pogosto, vendar pri izvajanju operacije potrditve povzroči precejšnje stroške.

Izkazalo se je, da je minimalna zahteva za zagotovitev, da je mogoče obnoviti zadnje dosledno stanje baze podatkov, ta, da se ob potrditvi transakcije vsi zapisi sprememb baze podatkov s to transakcijo potisnejo v zunanji pomnilnik dnevnika. V tem primeru je zadnji zapis v dnevniku, narejen v imenu te transakcije, poseben zapis o koncu transakcije.

Zdaj pa poglejmo, kako lahko izvajate operacije obnovitve baze podatkov v različnih situacijah, če sistem vzdržuje skupni dnevnik, ki je v medpomnilniku za vse transakcije in se vzdržuje v skladu s protokolom WAL.

Posamezni povrnitev transakcije

Da bi lahko v splošnem dnevniku izvedeli povrnitev posamezne transakcije, so vsi zapisi dnevnika za to transakcijo povezani v obratnem seznamu. Na vrhu seznama neuspešnih transakcij je zadnja sprememba baze podatkov, ki jo je opravila ta transakcija. Za zaključene transakcije (posamezne vrnitve niso več možne) je začetek seznama zapis o koncu transakcije, ki se nujno potisne v zunanji pomnilnik dnevnika.Konec seznama je vedno prvi zapis o spremembi baze podatkov s to transakcijo. Običajno je vsakemu zapisu dodeljen edinstven ID transakcije, tako da se lahko z dano transakcijo obnovi neposreden seznam zapisov sprememb baze podatkov.

Torej se posamezna transakcija rollback (še enkrat poudarjamo, da je to mogoče le za nepovezane transakcije) izvede na naslednji način:

· Naslednji zapis je izbran s seznama te transakcije.

· Izvede se nasprotna operacija: namesto operacije INSERT se izvede ustrezna operacija DELETE, namesto operacije DELETE se izvede operacija INSERT in namesto neposredne operacije UPDATE inverzna operacija UPDATE obnovi prejšnje stanje baze podatkov predmet.

· Vsaka od teh obratnih operacij je tudi zabeležena. Pravzaprav to ni potrebno za posamezen povrnitev, vendar lahko pri izvajanju posameznega rollbacka transakcije pride do mehke napake, po obnovi, iz katere bo treba vrniti transakcijo, za katero posamezna povrnitev ni bila v celoti zaključena.

· Če se povrnitev uspešno zaključi, se zapis o koncu transakcije zapiše v dnevnik. Z vidika dnevnika je takšna transakcija zavezana.

Okrevanje po mehki napaki

Ena od glavnih težav pri obnovitvi po mehki napaki je, da lahko ena sama logična operacija spremembe baze podatkov spremeni več fizičnih blokov baze podatkov, kot so podatkovna stran in več indeksnih strani. Strani baze podatkov so medpomnjene v RAM-u in se pojavljajo neodvisno. Kljub uporabi protokola WAL se lahko po mehki napaki nabor strani v zunanjem pomnilniku baze izkaže za nedosleden, to pomeni, da nekatere strani zunanjega pomnilnika ustrezajo objektu pred spremembo, nekatere pa - po spremembi. Operacije logične ravni niso uporabne za to stanje objekta.

Stanje zunanjega pomnilnika baze podatkov se imenuje fizično skladno, če so nabori strani vseh objektov skladni, to pomeni, da ustrezajo stanju predmeta pred spremembo ali potem, ko je bil spremenjen.

Predvidevamo, da dnevnik označuje točke fizične doslednosti baze podatkov - trenutke, v katerih zunanji pomnilnik vsebuje konsistentne rezultate operacij, ki so se zaključile pred ustreznim trenutkom, in ni rezultatov operacij, ki so ni dokončan in vmesni pomnilnik dnevnika je potisnjen v zunanji pomnilnik. Kako je mogoče doseči fizično doslednost, bomo pogledali malo kasneje. Takšne točke imenujemo tpc (čas fizične konsistence) - točke fizičnega soglasja.

Nato so v času mehke napake možna naslednja stanja transakcije:

· Transakcija je bila uspešno zaključena, to pomeni, da je bilo delovanje transakcije COMMIT potrjeno in za vse operacije transakcije je bilo prejeto potrdilo o njeni izvedbi v zunanjem pomnilniku;

· Transakcija je bila uspešno zaključena, vendar za nekatere operacije niso prejeli potrditve njihove izvedbe v zunanjem pomnilniku;

· Transakcija je prejela in izvršila ukaz ROLLBACK;

· Transakcija ni zaključena.

Fizična skladnost baze podatkov

Kako lahko zagotovite, da so v bazi podatkov točke fizične doslednosti, torej kako obnoviti stanje baze podatkov v času tpc? Za to se uporabljata dva glavna pristopa: pristop, ki temelji na senci, in pristop, ki uporablja beleženje sprememb baze podatkov od strani do strani.

Ko se datoteka odpre, se v RAM prebere tabela za preslikavo številk njenih logičnih blokov v naslove fizičnih blokov zunanjega pomnilnika. Ko se kateri koli blok datoteke spremeni, se v zunanji pomnilnik dodeli nov blok. V tem primeru se trenutna tabela preslikav (v RAM-u) spremeni, senčna tabela pa ostane nespremenjena. Če med delom z odprto datoteko pride do napake, se stanje datoteke, preden je bila odprta, samodejno shrani v zunanji pomnilnik. Za izrecno obnovitev datoteke je dovolj, da ponovno preberete tabelo preslikave senc v RAM.

Splošna ideja senčnega mehanizma je prikazana na sl. 11.4.

riž. 11.4.Uporaba senčnih prikazovalnih tabel

V kontekstu baze podatkov se senčni mehanizem uporablja na naslednji način. Kontrolne točke se izvajajo periodično. Da bi to naredili, so zaključene vse logične operacije, vsi medpomnilniki glavnega pomnilnika, katerih vsebina ne ustreza vsebini ustreznih strani zunanjega pomnilnika, se iztisnejo. Senčna tabela za preslikavo datotek baze podatkov se nadomesti s trenutno (pravilneje je, da se trenutna tabela preslikava zapiše na mesto senčne tabele).

Obnovitev na tpc je takojšnja: trenutna tabela preslikav se nadomesti s senčno (med obnovitvijo se tabela senčnih preslikav preprosto prebere). Vse težave pri obnovitvi so rešene, vendar na račun prevelike porabe zunanjega pomnilnika. Na meji boste morda potrebovali dvakrat več zunanjega pomnilnika, kot ga dejansko potrebujete za shranjevanje baze podatkov. Senčni mehanizem je zanesljivo, a preveč grobo orodje. Konsistentno stanje zunanjega pomnilnika je zagotovljeno v eni časovni točki, ki je skupna vsem objektom. Pravzaprav je dovolj, da imamo nabor konsistentnih nizov strani, od katerih lahko vsaka ustreza svojim časovnim vzorcem.

Da bi izpolnili tako šibkejšo zahtevo, se skupaj z logičnim beleženjem operacij spreminjanja baze podatkov beležijo spremembe od strani do strani. Prvi korak pri okrevanju po mehki napaki je povrnitev neuspešnih logičnih operacij eno stran naenkrat. Kot je storjeno z logičnimi zapisi v zvezi s transakcijami, je zadnji zapis sprememb na strani iz ene logične operacije konec operacije.

Pri tem pristopu obstajata dva načina za rešitev problema. Prva metoda vzdržuje skupni dnevnik logičnih in ostranjevalnih operacij. Seveda prisotnost dveh vrst zapisov, interpretiranih na popolnoma različne načine, otežuje strukturo revije. Poleg tega zapisi o spremembah strani za stranjo, katerih relevantnost je lokalne narave, znatno (in ne zelo smiselno) povečajo revijo.

Zato postaja vse bolj priljubljeno vodenje ločenega (kratkega) dnevnika stranskih sprememb. Ta tehnika se na primer uporablja v dobro znanem izdelku Informix Online.

Recimo, da je bilo mogoče na nek način obnoviti zunanji pomnilnik baze podatkov v stanje v trenutku tpc (kako je to mogoče storiti - malo kasneje). Nato:

· Za transakcijo T1 ni potrebno ukrepanje. Končal se je pred tpc in vsi njegovi rezultati se odražajo v zunanjem pomnilniku baze podatkov.

· Za transakcijo T2 morate ponovno izvesti preostale operacije (ponovno). Dejansko v zunanjem pomnilniku ni popolnoma nobenih sledi operacij, ki so bile izvedene v transakciji T2 po trenutku tpc. Zato je neposredna ponovna interpretacija operacij T2 pravilna in bo vodila v logično konsistentno stanje baze podatkov (ker je bila transakcija T2 uspešno zaključena pred mehko napako, dnevnik vsebuje zapis vseh sprememb, ki jih je opravila ta transakcija).

· Pri transakciji TK je treba prvi del operacij (razveljaviti) izvesti v nasprotni smeri. Dejansko so v zunanjem pomnilniku baze podatkov rezultati TK operacij, ki so bili izvedeni po trenutku tpc, popolnoma odsotni. Po drugi strani pa je zagotovljeno, da zunanji pomnilnik vsebuje rezultate TK operacij, ki so bile izvedene pred tpc. Posledično je obratna interpretacija operacij TK pravilna in bo vodila v konsistentno stanje baze podatkov (ker se transakcija TK do trenutka mehke napake ni zaključila, je med obnovitvijo potrebno ohraniti vse posledice njenega izvajanja ).

· Za transakcijo T4, ki se je začela po tpc in končala pred mehko napako, je treba izvesti popolno ponovitev.

Končno ni potrebno nobeno dejanje za transakcijo T5, ki se je začela po trenutku tpc in ni imela časa za dokončanje do trenutka mehke napake. Rezultati te transakcije popolnoma manjkajo v zunanjem pomnilniku baze podatkov.

Okrevanje po hudi nesreči

Jasno je, da dnevnik sprememb baze podatkov ni dovolj za obnovitev baze podatkov v zadnje dosledno stanje po hudi okvari. V tem primeru sta osnova obnovitve dnevnik in varnostna kopija baze podatkov.

Obnovitev se začne s kopiranjem baze podatkov nazaj iz arhivske kopije. Nato se izvede ponovitev za vse zaključene transakcije, to pomeni, da se operacije ponovno izvedejo v naslednjem vrstnem redu.

Natančneje, zgodi se naslednje:

· Vse operacije se izvajajo vzdolž hloda v smeri naprej;

· Za transakcije, ki se do neuspeha še niso zaključile, se izvede povrnitev.

Ker resna napaka ne povzroči izgube medpomnilnikov RAM-a, je možno bazo podatkov obnoviti na takšno raven, da se lahko nadaljujejo tudi neuspele transakcije. Toda to se običajno ne naredi, ker je okrevanje po hudi nesreči precej dolgotrajen proces.

Čeprav obstajajo posebne zahteve za sečnjo v smislu zanesljivosti, se načeloma lahko izgubi. Potem je edini način za obnovitev baze podatkov vrnitev na arhivsko kopijo. Seveda v tem primeru ne boste mogli dobiti zadnjega doslednega stanja baze podatkov, vendar je to bolje kot nič.

Zadnje vprašanje, ki si ga bomo na kratko ogledali, se nanaša na izdelavo varnostnih kopij baze podatkov. Najlažji način je arhiviranje baze podatkov, ko je dnevnik poln. V dnevnik je uvedena tako imenovana "rumena cona", po kateri je oblikovanje novih transakcij začasno blokirano. Ko so vse transakcije zaključene in je zato baza podatkov v doslednem stanju, jo lahko arhivirate in nato znova začnete polniti dnevnik.

Bazo podatkov lahko varnostno kopirate manj pogosto, kot je dnevnik poln. Če je dnevnik poln in so se vse začete transakcije končale, lahko sam dnevnik arhivirate. Ker je tak arhiviran dnevnik v bistvu potreben le za ponovno ustvarjanje arhivirane kopije baze podatkov, se lahko informacije arhiviranega dnevnika znatno stisnejo.

Stranka banke vsakič, ko z bančno kartico plača blago, dvig sredstev ali nakazila, izvede določene transakcije. In čeprav vse transakcije trajajo le nekaj minut, je celoten cikel operacij precej obsežen proces, ki vključuje pošiljanje zahtev za dvig denarja, njihovo obdelavo in izvedbo.

Transakcija je vsaka operacija z bančno kartico, katere izvršitev vodi v spremembo stanja na računu stranke. Transakcija se lahko izvede v realnem času (na spletu) in brez povezave.

Spletne transakcije zahtevajo obvezno potrditev plačila v času plačila ali prenosa sredstev.

Spletne transakcije vključujejo denarna nakazila med karticami, operacije dviga gotovine na bankomatih, obračunske operacije v maloprodajnih mestih in trgovinah. Razmislite o postopku izvajanja spletne transakcije na primeru plačila artikla v nakupovalnem centru.

V operacijo sodelujejo tri stranke:

banka prevzemnica, ki oskrbuje izbrano poslovalnico (v trgovini je nameščen njen POS terminal);
banka izdajateljica, ki služi plačilno bančno kartico;
mednarodni plačilni sistem, ki je vmesni člen pri poravnalnih transakcijah (Visa, MasterCard itd.).

Spletno transakcijsko naročilo

Poravnalna transakcija se začne od trenutka, ko je plačilna kartica predana blagajni in POS terminal prebere podatke, potrebne za plačilo (številka kartice, rok veljavnosti, ime lastnika in drugi podatki, šifrirani na magnetnem traku). Prebrane informacije se prenesejo na banko prevzemnico, ki oskrbuje POS terminal (trgovine praviloma sklepajo posebne pogodbe za servisiranje terminalov, po katerih se za vsako transakcijo zaračunavajo provizije).

Prejete podatke banka prevzemnica posreduje v center za obdelavo podatkov (DPC) mednarodnega plačilnega sistema, ki oskrbuje kartico.

Podatkovni center preveri prisotnost ali odsotnost plačilne kartice na stop seznamu (kartice, za katere obstaja sum goljufije, se lahko pojavijo na stop seznamu), zaradi česar je operacija odobrena ali zavrnjena.

Po tem se podatki prenesejo v procesni center banke izdajateljice, kjer je plačilo odobreno. Tu se preveri zakonitost transakcije: preveri, ali je dovolj sredstev za dokončanje transakcije, in preveri, ali vnesena PIN koda ustreza realni vrednosti. Poleg tega se izvede preverjanje za preseganje določene omejitve za izvajanje operacij.

Odgovor banke izdajateljice se pošlje nazaj, prek podatkovnega centra, banki prevzemnici in trgovini. Podatki o plačilu so prikazani na čeku, ki se prenese na kupca.

Značilnosti spletnih in offline transakcij

Upoštevana dejanja pri izvajanju spletnih transakcij zaključijo interakcijo med kupcem in trgovino. Toda sam postopek transakcije se s tem ne konča. Dejstvo je, da se sredstva s kartice ne bremenijo takoj: začasno so blokirana. Sredstva se v trgovino nakažejo z računa prevzemnika, bremenijo pa se s kartice šele po tem, ko banka prevzemnica nakaže finančni dokument izdajatelju v breme. To se lahko zgodi v obdobju nekaj dni ali celo mesec.

Transakcije brez povezave se izvajajo po drugačnem principu. Preidejo brez preverjanja s strani oddaljene strani in odobritve ali zavrnitve. Transakcija je vnaprej odobrena, stanje na bančni kartici je rezervirano, vsi podatki o plačilu pa so shranjeni v pomnilniku plačilnega terminala.

Transakcija brez povezave se izvede pozneje, ko se informacije, zbrane v terminalu, prenesejo po komunikacijskih kanalih v strežniško banko. Od trenutka, ko je zahtevano plačilo, do dejanskega plačila običajno mine več dni.

Transakcije brez povezave se uporabljajo v primerih, ko ni mogoče vzpostaviti povezave s procesnim centrom v realnem času (na letalih, avtobusih, taksijih ipd.).

Prepoved in preklic transakcij

Najpogostejše transakcije so plačila v trgovinah, denarna nakazila in dvigi gotovine. Obstaja več razlogov, zakaj se lahko transakcije prepovejo.

Najpogostejši so:

bančna kartica je blokirana;
na bančni kartici ni dovolj sredstev za dokončanje operacije;
plačilna kartica ima določene omejitve pri plačilih;
plačilna kartica je potekla;
pri vnosu PIN kode je prišlo do napake;
bančna kartica je bila uvrščena na stop listo zaradi suma pranja denarja, goljufije itd .;
obstajajo tehnične težave (na spletni strani, z bankomatom itd.).

Če prepoved transakcij ni povezana z nezadostnim stanjem na kartici, se morate za odpravo težav obrniti na servisno banko. V nekaterih primerih je mogoče transakcije preklicati na pobudo samih strank (seveda, če ne govorimo o dvigih gotovine). Morate vedeti o možnosti preklica transakcij, da boste lahko goljufivo vrnili sredstva, bremenjena s kartice.

Najlažji način je preklic transakcije na dan, ko je bila opravljena.

Funkcija preklica operacij je v samih terminalih.

Če so bili podatki s terminalov že preneseni v banko, se obrnite na samo finančno institucijo.