2021_10 번들¶

DESCRIBE USER 명령: 출력의 새 RSA_PUBLIC_KEY 및 RSA_PUBLIC_KEY_2 열¶

DESCRIBE USER 명령의 출력에는 다음의 두 열이 새로 포함됩니다.

• RSA_PUBLIC_KEY

• RSA_PUBLIC_KEY_2

이 두 열을 통해 사용자에 대해 현재 설정된 공개 키를 쉽게 얻을 수 있습니다.

제약 조건: RELY 제약 조건 속성과 뷰의 변경 사항¶

RELY 제약 조건 속성 의 동작과 제약 조건에 대한 두 가지 뷰(ACCOUNT_USAGE의 TABLE_CONSTRAINTS 뷰, INFORMATION_SCHEMA의 TABLE_CONSTRAINTS 뷰)가 다음과 같이 변경되었습니다.

이전

새 제약 조건을 만든 경우:

• RELY가 기본값이었습니다.

• 명령에 NORELY를 지정하여 이를 무시할 수 없었습니다. 명령에 NORELY를 지정한 경우 NORELY가 무시되거나 오류가 발생했습니다.

기존 제약 조건의 경우, RELY 제약 조건 속성을 변경할 수 없었습니다.

다음 뷰는 RELY 제약 조건 속성에 대한 정보를 제공하지 않았습니다.

• ACCOUNT_USAGE의 TABLE_CONSTRAINTS.

• INFORMATION_SCHEMA의 TABLE_CONSTRAINTS.

현재

새 제약 조건을 만드는 경우:

• NORELY가 기본값입니다.

• 명령에 RELY를 지정하여 이를 무시할 수 있습니다.

(제약 조건에 현재 RELY 또는 NORELY 속성이 있는지 여부에 관계없이) 모든 기존 제약 조건에 NORELY 속성이 있습니다. 제약 조건 속성을 NORELY에서 RELY로 변경할 수 있습니다.

다음 뷰는 RELY 제약 조건 속성이 설정되었는지 여부를 지정하는 RELY 열을 포함합니다.

• INFORMATION_SCHEMA의 TABLE_CONSTRAINTS. (업데이트: 2022년 8월에 RELY 열이 추가되었습니다.)

다음 릴리스에서 ACCOUNT_USAGE의 TABLE_CONSTRAINTS에 RELY 열이 추가될 예정입니다.

이렇게 변경된 이유는 쿼리 최적화에 대한 향후 개선 사항을 지원하기 위한 것입니다. 이러한 개선 사항에서는 테이블에 대해 정의된 제약 조건을 사용합니다.

새로운 기본 NORELY 설정을 사용하면 쿼리 최적화 프로그램에서 테이블의 데이터가 제약 조건을 준수한다고 가정하지 않습니다. 테이블의 데이터가 제약 조건을 준수함을 확인한 경우, (즉, 쿼리 최적화 프로그램이 테이블의 데이터가 제약 조건을 당연히 준수할 것으로 생각할 것임을 나타내기 위해) 이를 RELY로 변경할 수 있습니다.

구체화된 뷰: 데이터베이스 복제 시 뷰 생성 방식에 대한 변경 사항¶

데이터베이스를 복제할 때 구체화된 뷰가 생성되는 방식이 다음과 같이 변경되었습니다.

이전

데이터베이스를 복제할 때, 원본 데이터베이스에서 뷰를 만들 때 정규화된 이름을 지정하지 않았더라도 복제된 데이터베이스의 모든 구체화된 뷰가 정규화된 이름으로 생성되었습니다.

예를 들어, 데이터베이스 db1 에서 정규화되지 않은 이름 mv 로 구체화된 뷰를 만들었다고 가정합니다.

use database db1;
create materialized view mv as ...;

Copy

그런 다음 데이터베이스 db1 을 복제한다고 가정합니다.

create database db1_clone clone db1;

Copy

복제된 데이터베이스에 뷰를 만든 CREATE MATERIALIZED VIEW 문은 뷰의 정규화된 이름을 사용했습니다.

SHOW MATERIALIZED VIEWS 명령을 실행하여 이 문을 볼 수 있습니다.

use database db1_clone;
show materialized views;

Copy

text로 명명된 열에 이 구체화된 뷰를 만든 명령의 텍스트가 있습니다.

| text
+------ ...
| create or replace materialized view DB1_CLONE.PUBLIC.MV as ...

Copy

이 예에서 설명한 대로, 이 명령은 구체화된 뷰(DB1_CLONE.PUBLIC.MV)에 대해 정규화된 이름을 사용했습니다.

현재

복제된 데이터베이스 및 스키마의 이름이 원래 CREATE MATERIALIZED VIEW 문에 지정되지 않은 경우에는 복제된 데이터베이스 CREATE MATERIALIZED VIEW 문에 그러한 이름이 포함되지 않습니다.

예를 들어, 데이터베이스 db1 에서 정규화되지 않은 이름 mv 로 구체화된 뷰를 만든다고 가정합니다.

use database db1;
create materialized view mv as ...;

Copy

그런 다음 데이터베이스 db1 을 복제한다고 가정합니다.

create database db1_clone clone db1;

Copy

명령을 실행할 때:

use database db1_clone;
show materialized views;

-- OR --

use database db1_clone;
show views;

Copy

원래 CREATE MATERIALIZED VIEW 문에 정규화되지 않은 이름이 사용되었으므로 텍스트 열의 CREATE MATERIALIZED VIEW 문에서 뷰의 정규화되지 않은 이름을 사용합니다.

| text
+------ ...
| create or replace materialized view mv as ...

Copy

이렇게 변경된 이유는 복제된 데이터베이스의 이름을 바꿀 때 발생할 수 있는 문제를 방지하기 위한 것이었습니다. 복제된 데이터베이스의 이름을 바꿀 때 복제된 데이터베이스의 원래 이름은 구체화된 뷰에서 업데이트되지 않습니다.

예를 들어 복제된 데이터베이스 db1_clone 의 이름을 db2 로 바꾼다고 가정합니다.

alter database db1_clone rename to db2;

다음 명령을 실행할 때:

use database db2;
show materialized views;

텍스트 열의 명령은 복제된 데이터베이스의 새 이름(db2)이 아니라 복제된 데이터베이스의 원래 이름(db1_clone)을 사용했습니다.

| text
+------ ...
| create or replace materialized view DB1_CLONE.PUBLIC.MV as ...

결과적으로, 구체화된 뷰를 쿼리하면 오류가 발생합니다.

select * from mv;

SQL compilation error: Failure during expansion of view 'MV': Cannot perform SELECT.

이 동작 변경을 통해 이 오류가 발생하지 않게 됩니다.

SHOW ORGANIZATION ACCOUNTS 명령: 출력의 새 열¶

조직의 청구 엔터티에 대한 계정의 매핑을 더 잘 이해할 수 있도록, SHOW ORGANIZATION ACCOUNTS 명령의 출력에 다음 열이 추가되었습니다.

GET_DDL 함수: 뷰의 변경 사항¶

GET_DDL 함수는 함수 인자에 지정된 오브젝트에 따라 쿼리 출력의 변형과 함께, 지정된 오브젝트를 다시 만드는 데 사용할 수 있는 DDL 문을 반환합니다. 뷰에 대한 GET_DDL 함수의 동작이 다음과 같이 변경되었습니다.

이전

Snowflake는 뷰를 다시 만드는 정확한 SQL 문을 반환했습니다. 뷰가 보안 뷰인 경우, Snowflake는 뷰를 만드는 DDL 문과 뷰에서 SECURE 속성을 설정하는 ALTER 문을 반환했습니다.

현재

Snowflake는 다음과 같이 뷰에 대한 쿼리 결과를 업데이트했습니다.

• 쿼리 결과는 뷰를 만드는 데 사용된 원래 SQL 문의 대/소문자가 대문자 또는 대/소문자를 혼합한 경우에도 create or replace view 에 대해 소문자 SQL 텍스트를 반환합니다.

• OR REPLACE 절은 항상 CREATE VIEW 문에 포함됩니다.

• 뷰 본문 앞의 SQL 주석(AS)이 제거됩니다.

• 열 목록은 항상 생성됩니다. 열에 마스킹 정책이 설정된 경우 결과는 열에 대한 마스킹 정책을 지정합니다.

• 뷰에 하나 이상의 열에 대한 마스킹 정책이나 행 액세스 정책이 있고 GET_DDL 쿼리를 실행하는 역할에 전역 APPLY MASKING POLICY 또는 APPLY ROW ACCESS POLICY 권한이 없는 경우, 정책 이름은 #unknown_policy 로 바뀝니다. 아래 참고 사항을 참조하십시오.

• 뷰가 안전한 경우 쿼리 결과는 CREATE 문에 SECURE 속성을 포함합니다. SECURE 속성을 설정하기 위한 추가 ALTER 문은 쿼리 결과에 더 이상 포함되지 않습니다.

• COPY GRANTS는 원래 CREATE VIEW 문에 지정되었더라도 포함되지 않습니다.

• CREATE VIEW 문은 문 끝에 항상 세미콜론을 포함하도록 합니다.

INFER_SCHEMA 함수: NULL 열에 대한 변경 사항¶

INFER_SCHEMA 함수는 반정형 데이터가 있는 스테이징된 데이터 파일 세트에서 열 정의를 감지하고 Snowflake 오브젝트를 생성하기 위해 적합한 형식으로 메타데이터를 검색합니다.

이 함수가 열에 대해 NULL 또는 NOT NULL 제약 조건을 반환할지 여부를 결정하는 조건이 다음과 같이 변경되었습니다.

이전

INFER_SCHEMA 함수는 열을 포함하는 파일에 대한 메타데이터에 표시된 대로 열에 대한 Null 허용 여부 제약 조건을 반환했습니다. 함수에 대한 입력이 단일 파일일 때는 열에 대해 반환된 Null 허용 여부 제약 조건이 항상 알맞았습니다. 하지만 필요에 따라 메타데이터에서 열이 식별되었는데도 모든 입력 파일에 포함되지는 않은 경우, 이 함수는 여전히 열에 대해 NOT NULL 제약 조건을 반환했습니다. 이 논리는 INFER_SCHEMA 함수 출력을 사용하여 생성된 테이블에 모든 파일을 로딩할 때 오류를 일으킬 수 있습니다.

스테이징된 데이터 파일 세트에서 (CREATE TABLE … USING TEMPLATE 구문을 사용해) 파생된 열 정의로 테이블을 만들 때 테이블의 모든 열이 Null 허용으로 정의되었습니다.

현재

INFER_SCHEMA 함수는 열이 누락되었거나 입력 파일에서 선택 사항으로 표시된 경우 열을 Null 허용으로 반환합니다. 이 함수는 열이 모든 입력 파일에서 필수로 식별되는 경우에만 열을 Null 허용 안 함으로 반환합니다.

GENERATE_COLUMN_DESCRIPTION 함수와 CREATE TABLE … USING TEMPLATE 명령 구문은 INFER_SCHEMA 함수와 동일한 Null 허용 여부 동작을 따릅니다.

ACCESS_HISTORY 뷰: 쓰기 작업 지원¶

ACCOUNT_USAGE 스키마에서 ACCESS_HISTORY 뷰 의 동작이 다음과 같이 변경되었습니다.

이전

ACCESS_HISTORY 뷰는 SQL 읽기 작업만 지원했습니다.

현재

ACCESS_HISTORY 뷰는 다음과 같이 SQL 읽기 및 쓰기 작업을 지원합니다.

• 쓰기 작업이 발생했음을 나타내기 위해 뷰의 쿼리 출력에 추가 행이 포함되었습니다.

• ARRAY 데이터 타입의 새 열 OBJECTS_MODIFIED 는 SQL 쿼리의 쓰기 부분에서 수정된 오브젝트를 지정합니다.

• 스테이지에 액세스한 경우 objectDomain 필드는 값 STAGE를 지정합니다.

• 쿼리의 읽기 부분에서 스테이지에 액세스한 경우 DIRECT_OBJECTS_ACCESSED 및 BASE_OBJECTS_ACCESSED 열이 다음과 같이 업데이트되었습니다.

  • 새 JSON 필드 stageKind 는 스테이지를 지정합니다.

  • objectName 및 objectId 필드는 사용자, 테이블, 명명된 스테이지에 해당하는 값을 지정합니다.

• 지원되는 쓰기 작업과 지원되지 않는 쓰기 작업에 대한 자세한 내용은 아래의 참고 부분을 참조하세요.

다음 사항을 참고하십시오.

• OBJECTS_MODIFIED 열은 배열을 다음 형식으로 반환합니다.

  {
    "columns": [
       {
         "columnName": <string>,
         "columnId": <number>
       },
       {
         "columnName": <string>,
         "columnId": <number>
       }
      ...
    ],
    "objectId": <number>,
    "objectName": <string>,
    "objectDomain": TABLE | STAGE,
    "location": <string>,
    "stageKind": Table | User | Internal Named | External Named
  }
  

  Copy

  쿼리의 쓰기 부분에서 스테이지에 액세스한 경우:

  • objectId 값은 다음과 같습니다.

    • 사용자 의 NAME 식별자(사용자 스테이지).

    • 테이블 의 TABLE_ID 번호(테이블 스테이지).

    • 스테이지 의 STAGE_ID 번호(명명된 스테이지).

  • objectName 값은 다음과 같습니다.

    • 사용자 스테이지: 값은 username 입니다.

    • 테이블 스테이지: 값은 table_name 입니다.

    • 명명된 스테이지: 값은 stage_name 입니다.

• 쿼리의 쓰기 부분에서 스테이지에 액세스한 경우 BASE_OBJECTS_ACCESSED 및 DIRECT_OBJECTS_ACCESSED 열에 포함되는 JSON 필드는 다음과 같습니다.

  {
    "objectDomain": STAGE
    "objectName": <string>,
    "objectId": <number>,
    "stageKind": <string>
  }
  

  Copy

  이러한 두 열의 필드 이름으로 사용할 수 있는 값은 OBJECTS_MODIFIED 열과 같습니다.

• Snowflake는 ACCESS_HISTORY 뷰에서 다음 쓰기 작업을 지원합니다.

  • GET <내부_스테이지>

  • PUT <내부_스테이지>

  • DELETE

  • INSERT

    • INSERT INTO … FROM SELECT *

    • INSERT INTO TABLE … VALUES ()

  • MERGE INTO … FROM SELECT *

  • UPDATE

    • UPDATE TABLE … FROM SELECT * FROM …

    • UPDATE TABLE … WHERE …

  • 데이터 로딩 문:

    • COPY INTO TABLE FROM internalStage

    • COPY INTO TABLE FROM externalStage

    • COPY INTO TABLE FROM externalLocation

  • 데이터 언로딩 문:

    • COPY INTO internalStage FROM TABLE

    • COPY INTO externalStage FROM TABLE

    • COPY INTO externalLocation FROM TABLE

  • CREATE:

    • CREATE DATABASE … CLONE

    • CREATE SCHEMA … CLONE

    • CREATE TABLE … CLONE

    • CREATE TABLE … AS SELECT

• Snowflake는 ACCESS_HISTORY 뷰에서 다음 쓰기 작업을 지원하지 않습니다.

  • 뷰, 구체화된 뷰, 스트림을 채우는 작업.

  • 복제에 따른 데이터 이동.

COPY_HISTORY: 출력에서 일관된 STATUS 열 대/소문자 여부¶

데이터 로딩 상태는 Information Schema에서 COPY_HISTORY 테이블 함수 출력의 STATUS 열 및 ACCOUNT_USAGE의 COPY_HISTORY 뷰 에 보고됩니다. STATUS 열에 반환되는 값이 다음과 같이 변경되었습니다.

이전

대량 데이터 로딩(COPY INTO <테이블> 문)의 경우, 문서화된 Loaded, Load failed 등과 같이 상태 값이 첫 번째 단어의 첫 글자는 대문자, 나머지 단어는 모든 글자가 소문자인 상태로 반환되었습니다.

Snowpipe 데이터 로딩의 경우, 상태 값이 LOADED, LOAD FAILED 등과 같이 대문자로 반환되었습니다.

현재

대량 데이터 로딩과 Snowpipe 데이터 로딩의 경우에서 모두, 상태 값이 첫 번째 단어의 첫 글자는 대문자, 나머지 단어는 모든 글자가 소문자로 반환됩니다.

이 변경 사항은 STATUS 열 값에 일관성을 적용하고 제품 설명서와 일치하도록 합니다.

Java UDF: Scala JAR 파일 포함 기준 변경 사항¶

Java UDF 동작이 다음과 같이 변경되었습니다.

이전

Java UDF의 경우 Scala JAR 파일이 JVM 클래스 경로에 포함되었습니다.

현재

Java UDF의 경우 Scala 라이브러리는 더 이상 클래스 경로에 포함되지 않습니다. Scala 라이브러리에 의존하는 Java UDF 코드가 있는 경우, 새 UDF를 만들거나 기존 UDF를 바꿀 때 가져오기 목록에 Scala JAR 파일을 포함합니다. 예:

create or replace function add(x integer, y integer)
returns integer
language java
imports = ('@stage/scala-library-2.12.jar')
handler='TestAddFunc.add'

Copy

Snowpark Scala 라이브러리를 사용하여 생성된 UDF는 영향을 받지 않습니다.

COPY INTO <테이블> 명령: CSV 데이터를 로딩할 때 MATCH_BY_COLUMN_NAME 복사 옵션이 오류를 반환함¶

MATCH_BY_COLUMN_NAME 복사 옵션을 사용하면 원본 데이터에 표시된 해당 열과 일치하는 대상 테이블의 별도 열로 반정형 데이터를 로딩할 수 있습니다. 복사 옵션은 CSV(쉼표로 구분된 값) 파일에서의 데이터 로딩을 지원하지 않습니다.

MATCH_BY_COLUMN_NAME 복사 옵션을 CASE_SENSITIVE 또는 CASE_INSENSITIVE로 설정하여 CSV 형식의 데이터를 로딩하려고 할 때의 동작이 다음과 같이 변경되었습니다.

이전

COPY INTO <테이블> 문은 CSV 파일 형식과 함께 사용할 때 오류를 반환하지 않았지만, MATCH_BY_COLUMN_NAME 설정은 데이터 로딩에 영향을 미치지 않았으므로 무시됩니다.

현재

이 옵션이 CSV 파일을 지원하지 않으므로 COPY INTO <테이블> 문은 사용자 오류를 반환합니다.

COPY INTO <위치> 명령: Parquet 데이터로 언로딩할 때 명시적 열 캐스트가 무시됨¶

숫자 테이블 데이터를 Parquet 파일로 언로딩할 때 COPY INTO <위치> 문에서 CAST 함수를 호출하면 Parquet 데이터 타입에 매핑되는 Snowflake 데이터 타입을 선택할 수 있습니다.

숫자 열 데이터를 Parquet 파일로 명시적으로 캐스팅할 때의 동작이 다음과 같이 변경되었습니다.

이전

하나 이상의 숫자 열이 Parquet 데이터 타입에 매핑되지 않은 데이터 타입으로 명시적으로 캐스팅될 때 데이터 언로딩 작업은 Parquet 데이터 타입에 매핑된 명시적 캐스트를 모두 무시했습니다. 고정 소수점 숫자 열은 DECIMAL 열로 언로딩되었지만, 부동 소수점 숫자 열은 DOUBLE 열로 언로딩되었습니다.

현재

데이터 언로딩 작업은 대상 Snowflake 데이터 타입이 Parquet 데이터 타입에 매핑되는지 여부에 관계없이 숫자 열 데이터의 모든 명시적 캐스트를 적용합니다.

관리 계정: 새 계정 이름 형식을 지원하기 위한 변경 사항¶

Snowflake는 고객이 선택하고 변경할 수 있는 업데이트된 관리 계정 이름을 기반으로 하는 새로운 URL을 도입합니다. URL의 형식은 다음과 같습니다.

<조직_이름>-<관리_계정_이름>.snowflakecomputing.com

새 관리 계정 이름에는 다음 2가지의 새 명명 규칙이 있습니다.

• 밑줄(_)은 이름에서 유일하게 유효한 구분 기호입니다.

• 이름은 관리 계정이 속한 조직에서 고유해야 합니다.

대부분의 기존 관리 계정 이름은 이미 새 명명 규칙을 따르며 이름이 그대로 유지됩니다. 이러한 규칙을 따르지 않은 관리 계정 이름은 다음과 같이 자동으로 업데이트되었습니다.

• 관리 계정 이름에 밑줄이 아닌 구분 기호가 포함된 경우 밑줄로 변환되었습니다. 예를 들어 관리 계정 이름이 managed account-1 인 경우 새 관리 계정 이름은 managed_account_1 입니다.

• 관리 계정 이름이 조직에 고유하지 않은 경우 로케이터 이름이 관리 계정 이름에 추가되었습니다. 예를 들어 관리 계정 이름이 managed 이고 로케이터는 RE47190 인 경우 새 관리 계정 이름은 managed_RE47190 입니다.

업데이트된 관리 계정 이름은 모든 관리 계정 명령에 사용됩니다.

• CREATE MANAGED ACCOUNT 는 새 명명 규칙을 적용합니다.

• SHOW MANAGED ACCOUNTS 는 이름 열에서 업데이트된 관리 계정 이름을 표시합니다.

• DROP MANAGED ACCOUNT 는 업데이트된 관리 계정 이름을 매개 변수로 사용합니다.

SHOW SHARES 명령 및 데이터 공유 UI: 출력 변경 사항¶

출력에 계정 로케이터(이전에는 자동 생성 계정 이름라고 부름)를 포함하는 데이터 공유를 위한 SHOW SHARES 명령과 웹 인터페이스가 다음과 같이 조직 이름과 새 계정 이름을 사용하도록 변경되었습니다.

이전

name 열에 <계정_로케이터>.<공유_이름> 이 표시되었음

to 열(아웃바운드 공유용)에 <계정_로케이터> 가 표시되었음

현재

name 열에 <조직_이름>.<계정_이름>.<공유_이름> 이 표시될 것임

to 열(아웃바운드 공유용)에 <조직_이름>.<계정_이름> 이 표시될 것임

또한 <계정_로케이터>.<공유_이름> 을 매개 변수로 사용하는 명령(DESCRIBE SHARE 및 CREATE DATABASE … FROM SHARE)은 <조직_이름>.<계정_이름>.<공유_이름> 을 매개 변수로 사용할 수 있습니다.

계정 로케이터와 새 계정 이름의 차이점에 대한 자세한 내용은 계정 식별자 섹션을 참조하십시오.

SHOW 명령 및 SELECT 문: 여러 개의 공유가 같은 데이터베이스에서 비롯될 때의 출력 변경 사항¶

이전

컨슈머가 같은 공급자 데이터베이스(다수의 공유에 대해 한 데이터베이스 공급자 구성)에서 생성된 데이터 공유에서 두 개 이상의 데이터베이스를 탑재한 경우, 특정한 상황에서 출처가 같은 데이터 공유의 오브젝트가 그와 같이 출처가 같은 데이터 공유를 기반으로 탑재된 데이터베이스에서 예기치 않게 사용자에게 나타납니다. 이 문제는 데이터에 대한 실제 액세스에는 영향을 미치지 않았습니다. 오브젝트는 사용자가 해당 오브젝트에 대한 액세스 권한이 있는지 쿼리한 데이터베이스에서 예기치 않게 나타났을 뿐입니다.

예를 들어 공급자가 ORIGIN_DATABASE의 데이터를 공유하려고 한다고 가정해 보십시오. ORIGIN_DATABASE에는 SCHEMA_A와 SCHEMA_Z의 두 스키마가 있습니다. 공급자는 세 테이블을 공유하려고 합니다. 두 테이블 SCHEMA_A.TABLE1과 SCHEMA_A.TABLE2는 SCHEMA_A에 있는 테이블입니다. 공급자는 SCHEMA_Z TABLE1도 공유하려고 합니다.

공급자는 세 데이터 공유, 즉 SCHEMA_A.TABLE1에서 FIRST_DATASHARE, SCHEMA_A TABLE2에서 SECOND_DATASHARE, SCHEMA_Z TABLE1에서 THIRD_DATASHARE를 만듭니다. 그런 다음 공급자는 세 공유에 컨슈머를 추가합니다.

이 예에서는 컨슈머가 공급자의 데이터 공유를 기반으로 세 데이터베이스를 탑재했는데, FIRST_DATABASE는 FIRST_DATASHARE에서, SECOND_DATABASE는 SECOND_DATASHARE에서, THIRD_DATABASE는 THIRD_DATASHARE에서 탑재됩니다.

이 예에서 컨슈머는 자신이 탑재한 데이터베이스가 한 공급자 데이터베이스에서 파생되었다는 사실을 인식했을 수도, 인식하지 못했을 수도 있습니다.

탑재되는 데이터베이스가 서로 다른 공유에 있던 것이라도, 컨슈머가 SHOW OBJECTS(예: TABLES, FUNCTIONS 등)를 사용하여 탑재된 데이터베이스를 탐색하면 탑재된 각 데이터베이스에서 같은 원본 스키마의 같은 오브젝트 세트가 나타납니다.

이 예에서 컨슈머는 SHOW OBJECTS IN ACCOUNT를 사용할 때 다음 결과를 보았습니다. 이 예의 목적상, 출력의 관련 열만 포함됩니다. 출력에서 데이터베이스 이름은 같은 원본에서 가장 최근에 탑재된 데이터베이스로 덮어씁니다.

이름	데이터베이스_이름	스키마_이름
APPLICABLE_ROLES	THIRD_DATABASE	INFORMATION_SCHEMA
<기타 정보 스키마 오브젝트>
TABLE1	THIRD_DATABASE	SCHEMA_A
TABLE2	THIRD_DATABASE	SCHEMA_A
APPLICABLE_ROLES	THIRD_DATABASE	INFORMATION_SCHEMA
<기타 정보 스키마 오브젝트>
TABLE1	THIRD_DATABASE	SCHEMA_A
TABLE2	THIRD_DATABASE	SCHEMA_A
APPLICABLE_ROLES	THIRD_DATABASE	INFORMATION_SCHEMA
<기타 정보 스키마 오브젝트>
TABLE1	THIRD_DATABASE	SCHEMA_Z

현재

컨슈머가 데이터 공유에서 데이터베이스를 탑재할 때, 해당 데이터 공유가 같은 공급자 데이터베이스에서 비롯된 것이라도 공급자가 각 데이터 공유에 대해 원하는 예상 오브젝트만 컨슈머에게 표시됩니다.

이 예의 컨슈머는 SHOW OBJECTS IN ACCOUNT를 사용한 후 다음과 같은 결과를 보게 됩니다. 이 예의 목적상, 출력의 관련 열만 포함됩니다.

이름	데이터베이스_이름	스키마_이름
APPLICABLE_ROLES	FIRST_DATABASE	INFORMATION_SCHEMA
<기타 정보 스키마 오브젝트>
TABLE1	FIRST_DATABASE	SCHEMA_A
APPLICABLE_ROLES	SECOND_DATABASE	INFORMATION_SCHEMA
<기타 정보 스키마 오브젝트>
TABLE2	SECOND_DATABASE	SCHEMA_A
APPLICABLE_ROLES	THIRD_DATABASE	INFORMATION_SCHEMA
<기타 정보 스키마 오브젝트>
TABLE1	THIRD_DATABASE	SCHEMA_Z