• Increase font size
  • Default font size
  • Decrease font size

Zarządzanie transakcjami w PostgreSQL

Krystian Matejczyk, Andrzej Kucper, Piotr Kulejewski, Michał Kwiatkowski, Andrzej Kwiatos

System realizujący program, oraz przetwarzający dane przechowywane pod kontrolą systemu zarządzania danymi realizuje proces złożony z pewnej liczby transakcji. Transakcja jest to spójny logicznie zestaw operacji wykonywanych na bazie danych (przykładowo zapisywanie zmian, wprowadzenie pojedynczych pozycji danych osobowych, czy odczytywanie zestawu danych). System gwarantuje, że wykonanie transakcji zakończy się prawidłowo. W przypadku pojawienia się awarii żadna zmiana wykonana przez transakcje nie będzie zachowana w bazie danych. W systemie bazy  danych jest wykonywanych wiele transakcji równocześnie. Współbieżnie odczytywane są i modyfikowane te same dane. Przykładowo w  kinie przy sprzedaży biletów z wielu okienek kasowych może nadejść prośba o rezerwację tego samego miejsca w tym samym rzędzie, wtedy może zdarzyć się sytuacja podczas , której jedno miejsce w  kinie będzie przyporządkowane wielu osobom.
Zarządzanie transakcjami współbieżnymi jest jednym z podstawowych czynników, które maja wpływ na efektywność i funkcjonalność systemu informatycznego. Głównym celem twórców jest wiarygodność systemu, znaczy to iż niezależnie od różnych konfliktów udostępnianie danych ma być rzetelne i bezpieczne. W celu zapewnienia integralności należy ograniczyć współbieżność, co ma wpływ na opóźnienia w realizacji transakcji, które muszą oczekiwać na zakończenie innych operacji wykonywanych na bazie danych. Dopuszczana jest więc możliwość osłabiania rygorów podczas wykonywania transakcji poprzez zmianę sposobu izolacji transakcji, tak aby nie dopuścić do brudnych odczytów i niespójności odczytu.
Wszyscy użytkownicy korzystający z baz danych, muszą być świadomi tego, ze ich polecenia skierowane do baz podlegają zasadom zarządzania transakcjami. Dlatego konieczna znajomość takiej składni języka SQL, która ma wpływ na współużytkowanie zbioru danych.

Przetwarzanie transakcji

Powszechnie stosowane jest pojęcie transakcji jako jednostki operowania na bazie danych, które podlegają sterowaniu i kontroli. Cel ten można osiągnąć za pomocą odpowiednich metod zarządzania transakcjami.

Transakcje

Do operacji które można w trakcie transakcji przeprowadzić na zbiorze danych należy: czytanie danej, zapisywanie, otwarcie transakcji, odrzucenie transakcji oraz zatwierdzenie. Ciągi operacji pomiędzy otwarciem a zatwierdzeniem bądź odrzuceniem powinien spełniać postulaty ACID - (atomowość, spójność, odizolowanie, trwałość) |Heider74,1,2|

Tranzycje

Tranzycją nazywamy zbiór czynności (poleceń: update, insert, itp.) powodujących przejście bazy danych z jednego określonego stanu w stan inny.

Poziomy izolacji i powstające problemy przy przetwarzaniu

Ważnym pojęciem z poziomu widzenia algorytmu szeregowania który zarządza transakcjami wykonywanymi w bazie danych jest wprowadzenie terminu poziomu konfliktowości operacji, którego zadaniem jest zdefiniowanie jaka operacja jest konfliktowa, a która bezpieczna.
Zastosowanie określonego poziomu izolacji powoduje różne problemy związane z jego implementacją. Niski poziom zapewnia zwiększenie współczynnika współbieżności (współbieżność - nie dopuszczanie do wzajemnej blokady poszczególnych transakcji lub do stanu niezgodnego BD) może doprowadzić do powstania niekorzystnych cech związanych z odtwarzalnością. Wybranie wysokiego poziomu powoduje nieuzasadnione opóźnienie transakcji.
W PostgreSql  8.1 możemy mówić o czterech poziomach izolacji:

  • Read ucnommited  brak izolacji, wszystkie zmiany, w tym tez te nie zatwierdzone widziane są, czyli transakcja odczytująca może odczytywać dane z błędem.
  • Read commited “ transakcja widzi tylko dane zatwierdzone. Nie jest to sytuacja komfortowa, ponieważ długa  transakcja będzie mogła odczytywać dane zmieniane w czasie jej trwania przez inne transakcje.
  • Repeatable read “ transakcja widzi zmiany zatwierdzone już po jej rozpoczęciu przez inne transakcje oraz ma zapewnioną powtarzalność odczytu, gwarantuje to te same wyniki przy każdym czytaniu.
  • Serializable “ rozwiązany jest tutaj problem pozornej niespójności innych zatwierdzonych transakcji. Stan bazy jest widoczny w momencie swego rozpoczęcia a zmiany wprowadzone przez inne transakcje w tym momencie są niewidoczne, czyli do dypozycji mamy zamrożony obraz bazy danych. Ten proces został nazwany szeregowalnym, można więc szeregować według czasu rozpoczęcia, nie ma znaczenia w jakiej kolejności transakcje zostały zatwierdzone. Poziom ten nastręcza bazom danych sporo kłopotów, może być realizowany na dwa sposoby. |3|

** można odwołać się do danych historycznych
** założyć blokadę

Przykłady

W pracy porównano dwa poziomy izolacji: read committed i read uncommitted ze względu na ich częste stosowanie. Pozostałe poziomy izolacji są rzadziej stosowane ze względu na mniejszą współbieżność transakcji, jak np. w przypadku repeatable read i mniejszą efektywność przetwarzania, jak w przypadku serializable.

Blokada izolacji read commited

Aby sytuacja taka nastąpiła w bazie danych konieczne jest wywołanie dwóch transakcji w tym samym czasie.
Przykładowo w bazie danych wywołujemy instrukcje:

begin transaction izolation level read committed


następnie wywołujemy modyfikacje poszczególnych rekordów w bazie:

update pracownicy set nazwisko="DUDA", data_ur="2000-05-23" where nr_prac="1";


a w tym samym czasie z innego terminalu wydane jest kolejne polecenie modyfikacji tego samego rekordu

update pracownicy set nazwisko="MYK", data_ur="2001-05-23" where nr_prac="1"(Tabela 1)


W takiej sytuacji do czasu zakończenia wykonania pierwszej transakcji, transakcja wywołana jako druga przechodzi w stan oczekiwania. Możliwość wykonania drugiej operacji nastąpi po zakończeniu wykonania pierwszej. Odczytanie danych nie jest możliwe, tabela jest zablokowana.

Transakcja 1
Transakcja 2
Uwagi
begin transaction izolation level read committed begin transaction izolation level read committed Instrukcja uruchomienia poziomu transakcji read committed na obu konsolach
update pracownicy set nazwisko="DUDA", data_ur="2000-05-23" where nr_prac="1"; Rozpoczęcie modyfikacji danych z konsoli pierwszej blokuje możliwość modyfikacji danych w bazie z innych konsoli
update pracownicy set nazwisko="MYK", data_ur="2001-05-23" where nr_prac="1"; Rozpoczęcie modyfikacji z innych konsoli, transakcja oczekuje na zakończenie wykonywania operacji wcześniej rozpoczętej
Commit; Zakończenie operacji na konsoli pierwszej następuje po użyciu polecenia
Select nazwisko from pracownicy where nazwisko ="DUDA"; Nie ma możliwości wykonania polecenia, baza jest zablokowan


Tabela 1. Modyfikacja bazy przy użyciu blokady izolacji read committed

Read uncommited

Aby sytuacja taka nastąpiła w bazie danych konieczne jest wywołanie dwóch transakcji w tym samym czasie. Przykładowo w bazie danych wywołujemy instrukcje:

begin transaction izolation level read uncommitted

następnie wywołujemy modyfikacje poszczególnych rekordów w bazie

update pracownicy set nazwisko="DUDA", data_ur="2000-05-23" where nr_prac="1";

a w tym samym czasie z innego terminalu (z innej sesji) wydane jest kolejne polecenie modyfikacji tego samego rekordu

update pracownicy set nazwisko="MYK", data_ur="2001-05-23" where nr_prac="1";

W sytuacji takiej do czasu zakończenia wykonania pierwszej transakcji, transakcja wywołana jako druga oczekuje. Możliwość wykonania drugiej operacji nastąpi po zakończeniu wykonania pierwszej transakcji. Odczytanie danych może nastąpić, nawet w przypadku, gdy odczytane dane są błędne lub nieaktualne.(Tabela 2)

Transakcja 1 Transakcja 2 Uwagi
begin transaction izolation level read committed begin transaction izolation level read committed Instrukcja uruchomienia poziomu transakcji read committed na obu konsolach
update pracownicy set nazwisko="DUDA", data_ur="2000-05-23" where nr_prac="1"; Rozpoczęcie modyfikacji danych z konsoli pierwszej blokuje możliwość modyfikacji danych w bazie z innych konsoli
update pracownicy set nazwisko="MYK", data_ur="2001-05-23" where nr_prac="1"; Rozpoczęcie modyfikacji z innych konsoli, transakcja oczekuje na zakończenie wykonywania operacji wcześniej rozpoczętej
Commit; Zakończenie operacji na konsoli pierwszej następuje po użyciu polecenia


Tabela 2. Modyfikacja bazy przy użyciu blokady izolacji read uncommitted

Podsumowanie

Zastosowanie różnych poziomów izolacji transakcji powoduje odmienne wyniki działania operacji. Przy zastosowaniu read committed baza jest blokowana, oraz następuje wstrzymanie odczytu z tabel, na których aktualnie trwają operacje, natomiast zaimplementowanie read uncommitted powoduje zablokowanie baz, ale odczytanie danych nadal jest możliwe, co wiąże się z niebezpieczeństwem odczytu nieprawidłowych lub nieaktualnych danych.
Porównanie obu poziomów izolacji potwierdza potrzebę stosowania w trakcie wykonywanych transakcji  read committed.

 

Bibliografia:

 

  1. Jim Grag, Andreas Reuter Transaction Proccesing: Councepts and Techniques Morgan Kaufman 1993
  2. Theo Harder ,Andreas Reuter Optimization of Loggging and recovery in a Database System IFIP TC-2 Working Conference on Data Base Architectire 1997 139-156
 

Naszą witrynę przegląda teraz 47 gości