Transakcje Pojęcie transakcji Pojęcie transakcji stało się centralnym elementem w wielu współczesnych zastosowaniach baz danych. Jest kluczowym pojęciem pozwalającym zrozumieć zarówno kontrolę wielodostępu, jak i pojęcia odtwarzalności bazy danych. Transakcja jest to wykonywany program lub proces, na który składa się jeden lub więcej operacji dostępu do danych (takich jak np. odczytywanie danych, aktualizacja danych, itp.). Transakcja jest logiczną jednostką pracy w bazie danych. Transakcja może składać się z: pojedynczej operacji wykonywanej na bazie danych (np. polecenia wstawienia nowego rekordu danych poleceniem INSERT), dowolnej liczby operacji wykonywanych na bazie danych, całego programu aplikacji (dotyczącego działań wykonywanych w bazie) lub pewnej jego części. Uwaga. Z punktu widzenia bazy danych, wykonanie programu aplikacji można uważać za ciąg transakcji przeplatanych operacjami nie związanymi z bazą danych. Przykłady transakcji Przykład 1. Przykładem prostej transakcji w rozważanym przykładzie sprzedaży produktów w hurtowni może być podwyżka ceny jednostkowej o 5% produktu o wskazanym numerze. W języku abstrakcyjnym możemy ją zapisać w postaci READ(nrproduktu = X, cenajednostkowa) nowa_cenajednostkowa = cenajednostkowa*1,05 WRITE(nrproduktu = X, nowa_cenajednostkowa) gdzie: READ(X) odczyt jednostki danych X, WRITE(X) zapis jednostki danych X, READ(nrproduktu = X, cena jednostkowa) oznacza odczyt atrybutu cenajednostkowa krotki o wartości klucza głównego równej X. W rozważanym przypadku mamy do czynienia z transakcją składającą się z dwóch instrukcji dostępu do bazy danych (READ i WRITE), oraz instrukcji operacyjnej, czyli nie wykonywanej na bazie danych, tj. instrukcji nowa_cenajednostkowa = cenajednostkowa*1,05 Przykład 2. Przykładem nieco bardziej skomplikowanej transakcji w rozważanym przykładzie sprzedaży produktów w hurtowni może być usunięcie klienta o wskazanym numerze X. delete(kod_klienta = X) for all Zamówienia records, nrzam begin READ(nr_zamówienia = nrzam, kod_klienta) 1
if(kod_klienta = X) then begin for all Opisy_zamówień records begin READ(nr_zamówienia = nrzam, nr_zamówienia) DELETE(nr_zamówienia) end DELETE(nr_zamówienia = nrzam) end end W rozważanym przypadku, oprócz usunięcia krotki relacji Klienci, musimy także odnaleźć wszystkie krotki relacji Zamówienia, które zawierają zamówienia złożone przez danego klienta, aby je usunąć z tej relacji. Ale, aby usunąć krotki relacji Zamówienia, musimy najpierw usunąć krotki relacji Opisy_zamówień, które opisują zamówienia złożone przez klienta przeznaczonego do usunięcia. Własności transakcji Gdybyśmy nie wykonali powyższych modyfikacji, to wtedy baza danych utraciłaby integralność referencyjną i znalazłaby się w stanie niespójnym zawierałaby zamówienia, które nie byłyby przypisane żadnemu klientowi oraz zawierałaby opisy zamówień, których już nie byłoby w bazie. Transakcja powinna zawsze przeprowadzać bazę danych ze stanu spójnego w stan spójny, choć w trakcie jej trwania dopuszczalna jest możliwość naruszenia spójności. Przykładowo, rozważmy przypadek gdy któryś z pracowników zachoruje i wszystkie rozpoczęte przez niego zamówienia, a jeszcze niezakończone musi przejąć inny pracownik. Wówczas podczas wykonywania transakcji dotyczącej realizacji tej sytuacji może wystąpić moment, gdy jedna krotka relacji Zamówienia nową wartość kodu_pracownika, a druga nadal starą wartość kodu_pracownika. Jednak po zakończeniu transakcji, wszystkie krotki, których dotyczy modyfikacja w ramach tej transakcji, powinny mieć wpisaną nową wartość kodu_pracownika Rodzaje transakcji w oparciu o ich wynik Transakcja może zakończyć się na jeden z dwóch sposobów i związku z tym mówimy, że: transakcja została zatwierdzona, inaczej wypełniona (ang. commited) jeśli transakcja zakończy się sukcesem, transakcja została odrzucona (ang. aborted), inaczej wycofana (ang. rolled back) jeśli transakcja nie może być wykonana do końca z powodzeniem. Transakcji wypełnionej nie wolno wycofywać. W przypadku stwierdzenia, iż wykonanie transakcji było błędem, należy wykonać inną transakcję, tzw. transakcję kompensacyjną, która pozwoli odwrócić efekty błędnej transakcji. Transakcję wycofaną można powtórnie uruchamiać, i w zależności od powodu wycofania za pierwszym razem, za drugim uruchomieniem może udać się jej wykonanie do samego końca. 2
SZBD a określenie transakcji SZBD samodzielnie nie posiada możliwości określenia, które operacje powinny częścią składową jednej logicznej transakcji. Z tego powodu to sam użytkownik musi być wyposażony w sposób określania granic transakcji. W języku SQL istnieją następujące instrukcje dotyczące działań na transakcjach: BEGIN TRANSACTION inicjowanie nowej transakcji, COMMIT kończenie transakcji przez zatwierdzenie wszystkich działań wykonanych podczas transakcji, ROLLBACK kończenie transakcji przez wycofanie wszystkich działań wykonanych podczas transakcji. Uwaga. Jeśli w programie nie występują powyższe instrukcje, to zazwyczaj traktuje się go jako pojedynczą transakcję i w takim przypadku automatycznie jest wykonywana przez system operacja zatwierdzania COMMIT, gdy kończy się ona powodzeniem, natomiast w przypadku przeciwnym, automatycznie jest wykonywana operacja wycofania ROLLBACK. Wielodostęp w bazach danych Zasadniczy sposób wykorzystania baz danych polega na umożliwieniu wielu użytkownikom jednoczesnego dostępu do baz danych. Jak wskazuje sama nazwa, wielodostępny system zarządzania bazą danych umożliwia wielu użytkownikom jednoczesny dostęp do bazy danych. Ta właściwość ma znaczenie, jeśli z pojedynczą bazą danych chcemy zintegrować wiele aplikacji. System zarządzania bazą danych musi zawierać wtedy oprogramowanie sterowania współbieżnego (ang. concurrency control). Jedną z jego podstawowych własności jest zapewnienie wielu użytkownikom w kontrolowany sposób możliwość podejmowania prób aktualizacji tych samych danych oraz zagwarantowanie, iż efekt tych działań nie spowoduje niespójności bazy danych. Przykładowo, jeśli wiele biur podróży spowoduje jednocześnie zarezerwować miejsce na wycieczce dla swoich klientów, system zarządzania bazą danych powinien zagwarantować dostępność każdego miejsca (np. w wycieczkowym autobusie) tylko dla jednego klienta obsługiwanego przez jedno z biur. Tego typu zastosowania są określane ogólnym mianem rozwiązań z przetwarzaniem transakcji na bieżąco ( ang. Online Transaction Processing OLTP). Własności transakcji SZBD jest zaopatrzony w pewien mechanizm, który wymusza wiele własności transakcji (właściwie to za zagwarantowanie poszczególnych własności transakcji są odpowiedzialne wyodrębnione składniki SZBD). Transakcja, którą można traktować jako zespół operacji wykonywanych na bazie danych (SELECT, INSERT, UPDATE, DELETE ), charakteryzuje się następującymi własnościami: niepodzielność (atomicity) spójność stanu (consistency) wyłączność (isolation) trwałość (durability) szeregowalność (serializability) własność niepodzielności (atomowość) (ang. atomicity) gwarantuje, iż albo wszystkie operacje przeprowadzane na danych przechowywanych w bazie danych w ramach pojedynczej transakcji zostaną 3
wykonane, albo żadna z nich nie zostanie przeprowadzona za zapewnienie tej własności odpowiada system odtwarzania SZBD. własność spójności (ang. consistency) gwarantuje, iż każda transakcja musi przekształcać bazę danych z jednego stanu spójnego w inny stan spójny zapewnienie tej własności leży zarówno po stronie SZBD, jak i po stronie użytkownika. własność izolacji (wyłączności) (ang. isolation) gwarantuje, iż każda transakcja zostanie wykonana w ten sposób, iż będzie odseparowana od pozostałych transakcji. własność trwałości (ang. durability) gwarantuje, iż rezultaty zakończonej z powodzeniem transakcji są na trwale zapisane w bazie danych i nie mogą być utracone w wyniku jakiegoś późniejszej awarii za zapewnienie tej własności odpowiada podsystem odtwarzania SZBD. własność szeregowalności (ang. serializability) efekt wykonania kilku transakcji jednocześnie (z przełączaniem zadań) musi być równoważny oddzielnemu wykonaniu każdej z nich w pewnej ustalonej kolejności. Wówczas transakcje takie nazywamy szeregowalnymi. Stan spójny bazy danych Stan spójny (consistent state) bazy danych spełnia więzy określone w jej schemacie, jak również wszelkie inne więzy, które powinny być zachowane. Można w pewnym uproszczeniu powiedzieć także, iż stan spójny bazy danych to stan, w którym wszelkie istniejące powiązania pomiędzy obiektami tworzą logiczną całość tzn. np. nie ma odwołań do obiektów nie istniejących w bazie. Z tego punktu widzenia program bazodanowy powinien być zatem napisany w sposób gwarantujący, iż jeżeli baza danych znajduje się w stanie spójnym przed wykonaniem transakcji, to będzie również w stanie spójnym po zakończeniu wykonywania transakcji, przy założeniu, iż nie występują żadne kolizje z innym transakcjami. Przyczyny powodujące załamanie procesu wykonania transakcji błędy systemu komputerowego (system crash) awarie związane z oprogramowaniem lub sprzętem, zaistniałe podczas wykonywania transakcji; prawie zawsze związane są z utratą zawartości pamięci operacyjnej komputera. błędy transakcji lub systemu zarządzania baza danych (SZBD) załamanie wykonania może być spowodowane np. próbą wykonania przez transakcję operacji dzielenia przez zero, przekroczeniem zakresu typu danych, niewłaściwą wartością parametru lub poleceniem BREAK wydanym przez operatora. błędy lokalne i wyjątki wykryte przez transakcje przykładem okoliczności zmuszających do przerwania transakcji jest np. w bankowej bazie danych, niewystarczający stan konta, uniemożliwiający wykonanie operacji przelewu pieniędzy. Transakcja sama powinna obsłużyć sytuację, wykonując operację ABORT. awarie dysku błędy zapisu lub odczytu danych z powierzchni dyskowych podczas wykonywania transakcji. kontrola współbieżności procesy bazy odpowiedzialne za kontrolę dostępu równoległego mogą zadecydować o konieczności przerwania transakcji i jej późniejszym restarcie; przyczyną może być niespełnienie warunku szeregowalności czy też wykrycie stanu zakleszczenia. przyczyny zewnętrzne wynikające z zaniku napięcia, przypadkowego lub celowego zamazania danych przez operatora, pożaru, powodzi, kradzieży, itp. 4
Podstawowe operacje należące do transakcji Aby wyjaśnić pojęcia dotyczące przetwarzania transakcji w bazach danych, przyjmuje się pewien uproszczony model bazy danych, w którym baza danych jest zasadniczo reprezentowana jako zbiór nazwanych elementów danych (mogą nimi być pole, rekord, a nawet cały blok dyskowy). W przypadku wykorzystania uproszczonego modelu bazy danych za podstawowe operacje dostępu do bazy danych przyjmuje się: READ(X) odczytuje element bazy danych o nazwie X do zmiennej programowej (w celu uproszczenia przyjętej notacji zakłada się, iż zmienna programowa również nosi nazwę X; WRITE(X) zapisuje wartość zmiennej programowej X w elemencie bazy danych o nazwie X. Omówione teraz zostaną problemy, z jakimi mamy do czynienia w przypadku wykonywania transakcji w sposób niekontrolowany. Problem utraconej aktualizacji Problem utraconej aktualizacji występuje w przypadku, gdy dwie transakcje uzyskujące dostęp do tych samych elementów bazy danych są związane z przeplotem ich operacji w taki sposób, iż wartości pewnych elementów bazy danych stają się błędne. Przykład. Rozpatrzmy przykład dwóch transakcji, dla których podczas ich wykonania mamy do czynienia z problemem utraconej aktualizacji. Problem aktualizacji tymczasowej Problem aktualizacji tymczasowej występuje w przypadku, gdy jedna transakcja aktualizuje element bazy danych, a następnie transakcja ta z pewnego powodu kończy się niepowodzeniem. Jest on konsekwencją tego, iż do zaktualizowanego elementu dostęp uzyskuje inna transakcja, zanim zostanie on zmieniony na swoją oryginalną wartość. Przykład. Rozpatrzmy przykład dwóch transakcji, dla których podczas ich wykonania mamy do czynienia z problemem aktualizacji tymczasowej. 5
Problem błędnej sumy Problem błędnej sumy występuje w przypadku, gdy jedna transakcja oblicza wartość funkcji agregującej podsumowania na wielu rekordach, podczas gdy inna transakcja aktualizuje niektóre z tych rekordów. W takim przypadku funkcja agregująca może uwzględnić w obliczeniach pewne wartości przed ich aktualizacją, a inne już po ich zaktualizowaniu. Przykład. Rozpatrzmy przykład dwóch transakcji, dla których podczas ich wykonania mamy do czynienia z problemem błędnej sumy. Problem odczytu niepowtarzalnego Problem odczytu niepowtarzalnego (unrepeatable READ) występuje w przypadku, gdy jedna transakcja T 1 odczytuje element dwukrotnie, przy czym element ten zostaje zmieniony przez inną transakcję T 2 pomiędzy tymi dwoma odczytami transakcji T 1. Przykład. Rozpatrzmy przykład dwóch transakcji, dla których podczas ich wykonania mamy do czynienia z problemem odczytu niepowtarzalnego. Harmonogram Kolejność wykonywania operacji związanych (blokowanie, odczyt, zapis, itp.) z różnymi transakcjami w przypadku, gdy transakcje są wykonywane współbieżnie w technice przeplotu określa się mianem harmonogramu (schedule) zbioru transakcji (w skrócie, hamonogramem) albo historii. Harmonogram S, inaczej historia, zbioru n transakcji T 1, T 2,, T n jest uporządkowaniem operacji transakcji podlegającym ograniczeniu, które określa, że dla każdej transakcji T i należącej do harmonogramu S, operacje tej transakcji w S muszą występować w tej samej kolejności, w jakiej występują w T i. Należy jednak podkreślić fakt, iż operacje związane z innymi transakcjami T j mogą się przeplatać z operacjami transakcji T i. 6
Operacje konfliktowe Lp. T 1 T 2 1. READ(X) 2. READ(X) 3. X = X 100 4. WRITE(X) 5. X = X + 100 6. WRITE(X) Mówimy, iż dwie operacje w harmonogramie są w stanie konfliktu, gdy spełniają następujące trzy warunki: należą do różnych transakcji, uzyskują dostęp do tego samego elementu X, przynajmniej jedna z operacji jest operacją WRITE(X). Przykład. Rozpatrzmy harmonogram w skróconej notacji opisu rozpatrzony na slajdzie dotyczącym przedstawienia problemu utraconej aktualizacji: S: READ 1 (X); READ 2 (X); WRITE 1 (X); READ 1 (Y); WRITE 2 (X); WRITE 1 (Y); Przykładowo, w harmonogramie S operacje READ 1 (X) oraz WRITE 2 (X) są w konflikcie, podobnie jak operacje READ 2 (X) i WRITE 1 (X), a także operacje WRITE 1 (X) i WRITE 2 (X). Natomiast operacje READ 1 (X) i READ 2 (X) nie są w konflikcie, ponieważ obie są operacjami odczytu. Także i operacje WRITE 2 (X) i WRITE 1 (Y) nie są w konflikcie, gdyż operują na odrębnych elementach bazy danych. Z kolei operacje READ 1 (X) i WRITE 1 (X) nie są w konflikcie, gdyż stanowią część składowej tej samej transakcji. Harmonogram sekwencyjny i szeregowalny Definicja. Harmonogram zbioru transakcji nazywamy sekwencyjnym (serial), jeśli wszystkie operacje każdej transakcji występują kolejno po sobie. Lp. T 1 T 2 1. READ(X) 2. X = X 100 3. WRITE(X) 4. READ(X) 5. X = X + 100 6. WRITE(X) Definicja. Harmonogram transakcji nazywamy szeregowalnym (seriazable), jeśli jego wynik jest równoważny wynikowi otrzymanemu za pomocą pewnego harmonogramu sekwencyjnego. Przykład ilustrujący różne typy harmonogramów Przykład. W poniższym przykładzie zilustrujemy różnice pomiędzy różnymi typami harmonogramów. W tym celu rozważmy dwie transakcje przelewu pewnych kwot pieniężnych z konta na konto. T 1 : READ(A), A = A - 100, WRITE(A); READ(B), B = B + 100, WRITE(B); T 2 : READ(B), B = B - 200, WRITE(B); READ(C), C = C + 200, WRITE(C); każdy harmonogram sekwencyjny powyższych transakcji ma własność zachowania sumy, tj. A + B + C; 7
przestawienia kolejności wykonywania pojedynczych operacji wewnątrz transakcji mogą doprowadzić do stworzenia następujących harmonogramów: niesekwencyjnych, ale szeregowalnych (sytuacja pożądana); albo nieszeregowalnych (sytuacja niepożądana). Przykład harmonogramu sekwencyjnego Przykład harmonogramu szeregowalnego, niesekwencyjnego Przykład harmonogramu nieszeregowalnego 8