Openflow Connector for Oracle について¶

1.組み込みライセンス（Snowflake提供）¶

SnowflakeはOracle XStreamライセンスを有料で直接提供します。このモデルにより、Oracleとの直接契約なしでXStreamの複製を利用できます。詳しくは、:ref:`組み込みライセンスの詳細<label-oracle_embedded_license_details>`および`Openflow Connector for Oracle Addendum<https://www.snowflake.com/en/legal/optional-offerings/offering-specific-terms/openflow-oracle-terms/>`_を参照してください。

2.独立ライセンス（Bring Your Own License - BYOL）¶

XStream資格を含む独自のOracleライセンス（たとえば、Oracle GoldenGateライセンス）を提供します。詳しくは、:ref:`独立ライセンス（BYOL）の詳細<label-oracle_byol_license_details>`を参照してください。

請求¶

Oracle XStreamサービスは毎月請求され、Snowflakeの容量残高から差し引かれます。料金には、ライセンス料金とサポート&メンテナンス（S&M）料金の2つの要素があります。ライセンス料金は、ソースOracleデータベースのプロセッサーコアの数に、Oracleプロセッサーコア係数を掛けて計算されます。

契約（「61日」ルール）¶

最初の60日間は、ライセンスされたコア16個まで無料です。ただし、60日間の試用期間を超えてコネクタをアクティブ化すると、キャンセルできない36か月の請求期間（「初期期間」）が開始されます。

• 自動変換:請求は61日目から自動的に開始されます。請求を回避するには、60日目より前に:ui:Admin » Terms » :ui:`Openflow for Oracle`ダッシュボードでトライアルをキャンセルする必要があります。

• ロックイン:この初期期間中にSnowflake契約が終了した場合、初期期間の残額全体がすぐに支払われます。

期限後の更新とペナルティ¶

初期期間の後、ライセンス料金は0ドルになりますが、サポートおよびメンテナンス（S&M）料金は継続します。

• オプトアウトの結果:Admin » Terms » :ui:`Openflow for Oracle`のダッシュボードからS&M更新をオプトアウトできます。ただし、S&Mカバレッジが停止すると、コネクタプロセッサはロックされます。操作を再開するには、NEW組み込みライセンスを購入する必要があります（36か月の全額契約がリセットされます）。

要件¶

コネクタ構成において、プロセッサーコアの数と正しいコア係数を正確に報告する責任があります。ソースデータベースのハードウェアが変更された場合、この情報を最新の状態に保つ必要があります。

制限事項¶

このオプションは以下には利用できません。

• 公共部門のエンティティ（例：政府や教育のエンティティ）。

• GCP Marketplaceを通じてSnowflakeを購入しているお客様。

• サードパーティの再販業者を通じてSnowflakeと契約しているお客様（例：CDW、Optiv）。

設定¶

組み込みライセンスの設定方法：

• UIで提示される`Openflow Connector for Oracle Addendum<https://www.snowflake.com/en/legal/optional-offerings/offering-specific-terms/openflow-oracle-terms/>`_を確認して同意します。

• :ui:`Embedded License`のタイプを選択します。

• ソースOracleデータベースのCPUコア数の詳細を入力します。**合計コア**（ソースデータベースサーバー上の物理コアの合計数）および**コア係数**（Oracleプロセッサーコア係数。たとえば、Intelプロセッサーの場合は0.5）。正しい値については、Oracleプロセッサコア係数表を参照してください。

要件¶

コネクタの使用が既存のOracleライセンス契約の条項に準拠していることを確認する責任はご自身にのみあります。Snowflakeは、Oracle資格を検証または監査しません。

設定¶

独立ライセンスの設定方法（BYOL）：

• UIで提示される`Openflow Connector for Oracle Addendum<https://www.snowflake.com/en/legal/optional-offerings/offering-specific-terms/openflow-oracle-terms/>`_を確認して同意します。

• :ui:`Independent License`のタイプを選択します。

コネクタを構成する場合は、コア数や請求関連情報を入力せずに続行します。

テーブルの複製方法¶

テーブルは以下のステージで複製されます。

1. スキーマのイントロスペクション:コネクタは、列名やタイプなどのソーステーブル内の列を検出し、それらをSnowflakeとコネクタの`制限`_に照らして検証します。検証に失敗するとこのステージは失敗し、サイクルが完了します。このステージが正常に完了すると、コネクタは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_oracle_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``になる可能性があります。