Problem z kolacją po migracji

Problem z kolacją po migracji ujawnia się błędami porównań tekstu między bazą źródłową a docelową.

Problem z kolacją po migracji – czym jest to zjawisko

Problem z kolacją po migracji dotyczy sytuacji, w której dwa systemy przechowują pozornie takie same dane tekstowe, lecz porównują je według innych reguł. W tym kontekście słowo „kolacja” odnosi się do sposobu sortowania i porównywania znaków, czyli do ustawień collation. Reguły te określają między innymi, czy wielkość liter ma znaczenie, jak traktowane są polskie znaki diakrytyczne, czy spacje są pomijane oraz w jakiej kolejności układane są litery i cyfry.

Po przeniesieniu bazy danych do innego silnika, na nową wersję systemu albo do innego środowiska mogą pojawić się rozbieżności, których wcześniej nie było widać. Rekord z wartością „Łódź” może zostać uznany za różny od wartości „Lodz”, a w innym ustawieniu oba zapisy mogą być traktowane jako równoważne. Podobnie może zmienić się wynik wyszukiwania, sortowania, grupowania lub łączenia tabel. Nie musi to oznaczać uszkodzenia danych. Często przyczyną jest niespójność reguł porównywania tekstu pomiędzy źródłem i miejscem docelowym.

Skutki mogą obejmować błędy importu, odrzucone rekordy, duplikaty, brak wyników wyszukiwania oraz inne zachowanie filtrów. Problem bywa szczególnie trudny do zauważenia, gdy większość danych składa się z prostych znaków alfabetu łacińskiego, a rozbieżność ujawnia się dopiero przy nazwiskach, nazwach miejscowości, symbolach produktów lub danych wpisywanych w kilku językach.

Kolacja po migracji a kontekst techniczny i porównanie ustawień

Każda baza danych korzysta z zestawu parametrów opisujących sposób przechowywania i porównywania tekstu. Znaczenie ma kodowanie znaków, zestaw znaków, collation na poziomie całej bazy, tabeli, kolumny, indeksu, a czasami także ustawienie używane przez konkretne zapytanie. Jeżeli kolumna źródłowa działa według reguł niewrażliwych na wielkość liter, a kolumna docelowa rozróżnia małe i wielkie litery, zapytanie filtrujące może zwrócić inny zbiór rekordów.

Różnice mogą wystąpić także pomiędzy typami danych. Tekst o stałej długości może być porównywany inaczej niż tekst o długości zmiennej, a wartości zapisane jako tekst mogą zachowywać się inaczej niż wartości przechowywane w polach przeznaczonych dla liczb. Warto sprawdzić, czy migracja nie zmieniła sposobu traktowania końcowych spacji, znaków narodowych, znaków złożonych z kilku kodów oraz symboli spoza podstawowego alfabetu.

Istotne jest odróżnienie trzech obszarów: przechowywania danych, porównywania danych i sortowania danych. Prawidłowe przechowywanie znaków nie gwarantuje jeszcze zgodnych wyników sortowania. Dwa systemy mogą wyświetlać ten sam tekst, ale inaczej oceniać równość wartości albo ustalać ich kolejność. W praktyce należy porównać definicje kolumn, reguły indeksów, ustawienia połączenia aplikacji z bazą oraz sposób generowania zapytań.

Przykładowo, w jednym środowisku wyszukanie frazy bez rozróżniania wielkości liter może zwrócić „Jan Kowalski”, „jan kowalski” i „JAN KOWALSKI”. W drugim środowisku mogą zostać zwrócone tylko rekordy odpowiadające dokładnemu zapisowi. Jeszcze inny rezultat może pojawić się przy znakach „ą”, „a”, „ę” lub „e”, zależnie od wybranych reguł językowych. Dlatego porównanie kilku pojedynczych rekordów nie zawsze wystarcza. Potrzebny jest zestaw testowy obejmujący różne warianty zapisu.

Problem z kolacją po migracji – typowe problemy i objawy

Jednym z najczęstszych objawów jest zmiana wyników wyszukiwania po migracji. Użytkownik wpisuje nazwę, która wcześniej znajdowała rekord, lecz po przeniesieniu danych lista wyników jest pusta albo zawiera tylko część pasujących pozycji. Innym sygnałem jest pojawienie się pozornie identycznych wpisów, które nie są rozpoznawane jako duplikaty. Dotyczy to szczególnie danych kontaktowych, nazw firm, nazw ulic, kodów artykułów i identyfikatorów zapisanych jako tekst.

Może wystąpić również błąd tworzenia indeksu. Jeżeli nowe reguły porównywania uznają wcześniej odrębne wartości za równoważne, indeks unikatowy może odrzucić część danych. W odwrotnej sytuacji system może zaakceptować wpisy, które z punktu widzenia użytkownika są takie same, ale technicznie różnią się wielkością liter, znakiem diakrytycznym albo niewidoczną spacją.

Problemy pojawiają się także podczas łączenia tabel. Relacja oparta na tekście może przestać działać, jeśli klucz w jednej tabeli jest porównywany według innych zasad niż odpowiadająca mu kolumna w drugiej tabeli. W rezultacie raport może zawierać braki, liczba dopasowanych rekordów może się zmniejszyć, a agregacje mogą przedstawiać niepełny obraz danych. Zdarza się, że aplikacja nie zgłasza wyraźnego błędu, lecz prezentuje niekompletne wyniki.

Do typowych symptomów należą także nieprawidłowe sortowanie, zmieniona kolejność list wyboru, problemy z importem plików oraz różnice pomiędzy działaniem panelu administracyjnego i bezpośrednich zapytań. Niekiedy kłopot dotyczy tylko nowych danych, ponieważ starsze rekordy zostały zapisane w sposób zgodny z wcześniejszymi regułami. W takim przypadku konieczne może być ustalenie, od którego momentu pojawia się rozbieżność.

Kolacja po migracji – praktyczne wskazówki diagnostyczne

Diagnozę warto rozpocząć od zebrania dokładnych informacji o zakresie migracji. Należy ustalić, które tabele i kolumny zostały przeniesione, czy zmieniono silnik lub wersję bazy oraz czy aplikacja korzysta z tego samego sterownika. Przydatne jest zestawienie definicji schematu przed migracją i po niej, z uwzględnieniem typów pól, długości tekstu, indeksów i reguł porównywania.

Następnie należy przygotować mały, kontrolowany zestaw testowy. Powinny znaleźć się w nim wartości różniące się wyłącznie wielkością liter, wartości z polskimi znakami, zapisy z dodatkowymi spacjami, teksty zawierające łącznik lub apostrof oraz przykłady z cyframi. Ten sam zestaw należy sprawdzić w bazie źródłowej i docelowej za pomocą porównań równości, wyszukiwania częściowego, sortowania, grupowania i łączenia tabel.

Nie powinno się od razu masowo zmieniać ustawień ani wykonywać konwersji na całym zbiorze. Najpierw warto utworzyć kopię danych, zapisać aktualne definicje oraz przetestować wybrane rozwiązanie na odizolowanej kopii. Zmiana collation może wpływać na indeksy, ograniczenia unikatowości, wyniki raportów i działanie aplikacji. W niektórych przypadkach bezpieczniejsze jest ujednolicenie tylko konkretnych kolumn, a w innych konieczne będzie dostosowanie całego schematu.

Warto również sprawdzić ustawienia połączenia aplikacji. Reguła zastosowana podczas ręcznego testu może różnić się od reguły używanej przez program, sterownik albo warstwę zapytań. Należy porównać zapytania wykonywane przed i po migracji, zweryfikować typy parametrów oraz sprawdzić, czy aplikacja nie wykonuje dodatkowej normalizacji tekstu. Pomocne bywa zapisanie przykładów rekordów, dla których wynik jest odmienny, wraz z dokładnym zapytaniem i oczekiwanym rezultatem.

Jeżeli problem dotyczy danych wielojęzycznych, dobór reguł powinien uwzględniać rzeczywisty sposób pracy użytkowników. Ustawienie przeznaczone dla jednego języka może nie zapewniać poprawnych wyników dla wszystkich stosowanych znaków. Wymagana jest także kontrola eksportu i importu, ponieważ niezgodność kodowania pliku może stworzyć dodatkowy problem, niezależny od samej kolacji.

Kiedy zgłosić Problem z kolacją po migracji do serwisu

Zgłoszenie do serwisu jest uzasadnione, gdy rozbieżności wpływają na wyszukiwanie, raportowanie, import danych albo codzienną pracę aplikacji, a sam problem nie daje się jednoznacznie przypisać do pojedynczej kolumny. Warto przekazać opis objawu, przykładowe wartości, informacje o momencie wystąpienia oraz kopię komunikatu błędu. Przydatne będzie również wskazanie, czy zmieniono bazę, system, aplikację lub sposób wykonywania kopii.

Wsparcie techniczne może obejmować analizę ustawień, porównanie schematów, przygotowanie testu na kopii oraz ocenę ryzyka przed zmianą danych. Szczególnej ostrożności wymaga sytuacja, w której problem dotyczy indeksu unikatowego, danych klientów, historii zamówień albo tabel wykorzystywanych przez wiele modułów. Działania wykonywane bez kopii i bez planu odtworzenia mogą utrudnić ustalenie pierwotnej przyczyny.

W Warszawie takie zgłoszenie można przekazać firmie Warszawskie Pogotowie Komputerowe 24/7, opisując, że chodzi o różne wyniki porównań tekstu po migracji. Im dokładniej zostaną wskazane przykładowe rekordy i operacje, tym łatwiej zawęzić obszar poszukiwań. W przypadku niejasnych rezultatów dobrze zachować zarówno wersję danych przed migracją, jak i aktualny stan środowiska, aby możliwe było bezpieczne porównanie zachowania obu systemów.