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

このトピックでは、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 <権限> を使用)。

クローニングと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

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

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

内部(つまりSnowflake)の名前付きステージは、クローン できません

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

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

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

  • 内部の名前付きステージは、クローン されません

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

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

クローニングとパイプ

データベースまたはスキーマがクローンされる場合、内部(つまり、Snowflake)ステージを参照するソースコンテナーに含まれるパイプは、クローン されません

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

データファイルがステージの場所に作成されるとき(例: BLOBストレージコンテナー)、通知のコピーがステージの場所に一致するすべてのパイプに送信されます。これにより、次の動作が発生します。

  • パイプ定義の 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 をご参照ください。

次もご参照ください。

タグ:

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

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

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

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

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

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

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

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

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

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

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

クローニングとJava UDFs

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

クローニングに対する 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;

002002 (42710): None: SQL compilation error: Object 'T_SALES' already exists.
Copy

Tip

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

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

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

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

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

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);

002003 (02000): SQL compilation error:
Object 'SALES.PUBLIC.T_SALES' does not exist.
Copy

指定された時間/時点で存在しなかった、クローンされたデータベースまたはスキーマにある オブジェクトは、一切クローンされません。

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

  • 指定された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インジェストのために作成されたパイプオブジェクトには適用されません。

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

子オブジェクト(テーブルなど)の データ保持期間 が親オブジェクト(データベースやスキーマなど)のデータ保持期間よりも短い場合、子オブジェクトの履歴データは親オブジェクトの履歴データが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 句の値をタイムスタンプとして設定します。