Openflow Connector for SQL Server について¶

データ複製¶

コネクタは、単一のSQL Serverインスタンス内の複数のSQL Serverデータベースからのテーブルの複製をサポートします。コネクタは、宛先Snowflakeデータベースの個別のスキーマにある異なるデータベースから複製されたテーブルを作成します。

ソースデータベース名、ソーススキーマ名、テーブル名を次の形式で組み合わせて、複製されたテーブルを参照します。

<database_name>.<schema_name>.<table_name>

複製される各ソースデータベースのスキーマごとに、コネクタは宛先のSnowflakeデータベースに個別のスキーマを作成します。宛先スキーマの名前は、次の例に示すように、ソースデータベース名とソーススキーマ名をアンダースコア文字（_）で区切った組み合わせで表されます。

<source_database_name>_<source_schema_name>

次の例に示すように、コネクタは宛先スキーマにソーステーブル名と同じ名前のテーブルを作成します。

<destination_database>_<destination_schema_name>.<source_table_name>

テーブルの複製方法¶

コネクタは以下のステージでテーブルを複製します。

1. スキーマのイントロスペクション:コネクタは、列名やタイプなどのソーステーブル内の列を検出し、それらをSnowflakeとコネクタの制限に照らして検証します。検証に失敗するとこのステージが失敗し、サイクルが完了します。このステージが成功して完了すると、コネクタは空の宛先テーブルを作成します。

2. スナップショットのロード:コネクタは、ソーステーブルで使用可能なすべてのデータを宛先テーブルにコピーします。このステージが失敗すると、コネクタはデータの複製を停止します。成功して完了すると、ソーステーブルのデータが宛先テーブルで使用できるようになります。

3. 増分ロード: コネクタはソーステーブルの変更を追跡し、その変更を宛先テーブルに適用します。このプロセスはテーブルが複製から削除されるまで続きます。このステージで失敗すると、問題が解決するまでソーステーブルの複製が永久的に停止します。

スナップショットロードのバイパスと増分ロードプロセスの使用については、 増分複製 をご参照ください。

テーブル複製ステータス¶

接続エラーなどの一時的な障害は、テーブルの複製を妨げません。ただし、サポートされていないデータ型などの永続的な障害はテーブルの複製を妨げます。

複製の問題をトラブルシューティングする、または複製フローからテーブルが正常に削除されたことを確認するには、テーブル状態ストアをチェックします。

1. Openflowランタイムキャンバスで、プロセッサーグループを右クリックし、Controller Services を選択します。コントローラーサービスをリストしたテーブルが表示されます。

2. Table State Store というラベルの行を見つけて、行の右側にある More ボタンをクリックし、View State を選択します。

テーブルとその現在の状態が書かれたリストが表示されます。検索ボックスに入力して、テーブル名でリストをフィルタリングします。可能な状態は次のとおりです。

• NEW:テーブルは複製がスケジュールされていますが、複製は開始されていません。

• SNAPSHOT_REPLICATION:コネクタは既存のデータをコピーしています。このステータスは、すべての記録が宛先テーブルに保存されるまで表示されます。

• INCREMENTAL_REPLICATION:コネクタは変更をアクティブに複製しています。このステータスは、スナップショット複製の終了後に表示され、テーブルが複製から削除されるか、複製が失敗するまで無期限に表示され続けます。

• FAILED:エラーのため、複製が完全に停止しています。

Replication state for table <database_name>.<schema_name>.<table_name> changed from <old_state> to <new_state>

永続的な障害によりテーブルの複製が妨げられた場合は、複製からテーブルが削除されます。失敗の原因となった問題に対処した後、複製にテーブルを追加し直すことができます。詳細については、:ref:`テーブル複製の再開 <label-of_sql_server_restart_table_replication>`をご参照ください。

宛先テーブルのメタデータ列¶

各宛先テーブルには、複製情報を追跡する次のメタデータ列が含まれます。

ソフト削除された行¶

ソーステーブルから行が削除されても、コネクタはそれを宛先テーブルから物理的に削除しません。代わりに、``_SNOWFLAKE_DELETED``メタデータ列を``true``に設定することにより、行は削除済みとしてマークされます。

このアプローチにより、以下が可能になります。

• 監査またはコンプライアンスの目的で履歴データを保持する。

• 必要に応じて削除されたレコードをクエリする。

• 要件に基づいて、データを完全に削除するタイミングと方法を決定する。

アクティブな（削除されていない）行のみをクエリするには、``_SNOWFLAKE_DELETED``列でフィルターします。

SELECT * FROM my_table WHERE _SNOWFLAKE_DELETED = FALSE;

削除された行をクエリするには、以下のようにします。

SELECT * FROM my_table WHERE _SNOWFLAKE_DELETED = TRUE;

ドロップされた列¶

ソーステーブルから列がドロップされても、コネクタは宛先テーブルから対応する列をドロップしません。代わりに、履歴値を保持するために``__SNOWFLAKE_DELETED``サフィックスを追加して列の名前が変更されます。

たとえば、``EMAIL``という名前の列がソーステーブルからドロップされた場合、宛先テーブルでは``EMAIL__SNOWFLAKE_DELETED``に名前が変更されます。列がドロップされる前に存在していた行は元の値を保持しますが、ドロップ後に追加された行はこの列に``NULL``を持ちます。

名前が変更された列から履歴値を引き続きクエリできます。

SELECT EMAIL__SNOWFLAKE_DELETED FROM my_table;

列の名前の変更¶

CDC（変更データキャプチャ）メカニズムの制限により、コネクタは、列の名前変更と、列のドロップおよびその後の新しい列の追加を区別できません。その結果、ソーステーブルで列の名前を変更すると、コネクタはこれを元の列のドロップと、新しい名前の新しい列の追加という2つの別個の操作として扱います。

たとえば、ソーステーブルで列の名前を``A``から``B``に変更した場合、宛先テーブルには次が含まれます。

• A__SNOWFLAKE_DELETED:名前変更前の値が含まれます。名前変更後に追加された行は、この列が``NULL``です。

• B:名前変更後の値が含まれます。名前変更前に存在していた行は、この列が``NULL``です。

SELECT
    COALESCE(B, A__SNOWFLAKE_DELETED) AS A_RENAMED_TO_B
FROM my_table;

SELECT
    CASE
        WHEN B IS NOT NULL THEN B
        ELSE A__SNOWFLAKE_DELETED
    END AS A_RENAMED_TO_B
FROM my_table;

CREATE VIEW my_table_unified AS
SELECT
    *,
    COALESCE(B, A__SNOWFLAKE_DELETED) AS A_RENAMED_TO_B
FROM my_table;

ジャーナルテーブル¶

増分複製において、ソースデータベースからの変更は、宛先テーブルにマージされる前に、最初にジャーナルテーブルに書き込まれます。コネクタは、ジャーナルテーブルからデータを自動的に削除しません。このデータは、監査、デバッグ、再処理の目的で役立つ場合があります。

ジャーナルテーブルは、対応する宛先テーブルと同じスキーマで作成され、次の命名規則に従います。

<TABLE_NAME>_JOURNAL_<timestamp>_<number>

条件:

• ``<TABLE_NAME>``は宛先テーブルの名前である。

• ``<timestamp>``はUnixエポック形式（1970年1月1日からの秒数）の作成タイムスタンプであり、一意性を確保する。

• ``<number>``は1から始まり、ソーステーブルのスキーマ変更または列フィルターの変更により宛先テーブルスキーマが変更されるたびに増加します。

たとえば、宛先テーブルが``SALES.ORDERS``の場合、ジャーナルテーブルの名前は``SALES.ORDERS_JOURNAL_1705320000_1``になる可能性があります。