データベースの複製の考慮事項

このトピックでは、セカンダリデータベース内における特定のSnowflake機能の動作について説明し、複製されたオブジェクトとデータを操作するための一般的なガイダンスを提供します。

このトピックの内容:

このセクションでは、セカンダリデータベースの特定のSnowflake機能の動作について説明し、複製されたオブジェクトとデータを操作するための一般的なガイダンスを提供します。

複製と自動クラスタリング

プライマリデータベースでは、Snowflakeは 自動クラスタリング を使用してクラスター化されたテーブルを監視し、必要に応じてそれらを再クラスター化します。更新操作の一部として、クラスター化されたテーブルは、テーブルのマイクロパーティションの現在の並べ替えを使用してセカンダリデータベースに複製されます。そのため、セカンダリデータベース内のクラスター化されたテーブルで再クラスタリングが再度実行されることは ありません 。これは冗長です。

セカンダリデータベースにクラスター化されたテーブルが含まれており、データベースがプライマリデータベースになると、Snowflakeはこのデータベースのテーブルの自動クラスタリングを開始すると同時に、以前のプライマリデータベースのクラスター化テーブルの監視を一時停止します。

マテリアライズドビューの自動クラスタリングの詳細については、このトピックの 複製とマテリアライズドビュー をご参照ください。

複製とマテリアライズドビュー

プライマリデータベースでは、Snowflakeはマテリアライズドビューの自動バックグラウンドメンテナンスを実行します。ベーステーブルが変更されると、テーブルで定義されているすべてのマテリアライズドビューは、Snowflakeが提供する計算リソースを使用するバックグラウンドサービスによって更新されます。さらに、マテリアライズドビューに対して自動クラスタリングが有効になっている場合、ビューはプライマリデータベースで必要に応じて監視および再クラスター化されます。

リフレッシュ操作は、マテリアライズドビューの 定義 をセカンダリデータベースに複製します。マテリアライズドビューの データ は複製されません。セカンダリデータベースのマテリアライズドビューの自動バックグラウンドメンテナンスは、デフォルトで有効になっています。プライマリデータベースにあるマテリアライズドビューの自動クラスタリングが有効になっている場合は、セカンダリデータベースにあるマテリアライズドビューの自動モニタリングと再クラスタリングも有効になります。

ダングリングリファレンス (このトピック内)もご参照ください。

注釈

  • マテリアライズドビューの自動バックグラウンド同期の料金は、セカンダリデータベースを含む各アカウントに請求されます。

複製と外部テーブル

現在、プライマリデータベースの外部テーブルにより、レプリケーションまたは更新操作が失敗し、次のエラーメッセージが表示されます。

003906 (55000): SQL execution error:
Primary database contains an external table '<database_name>'.Replication of a database with external table is not supported

この制限を回避するには、外部テーブルを複製されていない別のデータベースに移動することをお勧めします。または、データベースを別のアカウントに移行する場合は、プライマリデータベースのクローンを作成し、クローンから外部テーブルを削除してから、クローンデータベースを複製することができます。ターゲットアカウントでセカンダリデータベースを昇格した後、データベースに外部テーブルを再作成する必要があります。

複製およびポリシー(マスキングおよび行アクセス)

マスキング ポリシーと 行アクセス ポリシーで次のいずれかの条件に該当する場合は、最初の複製操作または後続の更新操作に失敗します。

  • プライマリデータベースはEnterprise(またはそれ以上)のアカウントにあり、ポリシーを含んでいますが、下位エディションには、複製が承認された1つ以上のアカウントがあります。

  • プライマリデータベースに含まれるポリシーには、別のデータベースにあるポリシーへの参照があります。

複製およびテーブルストリーム

複製されたデータベースオブジェクト に示されているように、現在、プライマリデータベースのテーブルストリームは、セカンダリデータベースに複製されません。デルタストリームはセカンダリテーブルに作成できますが、追加専用ストリームを作成しようとすると、ユーザーエラーが発生します。 CHANGES 句も同様に機能します。セカンダリデータベースのテーブルのデルタ変更データを追跡するには、セカンダリデータベースのテーブルのクエリで CHANGES 句を使用します。

さらに、テーブルの変更追跡が有効になっている場合は、セカンダリデータベースが更新されたときに現在のテーブルバージョンのみが複製されます。更新間にあるテーブルバージョンは複製されません。セカンダリデータベースのテーブルにある追加のみの変更データを追跡するには、現在、セカンダリデータベースをプライマリデータベースとして機能するように昇格する必要があります。その後ユーザーは、同じデータベースまたは同じアカウントの別のデータベースにテーブルストリームを作成できます。これらのテーブルストリームは、セカンダリデータベースが昇格された後に、開始および完了したテーブルの変更のみを追跡します。

テーブルを格納するデータベースがプロモートされた時点でストリームを作成するには、 CREATE STREAM ... AT | BEFORE 構文を使用します。 AT | BEFORE 句は、テーブルの履歴データが要求される過去のポイントを決定します。

Time Travel

Time Travel を使用してセカンダリデータベースのテーブルとビューをクエリすると、プライマリデータベースで同じクエリを実行した場合とは異なる結果が生成される可能性があります。

履歴データ

Time Travelを使用してプライマリデータベースでクエリできる履歴データは、セカンダリデータベースに複製されません。

例えば、Snowpipeを使用してデータが10分ごとにテーブルに継続的にロードされ、セカンダリデータベースが1時間ごとに更新されるとします。更新操作では、テーブルの最新バージョンのみが複製されます。保持期間内のテーブルの1時間ごとのバージョンは、Time Travelを使用したクエリで使用できますが、1時間以内の反復バージョン(個々のSnowpipeロード)は使用できません。

データ保持期間

セカンダリデータベース内のテーブルのデータ保持期間は、プライマリデータベース内のテーブルに書き込まれた DML 操作(つまり、データの変更または削除)でセカンダリデータベースが更新されると始まります。

複製と大規模でチャーン率の高いテーブル

テーブルの1つ以上の行が更新または削除されると、このデータをプライマリデータベースに保存する、影響を受けるすべてのマイクロパーティションが再作成され、セカンダリデータベースと同期する必要があります。大規模でチャーン率の高いディメンションテーブルの場合、複製コストがかなり高くなる可能性があります。

大幅な複製コストが発生する大規模でチャーン率の高いディメンションテーブルの場合、次の軽減策を利用できます。

  • このようなテーブルを保存するプライマリデータベースをより低い頻度で複製します。

  • データモデルを変更して、チャーン率を減らします。

詳細については、 大規模でチャーンの大きいテーブルのコスト管理 をご参照ください。

複製とクローニング

クローンオブジェクトは、論理的にセカンダリデータベースに複製されるのではなく、物理的に複製されます。つまり、クローンに対する DML 操作が既存のデータに追加または変更しない限り、標準データベース内のクローンテーブルは全体的なデータストレージに寄与しません。ただし、クローンテーブルをセカンダリデータベースに複製すると、物理データも複製されるため、アカウントのデータストレージの使用量が増加します。

ダングリングリファレンス

別のデータベース内のオブジェクトへの参照

プライマリデータベースのビューまたはテーブル制約が別のデータベースを参照しているかどうかを慎重に分析します。

ビュー
  • このタイプの参照は名前ベースであるため、別のデータベース内のオブジェクトを参照する非マテリアライズドビュー(例:テーブル列、他のビュー、 UDFs、またはステージ)を複製できます。名前ベースの参照によって複製が失敗することはありません。ただし、他のデータベースが同じ地域に複製されていない場合、セカンダリデータベースのビューに対するクエリは失敗します。

    たとえば、データベース d1 のビュー v1 が、データベース d1d2 のテーブル t1t2 をそれぞれ参照するとします。セカンダリデータベース d1 のビューV1を正常にクエリするには、セカンダリデータベース d2 もアカウントに存在する必要があります(例:別のセカンダリデータベースとして)。さらに、プライマリデータベースとの一貫したクエリ結果を得るには、セカンダリデータベース d1d2 を同時に更新する必要があります。

  • 現在、別のデータベース内のオブジェクトを参照するマテリアライズドビューは、複製または更新操作の失敗を引き起こし、次のエラーメッセージが表示されます。

    Dangling references in the snapshot. Correct the errors before refreshing again. The following references are missing (referred entity <- [referring entities])
    

    これは、マテリアライズドビューがオブジェクトを名前ではなく ID で参照するためです。データベーススナップショットは、データベース外部のオブジェクトへの ID ベースの参照を解決できません。

    この制限を回避するには、マテリアライズドビューとそれらが参照するオブジェクトを同じデータベースに保存することをお勧めします。

制約

現在、外部キーをダングリングすると複製に失敗し、次のエラーメッセージが表示されます。

Dangling references in the snapshot. Correct the errors before refreshing again. The following references are missing (referred entity <- [referring entities])

この状況は、プライマリデータベースの外部キーが別のデータベースの主キーを参照する場合、またはその逆の場合に発生します。これは、制約参照が ID ベースであるためです。データベーススナップショットは、独自のデータベース外にあるオブジェクトへの ID ベースの参照を解決できません。

アカウントの外部キー参照を表示するには、Information Schemaまたは ACCOUNT_USAGE スキーマの TABLE_CONSTRAINTS ビューをクエリします。

この制限を回避するために、リンクされたテーブルは同じデータベースに保存することをお勧めします。

シーケンス

現在、シーケンスをダングリングすると複製に失敗し、次のエラーメッセージが表示されます。

Dangling references in the snapshot. Correct the errors before refreshing again. The following references are missing (referred entity <- [referring entities])

この状況は、プライマリデータベースのテーブルが別のデータベースのシーケンスを参照している場合に発生します。これは、シーケンス参照が ID ベースであるためです。データベーススナップショットは、独自のデータベース外にあるオブジェクトへの ID ベースの参照を解決できません。

この制限を回避するために、シーケンスは同じデータベースで参照することをお勧めします。

ドロップされたオブジェクトへの参照

同じデータベースまたは別のデータベース内の別のオブジェクトによって参照されているオブジェクトを削除すると、ダングリングリファレンスを引き起こします。プライマリデータベース内のオブジェクトが削除されたオブジェクトを参照すると、レプリケーション操作が失敗し、次のエラーメッセージが表示されます。

Dangling references in the snapshot. Correct the errors before refreshing again. The following references are missing (referred entity <- [referring entities])

この制限を回避するには、次のステップのいずれか 1つ を完了することをお勧めします。

  • 削除された参照されているオブジェクトを復元します。

  • 参照オブジェクトを変更します(たとえば、 ALTER MATERIALIZED VIEW を使用してマテリアライズドビューを変更します)。別のオブジェクトを参照するか、ドロップされたオブジェクトへの参照を削除します。

  • ドロップされたオブジェクトを参照するオブジェクトをプライマリデータベースでドロップします。

複製とアクセス制御

セカンダリデータベースは読み取り専用です。ただし、データベース所有者(つまり、セカンダリデータベースに対して OWNERSHIP 権限を持つロール)は、 GRANT <権限> ... TO ROLE を使用して、データベースオブジェクト(つまり、スキーマ、テーブル、ビューなど)に対する権限を他のロールに付与できます。

複数のデータベースの複製

複数のデータベースが複製される場合、データベース間でのポイントインタイムの一貫性は利用できません。各プライマリデータベースのスナップショットは個別に作成され、セカンダリデータベースへの変更は個別にコミットされます。これは、異なるデータベースのテーブル間で結合するビューがある場合、またはデータベース間のトランザクションに依存する場合に問題になる可能性があります。たとえば、2つのプライマリデータベースをアトミックに更新するトランザクションは、セカンダリデータベースに同時に反映されない可能性があります。

履歴使用データ

プライマリデータベースのアクティビティの履歴使用データは、セカンダリデータベースに複製されません。各アカウントには、独自のクエリ履歴、ログイン履歴などがあります。

履歴使用データには、次の 情報スキーマ 表関数または アカウントの使用 ビューによって返されたクエリデータが含まれます。

  • COPY_HISTORY

  • LOGIN_HISTORY

  • QUERY_HISTORY

  • など。