変更テーブル

タスクのすべての変更テーブルに共通の、単調に増加する変更シーケンス。変更シーケンスの形式は次のとおりです。

YYYYMMDDHHmmSShhxxxxxxxxxxxxxxxxxxx

条件:

• YYYY は 4 桁の年 (2012 など)
• MM は 2 桁の月 (01 ～ 12 の範囲)

• DD は 2 桁の日 (01 ～ 31 の範囲)

• HH は 1 日の時間 (00 ～ 23 の範囲)
• mm は分 (00 ～ 59 の範囲)
• SS は秒 (00 ～ 59 の範囲)
• hh は 100 分の 1 秒 (00 ～ 99 の範囲)
• xxxxxxxxxxxxxxxxxxx は 19 桁の接頭辞ゼロの変更番号 (タスクごとにグローバル)

時間部分は通常、変更レコードを含むトランザクションのコミット時間を指します。Qlik Talend Data Integration にはシーケンス番号の単調性を維持するロジックが含まれているため、エンドポイント時間を変更または調整すると、同じタイムスタンプ内でありながら変更番号が増加しているように見える複数の変更が生じる可能性があります。

xxx...xxx は通常、データ レコードの内部変更番号です。ただし、BEFORE-IMAGE レコードの場合は、一致する UPDATE レコードの変更番号と同じになります (例: BEFORE-IMAGE の変更番号が 1000 で UPDATE の変更番号が 1001 である場合、両方とも 1001 になります)。これにより、テーブルとそれ自体の間の単純な左外部結合が可能になります。左側では、ある時点までスキャンしますが、operation=before-image を除外し、右側では、change_oper が「B」である同じ change_seq で結合します。

操作の種類。これは次のいずれかになります。

• I: INSERT
• D: DELETE
• U: UPDATE
• B: 前画像

変更マスクは、変更テーブル内のどのデータ列がソース テーブルで変更された列に関連付けられているかを示します。

変更マスク内のビット位置は、変更テーブル内の列の序数に基づきます。つまり、ヘッダー列が 5 つある場合、それらはビット 0 ～ 4 を占め、最初のデータ列は変更マスクのビット 5 になります。

変更マスクは、変更マスクをリトルエンディアン順で表すバイナリ列 (バイト配列) です。

バイト0 bit7 bit6 bit5 bit4 bit3 bit2 bit1 bit0

バイト 1 bit15 bit14 bit13 bit12 bit11 bit10 bit9 bit8

この例では、bit#N は、序数 N の変更テーブル列がソース テーブルで変更された列に関連していることを示します。更新マスクが 11000 で、列の序数が 3 の場合、列は変更されません。

ビットのセマンティクスの説明は次のとおりです。

• INSERT レコードの場合、挿入されたすべての列に関連するビットが設定されます。
• DELETE レコードの場合、主キー (または一意のインデックス) 列にのみ関連ビットが設定されます。これにより、アプライヤーは、別のソースから主キー項目を見つけなくても DELETE ステートメントを構築できます。
• BEFORE-IMAGE レコードの場合、すべてのビットはクリアされます (変更マスクは空にできます)。
• UPDATE レコードの場合、BEFORE-IMAGE と UPDATE の間で値が変更された各列には、関連するビットが設定されます。

スペースと処理効率を高めるために、変更マスクに保存される実際のバイト数は null を取り除くことができます。つまり、末尾のゼロを保存する必要はありません。処理ロジックではこれを考慮する必要があります。

ソース CDC ストリームの位置。

変更レコードに関連付けられた操作。次のいずれかになります。

• INSERT
• UPDATE
• DELETE
• BEFOREIMAGE

変更レコードが属するトランザクションの ID。

値は、128 ビットのトランザクション ID の 16 進文字列です。

元の変更の UTC タイムスタンプ (値はおおよその値である可能性があります)。