Problemy regionalne przy migracji

Problemy regionalne przy migracji wynikają z różnic w ustawieniach języka, strefy czasowej i kolacji między serwerami.

Źródła problemów regionalnych w procesie migracji

Problemy regionalne przy migracji pojawiają się wtedy, gdy system źródłowy i system docelowy interpretują te same dane według różnych ustawień regionalnych. Dotyczy to przede wszystkim języka interfejsu, ustawień regionalnych formatu daty i liczb, strefy czasowej oraz reguł porównywania i sortowania tekstu. Sama zmiana konfiguracji serwera nie musi zmienić bajtów zapisanych w bazie, ale może zmienić sposób ich odczytu, sortowania, eksportowania i ponownego zapisu. Dlatego migracja danych wymaga rozdzielenia wartości przechowywanej od sposobu jej prezentacji.

Szczególne znaczenie ma odróżnienie lokalizacji od kodowania znaków. Lokalizacja określa między innymi nazwy miesięcy, separator dziesiętny, kolejność elementów daty i reguły sortowania, natomiast kodowanie określa sposób reprezentowania znaków w pamięci lub pliku. Tekst zapisany w UTF-8 może zostać nieprawidłowo odczytany, jeżeli narzędzie migracyjne potraktuje go jako inne kodowanie, na przykład Windows-1250. Efektem bywają zniekształcone polskie znaki, błędne długości pól albo odrzucenie rekordu podczas importu.

Daty, godziny i strefy czasowe po przeniesieniu danych

Data kalendarzowa i punkt na osi czasu nie są tym samym rodzajem informacji. Data urodzenia, termin płatności lub dzień wykonania czynności może być wartością bez strefy czasowej. Z kolei znacznik utworzenia pliku, zdarzenia w logu lub wykonania transakcji opisuje konkretny moment i powinien mieć jednoznaczne odniesienie do czasu, najczęściej UTC albo jawnie zapisanej strefy. Jeżeli system źródłowy przechowuje czas lokalny bez informacji o strefie, podczas migracji nie da się bez dodatkowych danych pewnie ustalić, jaki moment oznacza konkretny zapis.

Błąd może ujawnić się przy przejściu między czasem lokalnym a UTC. Dla strefy Europe/Warsaw występują okresy zmiany czasu, dlatego pewne godziny lokalne mogą wystąpić dwukrotnie, a inne nie wystąpić wcale. W czasie jesiennego cofnięcia zegara przedział obejmujący godzinę zmiany jest niejednoznaczny bez informacji o przesunięciu UTC. W czasie wiosennego przesunięcia część lokalnych godzin jest nieważna. Migracja powinna więc zachować offset, identyfikator strefy albo przeliczyć dane do UTC przed eksportem, zależnie od znaczenia konkretnego pola.

Niebezpieczne jest również traktowanie tekstowych dat jako wartości uniwersalnych. Zapis 03/04/2026 może oznaczać 3 kwietnia albo 4 marca, zależnie od przyjętej kolejności miesiąca i dnia. Bezpieczniejszy jest jednoznaczny format maszynowy, na przykład ISO 8601, o ile narzędzie importu interpretuje go zgodnie z dokumentacją. Należy także sprawdzić wartości graniczne, lata przestępne, północ na granicy dni oraz rekordy utworzone w pobliżu zmiany czasu.

Kolacja, porównywanie tekstu i integralność wyszukiwania

Kolacja określa reguły porównywania i sortowania ciągów znaków. Dwa systemy mogą przechowywać identyczny tekst, ale różnie oceniać wielkość liter, znaki diakrytyczne, kolejność liter albo równoważność różnych reprezentacji Unicode. W jednej konfiguracji wyszukiwanie może traktować „Łódź” i „łódź” jako wartości równoważne, a w innej jako różne. Podobne różnice dotyczą znaków złożonych z litery i znaku łączącego oraz znaków zapisanych jako pojedynczy znak Unicode.

Zmiana kolacji może wpłynąć na indeksy, klucze unikatowe i wyniki sortowania. Jeżeli w systemie źródłowym dwa napisy są uznawane za równoważne, a w docelowym za różne, mogą pojawić się duplikaty niewykrywane wcześniej. Odwrotna sytuacja może spowodować odrzucenie rekordu przy zakładaniu indeksu unikatowego. Różnice w sortowaniu wpływają także na paginację: zestaw rekordów znajdujących się na drugiej stronie wyników może zmienić się po migracji, nawet jeśli liczba rekordów pozostaje taka sama.

Kontrola kolacji powinna obejmować porównania z polskimi znakami, różne warianty wielkości liter, łączniki, apostrofy, spacje oraz znaki występujące w rzeczywistych danych. Warto porównać nie tylko pojedyncze rekordy, lecz także liczbę wyników dla tych samych filtrów, kolejność sortowania i zachowanie indeksów. Test powinien uwzględniać również pola używane jako identyfikatory logiczne, ponieważ niewidoczna zmiana reguł porównania może zmienić działanie dopasowania rekordów podczas kolejnych synchronizacji.

Plan kontroli migracji i diagnostyka rozbieżności

Przed migracją należy zinwentaryzować ustawienia środowiska źródłowego i docelowego: domyślną lokalizację, kodowanie połączeń, kodowanie plików eksportowych, strefę czasową procesu, reguły kolacji oraz typy pól przechowujących daty i godziny. Następnie trzeba ustalić znaczenie każdego pola. Osobno należy traktować daty bez czasu, lokalne godziny pracy, znaczniki zdarzeń i wartości zawierające offset. Nie powinno się konwertować wszystkich pól według jednej reguły bez sprawdzenia modelu danych.

Test migracji powinien używać reprezentatywnej próbki zawierającej polskie znaki, wartości graniczne dat, rekordy z godziną zmiany czasu, liczby z separatorem dziesiętnym oraz teksty różniące się wyłącznie wielkością liter lub znakami diakrytycznymi. Po imporcie należy porównać liczbę rekordów, sumy kontrolne pól tekstowych i liczbowych, wyniki wyszukiwania, kolejność sortowania oraz wartości czasowe po przeliczeniu do wspólnego odniesienia. Dla danych o wysokiej wartości kontrola powinna obejmować także eksport zwrotny i ponowny odczyt, ponieważ część błędów ujawnia się dopiero po drugim przejściu przez format pliku.

Przy rozbieżności należy ustalić, czy problem powstał podczas odczytu źródła, konwersji, transmisji, zapisu czy prezentacji w aplikacji. Pomocne jest porównanie surowej wartości, wartości pośredniej oraz wartości wyświetlanej użytkownikowi. Zmiana ustawień regionalnych na serwerze docelowym bez takiej kontroli może ukryć błąd tylko dla części rekordów i utrudnić jego odtworzenie. Stabilny proces migracji powinien jawnie definiować kodowanie, format dat, sposób obsługi stref czasowych i kolację, a następnie potwierdzać te założenia testami na danych obejmujących wszystkie istotne przypadki.