Konflikty typów danych w replikacji

Konflikty typów danych w replikacji to błąd wynikający z niezgodności definicji kolumn między wydawcą a subskrybentem.

Na czym polega konflikt typów danych w replikacji

Konflikt typów danych w replikacji występuje wtedy, gdy kolumna po stronie wydawcy i odpowiadająca jej kolumna po stronie subskrybenta mają definicje, których nie można bezpiecznie uznać za zgodne. Replikowane dane są wtedy pobierane z tabeli źródłowej, przekształcane do postaci wymaganej przez mechanizm transportu, a następnie zapisywane w tabeli docelowej. Jeżeli typ docelowy nie potrafi przechować wartości ze źródła albo wymaga innego sposobu konwersji, zastosowanie zmiany może zakończyć się błędem.

Niezgodność nie musi oznaczać wyłącznie różnych nazw typów. Problem może wynikać także z odmiennej precyzji liczby, innej skali części dziesiętnej, krótszego limitu długości tekstu, różnego sposobu przechowywania daty i czasu, niezgodności kodowania znaków albo innego dopuszczania wartości pustych. Przykładowo kolumna tekstowa o większym limicie długości po stronie wydawcy może przekazywać wartość, której nie da się zapisać w krótszej kolumnie subskrybenta. Podobnie liczba dziesiętna może utracić część ułamkową, jeśli definicja docelowa ma mniejszą skalę.

Jak schemat tabel wpływa na zastosowanie zmian

Replikacja wymaga zgodności nie tylko danych, lecz także mapowania obiektów, kolumn i operacji wykonywanych na rekordach. Gdy zmiana dotyczy wiersza, mechanizm musi wiedzieć, do której kolumny docelowej przekazać każdą wartość oraz jak ją zinterpretować. Dodatkowe kolumny po stronie subskrybenta mogą być dopuszczalne, jeśli mają wartości domyślne albo mogą pozostać puste, lecz brak kolumny wymaganej przez tabelę docelową może uniemożliwić zapis. Również zmiana kolejności kolumn nie powinna być traktowana jako bezpieczna, jeżeli konfiguracja mapowania opiera się na pozycji zamiast na jednoznacznej nazwie.

Szczególnej uwagi wymagają typy logiczne, binarne, identyfikatory oraz daty. Wartość logiczna może być reprezentowana jako liczba albo jako typ przeznaczony dla wartości prawda/fałsz, a niejawna konwersja między tymi reprezentacjami może zależeć od użytego mechanizmu. Dane binarne nie powinny być automatycznie traktowane jak tekst, ponieważ zmiana kodowania może uszkodzić zawartość. W przypadku identyfikatorów trzeba sprawdzić zakres wartości, format oraz sposób generowania kluczy. Przy datach i godzinach należy uwzględnić między innymi obecność informacji o strefie czasowej oraz dokładność zapisu ułamków sekund.

Rozpoznawanie źródła niezgodności

Diagnozę należy rozpocząć od porównania definicji obu tabel, a nie od ponownego uruchamiania procesu replikacji. Dla każdej replikowanej kolumny trzeba zestawić nazwę, typ, długość, precyzję, skalę, dopuszczalność wartości pustych, wartość domyślną oraz sposób mapowania. Następnie warto sprawdzić rzeczywiste wartości oczekujące na przekazanie, ponieważ sama zgodność deklarowanych typów nie wyklucza błędu wynikającego z ograniczenia długości lub zakresu. Istotne jest także ustalenie, czy problem dotyczy pojedynczego rekordu, całej kolumny, czy zmian schematu wykonanych po utworzeniu konfiguracji replikacji.

Objawem konfliktu może być zatrzymanie kolejki zmian, odrzucenie konkretnej operacji, komunikat o nieudanej konwersji albo powtarzające się próby zastosowania tego samego rekordu. Należy odróżnić błąd typu danych od błędu wartości: tekst zawierający znaki nienależące do oczekiwanego formatu daty może być odrzucony mimo tego, że obie kolumny mają typ daty, a liczba poza zakresem typu docelowego może nie zostać zapisana mimo formalnej zgodności kategorii numerycznej. Przydatne jest ustalenie identyfikatora zmiany, czasu jej utworzenia i kolejności operacji, ponieważ wcześniejsza nieudana zmiana może blokować późniejsze rekordy.

Bezpieczne przywracanie zgodności definicji

Naprawa polega na doprowadzeniu schematu i danych do jednoznacznej zgodności, przy zachowaniu kontroli nad możliwą utratą informacji. Jeżeli kolumna docelowa jest zbyt krótka, samo zwiększenie jej limitu może rozwiązać problem, ale przed zmianą trzeba sprawdzić zależności, indeksy, ograniczenia i aplikacje korzystające z tabeli. Jeżeli różnica dotyczy precyzji liczbowej, należy ustalić, czy rozszerzenie zakresu jest wystarczające, czy też dane powinny zostać jawnie zaokrąglone według ustalonej reguły. Takiej decyzji nie należy zastępować przypadkową konwersją, ponieważ pozornie poprawny zapis może zmienić znaczenie wartości.

Po korekcie schematu trzeba zweryfikować mapowanie kolumn, wykonać próbę na kontrolnym zakresie danych i sprawdzić, czy zmiana została zapisania po stronie subskrybenta bez obcięcia tekstu, utraty części ułamkowej lub zmiany kodowania. Jeżeli nie można zmienić tabeli docelowej, rozwiązaniem bywa jawne przekształcenie danych przed wysłaniem, lecz reguła konwersji powinna być określona dla każdego problematycznego typu i przetestowana dla wartości granicznych. W środowisku z replikacją warto dokumentować każdą zmianę schematu oraz sprawdzać jej wpływ na istniejące mapowania, aby kolejna modyfikacja kolumn nie odtworzyła tego samego konfliktu.