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

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

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

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

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

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

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

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

  新しいテーブルでソースシーケンスを引き続き使用したくない場合は、次のコマンドを実行します。

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

  Copy

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

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

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

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

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

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

ALTER TABLE <name> RESUME RECLUSTER

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

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

内部（つまり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 が特定の条件を満たす必要があります。詳細については、 クローニングの制限 をご参照ください。

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

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

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

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