行変更トラッキングが有効になっているスキーマ
CREATE SCHEMA または ALTER SCHEMA ステートメントの一部として ENABLE ROW MODIFICATION TRACKING 節を使用することにより、スキーマの行変更トラッキングが有効になります。 このようなスキーマの主な目的は、増分スキーマ・バックアップで、最後のフル・スキーマ・バックアップ以降に変更されたデータをキャプチャーできるようにすることです。
行変更トラッキングが有効になっているスキーマで作成された表
行変更トラッキングが有効になっているスキーマで作成されたカラム・オーガナイズ表は、行変更トラッキングで有効になります。 フルバックアップと増分バックアップの間の表データに対する増分変更を追跡するために、表の作成時に表ごとに 3 つの暗黙的な非表示列が追加されます。 詳しくは、 増分スキーマのバックアップとリストアを参照してください。
これらの 3 つの新しい列に保管される値には追加のスペースが必要になるため、行変更トラッキングが有効になっている表は、より多くのページを消費します。
行変更トラッキングが有効になっている表には、以下の 3 つの新しい列が追加されます。
| 列名 | データ型 | ヌルの許可 | 説明 |
|---|---|---|---|
| SYSROWID | BIGINT | いいえ | 表内の各行を一意的に識別する列。 この ID は、すべてのデータベース・パーティションで固有です。 この列の値は SEQUENCE によって生成されます。 |
| CREATEXID | BIGINT | いいえ | 表に行を追加したトランザクションの ID を保管します。 |
| DELETEXID | BIGINT | いいえ | 行を削除したトランザクションの ID を保管します。 行が削除されない場合は、ゼロになります。 |
行が挿入され、SYSROWID の値が割り当てられた後は、その行が更新されても、この値は変更されません。 上記の列名は、行変更トラッキングが有効になっている表で使用するために IBM® によって予約されることに注意してください。 表で同じ列名を使用しようとすると、表の作成時または変更時にエラーが発生します。
行変更トラッキングが有効になっているスキーマで作成された永続カラム・オーガナイズ表のみが、行変更トラッキングで有効になります。 以下の表は行変更トラッキングが有効になっていないため、追加の 3 つの列は含まれません。- 一時表
- 外部表
- マテリアライズ照会表
- 上記のリストに含まれていない表のうち、カラム・オーガナイズもされていない表 (例えば、行、挿入時間、ディメンション節などで編成された表)
表内の 3 つの追加列の例を以下に示します。 ユーザーは、表の記述を行うときに、表の追加の列を表示できます。
db2 "CREATE TABLE S1.T1 (C1 INTEGER)"
db2 "DESCRIBE TABLE S1.T1"
Data type Column
Column name schema Data type name Length Scale Nulls
------------------------------- --------- ------------------- ---------- ----- ------
SYSROWID SYSIBM BIGINT 8 0 No
CREATEXID SYSIBM BIGINT 8 0 No
DELETEXID SYSIBM BIGINT 8 0 No
C1 SYSIBM INTEGER 4 0 Yes
4 record(s) selected.
列は内部的に生成された値で暗黙的に非表示にされるため、例えば、表から select * を実行してもユーザーには表示されません。ユーザーは、insert、update、または delete ステートメントを実行するときに列を指定する必要はありません。 3 つの列のいずれかを (挿入/更新/削除/変更によって) 変更しようとすると、無視されるか、エラーになります。
行変更トラッキングが有効になっているスキーマ内のオブジェクトに対する Db2® データベースの制限
- db2load および INGEST の例外表はカラム・オーガナイズできないため、行変更トラッキングが有効になっている表に db2load または INGEST の例外表を使用するための推奨される方法は、別のスキーマに行オーガナイズ表を作成することです (行オーガナイズ表が原因で増分スキーマ・バックアップが失敗するため、異なるスキーマになります)。 さらに、例外表には、行変更トラッキング用に定義された隠し列を含む類似の定義が必要です。ただし、SYSROWID は例外表ではサポートされていないため、ID 列にすることはできません。 例えば、以下のようにします。
- スキーマ S1 を作成して、行変更トラッキングを有効にしてください
- スキーマ S2 の作成
- CREATE TABLE S1.T1 (C1 INT)
- CREATE TABLE S2.LOADEXTBL (SYSROWID BIGINT NOT NULL, CREATEXID BIGINT NOT NULL, DELETEXID BIGINT NOT NULL, C1 INT)
- LOAD FROM < file> OF DEL INSERT INTO S1.T1 FOR EXCEPTION S2.LOADEXTBL
- 行変更トラッキングが有効になっている表のユーザー定義列の最大数が 1009 に削減されました。
- 行変更トラッキングが有効になっている表に CREATE オプションまたは REPLACE_CREATE オプションを使用して IMPORT を実行すると、失敗する可能性があります。
- 少なくとも 1 つの表が DISTRIBUTE BY RANDOM として定義されているか、GENERATED ALWAYS AS IDENTITY 列を含んでいる場合、 copymode が「COPY」または「COPYNO」の ADMIN_COPY_SCHEMA は失敗します。
- 行変更トラッキングをマテリアライズ照会表にすることが可能な表の変更はサポートされていません。
- 3 つの新しい非表示列 (SYSROWID、CREATEXID、DELETEXID) は、表の分散キー内ではサポートされません (つまり、DISTRIBUTE BY HASH 列リストでは許可されません)。
- ソースまたはターゲットが行変更トラッキングが有効になっているスキーマ内の表である場合、 db2move はサポートされません。
- 3 つの新しい非表示列のいずれも、索引キーの一部として、または強制制約に含めることはできません。
- 行変更トラッキングが有効になっているシステム期間テンポラル表または Bitemporal 期間表はサポートされませんが、アプリケーション期間テンポラル表は行変更トラッキングをサポートします。
- CREATE VIEW のサポートなし ... 行変更トラッキングが有効になっている WITH ROW MOVEMENT。
- 表の REORG ... RECLAIM EXTENTS は、削除された SYSROWID/CREATEXID/DELETEXID 列からスペースを再利用します。 スペースは、最後の -type ONL (フル・スキーマ) バックアップより前に削除された行についてのみ再利用されます。
カタログの変更
SYSCAT.SCHEMATA の中の ROWMODIFICATIONTRACKING という新しい列は、スキーマが行変更トラッキングに対して使用可能になっているかどうかを、値「N」または「Y」で示します。 SYSCAT.SCHEMATA 内の QUIESCED という新しい列は、スキーマが進行中の LOGICAL_RESTORE () によってロックされているかどうかを値 'N' または' Y ' で示します。
db2 DESCRIBE TABLE SYSCAT.SCHEMATA
Data type Column
Column name schema Data type name Length Scale Nulls
------------------------------- --------- ------------------- ---------- ----- ------
SCHEMANAME SYSIBM VARCHAR 128 0 No
OWNER SYSIBM VARCHAR 128 0 No
OWNERTYPE SYSIBM CHARACTER 1 0 No
DEFINER SYSIBM VARCHAR 128 0 No
DEFINERTYPE SYSIBM CHARACTER 1 0 No
CREATE_TIME SYSIBM TIMESTAMP 10 6 No
AUDITPOLICYID SYSIBM INTEGER 4 0 Yes
AUDITPOLICYNAME SYSIBM VARCHAR 128 0 Yes
AUDITEXCEPTIONENABLED SYSIBM CHARACTER 1 0 No
DATACAPTURE SYSIBM VARCHAR 1 0 No
ROWMODIFICATIONTRACKING SYSIBM VARCHAR 1 0 No
QUIESCED SYSIBM VARCHAR 1 0 No
REMARKS SYSIBM VARCHAR 254 0 Yes
db2 SELECT CAST(SCHEMANAME as CHAR(5)) as SCHEMANAME, ROWMODIFICATIONTRACKING FROM SYSCAT.SCHEMATA WHERE SCHEMANAME='S1'
SCHEMANAME ROWMODIFICATIONTRACKING
---------- -----------------------
S1 Y
1 record(s) selected.移行に関する考慮事項
ユーザーは、行変更トラッキングを有効にするためにスキーマを変更できますが、行変更トラッキングを有効にするためにスキーマ内の表を変更することはありません。 スキーマ変更の構文は次のとおりです。
3 つの新しい列に保管される値には追加のスペースが必要になるため、行変更トラッキングが有効になっている表は、そうでない同じ表よりも多くのページを消費します。 行変更トラッキングが有効になるのは、スキーマで作成された新しい表のみです。 論理スキーマのバックアップを可能にするには、行変更トラッキングのためにスキーマを使用可能にした後で、スキーマ内のすべてのカラムナ表を再作成する必要があります。
表のマイグレーション
表の再作成は、例えば ADMIN_MOVE_TABLE または CREATE TABLE ... を使用して、任意の方法で行うことができます。 AS ... WITH DATA (1 つの表から同じスキーマ内の新しい表に * を選択)。 ターゲット表は、ターゲット・スキーマで行変更トラッキングが有効になっていて、ターゲット表タイプで行変更トラッキングがサポートされている場合、行変更トラッキングが有効になっているとして作成されます。 ソース表で行変更トラッキングが有効になっているかどうかは、ターゲット表の選択内容に影響しません。 ユーザーが、行変更が有効になっているスキーマでターゲットが作成されたソース表から新しい隠し列を選択しようとすると、これは、ユーザーが同じ名前のユーザー列を持つ表を作成しようとしてエラー (列名が既に存在する) が発生した場合と同様に処理されます。 CREATE TABLE の実行中に、新しい隠し列の値がソースからターゲットに引き継がれることはありません ... AS (全選択) WITH DATA 操作。
論理バックアップおよび復元を使用した表データの移行
マイグレーションを支援するために、SYSPROC.LOGICAL_BACKUP は、 -backup-migrate オプションを指定することによって、行変更トラッキングが有効になっていないスキーマの論理バックアップ・イメージを取ることができます。 このバックアップの期間中は、スキーマ内の表への読み取りアクセスのみが許可されることに注意してください。 バックアップが完了すると、SYSPROC.LOGICAL_RESTORE (-enable-row-modification-tracking) オプションを使用してバックアップ・イメージをリストアすることができます。 その場合、スキーマは ENABLE ROW MODIFICATION TRACKING として作成され、スキーマ内のすべての表も有効にしようとします。 表の行変更トラッキングが有効にならないようにする、元のスキーマ内の表 DDL/ 条件があると、バックアップは失敗します。