2022_06バンドル¶

複製グループ: Business Critical Editionではないアカウントのデータベースと共有に限定されたオブジェクト型¶

アカウント複製機能は、ユーザー、ロール、データベース、共有などのアカウントオブジェクトの複製をサポートします。サポートされているオブジェクト型の包括的なリストについては、 複製されたオブジェクト をご参照ください。 複製グループ には、サポートされているオブジェクト型の一部またはすべてを含めることができます。

この動作は次のように変更されました。

以前:

サポートされているすべてのアカウント複製オブジェクト型は、複製グループに含めることができます。

現在:

Business Critical Edition（または、それ以上）ではないアカウントの複製グループに追加できるオブジェクト型のサポートは、データベースと共有に限定されます。

エディションごとの機能サポートの詳細については、アカウント複製の 機能サポートテーブル をご参照ください。

Fail-safeストレージ: 過小請求につながるコーナーケースのバグ修正¶

内部システムエラーのため、 Fail-safe バイト用ストレージに対する一部の永続テーブルは請求されませんでした。具体的には、一時テーブルが永続テーブルのクローンとして作成され、その後永続テーブルがドロップされた場合、Snowflakeは永続テーブルのFail-safeストレージに対して請求しませんでした。

Fail-safeの請求が次のように変更されました。

以前:

一部の永続テーブルは、Fail-safeストレージに対して請求されませんでした。

現在:

お客様は、すべての永続テーブルのFail-safeストレージに対して請求されます。

CREATE DATABASE および CREATE SCHEMA コマンド: OR REPLACE 句によりポリシーのダングリング参照が発生する¶

CREATE DATABASE および CREATE SCHEMA コマンドの動作が次のように変更されました。

以前:

Snowflakeでは、別のデータベースまたはスキーマ内のオブジェクトを保護するマスキングポリシーまたは行アクセスポリシーを含むデータベースまたはスキーマで、 CREATE OR REPLACE DATABASE および CREATE OR REPLACE SCHEMA コマンドを実行できました。例:

• db1.s1.p1 という名前のマスキングポリシーは、 db2.s1.t1.c1 という名前の列を保護します。

• db1.s1.p2 という名前の行アクセスポリシーは、 db2.s1.t1 という名前のテーブルを保護します。

その結果、ダングリング参照が発生し、列またはオブジェクトに対するすべてのクエリに失敗しました。

この動作は、 CREATE OR REPLACE SCHEMA S1 CLONE S2; などの CLONE ステートメントにも適用されることに注意してください。

現在:

結果がポリシーで保護されたオブジェクトのダングリング参照である場合、 CREATE OR REPLACE DATABASE または CREATE OR REPLACE SCHEMA コマンドは失敗します。Snowflakeは、次のエラーメッセージのいずれかを返します。

• CREATE OR REPLACE DATABASE の場合: Cannot drop database because: Policy '<db.schema.policy>' used by schema '<db.schema>' in another database

• CREATE OR REPLACE SCHEMA の場合: Cannot drop schema because: Policy '<db.schema.policy>' used by another schema '<db.schema>'

2つのエラーメッセージのいずれかが発生した場合は、Account Usage POLICY_REFERENCES ビューをクエリし、ロールを使用してマスキングまたは行アクセスポリシーの設定を解除してから、 CREATE OR REPLACE ステートメントを再試行します。

例:

1. ビューをクエリする。

   • 置換前に削除する必要がある クロススキーマ ポリシー参照:

     select * from snowflake.account_usage.policy_references
     where policy_db=<policy_db> and
     policy_schema=<policy_schema_to_replace> and ref_schema_name != <policy_schema>;
     

     Copy

   • 置換前に削除する必要がある クロスデータベース ポリシー参照:

     select * from snowflake.account_usage.policy_references
     where policy_db=<policy_db_to_replace>’ and ref_database_name != <policy_db>;
     

     Copy

2. ポリシーを設定解除する。

   • マスキングポリシー の場合、

     alter table <table_name> modify column <col_name> unset masking policy;
     

     Copy

   • 行アクセスポリシー の場合、

     alter table <table_name> drop all row access policies;
     

     Copy

3. CREATE OR REPLACE コマンドを再試行します。

CLONE 操作では、 CLONE ステートメントを実行する前に、ポリシーオブジェクトを別のデータベースまたはスキーマに格納する必要があることに注意してください。

INFER_SCHEMA 関数: 出力の新しい ORDER_ID 列¶

INFER_SCHEMA 関数の出力には、ステージングされたファイルの列順序を示す新しい ORDER_ID 列が含まれるようになりました。

現在、ステージングされたファイルのセットから派生した列定義でテーブルを作成する（CREATE TABLE ... USING TEMPLATE を使用）と、テーブル内の列順序はランダム化されます。テーブルの列の順序はSnowflakeには関係ありませんが、ファイルの列順序とテーブルの列順序を比較すると、混乱が生じる可能性があります。INFER_SCHEMA 出力の新しい ORDER_ID 列は、検出されたスキーマで作成されたテーブルの列順序が同じであることを確認するのに役立ちます。

次の例に示すように、 INFER_SCHEMA を使用して任意のファイルのスキーマを取得できます。出力には新しい列 ORDER_ID が含まれ、単一のスキーマシナリオでは ORDER_ID で自動的に並べ替えられます。

SELECT *
  FROM TABLE(
  INFER_SCHEMA(
  LOCATION=>'@***_****_STAGE/' , FILE_FORMAT=>'FFPARQUET'
  )
  );

Copy

また、次の例に示すように、ステージングされたファイルから検出されたスキーマを使用してテーブルを作成し、列を ORDER_ID で並べ替えることができます。

CREATE OR REPLACE TABLE BIG_TABLE
  USING TEMPLATE (
  SELECT ARRAY_AGG(OBJECT_CONSTRUCT(*))
  WITHIN GROUP (ORDER BY ORDER_ID) // NEW
  FROM TABLE( INFER_SCHEMA(LOCATION=>'@***_****_STAGE/', FILE_FORMAT=>'FFPARQUET')
  )
  );

DESC TABLE BIG_TABLE;

Copy

ORDER_ID による列の並べ替えは、ステージングされたファイルすべてが1つのスキーマを共有する場合にのみ適用されることに注意してください。ステージングされたデータファイルのセットに、列名が共有されている複数のスキーマが含まれている場合は、 ORDER_ID 列で表される順序が単一のファイルと一致しない可能性があります。

FUNCTIONS ビュー（Account Usage）: ビューの新しい列¶

Account Usage FUNCTIONS ビューの出力に、次の新しい列が含まれるようになりました。