SCHEMA_AND_DATA

SCHEMA_AND_DATA to opcja replikacji przenosząca zarówno strukturę, jak i zawartość obiektu do subskrybenta.

Zakres kopiowania określany jako SCHEMA_AND_DATA

SCHEMA_AND_DATA oznacza tryb inicjalnej replikacji, w którym do subskrybenta przekazywane są dwa różne rodzaje informacji: definicja obiektu oraz jego bieżąca zawartość. Schemat obejmuje między innymi nazwę obiektu, kolumny, typy danych, wartości domyślne, ograniczenia, indeksy i zależności wymagane przez konkretny silnik. Dane to wiersze, rekordy lub inne elementy przechowywane w tym obiekcie. Sam zapis SCHEMA_AND_DATA nie jest uniwersalną komendą SQL ani jednolitym standardem wszystkich systemów baz danych. Zwykle jest nazwą wartości konfiguracyjnej używaną przez określone narzędzie replikacyjne.

Włączenie tego trybu nie oznacza automatycznie pełnego sklonowania całej bazy. Zakres zależy od implementacji: opcja może dotyczyć tabeli, kolekcji, schematu, zestawu obiektów albo publikacji. Narzędzie może również pomijać elementy, których nie potrafi odtworzyć po stronie subskrybenta, takie jak uprawnienia, wyzwalacze, procedury, widoki lub zależności zewnętrzne. Dlatego przed użyciem należy sprawdzić dokumentację konkretnego produktu i ustalić, które składniki struktury są rzeczywiście objęte operacją.

Dlaczego struktura musi poprzedzać przesyłanie rekordów

Replikacja danych wymaga zgodności modelu po stronie źródłowej i docelowej. Zanim subskrybent otrzyma rekord, musi znać kolejność kolumn, ich typy oraz zasady konwersji wartości. Jeżeli tabela nie istnieje albo ma inną strukturę, operacja kopiowania może zakończyć się błędem. Problemy pojawiają się także wtedy, gdy kolumna wymagana przez ograniczenie NOT NULL nie ma wartości domyślnej, typ liczbowy ma mniejszy zakres albo długość pola tekstowego jest ograniczona bardziej niż u źródła.

Poprawna kolejność inicjalizacji zwykle obejmuje utworzenie schematu, tabel i wymaganych zależności, a następnie załadowanie danych początkowych. Indeksy i ograniczenia mogą być tworzone przed importem albo po nim, zależnie od narzędzia i celu operacji. Utworzenie indeksów po załadowaniu dużego zbioru bywa szybsze, lecz do czasu ich utworzenia zapytania na subskrybencie mogą działać inaczej niż na źródle. Odtworzenie kluczy obcych przed kopiowaniem wymaga natomiast zachowania właściwej kolejności tabel lub czasowego odroczenia walidacji zależności.

Inicjalna synchronizacja a dalsza replikacja zmian

SCHEMA_AND_DATA najczęściej opisuje etap początkowego przygotowania subskrybenta. Po zakończeniu tego etapu system musi jeszcze obsługiwać zmiany wykonywane na źródle. Mogą one obejmować wstawienia, modyfikacje i usunięcia rekordów, a w niektórych rozwiązaniach także zmiany strukturalne. Nie wolno zakładać, że każda późniejsza zmiana schematu zostanie automatycznie przesłana razem z danymi. Dodanie kolumny, zmiana typu, usunięcie indeksu lub modyfikacja ograniczenia może wymagać osobnej procedury wdrożeniowej.

Podczas pierwszego kopiowania należy rozróżnić stan danych od strumienia zmian. System może wykonać migawkę, zapamiętać punkt rozpoczęcia i później zastosować zmiany powstałe w trakcie transferu. Jeżeli mechanizm nie zapewnia takiej kolejności, subskrybent może otrzymać rekordy nieaktualne, duplikaty albo zmiany zastosowane przed utworzeniem wymaganej struktury. Po synchronizacji warto porównać liczbę rekordów, zakres kluczy, sumy kontrolne wybranych kolumn oraz pozycję opóźnienia replikacji. Sama informacja o zakończeniu procesu nie potwierdza jeszcze zgodności wszystkich danych.

Kontrola procesu na komputerze i w środowisku serwisowym

Przy diagnozowaniu problemu z trybem SCHEMA_AND_DATA trzeba najpierw ustalić nazwę silnika, wersję narzędzia, kierunek replikacji oraz dokładny obiekt objęty konfiguracją. Następnie należy sprawdzić logi inicjalizacji, komunikaty o błędach typów danych, brakujących zależnościach, konflikcie nazw i odmowie uprawnień. Istotne są również informacje o rozmiarze źródła, czasie rozpoczęcia migawki, liczbie przesłanych rekordów i aktualnym opóźnieniu subskrybenta. Bez tych danych nie da się odróżnić błędu struktury od przerwanego transferu albo problemu z połączeniem.

Przed ponowną synchronizacją należy ustalić, czy narzędzie wykonuje operację idempotentnie, czy może utworzyć duplikaty, oraz czy częściowo załadowane dane zostaną wycofane. Kopię zapasową i plan odtworzenia trzeba przygotować zgodnie z dokumentacją używanego silnika, ponieważ sposób eksportu schematu i danych nie jest wspólny dla wszystkich baz. W praktyce diagnostyka obejmuje także sprawdzenie wolnego miejsca, stabilności połączenia, uprawnień konta replikacyjnego i zgodności ustawień kodowania. Takie postępowanie pozwala bezpiecznie ustalić, czy problem dotyczy definicji obiektu, zawartości, czy samego mechanizmu dostarczania zmian.