2022_02バンドル¶

階層データクエリ: 反復制限の適用取りやめ¶

階層データをクエリする場合は、 再帰的 CTEs または CONNECT BY コマンド を使用して、階層の各レベルを反復処理できます。

以前は（Snowflakeにより内部で）100回に設定されていた反復回数の制限は、現在は適用されていません。

以前:

クエリが最大反復回数（100回）を超えた場合はクエリに失敗し、次のエラーメッセージが表示されます。

Recursion exceeded max iteration count (n)

ここで、 n は許可された最大反復回数です。

このエラーのエラーコードは 100189 でした。

現在:

実行される反復回数に制限はありません。

上記のエラーメッセージで以前に失敗したクエリ（特に、無限ループが発生するクエリ）は失敗しなくなり、クエリが成功するかタイムアウトになるまで実行され続けます。これは、 STATEMENT_TIMEOUT_IN_SECONDS パラメーターを設定することで制御できます。

変更が有効になる前に最大反復回数を超えたクエリがあったかどうかを判断するには、 QUERY_HISTORY ビューで、エラーコード 100189 の失敗したクエリを確認します。

SELECT * FROM snowflake.account_usage.query_history WHERE error_code = 100189;

Copy

変更を有効にすると、これらの同じクエリが実行されても失敗しません。無限ループが発生した場合、クエリは早期に終了しません。代わりに、クエリは成功するかタイムアウトするまで実行されます（例: STATEMENT_TIMEOUT_IN_SECONDS パラメーターで設定された秒数を超える）。

無限ループが発生する仕組み、それらを識別する方法、およびそれらを修正する方法については、 再帰的 CTE のトラブルシューティング をご参照ください。

Time Travel: 一時テーブルに保持される継承された DATA_RETENTION_TIME_IN_DAYS パラメーター¶

親オブジェクト（アカウント、データベース、またはスキーマ）の DATA_RETENTION_TIME_IN_DAYS パラメーターが明示的に 0 （日間）に設定されている場合、 一時テーブル の動作は次のように変更されています。

以前:

データ保持時間が 0 日間である場合、一時テーブルは、親オブジェクトから DATA_RETENTION_TIME_IN_DAYS パラメーター設定を継承しませんでした。一時テーブルは、親オブジェクトのデータ保持時間に関係なく、 1 日間のデータ保持時間で作成されました。

現在:

親オブジェクトの DATA_RETENTION_TIME_IN_DAYS が 0 に設定されている場合、一時テーブルは、親オブジェクト（スキーマ、データベース、アカウント）に設定されたデータ保持時間を継承します。

親（スキーマまたはデータベース）の少なくとも1つで DATA_RETENTION_TIME_IN_DAYS が 0 に設定されているアカウントに一時テーブルのリストを生成するには、次の例のステートメントを実行します。ただし、ステートメントを実行する前に、次の点に注意してください。

• このリストには、 DATA_RETENTION_TIME_IN_DAYS パラメーターが 明示的 に 1 に設定されている一時テーブルが含まれています。

  アカウントレベル で DATA_RETENTION_TIME_IN_DAYS が 0 に設定されている場合は、以下の2番目の例にあるステートメントのセットを実行して、 DATA_RETENTION_TIME_IN_DAYS が 1 に設定されているすべての一時テーブルをリストします。

• テーブルのパラメーターを設定解除する前に、そのテーブルのTime Travelが無効になっていることを確認するようにお勧めします。

show tables in account;
set
  table_qid = (
    select
      last_query_id()
);

show schemas in account;
set
  schema_qid = (
    select
      last_query_id()
);

show databases in account;
set
  database_qid = (
    select
      last_query_id()
);

with table_v as (
    select
      "database_name" as database_name,
      "schema_name" as schema_name,
      "name" as table_name,
      "kind" = 'TRANSIENT' as is_transient,
      "retention_time" as table_retention_time
    from
      table(result_scan($table_qid))
  ),
  schema_v as (
    select
      "name" as schema_name,
      iff(
        try_to_number("retention_time") is null,
        0,
        try_to_number("retention_time")
      ) as schema_retention_time
    from
      table(result_scan($schema_qid))
  ),
  database_v as (
    select
      "name" as database_name,
      "retention_time" as database_retention_time
    from
      table(result_scan($database_qid))
  )
select
  *
from
  table_v
  left join schema_v using (schema_name)
  left join database_v using (database_name)
where
  is_transient
  and table_retention_time = 1
  and (
    schema_retention_time = 0
    or database_retention_time = 0
  );

Copy

アカウントレベル で DATA_RETENTION_TIME_IN_DAYS が 0 に設定されている場合は、次のステートメントを実行して、 DATA_RETENTION_TIME_IN_DAYS が 1 に設定されているすべての一時テーブルをリストします。

-- Verify account level DATA_RETENTION_TIME_IN_DAYS setting is 0
show parameters like 'DATA_RETENTION_TIME_IN_DAYS' in account;

show tables in account;

select
  "database_name" as database_name,
  "schema_name" as schema_name,
  "name" as table_name,
  "kind" = 'TRANSIENT' as is_transient,
  "retention_time" as table_retention_time
from
  table(result_scan(last_query_id()))
where
  is_transient
  and table_retention_time = 1;

Copy

親オブジェクトからパラメーター設定を継承できるようにする、既存の一時テーブルに対する DATA_RETENTION_TIME_IN_DAYS パラメーターの設定を解除するには、 ALTER TABLE を使用します。

ALTER TABLE <table_name> UNSET DATA_RETENTION_TIME_IN_DAYS;

Copy

テーブルに設定されているデータ保持時間を確認するには、 SHOW TABLES を使用します。

SHOW TABLES LIKE '<table_name>';

Copy

SHOW ORGANIZATION ACCOUNTS コマンド: 新しい列¶

次の列が SHOW TAGS コマンドの出力に追加されました。

SHOW PROCEDURES コマンド: 出力で、ユーザー作成および組み込みのストアドプロシージャ両方を包含¶

Snowflakeは、アカウント内の任意のデータベースにスキーマレベルのオブジェクトとしてストアドプロシージャを作成することをサポートしています。 SHOW PROCEDURES コマンドは、これらのユーザー作成のストアドプロシージャに関する情報を返します。

データ分類 の導入により、Snowflakeは、組み込み関数と同様に、グローバルオブジェクトとして呼び出すことができる組み込みのストアドプロシージャも提供するようになりました。

SHOW PROCEDURES コマンドの出力は、組み込みのストアドプロシージャをサポートするために、次のように変更されています。

以前:

このコマンドは、現在または指定されたデータベース/スキーマ（またはアカウント全体）でユーザーが作成したストアドプロシージャのみを返しました。

Snowflakeが提供する組み込みのストアドプロシージャを表示するには、コマンドで BUILTIN キーワードを使用できます。例:

SHOW BUILTIN PROCEDURES;

Copy

ただし、Snowflakeは単一の組み込みストアドプロシージャ、 ASSOCIATE_SEMANTIC_CATEGORY_TAGS のみを提供することに注意してください。

現在:

この関数は、ユーザー作成および組み込みのストアドプロシージャの両方を含む、すべてのストアドプロシージャを返します。

これにより、 SHOW PROCEDURES コマンドは SHOW FUNCTIONS コマンドと整合するようになります。

この変更は、 BUILTIN または USER キーワードには影響しません。これらのキーワードを使用して、組み込みまたはユーザー作成のストアドプロシージャを明示的に返すことができます。例:

SHOW BUILTIN PROCEDURES;

SHOW USER PROCEDURES;

Copy

SYSTEM$ESTIMATE_SEARCH_OPTIMIZATION_COSTS 関数: 推定の基礎の変更¶

SYSTEM$ESTIMATE_SEARCH_OPTIMIZATION_COSTS は、 検索最適化 をテーブルに追加するための推定コストを決定するために呼び出すことができるシステム関数です。

この関数は、コストを見積もるための基礎として小さなサンプルを使用するように変更されています。この変更により、関数はより正確なコスト見積もりを報告します。ただし、以下に説明するように、この変更はウェアハウスの使用と関数の出力に影響を与えるだけでなく、関数のパフォーマンスにも影響を与える可能性があります。

以前:

この関数は、単純なモデルを使用してコストを見積もりました。関数は単純なモデルを使用してコストを見積もったため、次のようになります。

• 関数を呼び出すときに、ウェアハウスを使用する必要はありませんでした。

• 関数はウェアハウスを使用しなかったため、この関数のウェアハウス使用量は請求されませんでした。

• 関数が実行され、数秒以内に返されました。

• costPositions 配列の BuildCosts および StorageCosts という名前のオブジェクトの場合、返された JSON 出力では、

  • comment フィールドがありませんでした。

  • computationMethod フィールドは "EstimatedUpperBound" に設定されました。

現在:

この関数は、指定されたテーブルからデータの小さなサンプルを取得し、仮の検索アクセスパスを生成し、プロセスのコストを分析し、結果を推定してテーブル全体のコストを見積もります。関数はサンプリングを使用してコストを見積もるため、次のようになります。

• 関数を呼び出すには、使用中のウェアハウスが必要です。現在使用中のウェアハウスがない場合、関数は次のメッセージを出力します。

  No active warehouse selected in the current session.

  USE WAREHOUSE コマンドで、アクティブなウェアハウスを選択します。この関数を実行するには、XSウェアハウスを使用できます。ウェアハウスのサイズは、この関数の速度とパフォーマンスには影響しません。

• 関数はウェアハウスを使用するため、関数のウェアハウスの使用に対して請求があります。

• この関数は、実行して結果を返すのに時間がかかります（20秒から10分の範囲）。上記のように、より大きなウェアハウスサイズを使用しても、この関数の実行が速くなることはありません。

• costPositions 配列の BuildCosts および StorageCosts という名前のオブジェクトの場合、返された JSON 出力では、

  • comment フィールドは "estimated via sampling" に設定されます。

  • computationMethod フィールドは "Estimated" に設定されます。

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

次の列が新しい ACCOUNT_USAGE.LOGIN_HISTORY ビューに追加されています。

QUERY_HISTORY ビュー（Account Usage）: QUERY_HISTORY 関数と整合する出力¶

インバウンドとアウトバウンドのデータ転送バイトの値は、次の間で整合していません。

• ACCOUNT_USAGE.QUERY_HISTORY および READER_ACCOUNT_USAGE.QUERY_HISTORY ビュー

• INFORMATION_SCHEMA.QUERY_HISTORY テーブル関数の出力

データ転送のクラウド値（それぞれ INBOUND_DATA_TRANSFER_CLOUD または OUTBOUND_DATA_TRANSFER_CLOUD ）がNullの場合、Account Usageビューには、インバウンドおよびアウトバウンドのデータ転送バイトが含まれます。

これらのビューは次のように変更されています。

以前:

ACCOUNT_USAGE および READER_ACCOUNT_USAGE の QUERY_HISTORY ビューには、次が含まれていました。

• INBOUND_DATA_TRANSFER_CLOUD 値がNullの場合、 INBOUND_DATA_TRANSFER_BYTES 列にはデータ転送バイトが含まれていました。

• OUTBOUND_DATA_TRANSFER_CLOUD 値がNullの場合、 OUTBOUND_DATA_TRANSFER_BYTES 列にはデータ転送バイトが含まれていました。

現在:

ビューは、 INFORMATION_SCHEMA.QUERY_HISTORY テーブル関数の出力と整合するようになりました。

INBOUND_DATA_TRANSFER_BYTES 列と OUTBOUND_DATA_TRANSFER_BYTES 列には、関連付けられた INBOUND_DATA_TRANSFER_CLOUD または OUTBOUND_DATA_TRANSFER_CLOUD の値がNullの場合、ファイル転送からのバイトは含まれません。

DESCRIBE STREAM/SHOW STREAM コマンド: 出力の新しい列¶

DESCRIBE STREAM および SHOW STREAMS コマンドの出力には、次の追加の列が含まれるようになりました。

新しい列が既存の TABLE_NAME 列と TYPE 列の間に挿入されました。

ディレクトリテーブル: ステージの作成時にメタデータを1回自動的に更新¶

ディレクトリテーブルを含むステージを作成すると、ディレクトリテーブルのメタデータが1回だけ自動的に更新されるようになりました。ディレクトリテーブルのメタデータを更新すると、指定したステージパス内のデータファイルの現在のリストとメタデータが同期されます。

以前は、既存のデータファイルをディレクトリテーブルのメタデータに登録するために、ユーザーはステージの作成後に ALTER STAGE...REFRESH ステートメントを実行する必要がありました。

この改善は、 CREATE STAGE コマンドの新しい REFRESH_ON_CREATE パラメーターによって実装されます。REFRESH_ON_CREATE = TRUE （デフォルト値）の場合、Snowflakeは、ステージの作成時にディレクトリテーブルのメタデータを1回自動的に更新します。