Wykłady z przedmiotu Podstawy baz danych Transakcje dr hab. prof. nadzw. Tadeusz Antczak. Transakcje

Transkrypt

1 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. Podstawowe operacje dostępu do danych należące do transakcji Baza danych jest zasadniczo reprezentowana jako zbiór nazwanych elementów danych. Rozmiar elementu danych określa się mianem ziarnistości (ang. granularity), a wśród typów elementów danych wyróżniamy: pole rekordu, rekord, blok dyskowy. Należy podkreślić, iż omawiane zagadnienia są niezależne od ziarnistości elementów danych. Przy pewnym uproszczeniu modelu bazy danych podstawowymi operacjami dostępu do danych, które mogą należeć do transakcji są: READ(X) odczytuje element bazy danych o nazwie X do zmiennej programowej, przy czym w celu uproszczenia zapisu przyjmujemy, że zmienna programowa ma tę samą nazwę co element, WRITE(X) zapisuje wartość zmiennej programowej X w elemencie bazy danych o nazwie X. Wykonanie polecenia READ(X) wiąże się z wykonaniem poniższych działań: 1) Znalezienie adresu bloku dyskowego, który zawiera element X. 2) Skopiowanie bloku dyskowego do bufora w pamięci głównej (o ile blok ten nie znajduje się już w którymś z buforów pamięci głównej). Skopiowanie elementu X z bufora do zmiennej programowej o nazwie X. Wykonanie polecenia WRITE(X) wiąże się z wykonaniem poniższych działań: 1) Znalezienie adresu bloku dyskowego, który zawiera element X. 2) Skopiowanie tego bloku dyskowego do bufora w pamięci głównej (o ile blok ten nie znajduje się już w którymś z buforów pamięci głównej). 3) Skopiowanie elementu X ze zmiennej programowej o nazwie X do odpowiedniej lokalizacji w buforze. 1

2 4) Przeniesienie zaktualizowanego bloku bufora z powrotem na dysk (od razu lub z pewnym opóźnieniem). Uwaga. Etap 4) jest tym, w którym dokonuje się faktyczna aktualizacja bazy danych na dysku. 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(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) 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. 2

3 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. Stany wykonania transakcji Diagram przejść stanów ilustrujący stany związane z wykonywaniem transakcji Transakcja przechodzi do stanu aktywnego (ang. active state) tuż po rozpoczęciu wykonania i wtedy mogą być wykonywane operacje ODCZYTAJ i ZAPISZ. W momencie kończenia transakcji przechodzi ona do stanu zatwierdzenia częściowego (ang. partially committed state). Po pomyślnym sprawdzeniu przez protokół zatwierdzania, o transakcji mówi się, iż osiągnęła swój punkt zatwierdzenia i przechodzi ona do stanu zatwierdzenia (ang. committed state). Po zatwierdzeniu transakcji jej wykonywanie jest zakończone i wszelkie wprowadzone zmiany muszą zostać trwale zapisane w bazie danych. Transakcja może także przejść do stanu awaryjnego (ang. failed state), jeżeli jedno ze sprawdzeń zakończy się niepowodzeniem lub transakcja zostanie anulowana w stanie aktywnym. Transakcja może wtedy zostać wycofana w celu anulowania efektów związanych z wykonanymi operacjami ZAPISZ na bazie danych. Stan zakończenia (ang. terminated state) odpowiada sytuacji, gdy transakcja opuszcza system. 3

4 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ą 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 4

5 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 szereg owalnoś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. Dziennik systemowy System przechowuje tzw. dziennik (ang. log) w celu umożliwienia odtwarzania stanu bazy danych po awariach mających wpływ na transakcje i przy jego pomocy śledzi wszystkie operacje związane z transakcjami, które mają wpływ na wartości elementów bazy danych. Dziennik jest przechowywany na dysku, a zatem nie mają na niego wpływu żadne awarie, oprócz dyskowych lub katastroficznych. Omówione teraz zostaną problemy, z jakimi mamy do czynienia w przypadku wykonywania transakcji w sposób niekontrolowany. 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. problemem utraconej aktualizacji. 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ść. problemem aktualizacji tymczasowej. 5

6 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. problemem błędnej sumy. Problem odczytu niepowtarzalnego (unrepeatable READ) występuje w przypadku, gdy jedna transakcja T1 odczytuje element dwukrotnie, przy czym element ten zostaje zmieniony przez inną transakcję T2 pomiędzy tymi dwoma odczytami transakcji T1. problemem odczytu niepowtarzalnego. 6