Wijzigingstabellen
U kunt de hulpmiddelen voor uw doeleindpunt gebruiken om informatie te vergaren met behulp van de metagegevens in de wijzigingstabellen. Deze gegevens worden gedefinieerd door de kopkolommen die zijn toegevoegd aan het wijzigingstabelschema. Deze kopkolommen worden in de onderstaande tabel beschreven.
Voor elke doeltabel in de replicationtaak wordt een wijzigingstabel met de bijbehorende naam onderhouden in de database met de doeltabellen. Ga voor meer informatie naar Werken met wijzigingstabellen. Een wijzigingstabel bevat de originele tabelkolommen en kopkolommen. De kopkolommen bevatten een prefix, zodat de naam niet in conflict is met de kolomnamen van de brontabel. De standaard prefix is header__
. Raadpleeg de vermelding Wijzigingstabellen onder Metagegevens in Taakinstellingen voor meer informatie over het wijzigen van deze prefix. De volgende tabel toont de standaardkopkolommen van de wijzigingstabel.
Kolomnaam | Waardetype | Beschrijving |
---|---|---|
varchar (35) |
Een monotoon toenemende wijzigingsreeks die voorkomt bij alle wijzigingstabellen van een taak. De wijzigingsreeks heeft de volgende indeling: YYYYMMDDHHmmSShhxxxxxxxxxxxxxxxxxxx Waarbij:
Het tijdgedeelte verwijst meestal naar de doorvoertijd van de transactie die het wijzigingsrecord bevat. Qlik Talend Data Integration bevat logica die de monotoniciteit van het volgnummer behoudt. Het wijzigen of aanpassen van de eindtijd kan daarom leiden tot meerdere wijzigingen waarbij het lijkt alsof ze tot hetzelfde tijdstempel behoren, maar dan met een toenemend wijzigingsnummer. De xxx...xxx is meestal het interne wijzigingsnummer van het gegevensrecord, maar voor BEFORE-IMAGE- records is dit hetzelfde als het wijzigingsnummer van het overeenkomende UPDATE-record (bijvoorbeeld als het wijzigingsnummer van BEFORE-IMAGE 1000 is en dat van de UPDATE 1001 is, dan hebben beide 1001). Dit maakt een simpele left outer join mogelijk tussen de tabel en zichzelf, waarbij we links scannen tot het tijdstip maar |
|
|
varchar (1) |
Het bewerkingstype. Dit kan een van het volgende zijn:
|
|
varbinary (128) |
Het wijzigingsmasker geeft aan welke gegevenskolommen in de wijzigingstabel zijn gekoppeld met kolommen die zijn gewijzigd in de brontabel. De bitpositie in het wijzigingsmasker is gebaseerd op de kolompositie in de wijzigingstabel. Dit betekent dat als er 5 kopkolommen zijn, ze bits 0 tot 4 innemen en de eerste gegevenskolom is bit 5 in het wijzigingsmasker. Het wijzigingsmasker is een binaire kolom (een bytematrix) die het wijzigingsmasker in de little-endianvolgorde vertegenwoordigt: Byte 0 bit7 bit6 bit5 bit4 bit3 bit2 bit1 bit0 Byte 1 bit15 bit14 bit13 bit12 bit11 bit10 bit9 bit8 In dit voorbeeld geeft Hieronder wordt de semantiek van bits beschreven:
De werkelijke hoeveelheid bytes die wordt opgeslagen in het wijzigingsmasker kan null-trimmed zijn. Dit betekent dat de laatste nullen niet opgeslagen hoeven te worden. De verwerkende logica moet hiermee rekening houden. |
|
varchar (128) |
De positie van de CDC-stream van de bron. |
|
varchar (12) |
De bewerking die is gekoppeld met het wijzigingsrecord. Dit kan een van de volgende zijn:
|
|
varchar (32) |
De id van de transactie waartoe het wijzigingsrecord behoort. De waarde is een hex-tekenreeks van de 128-bits transactie-id. |
|
tijdstempel |
De UTC-tijdstempel van de originele wijziging (de waarde kan een schatting zijn). Informatie Bij een PostgreSQL-bron is de tijdstempel pas bekend nadat de doorvoering is toegepast. Om die reden wordt de standaardatum weergegeven (bijv. 1970-01-01) totdat de wijzigingen zijn doorgevoerd in de brontabellen.
|
[header__] |
tekenreeks |
De naam van de partitie die is gemaakt op het doel wanneer Gegevenspartitie wijzigen is ingeschakeld. De partitienaam bevat de begin- en eindtijd van de partitie. Voorbeeld: 20170313T123000_20170313T170000 |