クローニングに関する考慮事項

このトピックでは、Snowflakeのオブジェクト、特にデータベース、スキーマ、および非仮テーブルをクローンする際の重要な考慮事項について説明します。 DDL および DML トランザクション（ソースオブジェクト上）、Time Travel、データ保持期間などの要因は、オブジェクトのクローンに影響を与える可能性があります。

このトピックの内容：

クローンオブジェクトのアクセス制御権限

ソースオブジェクトがデータベースまたはスキーマである場合、クローンは、ソースオブジェクト含まれている子オブジェクトのクローンに対して付与された すべて の権限を継承します。

  • データベースの場合、含まれるオブジェクトには、スキーマ、テーブル、ビューなどがあります。

  • スキーマの場合、含まれるオブジェクトには、テーブル、ビューなどがあります。

コンテナー自体のクローン（データベースまたはスキーマ）は、ソースコンテナーで付与された権限を継承しないことに注意してください。

ほとんどのオブジェクトの CREATE <オブジェクト> ... CLONE ステートメントは、ソースオブジェクトの付与をオブジェクトクローンにコピー しません。しかし、 COPY GRANTS 句をサポートする CREATE <オブジェクト> コマンド (例えば、 CREATE TABLE、 CREATE VIEW) では、オプションでオブジェクトクローンにグラントをコピーすることができます。たとえば、 CREATE TABLE ... CLONE コマンド構文は、 COPY GRANTS パラメーターをサポートします。COPY GRANTS パラメーターが CREATE TABLE ステートメントで指定されている場合、作成操作は OWNERSHIP を除くすべての権限をソーステーブルから新しいテーブルにコピーします。COPY GRANTS 句をサポートする他の CREATE コマンドについても、同じ動作が当てはまります。

それ以外の場合はすべて、新しく作成されたクローンに必要な権限を付与する必要があります（GRANT <権限> ... TO ROLE を使用）。

クローニングとSnowflakeオブジェクト

このセクションでは、特定のSnowflakeオブジェクトに関する特別なクローニングの考慮事項について説明します。

クローンと管理アクセススキーマ

スキーマをクローンして WITH MANAGED ACCESS 句を指定する場合、必要な権限はソーススキーマが管理対象スキーマであるか非管理対象スキーマであるかに応じて異なります。詳細については、 CREATE SCHEMA 権限 をご参照ください。

クローニングおよびオブジェクトパラメーター

クローンされたオブジェクトは、そのオブジェクトがクローンされたときに、ソースオブジェクトに設定されたすべてのオブジェクトパラメーターを継承します。オブジェクトパラメーターがオブジェクトコンテナー (アカウント、データベース、スキーマなど) にセット可能で、ソースオブジェクトに明示的にセットされていない場合、オブジェクトクローンはパラメーターのデフォルト値または最下位レベルでオーバーライドされた値を継承します。オブジェクトパラメーターの詳細については、 パラメーター をご参照ください。

クローニングおよびデフォルトのシーケンス

テーブル内で、列はデフォルト値を生成する シーケンス を参照できます。テーブルがクローンされると、クローンされたテーブルはソースまたはクローンされたシーケンスを参照します。

  • テーブルとシーケンスの両方を含むデータベースまたはスキーマがクローンされる場合、クローンされたテーブルはクローンされたシーケンスを参照します。

  • それ以外の場合、クローンされたテーブルはソースシーケンスを参照します。

    たとえば、シーケンスが別のデータベースまたはスキーマで定義されている場合、クローンされたテーブルはソースシーケンスを参照します。または、テーブル自体だけをクローンする場合、クローンされたテーブルはソースシーケンスを参照します。

    新しいテーブルにソース・シーケンスを使用し続けさせたくない場合は、以下のコマンドを実行してください。

    ALTER TABLE <table_name> ALTER COLUMN <column_name> SET DEFAULT <new_sequence>.nextval;
    Copy

クローン作成と外部キー制約

テーブルには、主キーを含むテーブルを参照する、外部キー制約を含めることができます。外部キー制約のあるテーブルがクローンされると、クローンされたテーブルは、主キーを含むソースまたはクローンされたテーブルを参照します。

  • 両方のテーブルを含むデータベースまたはスキーマがクローンされる場合、外部キーを持つクローンされたテーブルは、他のクローンされたテーブルの主キーを参照します。

  • テーブルが別々のデータベースまたはスキーマにある場合、クローンされたテーブルは、ソーステーブルの主キーを参照します。

クローニングおよびクラスタリングキー

テーブルには、 クラスタリングキー として指定された列のサブセットを含めて、同じマイクロパーティション内の類似の行を同じ場所に配置できます。クラスタリングキーを使用してテーブルがクローンされると、クラスタリングキーを使用して新しいテーブルが作成されます。デフォルトでは、 自動クラスタリング は新しいテーブルに対して一時停止されています。新しいテーブルの自動クラスタリングを再開するには、次のコマンドを実行します。

ALTER TABLE <name> RESUME RECLUSTER
Copy

クローニングおよびステージ

外部ステージを個別にクローニングできます。外部ステージは、外部クラウドストレージ内のバケットまたはコンテナーを参照します。外部ステージをクローニングしても、参照されるクラウドストレージには影響しません。

データベースまたはスキーマをクローンするときに、オプションで内部名前付きステージをクローンできます。

データベースまたはスキーマをクローンする場合、

  • クローニング操作の開始時にソースに存在していた外部の名前付きステージがクローニングされます。

  • テーブルはクローンされます。つまり、各テーブルに関連付けられた内部ステージもクローンされます。ソース・データベースまたはスキーマのテーブル・ステージに存在したデータファイルはクローンにコピーされません（つまり、クローンされたテーブル・ステージは空になります）。

  • INCLUDE INTERNAL STAGES 句を使用すると、内部名前付きステージはクローニングされます。詳細情報については、 内部ステージクローニング使用上の注意 をご覧ください。

クローニングと Apache Iceberg™ テーブル

ストレージ

クローン化されたIcebergテーブルのストレージは、他のクローン化されたSnowflakeオブジェクトのストレージと同じように機能します。クローンは、ソーステーブルと同じ基礎となるストレージを共有します。

クローン化されたオブジェクトのストレージの仕組みについては、 クローン化されたテーブル、スキーマ、データベースストレージ を参照してください。

Icebergテーブルのストレージについては、 Apache Iceberg™ テーブルのストレージ を参照してください。

データ操作言語（DML）コマンド

クローン化されたIcebergテーブルでも、通常のSnowflake管理テーブルと同様に DML コマンドを使用できます。説明と例については、 Snowflakeで管理されたテーブルで DML コマンドを使用する を参照してください。

クローン化されたテーブルに対する DML 操作では、Snowflakeは新しいデータファイルを生成し、ソーステーブルのベースロケーションに格納します。分岐したデータファイルはソーステーブルには影響しません。ソーステーブルに対する DML 操作は、ソーステーブルのデータファイルにのみ反映されます。

Icebergのメタデータ

クローンされたテーブルに対して、Snowflakeはソーステーブルとは異なるIcebergメタデータファイルを生成します。例えば、クローン化されたIcebergテーブルは、一意の table-uuid、 last-sequence-number、その他のプロパティを持つ独自の metadata.json ファイルを持ちます。クローン化されたテーブルスナップショットには、ソーステーブルのスナップショット情報は含まれません。

クローニングとイベントテーブル

イベントテーブルをクローンする場合、イベントテーブル間でのみクローンできます。つまり、通常のテーブルからイベントテーブルにクローンすることも、イベントテーブルから通常のテーブルにクローンすることもできません。

クローニングとパイプ

データベースまたはスキーマがクローニングされるとき、ソースコンテナー内の内部（つまり Snowflake）ステージをリファレンスするパイプは、クローニングされ ません。

ただし、外部ステージを参照するパイプはクローンされます。これには、 INTEGRATION パラメーターが設定されているすべてのパイプオブジェクトが含まれます。このパラメーターは、Google Cloud StorageまたはMicrosoft Azure BLOBストレージ内のファイルからデータをロードするときに、Snowpipeの自動インジェストを有効にする通知統合をポイントします。

ステージロケーション（例えば、ブロブストレージコンテナー）にデータファイルが作成されると、ステージロケーションに一致するすべてのパイプに通知のコピーが送信されます。これにより、次の動作が発生します。

  • パイプ定義の COPY ステートメントでテーブルが完全修飾されている場合 (db_name.schema_name.table_name または schema_name.table_name の形式)、Snowpipe は各パイプのソーステーブル (COPY ステートメントの database.schema.table) に重複データの読み込みを行います。

  • パイプ定義でテーブルが完全修飾されて いない 場合、Snowpipeはソースおよびクローンデータベース/スキーマのテーブル (例えば mytable) にデータの読み込みを行います。

パイプクローンのデフォルトの状態は次のとおりです。

  • AUTO_INGEST = FALSE の場合、クローンされたパイプはデフォルトで一時停止します。

  • AUTO_INGEST = TRUE の場合、クローンされたパイプは STOPPED_CLONED 状態に設定されます。この状態では、パイプは新しくステージングされたファイルによるイベント通知を蓄積しません。パイプが明示的に再開されると、新しいイベント通知の結果としてトリガーされたデータファイルのみを処理します。

ALTER PIPE ... RESUME ステートメントを実行すると、どちらの状態のパイプクローンも再開できます。

クローニングと検索の最適化

検索最適化サービス が有効になっているテーブルをクローンすることができます。そうすると、対応する検索アクセスパスは ゼロコピークローン となります。しかし、クローン化された検索アクセスパスが最新でない場合、クローン化されたテーブルが変更されなくても、検索アクセスパスがクローン化されたテーブルの現在の状態に追いつかなければならないため、メンテナンスコストが発生する可能性があります。クローニングと検索の最適化については、 テーブル、スキーマ、またはデータベースのクローニング を参照してください。

クローニングとストリーム

現在、ソーステーブルとストリームを含むデータベースまたはスキーマのクローンが作成されると、（クローン内の）ストリーム内の未使用のレコードにアクセスできなくなります。この動作は、テーブルの Time Travel と一致しています。テーブルのクローンが作成される場合、テーブルクローンの履歴データは、クローンが作成された時間/時点で開始されます。

クローニングとタスク

タスクを含むデータベースまたはスキーマがクローンされると、クローン内のタスクはデフォルトで一時停止されます。タスクは個別に再開できます（ ALTER TASK ... RESUME を使用）。

クローニングとアラート

アラートを含むデータベースまたはスキーマがクローンされると、クローン内のアラートはデフォルトで 中断 されます。

中断したアラートを再開するには、 ALTER ALERT ... RESUME コマンドを使用します。

クローニングとガバナンスオブジェクト

マスキングポリシーおよび行アクセスポリシー:

次のアプローチは、クローンされたオブジェクトにアクセスする際に、テーブルまたはビューに対する SELECT 権限を持つユーザーからデータを保護するのに役立ちます。

  • 個別のポリシーオブジェクトのクローニングはサポートされていません。

  • スキーマのクローニングにより、スキーマ内のすべてのポリシーがクローニングされます。

  • クローンされたテーブルは、ソーステーブルと同じポリシーにマップされます。つまり、ベーステーブルまたはその列にポリシーが設定されている場合、そのポリシーはクローンテーブルまたはその列にアタッチされます。

    • テーブルまたはビューがソーススキーマ/データベースに存在し、同じスキーマまたはデータベースにあるポリシーへの参照がある場合、クローンされたテーブルまたはビューは、ソーススキーマ/データベースにあるポリシーの代わりに、対応するクローンされたポリシー（ターゲットスキーマ/データベース内）にマップされます。

    • ソーステーブルが別のスキーマのポリシー（つまり、外部参照）を参照している場合、クローンされたテーブルは外部参照を保持します。

詳細については、 CREATE <オブジェクト> ... CLONE をご参照ください。

次もご参照ください。

タグ:

  • ソースオブジェクト（例: テーブル）にあるタグの関連付けは、クローンされたオブジェクトで維持されます。

  • データベースまたはスキーマの場合は、

    そのデータベースまたはスキーマに格納されているタグもクローンされます。

    データベースまたはスキーマがクローンされると、そのスキーマまたはデータベースに存在するタグもクローンされます。

    テーブルまたはビューがソーススキーマ/データベースに存在し、同じスキーマまたはデータベースにあるタグへの参照がある場合、クローンされたテーブルまたはビューは、ソーススキーマまたはデータベースにあるタグの代わりに、対応するクローンタグ（ターゲットスキーマ/データベース内）にマップされます。

タグベースのマスキングポリシー:

タグがマスキングポリシーおよびテーブルとは異なるスキーマに格納されているタグベースのマスキングポリシーの場合は、マスキングポリシーおよびテーブルを含むスキーマをクローンすると、クローンされたスキーマ内ではなく、ソーススキーマ内のマスキングポリシーによって保護されるクローンされたテーブルが生成されます。

ただし、タグ、マスキングポリシー、およびテーブルがすべてスキーマに存在するタグベースのマスキングポリシーの場合は、スキーマをクローンすると、ソーススキーマ内ではなく、クローンされたスキーマ内のマスキングポリシーによってテーブルが保護されます。

テーブルが別のスキーマまたはデータベースにクローンまたは移動され、そのスキーマまたはデータベースで設定されたタグベースのマスキングポリシーによって元々保護されていた場合、そのテーブルはソーススキーマまたはデータベースで設定されたタグベースのマスキングポリシーによっては保護されません。ターゲットスキーマまたはデータベースにタグベースのマスキングポリシーが設定されている場合、テーブルはターゲットスキーマまたはデータベースに設定されたタグベースのマスキングポリシーによって保護されます。

クローニングと差分プライバシー

差分プライバシー で保護されているテーブルまたはビューをクローニングすると、次のような動作になります。

プライバシーポリシー

プライバシー保護されたテーブルやビューをクローンすると、そのオブジェクトもプライバシー保護されます。プライバシーポリシーがクローンされるかどうかは、何をクローニングするかによって決まります。

  • プライバシー保護されたテーブルのみをクローニングする場合、プライバシーポリシーはクローンされません。

  • テーブルとプライバシーポリシーの両方を含むスキーマをクローンすると、プライバシーポリシーがクローンされます。

  • テーブルとプライバシーポリシーの両方を含むスキーマを含むデータベースをクローンすると、プライバシーポリシーがクローンされます。

プライバシー・ポリシーとテーブルが異なるスキーマにある場合、テーブルのデータベースまたはスキーマをクローニングしても、プライバシー・ポリシーはクローンされません。この場合、プライバシーポリシーは自動的にクローンされたオブジェクトに関連付けられます。

プライバシー・ドメイン

プライバシー保護されたテーブルまたはビューをクローンすると、列に設定されたプライバシードメインもクローンされます。

プライバシー保護されたテーブルやビューを REFERENCE プライバシードメインでクローニングする場合は、以下の点に注意してください。

  • プライバシー保護されたテーブルをクローンし、参照されるテーブルをクローンしない場合、新しいテーブルは同じテーブルを参照し続けます。

  • プライバシー保護されたテーブルと参照されるテーブルの両方をクローンした場合、新しいプライバシー保護されたテーブルは、参照されるテーブルのクローンされた新しいバージョンを参照します。

  • REFERENCE プライバシードメインが自分自身を参照する場合、新しくクローンされたテーブルは、元のテーブルではなく自分自身を参照します。

クローニングおよびデータベースロール

ターゲットデータベースに既存のデータベースロールがない場合は、 CREATE DATABASE ROLE ... CLONE コマンドを使用して、データベースロールをクローンすることができます。詳細については、 CREATE <オブジェクト> ... CLONE をご参照ください。

クローニングとJava UDFs

Java UDF は、Java UDF を含むデータベースまたはスキーマがクローンされるときに、クローンできます。クローンを作成するには、Java UDF が特定の条件を満たす必要があります。詳細については、 クローニングの制限 をご参照ください。

Snowflakeクラスのクローニングとインスタンス

インスタンスを含むスキーマがクローンされると、 CUSTOM_CLASSIFIER のインスタンスがクローンされます。他のSnowflake クラス のインスタンスのクローニングはサポート されていません。

クローニングに対する DDL の影響

クローニングは高速ですが、特に大容量オブジェクト（テーブルなど）については、即座にはできません。そのため、クローニングの実行中に DDL ステートメントがソース オブジェクトに対して実行された場合（スキーマのテーブル名の変更など）、その変更がクローンに反映されない可能性があります。これは、 DDL ステートメントがアトミックであり、複数ステートメントトランザクションの一部ではないためです。

さらに、Snowflakeはクローニング操作の開始時にどのオブジェクト名が存在し、どのオブジェクト名が変更されたかを記録しません。そのため、ソースの子オブジェクトの名前を変更（またはドロップして再作成）する DDL ステートメントは、進行中のクローニング操作と競合し、名前の競合を引き起こす可能性があります。

次の例では、 t_sales テーブルがドロップされ、また別のテーブルが変更され、親データベースのクローン作成中にドロップされたテーブルと同じ名前が付けられているため、エラーが発生します。

CREATE OR REPLACE DATABASE staging_sales CLONE sales;

DROP TABLE sales.public.t_sales;

ALTER TABLE sales.public.t_sales_20170522 RENAME TO sales.public.t_sales;
Copy
002002 (42710): None: SQL compilation error: Object 'T_SALES' already exists.

Tip

クローニング操作中の名前解決の競合を避けるために、クローニング操作が完了するまで、オブジェクトの名前をドロップされたオブジェクトが以前使用していた名前に変更しないことをお勧めします。

クローニングに対する DML およびデータ保持の影響

データ保持期間 は、オブジェクトでTime Travelアクションを実行するためにSnowflakeが履歴データを保持する日数を指定します。Time Travelのために保持されるデータはテーブルレベルでストレージコストが発生するため、ユーザーによってはこのパラメーターをいくつかのテーブルで 0 に設定し、これらのテーブルのデータ保持を事実上無効にしています（つまり、値が 0 に設定されている場合、 DML トランザクションのために保持されたTime Travelデータはパージされ、無視できるほどの追加ストレージコストが発生します）。

特に大きなテーブルの場合、クローニング操作には時間がかかります。この期間中、 DML トランザクションはソーステーブルのデータを変更できます。その後、Snowflakeは、操作の開始時に存在していたテーブルデータをクローンしようとします。ただし、クローニング中に発生する DML トランザクションのデータがパージされると（テーブルの保持時間が 0 であるため）、操作を完了するためのデータがないため、次のようなエラーが生成されます。

ProgrammingError occurred: "000707 (02000): None: Data is not available." with query id None

Tip

回避策として、オブジェクトをクローニングする際に、次のベストプラクティスの どちらか をお勧めします。

  • 可能であれば、クローニング操作が完了するまで、ソースオブジェクト（またはその子）で DML トランザクションを実行しないでください。

  • これが不可能な場合は、クローニングを開始する前に、スキーマ（またはデータベース全体をクローンする場合はデータベース）のすべてのテーブルに DATA_RETENTION_TIME_IN_DAYS=1 を設定します。操作が完了したら、必要に応じて、ソース内にあるこれらのテーブルのパラメーター値を 0 にリセットしてください。

    クローンされたテーブルの値を 0 に設定することもできます（クローンされたテーブルに DML 変更を加える予定があり、テーブルのTime Travelのために追加のストレージ・コストを発生させたくない場合）。

Time Travelを使用したクローニング（データベース、スキーマ、テーブル、動的テーブル、、イベントテーブル、ストリームのみ）

このセクションでは、 Time Travel を使用して、過去の特定の時間/ポイントでオブジェクトをクローンする際に考慮する情報を提供します。

履歴オブジェクトのクローニング

AT | BEFORE 句でセットした時点/時点でソース・オブジェクトが存在しなかった場合は、エラーが返されます。

次の例では、CREATE TABLE ... CLONE ステートメントは、ソーステーブルが存在しなかった過去（30分前）の時点でクローンしようとします。

CREATE TABLE t_sales (numeric integer) data_retention_time_in_days=1;

CREATE OR REPLACE TABLE sales.public.t_sales_20170522 CLONE sales.public.t_sales at(offset => -60*30);
Copy
002003 (02000): SQL compilation error:
Object 'SALES.PUBLIC.T_SALES' does not exist.

クローンされたデータベースまたはスキーマ内の 子 オブジェクトで、指定された時点/時点で存在しなかったものはクローンされません。

次のシナリオは、クローニング操作に失敗します。

  • 指定されたTime Travel時間が、クローンされたデータベースまたはスキーマの 現在の子 の保持時間を超えている場合。

    Time Travelからパージされた子オブジェクトの回避策として、 CREATE <object> ... CLONE コマンドの IGNORE TABLES WITH INSUFFICIENT DATA RETENTION パラメーターを使用します。詳細については、 子オブジェクトとデータ保持時間 をご参照ください。

  • AUTO_INGEST = TRUE セットにあるパイプオブジェクトが（CREATE OR REPLACE PIPE 構文を使用して）再作成された場合、または AT | BEFORE 句で指定された時点以降に削除された場合。この制限は、 REST API (つまり、 AUTO_INGEST = FALSE) を使用して手動でSnowpipeインジェスト用に作成されたパイプオブジェクトには適用されません。

  • IGNORE HYBRID TABLES パラメーター が指定されておらず、指定されたデータベースまたはスキーマにハイブリッド・テーブルが存在する場合。

子オブジェクトとデータ保持時間

子オブジェクト（テーブルなど）の データ保持期間 が親オブジェクト（データベースやスキーマなど）のデータ保持期間よりも短い場合、子オブジェクトの履歴データは親オブジェクトの履歴データがTime Travelの範囲外に移動する前にTime Travelの範囲外に移動します。

例えば、データベース db1 の データ保持期間 は7日間で、 db1 のテーブル t1 のデータ保持期間は1日です。12時間前の時点でTime Travelを使用して db1 をクローンすると、クローン操作によって db1 のクローンが正常に作成され、クローンされたテーブル t1 が含まれています。

しかし、2日前の時点で db1 をクローンしようとすると、その時点のテーブル t1 の履歴データはTime Travelでは利用できなくなり、クローン操作は失敗します。

回避策として、 CREATE <オブジェクト> ... CLONE コマンドの IGNORE TABLES WITH INSUFFICIENT DATA RETENTION パラメーターを使用してデータベースまたはスキーマをクローンします。このパラメーターは、クローン操作に指定した時点でTime Travelで利用可能な履歴データがないテーブルをスキップします。

履歴オブジェクトメタデータのクローニング

オブジェクトクローンは、 CREATE <オブジェクト> ... CLONE ステートメントが実行された時点、または Time Travel を使用して過去に指定された時間/ポイントで、現在のソースオブジェクトの 名前 および 構造 を継承します。オブジェクトクローンは、Time Travelが使用されているかどうかに関係なく、ステートメントの実行時にソースオブジェクトで現在使用されているコメントやテーブルクラスタリングキーなどの他のメタデータを継承します。

注釈

長いクローニング操作の一貫した動作を保証するために、 CREATE <オブジェクト> ... CLONE ステートメントに AT または BEFORE 句が指定されていない場合、クローニング操作は内部的に AT 句の値をステートメントが開始された時のタイムスタンプとしてセットします。

クローニングと複製

詳細については、 複製とクローニング をご参照ください。

言語: 日本語