mobilny

Transakcja jest wykonywana na kwotę - co oznacza ten SMS. Co to jest transakcja kartą bankową

Od 1 stycznia br. ustawa zobowiązała banki do informowania swoich klientów o każdej dokonanej transakcji. Jednocześnie sposób, w jaki klient musi zostać poinformowany, nie jest określony przez prawo. Banki, które dbają o swoich klientów, korzystają z najwygodniejszych i sposób operacyjny powiadomienia - SMS. Reszta używa dla siebie tańszych środków - zgłoszenie przez e-mail lub wiadomości w konto osobiste na stronie banku.

Bez względu na to, jaką metodę wybierze Twój bank, powinieneś uważnie śledzić ostrzeżenia, ponieważ w przypadku oszukańczych transakcji dosłownie każda minuta może zagrać w Twoje ręce lub pozbawić Cię szans na zwrot skradzionej kwoty.

Pamiętaj, że oszustwo to każda transakcja za pomocą Twojej karty, która nie została dokonana przez Ciebie. Istnieje kilka rodzajów oszustw:

Twoja karta została skradziona lub zgubiona, a następnie użyta bez Twojej zgody.
Nie otrzymałeś od wystawcy nowej karty (lub karty zastępczej) i nie wiedziałeś, że wpadła w niepowołane ręce, dopóki nie otrzymałeś dokumentów o transakcjach, których nie dokonałeś.Twoje dane osobowe są wykorzystywane przez inną osobę do złożenia wniosku na kartę. Ten rodzaj oszustwa jest bardzo trudny do rozpoznania, chyba że bank wydający otrzyma skargę od klienta lub konto zostanie poddane kontroli zaraz po otwarciu. Jeśli nie jesteś klientem tego banku, możesz nie wiedzieć, że ktoś otrzymał kartę na Twoje nazwisko, dopóki nie złożysz wniosku o pożyczkę i zostaniesz odrzucony z powodu złej historii kredytowej.
Wyciąg zawiera dane o transakcjach, których nie wykonałeś, co może oznaczać, że w obiegu znajduje się fałszywa karta o takim samym numerze jak Twoja.
Atakujący z fałszywymi dokumentami, podszywając się pod posiadacza karty, przejmuje kontrolę nad kontem posiadacza karty, żądając wymiany karty na tym samym koncie. Zazwyczaj proszą o przesłanie karty na inny adres. Zwykle dowiadujesz się o tym po otrzymaniu wyciągu z konta lub gdy rachunki przestają przychodzić na Twój adres.
Masz swoją kartę, ale atakujący dokonuje transakcji z wykorzystaniem numeru karty, np. zamawia towar pocztą, telefonicznie lub przez Internet

Jeśli znajdziesz się w którejkolwiek z tych sytuacji, pierwszą rzeczą do zrobienia jest skontaktowanie się z bankiem. Zgodnie z prawem bank musi zrekompensować ci brakujące pieniądze na karcie, jeśli skarga dotycząca nielegalnej transakcji wpłynęła w ciągu pierwszego dnia po obciążeniu środkami.

Według Stepana Zajcewa, zastępcy szefa działu rozwoju kart, jeśli klient nie zgłosi kontrowersyjnej transakcji w ciągu 24 godzin, może to zrobić później. Możesz napisać roszczenie w dowolnym oddziale banku. Dalsze rozpatrzenie zostanie przeprowadzone w sposób określony przez bank. Termin odpowiedzi na żądanie klienta wynosi 30 dni roboczych (do 60 dni w przypadku udziału zagranicznych banków przejmujących). Dla wyjaśnienia całej sytuacji bank może zażądać od klienta dodatkowych dokumentów i informacji.

1. Transakcjei blokowanie

2. Pojęcie transakcji

Podczas pracy z bazami danych nie wyklucza się błędów i awarii. Mogą być spowodowane błędami użytkownika podczas interakcji z systemem DBMS lub niestabilnymi komputerami. Dlatego DBMS używa specjalne sposoby cofnięcie działań, które spowodowały takie błędy. Polecenie SQL, które wpływa na zawartość i strukturę bazy danych, nie jest nieodwracalne. Użytkownik może ustawić, co stanie się po zakończeniu jej działań: czy zmiany wprowadzone w bazie danych pozostaną, czy zostaną zignorowane. W tym celu sekwencja operacji na bazie danych jest łączona w grupy - transakcje.

transakcjato sekwencja operacji wykonywanych na bazie danych i przenoszenie jej z jednego spójnego stanu do innego spójnego stanu.

Transakcja jest traktowana jako niepodzielna czynność na bazie danych, znacząca z punktu widzenia użytkownika, czyli jest logiczną jednostką systemu. Transakcja rozpoczyna się za każdym razem, gdy następuje sesja bazy danych.

Przykładem transakcji może być przelew pieniędzy przez bankomat. Kwota 100 tr. przelewany z rachunku bieżącego na rachunek karty. Program odejmuje kwotę z rachunku bieżącego, a następnie dodaje ją do rachunku karty. W trakcie działania programu po pierwszej modyfikacji następuje awaria zasilania i nie następuje zwiększenie stanu konta karty. Aby uniknąć takiej sytuacji, oba polecenia muszą zostać połączone w transakcję. W przypadku, gdy wszystkie polecenia transakcji nie zostaną wykonane, transakcja jest wycofywana.

Zdefiniujmy transakcję wprowadzenia danych o nowo otrzymanych książkach w bibliotece. Operację tę można podzielić na 2 następujące po sobie: najpierw należy wprowadzić dane o książce Nowa linia na stole Książki. Następnie musisz wprowadzić dane o wszystkich wystąpieniach książki - jest to wprowadzenie zestawu nowych wierszy do tabeli instancje. Jeśli ta sekwencja działań zostanie przerwana, to baza danych nie będzie odpowiadać rzeczywistemu obiektowi, dlatego wskazane jest wykonanie jej jako pojedyncza praca nad bazą danych.

3. Właściwości transakcji. Sposoby realizacji transakcji

istnieje różne modele transakcje, które można klasyfikować na podstawie różnych właściwości, w tym struktury transakcji, współbieżności wewnątrz transakcji, czasu trwania i tak dalej.

Obecnie wyróżnia się następujące typy transakcji: transakcje płaskie lub klasyczne, transakcje łańcuchowe oraz transakcje zagnieżdżone.

Płaskie transakcje charakteryzują się klasycznymi właściwościami atomowości, spójności, izolacji i trwałości.

· Właściwość atomowości wyraża się w fakcie, że transakcja musi zostać zakończona w całości lub wcale.

· Właściwość spójności zapewnia, że w miarę postępu transakcji dane przechodzą z jednego spójnego stanu do innego spójnego stanu — transakcja nie niszczy wzajemnej spójności danych.

· Właściwość izolacji oznacza, że transakcje konkurujące o dostęp do bazy danych są fizycznie przetwarzane sekwencyjnie, odizolowane od siebie, ale dla użytkowników wygląda na to, że są wykonywane równolegle.

· Właściwość trwałość oznacza, że jeśli transakcja zostanie zakończona pomyślnie, to wprowadzone przez nią zmiany danych nie mogą zostać utracone w żadnych okolicznościach, nawet w przypadku kolejnych błędów.

Istnieją 2 możliwości sfinalizowania transakcji:

· jeśli wszystkie wyciągi zostały zakończone pomyślnie i podczas transakcji nie wystąpiły żadne awarie oprogramowania lub oprogramowania sprzęt komputerowy, transakcja jest zatwierdzona. (Zatwierdzenie to zapis na dysku zmian w bazie danych, które zostały wprowadzone podczas wykonywania transakcji). Dopóki transakcja nie zostanie zatwierdzona, zmiany te można wycofać, a baza danych może zostać przywrócona do stanu, w jakim była w momencie rozpoczęcia transakcji. Zawarcie transakcji oznacza, że wszystkie skutki transakcji stają się trwałe. Będą widoczne dla innych transakcji dopiero po zatwierdzeniu bieżącej transakcji.

· W przypadku niepowodzenia transakcji baza danych musi zostać zwrócona do stan początkowy. Wycofanie transakcji to działanie, które cofa wszystkie wprowadzone zmiany danych Instrukcje SQL w treści bieżącej oczekującej transakcji.

4. OperatorzyPrzeprowadzać transakcjęSQLpracować z transakcjami

W standardzie ANSI/ISO zdefiniowane operatory POPEŁNIAĆ oraz COFNIĘCIE, w standardzie początek transakcji jest domyślnie podany przez pierwszego operatora modyfikacji danych; Operator POPEŁNIAĆ oznacza pomyślne zakończenie transakcji, wyniki transakcji są zapisywane w pamięci zewnętrznej; gdy transakcja zostanie zakończona przez operatora COFNIĘCIE wyniki transakcji są anulowane. Pomyślne zakończenie programu, w którym zainicjowano transakcję, oznacza pomyślne zakończenie transakcji (jak gdyby oświadczeniePOPEŁNIAĆ ), nieudane zakończenie - przerywa transakcję (tak jakby wyciągCOFNIĘCIE ). W modelu tym każda instrukcja zmieniająca stan danych jest traktowana jako transakcja. Model ten został zaimplementowany w pierwszych wersjach komercyjnego DBMS. Następnie w SYBASE DBMS wdrożono rozszerzony model transakcji.

Rozszerzony model transakcji (na przykład DBMS SQL SERVER) zapewnia szereg dodatkowych operacji:

· operator ROZPOCZNIJ TRANSAKCJĘ informuje o rozpoczęciu transakcji;

· operator POTWIERDZENIE TRANSAKCJI informuje o pomyślnym zakończeniu transakcji. Operator ten, podobnie jak COMMIT w standardowym modelu ANSI/ISO, naprawia wszystkie zmiany, które zostały wprowadzone w bazie danych podczas transakcji;

· operator ZAPISZ TRANSAKCJĘ tworzy punkt zapisu w transakcji, który odpowiada pośredniemu stanowi bazy danych zapisanej w czasie wykonywania instrukcji. W operatorze ZAPISZ TRANSAKCJĘ może istnieć nazwa punktu zapisu, więc podczas wykonywania transakcji można przechowywać kilka punktów zapisu odpowiadających kilku stanom pośrednim;

· operator COFNIĘCIE ma 2 wersje. Jeśli jest używany bez dodatkowego parametru, to jest interpretowany jako operator wycofania dla całej transakcji, jeśli ma parametr ROLLBACKn, to jest interpretowane jako instrukcja częściowego wycofania transakcji do punktu zapisu n.

Savepoints są przydatne w długich i złożonych transakcjach, aby zapewnić możliwość cofnięcia zmian wprowadzonych przez niektóre instrukcje.

W większości przypadków możesz ustawić parametr o nazwie AUTOCOMMIT , który automatycznie zapamięta wszystkie wykonane polecenia, a akcje, które doprowadziły do błędu, będą zawsze automatycznie cofane. Zazwyczaj ten tryb jest ustawiany poleceniem takim jak:

USTAWIĆ AUTOCOMMIT NA ;

i wróć do normalnego przetwarzania żądań okna dialogowego:

USTAWIĆ AUTOCOMMIT WYŁĄCZONY ;

Dodatkowo istnieje możliwość montażu AUTOCOMMIT , które DBMS wykona automatycznie po rejestracji.Jeżeli sesja użytkownika zakończyła się nieprawidłowo, na przykład nastąpiła awaria systemu, bieżąca transakcja automatycznie cofnie zmiany. Nie zaleca się organizowania pracy w taki sposób, aby pojedyncze transakcje zawierały wiele poleceń, zwłaszcza tych, które nie są ze sobą powiązane. Może to prowadzić do tego, że po anulowaniu zmian zostanie wykonanych zbyt wiele akcji, w tym tych, które są konieczne i nie spowodowały błędów. Najlepszym sposobem gdy transakcja składa się z jednego polecenia lub kilku ściśle powiązanych poleceń.

Wyzwalacz jest wykonywany jako transakcja zdefiniowana niejawnie, więc polecenia sterujące transakcją mogą być używane w wyzwalaczu. W szczególności, gdy wykryte zostanie naruszenie ograniczeń integralności, aby przerwać wykonywanie wyzwalacza i anulować wszystkie zmiany, które próbował wprowadzić użytkownik, należy użyć polecenia TRANSAKCJA WYCOFANIA . W przypadku pomyślnego zakończenia wyzwalacza możesz użyć polecenia POPEŁNIAĆ TRANSAKCJA .
Wykonanie polecenia TRANSAKCJA WYCOFANIA lub POPEŁNIAĆ TRANSAKCJA nie przerywa działania wyzwalacza, dlatego należy uważnie monitorować próby wielokrotnego wycofania transakcji w różnych warunkach.

Przykład transakcji:

ROZPOCZNIJ TRANSPORT

Zaktualizuj konto

ZESTAW saldo = saldo-100

Jeśli @@błąd=0

ZACZYNAĆ

PRZEJAZD WYCOFANIA

POWRÓT

KOŃCZYĆ SIĘ

AKTUALIZUJ konto_karty

ZESTAW saldo = równowaga + 100

GDZIE [e-mail chroniony] _rachunek

Jeśli @@błąd=0

ZACZYNAĆ

PRZEJAZD WYCOFANIA

POWRÓT

KOŃCZYĆ SIĘ

POTWIERDZAJ PRZEJAZD

Zespół ZACZYNAĆ TRAN informuje serwer o rozpoczęciu transakcji. Oznacza to, że zanim serwer otrzyma poleceniePOPEŁNIAĆ TRAN wszystkie zmiany są tymczasowe. Dlatego jeśli serwer ulegnie awarii po pierwszej aktualizacji, transakcja zostanie wycofana. Żaden proces nie będzie miał dostępu do danych do czasu zakończenia transakcji.

5. Dziennik transakcji.

Realizację zasady zapisywania stanów pośrednich, potwierdzania lub wycofywania transakcji zapewnia specjalny mechanizm, dla którego stworzona została struktura systemu zwana dziennikiem transakcji. Dziennik transakcji zawiera sekwencję zapisów o zmianach w bazie danych. Został zaprojektowany w celu zapewnienia niezawodnego przechowywania danych w bazie danych. Oznacza to możliwość przywrócenia spójnego stanu bazy danych po wszelkiego rodzaju awariach sprzętu i oprogramowania. Ogólne zasady logowanie i odzyskiwanie:

· wyniki zatwierdzonych transakcji muszą być zapisane w odtworzonym stanie bazy danych;

· wyniki niezatwierdzonych transakcji nie powinny znajdować się w przywróconym stanie bazy danych.

Oznacza to, że przywracany jest najnowszy spójny stan bazy danych.

Możliwe są następujące sytuacje, w których konieczne jest przywrócenie stanu bazy danych:

· Odzyskiwanie po nagłej utracie treści pamięć o dostępie swobodnym(miękki wypadek). Taka sytuacja może wystąpić w następujących przypadkach: podczas przerwy w zasilaniu lub krytycznej awarii procesora. Sytuacja charakteryzuje się utratą tej części bazy danych, która znajdowała się w buforach RAM w momencie awarii.

· Odzyskiwanie po awarii głównego zewnętrznego nośnika bazy danych (awaria twarda).

System musi być w stanie odzyskać sprawność zarówno po drobnych zakłóceniach (np. nieudane transakcje), jak i poważnych awariach (np. awarie zasilania, poważne awarie).

W przypadku awarii miękkiej konieczne jest odzyskanie zawartości bazy danych z zawartości logów transakcyjnych przechowywanych na dyskach. W przypadku poważnej awarii konieczne jest odtworzenie zawartości bazy danych z kopii zapasowych i dzienników transakcji, które przechowywane są na nieuszkodzonych nośnikach zewnętrznych.

Istnieją dwie główne opcje rejestrowania informacji. W pierwszej opcji dla każdej transakcji prowadzony jest przez tę transakcję osobny lokalny dziennik zmian bazy danych. Takie dzienniki nazywane są dziennikami lokalnymi. Służą do wycofywania lokalnych transakcji. Ponadto utrzymywany jest współużytkowany dziennik zmian bazy danych, który służy do przywracania bazy danych po miękkich i twardych awariach.

Takie podejście umożliwia szybkie wykonywanie pojedynczych wycofań transakcji, ale prowadzi do powielania informacji w dziennikach lokalnych i ogólnych. Dlatego częściej stosowana jest druga opcja - utrzymywanie tylko ogólnego dziennika zmian bazy danych, który jest również wykorzystywany przy wykonywaniu poszczególnych cofnięć.

Struktura ogólna Dziennik może być reprezentowany jako plik sekwencyjny, który rejestruje każdą zmianę w bazie danych, która następuje podczas realizacji transakcji. Wszystkie transakcje mają numery wewnętrzne, więc dziennik transakcji rejestruje wszystkie zmiany dokonane przez wszystkie transakcje.

Każdy wpis w logu jest oznaczony numerem transakcji, do której należy, oraz wartościami atrybutów, które zmienia, dodatkowo dla każdej transakcji w logu zapisywane jest polecenie rozpoczęcia i zakończenia transakcji .

Dla większej niezawodności dziennik transakcji jest często duplikowany przez narzędzia systemu DBMS, dlatego ilość pamięci zewnętrznej jest wielokrotnie większa niż rzeczywista ilość danych w bazie danych.

Istnieją 2 opcje rejestrowania transakcji: protokół z opóźnionymi aktualizacjami i protokół z natychmiastowymi aktualizacjami.

Logowanie z opóźnieniem obejmuje następujący mechanizm wykonywania transakcji:

1. Po rozpoczęciu transakcji T1 następuje wpis w logu

T1 Zaczynać transakcja

2. Podczas realizacji transakcji do protokołu zapisywana jest nowa wartość dla każdego wpisu podlegającego zmianie.

T1. ID _ NAGRYWAĆ , atrybut, nowa wartość

(ID _ NAGRYWAĆ – unikalny numer rekordu)

3. Jeżeli wszystkie czynności składające się na transakcję zostały pomyślnie zakończone, transakcja jest częściowo zatwierdzona, a w logu zapisywane są:

T 1 COMMT

4. Po zatwierdzeniu transakcji wpisy dziennika związane z T1 są używane do wprowadzania zmian w bazie danych.

5. Jeśli wystąpi awaria, DBMS przegląda dziennik i dowiaduje się, które transakcje należy powtórzyć. Transakcja T1 musi zostać powtórzona, jeśli protokół zawiera oba wpisy T1 Zaczynać transakcja oraz T 1 COMMT . Baza danych może być w stanie niespójnym, jednak wszystkie nowe wartości zmienionych elementów danych są zawarte w logu, a to wymaga ponownego wykonania transakcji. W tym celu skorzystaj z procedury systemowejPRZEROBIĆ(), który zastępuje wszystkie wartości pozycji nowymi poprzez skanowanie dziennika w bezpośredniej kolejności.

6. Jeśli protokół nie zawiera polecenia zatwierdzenia transakcji Z POMIŃ, nie jest wymagane żadne działanie, a transakcja zostanie ponownie uruchomiona.

Alternatywny mechanizm z natychmiastowym wykonaniem zapewnia natychmiastowe wprowadzanie zmian do bazy danych, a do logu wpisywane są nie tylko nowe, ale również wszystkie stare wartości zmienionych atrybutów, więc każdy wpis wygląda tak:

T1. ID _ NAGRYWAĆ , atrybut, nowa wartość stara wartość

W takim przypadku zapisanie do dziennika poprzedza bezpośrednie wykonanie operacji na bazie danych. Gdy transakcja zostanie zatwierdzona, to znaczy, że napotkano polecenie T1 POTWIERDZENIE, i jest wykonywany, wszystkie zmiany są już wprowadzone w bazie danych i nie są wymagane żadne dalsze działania w związku z tą transakcją.

Po wycofaniu transakcji wykonywana jest procedura systemowa COFNIJ(), który zwraca wszystkie stare wartości w anulowanej transakcji, kolejno przechodząc przez protokół, zaczynając od polecenia ROZPOCZNIJ TRANSAKCJĘ.

Do przełączania awaryjnego używany jest następujący mechanizm:

· Jeżeli transakcja zawiera polecenie rozpoczęcia transakcji, ale nie zawiera polecenia zatwierdzenia z potwierdzeniem jego wykonania, to sekwencja działań jest wykonywana tak, jakby transakcja została wycofana, czyli przywracane są stare wartości.

W rzeczywistości odzyskiwanie następuje według bardziej złożonych algorytmów, ponieważ zmiany, zarówno w logu, jak iw bazie danych, nie są od razu rejestrowane, lecz buforowane. Rejestrowanie zmian jest ściśle związane nie tylko z zarządzaniem transakcjami, ale także z buforowaniem stron bazy danych w pamięci RAM. Jeśli rekord zmiany bazy danych, który powinien trafić do dziennika przy każdej operacji modyfikacji bazy danych, został faktycznie natychmiast zapisany do pamięć zewnętrzna, doprowadziłoby to do znacznego spowolnienia systemu. Dlatego wpisy dziennika są również buforowane: podczas normalnej pracy następna strona jest wypychana do zewnętrznej pamięci dziennika tylko wtedy, gdy jest całkowicie wypełniona wpisami.

6. Zamki.

W systemach wieloużytkownikowych z jedną bazą danych kilku użytkowników może pracować jednocześnie lub programy użytkowe. Jednym z głównych zadań SZBD jest zapewnienie izolacji użytkowników, czyli stworzenie takiego trybu działania, aby każdy z użytkowników wydawał się sam pracować z bazą danych. To zadanie DBMS jest powszechnie nazywane paralelizmem transakcyjnym.

Istnieją trzy główne problemy związane z przetwarzaniem równoległym bazy danych:

§ Brakujące zmiany . Taka sytuacja ma miejsce, gdy 2 transakcje zmieniają ten sam rekord w bazie danych w tym samym czasie. Np. 2 operatorów pracuje nad przyjmowaniem zamówień, pierwszy operator przyjął zamówienie na 30 monitorów. Kiedy skontaktował się z magazynem, było tam 40 monitorów i po otrzymaniu potwierdzenia od klienta sfinalizował sprzedaż 30 monitorów z 40. W tym samym czasie pracuje z nim drugi operator, który przyjmuje zamówienie na 20 te same monitory, a z kolei kontaktując się z magazynem otrzymuje tę samą wartość 40 i składa zamówienie dla swojego klienta. Po zakończeniu z danymi wykonuje polecenie Odświeżać, co stanowi 20 jako saldo monitorów na stanie. Następnie pierwszy operator kończy pracę ze swoim klientem, a także wykonuje polecenie Odświeżać, która wprowadza resztę 10 jako liczbę monitorów w magazynie. W sumie sprzedali 50 monitorów z 40 dostępnymi i będą mieli 10 monitorów na stanie.

§ Pośrednie problemy z danymi . Związany z możliwością dostępu do danych pośrednich. Załóżmy, że pierwszy operator, negocjując ze swoim klientem, przedstawił zamówione 30 monitorów, ale przed finalizacją zamówienia klient chciał dowiedzieć się więcej o cechach produktu. Aplikacja, z której korzysta operator 1, zmieniła już pozostałe monitory w magazynie i teraz są tam przechowywane informacje o 10 pozostałych monitorach. W tej chwili drugi operator próbuje przyjąć od swojego klienta zamówienie na 20 monitorów, ale z jego aplikacji wynika, że na magazynie pozostało tylko 10 monitorów i operator jest zmuszony odmówić klientowi. W tym czasie klient pierwszego operatora rezygnuje z zakupu monitorów, operator wycofuje transakcję i 40 monitorów jest ponownie w magazynie. Sytuacja ta stała się możliwa, ponieważ aplikacja drugiego operatora miała dostęp do danych pośrednich, które wygenerowała pierwsza aplikacja.

§ Problemy niespójnych danych. Związany z możliwością zmiany danych x , już przeczytałem x inna aplikacja. Obaj operatorzy rozpoczynają pracę niemal w tym samym czasie, otrzymują początkowy zapas 40 monitorów, a następnie pierwszy operator sprzedaje 30 monitorów swojemu klientowi. Kończy swoją aplikację i wykonuje polecenie transakcji COMMIT. Stan bazy danych jest niespójny. W tym momencie klient drugiego operatora decyduje się na złożenie zamówienia, a drugi operator, ponownie odwołując się do danych, widzi, że zmieniła się ilość monitorów. Drugi operator uważa, że została naruszona integralność transakcji, ponieważ: podczas wykonywania jednego zlecenia otrzymał 2 różne stany magazynu. Sytuacja ta powstała, ponieważ aplikacja pierwszego operatora była w stanie zmienić krotkę danych, którą aplikacja drugiego operatora już odczytała.

Podsumowując wymienione problemy, można wyróżnić następujące rodzaje konfliktów pomiędzy dwiema równoległymi transakcjami:

· W-W – transakcja 2 próbuje zmodyfikować obiekt, który został zmodyfikowany przez transakcję 1, która się nie zakończyła;

· R-W - transakcja 2 próbuje zmienić obiekt odczytany przez transakcję 1, która się nie zakończyła;

· Transakcja W-R 2 próbuje odczytać obiekt zmodyfikowany przez transakcję 1, która się nie zakończyła;

7. Serializacja transakcji

Aby uniknąć takich konfliktów, konieczne jest opracowanie procedury spójnej realizacji transakcji równoległych. Ta procedura musi być zgodna z następującymi zasadami:

1. Podczas transakcji użytkownik widzi tylko spójne dane. Użytkownik nie powinien widzieć niespójnych danych pośrednich.

2. Gdy w bazie danych działają równolegle 2 transakcje, wyniki realizacji transakcji powinny być takie same, jak w przypadku realizacji transakcji 1, a następnie transakcji 2 lub odwrotnie.

Procedura wymuszająca te zasady nazywana jest serializacją transakcji. Zapewnia to, że każdy użytkownik uzyskujący dostęp do bazy danych pracuje z nią tak, jakby żaden inny użytkownik nie miał dostępu do tych samych danych w tym samym czasie. Wynik wspólnej realizacji transakcji jest równoznaczny z wynikiem sekwencyjnej realizacji tych samych transakcji.

Najprostszym wyjściem byłoby sekwencyjne wykonywanie transakcji, ale takie wyjście nie jest optymalne czasowo, istnieją bardziej elastyczne metody zarządzania dostępem równoległym do bazy danych. Najczęstszym mechanizmem radzenia sobie z tymi problemami jest zablokowanie obiektu (takiego jak tabela) na czas trwania transakcji. Jeśli transakcja uzyskuje dostęp do zablokowanego obiektu, pozostaje w stanie oczekiwania do momentu odblokowania obiektu, po czym może rozpocząć przetwarzanie. Jednak blokowanie stwarza nowe problemy - opóźnienia transakcji z powodu blokad.

Tak więc blokady, zwane również blokadami obiektów synchronizacji, mogą być stosowane do różnych typów obiektów. Największym obiektem blokady może być cała baza danych, ale ten rodzaj blokady sprawi, że baza danych będzie niedostępna dla wszystkich innych aplikacji, które współpracują z tą bazą danych. Kolejnym typem obiektu blokady są tabele. Transakcja działająca na tabeli blokuje ją na czas trwania transakcji. Ten rodzaj blokady jest lepszy od poprzedniego, ponieważ umożliwia równoległe wykonywanie transakcji operujących na innych tabelach.

Niektóre DBMS implementują blokowanie na poziomie strony. W tym przypadku DBMS blokuje tylko pojedyncze strony na dysku, gdy transakcja ma do nich dostęp. Ten rodzaj blokowania jest jeszcze łagodniejszy i pozwala na działanie różnych transakcji na tej samej tabeli, o ile mają dostęp różne strony dane.

W niektórych DBMS możliwe jest blokowanie na poziomie wiersza, ale taki mechanizm blokowania wymaga dodatkowych kosztów, aby go obsługiwać. Serwer SQL dąży do ustanowienia blokowania na poziomie rekordu, aby zapewnić maksymalną współbieżność w działaniu. Wraz ze wzrostem liczby blokad wierszy serwer może przejść do blokowania stron, jeśli liczba rekordów przekroczy próg.

8. Przedefiniowanie blokad na poziomie żądania. Rodzaje zamków

Jeśli po nazwie tabeli w zdaniu Z podąża za jednym z następujących słowa kluczowe, żądanie koliduje z menedżerem blokad i stosowany jest określony typ blokady:

· NOLOCK - umożliwia brudny odczyt;

· PAGLOCK - blokowanie na poziomie strony;

· ROWLOCK - blokada na rekordowym poziomie;

· TABLOCK - blokada wspólnego stołu;

· TABLOCKX - ekskluzywny zamek stołowy

Obecnie problem blokowania jest przedmiotem wielu badań.

Istnieją dwa podstawowe typy blokad (przechwytywanie synchronizacji):

Blokady współdzielone (nie twarde) — ten tryb oznacza przechwytywanie obiektu współdzielonego i służy do wykonywania operacji odczytu obiektu. Zablokowane w ten sposób obiekty nie ulegają zmianie w trakcie realizacji transakcji i są dostępne dla innych transakcji, a jedynie w trybie odczytu;

Wyłączne (twarde) blokady - nie zezwalaj nikomu poza właścicielem tej blokady na dostęp do danych. Blokady te są używane do poleceń zmieniających zawartość lub strukturę tabeli i trwają do końca transakcji.

Przechwytywanie obiektów przez wiele transakcji jest zgodne z odczytem, co oznacza, że wiele transakcji może odczytywać ten sam obiekt. Przechwycenie obiektu przez jedną transakcję przy odczycie nie jest zgodne z przechwyceniem tego samego obiektu przez inną transakcję przy zapisie. Przechwytywania tego samego obiektu przez różne transakcje zapisu nie są zgodne.

Jednak aplikacja różne rodzaje zamki prowadzą do problemu zakleszczeń. Problem zakleszczeń pojawił się przy rozważaniu wykonywania równoległych procesów w środowiska operacyjne a także był związany z zarządzaniem współdzielonymi (wspólnymi) obiektami. Przykład zakleszczenia: Niech transakcja A klucz blokady tabela 1, a następnie tabela klucza 2. Transakcja B, przeciwnie, tabela klucza 2, a następnie tabela klucza 1.

Jeśli obie te transakcje rozpoczęły się w tym samym czasie, to po wykonaniu operacji modyfikacji pierwszej tabeli, obie skończą w nieskończonym oczekiwaniu: transakcja A będzie oczekiwała na zakończenie transakcji B i odblokowanie tabeli 2, a transakcja B będzie na próżno czekać na zakończenie transakcji A i odblokowanie tabeli 1.

Sytuacje mogą być znacznie bardziej złożone. Liczba wzajemnie blokowanych transakcji może być znacznie wyższa. Każda transakcja nie może samodzielnie wykryć tej sytuacji. Musi na to pozwolić DBMS. Większość komercyjnych DBMS ma mechanizm wykrywania takich zakleszczeń.

Podstawą wykrywania zakleszczeń jest budowa (lub stałe utrzymanie) grafu oczekujących transakcji. Wykres oczekujący może być grafem skierowanym z nazwami transakcji na jego wierzchołkach. Jeśli transakcja T1 czeka na zakończenie transakcji T2, to strzałka przechodzi od T1 do T2. Dodatkowo strzałki mogą być opatrzone nazwami blokowanych obiektów oraz rodzajem blokowania.

Mechanizm implementacji blokady wykorzystuje koncepcję poziomu izolacji blokady, która określa, ile tabel zostanie zablokowanych. Tradycyjnie stosuje się trzy poziomy izolacji:

· Poziom izolacji o nazwie reread implementuje strategię, dzięki której w ramach danej transakcji nie można zmienić wszystkich rekordów pobranych przez zapytania. Tych rekordów nie można zmienić, dopóki transakcja nie zostanie zakończona.

· Poziom izolacji, zwany wskaźnikiem stabilności, uniemożliwia modyfikację każdego wpisu podczas jego odczytywania lub odczytywanie podczas modyfikowania.

· Trzeci poziom stabilności nazywa się tylko do odczytu. Tylko do odczytu blokuje całą tabelę i dlatego nie można jej używać z poleceniami aktualizacji. W ten sposób tylko do odczytu zapewnia, że dane wyjściowe zapytania są wewnętrznie spójne z danymi tabeli.

Tak więc kontrola współbieżności w DBMS określa, w jakim stopniu jednocześnie wydawane polecenia będą ze sobą kolidować. W nowoczesnym DBMS jest to narzędzie adaptowalne, które automatycznie znajduje optymalne rozwiązanie, biorąc pod uwagę maksymalną wydajność bazy danych oraz dostępność danych dla zespołów operacyjnych.

9. PYTANIA KONTROLNE

1. Zdefiniuj transakcję. Podaj przykłady transakcji.

2. Wymień i opisz właściwości transakcji.

3. Jakie są możliwe opcje realizacji transakcji.

4. Jakich operatorów językowych SQL służyć do pracy z transakcjami w rozszerzonym modelu transakcyjnym?

5. Czy można używać poleceń zarządzania transakcjami w wyzwalaczach?

6. Jaki jest cel dziennika transakcji?

7. W jakich przypadkach odzyskiwanie bazy danych odbywa się za pomocą dziennika transakcji?

8. Jakie są opcje rejestrowania transakcji?

9. Czym różnią się opcje rejestrowania transakcji: protokół z opóźnionymi aktualizacjami i protokół z natychmiastowymi aktualizacjami.

10. Jakie problemy pojawiają się, gdy użytkownicy pracują równolegle z bazą danych?

11. Jakie obiekty bazy danych można zablokować, aby wdrożyć zasadę izolacji użytkowników?

12. Czy można ustawić rodzaj blokowania w żądaniach?

13. Jakie rodzaje przechwytywania obiektów przez wiele transakcji istnieją? Które są kompatybilne?

14. Jaki jest problem impasu?

Istnieją różne modele transakcji, które można sklasyfikować na podstawie różnych właściwości, w tym struktury transakcji, współbieżności wewnątrz transakcji, czasu trwania itp.

V w tej chwili Wyróżniamy następujące rodzaje transakcji: transakcje płaskie lub klasyczne, transakcje łańcuchowe oraz transakcje zagnieżdżone.

Płaskie, czyli tradycyjne transakcje charakteryzują się czterema klasycznymi właściwościami: atomowością, spójnością, izolacją, trwałością (wytrzymałością) - KWAS (Atomowość, Konsystencja, Izolacja, Trwałość). Tradycyjne transakcje są czasami określane jako transakcje ACID. Wyżej wymienione właściwości oznaczają:

Właściwość atomowości (Atomity) wyraża się w fakcie, że transakcja musi zostać zakończona w całości lub wcale.

Właściwość Consistency zapewnia, że w miarę postępu transakcji dane przechodzą z jednego spójnego stanu do drugiego — transakcja nie narusza wzajemnej spójności danych.

Właściwość Isolation oznacza, że transakcje konkurujące o dostęp do bazy danych są fizycznie przetwarzane sekwencyjnie, odizolowane od siebie, ale użytkownikom wydaje się, że działają równolegle.

Właściwość Trwałość jest interpretowana w następujący sposób: jeśli transakcja zostanie zakończona pomyślnie, to dokonane przez nią zmiany danych nie mogą zostać utracone w żadnych okolicznościach (nawet w przypadku kolejnych błędów).

Istnieją dwie możliwości sfinalizowania transakcji. Jeśli wszystkie wyciągi zostaną zakończone pomyślnie i podczas transakcji nie wystąpiły żadne awarie oprogramowania ani sprzętu, transakcja zostaje zatwierdzona.

Zatwierdzenie transakcji to akcja, która zapisuje na dysku zmiany w bazie danych, które zostały wprowadzone podczas wykonywania transakcji.

Dopóki transakcja nie zostanie zatwierdzona, dopuszczalne jest cofnięcie tych zmian, przywrócenie bazy danych do stanu, w jakim była w momencie rozpoczęcia transakcji. Zawarcie transakcji oznacza, że wszystkie skutki transakcji stają się trwałe. Będą widoczne dla innych transakcji dopiero po zatwierdzeniu bieżącej transakcji. Do tego momentu wszystkie dane, których dotyczy transakcja, będą „widoczne” dla użytkownika w stanie z początku bieżącej transakcji.

Jeśli podczas realizacji transakcji wydarzy się coś, co uniemożliwi jej normalne zakończenie, bazę danych należy przywrócić do stanu pierwotnego. Wycofanie transakcji to działanie, które cofa wszystkie zmiany danych, które zostały wprowadzone przez instrukcje SQL w treści bieżącej oczekującej transakcji.

Każda instrukcja w transakcji wykonuje swoją część pracy, ale bezwarunkowe wypełnienie wszystkich ich instrukcji jest wymagane do pomyślnego zakończenia całej pracy jako całości. Wyrażenia grupujące w transakcji mówią SZBD, że cała grupa powinna być wykonywana jako pojedyncza jednostka i takie wykonanie powinno być obsługiwane automatycznie.

Standard ANSI/ISO SQL definiuje model transakcji i funkcje instrukcji COMMIT i ROLLBACK. Standard określa, że transakcja rozpoczyna się od pierwszej instrukcji SQL zainicjowanej przez użytkownika lub zawartej w programie, który się zmienia Stan aktulany Baza danych. Wszystkie kolejne instrukcje SQL tworzą treść transakcji. Transakcja kończy się jednym z czterech możliwe sposoby(Rys. 11.1):

oświadczenie COMMIT oznacza pomyślne zakończenie transakcji; jego użycie utrwala zmiany dokonane w bazie danych w ramach bieżącej transakcji;

instrukcja ROLLBACK przerywa transakcję, cofając zmiany wprowadzone w bazie danych w ramach tej transakcji; nowa transakcja rozpoczyna się natychmiast po użyciu ROLLBACK;

pomyślne zakończenie programu, w którym zainicjowano bieżącą transakcję, oznacza pomyślne zakończenie transakcji (tak jakby użyto instrukcji COMMIT);

błędne zakończenie programu przerywa transakcję (jak gdyby użyto instrukcji ROLLBACK).

W tym modelu każda instrukcja zmieniająca stan bazy danych jest traktowana jako transakcja, więc po pomyślnym wykonaniu tej instrukcji baza przechodzi do nowego stabilnego stanu.

Pierwsze wersje komercyjnych DBMS zaimplementowały model transakcji ANSI/ISO. Następnie w SYBASE DBMS wdrożono rozszerzony model transakcyjny, który obejmuje szereg dodatkowych operacji. Model SYBASE wykorzystuje następujące cztery instrukcje:

Instrukcja BEGIN TRANSACTION sygnalizuje rozpoczęcie transakcji. W przeciwieństwie do modelu w standardzie ANSI/ISO, w którym początek transakcji jest niejawnie ustawiany przez pierwszą instrukcję modyfikacji danych, w modelu SYBASE początek transakcji jest ustawiany jawnie przy użyciu początku instrukcji transakcji.

Instrukcja COMMIT TRANSACTION informuje o pomyślnym zakończeniu transakcji. Jest to odpowiednik instrukcji COMMIT w modelu ANSI/ISO. Ta instrukcja, podobnie jak instrukcja COMMIT, zatwierdza wszystkie zmiany wprowadzone w bazie danych podczas transakcji.

Instrukcja SAVE TRANSACTION tworzy punkt zapisu w transakcji, który odpowiada pośredniemu stanowi bazy danych zapisanej w czasie wykonywania instrukcji. Instrukcja SAVE TRANSACTION może zawierać nazwę punktu zapisu. Dlatego podczas wykonywania transakcji można zapisać kilka punktów zapisu odpowiadających kilku stanom pośrednim.

Instrukcja ROLLBACK ma dwie modyfikacje. Jeśli ta instrukcja jest używana bez dodatkowego parametru, jest interpretowana jako instrukcja wycofania dla całej transakcji, czyli w tym przypadku jest równoważna instrukcji wycofania ROLLBACK w modelu ANSI/ISO. Jeśli operator wycofania ma parametr i jest zapisany jako ROLLBACK B, jest interpretowany jako operator częściowego wycofania transakcji do punktu zapisu B.

Zasady realizacji transakcji w rozszerzonym modelu transakcyjnym przedstawiono na ryc. 11.2. Na rysunku operatorzy są oznaczeni numerami, aby wygodniej było nam śledzić przebieg transakcji we wszystkich dopuszczalnych przypadkach.

Transakcja rozpoczyna się jawnym operatorem rozpoczęcia transakcji, który w naszym schemacie ma numer 1. Następnie pojawia się operator 2, który jest operatorem wyszukiwania i nie zmienia aktualnego stanu bazy, a kolejne operatory 3 i 4 przenoszą bazę do nowy stan. Instrukcja 5 zapisuje ten nowy stan pośredni bazy danych i oznacza go jako stan pośredni w punkcie A. Następujące instrukcje 6 i 7 wprowadzają bazę danych do nowego stanu. A operator 8 przechowuje ten stan jako stan pośredni w punkcie B. Operator 9 wprowadza nowe dane, a operator 10 przeprowadza pewną weryfikację warunku 1; jeśli spełniony jest warunek 1, to wykonywana jest instrukcja 11, która cofa transakcję do stanu pośredniego B Oznacza to, że konsekwencje działań instrukcji 9 są jakby wymazane i baza danych powraca do stanu pośredniego B, chociaż po wykonaniu oświadczenie 9 był już w nowym stanie A po wycofaniu transakcji zamiast operatora 9, który był wcześniej wykonywany ze stanu W bazie danych wykonywany jest operator 13 do wprowadzenia nowych danych, a następnie kontrola przekazywana jest operatorowi 14 Operator 14 ponownie sprawdza warunek, ale już jakiś nowy warunek 2, jeśli warunek jest spełniony, to kontrola jest przekazywana operatorowi 15, który wycofuje transakcję do stanu pośredniego A, czyli wszystkich instrukcji, które zmieniły bazę danych, zaczynając od 6 i kończąc na 13, uważane są za niewykonane, to znaczy, że wyniki ich wykonania zniknęły i ponownie znajdujemy się w stanie A, tak jak po wykonaniu instrukcji 4 Następna kontrola jest przekazywana do operatora 17, który aktualizuje zawartość instrukcji baza danych, po której następuje kontrola Decyzja jest przekazywana do instrukcji 18, która jest związana ze sprawdzeniem warunku 3 Sprawdzenie kończy się albo przeniesieniem kontroli na instrukcję 20, która zatwierdza transakcję, a baza danych wchodzi w nowy stan stabilny i nie można go zmienić w ramach bieżąca transakcja Lub, jeżeli kontrola zostanie przekazana do instrukcji 19, to transakcja jest cofana do początku i baza wraca do stanu początkowego, a wszystkie stany pośrednie zostały już tutaj sprawdzone i nie można wykonać operacji cofnięcia do te stany pośrednie po wykonaniu instrukcji 19

Oczywiście rozszerzony model transakcji proponowany przez SYBASE wspiera znacznie bardziej elastyczny mechanizm realizacji transakcji możliwość cofnięcia zmiany dla niektórych operatorów Jednak nakłada to dodatkowe zasoby systemowe – operator wykonuje pracę, a zmiany są następnie odrzucane, zwykle ulepszenia w logika przetwarzania może być lepszym rozwiązaniem

Modele transakcji są klasyfikowane na podstawie różnych właściwości:

struktura transakcji;

współbieżność w ramach transakcji;

Trwanie.

Rodzaje transakcji:

1. Płaski (klasyczny)

2. Łańcuch

3. Zagnieżdżone

Transakcje mieszkań charakteryzują się 4 klasycznymi właściwościami:

atomowość;

konsystencja;

izolacja;

trwałość (wytrzymałość).

Czasami transakcje te nazywane są transakcjami ACID.

KWAS - Atomowość, Konsystencja, Izolacja, Trwałość.

Wyżej wymienione właściwości oznaczają:

Atomowość – wyraża się w tym, że transakcja musi być zrealizowana w całości lub w ogóle nie została zrealizowana.

Spójność - zapewnia, że w miarę realizacji transakcji dane przechodzą z jednego spójnego stanu do drugiego, czyli transakcja nie niszczy wzajemnej spójności danych.

Izolacja oznacza, że transakcje konkurujące o dostęp do bazy danych są fizycznie przetwarzane sekwencyjnie, odizolowane od siebie, ale dla użytkowników wygląda na to, że są wykonywane równolegle.

Trwałość - jeśli transakcja zakończy się sukcesem, to te zmiany danych, które zostały przez nią dokonane, nie mogą zostać utracone w żadnych okolicznościach.

Opcje realizacji transakcji:

1. Jeżeli wszystkie wyciągi zostały zakończone pomyślnie i podczas transakcji nie wystąpiły żadne awarie oprogramowania ani sprzętu, transakcja zostaje zatwierdzona.

Zatwierdzenie transakcji to akcja, która zapisuje na dysku zmiany w bazie danych, które zostały dokonane podczas wykonywania transakcji. Zatwierdzanie transakcji oznacza, że wszystkie skutki jej wykonania stają się trwałe i będą widoczne dla innych transakcji dopiero po zatwierdzeniu bieżącej transakcji.

2. Jeżeli podczas realizacji transakcji wydarzyło się coś, co uniemożliwia jej normalne zakończenie, bazę danych należy przywrócić do stanu pierwotnego.

Wycofanie transakcji to działanie, które cofa wszystkie zmiany danych, które zostały wprowadzone przez instrukcje SQL w treści bieżącej oczekującej transakcji. Każda instrukcja w transakcji wykonuje swoją część pracy, ale do pomyślnego zakończenia całej pracy jako całości wymagane jest bezwarunkowe wypełnienie wszystkich ich oświadczeń.

W standardzie ANSI/ISO SQL transakcja kończy się na jeden z 4 możliwych sposobów (rys. 1):

Ryż. 1. Model transakcji ANSI/ISO

1. Oświadczenie COMMIT oznacza pomyślne zakończenie transakcji; jego użycie utrwala zmiany dokonane w bazie danych w ramach bieżącej transakcji;

2. Instrukcja ROLLBACK przerywa transakcję, anulując zmiany dokonane w bazie danych w ramach tej transakcji; nowa transakcja rozpoczyna się natychmiast po użyciu ROLLBACK;

3. pomyślne zakończenie programu, w którym zainicjowano bieżącą transakcję, oznacza pomyślne zakończenie transakcji (tak jakby użyto instrukcji COMMIT);

4. błędne zakończenie programu przerywa transakcję (tak jakby użyto instrukcji ROLLBACK).

Dziennik transakcji ma na celu zapewnienie niezawodnego przechowywania danych w bazie danych. A ten wymóg implikuje w szczególności możliwość przywrócenia spójnego stanu bazy danych po wszelkiego rodzaju awariach sprzętu i oprogramowania. Oczywiście do wykonania przywracania potrzebne są dodatkowe informacje, które są utrzymywane w postaci dziennika zmian bazy danych zwanego dziennikiem transakcji.

Odzyskiwanie po ciężkiej awarii

Podstawą przywrócenia ostatniego spójnego stanu bazy danych po poważnej awarii jest log i kopia zapasowa bazy danych.

Przywracanie rozpoczyna się od skopiowania bazy danych z kopii zapasowej. Następnie wykonywane jest ponawianie dla wszystkich zakończonych transakcji, czyli operacje są ponownie wykonywane w kolejności bezpośredniej.

Równoległe wykonywanie transakcji

Jeżeli z bazą danych pracuje jednocześnie kilku użytkowników, to SZBD musi nie tylko poprawnie wykonywać poszczególne transakcje i przywracać spójny stan bazy po awariach, ale ma zapewnić poprawną równoległą pracę wszystkich użytkowników na tych samych danych . Teoretycznie każdy użytkownik i każda transakcja powinny mieć właściwość izolacji, czyli powinny być wykonywane tak, jakby z bazą danych pracował tylko jeden użytkownik. A narzędzia nowoczesnego DBMS pozwalają w ten sposób odizolować użytkowników od siebie. Jednak w tym przypadku pojawiają się problemy ze spowolnieniem doświadczenia użytkownika.

Każdorazowe użycie karty bankowej do zapłaty za towar, wypłata Pieniądze lub dokonywanie przelewów, niektóre transakcje realizuje klient banku. I choć wszystkie transakcje trwają tylko kilka minut, pełny cykl operacji to dość rozbudowany proces, który obejmuje wysyłanie żądań obciążenia pieniędzy, ich przetworzenie i wykonanie.

Transakcja to każda operacja dokonana kartą bankową, której wykonanie prowadzi do zmiany stanu rachunku klienta. Transakcja może być przeprowadzona w czasie rzeczywistym (online) oraz offline.

Transakcje internetowe wymagają obowiązkowego potwierdzenia płatności w momencie wpłaty lub przelewu środków.

Transakcje online obejmują Przelewy pieniężne między kartami, wypłaty gotówki w bankomatach, operacje rozliczeniowe w punktach detalicznych i sklepach. Rozważ proces dokonywania transakcji online na przykładzie płatności za towar w centrum handlowym.

W operację zaangażowane są trzy strony:

bank pozyskujący obsługujący wybraną placówkę (jego terminal POS jest zainstalowany w sklepie);
bank wydający obsługujący płatniczą kartę bankową;
międzynarodowy system płatniczy, który jest ogniwem pośrednim w prowadzeniu transakcji rozliczeniowych (Visa, MasterCard itp.).

Kolejność transakcji online

Transakcja rozliczeniowa rozpoczyna się w momencie przekazania karty płatniczej kasjerowi i odczytaniu przez terminal POS danych wymaganych do płatności (numer karty, okres ważności, nazwisko właściciela i inne informacje zaszyfrowane na taśmie magnetycznej). Odczytane informacje są przekazywane do banku przejmującego obsługującego terminal POS (z reguły sklepy zawierają specjalne umowy na obsługę terminali, zgodnie z którymi od każdej transakcji naliczane są prowizje).

Otrzymane dane są przesyłane przez bank przejmujący do centrum przetwarzania danych (DPC) międzynarodowego system płatności obsługujących kartę.

Centrum danych sprawdza obecność lub brak karty płatniczej na liście przystanków (lista przystanków może zawierać karty podejrzane o oszustwo), w wyniku czego operacja zostaje zatwierdzona lub odrzucona.

Następnie informacje są przekazywane do centrum przetwarzania banku wydającego, gdzie płatność jest zatwierdzana. Tutaj transakcja jest sprawdzana pod kątem legalności: sprawdzana jest dostępność wystarczającej ilości środków do sfinalizowania transakcji oraz sprawdzana jest zgodność wprowadzonego kodu PIN z rzeczywistą wartością. Sprawdza również pod kątem nadmiaru ustalony limit do wykonywania operacji.

Odpowiedź banku wydającego jest odsyłana przez centrum danych do banku przejmującego i sklepu. Szczegóły płatności są wyświetlane na czeku, który jest przekazywany kupującemu.

Funkcje operacji online i offline

Rozważane działania przy dokonywaniu transakcji online uzupełniają interakcję między kupującym a sklepem. Ale sama transakcja na tym się nie kończy. Faktem jest, że środki z karty nie są obciążane natychmiast: są tymczasowo blokowane. Środki przelewane są do sklepu z konta agenta rozliczeniowego i obciążane są z karty dopiero po przesłaniu przez bank przejmujący do wydawcy dokumentu finansowego w celu ich obciążenia. Może to nastąpić w ciągu kilku dni lub nawet miesiąca.

Transakcje offline realizowane są na innej zasadzie. Przechodzą bez czynności weryfikacyjnych przez stronę zdalną i zatwierdzenia lub odrzucenia. Transakcja jest z góry zatwierdzona, saldo środków na karta bankowa jest zastrzeżone, a wszystkie szczegóły płatności są przechowywane w pamięci terminala płatniczego.

Transakcja offline dokonywana jest później, gdy informacje zgromadzone w terminalu są przesyłane kanałami komunikacyjnymi do banku obsługującego. Co do zasady od momentu wezwania do realizacji płatności do momentu faktycznej zapłaty mija kilka dni.

Transakcje offline są stosowane w przypadkach, gdy nie ma możliwości nawiązania połączenia z centrum przetwarzania w czasie rzeczywistym (w samolotach, autobusach, taksówkach itp.).

Zakaz i anulowanie transakcji

Najczęstsze transakcje to płatności w sklepach, przelewy pieniężne i wypłaty gotówki. Istnieje kilka powodów, dla których transakcje mogą być zabronione.

Najczęstsze z nich:

karta bankowa została zablokowana;
na karcie bankowej nie ma wystarczających środków do zakończenia operacji;
karta płatnicza wprowadziła ograniczenia w dokonywaniu płatności;
karta płatnicza straciła ważność;
wystąpił błąd podczas wprowadzania kodu PIN;
karta bankowa znajduje się na liście stop w przypadku podejrzenia prania pieniędzy, oszustwa itp.;
występują problemy techniczne (na stronie, z bankomatem itp.).

Jeśli zakaz operacji nie jest związany z niewystarczającym saldem karty, musisz skontaktować się z bankiem obsługującym, aby rozwiązać problemy. W niektórych przypadkach transakcje można anulować z inicjatywy samych klientów (oczywiście, jeśli nie mówimy o wypłatach gotówki). Musisz także wiedzieć o możliwości anulowania transakcji, aby móc nieuczciwie zwrócić środki pobrane z karty.

Najprostszym sposobem jest anulowanie operacji w dniu, w którym została wykonana.