Übersetzungsleitfaden für Oracle SQL

In diesem Dokument werden die Gemeinsamkeiten und Unterschiede in der SQL-Syntax zwischen Oracle und BigQuery beschrieben, damit Sie die Migration planen können. Verwenden Sie die Batch-SQL-Übersetzung, um Ihre SQL-Skripts im Bulk zu migrieren, oder die interaktive SQL-Übersetzung, um Ad-hoc-Abfragen zu übersetzen.

Datentypen

In diesem Abschnitt werden die Entsprechungen zwischen den Datentypen in Oracle und BigQuery beschrieben.

Oracle BigQuery Hinweise
VARCHAR2 STRING
NVARCHAR2 STRING
CHAR STRING
NCHAR STRING
CLOB STRING
NCLOB STRING
INTEGER INT64
SHORTINTEGER INT64
LONGINTEGER INT64
NUMBER NUMERIC In BigQuery sind keine benutzerdefinierten Werte für die Genauigkeit oder Skalierung zulässig. Daher kann eine Spalte in Oracle so definiert werden, dass sie eine größere Größe hat als BigQuery unterstützt.

Vor dem Speichern einer Dezimalzahl wird außerdem aufgerundet, wenn diese Zahl nach dem Dezimalzeichen mehr Ziffern enthält, als für die entsprechende Spalte angegeben ist. In BigQuery kann diese Funktion mit der Funktion ROUND() implementiert werden.

NUMBER(*, x) NUMERIC In BigQuery sind keine benutzerdefinierten Werte für die Genauigkeit oder Skalierung zulässig. Daher kann eine Spalte in Oracle so definiert werden, dass sie eine größere Größe hat als BigQuery unterstützt.

Vor dem Speichern einer Dezimalzahl wird außerdem aufgerundet, wenn diese Zahl nach dem Dezimalzeichen mehr Ziffern enthält, als für die entsprechende Spalte angegeben ist. In BigQuery kann diese Funktion mit der Funktion ROUND() implementiert werden.

NUMBER(x, -y) INT64 Wenn ein Nutzer versucht, eine Dezimalzahl zu speichern, rundet Oracle diese auf eine ganze Zahl auf. Bei BigQuery führt ein Versuch, eine Dezimalzahl in einer Spalte zu speichern, die als INT64 definiert ist, zu einem Fehler. In diesem Fall sollte die Funktion ROUND() angewendet werden.

INT64-Datentypen in BigQuery ermöglichen eine Genauigkeit von bis zu 18 Stellen. Wenn ein Zahlenfeld mehr als 18 Ziffern hat, sollte in BigQuery der Datentyp FLOAT64 verwendet werden.

NUMBER(x) INT64 Wenn ein Nutzer versucht, eine Dezimalzahl zu speichern, rundet Oracle diese auf eine ganze Zahl auf. Bei BigQuery führt ein Versuch, eine Dezimalzahl in einer Spalte zu speichern, die als INT64 definiert ist, zu einem Fehler. In diesem Fall sollte die Funktion ROUND() angewendet werden.

INT64-Datentypen in BigQuery ermöglichen eine Genauigkeit von bis zu 18 Stellen. Wenn ein Zahlenfeld mehr als 18 Ziffern hat, sollte in BigQuery der Datentyp FLOAT64 verwendet werden.

FLOAT FLOAT64/NUMERIC FLOAT ist ein exakter Datentyp und ist ein NUMBER-Untertyp in Oracle. In BigQuery ist FLOAT64 ein ungefährer Datentyp. NUMERIC ist in BigQuery möglicherweise besser für den Typ FLOAT geeignet.
BINARY_DOUBLE FLOAT64/NUMERIC FLOAT ist ein exakter Datentyp und ist ein NUMBER-Untertyp in Oracle. In BigQuery ist FLOAT64 ein ungefährer Datentyp. NUMERIC ist in BigQuery möglicherweise besser für den Typ FLOAT geeignet.
BINARY_FLOAT FLOAT64/NUMERIC FLOAT ist ein exakter Datentyp und ist ein NUMBER-Untertyp in Oracle. In BigQuery ist FLOAT64 ein ungefährer Datentyp. NUMERIC ist in BigQuery möglicherweise besser für den Typ FLOAT geeignet.
LONG BYTES Der Datentyp LONG wird in früheren Versionen verwendet und wird in neuen Versionen von Oracle Database nicht empfohlen.

Der Datentyp BYTES kann in BigQuery verwendet werden, wenn die LONG-Daten in BigQuery gespeichert werden müssen. Ein besserer Ansatz wäre, binäre Objekte in Cloud Storage zu platzieren und Verweise in BigQuery zu speichern.

BLOB BYTES BYTES-Datentyp kann zum Speichern von Binärdaten mit variabler Länge verwendet werden. Wenn dieses Feld nicht abgefragt und nicht für Analysen verwendet wird, ist es besser, Binärdaten in Cloud Storage zu speichern.
BFILE STRING Binärdateien können in Cloud Storage gespeichert werden und der Datentyp STRING kann zum Verweis auf Dateien in einer BigQuery-Tabelle verwendet werden.
DATE DATETIME
TIMESTAMP TIMESTAMP BigQuery unterstützt eine Mikrosekundenpräzision (10-6) im Vergleich zu Oracle, das eine Genauigkeit von 0 bis 9 unterstützt.

BigQuery unterstützt einen Zeitzonenregionsnamen aus einer TZ-Datenbank und einen Zeitzonenversatz zu UTC.

In BigQuery sollte eine Zeitzonenkonvertierung manuell durchgeführt werden, um der TIMESTAMP WITH LOCAL TIME ZONE-Funktion von Oracle zu entsprechen.

TIMESTAMP(x) TIMESTAMP BigQuery unterstützt eine Mikrosekundenpräzision (10-6) im Vergleich zu Oracle, das eine Genauigkeit von 0 bis 9 unterstützt.

BigQuery unterstützt einen Zeitzonenregionsnamen aus einer TZ-Datenbank und einen Zeitzonenversatz zu UTC.

In BigQuery sollte eine Zeitzonenkonvertierung manuell durchgeführt werden, um der TIMESTAMP WITH LOCAL TIME ZONE-Funktion von Oracle zu entsprechen.

TIMESTAMP WITH TIME ZONE TIMESTAMP BigQuery unterstützt eine Mikrosekundenpräzision (10-6) im Vergleich zu Oracle, das eine Genauigkeit von 0 bis 9 unterstützt.

BigQuery unterstützt einen Zeitzonenregionsnamen aus einer TZ-Datenbank und einen Zeitzonenversatz zu UTC.

In BigQuery sollte eine Zeitzonenkonvertierung manuell durchgeführt werden, um der TIMESTAMP WITH LOCAL TIME ZONE-Funktion von Oracle zu entsprechen.

TIMESTAMP WITH LOCAL TIME ZONE TIMESTAMP BigQuery unterstützt eine Mikrosekundenpräzision (10-6) im Vergleich zu Oracle, das eine Genauigkeit von 0 bis 9 unterstützt.

BigQuery unterstützt einen Zeitzonenregionsnamen aus einer TZ-Datenbank und einen Zeitzonenversatz zu UTC.

In BigQuery sollte eine Zeitzonenkonvertierung manuell durchgeführt werden, um der TIMESTAMP WITH LOCAL TIME ZONE-Funktion von Oracle zu entsprechen.

INTERVAL YEAR TO MONTH STRING Intervallwerte können als Datentyp STRING in BigQuery gespeichert werden.
INTERVAL DAY TO SECOND STRING Intervallwerte können als Datentyp STRING in BigQuery gespeichert werden.
RAW BYTES BYTES-Datentyp kann zum Speichern von Binärdaten mit variabler Länge verwendet werden. Wenn dieses Feld nicht abgefragt und in Analysen verwendet wird, ist es besser, Binärdaten in Cloud Storage zu speichern.
LONG RAW BYTES BYTES-Datentyp kann zum Speichern von Binärdaten mit variabler Länge verwendet werden. Wenn dieses Feld nicht abgefragt und in Analysen verwendet wird, ist es besser, Binärdaten in Cloud Storage zu speichern.
ROWID STRING Diese Datentypen werden intern von Oracle verwendet, um eindeutige Adressen für Zeilen in einer Tabelle anzugeben. Im Allgemeinen sollte das Feld ROWID oder UROWID nicht in Anwendungen verwendet werden. In diesem Fall kann der Datentyp STRING jedoch zur Speicherung dieser Daten verwendet werden.

Typformattierung

Oracle SQL verwendet eine Reihe von Standardformaten, die als Parameter zum Anzeigen von Ausdrücken und Spaltendaten sowie für die Konvertierung zwischen Datentypen festgelegt werden. Beispiel: Für NLS_DATE_FORMAT, die als YYYY/MM/DD-Formate festgelegt ist, wird standardmäßig das Datum YYYY/MM/DD festgelegt. Weitere Informationen zu den NLS-Einstellungen finden Sie in der Oracle-Onlinedokumentation. In BigQuery gibt es keine Initialisierungsparameter.

BigQuery erwartet standardmäßig, dass alle Quelldaten beim Laden UTF-8-codiert sind. Wenn Sie wahlweise CSV-Dateien mit codierten Daten im ISO-8859-1-Format vorliegen haben, müssen Sie die Codierung ausdrücklich beim Importieren der Daten angeben. Dies ist erforderlich, damit BigQuery die Daten während des Importvorgangs ordnungsgemäß in UTF-8 konvertieren kann.

Nur ISO-8859-1- oder UTF-8-codierte Daten können importiert werden. BigQuery speichert und gibt die Daten in UTF-8-Codierung zurück. Das gewünschte Datumsformat oder die Zeitzone kann in den Funktionen DATE und TIMESTAMP festgelegt werden.

Formatierung von Zeitstempel und Datumstyp

Wenn Sie Zeitstempel- und Datumsformatierungselemente von Oracle in BigQuery konvertieren, müssen Sie die Zeitzonenunterschiede zwischen TIMESTAMP und DATETIME berücksichtigen, wie in der folgenden Tabelle zusammengefasst.

In den Teradata-Formaten gibt es keine Klammern, da die Formate (CURRENT_*) Keywords und keine Funktionen sind.

Oracle BigQuery Hinweise
CURRENT_TIMESTAMP TIMESTAMP-Informationen in Oracle können unterschiedliche Zeitzoneninformationen haben, die mit WITH TIME ZONE in der Spaltendefinition oder TIME_ZONE-Einstellung definiert werden. Verwenden Sie nach Möglichkeit die Funktion CURRENT_TIMESTAMP(), die im ISO-Format formatiert ist. Das Ausgabeformat zeigt jedoch immer die UTC-Zeitzone an. (Intern hat BigQuery keine Zeitzone.)

Beachten Sie die folgenden Details zu den Unterschieden im ISO-Format:

DATETIME wird basierend auf den Ausgabekanalkonventionen formatiert. Im BigQuery-Befehlszeilentool und der BigQuery-Konsole DATETIME wird mit einem Trennzeichen T gemäß RFC 3339 formatiert. In Python und Java JDBC wird jedoch ein Leerzeichen als Trennzeichen verwendet.

Wenn Sie ein explizites Format nutzen möchten, verwenden Sie die Funktion FORMAT_DATETIME(), die eine explizite Umwandlung eines Strings ermöglicht. Der folgende Ausdruck gibt beispielsweise immer ein Leerzeichen-Trennzeichen zurück: CAST(CURRENT_DATETIME() AS STRING)

CURRENT_DATE
SYSDATE 		Oracle verwendet für das Datum zwei Typen:
  • Typ 12
  • Typ 13
Oracle verwendet beim Speichern von Datumsangaben den Typ 12. Intern sind es Zahlen mit fester Länge. Oracle verwendet den Typ 13, wenn ein von SYSDATE or CURRENT_DATE zurückgegeben wird. 		BigQuery hat ein separates DATE-Format, das immer ein Datum im ISO 8601-Format zurückgibt.

DATE_FROM_UNIX_DATE kann nicht verwendet werden, da es auf 1970 basiert.

CURRENT_DATE-3 Datumswerte werden als Ganzzahlen dargestellt. Oracle unterstützt arithmetische Operatoren für Datumstypen. Verwenden Sie für Datumstypen DATE_ADD() oder DATE_SUB(). BigQuery verwendet arithmetische Operatoren für die Datentypen INT64, NUMERIC und FLOAT64.
NLS_DATE_FORMAT Legen Sie das Sitzungs- oder Systemdatumsformat fest. BigQuery verwendet immer ISO 8601. Gewährleisten Sie daher, dass Sie Teradata-Datums- und Zeitangaben konvertieren.

Abfragesyntax

In diesem Abschnitt werden Unterschiede in der Abfragesyntax zwischen Oracle und BigQuery behandelt.

SELECT-Anweisungen

Die meisten Oracle-SELECT-Anweisungen sind mit BigQuery kompatibel.

Funktionen, Operatoren und Ausdrücke

In den folgenden Abschnitten werden Zuordnungen zwischen Oracle-Funktionen und BigQuery-Entsprechungen aufgeführt.

Vergleichsoperator

Die Vergleichsoperatoren von Oracle und BigQuery sind ANSI SQL:2011-konform. Die Vergleichsoperatoren in der folgenden Tabelle sind sowohl in BigQuery als auch in Oracle identisch. Sie können in BigQuery REGEXP_CONTAINS anstelle von REGEXP_LIKE verwenden.

Operator Beschreibung
"=" Gleich
<> Ungleich
!= Ungleich
> Größer als
>= Größer als oder gleich
< Kleiner als
<= Kleiner als oder gleich
IN ( ) Stimmt mit einem Wert in einer Liste überein
NOT Bedingung negiert
BETWEEN Innerhalb eines Bereichs (einschließlich)
IS NULL NULL Wert
IS NOT NULL Nicht NULL Wert
LIKE Musterabgleich mit %
EXISTS Bedingung wird erfüllt, wenn die Unterabfrage mindestens eine Zeile zurückgibt

Die Operatoren in der Tabelle sind in BigQuery und Oracle identisch.

Logische Ausdrücke und Funktionen

Oracle BigQuery
CASE CASE
COALESCE COALESCE(expr1, ..., exprN)
DECODE CASE.. WHEN.. END
NANVL IFNULL
FETCH NEXT> LIMIT
NULLIF NULLIF(expression, expression_to_match)
NVL IFNULL(expr, 0), COALESCE(exp, 0)
NVL2 IF(expr, true_result, else_result)

Aggregatfunktionen

Die folgende Tabelle zeigt Zuordnungen zwischen gängigen Oracle-Aggregatfunktionen, statistischen Aggregatfunktionen und ungefähren Aggregatfunktionen mit ihren BigQuery-Entsprechungen:

Oracle BigQuery
ANY_VALUE
(von Oracle 19c)		 ANY_VALUE
APPROX_COUNT HLL_COUNT set of functions with specified precision
APPROX_COUNT_DISTINCT APPROX_COUNT_DISTINCT
APPROX_COUNT_DISTINCT_AGG APPROX_COUNT_DISTINCT
APPROX_COUNT_DISTINCT_DETAIL APPROX_COUNT_DISTINCT
APPROX_PERCENTILE(percentile) WITHIN GROUP (ORDER BY expression) APPROX_QUANTILES(expression, 100)[
OFFSET(CAST(TRUNC(percentile * 100) as INT64))]
BigQuery unterstützt nicht die übrigen Argumente, die von Oracle definiert werden.
<codeAPPROX_PERCENTILE_AGG APPROX_QUANTILES(expression, 100)[
OFFSET(CAST(TRUNC(percentile * 100) as INT64))]
APPROX_PERCENTILE_DETAIL APPROX_QUANTILES(expression, 100)[OFFSET(CAST(TRUNC(percentile * 100) as INT64))]
APPROX_SUM APPROX_TOP_SUM(expression, weight, number)
AVG AVG
BIT_COMPLEMENT Bitweiser Not-Operator: ~
BIT_OR BIT_OR, X | Y
BIT_XOR BIT_XOR, X ^ Y
BITAND BIT_AND, X & Y
CARDINALITY COUNT
COLLECT BigQuery unterstützt TYPE AS TABLE OF nicht. Verwenden Sie gegebenenfalls STRING_AGG() oder ARRAY_AGG() in BigQuery
CORR/CORR_K/ CORR_S CORR
COUNT COUNT
COVAR_POP COVAR_POP
COVAR_SAMP COVAR_SAMP
FIRST Gibt es implizit nicht in BigQuery. Verwenden Sie stattdessen benutzerdefinierte Funktionen (User-Defined Functions, UDFs).
GROUP_ID Wird in BigQuery nicht verwendet.
GROUPING Wird in BigQuery nicht verwendet.
GROUPING_ID Wird in BigQuery nicht verwendet.
LAST Gibt es implizit nicht in BigQuery. Verwenden Sie stattdessen UDFs.
LISTAGG STRING_AGG, ARRAY_CONCAT_AGG(expression [ORDER BY key [{ASC|DESC}] [, ... ]] [LIMIT n])
MAX MAX
MIN MIN
OLAP_CONDITION Oracle-spezifisch, ist in BigQuery nicht vorhanden.
OLAP_EXPRESSION Oracle-spezifisch, ist in BigQuery nicht vorhanden.
OLAP_EXPRESSION_BOOL Oracle-spezifisch, ist in BigQuery nicht vorhanden.
OLAP_EXPRESSION_DATE Oracle-spezifisch, ist in BigQuery nicht vorhanden.
OLAP_EXPRESSION_TEXT Oracle-spezifisch, ist in BigQuery nicht vorhanden.
OLAP_TABLE Oracle-spezifisch, ist in BigQuery nicht vorhanden.
POWERMULTISET Oracle-spezifisch, ist in BigQuery nicht vorhanden.
POWERMULTISET_BY_CARDINALITY Oracle-spezifisch, ist in BigQuery nicht vorhanden.
QUALIFY Oracle-spezifisch, ist in BigQuery nicht vorhanden.
REGR_AVGX AVG(
IF(dep_var_expr is NULL
OR ind_var_expr is NULL,
NULL, ind_var_expr)
)
REGR_AVGY AVG(
IF(dep_var_expr is NULL
OR ind_var_expr is NULL,
NULL, dep_var_expr)
)
REGR_COUNT SUM(
IF(dep_var_expr is NULL
OR ind_var_expr is NULL,
NULL, 1)
)
REGR_INTERCEPT AVG(dep_var_expr)
- AVG(ind_var_expr)
* (COVAR_SAMP(ind_var_expr,dep_var_expr)
/ VARIANCE(ind_var_expr)
)
REGR_R2 (COUNT(dep_var_expr) *
SUM(ind_var_expr * dep_var_expr) -
SUM(dep_var_expr) * SUM(ind_var_expr))
/ SQRT(
(COUNT(ind_var_expr) *
SUM(POWER(ind_var_expr, 2)) *
POWER(SUM(ind_var_expr),2)) *
(COUNT(dep_var_expr) *
SUM(POWER(dep_var_expr, 2)) *
POWER(SUM(dep_var_expr), 2)))
REGR_SLOPE COVAR_SAMP(ind_var_expr,

dep_var_expr)

/ VARIANCE(ind_var_expr)

REGR_SXX SUM(POWER(ind_var_expr, 2)) - COUNT(ind_var_expr) * POWER(AVG(ind_var_expr),2)
REGR_SXY SUM(ind_var_expr*dep_var_expr) - COUNT(ind_var_expr) * AVG(ind) * AVG(dep_var_expr)
REGR_SYY SUM(POWER(dep_var_expr, 2)) - COUNT(dep_var_expr) * POWER(AVG(dep_var_expr),2)
ROLLUP ROLLUP
STDDEV_POP STDDEV_POP
STDDEV_SAMP STDDEV_SAMP, STDDEV
SUM SUM
VAR_POP VAR_POP
VAR_SAMP VAR_SAMP, VARIANCE
WM_CONCAT STRING_AGG

BigQuery bietet die folgenden zusätzlichen Aggregatfunktionen:

Analysefunktionen

Die folgende Tabelle zeigt Zuordnungen zwischen gängigen Oracle-Analysefunktionen und aggregierten Analysefunktionen mit ihren BigQuery-Entsprechungen.

Oracle BigQuery
AVG AVG
BIT_COMPLEMENT Bitweiser Not-Operator: ~
BIT_OR BIT_OR, X | Y
BIT_XOR BIT_XOR, X ^ Y
BITAND BIT_AND, X & Y
BOOL_TO_INT CAST(X AS INT64)
COUNT COUNT
COVAR_POP COVAR_POP
COVAR_SAMP COVAR_SAMP
CUBE_TABLE Wird in BigQuery nicht unterstützt. Stattdessen ein BI-Tool oder eine benutzerdefinierte UDF verwenden
CUME_DIST CUME_DIST
DENSE_RANK(ANSI) DENSE_RANK
FEATURE_COMPARE Gibt es implizit nicht in BigQuery. Stattdessen UDFs und BigQuery ML verwenden
FEATURE_DETAILS Gibt es implizit nicht in BigQuery. Stattdessen UDFs und BigQuery ML verwenden
FEATURE_ID Gibt es implizit nicht in BigQuery. Stattdessen UDFs und BigQuery ML verwenden
FEATURE_SET Gibt es implizit nicht in BigQuery. Stattdessen UDFs und BigQuery ML verwenden
FEATURE_VALUE Gibt es implizit nicht in BigQuery. Stattdessen UDFs und BigQuery ML verwenden
FIRST_VALUE FIRST_VALUE
HIER_CAPTION Hierarchische Abfragen werden in BigQuery nicht unterstützt.
HIER_CHILD_COUNT Hierarchische Abfragen werden in BigQuery nicht unterstützt.
HIER_COLUMN Hierarchische Abfragen werden in BigQuery nicht unterstützt.
HIER_DEPTH Hierarchische Abfragen werden in BigQuery nicht unterstützt.
HIER_DESCRIPTION Hierarchische Abfragen werden in BigQuery nicht unterstützt.
HIER_HAS_CHILDREN Hierarchische Abfragen werden in BigQuery nicht unterstützt.
HIER_LEVEL Hierarchische Abfragen werden in BigQuery nicht unterstützt.
HIER_MEMBER_NAME Hierarchische Abfragen werden in BigQuery nicht unterstützt.
HIER_ORDER Hierarchische Abfragen werden in BigQuery nicht unterstützt.
HIER_UNIQUE_MEMBER_NAME Hierarchische Abfragen werden in BigQuery nicht unterstützt.
LAST_VALUE LAST_VALUE
LAG LAG
LEAD LEAD
LISTAGG ARRAY_AGG
STRING_AGG
ARRAY_CONCAT_AGG
MATCH_NUMBER Die Mustererkennung und -berechnung kann mit regulären Ausdrücken und UDFs in BigQuery erfolgen.
MATCH_RECOGNIZE Die Mustererkennung und -berechnung kann mit regulären Ausdrücken und UDFs in BigQuery erfolgen.
MAX MAX
MEDIAN PERCENTILE_CONT(x, 0.5 RESPECT NULLS) OVER()
MIN MIN
NTH_VALUE NTH_VALUE (value_expression, constant_integer_expression [{RESPECT | IGNORE} NULLS])
NTILE NTILE(constant_integer_expression)
PERCENT_RANK
PERCENT_RANKM 		PERCENT_RANK
PERCENTILE_CONT
PERCENTILE_DISC 		PERCENTILE_CONT
PERCENTILE_CONT
PERCENTILE_DISC 		PERCENTILE_DISC
PRESENTNNV Oracle-spezifisch, ist in BigQuery nicht vorhanden.
PRESENTV Oracle-spezifisch, ist in BigQuery nicht vorhanden.
PREVIOUS Oracle-spezifisch, ist in BigQuery nicht vorhanden.
RANK (ANSI) RANK
RATIO_TO_REPORT(expr) OVER (partition clause) expr / SUM(expr) OVER (partition clause)
ROW_NUMBER ROW_NUMBER
STDDEV_POP STDDEV_POP
STDDEV_SAMP STDDEV_SAMP, STDDEV
SUM SUM
VAR_POP VAR_POP
VAR_SAMP VAR_SAMP, VARIANCE
VARIANCE VARIANCE()
WIDTH_BUCKET UDF kann verwendet werden.

Datums-/Zeitfunktionen

Die folgende Tabelle zeigt Zuordnungen zwischen gängigen Datums-/Uhrzeitfunktionen von Oracle und ihren BigQuery-Entsprechungen.

Oracle BigQuery
ADD_MONTHS(date, integer) DATE_ADD(date, INTERVAL integer MONTH),
Wenn das Datum ein TIMESTAMP ist, den Sie verwenden können.

EXTRACT(DATE FROM TIMESTAMP_ADD(date, INTERVAL integer MONTH))

CURRENT_DATE CURRENT_DATE
CURRENT_TIME CURRENT_TIME
CURRENT_TIMESTAMP CURRENT_TIMESTAMP
DATE - k DATE_SUB(date_expression, INTERVAL k DAY)
DATE + k DATE_ADD(date_expression, INTERVAL k DAY)
DBTIMEZONE BigQuery unterstützt die Datenbankzeitzone nicht.
EXTRACT EXTRACT(DATE), EXTRACT(TIMESTAMP)
LAST_DAY DATE_SUB(
  DATE_TRUNC(
    DATE_ADD(
      date_expression,
      INTERVAL 1 MONTH
    ),
  MONTH
  ),
INTERVAL 1 DAY
)
LOCALTIMESTAMP Zeitzoneneinstellungen werden von BigQuery nicht unterstützt.
MONTHS_BETWEEN DATE_DIFF(date_expression, date_expression, MONTH)
NEW_TIME DATE(timestamp_expression, time zone)
TIME(timestamp, time zone)
DATETIME(timestamp_expression, time zone)
NEXT_DAY DATE_ADD(
  DATE_TRUNC(
    date_expression,
    WEEK(day_value)
  ),
  INTERVAL 1 WEEK
)
SYS_AT_TIME_ZONE CURRENT_DATE([time_zone])
SYSDATE CURRENT_DATE()
SYSTIMESTAMP CURRENT_TIMESTAMP()
TO_DATE PARSE_DATE
TO_TIMESTAMP PARSE_TIMESTAMP
TO_TIMESTAMP_TZ PARSE_TIMESTAMP
TZ_OFFSET Wird in BigQuery nicht unterstützt. Verwenden Sie stattdessen eine benutzerdefinierte UDF.
WM_CONTAINS
WM_EQUALS
WM_GREATERTHAN
WM_INTERSECTION
WM_LDIFF
WM_LESSTHAN
WM_MEETS
WM_OVERLAPS
WM_RDIFF
 Punkte werden in BigQuery nicht verwendet. Mit UDFs können zwei Zeiträume verglichen werden.

BigQuery bietet die folgenden zusätzlichen Datums-/Zeitfunktionen:

Stringfunktionen

Die folgende Tabelle zeigt Zuordnungen zwischen Oracle-Stringfunktionen und ihren BigQuery-Entsprechungen:

Oracle BigQuery
ASCII TO_CODE_POINTS(string_expr)[OFFSET(0)]
ASCIISTR BigQuery unterstützt UTF-16 nicht
RAWTOHEX TO_HEX
LENGTH CHAR_LENGTH
LENGTH CHARACTER_LENGTH
CHR CODE_POINTS_TO_STRING(
[mod(numeric_expr, 256)]
)
COLLATION Ist in BigQuery nicht vorhanden. COLLATE in DML wird von BigQuery nicht unterstützt.
COMPOSE Benutzerdefinierte Funktion
CONCAT, (|| operator) CONCAT
DECOMPOSE Benutzerdefinierte Funktion
ESCAPE_REFERENCE (UTL_I18N) Wird in BigQuery nicht unterstützt. Verwenden Sie stattdessen eine benutzerdefinierte Funktion.
INITCAP INITCAP
INSTR/INSTR2/INSTR4/INSTRB/INSTRC Benutzerdefinierte Funktion
LENGTH/LENGTH2/LENGTH4/LENGTHB/LENGTHC LENGTH
LOWER LOWER
LPAD LPAD
LTRIM LTRIM
NLS_INITCAP Benutzerdefinierte Funktion
NLS_LOWER LOWER
NLS_UPPER UPPER
NLSSORT Oracle-spezifisch, ist in BigQuery nicht vorhanden.
POSITION STRPOS(string, substring)
PRINTBLOBTOCLOB Oracle-spezifisch, ist in BigQuery nicht vorhanden.
REGEXP_COUNT ARRAY_LENGTH(REGEXP_EXTRACT_ALL(value, regex))
REGEXP_INSTR STRPOS(source_string, REGEXP_EXTRACT(source_string, regexp_string))

Hinweis: Gibt das erste Vorkommen zurück.

REGEXP_REPLACE REGEXP_REPLACE
REGEXP_LIKE IF(REGEXP_CONTAINS,1,0)
REGEXP_SUBSTR REGEXP_EXTRACT, REGEXP_EXTRACT_ALL
REPLACE REPLACE
REVERSE REVERSE
RIGHT SUBSTR(source_string, -1, length)
RPAD RPAD
RTRIM RTRIM
SOUNDEX Wird in BigQuery nicht unterstützt. Stattdessen benutzerdefinierte UDF verwenden
STRTOK SPLIT(instring, delimiter)[ORDINAL(tokennum)]

Note: The entire delimiter string argument is used as a single delimiter. The default delimiter is a comma.

SUBSTR/SUBSTRB/SUBSTRC/SUBSTR2/SUBSTR4 SUBSTR
TRANSLATE REPLACE
TRANSLATE USING REPLACE
TRIM TRIM
UNISTR CODE_POINTS_TO_STRING
UPPER UPPER
|| (VERTICAL BARS) CONCAT

BigQuery bietet die folgenden zusätzlichen Stringfunktionen:

Mathematische Funktionen:

Die folgende Tabelle zeigt Zuordnungen zwischen den mathematischen Oracle-Funktionen und ihren BigQuery-Entsprechungen.

Oracle BigQuery
ABS ABS
ACOS ACOS
ACOSH ACOSH
ASIN ASIN
ASINH ASINH
ATAN ATAN
ATAN2 ATAN2
ATANH ATANH
CEIL CEIL
CEILING CEILING
COS COS
COSH COSH
EXP EXP
FLOOR FLOOR
GREATEST GREATEST
LEAST LEAST
LN LN
LNNVL mit ISNULL verwenden
LOG LOG
MOD (% operator) MOD
POWER (** operator) POWER, POW
DBMS_RANDOM.VALUE RAND
RANDOMBYTES Wird in BigQuery nicht unterstützt. Stattdessen benutzerdefinierte UDF und RAND-Funktion verwenden
RANDOMINTEGER CAST(FLOOR(10*RAND()) AS INT64)
RANDOMNUMBER Wird in BigQuery nicht unterstützt. Stattdessen benutzerdefinierte UDF und RAND-Funktion verwenden
REMAINDER MOD
ROUND ROUND
ROUND_TIES_TO_EVEN ROUND()
SIGN SIGN
SIN SIN
SINH SINH
SQRT SQRT
STANDARD_HASH FARM_FINGERPRINT, MD5, SHA1, SHA256, SHA512
STDDEV STDDEV
TAN TAN
TANH TANH
TRUNC TRUNC
NVL IFNULL(expr, 0), COALESCE(exp, 0)

BigQuery bietet die folgenden zusätzlichen mathematischen Funktionen:

Typkonvertierungsfunktionen

Die folgende Tabelle zeigt Zuordnungen zwischen den Konvertierungsfunktionen des Oracle-Typs und ihren BigQuery-Entsprechungen.

Oracle BigQuery
BIN_TO_NUM SAFE_CONVERT_BYTES_TO_STRING(value)

CAST(x AS INT64)

BINARY2VARCHAR SAFE_CONVERT_BYTES_TO_STRING(value)
CAST
CAST_FROM_BINARY_DOUBLE
CAST_FROM_BINARY_FLOAT
CAST_FROM_BINARY_INTEGER
CAST_FROM_NUMBER
CAST_TO_BINARY_DOUBLE
CAST_TO_BINARY_FLOAT
CAST_TO_BINARY_INTEGER
CAST_TO_NUMBER
CAST_TO_NVARCHAR2
CAST_TO_RAW
>CAST_TO_VARCHAR 		CAST(expr AS typename)
CHARTOROWID Oracle-spezifisch nicht erforderlich.
CONVERT BigQuery unterstützt keine Zeichensätze. Verwenden Sie stattdessen eine benutzerdefinierte Funktion.
EMPTY_BLOB BLOB wird in BigQuery nicht verwendet.
EMPTY_CLOB CLOB wird in BigQuery nicht verwendet.
FROM_TZ Typen mit Zeitzonen werden in BigQuery nicht unterstützt. Stattdessen benutzerdefinierte Funktion und FORMAT_TIMESTAMP verwenden
INT_TO_BOOL CAST
IS_BIT_SET Gibt es implizit nicht in BigQuery. Stattdessen UDFs verwenden
NCHR UDF kann verwendet werden, um ein Äquivalent des Binärprogramms abzurufen.
NUMTODSINTERVAL Der Datentyp INTERVAL wird in BigQuery nicht unterstützt.
NUMTOHEX Wird in BigQuery nicht unterstützt. Stattdessen benutzerdefinierte UDF und eine TO_HEX-Funktion verwenden
NUMTOHEX2
NUMTOYMINTERVAL Der Datentyp INTERVAL wird in BigQuery nicht unterstützt.
RAW_TO_CHAR Oracle-spezifisch, ist in BigQuery nicht vorhanden.
RAW_TO_NCHAR Oracle-spezifisch, ist in BigQuery nicht vorhanden.
RAW_TO_VARCHAR2 Oracle-spezifisch, ist in BigQuery nicht vorhanden.
RAWTOHEX Oracle-spezifisch, ist in BigQuery nicht vorhanden.
RAWTONHEX Oracle-spezifisch, ist in BigQuery nicht vorhanden.
RAWTONUM Oracle-spezifisch, ist in BigQuery nicht vorhanden.
RAWTONUM2 Oracle-spezifisch, ist in BigQuery nicht vorhanden.
RAWTOREF Oracle-spezifisch, ist in BigQuery nicht vorhanden.
REFTOHEX Oracle-spezifisch, ist in BigQuery nicht vorhanden.
REFTORAW Oracle-spezifisch, ist in BigQuery nicht vorhanden.
ROWIDTOCHAR ROWID ist ein Oracle-spezifischer Typ und ist in BigQuery nicht vorhanden. Dieser Wert sollte als String dargestellt werden.
ROWIDTONCHAR ROWID ist ein Oracle-spezifischer Typ und ist in BigQuery nicht vorhanden. Dieser Wert sollte als String dargestellt werden.
SCN_TO_TIMESTAMP SCN ist ein Oracle-spezifischer Typ und ist in BigQuery nicht vorhanden. Dieser Wert sollte als Zeitstempel dargestellt werden.
TO_ACLID
TO_ANYLOB
TO_APPROX_COUNT_DISTINCT
TO_APPROX_PERCENTILE
TO_BINARY_DOUBLE
TO_BINARY_FLOAT
TO_BLOB
TO_CHAR
TO_CLOB
TO_DATE
TO_DSINTERVAL
TO_LOB
TO_MULTI_BYTE
TO_NCHAR
TO_NCLOB
TO_NUMBER
TO_RAW
TO_SINGLE_BYTE
TO_TIME
TO_TIMESTAMP
TO_TIMESTAMP_TZ
TO_TIME_TZ
TO_UTC_TIMEZONE_TZ
TO_YMINTERVAL
 CAST(expr AS typename)
PARSE_DATE
PARSE_TIMESTAMP
Die Umwandlungssyntax wird in einer Abfrage verwendet, um anzuzeigen, dass der Ergebnistyp eines Ausdrucks in einen anderen Typ umgewandelt werden soll.
TREAT Oracle-spezifisch, ist in BigQuery nicht vorhanden.
VALIDATE_CONVERSION Wird in BigQuery nicht unterstützt. Stattdessen benutzerdefinierte UDF verwenden
VSIZE Wird in BigQuery nicht unterstützt. Stattdessen benutzerdefinierte UDF verwenden

JSON-Funktionen

Die folgende Tabelle zeigt Zuordnungen zwischen Oracle-JSON-Funktionen und ihren BigQuery-Entsprechungen.

Oracle BigQuery
AS_JSON TO_JSON_STRING(value[, pretty_print])
JSON_ARRAY Stattdessen UDFs und die Funktion TO_JSON_STRING verwenden
JSON_ARRAYAGG Stattdessen UDFs und die Funktion TO_JSON_STRING verwenden
JSON_DATAGUIDE Benutzerdefinierte Funktion
JSON_EQUAL Benutzerdefinierte Funktion
JSON_EXIST Stattdessen UDFs und JSON_EXTRACT oder JSON_EXTRACT_SCALAR verwenden
JSON_MERGEPATCH Benutzerdefinierte Funktion
JSON_OBJECT Wird von BigQuery nicht unterstützt.
JSON_OBJECTAGG Wird von BigQuery nicht unterstützt.
JSON_QUERY Verwenden Sie stattdessen UDFs und JSON_EXTRACT oder JSON_EXTRACT_SCALAR.
JSON_TABLE Benutzerdefinierte Funktion
JSON_TEXTCONTAINS Verwenden Sie stattdessen UDFs und JSON_EXTRACT oder JSON_EXTRACT_SCALAR.
JSON_VALUE JSON_EXTRACT_SCALAR

XML-Funktionen

BigQuery stellt keine impliziten XML-Funktionen bereit. XML kann in BigQuery als String geladen werden und UDFs können zum Parsen von XML verwendet werden. Alternativ kann die XML-Verarbeitung von einem ETL-/ELT-Tool wie Dataflow durchgeführt werden. In der folgenden Liste sind die Oracle-XML-Funktionen aufgeführt:

Oracle BigQuery
DELETEXML Zur Verarbeitung von XML können BigQuery-User-Tags oder ETL-Tools wie Dataflow verwendet werden.
ENCODE_SQL_XML
EXISTSNODE
EXTRACTCLOBXML
EXTRACTVALUE
INSERTCHILDXML
INSERTCHILDXMLAFTER
INSERTCHILDXMLBEFORE
INSERTXMLAFTER
INSERTXMLBEFORE
SYS_XMLAGG
SYS_XMLANALYZE
SYS_XMLCONTAINS
SYS_XMLCONV
SYS_XMLEXNSURI
SYS_XMLGEN
SYS_XMLI_LOC_ISNODE
SYS_XMLI_LOC_ISTEXT
SYS_XMLINSTR
SYS_XMLLOCATOR_GETSVAL
SYS_XMLNODEID
SYS_XMLNODEID_GETLOCATOR
SYS_XMLNODEID_GETOKEY
SYS_XMLNODEID_GETPATHID
SYS_XMLNODEID_GETPTRID
SYS_XMLNODEID_GETRID
SYS_XMLNODEID_GETSVAL
SYS_XMLT_2_SC
SYS_XMLTRANSLATE
SYS_XMLTYPE2SQL
UPDATEXML
XML2OBJECT
XMLCAST
XMLCDATA
XMLCOLLATVAL
XMLCOMMENT
XMLCONCAT
XMLDIFF
XMLELEMENT
XMLEXISTS
XMLEXISTS2
XMLFOREST
XMLISNODE
XMLISVALID
XMLPARSE
XMLPATCH
XMLPI
XMLQUERY
XMLQUERYVAL
XMLSERIALIZE
XMLTABLE
XMLTOJSON
XMLTRANSFORM
XMLTRANSFORMBLOB
XMLTYPE

Funktionen für maschinelles Lernen

Die Funktionen für maschinelles Lernen (ML) in Oracle und BigQuery sind unterschiedlich. Oracle benötigt ein erweitertes Analysepaket und Lizenzen für ML in der Datenbank. Oracle verwendet denDBMS_DATA_MINING ML-Paket. Für die Konvertierung von Oracle-Data-Miner-Jobs muss der Code umgeschrieben werden. Sie können aus umfassenden Google-KI-Produkten wie BigQuery ML und AI APIs wählen, einschließlich Speech-to-Text, Text-to-Speech, Dialogflow, Cloud Translation, NLP, Cloud Vision und Timeseries Insights API, AutoML, AutoML Tables oder AI Platform. Nutzerverwaltete Notebooks von Google können als Entwicklungsumgebung für Data Scientists und Google AI Platform Training zum Ausführen von Trainings und Arbeitslasten im großen Maßstab bewerten. Die folgende Tabelle enthält Oracle ML-Funktionen:

Oracle BigQuery
CLASSIFIER Unter BigQuery ML finden Sie Informationen zu den Optionen für den Klassifikator und die Regression für maschinelles Lernen.
CLUSTER_DETAILS
CLUSTER_DISTANCE
CLUSTER_ID
CLUSTER_PROBABILITY
CLUSTER_SET
PREDICTION
PREDICTION_BOUNDS
PREDICTION_COST
PREDICTION_DETAILS
PREDICTION_PROBABILITY
PREDICTION_SET

Sicherheitsfunktionen

In der folgenden Tabelle sind die Funktionen zur Identifizierung des Nutzers in Oracle und BigQuery aufgeführt:

Oracle BigQuery
UID SESSION_USER
USER/SESSION_USER/CURRENT_USER SESSION_USER()

Set- oder Arrayfunktionen

Die folgende Tabelle zeigt die Set- oder Array-Funktionen in Oracle und ihre Entsprechungen in BigQuery:

Oracle BigQuery
MULTISET ARRAY_AGG
MULTISET EXCEPT ARRAY_AGG([DISTINCT] expression)
MULTISET INTERSECT ARRAY_AGG([DISTINCT])
MULTISET UNION ARRAY_AGG

Fensterfunktionen

Die folgende Tabelle zeigt Fensterfunktionen in Oracle und ihre Entsprechungen in BigQuery.

Oracle BigQuery
LAG LAG (value_expression[, offset [, default_expression]])
LEAD LEAD (value_expression[, offset [, default_expression]])

Hierarchische oder wiederkehrende Abfragen

Hierarchische oder rekursive Abfragen werden in BigQuery nicht verwendet. Wenn die Tiefe der Hierarchie bekannt ist, können ähnliche Funktionen mit Joins erreicht werden, wie im folgenden Beispiel dargestellt. Eine weitere Lösung wäre die Verwendung der BigQueryStorage API und von Spark.

select
  array(
    select e.update.element
    union all
    select c1 from e.update.element.child as c1
    union all
    select c2 from e.update.element.child as c1, c1.child as c2
    union all
    select c3 from e.update.element.child as c1, c1.child as c2, c2.child as c3
    union all
    select c4 from e.update.element.child as c1, c1.child as c2, c2.child as c3, c3.child as c4
    union all
    select c5 from e.update.element.child as c1, c1.child as c2, c2.child as c3, c3.child as c4, c4.child as c5
  ) as flattened,
  e as event
from t, t.events as e

Die folgende Tabelle enthält hierarchische Funktionen in Oracle.

Oracle BigQuery
DEPTH Hierarchische Abfragen werden in BigQuery nicht verwendet.
PATH
SYS_CONNECT_BY_PATH (hierarchical)

UTL-Funktionen

Das Paket UTL_File wird hauptsächlich zum Lesen und Schreiben der Betriebssystemdateien aus PL/SQL verwendet. Cloud Storage kann für jede Art von Staging von Rohdateien verwendet werden. Externe Tabellen sowie BigQuery-Load-Balancing und Export sollten zum Lesen und Schreiben von Dateien in und aus Cloud Storage verwendet werden. Weitere Informationen finden Sie unter Einführung in externe Datenquellen.

Räumliche Funktionen

Durch räumliche Analysen können Sie räumliche Funktionen ersetzen. Es gibt SDO_*-Funktionen und -Typen in Oracle, z. B. SDO_GEOM_KEY, SDO_GEOM_MBR, SDO_GEOM_MMB. Diese Funktionen werden für räumliche Analysen verwendet. Sie können raumbezogene Analysen für räumliche Analysen verwenden.

DML-Syntax

In diesem Abschnitt werden Unterschiede in der Syntax der Datenverwaltungssprache zwischen Oracle und BigQuery behandelt.

INSERT-Anweisung

Die meisten Oracle-INSERT-Anweisungen sind mit BigQuery kompatibel. Die folgende Tabelle enthält Ausnahmen.

DML-Skripts in BigQuery haben eine etwas andere Konsistenzsemantik als die entsprechenden Anweisungen in Oracle. Eine Übersicht über die Snapshot-Isolation sowie die Sitzungs- und Transaktionsbehandlung finden Sie im Abschnitt CREATE [UNIQUE] INDEX section an anderer Stelle in diesem Dokument.

Oracle BigQuery
INSERT INTO table VALUES (...); INSERT INTO table (...) VALUES (...);

Oracle bietet das Keyword DEFAULT für Spalten, die keine Nullwerte zulassen.

Hinweis: In BigQuery funktioniert das Weglassen von Spaltennamen in der Anweisung INSERT nur, wenn Werte für alle Spalten in der Zieltabelle auf der Grundlage ihrer ordinalen Positionen in aufsteigender Reihenfolge enthalten sind.

INSERT INTO table VALUES (1,2,3);
INSERT INTO table VALUES (4,5,6);
INSERT INTO table VALUES (7,8,9);
INSERT ALL
INTO table (col1, col2) VALUES ('val1_1', 'val1_2')
INTO table (col1, col2) VALUES ('val2_1', 'val2_2')
INTO table (col1, col2) VALUES ('val3_1', 'val3_2')
.
.
.
SELECT 1 FROM DUAL; 		INSERT INTO table VALUES (1,2,3), (4,5,6),
(7,8,9);

BigQuery legt DML-Kontingente fest, die die Anzahl der DML-Anweisungen begrenzen, die Sie täglich ausführen können. Ziehen Sie die folgenden Ansätze in Betracht, um Ihr Kontingent optimal zu nutzen:

  • Kombinieren Sie mehrere Zeilen in einer einzigen INSERT-Anweisung anstelle einer Zeile pro INSERT-Vorgang.
  • Kombinieren Sie mehrere DML-Anweisungen (einschließlich INSERT) mit einer MERGE-Anweisung.
  • Mit CREATE TABLE ... AS SELECT können Sie neue Tabellen erstellen und mit Daten füllen.

UPDATE-Anweisung

Oracle-UPDATE-Anweisungen sind hauptsächlich mit BigQuery kompatibel. In BigQuery muss die UPDATE-Anweisung jedoch eine WHERE-Klausel enthalten.

Als Best Practice empfehlen wir, Batch-DML-Anweisungen gegenüber mehreren einzelnen UPDATE- und INSERT-Anweisungen zu bevorzugen. DML-Skripts in BigQuery haben eine etwas andere Konsistenzsemantik als entsprechende Anweisungen in Oracle. Eine Übersicht über die Snapshot-Isolation sowie die Sitzungs- und Transaktionsbehandlung finden Sie im Abschnitt CREATE INDEX an anderer Stelle in diesem Dokument.

Die folgende Tabelle zeigt Teradata-UPDATE-Anweisungen und BigQuery-Anweisungen, die dieselben Aufgaben ausführen.

In BigQuery muss die UPDATE-Anweisung eine WHERE-Klausel enthalten. Weitere Informationen zu UPDATE in BigQuery finden Sie in den BigQuery UPDATE-Beispielen in der DML-Dokumentation.

DELETE- und TRUNCATE-Anweisungen

Die Anweisungen DELETE und TRUNCATE sind beide Möglichkeiten zum Entfernen von Zeilen aus einer Tabelle, ohne dass sich dies auf das Tabellenschema auswirkt. TRUNCATE wird in BigQuery nicht verwendet. Sie können jedoch DELETE-Anweisungen verwenden, um den gleichen Effekt zu erzielen.

In BigQuery muss die DELETE-Anweisung eine WHERE-Klausel enthalten. Weitere Informationen zu DELETE in BigQuery finden Sie in den BigQuery-DELETE-Beispielen in der DML-Dokumentation.

Oracle BigQuery
DELETE database.table; DELETE FROM table WHERE TRUE;

MERGE-Anweisung

Die MERGE-Anweisung kann die Vorgänge INSERT, UPDATE und DELETE in einer einzigen UPSERT-Anweisung kombinieren und die Vorgänge atomar ausführen. Der MERGE-Vorgang muss mit maximal einer Quellzeile für jede Zielzeile übereinstimmen. BigQuery und Oracle folgen beide der ANSI-Syntax.

DML-Skripts in BigQuery haben jedoch eine etwas andere Konsistenzsemantik als die entsprechenden Anweisungen in Oracle.

DDL-Syntax

In diesem Abschnitt werden Unterschiede in der Syntax der Datendefinitionssprache zwischen Oracle und BigQuery behandelt.

CREATE TABLE-Anweisung

Die meisten Oracle-CREATE TABLE-Anweisungen sind mit BigQuery kompatibel, mit Ausnahme der folgenden Einschränkungen und Syntaxelemente, die in BigQuery nicht verwendet werden:

  • STORAGE
  • TABLESPACE
  • DEFAULT
  • GENERATED ALWAYS AS
  • ENCRYPT
  • PRIMARY KEY (col, ...). Weitere Informationen erhalten Sie hier: CREATE INDEX.
  • UNIQUE INDEX. Weitere Informationen erhalten Sie hier: CREATE INDEX.
  • CONSTRAINT..REFERENCES
  • DEFAULT
  • PARALLEL
  • COMPRESS

Weitere Informationen zu CREATE TABLE in BigQuery finden Sie unter BigQuery CREATE TABLE-Beispiele.

Optionen und Attribute für Spalten

Identitätsspalten werden mit der Oracle 12c-Version eingeführt, die die automatische Erhöhung einer Spalte ermöglicht. Dies wird in BigQuery nicht verwendet. Dies kann mit der folgenden Batchmethode erreicht werden. Weitere Informationen zu Ersatzschlüsseln und zu einer langsam ändernden Dimension (SCD) finden Sie in den folgenden Anleitungen:

Oracle BigQuery
CREATE TABLE table (
  id NUMBER GENERATED ALWAYS AS IDENTITY,
  description VARCHAR2(30)
); 		INSERT INTO dataset.table SELECT
  *,
  ROW_NUMBER() OVER () AS id
FROM dataset.table

Spaltenkommentare

Oracle verwendet die Comment-Syntax, um Kommentare zu Spalten hinzuzufügen. Diese Funktion kann in BigQuery auf ähnliche Weise mithilfe der Spaltenbeschreibung implementiert werden, wie in der folgenden Tabelle dargestellt:

Oracle BigQuery
Comment on column table is 'column desc'; CREATE TABLE dataset.table (
   col1 STRING
OPTIONS(description="column desc")
);

Temporäre Tabellen

Oracle unterstützt temporäre Tabellen, die häufig zum Speichern von Zwischenergebnissen in Skripts verwendet werden. Temporäre Tabellen werden in BigQuery unterstützt.

Oracle BigQuery
CREATE GLOBAL TEMPORARY TABLE
temp_tab
    (x INTEGER,
    y VARCHAR2(50))
  ON COMMIT DELETE ROWS;
COMMIT; 		CREATE TEMP TABLE temp_tab
(
  x INT64,
  y STRING
);
DELETE FROM temp_tab WHERE TRUE;

Die folgenden Oracle-Elemente werden in BigQuery nicht verwendet:

  • ON COMMIT DELETE ROWS;
  • ON COMMIT PRESERVE ROWS;

Es gibt auch andere Möglichkeiten, temporäre Tabellen in BigQuery zu emulieren:

  • Dataset-TTL: Erstellen Sie ein Dataset mit einer kurzen Lebensdauer (z. B. eine Stunde), damit alle im Dataset erstellten Tabellen praktisch temporär sind, da sie nicht länger als für die Lebensdauer des Datasets beibehalten werden. Sie können allen Tabellennamen in diesem Dataset temp voranstellen, um deutlich zu machen, dass die Tabellen temporär sind.

  • Tabellen-TTL: Erstellen Sie eine Tabelle mit einer tabellenspezifischen kurzen Lebensdauer mithilfe von DDL-Anweisungen wie der folgenden:

    CREATE TABLE temp.name (col1, col2, ...)
    
OPTIONS(expiration_timestamp=TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR));

  • WITH-Klausel: Wenn eine temporäre Tabelle nur im selben Block benötigt wird, verwenden Sie ein temporäres Ergebnis mithilfe einer WITH-Anweisung oder -Unterabfrage.

CREATE SEQUENCE-Anweisung

Sequenzen werden in BigQuery nicht verwendet und können mit der folgenden Batchmethode erreicht werden. Weitere Informationen zu Ersatzschlüsseln und zu einer langsam ändernden Dimension (SCD) finden Sie in den folgenden Anleitungen:

INSERT INTO dataset.table
    SELECT *,
      ROW_NUMBER() OVER () AS id
      FROM dataset.table

CREATE VIEW-Anweisung

Die folgende Tabelle zeigt Entsprechungen zwischen Teradata und BigQuery für die Anweisung CREATE VIEW.

Oracle BigQuery Hinweise
CREATE VIEW view_name AS SELECT ... CREATE VIEW view_name AS SELECT ...
CREATE OR REPLACE VIEW view_name AS SELECT ... CREATE OR REPLACE VIEW view_name AS SELECT ...
Nicht unterstützt CREATE VIEW IF NOT EXISTS view_name OPTIONS(view_option_list) AS SELECT ... Erstellt nur dann eine neue Ansicht, wenn die Ansicht derzeit im angegebenen Dataset nicht vorhanden ist.

CREATE MATERIALIZED VIEW-Anweisung

In BigQuery werden Aktualisierungsvorgänge in der materialisierten Ansicht automatisch ausgeführt. Sie müssen in BigQuery keine Aktualisierungsoptionen angeben (z. B. für Commit oder Zeitplan). Weitere Informationen finden Sie unter Einführung in materialisierte Ansichten.

Wenn sich die Basistabelle immer wieder nur durch Anfügungen ändert, scannt die Abfrage, die eine materialisierte Ansicht verwendet (unabhängig davon, ob die Ansicht explizit referenziert oder vom Abfrageoptimierungstool ausgewählt wird), alle materialisierten Ansichten seit der letzten Aktualisierung der Ansicht sowie ein Delta in der Basistabelle. Das bedeutet, dass Abfragen schneller und günstiger sind.

Sind dagegen Aktualisierungen (DML UPDATE / MERGE) oder Löschungen (DML DELETE, Kürzung, Partitionsablauf) in der Basistabelle seit der letzten Aktualisierung der Ansicht aufgetreten, werden die materialisierte Ansicht nicht gescannt. Daher erhält die Abfrage bis zur nächsten Aktualisierung der Ansicht keine Einsparungen. Grundsätzlich wird bei jeder Aktualisierung oder Löschung in der Basistabelle der Status der materialisierten Ansicht ungültig.

Außerdem werden die Daten aus dem Streamingpuffer der Basistabelle nicht in der materialisierten Ansicht gespeichert. Der Streamingzwischenspeicher wird immer noch vollständig gescannt, unabhängig davon, ob die materialisierte Ansicht verwendet wird.

Die folgende Tabelle zeigt Entsprechungen zwischen Teradata und BigQuery für die Anweisung CREATE MATERIALIZED VIEW.

Oracle BigQuery Hinweise
CREATE MATERIALIZED VIEW view_name
REFRESH FAST NEXT sysdate + 7
AS SELECT … FROM TABLE_1 		CREATE MATERIALIZED VIEW
view_name AS SELECT ...

CREATE [UNIQUE] INDEX-Anweisung

In diesem Abschnitt werden Ansätze in BigQuery zum Erstellen von Funktionen beschrieben, die Indexen in Oracle ähneln.

Indexierung aus Gründen der Leistung

BigQuery benötigt keine expliziten Indexe, da es sich um eine spaltenorientierte Datenbank mit Abfrage- und Speicheroptimierung handelt. BigQuery bietet Funktionen wie Partitionierung und Clustering sowie verschachtelte Felder, die durch Optimierung der Datenspeicherung die Effizienz und Leistung von Abfragen erhöhen können.

Indexierung aus Konsistenzgründen (UNIQUE, PRIMARY INDEX)

In Oracle, kann ein eindeutiger Index verwendet werden, um Zeilen mit nicht eindeutigen Schlüsseln in einer Tabelle zu verhindern. Wenn ein Prozess versucht, Daten mit einem Wert einzufügen oder zu aktualisieren, der bereits im Index enthalten ist, schlägt der Vorgang mit einem Indexverstoß fehl.

Da BigQuery keine expliziten Indexe bereitstellt, kann stattdessen eine MERGE-Anweisung verwendet werden, um nur eindeutige Einträge aus einer Staging-Tabelle in eine Zieltabelle einzufügen, während doppelte Einträge verworfen werden. Es gibt jedoch keine Möglichkeit, zu verhindern, dass ein Nutzer mit Bearbeitungsberechtigungen einen doppelten Eintrag einfügt.

Zum Generieren eines Fehlers für doppelte Einträge in BigQuery können Sie eine MERGE-Anweisung aus einer Staging-Tabelle verwenden, wie im folgenden Beispiel gezeigt:

Oracle BigQuery
CREATE [UNIQUE] INDEX name; MERGE `prototype.FIN_MERGE` t \
USING `prototype.FIN_TEMP_IMPORT` m \
ON t.col1 = m.col1 \
  AND t.col2 = m.col2 \
WHEN MATCHED THEN \
  UPDATE SET t.col1 = ERROR(CONCAT('Encountered Error for ', m.col1, ' ', m.col2)) \
WHEN NOT MATCHED THEN \
  INSERT (col1,col2,col3,col4,col5,col6,col7,col8)
VALUES(col1,col2,col3,col4,col5,col6, CURRENT_TIMESTAMP(),CURRENT_TIMESTAMP());

Häufiger ziehen es Nutzer vor, Duplikate unabhängig zu entfernen, um Fehler in nachgelagerten Systemen zu finden.

BigQuery unterstützt die Spalten DEFAULT und IDENTITY (Sequenzen) nicht.

Sperren

BigQuery hat keinen Sperrmechanismus wie Oracle und kann gleichzeitige Abfragen (bis zu Ihrem Kontingent) ausführen. Nur DML-Anweisungen haben bestimmte Gleichzeitigkeitslimits und erfordern in einigen Szenarien eine Tabellensperre während der Ausführung.

Prozedurale SQL-Anweisungen

In diesem Abschnitt wird beschrieben, wie Sie prozedurale SQL-Anweisungen, die in gespeicherten Verfahren, Funktionen und Triggern verwendet werden, von Oracle in BigQuery konvertieren.

CREATE PROCEDURE-Anweisung

Gespeicherte Prozeduren werden im Rahmen der BigQuery-Skripterstellung (Beta) unterstützt.

Oracle BigQuery Hinweise
CREATE PROCEDURE CREATE PROCEDURE Ähnlich wie Oracle unterstützt BigQuery die Argumentmodi IN, OUT, INOUT. Andere Syntaxspezifikationen werden in BigQuery nicht unterstützt.
CREATE OR REPLACE PROCEDURE CREATE OR REPLACE PROCEDURE
CALL CALL

In den folgenden Abschnitten wird beschrieben, wie vorhandene prozedurale Oracle-Anweisungen in BigQuery-Skript-Anweisungen mit ähnlicher Funktionalität konvertiert werden.

CREATE TRIGGER-Anweisung

Trigger werden in BigQuery nicht verwendet. Die zeilenbasierte Anwendungslogik sollte auf der Anwendungsebene verarbeitet werden. Die Triggerfunktion kann über die Nutzung des Aufnahmetools, Pub/Sub und/oder Cloud Run Functions während der Aufnahmezeit oder durch Nutzung regulärer Scans erreicht werden.

Variablendeklaration und -zuweisung

Die folgende Tabelle zeigt DECLARE-Anweisungen von Oracle und ihre Entsprechungen in BigQuery.

Oracle BigQuery
DECLARE
  L_VAR NUMBER;
BEGIN
  L_VAR := 10 + 20;
END; 		DECLARE L_VAR int64;
BEGIN
  SET L_VAR = 10 + 20;
  SELECT L_VAR;
END
SET var = value; SET var = value;

Cursor-Deklarationen und -Vorgänge

Da BigQuery keine Cursor unterstützt, werden die folgenden Anweisungen in BigQuery nicht verwendet:

Dynamische SQL-Anweisungen

Die folgende Oracle Dynamic SQL-Anweisung und ihre BigQuery-Entsprechungen:

Oracle BigQuery
EXECUTE IMMEDIATE sql_str

[USING IN OUT [, ...]];

EXECUTE IMMEDIATE

sql_expression [INTO variable[, ...]]

[USING identifier[, ...]];

;

Anweisungen zum Kontrollfluss

Die folgende Tabelle zeigt Oracle-Flow-of-Control-Anweisungen und ihre BigQuery-Entsprechungen.

Oracle BigQuery
IF condition THEN
  [if_statement_list]
[ELSE
  else_statement_list
]
END IF; 		IF condition THEN
  [if_statement_list]
[ELSE
  else_statement_list
]
END IF;
SET SERVEROUTPUT ON;
DECLARE
x INTEGER DEFAULT 0;
y INTEGER DEFAULT 0;
BEGIN
LOOP
  IF x>= 10 THEN
    EXIT;
  ELSIF x>= 5 THEN
     y := 5;
  END IF;
  x := x + 1;
END LOOP;
dbms_output.put_line(x||','||y);
END;
/ 		DECLARE x INT64 DEFAULT 0;
DECLARE y INT64 DEFAULT 0;
LOOP
  IF x>= 10 THEN
     LEAVE;
  ELSE IF x>= 5 THEN
    SET y = 5;
    END IF;
  END IF;
  SET x = x + 1;
END LOOP;
SELECT x,y;
LOOP
  sql_statement_list
END LOOP; 		LOOP
  sql_statement_list
END LOOP;
WHILE boolean_expression DO
  sql_statement_list
END WHILE; 		WHILE boolean_expression DO
  sql_statement_list
END WHILE;
FOR LOOP FOR LOOP wird in BigQuery nicht verwendet. Verwenden Sie andere LOOP-Anweisungen.
BREAK BREAK
CONTINUE CONTINUE
CONTINUE/EXIT WHEN CONTINUE mit IF-Bedingung verwenden.
GOTO GOTO-Anweisung ist in BigQuery nicht vorhanden. Verwenden Sie die Bedingung IF.

Metadaten- und Transaktions-SQL-Anweisungen

Oracle BigQuery
GATHER_STATS_JOB Wird in BigQuery noch nicht verwendet.
LOCK TABLE table_name IN [SHARE/EXCLUSIVE] MODE NOWAIT; Wird in BigQuery noch nicht verwendet.
Alter session set isolation_level=serializable; /

SET TRANSACTION ...

BigQuery verwendet immer die Snapshot-Isolation. Weitere Informationen finden Sie in diesem Dokument unter Konsistenzgarantien und Transaktionsisolation.
EXPLAIN PLAN ... Wird in BigQuery nicht verwendet.

Ähnliche Funktionen sind die Erläuterung des Abfrageplans in der BigQuery-Web-UI, die Slotzuweisung und im Audit-Logging in Stackdriver.

SELECT * FROM DBA_[*];

(Oracle DBA_/ALL_/V$-Ansichten)

SELECT * FROM mydataset.INFORMATION_SCHEMA.TABLES;

Weitere Informationen finden Sie unter Einführung in BigQuery INFORMATION_SCHEMA.

SELECT * FROM GV$SESSION;

SELECT * FROM V$ACTIVE_SESSION_HISTORY;

BigQuery hat nicht das herkömmliche Sitzungskonzept. Sie können Abfragejobs in der UI aufrufen oder Stackdriver-Audit-Logs nach BigQuery exportieren und BigQuery-Logs zur Analyse von Jobs analysieren. Weitere Informationen finden Sie unter Jobdetails ansehen.
START TRANSACTION;

LOCK TABLE table_A IN EXCLUSIVE MODE NOWAIT;

DELETE FROM table_A;

INSERT INTO table_A SELECT * FROM table_B;

COMMIT;

 Das Ersetzen des Inhalts einer Tabelle durch die Abfrageausgabe entspricht einer Transaktion. Sie können dazu entweder einen Abfragevorgang oder einen Kopiervorgang verwenden.

Abfrage verwenden:

bq query --replace --destination_table table_A 'SELECT * FROM table_B';

Kopie verwenden:

bq cp -f table_A table_B

Mehrfachanweisungen und mehrzeilige SQL-Anweisungen

Sowohl Oracle als auch BigQuery unterstützen Transaktionen (Sitzungen) und unterstützen daher durch Semikolons getrennte Anweisungen, die konsistent zusammen ausgeführt werden. Weitere Informationen finden Sie unter Transaktionen mit mehreren Anweisungen.

Fehlercodes und -meldungen

Oracle-Fehlercodes und BigQuery-Fehlercodes sind unterschiedlich. Wenn Ihre Anwendungslogik derzeit die Fehler erkennt, versuchen Sie, die Fehlerquelle zu beheben, da BigQuery nicht die gleichen Fehlercodes zurückgibt.

Konsistenzgarantien und Transaktionsisolation

Sowohl Oracle als auch BigQuery sind unteilbar, d. h. ACID-konform auf Mutationsebene über viele Zeilen hinweg. Zum Beispiel ist ein MERGE-Vorgang vollständig unteilbar, auch wenn mehrere eingefügte und aktualisierte Werte vorhanden sind.

Transaktionen

Oracle bietet schreibgeschützte oder serialisierbare Transaktionsisolationsebenen. Deadlocks sind möglich. Oracle-Insert-Jobs werden unabhängig ausgeführt.

BigQuery unterstützt auch Transaktionen. BigQuery sorgt mit der Snapshot-Isolation für eine optimistische Gleichzeitigkeitserkennung (der erste Commit erhält Vorrang), bei der eine Abfrage die letzten übergebenen Daten liest, bevor die Abfrage beginnt. Dieser Ansatz garantiert die gleiche Konsistenz auf Zeilen- und Mutationsbasis sowie zeilenübergreifend innerhalb derselben DML-Anweisung, vermeidet dabei jedoch Deadlocks. Bei mehreren UPDATE-Anweisungen für dieselbe Tabelle wechselt BigQuery zu pessimistischer Gleichzeitigkeitserkennung und stellt mehrfache UPDATE-Anweisungen in die Warteschlange. Bei Konflikten werden die Anweisungen automatisch wiederholt. INSERT-DML-Anweisungen und Ladejobs können gleichzeitig und unabhängig ausgeführt werden, um Daten an Tabellen anzuhängen.

Rollback

Oracle unterstützt Rollbacks. Da es in BigQuery keine explizite Transaktionsgrenze gibt, gibt es kein Konzept eines expliziten Rollbacks in BigQuery. Diese Problemumgehungen sind Tabellen-Decorators oder FOR SYSTEM_TIME AS OF.

Datenbanklimits

Sehen Sie sich die aktuellen BigQuery-Kontingente und -Limits an. Viele Kontingente für Nutzer mit hohem Datenvolumen können über die Cloud-Kundenbetreuung erhöht werden. Die folgende Tabelle zeigt einen Vergleich der Oracle- und BigQuery-Datenbanklimits.

Limit Oracle BigQuery
Tabellen pro Datenbank Uneingeschränkt Uneingeschränkt
Spalten pro Tabelle 1000 10.000
Maximale Zeilengröße Unbegrenzt (hängt vom Spaltentyp ab) 100 MB
Länge des Spalten- und Tabellennamens Wenn v12.2>= 128 Byte

Andernfalls 30 Byte

16.384 Unicode-Zeichen
Zeilen pro Tabelle Unbegrenzt Unbegrenzt
Maximale Länge von SQL-Anfragen Unbegrenzt 1 MB (maximale Länge ungelöster Google SQL-Abfragen)

12 MB (maximale Länge gelöster Legacy- und Google SQL-Abfragen)

Streaming:

  • 10 MB (Größenbeschränkung für HTTP-Anfragen)
  • 10.000 (maximale Zeilen pro Anfrage)
Maximale Anfrage- und Antwortgröße Unbegrenzt 10 MB (Anfrage) und 10 GB (Antwort) oder praktisch unbegrenzt, wenn Sie den Seitenumbruch oder die Cloud Storage API verwenden.
Maximale Anzahl gleichzeitiger Sitzungen Eingeschränkt durch die Parameter für Sitzungen oder Prozesse 100 gleichzeitige Abfragen (kann mit einer Slot-Reservierung erhöht werden), 300 gleichzeitige API-Anfragen pro Nutzer
Maximale Anzahl gleichzeitiger (schneller) Ladevorgänge Eingeschränkt durch die Parameter für Sitzungen oder Prozesse Keine Beschränkung der Gleichzeitigkeit; Jobs werden in die Warteschlange gestellt. 100.000 Ladejobs pro Projekt und Tag.

Weitere Oracle-Datenbanklimits umfassen Datentyplimits, physische Datenbanklimits, logische Datenbanklimits sowie Prozess- und Laufzeitlimits.