Transakcje DML

Transakcje DML obejmują operacje INSERT, UPDATE i DELETE modyfikujące zawartość tabel.

Transakcje DML – czym są i do czego służą

Transakcje DML to uporządkowane zestawy operacji wykonywanych na danych przechowywanych w relacyjnej bazie danych. Skrót DML pochodzi od określenia Data Manipulation Language i odnosi się do poleceń, które zmieniają zawartość tabel. Najczęściej wykorzystywane są instrukcje INSERT, UPDATE oraz DELETE. Dzięki nim można dodawać nowe rekordy, modyfikować informacje już zapisane i usuwać dane, które nie powinny dłużej znajdować się w tabeli.

Najważniejszą cechą transakcji jest traktowanie kilku powiązanych operacji jako jednego logicznego działania. Jeżeli proces obejmuje na przykład zmniejszenie stanu magazynowego oraz zapisanie informacji o sprzedaży, obie zmiany powinny zostać wykonane razem. W przypadku powodzenia można je zatwierdzić poleceniem COMMIT. Jeżeli wystąpi błąd, całość może zostać wycofana przez ROLLBACK. Pozwala to uniknąć sytuacji, w której tylko część operacji zostaje zapisana i dane przestają przedstawiać spójny obraz.

Samo polecenie DML nie musi jeszcze oznaczać pełnej transakcji obejmującej wiele tabel. W zależności od silnika bazy danych, ustawień połączenia i sposobu działania aplikacji pojedyncza instrukcja może być zatwierdzana automatycznie. Taki tryb nazywa się autocommit. Gdy wymagane jest świadome zarządzanie całym zestawem zmian, autocommit powinien zostać wyłączony albo zastąpiony kontrolowanym rozpoczęciem i zakończeniem transakcji.

Transakcje DML – kontekst techniczny i porównanie z innymi poleceniami

W praktyce warto odróżnić DML od innych grup poleceń SQL. DML służy do pracy na rekordach, natomiast DDL dotyczy struktury bazy, czyli tworzenia i zmieniania tabel, indeksów oraz ograniczeń. Do DDL zalicza się między innymi CREATE, ALTER i DROP. Osobną grupę stanowią polecenia związane z kontrolą transakcji, takie jak COMMIT, ROLLBACK oraz SAVEPOINT. Nie modyfikują one bezpośrednio rekordów, lecz decydują o tym, czy wykonane zmiany pozostaną trwałe.

W niektórych klasyfikacjach spotyka się także określenie DQL dla zapytań odczytujących dane, przede wszystkim SELECT, oraz DCL dla uprawnień, na przykład GRANT i REVOKE. Granice między tymi kategoriami mogą być opisywane nieco inaczej w zależności od dokumentacji, lecz z punktu widzenia codziennej pracy najważniejsze pozostaje rozróżnienie: DML zmienia rekordy, DDL zmienia strukturę, a COMMIT i ROLLBACK sterują losem zmian.

Transakcje DML są zwykle analizowane przez pryzmat właściwości ACID. Atomowość oznacza, że zestaw operacji jest traktowany jako całość. Spójność wymaga zachowania reguł określonych przez bazę, takich jak klucze główne, klucze obce i ograniczenia CHECK. Izolacja ogranicza wpływ jednocześnie wykonywanych transakcji na siebie. Trwałość oznacza, że po zatwierdzeniu dane powinny przetrwać zakończenie procesu, a nawet typowe awarie systemu, zgodnie z możliwościami danego silnika.

Istotną rolę odgrywają również blokady oraz poziomy izolacji. Przy pracy wielu użytkowników jedna transakcja może chwilowo blokować rekord lub zakres rekordów, aby zapobiec kolizji zmian. Zbyt niski poziom izolacji może prowadzić do odczytu danych niezatwierdzonych albo do powtarzania tego samego zapytania z innym wynikiem. Zbyt wysoki poziom izolacji zwiększa natomiast ryzyko oczekiwania na blokady. Dobór ustawień powinien uwzględniać charakter operacji i przewidywane obciążenie.

Transakcje DML – typowe problemy i błędy

Jednym z częstych problemów jest brak warunku WHERE przy UPDATE lub DELETE. W takiej sytuacji polecenie może zmienić albo usunąć wszystkie rekordy w tabeli. Bezpieczna praktyka polega na wcześniejszym wykonaniu zapytania SELECT z identycznym warunkiem, sprawdzeniu liczby pasujących wierszy, a dopiero potem zastosowaniu zmiany. W środowisku testowym można dodatkowo uruchomić operację w transakcji i zweryfikować wynik przed wykonaniem COMMIT.

Ryzykowne jest także zatwierdzanie każdej pojedynczej instrukcji w procesie, który powinien być atomowy. Przykładowo, jeśli najpierw zapisano zamówienie, a dopiero później pozycje zamówienia, awaria pomiędzy tymi krokami może pozostawić rekord nadrzędny bez kompletu danych. Lepszym rozwiązaniem jest objęcie całej sekwencji jedną transakcją oraz wycofanie wszystkich zmian, gdy dowolny etap zakończy się błędem.

Inny kłopot stanowią blokady utrzymywane zbyt długo. Długotrwała transakcja może zatrzymywać inne operacje, zwiększać czas odpowiedzi i prowadzić do zakleszczenia. Zakleszczenie występuje wtedy, gdy dwie transakcje czekają na zasoby zablokowane przez siebie nawzajem. Silnik zazwyczaj przerywa jedną z nich, lecz aplikacja powinna poprawnie obsłużyć taki przypadek i w razie potrzeby ponowić operację.

Problemy pojawiają się również przy częściowym przetwarzaniu dużych zestawów danych. Jedna ogromna transakcja może długo zajmować zasoby i rozbudowywać dziennik zmian. Z kolei zbyt małe partie mogą utrudniać odtworzenie procesu i zwiększać liczbę zatwierdzeń. Rozsądny podział zależy od rozmiaru tabel, indeksów, ograniczeń integralności oraz możliwości systemu. Szczególnej ostrożności wymagają operacje wykonywane na danych produkcyjnych, ponieważ ich skutków nie zawsze da się łatwo odwrócić.

Transakcje DML – praktyczne wskazówki bezpiecznej pracy

Przed wykonaniem modyfikacji warto jasno określić zakres danych, zależności między tabelami oraz oczekiwany wynik. Warunki w UPDATE i DELETE powinny być możliwie precyzyjne, a wartości wejściowe przekazywane jako parametry. Parametryzacja ogranicza ryzyko wstrzyknięcia SQL i pomaga uniknąć błędów wynikających z ręcznego składania poleceń z tekstu.

Każda transakcja powinna mieć czytelny początek, ścieżkę zatwierdzenia oraz obsługę błędu. W razie wyjątku należy wykonać ROLLBACK, a następnie zapisać informację diagnostyczną wystarczającą do ustalenia przyczyny. Nie powinno się ukrywać błędów przez automatyczne zatwierdzanie części operacji. W aplikacjach wielowarstwowych trzeba też kontrolować, czy połączenie z bazą nie jest zwalniane przed zatwierdzeniem albo wycofaniem zmian.

Przydatne bywa użycie SAVEPOINT. Punkt zapisu pozwala wycofać tylko fragment większej transakcji, bez anulowania wszystkich wcześniejszych działań. Należy jednak pamiętać, że nie zastępuje on prawidłowego projektu procesu. Im bardziej złożona jest logika, tym ważniejsze stają się jednoznaczne reguły kolejności operacji, kontrola liczby zmodyfikowanych rekordów i testy scenariuszy awaryjnych.

Przed wdrożeniem zmian wskazane jest wykonanie kopii zapasowej zgodnie z przyjętą procedurą, sprawdzenie planu zapytania i przetestowanie operacji na reprezentatywnym zbiorze danych. Warto również monitorować czas trwania transakcji, liczbę blokad oraz błędy integralności. Sama poprawność składni SQL nie gwarantuje bezpieczeństwa, ponieważ o skutkach decydują także uprawnienia, indeksy, relacje i sposób obsługi połączenia przez aplikację.

Transakcje DML – kiedy zgłosić się do serwisu

Pomoc serwisowa może być potrzebna, gdy po wykonaniu INSERT, UPDATE lub DELETE dane zniknęły, pojawiają się niespójności między tabelami, aplikacja nie kończy transakcji albo baza regularnie zgłasza zakleszczenia. Warto zgłosić problem także wtedy, gdy operacje, które wcześniej trwały krótko, zaczynają długo oczekiwać na blokady lub powodują znaczne spowolnienie programu. Do analizy przydatne są komunikaty błędów, fragment zapytania, informacja o momencie wystąpienia problemu oraz opis ostatnich zmian w aplikacji lub konfiguracji.

Przed przekazaniem środowiska do sprawdzenia nie powinno się wielokrotnie uruchamiać tych samych poleceń na żywych danych, zwłaszcza jeśli nie wiadomo, czy wcześniejsza transakcja została zatwierdzona. Bezpieczniej jest zachować kopię logów, ustalić aktualny status połączenia i ograniczyć kolejne modyfikacje do minimum. W przypadku problemów sprzętowych, systemowych lub z działaniem aplikacji analiza całego stanowiska może ułatwić ustalenie, czy przyczyną jest baza, program, nośnik danych czy konfiguracja komputera. W Warszawskim Pogotowiu Komputerowym 24/7 naprawy z reguły realizuje się do 3 dni roboczych, po wcześniejszym ustaleniu zakresu prac.