Bundle 2021_10¶

Befehl DESCRIBE USER: Neue Spalten RSA_PUBLIC_KEY und RSA_PUBLIC_KEY_2 in Ausgabe¶

Die Ausgabe des Befehls DESCRIBE USER enthält zwei neue Spalten:

• RSA_PUBLIC_KEY

• RSA_PUBLIC_KEY_2

Diese beiden Spalten erleichtern das Abrufen der öffentlichen Schlüssel, die derzeit für den Benutzer eingestellt sind.

Einschränkungen: Änderungen an der RELY-Einschränkungseigenschaft und zugehörigen Ansichten¶

Das Verhalten der RELY-Einschränkungseigenschaft und von zwei Ansichten für Einschränkungen (TABLE_CONSTRAINTS-Ansicht in ACCOUNT_USAGE und TABLE_CONSTRAINTS-Ansicht in INFORMATION_SCHEMA) hat sich wie folgt geändert:

Bisher

Wenn Sie eine neue Einschränkung erstellt haben:

• RELY war der Standard.

• Sie konnten dies nicht überschreiben, indem Sie im Befehl NORELY angeben. Wenn Sie NORELY im Befehl angegeben haben, wurde NORELY ignoriert oder es wurde ein Fehler ausgegeben.

Bei bestehenden Einschränkungen konnten Sie die RELY-Einschränkungseigenschaft nicht ändern.

Die folgenden Ansichten lieferten keine Informationen über die RELY-Einschränkungseigenschaft:

• TABLE_CONSTRAINTS in ACCOUNT_USAGE

• TABLE_CONSTRAINTS in INFORMATION_SCHEMA

Jetzt

Wenn Sie eine neue Einschränkung erstellen:

• NORELY ist der Standard.

• Sie können dies nun überschreiben, indem Sie im Befehl RELY angeben.

Alle vorhandenen Einschränkungen haben die Eigenschaft NORELY (unabhängig davon, ob die Einschränkung derzeit die Eigenschaft RELY oder NORELY hat). Sie können nun die Einschränkungseigenschaft von NORELY auf RELY ändern.

Die folgenden Ansichten enthalten nun eine RELY-Spalte, die angibt, ob die RELY-Einschränkungseigenschaft gesetzt ist oder nicht:

• TABLE_CONSTRAINTS in INFORMATION_SCHEMA (Aktualisierung: Die Spalte RELY wurde im August 2022 hinzugefügt.)

Die Spalte RELY wird in einem der nächsten Releases zu TABLE_CONSTRAINTS in ACCOUNT_USAGE hinzugefügt.

Diese Änderung wurde vorgenommen, um zukünftige Verbesserungen bei der Abfrageoptimierung zu unterstützen. Diese Verbesserungen werden die für die Tabelle definierten Einschränkungen nutzen.

Mit der neuen Standardeinstellung NORELY geht die Abfrageoptimierung nicht davon aus, dass die Daten in einer Tabelle den Einschränkungen entsprechen. Wenn Sie sichergestellt haben, dass die Daten in der Tabelle den Einschränkungen entsprechen, können Sie diesen Wert in RELY ändern (d. h. um anzuzeigen, dass die Abfrageoptimierung erwarten kann, dass die Daten in der Tabelle den Einschränkungen entsprechen).

Materialisierte Ansichten: Änderung der Art und Weise, wie Ansichten beim Klonen von Datenbanken erstellt werden¶

Die Art und Weise, in der materialisierte Ansichten beim Klonen von Datenbanken erstellt werden, hat sich wie folgt geändert:

Bisher

Wenn Sie eine Datenbank geklont haben, wurden alle materialisierten Ansichten in der geklonten Datenbank mit vollqualifizierten Namen erstellt, auch wenn Sie den vollqualifizierten Namen beim Erstellen der Ansicht in der Originaldatenbank nicht angegeben haben.

Angenommen, Sie haben in der Datenbank db1 eine materialisierte Ansicht mit dem nicht qualifizierten Namen mv erstellt:

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

Copy

Und Sie klonen dann die Datenbank db1:

create database db1_clone clone db1;

Copy

Die Anweisung CREATE MATERIALIZED VIEW, mit der die Ansicht in der geklonten Datenbank erstellt wurde, verwendete den vollqualifizierten Namen der Ansicht.

Sie können diese Anweisung anzeigen, indem Sie den Befehl SHOW MATERIALIZED VIEWS ausführen:

use database db1_clone;
show materialized views;

Copy

Die Spalte „text“ enthält den Text des Befehls, mit dem diese materialisierte Ansicht erstellt wurde:

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

Copy

Wie in diesem Beispiel gezeigt, verwendet der Befehl den vollqualifizierten Namen der materialisierten Ansicht (DB1_CLONE.PUBLIC.MV).

Jetzt

Die CREATE MATERIALIZED VIEW-Anweisung in der geklonten Datenbank enthält nicht den Namen der geklonten Datenbank und des Schemas, es sei denn, diese Namen wurden in der ursprünglichen CREATE MATERIALIZED VIEW-Anweisung angegeben.

Angenommen, Sie erstellen in der Datenbank db1 eine materialisierte Ansicht mit dem nicht qualifizierten Namen mv:

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

Copy

Und Sie klonen dann die Datenbank db1:

create database db1_clone clone db1;

Copy

Wenn Sie nun folgenden Befehl ausführen:

use database db1_clone;
show materialized views;

-- OR --

use database db1_clone;
show views;

Copy

Die CREATE MATERIALIZED VIEW-Anweisung in der Spalte „text“ verwendet den nicht qualifizierten Namen für die Ansicht, da in der ursprünglichen CREATE MATERIALIZED VIEW-Anweisung der nicht qualifizierte Name verwendet wurde:

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

Copy

Diese Änderung wurde vorgenommen, um mögliche Probleme beim Umbenennen einer geklonten Datenbank zu vermeiden. Wenn Sie eine geklonte Datenbank umbenennen, wird der ursprüngliche Name der geklonten Datenbank in der materialisierten Ansicht nicht aktualisiert.

Angenommen, Sie benennen die geklonte Datenbank db1_clone in db2 um:

alter database db1_clone rename to db2;

Und Sie führen nun den folgenden Befehl aus:

use database db2;
show materialized views;

Der Befehl in der Spalte „text“ verwendet den ursprünglichen Namen der geklonten Datenbank (db1_clone), nicht den neuen Namen der geklonten Datenbank (db2):

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

Infolgedessen führt die Abfrage der materialisierten Ansicht zu einem Fehler:

select * from mv;

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

Diese Verhaltensänderung verhindert, dass dieser Fehler auftritt.

Befehl SHOW ORGANIZATIONACCOUNTS: Neue Spalten in Ausgabe¶

Zum besseren Verständnis der Zuordnungen von Konten zu Abrechnungseinheiten in einer Organisation wurden die folgenden Spalten zur Ausgabe des Befehls SHOW ORGANIZATION ACCOUNTS hinzugefügt:

Funktion GET_DDL: Änderungen bei Ansichten¶

Die Funktion GET_DDL gibt eine DDL-Anweisung zurück, mit der das angegebene Objekt neu erstellt werden kann, wobei die Ausgabe der Abfrage je nach dem im Funktionsargument angegebenen Objekt variiert. Das Verhalten der GET_DDL-Funktion bei Ansichten hat sich wie folgt geändert:

Bisher

Snowflake gab die genaue SQL-Anweisung zum Neuerstellen der Ansicht zurück. Wenn die Ansicht eine sichere Ansicht war, gab Snowflake die DDL-Anweisung zum Erstellen der Ansicht sowie eine ALTER-Anweisung zurück, um die Eigenschaft SECURE für die Ansicht festzulegen.

Jetzt

Snowflake hat das Abfrageergebnis für Ansichten wie folgt aktualisiert:

• Das Abfrageergebnis gibt SQL-Text in Kleinbuchstaben für create or replace view zurück, auch wenn in der ursprünglichen SQL-Anweisung, die zum Erstellen der Ansicht verwendet wurde, Großschreibung oder gemischte Klein-/Großschreibung verwendet wurde.

• Die OR REPLACE-Klausel ist immer in der CREATE VIEW-Anweisung enthalten.

• SQL-Kommentare vor dem Ansichtstext (AS) werden entfernt.

• Die Spaltenliste wird immer generiert. Wenn auf einer Spalte eine Maskierungsrichtlinie festgelegt ist, gibt das Ergebnis die Maskierungsrichtlinie für die Spalte an.

• Wenn die Ansicht eine Maskierungsrichtlinie für eine oder mehrere ihrer Spalten oder eine Zeilenzugriffsrichtlinie hat und die Rolle, die die GET_DDL-Abfrage ausführt, nicht über die globale Berechtigung APPLY MASKING POLICY oder APPLY ROW ACCESS POLICY verfügt, wird der Richtlinienname durch #unknown_policy ersetzt (siehe Hinweis unten).

• Wenn die Ansicht sicher ist, enthält das Abfrageergebnis die SECURE-Eigenschaft in der CREATE-Anweisung. Eine zusätzliche ALTER-Anweisung zur Festlegung der SECURE-Eigenschaft ist nicht mehr im Abfrageergebnis enthalten.

• COPY GRANTS ist nicht enthalten, auch wenn es in der ursprünglichen CREATE VIEW-Anweisung angegeben wurde.

• Es ist sichergestellt, dass die CREATE VIEW-Anweisung immer mit einem Semikolon endet.

INFER_SCHEMA-Funktion: Änderung bei NULL-Spalten¶

Die Funktion INFER_SCHEMA erkennt die Spaltendefinitionen in einer Menge von Staging-Datendateien, die semistrukturierte Daten enthalten, und ruft die Metadaten in einem Format ab, das für die Erstellung von Snowflake-Objekten geeignet ist.

Die Bedingung, die bestimmt, ob die Funktion die NULL- oder NOT NULL-Einschränkung für eine Spalte zurückgibt, wurde wie folgt geändert:

Bisher

Die Funktion INFER_SCHEMA gibt die NULL-Zulässigkeitseinschränkung für eine Spalte zurück, wie sie in den Metadaten der Dateien, die die Spalte enthalten, angegeben ist. Wenn die Eingabe für die Funktion eine einzelne Datei war, war die für die Spalten zurückgegebene NULL-Zulässigkeitseinschränkung immer korrekt. Wenn jedoch eine Spalte in den Metadaten als erforderlich identifiziert wurde, aber nicht in allen Eingabedateien enthalten war, lieferte die Funktion dennoch eine NOT NULL-Einschränkung für die Spalte. Diese Logik kann zu Fehlern führen, wenn alle Dateien in eine Tabelle geladen werden, die mit der Ausgabe der INFER_SCHEMA-Funktion erstellt wurde.

Beim Erstellen einer Tabelle mit den Spaltendefinitionen, die aus einer Menge von Staging-Datendateien abgeleitet wurden (unter Verwendung der CREATE TABLE … USING TEMPLATE-Syntax), wurden alle Spalten in der Tabelle als nullwertfähig definiert.

Jetzt

Die Funktion INFER_SCHEMA gibt eine Spalte als nullwertfähig zurück, wenn die Spalte in den Eingabedateien fehlt oder als optional angegeben ist. Die Funktion gibt eine Spalte nur dann als nicht nullwertfähig zurück, wenn die Spalte in allen Eingabedateien als erforderlich gekennzeichnet ist.

Die Funktion GENERATE_COLUMN_DESCRIPTION und die Syntax des CREATE TABLE … USING TEMPLATE-Befehls folgen demselben NULL-Zulässigkeitsverhalten wie die Funktion INFER_SCHEMA.

Ansicht ACCESS_HISTORY: Unterstützung von Schreiboperationen¶

Das Verhalten von ACCESS_HISTORY-Ansicht im ACCOUNT_USAGE-Schema hat sich wie folgt geändert:

Bisher

Die Ansicht ACCESS_HISTORY unterstützte nur SQL-Leseoperationen.

Jetzt

Die Ansicht ACCESS_HISTORY unterstützt SQL-Lese-/Schreiboperationen wie folgt:

• Es wurden zusätzliche Zeilen in die Abfrageausgabe der Ansicht hinzugefügt, um anzuzeigen, dass Schreiboperationen stattgefunden haben.

• Die neue Spalte OBJECTS_MODIFIED vom Datentyp ARRAY gibt Objekte an, die im Schreibteil einer SQL-Abfrage geändert wurden.

• Wenn auf einen Stagingbereich zugegriffen wurde, gibt das Feld objectDomain den Wert STAGE an.

• Wenn im Leseteil der Abfrage auf einen Stagingbereich zugegriffen wurde, wurden die Spalten DIRECT_OBJECTS_ACCESSED und BASE_OBJECTS_ACCESSEDn wie folgt aktualisiert:

  • In dem neuen JSON-Feld stageKind wird der Stagingbereich angegeben.

  • In den Feldern objectName und objectId werden die entsprechenden Werte für den Benutzer, die Tabelle und den benannten Stagingbereich angegeben.

• Weitere Informationen zu unterstützten und nicht unterstützten Schreiboperationen finden Sie in den Hinweisen unten.

Beachten Sie Folgendes:

• Die Spalte OBJECTS_MODIFIED gibt ein Array im folgenden Format zurück:

  {
    "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

  Wenn im Schreibteil der Abfrage auf einen Stagingbereich zugegriffen wurde:

  • Der Wert von objectId lautet wie folgt:

    • NAME – Bezeichner für einen Benutzer (Benutzer-Stagingbereich).

    • TABLE_ID – Nummer für eine Tabelle (Tabellen-Stagingbereich).

    • STAGE_ID – Nummer für einen Stagingbereich (Benannter Stagingbereich).

  • Der Wert von objectName lautet wie folgt:

    • Benutzer-Stagingbereich: Der Wert ist der Wert von username.

    • Tabellen-Stagingbereich: Der Wert ist der Wert von table_name.

    • Benannter Stagingbereich: Der Wert ist der Wert von stage_name.

• Wenn im Schreibteil der Abfrage auf einen Stagingbereich zugegriffen wurde, enthalten die Spalten BASE_OBJECTS_ACCESSED und DIRECT_OBJECTS_ACCESSED die folgenden JSON-Felder:

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

  Copy

  Die möglichen Werte für die Feldnamen in diesen beiden Spalten sind die gleichen wie in der Spalte OBJECTS_MODIFIED.

• Snowflake unterstützt die folgenden Schreiboperationen in der ACCESS_HISTORY-Ansicht:

  • GET <interner_Stagingbereich>

  • PUT <interner_Stagingbereich>

  • DELETE

  • INSERT

    • INSERT INTO … FROM SELECT *

    • INSERT INTO TABLE … VALUES ()

  • MERGE INTO … FROM SELECT *

  • UPDATE

    • UPDATE TABLE … FROM SELECT * FROM …

    • UPDATE TABLE … WHERE …

  • Anweisungen zum Laden von Daten:

    • COPY INTO TABLE FROM internalStage

    • COPY INTO TABLE FROM externalStage

    • COPY INTO TABLE FROM externalLocation

  • Anweisungen zum Entladen von Daten:

    • 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 unterstützt die folgenden Schreiboperationen in der ACCESS_HISTORY-Ansicht nicht:

  • Operationen zum Befüllen von Ansichten, materialisierten Ansichten und Streams

  • Verschieben von Daten für Replikation

COPY_HISTORY: Konsistent Schreibung in STATUS-Spalte der Ausgabe¶

Der Status einer Datenladeoperation wird in der Ausgabe der Information Schema-Tabellenfunktion COPY_HISTORY und in der COPY_HISTORY-Ansicht von ACCOUNT_USAGE jeweils in der Spalte STATUS angegeben. Die in der Spalte STATUS zurückgegebenen Werte haben sich wie folgt geändert:

Bisher

Beim Massenladen von Daten (COPY INTO <Tabelle>-Anweisungen) wurden die Statuswerte mit dem ersten Buchstaben des ersten Wortes in Großbuchstaben und den restlichen Wörtern in Kleinbuchstaben zurückgegeben: Loaded, Load failed usw.

Beim Laden von Snowpipe-Daten wurden die Statuswerte in Großbuchstaben zurückgegeben: LOADED, LOAD FAILED usw.

Jetzt

Sowohl beim Massenladen von Daten als auch beim Laden von Snowpipe-Daten werden die Statuswerte mit dem ersten Buchstaben des ersten Wortes in Großbuchstaben und den restlichen Wörtern in Kleinbuchstaben zurückgegeben.

Durch diese Änderung werden die Werte in den STATUS-Spalten konsistent und in Übereinstimmung mit der Produktdokumentation angegeben.

Java-UDFs: Änderungen an Aufnahmekriterien für Scala-JAR-Dateien¶

Das Verhalten von Java-UDFs hat sich wie folgt geändert:

Bisher

Beo Java-UDFs wurden Scala-JAR-Dateien in den JVM-Klassenpfad aufgenommen.

Jetzt

Bei Java-UDFs werden Scala-Bibliotheken nicht mehr in den Klassenpfad aufgenommen. Wenn Sie Java-UDF-Code verwenden, der von Scala-Bibliotheken abhängt, müssen Sie beim Erstellen neuer UDFs oder beim Ersetzen bestehender UDFs die entsprechenden Scala-JAR-Dateien zur Importliste hinzufügen. Beispiel:

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

Copy

UDFs, die mit der Snowpark-Scala-Bibliothek erstellt wurden, sind davon nicht betroffen.

Befehl COPY INTO <Tabelle>: Kopieroption MATCH_BY_COLUMN_NAME liefert beim Laden von CSV-Daten einen Fehler¶

Mit der Kopieroption MATCH_BY_COLUMN_NAME können semistrukturierte Daten in separate Spalten einer Zieltabelle geladen werden, die aber mit den entsprechenden Spalten in den Quelldaten übereinstimmen müssen. Die Kopieroption unterstützt nicht das Laden von Daten aus Dateien mit durch Trennzeichen getrennten Werten (CSV).

Das Verhalten beim Versuch, CSV-formatierte Daten zu laden, wenn die Kopieroption MATCH_BY_COLUMN_NAME entweder auf CASE_SENSITIVE oder CASE_INSENSITIVE gesetzt ist, hat sich wie folgt geändert:

Bisher

Die Anweisung COPY INTO <Tabelle> gab keinen Fehler zurück, wenn sie mit Dateien im CSV-Format verwendet wurde, aber die MATCH_BY_COLUMN_NAME-Einstellung hatte keinen Einfluss auf das Laden der Daten und wurde ignoriert.

Jetzt

Die Anweisung COPY INTO <Tabelle> gibt einen Benutzerfehler zurück, da die Option keine CSV-Dateien unterstützt.

Befehl COPY INTO <Speicherort>: Explizites Umwandeln von Spalten wird beim Entladen in Parquet-Daten ignoriert¶

Beim Entladen numerischer Tabellendaten in Parquet-Dateien können Sie durch Aufruf der CAST-Funktion in der COPY INTO <Speicherort>-Anweisung die Snowflake-Datentypen auswählen, die Parquet-Datentypen zugeordnet werden sollen.

Das Verhalten beim expliziten Umwandeln von numerischen Spaltendaten in Parquet-Dateien hat sich wie folgt geändert:

Bisher

Wenn mindestens eine numerische Spalte explizit in einen Datentyp umgewandelt wurde, der keinem Parquet-Datentyp zugeordnet war, dann ignorierte die Datenentladeoperation sämtliche expliziten Umwandlungen, auch wenn diese Parquet-Datentypen zugeordnet waren. Spalten mit Festkommazahlen wurden als DECIMAL-Spalten entladen, während Spalten mit Gleitkommazahlen als DOUBLE-Spalten entladen wurden.

Jetzt

Datenentladeoperationen berücksichtigen alle expliziten Umwandlungen von numerischen Spaltendaten, unabhängig davon, ob die Snowflake-Zieldatentypen bestimmten Parquet-Datentypen zugeordnet sind.

Verwaltete Konten: Änderungen zur Unterstützung eines neuen Kontonamensformats¶

Snowflake führt eine neue URL ein, die auf einem aktualisierten Namen für verwaltete Konten basiert, den Kunden auswählen und ändern können. Die URL hat das folgende Format:

<Organisationsname>-<Name_des_verwalteten_Kontos>.snowflakecomputing.com

Für den neuen Name von verwalteten Konten gelten zwei neue Benennungsregeln:

• Der Unterstrich (_) ist das einzige gültige Trennzeichen im Namen.

• Der Name muss innerhalb der Organisation, zu der das verwaltete Konto gehört, eindeutig sein.

Die meisten bestehenden Namen für verwaltete Konten entsprechen bereits den neuen Benennungsregeln, sodass die Namen unverändert bleiben. Namen von verwalteten Konten, die diesen Regeln nicht entsprachen, werden automatisch wie folgt aktualisiert:

• Wenn der Name des verwalteten Kontos Trennzeichen enthält, die keine Unterstriche sind, werden diese in Unterstriche umgewandelt. Wenn der Name des verwalteten Kontos beispielsweise managed account-1 ist, lautet der neue Name des verwalteten Kontos managed_account_1.

• Wenn der Name des verwalteten Kontos für die Organisation nicht eindeutig ist, wird der Name des Konto-Locators an den Namen des verwalteten Kontos angehängt. Wenn der Name des verwalteten Kontos beispielsweise managed mit dem Locator RE47190 ist, lautet der neue Name des verwalteten Kontos managed_RE47190.

Der aktualisierte Name von verwalteten Konten wird in allen Befehlen für verwaltete Konten verwendet:

• CREATE MANAGED ACCOUNT setzt die neuen Benennungsregeln durch.

• SHOW MANAGED ACCOUNTS zeigt den aktualisierten Namen des verwalteten Kontos in der Spalte „Name“ an.

• DROP MANAGED ACCOUNT verwendet den aktualisierten Namen des verwalteten Kontos als Parameter.

Befehl SHOW SHARES und Data Sharing-UI: Änderungen an der Ausgabe¶

Der Befehl SHOW SHARES und die Data Sharing-Weboberfläche, die in der Ausgabe einen Konto-Locator (früher als automatisch generierter Kontoname bekannt) enthalten, verwenden jetzt den Organisationsnamen und den neuen Kontonamen wie folgt:

Bisher

Spalte name zeigte <Konto-Locator>.<Freigabename>

Spalte to (für ausgehende Freigaben) zeigte <Konto-Locator>

Jetzt

Spalte name zeigt <Organisationsname>.<Kontoname>.<Freigabename>

Spalte to (für ausgehende Freigaben) zeigt <Organisationsname>.<Kontoname>

Außerdem können Befehle, die <Konto-Locator>.<Freigabename> als Parameter verwenden (DESCRIBE SHARE und CREATE DATABASE … FROM SHARE), nun <Organisationsname>.<Kontoname>.<Freigabename> als Parameter verwenden.

Weitere Informationen zum Unterschied zwischen Konto-Locator und dem neuen Kontonamen finden Sie unter Kontobezeichner.

SHOW-Befehle und SELECT-Anweisungen: Änderungen bei der Ausgabe, wenn mehrere Freigaben aus derselben Datenbank stammen¶

Bisher

Wenn ein Verbraucher mehrere Datenbanken aus Datenfreigaben eingebunden hatte, die aus derselben Anbieterdatenbank erstellt worden waren (Anbieterkonfiguration Eine Datenbank für viele Freigaben), wurden unter bestimmten Umständen Objekte aus den Datenfreigaben gleichen Ursprungs für einen Benutzer unerwartet in eingebundenen Datenbanken angezeigt, die auf diesen Datenfreigaben gleichen Ursprungs basierten. Dieses Problem hatte keine Auswirkungen auf den tatsächlichen Zugriff auf die Daten. Objekte tauchten in einer Datenbank, die der Benutzer abfragte, nur dann unerwartet auf, wenn dieser eine Zugriffsberechtigung für diese Objekte hatte.

Beispiel: Ein Anbieter möchte Daten von ORIGIN_DATABASE freigeben. ORIGIN_DATABASE hat zwei Schemas: SCHEMA_A und SCHEMA_Z. Der Anbieter möchte drei Tabellen freigeben. Zwei Tabellen stammen von SCHEMA_A: SCHEMA_A.TABLE1 und SCHEMA_A.TABLE2. Der Anbieter möchte auch SCHEMA_Z.TABLE1 freigeben.

Der Anbieter erstellt drei Datenfreigaben: FIRST_DATASHARE aus SCHEMA_A.TABLE1, SECOND_DATASHARE aus SCHEMA_A.TABLE2 und THIRD_DATASHARE aus SCHEMA_Z.TABLE1. Der Anbieter fügt dann den drei Freigaben einen Verbraucher hinzu.

In diesem Beispiel hat der Verbraucher drei Datenbanken auf der Basis der Datenfreigaben des Anbieters eingebunden: FIRST_DATABASE bindet FIRST_DATASHARE ein, SECOND_DATABASE bindet SECOND_DATASHARE ein und THIRD_DATABASE bindet THIRD_DATASHARE ein.

Der Verbraucher in diesem Beispiel war sich möglicherweise nicht bewusst, dass die Datenbanken, die er eingebunden hatte, von ein und derselben Anbieterdatenbank abgeleitet waren.

Wenn der Verbraucher SHOW OBJECTS (z. B. TABLES, FUNCTIONS usw.) verwendet, um seine eingebundenen Datenbanken zu durchsuchen, sieht er in jeder der eingebundenen Datenbanken dieselbe Menge von Objekten aus demselben Ursprungsschema, obwohl die eingebundenen Datenbanken aus verschiedenen Freigaben stammen.

In diesem Beispiel sah der Verbraucher bei Verwendung von SHOW OBJECTS IN ACCOUNT folgendes Ergebnis. Zur besseren Veranschaulichung werden in diesem Beispiel nur die relevanten Spalten der Ausgabe einbezogen. In der Ausgabe werden die Datenbanknamen durch die zuletzt eingebundene Datenbank desselben Ursprungs überschrieben.

name	database_name	schema_name
APPLICABLE_ROLES	THIRD_DATABASE	INFORMATION_SCHEMA
<weitere Info Schema-Objekte>
TABLE1	THIRD_DATABASE	SCHEMA_A
TABLE2	THIRD_DATABASE	SCHEMA_A
APPLICABLE_ROLES	THIRD_DATABASE	INFORMATION_SCHEMA
<weitere Info Schema-Objekte>
TABLE1	THIRD_DATABASE	SCHEMA_A
TABLE2	THIRD_DATABASE	SCHEMA_A
APPLICABLE_ROLES	THIRD_DATABASE	INFORMATION_SCHEMA
<weitere Info Schema-Objekte>
TABLE1	THIRD_DATABASE	SCHEMA_Z

Jetzt

Wenn ein Verbraucher Datenbanken aus Datenfreigaben einbindet, sieht er nur die erwarteten Objekte, die der Anbieter für die jeweilige Datenfreigabe bereitstellen wollte, auch wenn diese Datenfreigaben aus derselben Anbieterdatenbank stammen.

Der Verbraucher im Beispiel sieht nach der Verwendung von SHOW OBJECTS IN ACCOUNT das folgende Ergebnis. Zur besseren Veranschaulichung werden in diesem Beispiel nur die relevanten Spalten der Ausgabe einbezogen.

name	database_name	schema_name
APPLICABLE_ROLES	FIRST_DATABASE	INFORMATION_SCHEMA
<weitere Info Schema-Objekte>
TABLE1	FIRST_DATABASE	SCHEMA_A
APPLICABLE_ROLES	SECOND_DATABASE	INFORMATION_SCHEMA
<weitere Info Schema-Objekte>
TABLE2	SECOND_DATABASE	SCHEMA_A
APPLICABLE_ROLES	THIRD_DATABASE	INFORMATION_SCHEMA
<weitere Info Schema-Objekte>
TABLE1	THIRD_DATABASE	SCHEMA_Z