Przenoszenie danych między bazami

Przenoszenie danych między bazami wykonuje się zapytaniem z pełną nazwą tabeli źródłowej lub narzędziem importu.

Zakres przenoszenia danych między bazami

Przenoszenie danych między bazami oznacza skopiowanie rekordów z jednej bazy danych do drugiej przy zachowaniu ich znaczenia, struktury oraz zależności. Źródłem i celem mogą być różne schematy, tabele albo całe zbiory danych w obrębie tego samego systemu bazodanowego. Operacja nie ogranicza się do mechanicznego przepisania wartości. Trzeba ustalić, które kolumny odpowiadają sobie wzajemnie, jak kodowane są teksty, jakie typy mają daty i liczby oraz czy identyfikatory zachowują tę samą funkcję w obu bazach.

Najprostszy przypadek występuje wtedy, gdy tabela źródłowa i docelowa mają zgodne kolumny oraz kompatybilne typy danych. Wówczas dane można pobrać zapytaniem wskazującym pełną nazwę tabeli, obejmującą odpowiedni schemat lub bazę, a następnie zapisać je w tabeli docelowej. Przy rozbieżnej strukturze potrzebne jest jawne przypisanie kolumn, przekształcenie wartości albo etapowa tabela pośrednia. Narzędzia importu i eksportu wykonują podobne zadania, lecz wymagają poprawnego wskazania źródła, celu, formatu pliku oraz sposobu obsługi błędnych rekordów.

Mapowanie tabel, kolumn i typów danych

Przed rozpoczęciem migracji należy porównać schemat źródłowy i docelowy. Istotne są nazwy tabel, nazwy kolumn, typy danych, dopuszczalność wartości pustych, wartości domyślne, klucze główne oraz ograniczenia integralności. Kolumna tekstowa w jednej bazie może mieć inny limit długości niż odpowiadająca jej kolumna w bazie docelowej. Podobnie data, liczba dziesiętna i wartość logiczna mogą być reprezentowane w odmienny sposób. Bez takiego mapowania import może zakończyć się błędem albo doprowadzić do cichego obcięcia lub zmiany wartości.

Trzeba również określić kolejność przenoszenia tabel. Rekord zależny od wartości klucza obcego powinien trafić do bazy po utworzeniu odpowiadającego mu rekordu nadrzędnego, chyba że używany proces przewiduje czasowe odroczenie kontroli zależności. Szczególnej uwagi wymagają identyfikatory generowane automatycznie. Jeżeli podczas importu zostaną nadane nowe wartości, relacje między tabelami mogą przestać wskazywać właściwe rekordy. Bezpieczniejsze jest zachowanie identyfikatorów albo przygotowanie jednoznacznej tabeli odwzorowań starych i nowych kluczy.

Warto wcześniej ustalić sposób obsługi duplikatów. Możliwe jest pominięcie istniejącego rekordu, jego aktualizacja, odrzucenie całej partii albo zapisanie konfliktu do osobnego raportu. Nie powinno się zakładać, że identyczna nazwa oznacza identyczny rekord. Do porównania stosuje się stabilny identyfikator, zestaw pól jednoznacznie opisujących obiekt albo określoną regułę biznesową, jeżeli została formalnie ustalona dla danego systemu.

Transakcja, walidacja i kontrola kompletności

Przenoszenie większej liczby rekordów powinno być wykonywane w kontrolowanych partiach lub transakcjach. Transakcja pozwala zatwierdzić spójny zestaw zmian dopiero po pomyślnym zakończeniu operacji albo wycofać zmiany, gdy wystąpi błąd. Przy bardzo dużych zbiorach jedna transakcja może nadmiernie obciążyć dziennik transakcji, pamięć i blokady, dlatego rozmiar partii dobiera się do możliwości konkretnego środowiska. Każda partia powinna mieć możliwy do odtworzenia zakres, na przykład przedział identyfikatorów lub znacznik czasu.

Po imporcie należy sprawdzić nie tylko liczbę rekordów, lecz także ich zawartość. Podstawowa kontrola obejmuje porównanie liczby wierszy w źródle i celu, liczby wartości pustych, zakresów dat, sum kontrolnych dla wybranych kolumn oraz liczby rekordów powiązanych relacjami. Trzeba zweryfikować, czy wartości nie zostały obcięte, przekonwertowane na inny format albo przesunięte wskutek różnic w strefie czasowej. W przypadku danych tekstowych należy sprawdzić znaki diakrytyczne i sposób kodowania, ponieważ błędna konwersja może zmienić treść bez zgłoszenia awarii.

Proces powinien pozostawiać dziennik zawierający czas wykonania, zakres przenoszonych danych, liczbę rekordów odczytanych, zapisanych i odrzuconych oraz opis błędów. Przydatny jest także test na kopii danych, wykonany przed właściwą operacją. Jeżeli baza docelowa zawiera już część informacji, należy ustalić, czy ponowne uruchomienie procesu jest bezpieczne. Idempotentny import nie tworzy kolejnych kopii tych samych rekordów po ponownym wykonaniu, ponieważ rozpoznaje wcześniej przetworzone dane według ustalonego klucza.

Diagnozowanie problemów po migracji

Nieudane przenoszenie danych może wynikać z niezgodności typów, braku uprawnień, naruszenia klucza głównego lub obcego, przekroczenia długości pola, błędnego kodowania albo nieprawidłowego formatu pliku. Sam komunikat o błędzie nie zawsze wskazuje rekord, który go wywołał. Dlatego procedura diagnostyczna powinna rozdzielać dane poprawne od odrzuconych i zapisywać identyfikator oraz przyczynę odrzucenia każdego problematycznego wiersza. Warto też sprawdzić, czy błąd występuje przy odczycie ze źródła, transformacji wartości, czy dopiero przy zapisie do celu.

Jeżeli import zakończył się pozornie poprawnie, ale aplikacja pokazuje niepełne lub niespójne informacje, należy porównać zapytania używane przez aplikację z rzeczywistym schematem bazy docelowej. Częstą przyczyną jest przeniesienie tabel bez indeksów, widoków, procedur lub ograniczeń wymaganych przez aplikację. Znaczenie ma również kolejność aktualizacji danych, ponieważ częściowo wykonana migracja może pozostawić rekordy nadrzędne bez elementów zależnych albo odwrotnie. Przed udostępnieniem bazy użytkownikom należy wykonać odczyt przykładowych rekordów, sprawdzić relacje i potwierdzić możliwość odtworzenia danych z kopii zapasowej.

Przy problemach z bazą na laptopie lub komputerze PC diagnostyka powinna obejmować także stan dysku, dostępne miejsce, działanie usługi bazodanowej, uprawnienia konta oraz poprawność plików kopii zapasowej. W środowisku roboczym nie należy eksperymentować na jedynej kopii danych. Najpierw trzeba zabezpieczyć aktualny stan, opisać wykonane operacje i ustalić punkt, do którego można bezpiecznie wrócić. Naprawa może polegać na korekcie mapowania, ponownym imporcie wybranej partii, odbudowie brakujących indeksów albo odtworzeniu spójnej kopii i powtórzeniu migracji według poprawionej procedury.