Przeskocz do zawartości głównej

Tabele zmian

Możesz użyć narzędzi dla docelowego punktu końcowego, aby uzyskać informacje przy użyciu metadanych w tabelach zmian. Dane te są definiowane przez kolumny nagłówka dodane do schematu tabeli zmian. Nagłówki te opisano w poniższej tabeli.

Dla każdej tabeli docelowej w zadaniu replikacji w bazie danych zawierającej tabele docelowe utrzymywana jest tabela zmian o odpowiadającej jej nazwie. Więcej informacji zawiera temat Praca z tabelami zmian. Tabela zmian zawiera oryginalne kolumny tabeli i kolumny nagłówka. Kolumny nagłówka zawierają prefiks, dzięki czemu nazwa nie koliduje z nazwami kolumn tabeli źródłowej. Domyślny prefiks to header__. Aby uzyskać informacje na temat zmiany tego prefiksu, zobacz listę Tabele zmian w obszarze Metadane w Ustawieniach zadania. W poniższej tabeli wymieniono domyślne kolumny nagłówka tabeli zmian.

Nazwa kolumny Typ Opis

[header__]change_seq

varchar (35)

Monotonicznie rosnący sekwencer zmian, który jest wspólny dla wszystkich tabel zmian zadania. Sekwencja zmian ma następujący format:

YYYYMMDDHHmmSShhxxxxxxxxxxxxxxxxxxx

Gdzie:

  • YYYY to czterocyfrowy rok (np. 2012)
  • MM to dwucyfrowy miesiąc (zakres 01–12)
  • DD to dwucyfrowy dzień (zakres 01–31)

  • HH to godzina dnia (zakres 00–23)
  • mm to minuta w godzinie (zakres 00–59)
  • SS to sekunda w minucie (zakres od 00–59)
  • hh to setna część sekundy (zakres od 00–99)
  • xxxxxxxxxxxxxxxxxxx to 19-cyfrowy numer zmiany, poprzedzony zerem (globalny dla każdego zadania)

Część czasowa zwykle odnosi się do czasu zatwierdzenia transakcji, która obejmuje rekord zmiany. Qlik Talend Data Integration zawiera logikę, która utrzymuje monotoniczność numeru sekwencyjnego, dlatego modyfikowanie lub dostosowywanie czasu punktu końcowego może skutkować wieloma zmianami, które będą sprawiać wrażenie, że znajdują się w tym samym znaczniku czasu, ale ze wzrastającą liczbą zmian.

Numer xxx...xxx jest zwykle wewnętrznym numerem zmiany z rekordu danych z tą różnicą, że w przypadku rekordów BEFORE-IMAGE jest on taki sam jak numer zmiany pasującego rekordu UPDATE (na przykład, jeśli numer zmiany BEFORE-IMAGE wynosi 1000, a numer zmiany rekordu UPDATE wynosi 1001, wówczas oba mają 1001). Pozwala to na lewe sprzężenie zewnętrzne między tabelą a nią samą, gdzie po lewej stronie skanujemy do punktu w czasie, ale odfiltrowujemy operation=before-image, a po prawej sprzęgamy z tym samym change_seq, gdzie change_oper to „B”.

[header__]change_oper

varchar (1)

Typ operacji. Może to być jeden z następujących typów:

  • I: INSERT
  • D: DELETE
  • U: UPDATE
  • B: obraz przed

[header__] change_mask

varbinary (128)

Maska zmian wskazuje, które kolumny danych w tabeli zmian są powiązane z kolumnami zmienionymi w tabeli źródłowej.

Pozycja bitu w masce zmian jest oparta na liczbie porządkowej kolumny w tabeli zmian. Oznacza to, że jeśli jest 5 kolumn nagłówka, zajmują one bity od 0 do 4, a pierwsza kolumna danych jest bitem 5 w masce zmiany.

Maska zmiany to kolumna binarna (tablica bajtów) reprezentująca maskę zmiany w kolejności little-endian:

Bajt 0 bit7 bit6 bit5 bit4 bit3 bit2 bit1 bit0

Bajt 1 bit15 bit14 bit13 bit12 bit11 bit10 bit9 bit8

W tym przykładzie bit#N wskazuje, że kolumna tabeli zmian o liczbie porządkowej N odnosi się do kolumny, która uległa zmianie w tabeli źródłowej. Jeśli maska aktualizacji wynosi 11000, a liczba porządkowa kolumny to 3, kolumna nie uległa zmianie.

Poniżej opisano semantykę bitów:

  • W przypadku rekordów INSERT wszystkie wstawione kolumny mają ustawione powiązane bity.
  • W przypadku rekordów DELETE tylko kolumny z kluczem podstawowym (lub unikatowym indeksem) mają ustawione powiązane bity. Umożliwia to funkcji applier skonstruowanie instrukcji DELETE bez konieczności wyszukiwania pól klucza podstawowego z innego źródła.
  • Dla rekordów BEFORE-IMAGE wszystkie bity są wyczyszczone (maska zmiany może być pusta).
  • W przypadku rekordów UPDATE każda kolumna, której wartość uległa zmianie pomiędzy BEFORE-IMAGE i UPDATE, będzie miała ustawiony powiązany bit.

Ze względu na ilość miejsca i wydajność przetwarzania rzeczywistą liczbę bajtów przechowywanych w masce zmian można zmniejszyć przez redukcję wartości null. Oznacza to, że zera końcowe nie muszą być przechowywane. Logika obsługi powinna to wziąć pod uwagę.

[header__] stream_position

varchar (128)

Pozycja źródłowego strumienia CDC.

[header__] operation

varchar (12)

Operacja powiązana z rekordem zmiany. Może to być jedna z następujących operacji:

  • INSERT
  • UPDATE
  • DELETE
  • BEFOREIMAGE

[header__] transaction_id

varchar (32)

Identyfikator transakcji, do której należy rekord zmiany.

Wartość jest ciągiem szesnastkowym 128-bitowego identyfikatora transakcji.

[header__] timestamp

znacznik czasu

Oryginalny znacznik czasu UTC zmiany (wartość może być przybliżona).

Informacja W przypadku źródła PostgreSQL znacznik czasu jest znany dopiero po zatwierdzeniu. Dlatego do czasu zatwierdzenia zmian w tabelach źródłowych wyświetlana będzie data domyślna (np. 1970-01-01).

[header__] partition_name

ciąg znaków

Nazwa partycji utworzonej w miejscu docelowym, gdy włączona jest opcja Partycjonowanie zmian danych. Nazwa partycji składa się z czasu rozpoczęcia i zakończenia partycji.

Przykład:

20170313T123000_20170313T170000

Czy ta strona była pomocna?

Jeżeli natkniesz się na problemy z tą stroną lub jej zawartością — literówkę, brakujący krok lub błąd techniczny — daj nam znać, co możemy poprawić!