Procedura z instrukcją MERGE

Procedura z instrukcją MERGE łączy wstawianie, aktualizację i usuwanie względem tabeli źródłowej w jednym kroku.

Rola instrukcji MERGE w synchronizacji danych

Procedura z instrukcją MERGE służy do porównania danych źródłowych z tabelą docelową i wykonania odpowiedniej operacji zależnie od wyniku tego porównania. Dla rekordu, który ma odpowiednik w tabeli docelowej, może zostać wykonana aktualizacja. Dla rekordu obecnego w źródle, lecz nieobecnego w tabeli docelowej, można wykonać wstawienie. W niektórych implementacjach możliwe jest także usunięcie rekordu docelowego, gdy nie znajduje się on w zbiorze źródłowym.

Warunkiem wyboru operacji jest predykat dopasowania, zwykle oparty na kluczu głównym, kluczu unikatowym albo innym jednoznacznym identyfikatorze. Instrukcja MERGE nie porównuje tabel wyłącznie na podstawie podobieństwa całych wierszy. To warunek dopasowania określa, które rekordy są traktowane jako odpowiadające sobie. Jeżeli klucz dopasowania nie jest jednoznaczny, jeden rekord docelowy może zostać powiązany z wieloma rekordami źródłowymi, co może prowadzić do błędu albo niejednoznacznego wyniku.

Składniki procedury wykonującej MERGE

Typowa instrukcja MERGE określa tabelę docelową, zbiór źródłowy oraz warunek łączenia obu zbiorów. Następnie zawiera gałęzie opisujące działania dla rekordów dopasowanych i niedopasowanych. W gałęzi aktualizacji wskazuje się kolumny, które mają otrzymać wartości ze źródła. W gałęzi wstawiania określa się listę kolumn oraz wartości pobierane z nowego rekordu. Opcjonalna gałąź usuwania wymaga szczególnej ostrożności, ponieważ może zmienić zakres danych większy niż sama synchronizacja nowych i zmodyfikowanych wierszy.

Źródłem danych może być tabela, widok, podzapytanie albo wynik wcześniejszego przetwarzania, zależnie od konkretnego silnika bazy danych. Przed wykonaniem operacji trzeba sprawdzić zgodność typów danych, możliwość wystąpienia wartości NULL oraz ograniczenia tabeli docelowej. Wstawienie może zostać odrzucone przez klucz obcy, ograniczenie NOT NULL, ograniczenie UNIQUE albo wyzwalacz. Aktualizacja może natomiast naruszyć unikatowość, zmienić wartości używane do dalszego dopasowania lub uruchomić dodatkową logikę zdefiniowaną w bazie.

Spójność, duplikaty i obsługa błędów

MERGE powinno być wykonywane w transakcji, gdy kilka zmian musi zostać zatwierdzonych jako jeden logiczny zestaw. W razie błędu transakcję można wycofać, aby tabela docelowa nie pozostała w stanie częściowo zsynchronizowanym. Samo użycie jednej instrukcji nie gwarantuje jednak pełnej ochrony przed równoczesnymi modyfikacjami. Znaczenie mają poziom izolacji transakcji, blokady, sposób odczytu źródła oraz zasady współbieżności stosowane przez wybrany silnik.

Przed uruchomieniem procedury warto wykonać zapytania kontrolne wykrywające powtarzające się klucze w źródle, rekordy bez odpowiednika oraz wartości różniące się między tabelami. Należy również sprawdzić, czy warunek dopasowania używa tych samych reguł porównania dla tekstu, liczb i dat. Różnice w wielkości liter, sortowaniu, strefie czasowej albo precyzji części ułamkowej mogą spowodować potraktowanie dwóch logicznie równych wartości jako różnych. W przypadku dużych zbiorów trzeba ocenić plan wykonania, indeksy na kolumnach dopasowania oraz wpływ operacji na blokowanie innych zapytań.

Diagnostyka nieprawidłowego wyniku synchronizacji

Jeżeli MERGE nie aktualizuje oczekiwanych wierszy, pierwszym krokiem jest odtworzenie samego warunku dopasowania w zwykłym zapytaniu porównującym źródło z tabelą docelową. Pozwala to ustalić, czy problem wynika z danych, typu kolumn, wartości NULL, spacji lub odmiennej reguły porównywania. Gdy pojawiają się nieoczekiwane wstawienia, należy sprawdzić, czy klucz źródłowy rzeczywiście istnieje w tabeli docelowej oraz czy nie jest porównywany z niewłaściwą kolumną.

W diagnostyce przydatne jest zapisanie liczby rekordów przewidzianych do aktualizacji, wstawienia i usunięcia przed zatwierdzeniem transakcji. Należy także przejrzeć komunikaty błędów, logi aplikacji oraz historię zmian, o ile dany system ją prowadzi. Szczególnej uwagi wymagają procedury uruchamiane wielokrotnie: poprawnie zaprojektowana synchronizacja powinna być możliwie idempotentna, czyli ponowne wykonanie z tym samym źródłem nie powinno tworzyć kolejnych duplikatów ani zmieniać danych bez powodu. W środowisku roboczym naprawa problemu może obejmować analizę klienta bazodanowego, konfiguracji połączenia, skryptu procedury i samej tabeli, bez modyfikowania danych przed wykonaniem kopii lub uzgodnieniem zakresu zmian.