Ga naar hoofdinhoud

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

[header__]change_seq

varchar (35)

Een monotoon toenemende wijzigingsreeks die voorkomt bij alle wijzigingstabellen van een taak. De wijzigingsreeks heeft de volgende indeling:

YYYYMMDDHHmmSShhxxxxxxxxxxxxxxxxxxx

Waarbij:

  • YYYY een viercijferig jaar is (zoals 2012)
  • MM de tweecijferige maand is (bereik van 01-12)
  • DD de tweecijferige dag is(bereik van 01-31)

  • HH het uur van de dag is (bereik van 00-23)
  • mm de minuut van het uur is (bereik van 00-59)
  • SS de seconde van de minuut is (bereik van 00-59)
  • hh de honderste van een seconde is (bereik van 00-99)
  • xxxxxxxxxxxxxxxxxxx is een 19-cijferig wijzigingsnummer dat wordt voorafgegaan door een nul (algemeen per taak)

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 operation=before-image uitfilteren, en rechts voeren we een joint uit op dezelfde change_seq waarbij change_oper 'B' is .

[header__]change_oper

varchar (1)

Het bewerkingstype. Dit kan een van het volgende zijn:

  • I: INSERT
  • D: DELETE
  • U: UPDATE
  • B: Before Image

[header__] change_mask

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 bit#N aan dat de kolom van de wijzingstabel van positie N gerelateerd is aan een kolom die is gewijzigigd in de brontabel. Als het updatemasker 11000 is en de kolompositie 3, is de kolom niet gewijzigd.

Hieronder wordt de semantiek van bits beschreven:

  • In het geval van INSERT-records beschikken alle ingevoegde kolommen over de gekoppelde bitset.
  • In het geval van DELETE-records beschikken alleen kolommen met de primaire sleutel (of unieke index) over de gekoppelde bitset. Dit stelt een aanvrager in staat om een DELETE-instructie te maken zonder de velden met primaire sleutels van een andere bron te vinden.
  • In het geval van BEFORE-IMAGE-records zijn alle bits gewist (het wijzigingsmasker is mogelijk leeg).
  • In het geval van UPDATE-records beschikt elke kolom waarvan de waarde is gewijzigd tussen de BFORE-IMAGE en de UPDATE over de koppelde bitset.

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.

[header__] stream_position

varchar (128)

De positie van de CDC-stream van de bron.

[header__] operation

varchar (12)

De bewerking die is gekoppeld met het wijzigingsrecord. Dit kan een van de volgende zijn:

  • INSERT
  • UPDATE
  • DELETE
  • BEFOREIMAGE

[header__] transaction_id

varchar (32)

De id van de transactie waartoe het wijzigingsrecord behoort.

De waarde is een hex-tekenreeks van de 128-bits transactie-id.

[header__] timestamp

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__] partition_name

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

Was deze pagina nuttig?

Als u problemen ervaart op deze pagina of de inhoud onjuist is – een typfout, een ontbrekende stap of een technische fout – laat het ons weten zodat we dit kunnen verbeteren!