Guía de traducción de SQL de Oracle

En este documento, se detallan las similitudes y diferencias que existen en la sintaxis de SQL de Oracle y BigQuery para ayudarte a planificar tu migración. Usa la traducción de SQL por lotes para migrar tus secuencias de comandos de SQL de forma masiva o la traducción de SQL interactiva a fin de traducir consultas ad hoc.

Tipos de datos

En esta sección, se muestran los equivalentes entre los tipos de datos en Oracle y en BigQuery.

Oracle BigQuery Notas
VARCHAR2 STRING
NVARCHAR2 STRING
CHAR STRING
NCHAR STRING
CLOB STRING
NCLOB STRING
INTEGER INT64
SHORTINTEGER INT64
LONGINTEGER INT64
NUMBER NUMERIC BigQuery no permite la especificación de usuarios para valores personalizados de precisión o escalamiento. Como resultado, se puede definir una columna en Oracle para que tenga una escala mayor que la compatible con BigQuery.

Además, antes de almacenar un número decimal, Oracle se redondea hacia arriba si ese número tiene más dígitos después del punto decimal que el especificado para la columna correspondiente. En BigQuery, esta función se puede implementar con la función ROUND().

NUMBER(*, x) NUMERIC BigQuery no permite la especificación de usuarios para valores personalizados de precisión o escalamiento. Como resultado, se puede definir una columna en Oracle para que tenga una escala mayor que la compatible con BigQuery.

Además, antes de almacenar un número decimal, Oracle se redondea hacia arriba si ese número tiene más dígitos después del punto decimal que el especificado para la columna correspondiente. En BigQuery, esta función se puede implementar con la función ROUND().

NUMBER(x, -y) INT64 Si un usuario intenta almacenar un número decimal, Oracle lo redondea a un número entero. Para BigQuery, un intento de almacenar un número decimal en una columna definida como INT64 genera un error. En este caso, se debe aplicar la función ROUND().

Los tipos de datos INT64 de BigQuery permiten hasta 18 dígitos de precisión. Si un campo numérico tiene más de 18 dígitos, se debe usar el tipo de datos FLOAT64 en BigQuery.

NUMBER(x) INT64 Si un usuario intenta almacenar un número decimal, Oracle lo redondea a un número entero. Para BigQuery, un intento de almacenar un número decimal en una columna definida como INT64 genera un error. En este caso, se debe aplicar la función ROUND().

Los tipos de datos INT64 de BigQuery permiten hasta 18 dígitos de precisión. Si un campo numérico tiene más de 18 dígitos, se debe usar el tipo de datos FLOAT64 en BigQuery.

FLOAT FLOAT64/NUMERIC FLOAT es un tipo de datos exacto y es un subtipo de NUMBER en Oracle. En BigQuery, FLOAT64 es un tipo de datos aproximado. NUMERIC puede ser una mejor coincidencia para el tipo FLOAT en BigQuery.
BINARY_DOUBLE FLOAT64/NUMERIC FLOAT es un tipo de datos exacto y es un subtipo de NUMBER en Oracle. En BigQuery, FLOAT64 es un tipo de datos aproximado. NUMERIC puede ser una mejor coincidencia para el tipo FLOAT en BigQuery.
BINARY_FLOAT FLOAT64/NUMERIC FLOAT es un tipo de datos exacto y es un subtipo de NUMBER en Oracle. En BigQuery, FLOAT64 es un tipo de datos aproximado. NUMERIC puede ser una mejor coincidencia para el tipo FLOAT en BigQuery.
LONG BYTES El tipo de datos LONG se usa en versiones anteriores y no se sugiere en versiones nuevas de la base de datos de Oracle.

Se puede usar el tipo de datos BYTES en BigQuery si es necesario conservar datos LONG en BigQuery. Un mejor enfoque sería colocar objetos binarios en Cloud Storage y conservar referencias en BigQuery.

BLOB BYTES Se puede usar el tipo de datos BYTES para almacenar datos binarios de longitud variable. Si este campo no se consulta y no se usa en las estadísticas, una mejor opción es almacenar los datos binarios en Cloud Storage.
BFILE STRING Los archivos binarios se pueden almacenar en Cloud Storage y el tipo de datos STRING se puede usar para hacer referencia a archivos en una tabla de BigQuery.
DATE DATETIME
TIMESTAMP TIMESTAMP BigQuery admite la precisión de microsegundos (10-6) en comparación con Oracle, que admite una precisión de 0 a 9.

BigQuery admite un nombre de región de zona horaria a partir de una base de datos TZ y un desplazamiento de zona horaria de UTC.

En BigQuery, se debe realizar una conversión de zona horaria de forma manual para que coincida con la función TIMESTAMP WITH LOCAL TIME ZONE de Oracle.

TIMESTAMP(x) TIMESTAMP BigQuery admite la precisión de microsegundos (10-6) en comparación con Oracle, que admite una precisión de 0 a 9.

BigQuery admite un nombre de región de zona horaria a partir de una base de datos TZ y un desplazamiento de zona horaria de UTC.

En BigQuery, se debe realizar una conversión de zona horaria de forma manual para que coincida con la función TIMESTAMP WITH LOCAL TIME ZONE de Oracle.

TIMESTAMP WITH TIME ZONE TIMESTAMP BigQuery admite la precisión de microsegundos (10-6) en comparación con Oracle, que admite una precisión de 0 a 9.

BigQuery admite un nombre de región de zona horaria a partir de una base de datos TZ y un desplazamiento de zona horaria de UTC.

En BigQuery, se debe realizar una conversión de zona horaria de forma manual para que coincida con la función TIMESTAMP WITH LOCAL TIME ZONE de Oracle.

TIMESTAMP WITH LOCAL TIME ZONE TIMESTAMP BigQuery admite la precisión de microsegundos (10-6) en comparación con Oracle, que admite una precisión de 0 a 9.

BigQuery admite un nombre de región de zona horaria a partir de una base de datos TZ y un desplazamiento de zona horaria de UTC.

En BigQuery, se debe realizar una conversión de zona horaria de forma manual para que coincida con la función TIMESTAMP WITH LOCAL TIME ZONE de Oracle.

INTERVAL YEAR TO MONTH STRING Los valores de intervalo se pueden almacenar como el tipo de datos STRING en BigQuery.
INTERVAL DAY TO SECOND STRING Los valores de intervalo se pueden almacenar como el tipo de datos STRING en BigQuery.
RAW BYTES Se puede usar el tipo de datos BYTES para almacenar datos binarios de longitud variable. Si este campo no se consulta ni se usa en las estadísticas, una mejor opción es almacenar los datos binarios en Cloud Storage.
LONG RAW BYTES Se puede usar el tipo de datos BYTES para almacenar datos binarios de longitud variable. Si este campo no se consulta ni se usa en las estadísticas, una mejor opción es almacenar los datos binarios en Cloud Storage.
ROWID STRING Estos tipos de datos se usan en Oracle de forma interna para especificar direcciones únicas para las filas de una tabla. Por lo general, los campos ROWID o UROWID no deben usarse en aplicaciones. Sin embargo, si este es el caso, se puede usar el tipo de datos STRING para conservar estos datos.

Formateo de tipos

SQL de Oracle usa un conjunto de formatos predeterminados establecidos como parámetros para mostrar expresiones y datos de columnas y para conversiones entre tipos de datos. Por ejemplo, NLS_DATE_FORMAT configurado como YYYY/MM/DD formatea fechas como YYYY/MM/DD de forma predeterminada. Puedes encontrar más información sobre la configuración de NLS en la documentación en línea de Oracle. En BigQuery, no hay parámetros de inicialización.

De manera predeterminada, BigQuery espera que todos los datos de origen estén codificados en UTF-8 durante la carga. Por otro lado, si tienes archivos CSV con datos codificados en formato ISO-8859-1, puedes especificar de forma explícita la codificación cuando importes tus datos a fin de que BigQuery pueda convertirlos con éxito en UTF-8 durante el proceso de importación.

Solo es posible importar datos codificados como ISO-8859-1 o como UTF-8. BigQuery almacena y muestra los datos como codificados en UTF-8. El formato de fecha o la zona horaria deseados se pueden configurar en las funciones DATE y TIMESTAMP.

Tipos de formato de marca de tiempo y fecha

Cuando conviertes los elementos de formato de fecha y marca de tiempo de Oracle en BigQuery, debes prestar atención a las diferencias de zona horaria entre TIMESTAMP y DATETIME, como se resume en la siguiente tabla.

Ten en cuenta que no hay paréntesis en los formatos de Oracle, ya que los formatos (CURRENT_*) son palabras clave, no funciones.

Oracle BigQuery Notas
CURRENT_TIMESTAMP La información de TIMESTAMP en Oracle puede tener información de zona horaria diferente, que se define mediante WITH TIME ZONE en la definición de columnas o la variable de configuración TIME_ZONE. Si es posible, usa la función CURRENT_TIMESTAMP(), que tiene formato ISO. Sin embargo, el formato de salida siempre muestra la zona horaria UTC. (A nivel interno, BigQuery no tiene una zona horaria).

Ten en cuenta los siguientes detalles sobre las diferencias en el formato ISO.

El formato de DATETIME se basa en las convenciones del canal de salida. En la herramienta de línea de comandos y la consola de BigQuery, DATETIME se formatea con un separador T según RFC 3339. Sin embargo, en JDBC de Python y Java, se usa un espacio como separador.

Si quieres usar un formato explícito, usa la función FORMAT_DATETIME(), que hace que una conversión explícita sea una string. Por ejemplo, la siguiente expresión siempre muestra un separador de espacio: CAST(CURRENT_DATETIME() AS STRING)

CURRENT_DATE
SYSDATE 		Oracle usa 2 tipos para la fecha:
  • tipo 12
  • tipo 13
Oracle usa el tipo 12 cuando almacena fechas. De forma interna, estos son números de longitud fija. Oracle usa el tipo 13 cuando SYSDATE or CURRENT_DATE muestra uno. 		BigQuery tiene un formato DATE independiente que siempre muestra una fecha en formato ISO 8601.

No se puede usar DATE_FROM_UNIX_DATE porque se basa en 1970.

CURRENT_DATE-3 Los valores de fecha se representan como números enteros. Oracle admite operadores aritméticos para tipos de fecha. Para los tipos de fecha, usa DATE_ADD() o DATE_SUB(). BigQuery usa operadores aritméticos a tipos de datos: INT64, NUMERIC y FLOAT64.
NLS_DATE_FORMAT Establece el formato de fecha de la sesión o del sistema. BigQuery siempre usa ISO 8601, así que asegúrate de convertir las fechas y horas de Oracle.

Sintaxis de las consultas

En esta sección, se abordan las diferencias que existen en la sintaxis de consultas en Oracle y en BigQuery.

Declaraciones SELECT

La mayoría de las declaraciones SELECT de Oracle son compatibles con BigQuery.

Funciones, operadores y expresiones

En las siguientes secciones, se muestra una lista de las funciones de Oracle junto con las funciones equivalentes de BigQuery.

Operadores de comparación

Los operadores de comparación de Oracle y BigQuery cumplen con el ANSI SQL:2011. Los operadores de comparación en la siguiente tabla son los mismos en BigQuery y Oracle. Puedes usar REGEXP_CONTAINS en lugar de REGEXP_LIKE en BigQuery.

Operador Descripción
"=" Igual
<> No igual
!= No igual
> Mayor que
>= Mayor que o igual
< Menor que
<= Menor que o igual
IN ( ) Coincide con un valor de una lista
NOT Niega una condición
BETWEEN Dentro de un rango (inclusivo)
IS NULL valor NULL
IS NOT NULL No es un valor NULL
LIKE Coincidencia de patrones con %
EXISTS La condición se cumple si la subconsulta muestra al menos una fila.

Los operadores de la tabla son los mismos en BigQuery y Oracle.

Expresiones y funciones lógicas

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)

Funciones de agregación

En la siguiente tabla, se muestran las asignaciones entre las funciones comunes de agregación de Oracle, de agregación estadística y de agregación aproximada con sus equivalentes de BigQuery:

Oracle BigQuery
ANY_VALUE
(de 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 no admite el resto de los argumentos que define Oracle.
<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 Operador NOT a nivel de bits:
BIT_OR BIT_OR, X | Y
BIT_XOR BIT_XOR, X ^ Y
BITAND BIT_AND, X & Y
CARDINALITY COUNT
COLLECT BigQuery no es compatible con TYPE AS TABLE OF. Considera usar STRING_AGG() o ARRAY_AGG() en BigQuery
CORR/CORR_K/ CORR_S CORR
COUNT COUNT
COVAR_POP COVAR_POP
COVAR_SAMP COVAR_SAMP
FIRST No existe implícitamente en BigQuery. Considera usar funciones definidas por el usuario (UDF).
GROUP_ID No se usa en BigQuery.
GROUPING No se usa en BigQuery.
GROUPING_ID No se usa en BigQuery.
LAST No existe implícitamente en BigQuery. Considera usar las UDFs
LISTAGG STRING_AGG, ARRAY_CONCAT_AGG(expression [ORDER BY key [{ASC|DESC}] [, ... ]] [LIMIT n])
MAX MAX
MIN MIN
OLAP_CONDITION Específico de Oracle, no existe en BigQuery.
OLAP_EXPRESSION Específico de Oracle, no existe en BigQuery.
OLAP_EXPRESSION_BOOL Específico de Oracle, no existe en BigQuery.
OLAP_EXPRESSION_DATE Específico de Oracle, no existe en BigQuery.
OLAP_EXPRESSION_TEXT Específico de Oracle, no existe en BigQuery.
OLAP_TABLE Específico de Oracle, no existe en BigQuery.
POWERMULTISET Específico de Oracle, no existe en BigQuery.
POWERMULTISET_BY_CARDINALITY Específico de Oracle, no existe en BigQuery.
QUALIFY Específico de Oracle, no existe en BigQuery.
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 ofrece las siguientes funciones de agregación adicionales:

Funciones analíticas

En la siguiente tabla, se muestran las asignaciones entre las funciones analíticas y de agregación comunes de Oracle con sus equivalentes de BigQuery.

Oracle BigQuery
AVG AVG
BIT_COMPLEMENT Operador NOT a nivel de bits:
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 No es compatible con BigQuery. Considera usar una herramienta de IE o una UDF personalizada
CUME_DIST CUME_DIST
DENSE_RANK(ANSI) DENSE_RANK
FEATURE_COMPARE No existe implícitamente en BigQuery. Considera usar UDF y BigQuery ML
FEATURE_DETAILS No existe implícitamente en BigQuery. Considera usar UDF y BigQuery ML
FEATURE_ID No existe implícitamente en BigQuery. Considera usar UDF y BigQuery ML
FEATURE_SET No existe implícitamente en BigQuery. Considera usar UDF y BigQuery ML
FEATURE_VALUE No existe implícitamente en BigQuery. Considera usar UDF y BigQuery ML
FIRST_VALUE FIRST_VALUE
HIER_CAPTION Las consultas jerárquicas no son compatibles con BigQuery.
HIER_CHILD_COUNT Las consultas jerárquicas no son compatibles con BigQuery.
HIER_COLUMN Las consultas jerárquicas no son compatibles con BigQuery.
HIER_DEPTH Las consultas jerárquicas no son compatibles con BigQuery.
HIER_DESCRIPTION Las consultas jerárquicas no son compatibles con BigQuery.
HIER_HAS_CHILDREN Las consultas jerárquicas no son compatibles con BigQuery.
HIER_LEVEL Las consultas jerárquicas no son compatibles con BigQuery.
HIER_MEMBER_NAME Las consultas jerárquicas no son compatibles con BigQuery.
HIER_ORDER Las consultas jerárquicas no son compatibles con BigQuery.
HIER_UNIQUE_MEMBER_NAME Las consultas jerárquicas no son compatibles con BigQuery.
LAST_VALUE LAST_VALUE
LAG LAG
LEAD LEAD
LISTAGG ARRAY_AGG
STRING_AGG
ARRAY_CONCAT_AGG
MATCH_NUMBER El reconocimiento y el cálculo de patrones se pueden realizar con expresiones regulares y UDF en BigQuery
MATCH_RECOGNIZE El reconocimiento y el cálculo de patrones se pueden realizar con expresiones regulares y UDF en BigQuery
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 Específico de Oracle, no existe en BigQuery.
PRESENTV Específico de Oracle, no existe en BigQuery.
PREVIOUS Específico de Oracle, no existe en BigQuery.
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 Se puede usar una UDF.

Funciones de fecha y hora

En la siguiente tabla, se muestran las asignaciones entre las funciones comunes de fecha y hora de Oracle y sus equivalentes de BigQuery.

Oracle BigQuery
ADD_MONTHS(date, integer) DATE_ADD(date, INTERVAL integer MONTH),
Si la fecha es un TIMESTAMP, puedes usar

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 no admite la zona horaria de la base de datos.
EXTRACT EXTRACT(DATE), EXTRACT(TIMESTAMP)
LAST_DAY DATE_SUB(
  DATE_TRUNC(
    DATE_ADD(
      date_expression,
      INTERVAL 1 MONTH
    ),
  MONTH
  ),
INTERVAL 1 DAY
)
LOCALTIMESTAMP BigQuery no admite la configuración de zona horaria.
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 No es compatible con BigQuery. Considera usar una UDF personalizada.
WM_CONTAINS
WM_EQUALS
WM_GREATERTHAN
WM_INTERSECTION
WM_LDIFF
WM_LESSTHAN
WM_MEETS
WM_OVERLAPS
WM_RDIFF
 Los períodos no se usan en BigQuery. Las UDFs se pueden usar para comparar dos períodos.

BigQuery ofrece las siguientes funciones adicionales de fecha y hora:

Funciones de string

En la siguiente tabla, se muestran las asignaciones entre las funciones de cadenas de Oracle y sus equivalentes de BigQuery:

Oracle BigQuery
ASCII TO_CODE_POINTS(string_expr)[OFFSET(0)]
ASCIISTR BigQuery no es compatible con UTF-16
RAWTOHEX TO_HEX
LENGTH CHAR_LENGTH
LENGTH CHARACTER_LENGTH
CHR CODE_POINTS_TO_STRING(
[mod(numeric_expr, 256)]
)
COLLATION No existe en BigQuery. BigQuery no admite COLLATE en DML
COMPOSE Función personalizada definida por el usuario.
CONCAT, (|| operator) CONCAT
DECOMPOSE Función personalizada definida por el usuario.
ESCAPE_REFERENCE (UTL_I18N) No es compatible con BigQuery. Considera usar una función definida por el usuario.
INITCAP INITCAP
INSTR/INSTR2/INSTR4/INSTRB/INSTRC Función personalizada definida por el usuario.
LENGTH/LENGTH2/LENGTH4/LENGTHB/LENGTHC LENGTH
LOWER LOWER
LPAD LPAD
LTRIM LTRIM
NLS_INITCAP Función personalizada definida por el usuario.
NLS_LOWER LOWER
NLS_UPPER UPPER
NLSSORT Específico de Oracle, no existe en BigQuery.
POSITION STRPOS(string, substring)
PRINTBLOBTOCLOB Específico de Oracle, no existe en BigQuery.
REGEXP_COUNT ARRAY_LENGTH(REGEXP_EXTRACT_ALL(value, regex))
REGEXP_INSTR STRPOS(source_string, REGEXP_EXTRACT(source_string, regexp_string))

Nota: Muestra el primer caso.
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 No es compatible con BigQuery. Considera usar una UDF personalizada
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
|| (BARRAS VERTICALES) CONCAT

BigQuery ofrece las siguientes funciones de string adicionales:

Funciones matemáticas

En la siguiente tabla, se muestran las asignaciones entre las funciones matemáticas de Oracle y sus equivalentes de BigQuery:

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 úsalo con ISNULL.
LOG LOG
MOD (% operator) MOD
POWER (** operator) POWER, POW
DBMS_RANDOM.VALUE RAND
RANDOMBYTES No es compatible con BigQuery. Considera usar una función UDF y RAND personalizada
RANDOMINTEGER CAST(FLOOR(10*RAND()) AS INT64)
RANDOMNUMBER No es compatible con BigQuery. Considera usar una función UDF y RAND personalizada
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 ofrece las siguientes funciones matemáticas adicionales:

Funciones de conversión de tipo

En la siguiente tabla, se muestran las asignaciones entre las funciones de conversión de tipo de Oracle y sus equivalentes de BigQuery.

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 No se necesita la información específica de Oracle.
CONVERT BigQuery no admite grupos de caracteres. Considera usar una función personalizada definida por el usuario.
EMPTY_BLOB BLOB no se usa en BigQuery.
EMPTY_CLOB CLOB no se usa en BigQuery.
FROM_TZ Los tipos con zonas horarias no son compatibles con BigQuery. Considera usar una función definida por el usuario y FORMAT_TIMESTAMP.
INT_TO_BOOL CAST
IS_BIT_SET No existe implícitamente en BigQuery. Considera usar las UDFs
NCHR La UDF se puede usar para obtener el equivalente de caracteres del objeto binario
NUMTODSINTERVAL BigQuery no admite el tipo de datos INTERVAL
NUMTOHEX No es compatible con BigQuery. Considera usar una UDF personalizada y una función TO_HEX
NUMTOHEX2
NUMTOYMINTERVAL El tipo de datos INTERVAL no es compatible con BigQuery.
RAW_TO_CHAR Específico de Oracle, no existe en BigQuery.
RAW_TO_NCHAR Específico de Oracle, no existe en BigQuery.
RAW_TO_VARCHAR2 Específico de Oracle, no existe en BigQuery.
RAWTOHEX Específico de Oracle, no existe en BigQuery.
RAWTONHEX Específico de Oracle, no existe en BigQuery.
RAWTONUM Específico de Oracle, no existe en BigQuery.
RAWTONUM2 Específico de Oracle, no existe en BigQuery.
RAWTOREF Específico de Oracle, no existe en BigQuery.
REFTOHEX Específico de Oracle, no existe en BigQuery.
REFTORAW Específico de Oracle, no existe en BigQuery.
ROWIDTOCHAR ROWID es un tipo específico de Oracle y no existe en BigQuery. Este valor se debe representar como una string.
ROWIDTONCHAR ROWID es un tipo específico de Oracle y no existe en BigQuery. Este valor se debe representar como una string.
SCN_TO_TIMESTAMP SCN es un tipo específico de Oracle y no existe en BigQuery. Este valor debe representarse como una marca de tiempo.
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
La sintaxis de conversión de tipos se usa en una consulta para indicar que el tipo de resultado de una expresión debe convertirse en algún otro tipo.
TREAT Específico de Oracle, no existe en BigQuery.
VALIDATE_CONVERSION No es compatible con BigQuery. Considera usar una UDF personalizada
VSIZE No es compatible con BigQuery. Considera usar una UDF personalizada

Funciones JSON

En la siguiente tabla, se muestran las asignaciones entre las funciones JSON de Oracle y sus equivalentes de BigQuery.

Oracle BigQuery
AS_JSON TO_JSON_STRING(value[, pretty_print])
JSON_ARRAY Considera usar UDFs y la función TO_JSON_STRING
JSON_ARRAYAGG Considera usar UDFs y la función TO_JSON_STRING
JSON_DATAGUIDE Función personalizada definida por el usuario.
JSON_EQUAL Función personalizada definida por el usuario.
JSON_EXIST Considera usar UDFs y JSON_EXTRACT o JSON_EXTRACT_SCALAR
JSON_MERGEPATCH Función personalizada definida por el usuario.
JSON_OBJECT No es compatible con BigQuery.
JSON_OBJECTAGG No es compatible con BigQuery.
JSON_QUERY Considera usar UDF y JSON_EXTRACT o JSON_EXTRACT_SCALAR.
JSON_TABLE Función personalizada definida por el usuario.
JSON_TEXTCONTAINS Considera usar UDF y JSON_EXTRACT o JSON_EXTRACT_SCALAR.
JSON_VALUE JSON_EXTRACT_SCALAR

Funciones XML

BigQuery no proporciona funciones XML implícitas. El XML se puede cargar en BigQuery como una string y las UDFs se pueden usar para analizar XML. Como alternativa, el procesamiento XML lo realiza una herramienta de ETL/ELT, como Dataflow. En la siguiente lista, se muestran las funciones de XML de Oracle:

Oracle BigQuery
DELETEXML Las UDFs de BigQuery o la herramienta ETL como Dataflow se pueden usar para procesar XML.
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

Funciones de aprendizaje automático

Las funciones de aprendizaje automático (AA) en Oracle y BigQuery son diferentes. Oracle requiere un paquete de estadísticas avanzadas y licencias para realizar el AA en la base de datos. Oracle usa el paquete DBMS_DATA_MINING para el AA. La conversión de trabajos de minería de datos de Oracle requiere volver a escribir el código; puedes elegir entre ofertas completas de productos de IA de Google, como BigQuery ML o las APIs de IA (incluidas Speech‐to‐Text, Text‐to‐Speech, Dialogflow, Cloud Translation y PLN, Cloud Vision y la API de Timeseries Insights, AutoML, AutoML Tables o AI Platform. Los notebooks administrados por el usuario de Google se pueden usar como un entorno de desarrollo para científicos de datos, y Google AI Platform Training se puede usar para ejecutar el entrenamiento y puntuación de las cargas de trabajo a gran escala. En la siguiente tabla, se muestran las funciones del AA de Oracle:

Oracle BigQuery
CLASSIFIER Consulta BigQuery ML para ver las opciones de clasificación y regresión de aprendizaje automático.
CLUSTER_DETAILS
CLUSTER_DISTANCE
CLUSTER_ID
CLUSTER_PROBABILITY
CLUSTER_SET
PREDICTION
PREDICTION_BOUNDS
PREDICTION_COST
PREDICTION_DETAILS
PREDICTION_PROBABILITY
PREDICTION_SET

Funciones de seguridad

En la siguiente tabla, se muestran las funciones para identificar al usuario en Oracle y BigQuery:

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

Funciones de conjuntos o arrays

En la siguiente tabla, se muestran las funciones de conjuntos o arrays en Oracle y sus equivalentes en BigQuery:

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

Funciones analíticas

En la siguiente tabla, se muestran las funciones analíticas en Oracle y sus equivalentes en BigQuery.

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

Consultas jerárquicas o recurrentes

No se usan consultas jerárquicas o recurrentes en BigQuery. Si la profundidad de la jerarquía se conoce, se puede lograr una funcionalidad similar con uniones, como se ilustra en el siguiente ejemplo. Otra solución sería usar la API de BigQuery Storage y 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

En la siguiente tabla, se muestran las funciones jerárquicas en Oracle.

Oracle BigQuery
DEPTH Las consultas jerárquicas no se usan en BigQuery.
PATH
SYS_CONNECT_BY_PATH (hierarchical)

Funciones UTL

El paquete UTL_File se usa principalmente para leer y escribir los archivos del sistema operativo desde PL/SQL. Cloud Storage se puede usar para cualquier tipo de etapa de pruebas de archivos sin procesar. Las tablas externas y las cargas y exportaciones de BigQuery deben usarse para leer y escribir archivos desde y hacia Cloud Storage. Para obtener más información, consulta Introducción a las fuentes de datos externas.

Funciones espaciales

Puedes usar las estadísticas geoespaciales de BigQuery para reemplazar la funcionalidad espacial. Hay funciones y tipos SDO_* en Oracle, como SDO_GEOM_KEY, SDO_GEOM_MBR, SDO_GEOM_MMB. Estas funciones se usan para el análisis espacial. Puedes usar estadísticas geoespaciales para realizar análisis espaciales.

Sintaxis de DML

En esta sección, se abordan las diferencias que existen entre la sintaxis del lenguaje de administración de datos de Oracle y de BigQuery.

Declaración INSERT

La mayoría de las declaraciones INSERT de Oracle son compatibles con BigQuery. En la siguiente tabla, se muestran las excepciones.

Las secuencias de comandos del DML en BigQuery tienen una semántica de coherencia apenas diferente de la que tienen las declaraciones equivalentes de Oracle. Para obtener una descripción general del aislamiento de instantáneas y el control de sesiones y transacciones, consulta la sección CREATE [UNIQUE] INDEX section en este documento.

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

Oracle ofrece una palabra clave DEFAULT para las columnas que no admiten valores nulos.

Nota: En BigQuery, omitir los nombres de columna en la declaración INSERT solo funciona si los valores de todas las columnas de la tabla de destino se incluyen en orden ascendente según sus posiciones ordinales.
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 impone cuotas de DML, que restringen la cantidad de declaraciones DML que puedes ejecutar a diario. Para aprovechar al máximo tu cuota, considera los siguientes enfoques:

  • Combina varias filas en una sola declaración INSERT, en lugar de una fila por operación INSERT.
  • Combina varias declaraciones DML (incluida INSERT) mediante una declaración MERGE.
  • Usa CREATE TABLE ... AS SELECT para crear y propagar tablas nuevas.

Declaración UPDATE

Las declaraciones UPDATE de Oracle son, en su mayoría, compatibles con BigQuery. Sin embargo, en BigQuery, la declaración UPDATE debe tener una cláusula WHERE.

Como práctica recomendada, debes preferir las declaraciones DML por lotes en lugar de varias declaraciones UPDATE y INSERT. Las secuencias de comandos del DML en BigQuery tienen una semántica de coherencia apenas diferente de la que tienen las declaraciones equivalentes de Oracle. Para obtener una descripción general del aislamiento de instantáneas y el control de sesiones y transacciones, consulta la sección CREATE INDEX de este documento.

En la siguiente tabla, se muestran las declaraciones UPDATE de Oracle y las declaraciones de BigQuery que realizan las mismas tareas.

En BigQuery, la declaración UPDATE debe tener una cláusula WHERE. Para obtener más información sobre UPDATE en BigQuery, consulta los ejemplos de UPDATE de BigQuery en la documentación del DML.

Declaraciones DELETE y TRUNCATE

Las declaraciones DELETE y TRUNCATE son alternativas para quitar filas de una tabla sin afectar el esquema de esta. TRUNCATE no se usa en BigQuery. Sin embargo, puedes usar declaraciones DELETE para obtener el mismo resultado.

En BigQuery, la declaración DELETE debe tener una cláusula WHERE. Para obtener más información sobre DELETE en BigQuery, consulta los ejemplos de DELETE de BigQuery en la documentación del DML.

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

Declaración MERGE

La declaración MERGE puede combinar operaciones INSERT, UPDATE y DELETE en una sola declaración de UPSERT y realizar las operaciones de forma atómica. La operación MERGE debe vincular como máximo una fila de origen con cada fila de destino. BigQuery y Oracle siguen la sintaxis ANSI.

Sin embargo, las secuencias de comandos de DML en BigQuery tienen una semántica de coherencia apenas diferente a las declaraciones equivalentes de Oracle.

Sintaxis del DDL

En esta sección, se abordan las diferencias que existen entre la sintaxis del lenguaje de definición de datos en Snowflake y en Oracle.

Declaración CREATE TABLE

La mayoría de las declaraciones CREATE TABLE de Oracle son compatibles con BigQuery, excepto las siguientes restricciones y elementos de sintaxis, que no se usan en BigQuery:

  • STORAGE
  • TABLESPACE
  • DEFAULT
  • GENERATED ALWAYS AS
  • ENCRYPT
  • PRIMARY KEY (col, ...). Para obtener más información, consulta CREATE INDEX.
  • UNIQUE INDEX. Para obtener más información, consulta CREATE INDEX.
  • CONSTRAINT..REFERENCES
  • DEFAULT
  • PARALLEL
  • COMPRESS

Para obtener más información sobre CREATE TABLE en BigQuery, consulta los ejemplos de CREATE TABLE de BigQuery.

Atributos y opciones de columnas

Las columnas de identidad se ingresan con la versión de Oracle 12c, que habilita el incremento automático en una columna. Esto no se usa en BigQuery; esto se puede lograr con el siguiente método por lotes. Para obtener más información sobre las claves sustitutas y el cambio lento de las dimensiones (SCD), consulta las siguientes guías:

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

Comentarios de la columna

Oracle usa la sintaxis Comment para agregar comentarios en las columnas. Esta función se puede implementar de manera similar en BigQuery mediante la descripción de la columna, como se muestra en la siguiente tabla:

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

Tablas temporales

Oracle admite tablas temporales, que a menudo se usan para almacenar resultados intermedios en secuencias de comandos. Las tablas temporales son compatibles con BigQuery.

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;

Los siguientes elementos de Oracle no se usan en BigQuery:

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

También existen otras formas de emular tablas temporales en BigQuery, como las que se describen a continuación:

  • TTL del conjunto de datos: Crea un conjunto de datos con un tiempo de actividad corto (por ejemplo, 1 hora) para que las tablas creadas en el conjunto de datos sean temporales, ya que no durarán más que el tiempo de actividad del conjunto de datos. Puedes poner prefijos en todos los nombres de las tablas de este conjunto de datos mediante temp para indicar con claridad que las tablas son temporales.

  • TTL de la tabla: Crea una tabla que tenga un tiempo de actividad específico para la tabla mediante declaraciones del DDL similares a las siguientes:

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

  • Cláusula WITH: Si se necesita una tabla temporal solo dentro del mismo bloque, usa un resultado temporal mediante una declaración o subconsulta WITH.

Declaración CREATE SEQUENCE

Las secuencias no se usan en BigQuery; esto se puede lograr de la siguiente manera por lotes. Para obtener más información sobre las claves sustitutas y el cambio lento de las dimensiones (SCD), consulta las siguientes guías:

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

Declaración CREATE VIEW

En la siguiente tabla, se muestran equivalencias de la declaración CREATE VIEW entre Oracle y BigQuery.

Oracle BigQuery Notas
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 ...
No compatible CREATE VIEW IF NOT EXISTS view_name OPTIONS(view_option_list) AS SELECT ... Crea una nueva vista solo si la vista no existe actualmente en el conjunto de datos especificado.

Declaración CREATE MATERIALIZED VIEW

En BigQuery, las operaciones de actualización de vistas materializadas se realizan de forma automática. No es necesario especificar opciones de actualización (por ejemplo, en la confirmación o según la programación) en BigQuery. Para obtener más información, consulta Introducción a las vistas materializadas.

En caso de que la tabla base cambie solo mediante anexos, la consulta que usa la vista materializada (ya sea que el optimizador de consultas haga referencia a ella o la seleccione de forma explícita) analiza toda la vista materializada más un delta en la tabla base desde la última actualización de la vista. Esto significa que las consultas son más rápidas y económicas.

Por el contrario, si hubo alguna actualización (DML UPDATE/MERGE) o eliminación (DML DELETE, t, truncamiento, vencimiento de la partición) en la tabla base desde la última actualización de la vista, la vista materializada no se analiza y, por lo tanto, la consulta no obtiene ningún ahorro hasta la próxima actualización de la vista. En esencia, cualquier actualización o eliminación en la tabla base invalida el estado de la vista materializada.

Además, los datos del búfer de transmisión de la tabla base no se guardan en la vista materializada. El búfer de transmisión aún se está analizando por completo, independientemente de si se usa la vista materializada.

En la siguiente tabla, se muestran equivalencias de la declaración CREATE MATERIALIZED VIEW entre Oracle y BigQuery.

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

Declaración CREATE [UNIQUE] INDEX

En esta sección, se describen los enfoques en BigQuery para crear una funcionalidad similar a los índices en Oracle.

Indexa en favor del rendimiento

BigQuery no necesita índices explícitos, ya que es una base de datos orientada a columnas con optimización de consultas y almacenamiento. BigQuery proporciona funciones como la partición y el agrupamiento en clústeres, además de los campos anidados, que pueden aumentar la eficiencia y el rendimiento de las consultas mediante la optimización de la forma en que se almacenan los datos.

Indexa en favor de la coherencia (UNIQUE, PRIMARY INDEX)

En Oracle, se puede usar un índice único para evitar filas con claves que no sean únicas en una tabla. Si un proceso intenta insertar o actualizar datos que tienen un valor que ya está en el índice, la operación falla y se muestra una infracción del índice.

Debido a que BigQuery no proporciona índices explícitos, se puede usar una declaración MERGE en su lugar para insertar solo registros únicos en una tabla de destino desde una tabla de etapa de pruebas y descartar los registros duplicados. Sin embargo, no hay forma de evitar que un usuario con permisos de edición inserte un registro duplicado.

Para generar un error en los registros duplicados de BigQuery, puedes usar una declaración MERGE de la tabla de etapa de pruebas, como se muestra en el siguiente ejemplo.

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());

Por lo general, los usuarios prefieren quitar los duplicados de forma independiente para encontrar errores en los sistemas posteriores.

BigQuery no admite las columnas DEFAULT ni IDENTITY (secuencias).

Bloqueo

BigQuery no tiene un mecanismo de bloqueo como Oracle y puede ejecutar consultas simultáneas (hasta completar tu cuota). Solo las declaraciones DML tienen ciertos límites de simultaneidad y pueden requerir un bloqueo de la tabla durante la ejecución en algunos casos.

Instrucciones de SQL de procedimiento

En esta sección, se describe cómo convertir las instrucciones de SQL de procedimiento que se usan en procedimientos, funciones y activadores almacenados de Oracle a BigQuery.

Declaración CREATE PROCEDURE

El procedimiento almacenado es compatible con la fase Beta de la secuencia de comandos de BigQuery.

Oracle BigQuery Notas
CREATE PROCEDURE CREATE PROCEDURE Al igual que en Oracle, BigQuery admite modos de argumento IN, OUT, INOUT. BigQuery no admite otras especificaciones de sintaxis.
CREATE OR REPLACE PROCEDURE CREATE OR REPLACE PROCEDURE
CALL CALL

En las siguientes secciones, se describen las maneras de convertir las declaraciones de procedimiento de Oracle existentes en declaraciones de scripting de BigQuery que funcionan de manera similar.

Declaración CREATE TRIGGER

No se usan activadores en BigQuery. La lógica de aplicación basada en filas debe manejarse en la capa de aplicación. La funcionalidad del activador se puede lograr mediante la herramienta de transferencia, Pub/Sub o Cloud Functions durante el tiempo de transferencia o mediante análisis regulares.

Declaración y asignación de variables

En la siguiente tabla, se muestran las declaraciones DECLARE de Oracle y sus equivalentes de 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;

Declaraciones y operaciones del cursor

BigQuery no admite cursores, por lo que las siguientes declaraciones no se usan en BigQuery:

Instrucciones de SQL dinámicas

La siguiente instrucción de SQL dinámica de Oracle y su equivalente de BigQuery:

Oracle BigQuery
EXECUTE IMMEDIATE sql_str

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

EXECUTE IMMEDIATE

sql_expression [INTO variable[, ...]]

[USING identifier[, ...]];

;

Instrucciones de flujo de control

En la siguiente tabla, se muestran las instrucciones de flujo de control de Oracle y sus equivalentes de BigQuery.

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 no se usa en BigQuery. Usa otras declaraciones LOOP.
BREAK BREAK
CONTINUE CONTINUE
CONTINUE/EXIT WHEN Usa CONTINUE con la condición IF.
GOTO La declaración GOTO no existe en BigQuery. Usa la condición IF.

Instrucciones de SQL de transacciones y metadatos

Oracle BigQuery
GATHER_STATS_JOB Aún no se usa en BigQuery.
LOCK TABLE table_name IN [SHARE/EXCLUSIVE] MODE NOWAIT; Aún no se usa en BigQuery.
Alter session set isolation_level=serializable; /

SET TRANSACTION ...

BigQuery siempre usa el aislamiento de instantáneas. Para obtener más información, consulta Garantías de coherencia y aislamiento de transacción en este documento.
EXPLAIN PLAN ... No se usa en BigQuery.

Funciones similares a este elemento son la explicación del plan de consulta en la IU web de BigQuery y la asignación de ranuras, en el registro de auditoría de Stackdriver.
SELECT * FROM DBA_[*];

(Vistas DBA_/ALL_/V$ de Oracle)

SELECT * FROM mydataset.INFORMATION_SCHEMA.TABLES;

Para obtener más información, consulta Introducción a INFORMATION_SCHEMA de BigQuery.
SELECT * FROM GV$SESSION;

SELECT * FROM V$ACTIVE_SESSION_HISTORY;

BigQuery no tiene el concepto de sesión tradicional. Puedes ver los trabajos de consulta en la IU o exportar los registros de auditoría de Stackdriver a BigQuery y analizar los registros de BigQuery para analizar trabajos. Para obtener más información, consulta Visualiza los detalles del trabajo.
START TRANSACTION;

LOCK TABLE table_A IN EXCLUSIVE MODE NOWAIT;

DELETE FROM table_A;

INSERT INTO table_A SELECT * FROM table_B;

COMMIT;

 El equivalente a una transacción es reemplazar el contenido de una tabla por el resultado de la consulta. Puedes hacerlo con una operación de consulta o una operación de copiado.

Mediante una consulta:

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

Mediante una copia:

bq cp -f table_A table_B

Instrucciones de SQL de varias instrucciones y varias líneas

Oracle y BigQuery admiten transacciones (sesiones) y, por lo tanto, admiten declaraciones separadas por punto y coma que se ejecutan juntas de manera coherente. Para obtener más información, consulta Transacciones de varias declaraciones.

Mensajes y códigos de error

Los códigos de error de Oracle y los de BigQuery son diferentes. Si la lógica de tu aplicación detecta los errores, intenta quitar la fuente del error, ya que BigQuery no muestra los mismos códigos de error.

Garantías de coherencia y aislamiento de transacción

Tanto Oracle como BigQuery son atómicos, es decir, cumplen con el estándar ACID en un nivel por transformación en muchas filas. Por ejemplo, una operación MERGE es atómica, incluso con varios valores insertados y actualizados.

Transacciones

Oracle proporciona niveles de aislamiento de transacción confirmados o serializables. Los interbloqueos son posibles. Los trabajos de anexo de inserción de Oracle se ejecutan de forma independiente.

BigQuery también admite transacciones. BigQuery ayuda a garantizar el control de simultaneidad optimista (gana el primero en confirmarse) con el aislamiento de instantáneas, de modo que una consulta lea los últimos datos que se confirmaron antes de comenzar la consulta. Este enfoque garantiza el mismo nivel de coherencia por fila, por transformación y entre filas dentro de la misma declaración DML y evita los interbloqueos. En el caso de varias declaraciones UPDATE en la misma tabla, BigQuery cambia al control de simultaneidad pesimista y pone en cola varias declaraciones UPDATE; además se realizan reintentos de forma automática en caso de conflictos. Las declaraciones DML INSERT y los trabajos de carga se pueden ejecutar de forma independiente y simultánea para agregar contenido a las tablas.

Revertir

Oracle admite reversiones. En BigQuery no hay un límite de transacciones explícito, por lo que no hay un concepto de reversión explícita. Las soluciones alternativas son los decoradores de tablas o el uso de FOR SYSTEM_TIME AS OF.

Límites de bases de datos

Verifica las cuotas y los límites más recientes de BigQuery. Para aumentar las cuotas de los usuarios de gran volumen, comunícate con el servicio de Atención al cliente de Cloud. En la siguiente tabla, se muestra una comparación de los límites de bases de datos de Oracle y BigQuery.

Límite Oracle BigQuery
Tablas por base de datos Sin restricciones Sin restricciones
Columnas por tabla 1000 10,000
Tamaño máximo de fila Ilimitado (depende del tipo de columna) 100 MB
Longitud del nombre de la columna y la tabla Si v12.2>= 128 bytes

De los demás 30 bytes

16,384 caracteres Unicode
Filas por tabla Ilimitado Ilimitado
Longitud máxima de la solicitud de SQL Ilimitado 1 MB (extensión máxima de la consulta de GoogleSQL sin resolver)

12 MB (extensión máxima de la consulta de GoogleSQL resuelta)

Transmisión:

  • 10 MB (límite de tamaño de la solicitud HTTP)
  • 10,000 (máximo de filas por solicitud)
Tamaño máximo de solicitudes y respuestas Ilimitadas 10 MB (solicitud) y 10 GB (respuesta) o casi sin límite si usas la paginación o la API de Cloud Storage
Cantidad máxima de sesiones simultáneas Limitado por las sesiones o los parámetros de procesos 100 consultas simultáneas (se pueden generar con una reserva de ranura) y 300 solicitudes a la API simultáneas por usuario.
Cantidad máxima de cargas (rápidas) simultáneas Limitado por las sesiones o los parámetros de procesos Sin límite de simultaneidad; los trabajos se ponen en cola. 100,000 trabajos de carga por proyecto por día

Otros límites de Oracle Database incluyen los límites de tipos de datos, límites de bases de datos físicas, límites lógicos de bases de datos y límites de procesos y entornos de ejecución.