DELETE

DELETE to polecenie Transact-SQL usuwające wskazane wiersze z tabeli bazy danych.

Składnia i to, co dzieje się pod spodem

Podstawowa forma to DELETE FROM dbo.Zamowienia WHERE DataUtworzenia < '2020-01-01'. Silnik nie kasuje danych natychmiast z pliku — zapisuje operację w dzienniku transakcji, oznacza wiersze i zwalnia miejsce dopiero przy późniejszym porządkowaniu stron. Dlatego usunięcie miliona wierszy potrafi rozdąć plik LDF bardziej niż same dane zajmowały w MDF. Transact-SQL pozwala też usuwać na podstawie złączenia: DELETE z FROM tabela_docelowa INNER JOIN tabela_pomocnicza, co bywa szybsze od podzapytania z IN. Klauzula OUTPUT DELETED.* przechwytuje kasowane wiersze do tabeli archiwalnej w tej samej operacji, a TOP (5000) pozwala rozbić kasowanie na porcje. Bez transakcji jawnej każde DELETE jest transakcją samo w sobie i zatwierdza się natychmiast.

DELETE, TRUNCATE TABLE i DROP — trzy różne narzędzia

TRUNCATE TABLE usuwa całą zawartość, zwalniając od razu strony danych i zapisując w dzienniku znacznie mniej, przez co bywa o rzędy wielkości szybsze. Płaci się za to elastycznością: nie da się podać warunku WHERE, licznik IDENTITY wraca do wartości początkowej, operacja jest blokowana, gdy do tabeli prowadzi aktywny klucz obcy, i wymaga wyższych uprawnień niż zwykłe DELETE. DROP TABLE idzie dalej i likwiduje samą definicję razem z indeksami i wyzwalaczami. W bazach systemów handlowych praktycznie zawsze właściwym wyborem jest DELETE z warunkiem, bo tabele dokumentów są spięte relacjami z pozycjami, płatnościami i magazynem.

Błędy, zakleszczenia i dane skasowane bezpowrotnie

Komunikat o konflikcie z ograniczeniem REFERENCE oznacza, że w tabeli podrzędnej wciąż istnieją wiersze wskazujące na kasowany rekord — trzeba usunąć je wcześniej albo zdefiniować kaskadę przy kluczu obcym, czego w bazach ERP raczej się nie robi, bo kaskada potrafi wyczyścić pół dokumentacji. Przy dużych operacjach silnik eskaluje blokady wierszy do blokady całej tabeli, co unieruchamia pracowników w programie handlowym na czas kasowania; stąd zalecenie usuwania partiami w pętli sprawdzającej liczbę zmienionych wierszy. Najboleśniejsza pomyłka to uruchomienie polecenia bez zaznaczonej klauzuli WHERE w oknie edytora — zaznaczony fragment wykonuje się sam i czyści całą tabelę. Ratunkiem jest wyłącznie kopia zapasowa plus łańcuch kopii dziennika przy pełnym modelu odzyskiwania, który pozwala odtworzyć bazę do sekundy sprzed zdarzenia.

Ratowanie baz systemów handlowych po nieudanym czyszczeniu

Wdrażamy i serwisujemy oprogramowanie oparte o SQL Server — Subiekt, WAPRO i Comarch — i wezwania po nieostrożnym kasowaniu danych są w tej pracy stałym punktem. Odtwarzamy bazę z kopii na instancję pomocniczą, wyciągamy z niej brakujące dokumenty i wstawiamy je z powrotem do bazy produkcyjnej, nie ruszając tego, co pracownicy wprowadzili po awarii. Przy okazji zwykle okazuje się, że kopie w ogóle nie były robione albo model odzyskiwania stał na prostym, przez co dziennik nie pozwalał cofnąć się do konkretnej minuty — wtedy ustawiamy harmonogram kopii pełnych i różnicowych oraz kontrolę tego, czy plany konserwacji naprawdę się wykonują.