SQL-Datentypen: Änderungen der maximalen Länge, Ausgabe und Fehlermeldungen (ausstehend)

Achtung

Diese Verhaltensweisen sind im Bundle 2024_08 enthalten.

Den aktuellen Status des Bundles finden Sie unter Bundle-Verlauf.

Mit dieser geänderten Verhaltensweise verhalten sich die kompilierten SQL-Ausdrücke und einige Fehlermeldungen wie folgt:

Vor der Änderung:

  • In kompilierten SQL-Ausdrücken und Fehlermeldungen gab Snowflake explizit die Länge des Datentyps an (z. B. VARCHAR(16777216)).

  • Beim Laden von Objekten, die größer als 16 MB sind, wird ein Fehler im Zusammenhang mit dem Parsen oder der Verarbeitung einer großen Zeichenfolge oder Datei zurückgegeben (z. B. 100069 (22P02): Error parsing JSON: document is too large, max size 16777216 bytes).

Nach der Änderung:

  • In kompilierten SQL-Ausdrücken und Fehlermeldungen lässt Snowflake die Länge des Datentyps weg (z. B. VARCHAR).

  • Beim Laden von Objekten, die größer als 16 MB sind, wird ein Fehler im Zusammenhang mit der Speicherung eines großen Objekts zurückgegeben (zum Beispiel 100082 (22000): Max LOB size (16777216) exceeded, actual size of parsed column is <actual_size>).

In der Vergangenheit trat ein Fehler auf, wenn Sie versuchten, ein Objekt, das größer als 16 MB (8 MB für BINARY, GEOMETRY und GEOGRAPHY) ist, in einem Stagingbereich abzufragen. Sie können nun Objekte mit einer Größe von bis zu 128 MB lesen und verarbeiten. Obwohl Sie immer noch keine Objekte mit einer Größe von mehr als 16 MB in eine Spalte laden oder in einem Resultset ausgeben können, können Sie Objekte mit einer Größe von bis zu 128 MB (64 MB für BINARY, GEOMETRY und GEOGRAPHY) in Dateien in einem Stagingbereich abfragen und die Größe der Objekte reduzieren, bevor Sie die Objekte in Spalten speichern.

Weitere Informationen dazu finden Sie unter Verkleinern der Größe von Objekten, die größer als 16 MB sind, vor dem Laden.

Die neue Größenbeschränkung wird nicht explizit in der SQL-Ausgabe oder in den Metadaten angezeigt. Sie können die neue größere Länge jedoch implizit beachten, indem Sie Objekte mit einer größeren Größe erstellen oder lesen, aber nicht speichern. Die Aktivierung dieser Funktion führt zu den folgenden Verhaltensweisen:

  • VARCHAR und BINARY erscheinen ohne Länge in der Ausgabe der Befehle GET_DDL, SHOW und DESCRIBE für Spaltenausdrücke, UDFs und gespeicherte Prozeduren.

    Zum Beispiel wird VARCHAR anstelle von VARCHAR(16777216) angezeigt. Diese Änderung gilt nur für neu erstellte Objekte, bei denen Sie die Länge nicht ausdrücklich in der DDL-Anweisung angegeben haben. Die Änderung gilt nicht für bestehende Objekte.

  • Einige Anweisungen, die zuvor mit einem Fehler für maximum size exceeded (oder ähnlichen) fehlgeschlagen sind, werden nun erfolgreich sein.

    Anweisungen, die nur laden oder erstellen, aber niemals einen großen Wert speichern oder zurückgeben, sind nun erfolgreich.

  • Einige Anweisungen, die zuvor mit einem Fehler für maximum size exceeded (oder ähnlichem) fehlgeschlagen sind, schlagen weiterhin fehl, allerdings mit einem anderen Fehlercode oder einer anderen Meldung.

    Der neue Fehlercode und die Meldung beziehen sich immer noch auf die Überschreitung der 16-MB-Grenze, aber der Fehler kann von einem anderen Teil des Ausführungsplans ausgehen. Zum Beispiel könnte sich cannot load value in cannot store value oder cannot output value ändern.

Die erste Änderung betrifft alle Kunden. Die zweite und dritte Änderung betrifft Kunden, die versuchen, Objekte zu laden oder zu erzeugen, die größer als 16 MB sind.

Wichtig

Wir raten dringend davon ab, eine Logik zu erstellen, die von Fehlermeldungen abhängt, die mit Objekten größer als 16 MB verbunden sind. Stattdessen können Sie eine Logik erstellen, die die Funktion BIT_LENGTH verwendet, um die Größe des Wertes zu überprüfen.

Änderungen in Metadaten

Es gibt Verhaltensweisen, die sich auf die folgenden Typen von Operationen auswirken:

Bei diesen Typen von Operationen kommt es zu Änderungen der Metadaten im Resultset.

Bemerkung

Diese Auflistung ist nicht vollständig.

Rückgabe von Metadaten für UDFs

Bei neuen benutzerdefinierten Funktionen (UDFs), die VARCHAR- oder BINARY-Werte als Eingabe oder Ausgabe verwenden, wirken sich Änderungen in den Metadaten für DDL-Anweisungen im Zusammenhang mit UDFs auf die Ausgabe aus, die zurückgegeben wird, wenn Sie die GET_DDL-Funktion aufrufen, die DESCRIBE FUNCTION-Anweisung ausführen oder die Ereignistabelle abfragen. Das folgende Beispiel erstellt eine UDF:

CREATE OR REPLACE FUNCTION udf_varchar(g1 VARCHAR)
  RETURNS VARCHAR
  AS $$
    'Hello' || g1
  $$;
Copy

GET_DDL

Die Metadaten, die von einem Aufruf der GET_DDL-Funktion zurückgegeben werden, ändern sich auf folgende Weise:

SELECT GET_DDL('function', 'udf_varchar(VARCHAR)');
Copy
Metadaten vor der Änderung:
CREATE OR REPLACE FUNCTION "UDF_VARCHAR"("G1" VARCHAR(16777216))
RETURNS VARCHAR(16777216)
LANGUAGE SQL
AS '
  ''Hello'' || g1
';
Metadaten nach der Änderung:
CREATE OR REPLACE FUNCTION "UDF_VARCHAR"("G1" VARCHAR)
RETURNS VARCHAR
LANGUAGE SQL
AS '
  ''Hello'' || g1
';

DESCRIBE FUNCTION

Die Metadaten, die für eine DESCRIBE FUNCTION-Anweisung zurückgegeben werden, ändern sich wie folgt:

DESCRIBE FUNCTION udf_varchar(VARCHAR);
Copy
Metadaten vor der Änderung:
+-----------+-------------------+
| property  | value             |
|-----------+-------------------|
| signature | (G1 VARCHAR)      |
| returns   | VARCHAR(16777216) |
| language  | SQL               |
| body      |                   |
|           |   'Hello' || g1   |
|           |                   |
+-----------+-------------------+
Metadaten nach der Änderung:
+-----------+-------------------+
| property  | value             |
|-----------+-------------------|
| signature | (G1 VARCHAR)      |
| returns   | VARCHAR           |
| language  | SQL               |
| body      |                   |
|           |   'Hello' || g1   |
|           |                   |
+-----------+-------------------+

Ereignistabelle

Für neue benutzerdefinierte Funktionen, die VARCHAR- oder BINARY-Werte als Ausgabe zurückgeben, ändert sich das Attribut snow.executable.name in der Spalte RESOURCE_ATTRIBUTES der Ereignistabelle wie folgt:

Metadaten vor der Änderung:
{
  "db.user": "MYUSERNAME",
  "snow.database.id": 13,
  "snow.database.name": "MY_DB",
  "snow.executable.id": 197,
  "snow.executable.name": "UDF_VARCHAR(X VARCHAR):VARCHAR(16777216)",
  "snow.executable.type": "FUNCTION",
  "snow.owner.id": 2,
  "snow.owner.name": "MY_ROLE",
  "snow.query.id": "01ab0f07-0000-15c8-0000-0129000592c2",
  "snow.schema.id": 16,
  "snow.schema.name": "PUBLIC",
  "snow.session.id": 1275605667850,
  "snow.session.role.primary.id": 2,
  "snow.session.role.primary.name": "MY_ROLE",
  "snow.user.id": 25,
  "snow.warehouse.id": 5,
  "snow.warehouse.name": "MYWH",
  "telemetry.sdk.language": "python"
}
Copy
Metadaten nach der Änderung:
{
  "db.user": "MYUSERNAME",
  "snow.database.id": 13,
  "snow.database.name": "MY_DB",
  "snow.executable.id": 197,
  "snow.executable.name": "UDF_VARCHAR(X VARCHAR):VARCHAR",
  "snow.executable.type": "FUNCTION",
  "snow.owner.id": 2,
  "snow.owner.name": "MY_ROLE",
  "snow.query.id": "01ab0f07-0000-15c8-0000-0129000592c2",
  "snow.schema.id": 16,
  "snow.schema.name": "PUBLIC",
  "snow.session.id": 1275605667850,
  "snow.session.role.primary.id": 2,
  "snow.session.role.primary.name": "MY_ROLE",
  "snow.user.id": 25,
  "snow.warehouse.id": 5,
  "snow.warehouse.name": "MYWH",
  "telemetry.sdk.language": "python"
}
Copy

Rückgabe von Metadaten für Tabellen mit Spaltenausdrücken

Bei neuen Tabellen, die VARCHAR oder BINARY in Spaltenausdrücken verwenden, beeinflussen Änderungen in den Metadaten für DDL-Anweisungen, die sich auf diese Spalten beziehen, die Ausgabe, die zurückgegeben wird, wenn Sie die Funktion GET_DDL aufrufen.

Das folgende Beispiel erstellt eine Tabelle mit einem Spaltenausdruck:

CREATE OR REPLACE TABLE table_with_default(x INT, v TEXT DEFAULT x::VARCHAR);
Copy

Die Metadaten, die von einem Aufruf der GET_DDL-Funktion zurückgegeben werden, ändern sich auf folgende Weise:

SELECT GET_DDL('table', 'table_with_default');
Copy
Metadaten vor der Änderung:
create or replace TABLE TABLE_WITH_DEFAULT ( |
      X NUMBER(38,0),
      V VARCHAR(16777216) DEFAULT CAST(TABLE_WITH_DEFAULT.X AS VARCHAR(16777216))
);
Metadaten nach der Änderung:
create or replace TABLE TABLE_WITH_DEFAULT ( |
      X NUMBER(38,0),
      V VARCHAR(16777216) DEFAULT CAST(TABLE_WITH_DEFAULT.X AS VARCHAR)
);

Externe Tabellen

Das folgende Beispiel erstellt eine externe Tabelle:

CREATE OR REPLACE EXTERNAL TABLE ext_table(
    data_str VARCHAR AS (value:c1::TEXT))
  LOCATION = @csv_stage
  AUTO_REFRESH = false
  FILE_FORMAT =(type = csv);
Copy

Die Metadaten, die von einem Aufruf der GET_DDL-Funktion zurückgegeben werden, ändern sich auf folgende Weise:

SELECT GET_DDL('table', 'ext_table');
Copy
Metadaten vor der Änderung:
create or replace external table EXT_TABLE(
      DATA_STR VARCHAR(16777216) AS (CAST(GET(VALUE, 'c1') AS VARCHAR(16777216))))
location=@CSV_STAGE/
auto_refresh=false
file_format=(TYPE=csv)
;
Metadaten nach der Änderung:
create or replace external table EXT_TABLE(
      DATA_STR VARCHAR(16777216) AS (CAST(GET(VALUE, 'c1') AS VARCHAR)))
location=@CSV_STAGE/
auto_refresh=false
file_format=(TYPE=csv)
;

Rückgabe von Metadaten für SYSTEM$TYPEOF

Die Metadaten, die bei einem Aufruf der Funktion SYSTEM$TYPEOF zurückgegeben werden, ändern sich wie folgt:

SELECT SYSTEM$TYPEOF(REPEAT('a',10));
Copy
Metadaten vor der Änderung:
VARCHAR(16777216)[LOB]
Metadaten nach der Änderung:
VARCHAR[LOB]

Rückgabe von Metadaten für SHOW COLUMNS

Diese Änderung betrifft sowohl bestehende als auch neue Tabellen. Die Metadaten, die für eine SHOW COLUMNS-Anweisung zurückgegeben werden, ändern sich wie folgt:

CREATE OR REPLACE TABLE t AS
  SELECT TO_VARIANT('abc') AS col;

SHOW COLUMNS IN t;
Copy
Metadaten vor der Änderung:
{
  "type":"VARIANT",
  "length":16777216,
  "byteLength":16777216,
  "nullable":true,
  "fixed":false
}
Metadaten nach der Änderung:
{
  "type":"VARIANT",
  "nullable":true,
  "fixed":false
}

Änderungen beim Laden und Verarbeiten von Objekten, die größer als 16 MB

Es gibt Änderungen in der Verhaltensweise, die Fälle betreffen, in denen Sie versuchen, Objekte zu laden oder zu verarbeiten, die größer als 16 MB sind, indem Sie die folgenden Typen von Operationen verwenden:

Bemerkung

Diese Auflistung ist nicht vollständig.

Laden von Daten durch Scannen von Dateien in einem Stagingbereich

Wenn Sie versuchen, durch Scannen von Dateien in einem Stagingbereich Daten zu laden, die größer als 16 MB sind, wird eine Fehlermeldung ausgegeben.

Laden eines vollständigen großen Objekts mit CREATE TABLE AS SELECT

Eine andere Fehlermeldung erscheint, wenn Sie versuchen, mit der Anweisung CREATE TABLE AS SELECT Objekte zu laden, die größer als 16 MB für VARCHAR, VARIANT, OBJECT und ARRAY (oder größer als 8 MB für BINARY, GEOMETRY oder GEOGRAPHY) sind. Der Fehler hängt von der Art der Quelle ab. Die gleiche Meldung ändert sich, wenn eine INSERT INTO SELECT-Anweisung für dieses Szenario verwendet wird.

Laden eines vollständigen großen Objekts aus einer JSON-Quelle

Im folgenden Beispiel wird versucht, ein vollständiges Objekt, das größer als 16 MB ist, aus einer JSON-Quelle mithilfe von CREATE TABLE AS SELECT zu laden:

CREATE OR REPLACE FILE FORMAT json_format TYPE = JSON;

CREATE OR REPLACE TABLE table_varchar (lob_column VARCHAR) AS
  SELECT $1::VARCHAR
    FROM @lob_int_stage/driver_status.json.gz (FILE_FORMAT => 'json_format');
Copy
Fehlermeldung vor der Änderung:
100069 (22P02): Error parsing JSON: document is too large, max size 16777216 bytes
Fehlermeldung nach der Änderung:
100082 (22000): Max LOB size (16777216) exceeded, actual size of parsed column is <actual_size>
Laden eines vollständigen großen Objekts aus einer XML-Quelle

Im folgenden Beispiel wird versucht, ein vollständiges Objekt, das größer als 16 MB ist, aus einer XML-Quelle mithilfe von CREATE TABLE AS SELECT zu laden:

CREATE or REPLACE FILE FORMAT xml_format TYPE = XML;

CREATE OR REPLACE TABLE table_varchar (lob_column VARCHAR) AS
  SELECT $1 AS XML
    FROM @lob_int_stage/large_xml.xte (FILE_FORMAT => 'xml_format');
Copy
Fehlermeldung vor der Änderung:
100100 (22P02): Error parsing XML: document is too large, max size 16777216 bytes
Fehlermeldung nach der Änderung:
100078 (22000): String '<string_preview>' is too long and would be truncated

Laden eines vollständigen großen Objekts mit COPY INTO <table_name> … FROM SELECT

Eine andere Fehlermeldung erscheint, wenn Sie versuchen, eine COPY INTO <table_name> … FROM SELECT-Anweisung zu verwenden, um Objekte zu laden, die größer als 16 MB für VARCHAR, VARIANT, OBJECT und ARRAY (oder größer als 8 MB für BINARY, GEOMETRY oder GEOGRAPHY) sind. Der Fehler hängt von der Art der Quelle ab.

Wichtig

Wenn Sie versuchen, Daten zu laden, die Objekte enthalten, die größer als 16 MB sind, indem Sie den Befehl COPY INTO mit ON_ERROR=CONTINUE verwenden und sich auf die im Fehlerprotokoll geschriebenen Fehlermeldungen verlassen, könnte die Änderung der Fehlermeldung Probleme in der Logik verursachen, die von der Fehlermeldung abhängt.

Laden eines vollständigen großen Objekts aus einer JSON-Quelle

Das folgende Beispiel versucht, ein vollständiges Objekt, das größer als 16 MB ist, aus einer JSON-Quelle zu laden, indem COPY INTO <table_name> … FROM SELECT verwendet wird:

CREATE OR REPLACE TABLE table_varchar (lob_column VARCHAR);

COPY INTO table_varchar FROM (
  SELECT $1::VARCHAR
    FROM @lob_int_stage/driver_status.json.gz (FILE_FORMAT => 'json_format'));
Copy
Fehlermeldung vor der Änderung:
100069 (22P02): Error parsing JSON: document is too large, max size 16777216 bytes
Fehlermeldung nach der Änderung:
100082 (22000): Max LOB size (16777216) exceeded, actual size of parsed column is <actual_size>
Laden großer verschachtelter Objekte aus einer JSON-Quelle

Das folgende Beispiel versucht, JSON-Daten zu laden, wenn Sie auf große verschachtelte Objekte zugreifen:

CREATE OR REPLACE TABLE table_varchar (lob_column VARCHAR);

COPY INTO table_varchar FROM (
  SELECT $1:"Driver_Status"
    FROM @lob_int_stage/driver_status.json.gz (FILE_FORMAT => 'json_format'));
Copy
Fehlermeldung vor der Änderung:
100069 (22P02): Max LOB size (16777216) exceeded, actual size of parsed column is <object_size>
Fehlermeldung nach der Änderung:
100082 (22000): Max LOB size (16777216) exceeded, actual size of parsed column is <actual_size>
Laden eines vollständigen großen Objekts aus einer XML-Quelle

Das folgende Beispiel versucht, ein ganzes Objekt, das größer als 16 MB ist, aus einer XML-Quelle zu laden, indem COPY INTO <table_name> … FROM SELECT verwendet wird:

CREATE OR REPLACE TABLE table_varchar (lob_column VARCHAR);

COPY INTO table_varchar FROM (
  SELECT $1::VARCHAR AS lob_column
    FROM @lob_int_stage/large_xml.xte (FILE_FORMAT => 'xml_format'));
Copy
Fehlermeldung vor der Änderung:
100100 (22P02): Error parsing XML: document is too large, max size 16777216 bytes
Fehlermeldung nach der Änderung:
100082 (22000): Max LOB size (16777216) exceeded, actual size of parsed column is <object_size>

Laden eines vollständigen großen Objekts mit COPY INTO <table_name> … FROM <stage_or_location>

Eine andere Fehlermeldung erscheint, wenn Sie versuchen, mit einer COPY INTO <table_name> … FROM <stage_or_location>-Anweisung Objekte zu laden, die größer als 16 MB für VARCHAR, VARIANT, OBJECT und ARRAY (oder größer als 8 MB für BINARY, GEOMETRY oder GEOGRAPHY) sind. Der Fehler hängt von der Art der Quelle ab.

Wenn Sie den Befehl COPY mit großen Objekten verwenden, können Abfragen fehlschlagen, auch wenn der Parameter ON_ERROR auf CONTINUE eingestellt ist. Weitere Informationen finden Sie in den Nutzungshinweisen für den Befehl COPY.

Wichtig

Wenn Sie versuchen, Daten zu laden, die Objekte enthalten, die größer als 16 MB sind, indem Sie den Befehl COPY INTO mit ON_ERROR=CONTINUE verwenden und sich auf die im Fehlerprotokoll geschriebenen Fehlermeldungen verlassen, könnte die Änderung der Fehlermeldung Probleme in der Logik verursachen, die von der Meldung abhängt.

Laden eines vollständigen großen Objekts aus einer JSON-Quelle

Das folgende Beispiel versucht, ein vollständiges Objekt, das größer als 16 MB ist, aus einer JSON-Quelle zu laden, indem COPY INTO <table_name> … FROM <stage_or_location> verwendet wird:

CREATE OR REPLACE TABLE table_varchar (lob_column VARCHAR);

COPY INTO table_varchar (lob_column)
  FROM @lob_int_stage/driver_status.json.gz
  FILE_FORMAT = (FORMAT_NAME = json_format);
Copy
Fehlermeldung vor der Änderung:
100069 (22P02): Error parsing JSON: document is too large, max size 16777216 bytes
Fehlermeldung nach der Änderung:
100082 (22000): Max LOB size (16777216) exceeded, actual size of parsed column is <actual_size>
Laden eines vollständigen großen Objekts aus einer XML-Quelle

Das folgende Beispiel versucht, ein ganzes Objekt, das größer als 16 MB ist, aus einer XML-Quelle zu laden, indem COPY INTO <table_name> … FROM <stage_or_location> verwendet wird:

CREATE OR REPLACE TABLE table_varchar (lob_column VARCHAR);

COPY INTO table_varchar (lob_column)
  FROM @lob_int_stage/large_xml.xte
  FILE_FORMAT = (FORMAT_NAME = xml_format);
Copy
Fehlermeldung vor der Änderung:
100100 (22P02): Error parsing XML: document is too large, max size 16777216 bytes
Fehlermeldung nach der Änderung:
100082 (22000): Max LOB size (16777216) exceeded, actual size of parsed column is <actual_size>

Abfrage eines vollständigen großen Objekts aus einer Quelldatei

Da Objekte, die größer als 16 MB sind, derzeit nicht in einem Resultset erlaubt sind, erscheint eine andere Fehlermeldung, wenn Sie versuchen, Objekte aus einer Quelldatei abzufragen, die größer als 16 MB für VARCHAR, VARIANT, OBJECT und ARRAY (oder größer als 8 MB für BINARY, GEOMETRY oder GEOGRAPHY) sind. Der Fehler hängt von der Art der Quelle ab.

Abfrage eines vollständigen großen Objekts aus einer JSON-Quelle

Im folgenden Beispiel wird versucht, ein vollständiges Objekt, das größer als 16 MB ist, aus einer JSON-Quelle abzufragen:

SELECT $1
  FROM @lob_int_stage/driver_status.json.gz (FILE_FORMAT => 'json_format');
Copy
Fehlermeldung vor der Änderung:
100069 (22P02): Error parsing JSON: document is too large, max size 16777216 bytes
Fehlermeldung nach der Änderung:
100082 (22000): The data length in result column $1 is not supported by this version of the client. Actual length <actual_length> exceeds supported length of 16777216.

Abfrage eines vollständigen großen Objekts aus einer XML-Quelle

Im folgenden Beispiel wird versucht, ein vollständiges Objekt, das größer als 16 MB ist, aus einer XML-Quelle abzufragen:

SELECT $1 as lob_column
  FROM @lob_int_stage/large_xml.xte (FILE_FORMAT => 'xml_format');
Copy
Fehlermeldung vor der Änderung:
100100 (22P02): Error parsing XML: document is too large, max size 16777216 bytes
Fehlermeldung nach der Änderung:
100082 (22000): The data length in result column $1 is not supported by this version of the client. Actual length <actual_length> exceeds supported length of 16777216.

Abfrage eines vollständigen großen Objekts aus einer CSV-Quelle

Im folgenden Beispiel wird versucht, ein vollständiges Objekt, das größer als 16 MB ist, aus einer CSV-Quelle abzufragen:

SELECT $1
  FROM @lob_int_stage/driver_status.csv.gz (FILE_FORMAT => 'csv_format');
Copy
Fehlermeldung vor der Änderung:
100082 (22000): Max LOB size (16777216) exceeded, actual size of parsed column is <object_size>
Fehlermeldung nach der Änderung:
100082 (22000): The data length in result column $1 is not supported by this version of the client. Actual length <actual_length> exceeds supported length of 16777216.

Abfrage eines vollständigen großen Objekts aus einer Parquet-Quelle

Im folgenden Beispiel wird versucht, ein vollständiges Objekt, das größer als 16 MB ist, aus einer Parquet-Quelle abzufragen:

SELECT $1
  FROM @lob_int_stage/driver_status.parquet (FILE_FORMAT => 'parquet_format');
Copy
Fehlermeldung vor der Änderung:
100082 (22000): Max LOB size (16777216) exceeded, actual size of parsed column is <object_size>
Fehlermeldung nach der Änderung:
100082 (22000): The data length in result column $1 is not supported by this version of the client. Actual length <actual_length> exceeds supported length of 16777216.

Große Objekte in Abfrageergebnisse aufnehmen

Sie können jetzt Objekte erstellen, die größer als 16 MB im Speicher sind. Sie können diese Objekte jedoch nicht in Abfrageergebnisse einbeziehen oder sie in einer Tabelle speichern. Wenn Sie dies versuchen, erhalten Sie eine Fehlermeldung.

Der Versuch, ein Objekt größer als 16 MB in die Abfrageergebnisse aufzunehmen

Die folgende Abfrage versucht, zwei große Zeichenfolgen zu verketten:

SELECT large_str || large_str FROM lob_strings;
Copy
Fehlermeldung vor der Änderung:
100078 (22000): String '<preview_of_string>' is too long and would be truncated in 'CONCAT'
Fehlermeldung nach der Änderung:
100067 (54000): The data length in result column <column_name> is not supported by this version of the client. Actual length <actual_size> exceeds supported length of 16777216.

Der Versuch, ein Objekt größer als 16 MB in einer Tabelle zu speichern

Mit der folgenden CREATE TABLE AS SELECT-Anweisung wird versucht, zwei große Zeichenfolgen zu verketten:

CREATE OR REPLACE TABLE table_varchar
  AS SELECT large_str || large_str as LOB_column
  FROM lob_strings;
Copy
Fehlermeldung vor der Änderung:
100078 (22000): String '<preview_of_string>' is too long and would be truncated in 'CONCAT'
Fehlermeldung nach der Änderung:
100067 (54000): The data length in result column <column_name> is not supported by this version of the client. Actual length <actual_size> exceeds supported length of 16777216.

Erstellen eines großen Objekts durch Aggregation

Wenn Sie versuchen, ein Objekt zu erstellen, das größer als 16 MB ist, und dafür eine Ausgabe zu erstellen, wird eine Fehlermeldung zurückgegeben.

Das folgende Beispiel verwendet die ARRAY_AGG-Funktion in einer Abfrage einer großen Objektspalte:

SELECT ARRAY_AGG(status) FROM lob_object;
Copy
Fehlermeldung vor der Änderung:
100082 (22000): Max LOB size (16777216) exceeded, actual size of parsed column is <actual_size>
Fehlermeldung nach der Änderung:
100067 (54000): The data length in result column <column_name> is not supported by this version of the client. Actual length <actual_size> exceeds supported length of 16777216.

Ref.: 1779

Sprache: Deutsch