Guide de traduction du langage SQL d'Oracle

Ce document décrit les similitudes et les différences de syntaxe SQL entre Oracle et BigQuery pour vous aider à planifier votre migration. Utilisez la traduction SQL par lot pour migrer vos scripts SQL de façon groupée, ou la traduction SQL interactive pour traduire des requêtes ad hoc.

Types de données

Cette section présente les équivalences entre les types de données Oracle et BigQuery.

Oracle	BigQuery	Remarques
`VARCHAR2`	`STRING`
`NVARCHAR2`	`STRING`
`CHAR`	`STRING`
`NCHAR`	`STRING`
`CLOB`	`STRING`
`NCLOB`	`STRING`
`INTEGER`	`INT64`
`SHORTINTEGER`	`INT64`
`LONGINTEGER`	`INT64`
`NUMBER`	`NUMERIC`	BigQuery n'autorise pas la spécification des valeurs personnalisées par l'utilisateur pour la précision ou le l'échelle. Par conséquent, une colonne dans Oracle peut être définie de sorte qu'elle ait une échelle plus importante que ce que BigQuery accepte. En outre, avant de stocker un nombre décimal, Oracle arrondit si ce nombre contient plus de chiffres après la virgule que le nombre indiqué dans la colonne correspondante. Dans BigQuery, cette fonctionnalité pourrait être implémentée à l'aide de la fonction `ROUND()`.
`NUMBER(*, x)`	`NUMERIC`	BigQuery n'autorise pas la spécification des valeurs personnalisées par l'utilisateur pour la précision ou le l'échelle. Par conséquent, une colonne dans Oracle peut être définie de sorte qu'elle ait une échelle plus importante que ce que BigQuery accepte. En outre, avant de stocker un nombre décimal, Oracle arrondit si ce nombre contient plus de chiffres après la virgule que le nombre indiqué dans la colonne correspondante. Dans BigQuery, cette fonctionnalité pourrait être implémentée à l'aide de la fonction `ROUND()`.
`NUMBER(x, -y)`	`INT64`	Si un utilisateur tente de stocker un nombre décimal, Oracle l'arrondit à un nombre entier. Pour BigQuery, toute tentative de stockage d'un nombre décimal dans une colonne définie comme `INT64` entraîne une erreur. Dans ce cas, la fonction `ROUND()` doit être appliquée. Les types de données `INT64` BigQuery permettent jusqu'à 18 chiffres de précision. Si un champ numérique comporte plus de 18 chiffres, le type de données `FLOAT64` doit être utilisé dans BigQuery.
`NUMBER(x)`	`INT64`	Si un utilisateur tente de stocker un nombre décimal, Oracle l'arrondit à un nombre entier. Pour BigQuery, toute tentative de stockage d'un nombre décimal dans une colonne définie comme `INT64` entraîne une erreur. Dans ce cas, la fonction `ROUND()` doit être appliquée. Les types de données `INT64` BigQuery permettent jusqu'à 18 chiffres de précision. Si un champ numérique comporte plus de 18 chiffres, le type de données `FLOAT64` doit être utilisé dans BigQuery.
`FLOAT`	`FLOAT64`/`NUMERIC`	`FLOAT` est un type de données exact et un sous-type `NUMBER` dans Oracle. Dans BigQuery, `FLOAT64` est un type de données approximatif. `NUMERIC` peut être plus adapté au type `FLOAT` dans BigQuery.
`BINARY_DOUBLE`	`FLOAT64`/`NUMERIC`	`FLOAT` est un type de données exact et un sous-type `NUMBER` dans Oracle. Dans BigQuery, `FLOAT64` est un type de données approximatif. `NUMERIC` peut être plus adapté au type `FLOAT` dans BigQuery.
`BINARY_FLOAT`	`FLOAT64`/`NUMERIC`	`FLOAT` est un type de données exact et un sous-type `NUMBER` dans Oracle. Dans BigQuery, `FLOAT64` est un type de données approximatif. `NUMERIC` peut être plus adapté au type `FLOAT` dans BigQuery.
`LONG`	`BYTES`	Le type de données `LONG` est utilisé dans les versions précédentes et n'est pas suggéré dans les nouvelles versions de la base de données Oracle. Le type de données `BYTES` dans BigQuery peut être utilisé s'il est nécessaire de stocker des données `LONG` dans BigQuery. Une meilleure approche consisterait à placer des objets binaires dans Cloud Storage et à conserver des références dans BigQuery.
`BLOB`	`BYTES`	Le type de données `BYTES` permet de stocker des données binaires de longueur variable. Si ce champ n'est pas interrogé et n'est pas utilisé dans les analyses, une meilleure option consiste à stocker des données binaires dans Cloud Storage.
`BFILE`	`STRING`	Les fichiers binaires peuvent être stockés dans Cloud Storage et le type de données `STRING` peut être utilisé pour référencer des fichiers dans une table BigQuery.
`DATE`	`DATETIME`
`TIMESTAMP`	`TIMESTAMP`	BigQuery accepte une précision à la microseconde (10^-6) par rapport à Oracle, qui accepte une précision comprise entre 0 et 9. BigQuery accepte un nom de région de fuseau horaire provenant d'une base de données TZ et un décalage de fuseau horaire par rapport à l'heure UTC. Dans BigQuery, une conversion de fuseau horaire doit être effectuée manuellement pour correspondre à la fonctionnalité `TIMESTAMP WITH LOCAL TIME ZONE` d'Oracle.
`TIMESTAMP(x)`	`TIMESTAMP`	BigQuery accepte une précision à la microseconde (10^-6) par rapport à Oracle, qui accepte une précision comprise entre 0 et 9. BigQuery accepte un nom de région de fuseau horaire provenant d'une base de données TZ et un décalage de fuseau horaire par rapport à l'heure UTC. Dans BigQuery, une conversion de fuseau horaire doit être effectuée manuellement pour correspondre à la fonctionnalité `TIMESTAMP WITH LOCAL TIME ZONE` d'Oracle.
`TIMESTAMP WITH TIME ZONE`	`TIMESTAMP`	BigQuery accepte une précision à la microseconde (10^-6) par rapport à Oracle, qui accepte une précision comprise entre 0 et 9. BigQuery accepte un nom de région de fuseau horaire provenant d'une base de données TZ et un décalage de fuseau horaire par rapport à l'heure UTC. Dans BigQuery, une conversion de fuseau horaire doit être effectuée manuellement pour correspondre à la fonctionnalité `TIMESTAMP WITH LOCAL TIME ZONE` d'Oracle.
`TIMESTAMP WITH LOCAL TIME ZONE`	`TIMESTAMP`	BigQuery accepte une précision à la microseconde (10^-6) par rapport à Oracle, qui accepte une précision comprise entre 0 et 9. BigQuery accepte un nom de région de fuseau horaire provenant d'une base de données TZ et un décalage de fuseau horaire par rapport à l'heure UTC. Dans BigQuery, une conversion de fuseau horaire doit être effectuée manuellement pour correspondre à la fonctionnalité `TIMESTAMP WITH LOCAL TIME ZONE` d'Oracle.
`INTERVAL YEAR TO MONTH`	`STRING`	Les valeurs d'intervalle peuvent être stockées en tant que type de données `STRING` dans BigQuery.
`INTERVAL DAY TO SECOND`	`STRING`	Les valeurs d'intervalle peuvent être stockées en tant que type de données `STRING` dans BigQuery.
`RAW`	`BYTES`	Le type de données `BYTES` permet de stocker des données binaires de longueur variable. Si ce champ n'est pas interrogé et utilisé dans les analyses, une meilleure option consiste à stocker les données binaires sur Cloud Storage.
`LONG RAW`	`BYTES`	Le type de données `BYTES` permet de stocker des données binaires de longueur variable. Si ce champ n'est pas interrogé et utilisé dans les analyses, une meilleure option consiste à stocker les données binaires sur Cloud Storage.
`ROWID`	`STRING`	Ces types de données sont utilisés par Oracle en interne pour spécifier des adresses uniques aux lignes d'une table. En règle générale, les champs `ROWID` ou `UROWID` ne doivent pas être utilisés dans les applications. Si tel est le cas, le type de données `STRING` peut être utilisé pour stocker ces données.

Formats types

Oracle SQL utilise un ensemble de formats par défaut définis comme des paramètres pour afficher des expressions et des données de colonne, ainsi que pour les conversions entre les types de données. Par exemple, NLS_DATE_FORMAT défini comme YYYY/MM/DD définit le format des date comme YYYY/MM/DD par défaut. Vous trouverez plus d'informations sur les paramètres NLS dans la documentation en ligne d'Oracle. Dans BigQuery, il n'existe aucun paramètre d'initialisation.

Par défaut, BigQuery s'attend à ce que toutes les données sources soient encodées au format UTF-8 lors du chargement. Si vous avez des fichiers CSV avec des données encodées au format ISO-8859-1, vous pouvez spécifier explicitement l'encodage lorsque vous importez vos données afin que BigQuery puisse les convertir correctement au format UTF-8 lors du processus d'importation.

Il n'est possible d'importer que des données encodées au format ISO-8859-1 ou UTF-8. BigQuery stocke et renvoie les données encodées au format UTF-8. Le format de date ou le fuseau horaire souhaité peut être défini dans les fonctions DATE et TIMESTAMP.

Mise en forme des types d'horodatage et de date

Lorsque vous convertissez des éléments de mise en forme d'horodatages et de dates d'Oracle en BigQuery, vous devez faire attention aux différences de fuseau horaire entre TIMESTAMP et DATETIME, comme résumé dans le tableau suivant.

Notez que les formats Oracle ne comportent pas de parenthèses, car les formats (CURRENT_*) sont des mots clés, et non des fonctions.

Oracle	BigQuery	Remarques
`CURRENT_TIMESTAMP`	Les informations `TIMESTAMP` dans Oracle peuvent avoir des informations de fuseau horaire différentes, définies à l'aide de `WITH TIME ZONE` dans la définition de colonne ou de la variable `TIME_ZONE`.	Si possible, utilisez la fonction `CURRENT_TIMESTAMP()`, qui est au format ISO. Toutefois, le format de sortie affiche toujours le fuseau horaire UTC. (En interne, BigQuery n'a pas de fuseau horaire.) Notez les détails suivants concernant les différences du format ISO : Le format de `DATETIME` repose sur des conventions de canal de sortie. Dans l'outil de ligne de commande BigQuery et la console BigQuery, `DATETIME` est mis en forme à l'aide d'un séparateur `T` conformément à la norme RFC 3339. Toutefois, dans Python et Java JDBC, un espace est utilisé comme séparateur. Si vous souhaitez utiliser un format explicite, utilisez la fonction `FORMAT_DATETIME`(), qui permet de caster une chaîne de manière explicite. Par exemple, l'expression suivante renvoie toujours un séparateur d'espace : `CAST(CURRENT_DATETIME() AS STRING)`
`CURRENT_DATE SYSDATE`	Oracle utilise deux types de date : type 12 type 13 Oracle utilise le type 12 lors du stockage des dates. En interne, il s'agit de nombres ayant une longueur fixe. Oracle utilise le type 13 lorsqu'une réponse `SYSDATE or CURRENT_DATE` est renvoyée.	BigQuery possède un format `DATE` distinct qui renvoie toujours une date au format ISO 8601. `DATE_FROM_UNIX_DATE` ne peut pas être utilisé, car il repose sur le nombre de secondes écoulées depuis le 1er janvier 1970.
`CURRENT_DATE-3`	Les valeurs de date sont représentées sous forme d'entiers. Oracle accepte les opérateurs arithmétiques pour les types de date.	Pour les types de date, utilisez `DATE_ADD`() ou `DATE_SUB`(). BigQuery utilise des opérateurs arithmétiques pour les types de données `INT64`, `NUMERIC` et `FLOAT64`.
`NLS_DATE_FORMAT`	Définissez le format de date système ou de session.	BigQuery utilise toujours la norme ISO 8601. Par conséquent, veillez à convertir les dates et heures Oracle.

Syntaxe des requêtes

Cette section traite des différences de syntaxe des requêtes entre Oracle et BigQuery.

Instructions `SELECT`

La plupart des instructions SELECT Oracle sont compatibles avec BigQuery.

Fonctions, opérateurs et expressions

Les sections suivantes répertorient les correspondances entre les fonctions Oracle et leurs équivalents dans BigQuery.

Opérateurs de comparaison

Les opérateurs de comparaison Oracle et BigQuery sont conformes à la norme ANSI SQL:2011. Les opérateurs de comparaison du tableau ci-dessous sont identiques dans BigQuery et Oracle. Vous pouvez utiliser REGEXP_CONTAINS au lieu de REGEXP_LIKE dans BigQuery.

Opérateur	Description
`"="`	Égal à
`<>`	Not Equal (Non égal à)
`!=`	Not Equal (Non égal à)
`>`	Supérieur à
`>=`	Supérieur ou égal à
`<`	Moins de
`<=`	Inférieur ou égal à
`IN ( )`	Correspond à une valeur dans une liste
`NOT`	Annule une condition
`BETWEEN`	Compris dans une plage (inclusive)
`IS NULL`	Valeur `NULL`
`IS NOT NULL`	Pas de valeur `NULL`
`LIKE`	Correspondance de modèles avec %
`EXISTS`	La condition est remplie si la sous-requête renvoie au moins une ligne

Les opérateurs de la table sont identiques dans BigQuery et Oracle.

Expressions et fonctions logiques

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)`

Fonctions d'agrégation

Le tableau suivant présente les mappages des fonctions Oracle d'agrégation, d'agrégation statistique et d'agrégation approximative courantes avec leurs équivalents dans BigQuery :

Oracle	BigQuery
`ANY_VALUE` (à partir d'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 n'est pas compatible avec les autres arguments définis par 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`	Opérateur NOT (PAS) au niveau du bit : ~
`BIT_OR`	`BIT_OR, X \| Y`
`BIT_XOR`	`BIT_XOR, X ^ Y`
`BITAND`	`BIT_AND, X & Y`
`CARDINALITY`	`COUNT`
`COLLECT`	BigQuery n'est pas compatible avec la clause `TYPE AS TABLE OF`. Songez à utiliser `STRING_AGG()` ou `ARRAY_AGG()` dans BigQuery.
`CORR/CORR_K/` `CORR_S`	`CORR`
`COUNT`	`COUNT`
`COVAR_POP`	`COVAR_POP`
`COVAR_SAMP`	`COVAR_SAMP`
`FIRST`	N'existe pas implicitement dans BigQuery. Envisagez d'utiliser des fonctions définies par l'utilisateur (UDF).
`GROUP_ID`	Non utilisé dans BigQuery
`GROUPING`	Non utilisé dans BigQuery
`GROUPING_ID`	Non utilisé dans BigQuery.
`LAST`	N'existe pas implicitement dans BigQuery. Envisagez d'utiliser des UDF.
`LISTAGG`	`STRING_AGG, ARRAY_CONCAT_AGG(expression [ORDER BY key [{ASC\|DESC}] [, ... ]] [LIMIT n])`
`MAX`	`MAX`
`MIN`	`MIN`
`OLAP_CONDITION`	Propre à Oracle, n'existe pas dans BigQuery.
`OLAP_EXPRESSION`	Propre à Oracle, n'existe pas dans BigQuery.
`OLAP_EXPRESSION_BOOL`	Propre à Oracle, n'existe pas dans BigQuery.
`OLAP_EXPRESSION_DATE`	Propre à Oracle, n'existe pas dans BigQuery.
`OLAP_EXPRESSION_TEXT`	Propre à Oracle, n'existe pas dans BigQuery.
`OLAP_TABLE`	Propre à Oracle, n'existe pas dans BigQuery.
`POWERMULTISET`	Propre à Oracle, n'existe pas dans BigQuery.
`POWERMULTISET_BY_CARDINALITY`	Propre à Oracle, n'existe pas dans BigQuery.
`QUALIFY`	Propre à Oracle, n'existe pas dans 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_exprdep_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 propose les fonctions d'agrégation supplémentaires suivantes :

Fonctions analytiques

Le tableau suivant présente les mappages des fonctions analytiques et des fonctions analytiques d'agrégation Oracle courantes avec leurs équivalents dans BigQuery.

Oracle	BigQuery
`AVG`	`AVG`
`BIT_COMPLEMENT`	Opérateur NOT (PAS) au niveau du bit : ~
`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`	Non compatible avec BigQuery. Envisagez d'utiliser un outil d'informatique décisionnelle ou une UDF personnalisée
`CUME_DIST`	`CUME_DIST`
`DENSE_RANK(ANSI)`	`DENSE_RANK`
`FEATURE_COMPARE`	N'existe pas implicitement dans BigQuery. Utiliser des fonctions définies par l'utilisateur et BigQuery ML
`FEATURE_DETAILS`	N'existe pas implicitement dans BigQuery. Utiliser des fonctions définies par l'utilisateur et BigQuery ML
`FEATURE_ID`	N'existe pas implicitement dans BigQuery. Utiliser des fonctions définies par l'utilisateur et BigQuery ML
`FEATURE_SET`	N'existe pas implicitement dans BigQuery. Utiliser des fonctions définies par l'utilisateur et BigQuery ML
`FEATURE_VALUE`	N'existe pas implicitement dans BigQuery. Utiliser des fonctions définies par l'utilisateur et BigQuery ML
`FIRST_VALUE`	`FIRST_VALUE`
`HIER_CAPTION`	Les requêtes hiérarchiques ne sont pas compatibles avec BigQuery.
`HIER_CHILD_COUNT`	Les requêtes hiérarchiques ne sont pas compatibles avec BigQuery.
`HIER_COLUMN`	Les requêtes hiérarchiques ne sont pas compatibles avec BigQuery.
`HIER_DEPTH`	Les requêtes hiérarchiques ne sont pas compatibles avec BigQuery.
`HIER_DESCRIPTION`	Les requêtes hiérarchiques ne sont pas compatibles avec BigQuery.
`HIER_HAS_CHILDREN`	Les requêtes hiérarchiques ne sont pas compatibles avec BigQuery.
`HIER_LEVEL`	Les requêtes hiérarchiques ne sont pas compatibles avec BigQuery.
`HIER_MEMBER_NAME`	Les requêtes hiérarchiques ne sont pas compatibles avec BigQuery.
`HIER_ORDER`	Les requêtes hiérarchiques ne sont pas compatibles avec BigQuery.
`HIER_UNIQUE_MEMBER_NAME`	Les requêtes hiérarchiques ne sont pas compatibles avec BigQuery.
`LAST_VALUE`	`LAST_VALUE`
`LAG`	`LAG`
`LEAD`	`LEAD`
`LISTAGG`	`ARRAY_AGG STRING_AGG ARRAY_CONCAT_AGG`
`MATCH_NUMBER`	La reconnaissance et le calcul de modèles peuvent être effectués avec des expressions régulières et des fonctions définies par l'utilisateur dans BigQuery.
`MATCH_RECOGNIZE`	La reconnaissance et le calcul de modèles peuvent être effectués avec des expressions régulières et des fonctions définies par l'utilisateur dans 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`	Propre à Oracle, n'existe pas dans BigQuery.
`PRESENTV`	Propre à Oracle, n'existe pas dans BigQuery.
`PREVIOUS`	Propre à Oracle, n'existe pas dans 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`	Vous pouvez utiliser des UDF.

Fonctions de date/heure

Le tableau suivant présente les mappages des fonctions de date/heure courantes d'Oracle et de leurs équivalents dans BigQuery.

Oracle	BigQuery
`ADD_MONTHS(date, integer)`	`DATE_ADD(date, INTERVAL integer MONTH),` Si la date est un `TIMESTAMP`, vous pouvez utiliser `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 n'est pas compatible avec le fuseau horaire de la base de données.
`EXTRACT`	`EXTRACT(DATE), EXTRACT(TIMESTAMP)`
`LAST_DAY`	`DATE_SUB( DATE_TRUNC( DATE_ADD( date_expression, INTERVAL 1 MONTH ), MONTH ), INTERVAL 1 DAY )`
`LOCALTIMESTAMP`	BigQuery n'accepte pas les paramètres de fuseau horaire.
`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`	Non compatible avec BigQuery. Envisagez d'utiliser une UDF personnalisée.
`WM_CONTAINS` `WM_EQUALS` `WM_GREATERTHAN` `WM_INTERSECTION` `WM_LDIFF` `WM_LESSTHAN` `WM_MEETS` `WM_OVERLAPS` `WM_RDIFF`	Les périodes ne sont pas utilisées dans BigQuery. Vous pouvez utiliser des UDF pour comparer deux points.

BigQuery propose les fonctions de date/heure supplémentaires suivantes :

Fonctions de chaîne

Le tableau suivant présente les mappages entre les fonctions de chaîne Oracle et leurs équivalents dans BigQuery :

Oracle	BigQuery
`ASCII`	`TO_CODE_POINTS(string_expr)[OFFSET(0)]`
`ASCIISTR`	BigQuery n'est pas compatible avec UTF-16
`RAWTOHEX`	`TO_HEX`
`LENGTH`	`CHAR_LENGTH`
`LENGTH`	`CHARACTER_LENGTH`
`CHR`	`CODE_POINTS_TO_STRING( [mod(numeric_expr, 256)] )`
`COLLATION`	N'existe pas dans BigQuery. BigQuery n'accepte pas la fonction COLLATE en LMD
`COMPOSE`	Fonction définie par l'utilisateur personnalisée.
`CONCAT, (\|\| operator)`	`CONCAT`
`DECOMPOSE`	Fonction définie par l'utilisateur personnalisée.
`ESCAPE_REFERENCE (UTL_I18N)`	Non compatible avec BigQuery. Envisagez d'utiliser une UDF.
`INITCAP`	`INITCAP`
`INSTR/INSTR2/INSTR4/INSTRB/INSTRC`	Fonction définie par l'utilisateur personnalisée.
`LENGTH/LENGTH2/LENGTH4/LENGTHB/LENGTHC`	`LENGTH`
`LOWER`	`LOWER`
`LPAD`	`LPAD`
`LTRIM`	`LTRIM`
`NLS_INITCAP`	Fonction définie par l'utilisateur personnalisée.
`NLS_LOWER`	`LOWER`
`NLS_UPPER`	`UPPER`
`NLSSORT`	Propre à Oracle, n'existe pas dans BigQuery.
`POSITION`	`STRPOS(string, substring)`
`PRINTBLOBTOCLOB`	Propre à Oracle, n'existe pas dans BigQuery.
`REGEXP_COUNT`	`ARRAY_LENGTH(REGEXP_EXTRACT_ALL(value, regex))`
`REGEXP_INSTR`	`STRPOS(source_string, REGEXP_EXTRACT(source_string, regexp_string))` Remarque : Renvoie la première occurrence.
`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`	Non compatible avec BigQuery. Envisagez d'utiliser une UDF personnalisée
`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`
`\|\|` (BARRES VERTICALES)	`CONCAT`

BigQuery propose les fonctions de chaîne supplémentaires suivantes :

Fonctions mathématiques

Le tableau suivant présente les mappages entre les fonctions mathématiques Oracle et leurs équivalents dans 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`	Utilisez cette option avec `ISNULL`.
`LOG`	`LOG`
`MOD (% operator)`	`MOD`
`POWER (** operator)`	`POWER, POW`
`DBMS_RANDOM.VALUE`	`RAND`
`RANDOMBYTES`	Non compatible avec BigQuery. Envisagez d'utiliser une UDF et une fonction RAND personnalisées
`RANDOMINTEGER`	`CAST(FLOOR(10*RAND()) AS INT64)`
`RANDOMNUMBER`	Non compatible avec BigQuery. Envisagez d'utiliser une UDF et une fonction RAND personnalisées
`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 propose les fonctions mathématiques supplémentaires suivantes :

Types de fonctions de conversion

Le tableau suivant présente les mappages entre les fonctions de conversion de type Oracle et leurs équivalents dans 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`	Aucune connaissance spécifique d'Oracle n'est requise.
`CONVERT`	BigQuery n'accepte pas les jeux de caractères. Envisagez d'utiliser une UDF personnalisée.
`EMPTY_BLOB`	`BLOB` n'est pas utilisé dans BigQuery.
`EMPTY_CLOB`	`CLOB` n'est pas utilisé dans BigQuery.
`FROM_TZ`	Les types avec fuseaux horaires ne sont pas acceptés dans BigQuery. Envisagez d'utiliser une UDF et FORMAT_TIMESTAMP
`INT_TO_BOOL`	`CAST`
`IS_BIT_SET`	N'existe pas implicitement dans BigQuery. Envisagez d'utiliser des UDF
`NCHR`	Les UDF peuvent être utilisées pour obtenir un équivalent de caractères binaires
`NUMTODSINTERVAL`	Le type de données `INTERVAL` n'est pas compatible avec BigQuery
`NUMTOHEX`	Non compatible avec BigQuery. Envisagez d'utiliser une UDF et une fonction `TO_HEX` personnalisées
`NUMTOHEX2`
`NUMTOYMINTERVAL`	Le type de données `INTERVAL` n'est pas compatible avec BigQuery.
`RAW_TO_CHAR`	Propre à Oracle, n'existe pas dans BigQuery.
`RAW_TO_NCHAR`	Propre à Oracle, n'existe pas dans BigQuery.
`RAW_TO_VARCHAR2`	Propre à Oracle, n'existe pas dans BigQuery.
`RAWTOHEX`	Propre à Oracle, n'existe pas dans BigQuery.
`RAWTONHEX`	Propre à Oracle, n'existe pas dans BigQuery.
`RAWTONUM`	Propre à Oracle, n'existe pas dans BigQuery.
`RAWTONUM2`	Propre à Oracle, n'existe pas dans BigQuery.
`RAWTOREF`	Propre à Oracle, n'existe pas dans BigQuery.
`REFTOHEX`	Propre à Oracle, n'existe pas dans BigQuery.
`REFTORAW`	Propre à Oracle, n'existe pas dans BigQuery.
`ROWIDTOCHAR`	`ROWID` est de type propre à Oracle et n'existe pas dans BigQuery. Cette valeur doit être représentée sous forme de chaîne.
`ROWIDTONCHAR`	`ROWID` est de type propre à Oracle et n'existe pas dans BigQuery. Cette valeur doit être représentée sous forme de chaîne.
`SCN_TO_TIMESTAMP`	`SCN` est de type propre à Oracle et n'existe pas dans BigQuery. Cette valeur doit être représentée sous forme d'horodatage.
`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 syntaxe "Cast" est utilisée dans une requête pour indiquer que le type de résultat d'une expression doit être converti dans un autre type.
`TREAT`	Propre à Oracle, n'existe pas dans BigQuery.
`VALIDATE_CONVERSION`	Non compatible avec BigQuery. Envisagez d'utiliser une UDF personnalisée
`VSIZE`	Non compatible avec BigQuery. Envisagez d'utiliser une UDF personnalisée

Fonctions JSON

Le tableau suivant présente les mappages entre les fonctions JSON Oracle et leurs équivalents dans BigQuery.

Oracle	BigQuery
`AS_JSON`	`TO_JSON_STRING(value[, pretty_print])`
`JSON_ARRAY`	Envisagez d'utiliser des UDF et la fonction `TO_JSON_STRING`
`JSON_ARRAYAGG`	Envisagez d'utiliser des UDF et la fonction `TO_JSON_STRING`
`JSON_DATAGUIDE`	Fonction définie par l'utilisateur personnalisée.
`JSON_EQUAL`	Fonction définie par l'utilisateur personnalisée.
`JSON_EXIST`	Envisagez d'utiliser des UDF, ainsi que `JSON_EXTRACT` ou `JSON_EXTRACT_SCALAR`
`JSON_MERGEPATCH`	Fonction définie par l'utilisateur personnalisée.
`JSON_OBJECT`	Non compatible avec BigQuery.
`JSON_OBJECTAGG`	Non compatible avec BigQuery.
`JSON_QUERY`	Envisagez d'utiliser des UDF, ainsi que `JSON_EXTRACT` ou `JSON_EXTRACT_SCALAR`.
`JSON_TABLE`	Fonction définie par l'utilisateur personnalisée.
`JSON_TEXTCONTAINS`	Envisagez d'utiliser des UDF, ainsi que `JSON_EXTRACT` ou `JSON_EXTRACT_SCALAR`.
`JSON_VALUE`	`JSON_EXTRACT_SCALAR`

Fonctions XML

BigQuery ne fournit pas de fonctions XML implicites. Le code XML peut être chargé dans BigQuery en tant que chaîne, et les UDF peuvent être utilisées pour analyser le code XML. Le traitement XML peut également être effectué à l'aide d'un outil ETL/ELT tel que Dataflow. La liste suivante répertorie les fonctions XML d'Oracle :

Oracle	BigQuery
`DELETEXML`	Les UDF BigQuery ou un outil ETL comme Dataflow peuvent être utilisés pour traiter le format 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`

Fonctions de machine learning

Les fonctions de machine learning (ML) d'Oracle et de BigQuery sont différentes. Oracle nécessite un pack d'analyse avancée et des licences pour effectuer du ML sur la base de données. Oracle utilise le package DBMS_DATA_MINING pour le ML. Pour convertir des tâches de minage de données Oracle, vous devez réécrire le code. Vous avez le choix entre des solutions de produits d'IA Google complètes telles que BigQuery ML et les API d'IA, notamment Speech-to-Text, Text-to-Speech, Dialogflow, Cloud Translation, NLP, Cloud Vision et API Timeseries Insights, AutoML, AutoML Tables ou AI Platform. Les notebooks gérés par l'utilisateur de Google peuvent être utilisés comme environnement de développement pour les data scientists et Google AI Platform Training pour exécuter des tâches d'entraînement et l'évaluation des charges de travail à grande échelle. Le tableau suivant présente les fonctions ML d'Oracle :

Oracle	BigQuery
`CLASSIFIER`	Consultez la page BigQuery ML pour découvrir les options de classificateur et de régression de machine learning.
`CLUSTER_DETAILS`
`CLUSTER_DISTANCE`
`CLUSTER_ID`
`CLUSTER_PROBABILITY`
`CLUSTER_SET`
`PREDICTION`
`PREDICTION_BOUNDS`
`PREDICTION_COST`
`PREDICTION_DETAILS`
`PREDICTION_PROBABILITY`
`PREDICTION_SET`

Fonctions de sécurité

Le tableau suivant présente les fonctions permettant d'identifier l'utilisateur dans Oracle et BigQuery :

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

Fonctions d'ensembles ou de tableaux

Le tableau suivant présente les fonctions d'ensembles ou de tableaux dans Oracle et leurs équivalents dans BigQuery :

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

Fonctions de fenêtrage

Le tableau suivant présente les fonctions de fenêtrage dans Oracle et leurs équivalents dans BigQuery.

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

Requêtes hiérarchiques ou récursives

Les requêtes hiérarchisées ou récursives ne sont pas utilisées dans BigQuery. Si la profondeur de la hiérarchie est connue, une fonctionnalité similaire peut être obtenue avec des jointures, comme illustré dans l'exemple suivant. Une autre solution consiste à utiliser l'API BigQueryStorage et 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

Le tableau suivant présente les fonctions hiérarchiques dans Oracle.

Oracle	BigQuery
`DEPTH`	Les requêtes hiérarchiques ne sont pas utilisées dans BigQuery.
`PATH`
`SYS_CONNECT_BY_PATH (hierarchical)`

Fonctions UTL

Le package UTL_File est principalement utilisé pour lire et écrire les fichiers du système d'exploitation à partir de PL/SQL. Cloud Storage peut être utilisé pour tout type de préproduction de fichiers bruts. Les tables externes ainsi que les opérations de chargement et d'exportation BigQuery doivent être utilisées pour lire et écrire des fichiers dans et depuis Cloud Storage. Pour en savoir plus, consultez la page Présentation des sources de données externes.

Fonctions spatiales

Vous pouvez remplacer les fonctionnalités spatiales à l'aide des analyses géospatiales BigQuery. Oracle propose des fonctions et des types SDO_* tels que SDO_GEOM_KEY, SDO_GEOM_MBR et SDO_GEOM_MMB. Ces fonctions sont utilisées pour l'analyse spatiale. Vous pouvez utiliser les analyses géospatiales pour effectuer des analyses spatiales.

Syntaxe LMD

Cette section traite des différences de syntaxe du langage de manipulation de données entre Oracle et BigQuery.

Instruction `INSERT`

La plupart des instructions INSERT Oracle sont compatibles avec BigQuery. Le tableau suivant présente les exceptions.

Les scripts LMD dans BigQuery présentent une sémantique de cohérence légèrement différente de celle des instructions équivalentes dans Oracle. Pour obtenir une présentation de l'isolation d'instantané et de la gestion des sessions et des transactions, consultez la section CREATE [UNIQUE] INDEX section plus loin dans ce document.

Oracle BigQuery

Oracle	BigQuery
`INSERT INTO table VALUES (...);`	`INSERT INTO table (...) VALUES (...);` Teradata propose un mot clé `DEFAULT` pour les colonnes n'autorisant pas les valeurs nulles. Remarque : Dans BigQuery, l'omission des noms de colonnes dans l'instruction `INSERT` ne fonctionne que si les valeurs de toutes les colonnes de la table cible sont incluses dans l'ordre croissant en fonction de leurs positions 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 impose des quotas DML qui limitent le nombre d'instructions DML que vous pouvez exécuter quotidiennement. Pour utiliser au mieux votre quota, envisagez les approches suivantes : Combinez plusieurs lignes en une seule instruction `INSERT` au lieu d'avoir une ligne par opération `INSERT`. Combinez plusieurs instructions LMD (y compris `INSERT`) à l'aide d'une instruction `MERGE`. Utilisez `CREATE TABLE ... AS SELECT` pour créer et remplir des tables.

INSERT INTO table VALUES (...);

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

Teradata propose un mot clé DEFAULT pour les colonnes n'autorisant pas les valeurs nulles.

Remarque : Dans BigQuery, l'omission des noms de colonnes dans l'instruction INSERT ne fonctionne que si les valeurs de toutes les colonnes de la table cible sont incluses dans l'ordre croissant en fonction de leurs positions 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 impose des quotas DML qui limitent le nombre d'instructions DML que vous pouvez exécuter quotidiennement. Pour utiliser au mieux votre quota, envisagez les approches suivantes :

Combinez plusieurs lignes en une seule instruction INSERT au lieu d'avoir une ligne par opération INSERT.
Combinez plusieurs instructions LMD (y compris INSERT) à l'aide d'une instruction MERGE.
Utilisez CREATE TABLE ... AS SELECT pour créer et remplir des tables.

Instruction `UPDATE`

Les instructions UPDATE Oracle sont généralement compatibles avec BigQuery. Toutefois, dans BigQuery, l'instruction UPDATE doit comporter une clause WHERE.

Nous vous recommandons de privilégier les instructions LMD par lots plutôt que plusieurs instructions UPDATE et INSERT uniques. Les scripts LMD dans BigQuery présentent une sémantique de cohérence légèrement différente de celle des instructions équivalentes dans Oracle. Pour obtenir une présentation de l'isolation d'instantané et de la gestion des sessions et des transactions, consultez la section CREATE INDEX dans ce document.

Le tableau suivant présente les instructions UPDATE Oracle et les instructions BigQuery qui effectuent les mêmes tâches.

Dans BigQuery, l'instruction UPDATE doit comporter une clause WHERE. Pour en savoir plus sur UPDATE dans BigQuery, consultez les exemples UPDATE BigQuery dans la documentation sur le LMD.

Instructions `DELETE` et `TRUNCATE`

Les instructions DELETE et TRUNCATE permettent de supprimer des lignes d'une table sans que cela n'affecte son schéma. TRUNCATE n'est pas utilisé dans BigQuery. Cependant, vous pouvez utiliser les instructions DELETE pour obtenir le même effet.

Dans BigQuery, l'instruction DELETE doit comporter une clause WHERE. Pour en savoir plus sur l'instruction DELETE dans BigQuery, consultez les exemples d'instructions DELETE BigQuery dans la documentation sur le LMD.

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

Instruction `MERGE`

L'instruction MERGE peut combiner les opérations INSERT, UPDATE et DELETE en une seule instruction UPSERT et effectuer les opérations de manière atomique. L'opération MERGE doit correspondre à une ligne source au maximum pour chaque ligne cible. BigQuery et Oracle suivent tous deux la syntaxe ANSI.

Toutefois, les scripts LMD dans BigQuery présentent une sémantique de cohérence légèrement différente de celle des instructions équivalentes dans Oracle.

Syntaxe LDD

Cette section traite des différences de syntaxe du langage de définition de données entre Oracle et BigQuery.

Instruction `CREATE TABLE`

La plupart des instructions Oracle CREATE TABLE sont compatibles avec BigQuery, à l'exception des contraintes et des éléments de syntaxe suivants, qui ne sont pas utilisés dans BigQuery :

STORAGE
TABLESPACE
DEFAULT
GENERATED ALWAYS AS
ENCRYPT
PRIMARY KEY (col, ...). Pour en savoir plus, consultez la page sur CREATE INDEX.
UNIQUE INDEX. Pour en savoir plus, consultez la page sur CREATE INDEX.
CONSTRAINT..REFERENCES
DEFAULT
PARALLEL
COMPRESS

Pour en savoir plus sur CREATE TABLE dans BigQuery, consultez les exemples de CREATE TABLE BigQuery.

Attributs et options de colonne

Les colonnes d'identité sont introduites avec la version Oracle 12c, qui permet l'auto-incrémentation d'une colonne. Cette méthode n'est pas utilisée dans BigQuery. Elle peut être obtenue par traitement par le lot suivant. Pour en savoir plus sur les clés de substitution et les dimensions à évolution lente (SCD, Slowly Changing Dimensions), consultez les guides suivants :

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`

Commentaires sur la colonne

Oracle utilise la syntaxe Comment pour ajouter des commentaires aux colonnes. Cette fonctionnalité peut être mise en œuvre d'une manière similaire dans BigQuery à l'aide de la description de colonne, comme indiqué dans le tableau suivant :

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

Tables temporaires

Oracle accepte les tables temporaires, qui sont souvent utilisées pour stocker des résultats intermédiaires dans des scripts. Les tables temporaires sont acceptées dans 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;`

Les éléments Oracle suivants ne sont pas utilisés dans BigQuery :

ON COMMIT DELETE ROWS;
ON COMMIT PRESERVE ROWS;

Il existe également d'autres moyens d'émuler des tables temporaires dans BigQuery :

Valeur TTL de l'ensemble de données : créez un ensemble de données ayant une durée de vie courte (par exemple, 1 heure) afin que les tables créées dans cet ensemble de données soient effectivement temporaires, car elles ne persisteront pas au-delà de la durée de vie d'un script. Vous pouvez ajouter le préfixe temp à tous les noms de tables de cet ensemble de données pour indiquer clairement que les tables sont temporaires.
Valeur TTL de la table : créez une table ayant une durée de vie courte à l'aide d'instructions LDD semblables à ce qui suit :
```
CREATE TABLE temp.name (col1, col2, ...)

OPTIONS(expiration_timestamp=TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR));
```
Clause WITH : si une table temporaire n'est nécessaire que dans le même bloc, utilisez un résultat temporaire à l'aide d'une sous-requête ou d'une instruction WITH.

Instruction `CREATE SEQUENCE`

Les séquences ne sont pas utilisées dans BigQuery. Pour ce faire, vous pouvez utiliser le traitement par le lot suivant. Pour en savoir plus sur les clés de substitution et les dimensions à évolution lente (SCD), consultez les guides suivants :

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

Instruction `CREATE VIEW`

Le tableau suivant présente les équivalences entre Oracle et BigQuery pour l'instruction CREATE VIEW.

Oracle	BigQuery	Remarques
`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 ...`
Non compatible	`CREATE VIEW IF NOT EXISTS` `view_name` `OPTIONS(view_option_list)` `AS SELECT ...`	Crée une vue uniquement si la vue n'existe pas dans l'ensemble de données spécifié.

Instruction `CREATE MATERIALIZED VIEW`

Dans les vues matérialisées BigQuery, les opérations d'actualisation sont effectuées automatiquement. Il n'est pas nécessaire de spécifier des options d'actualisation (par exemple, lors d'un commit ou d'une programmation). Pour plus d'informations, consultez la page Présentation des vues matérialisées.

Si la table de base ne cesse d'être modifiée par des ajouts, la requête qui utilise la vue matérialisée (qu'elle soit explicitement référencée ou sélectionnée par l'optimiseur de requêtes) analyse toutes les vues matérialisées plus un delta dans la table de base depuis la dernière actualisation de la vue. Résultat : les requêtes sont plus rapides et moins coûteuses.

En revanche, en cas de mises à jour (LMD UPDATE / MERGE) ou de suppressions (LMD DELETE, troncation ou expiration de la partition) dans la table de base depuis la dernière actualisation de la vue, la vue matérialisée n'est pas analysée. Par conséquent, les requêtes ne sont pas enregistrées jusqu'à la prochaine actualisation de la vue. En effet, toute modification ou suppression effectuée dans la table de base invalide l'état de la vue matérialisée.

De plus, les données du tampon d'insertion en flux continu de la table de base ne sont pas enregistrées dans la vue matérialisée. Le tampon de streaming est toujours entièrement analysé, qu'une vue matérialisée soit utilisée ou non.

Le tableau suivant présente les équivalences entre Oracle et BigQuery pour l'instruction CREATE MATERIALIZED VIEW.

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

Instruction `CREATE [UNIQUE] INDEX`

Cette section décrit les méthodes dans BigQuery permettant de créer des fonctionnalités semblables aux index dans Oracle.

Indexation à des fins de performances

BigQuery n'a pas besoin d'index explicites, car il s'agit d'une base de données orientée colonnes avec optimisation des requêtes et du stockage. BigQuery fournit des fonctionnalités telles que le partitionnement et le clustering, ainsi que des champs imbriqués, qui peuvent améliorer l'efficacité et les performances des requêtes en optimisant le stockage des données.

Indexation à des fins de cohérence (UNIQUE, PRIMARY INDEX)

Dans Oracle, un index unique peut être utilisé pour empêcher que des lignes contiennent des clés non uniques dans une table. Si un processus tente d'insérer ou de mettre à jour des données ayant une valeur figurant déjà dans l'index, l'opération échoue avec une violation d'index.

Comme BigQuery ne fournit pas d'index explicites, une instruction MERGE peut être utilisée à la place pour insérer uniquement des enregistrements uniques dans une table cible à partir d'une table intermédiaire tout en supprimant les enregistrements en double. Cependant, il est impossible d'empêcher un utilisateur disposant de droits de modification d'insérer un enregistrement en double.

Pour générer une erreur liée à des enregistrements en double dans BigQuery, vous pouvez utiliser une instruction MERGE à partir de la table intermédiaire, comme indiqué dans l'exemple suivant :

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

Le plus souvent, les utilisateurs préfèrent supprimer les doubles indépendamment afin de détecter les erreurs dans les systèmes en aval.

BigQuery n'est pas compatible avec les colonnes DEFAULT et IDENTITY (séquences).

Verrouillage

BigQuery ne dispose pas d'un mécanisme de verrouillage comme celui d'Oracle et peut exécuter des requêtes simultanées (jusqu'à votre quota). Seules les instructions LMD sont soumises à certaines limites de simultanéité et peuvent nécessiter un verrouillage de la table pendant l'exécution dans certains cas.

Instructions SQL procédurales

Cette section explique comment convertir les instructions SQL procédurales utilisées dans des procédures stockées, des fonctions et des déclencheurs d'Oracle en BigQuery.

Instruction `CREATE PROCEDURE`

La procédure stockée est compatible avec la version bêta des scripts BigQuery.

Oracle	BigQuery	Remarques
`CREATE PROCEDURE`	`CREATE PROCEDURE`	Comme Oracle, BigQuery accepte les modes d'argument `IN, OUT, INOUT`. Les autres spécifications de syntaxe ne sont pas acceptées dans BigQuery.
`CREATE OR REPLACE PROCEDURE`	`CREATE OR REPLACE PROCEDURE`
`CALL`	`CALL`

Les sections suivantes décrivent comment convertir des instructions procédurales Oracle existantes en instructions de script BigQuery ayant des fonctionnalités similaires.

Instruction `CREATE TRIGGER`

Les déclencheurs ne sont pas utilisés dans BigQuery. La logique d'application basée sur les lignes doit être gérée sur la couche d'application. Vous pouvez déclencher des fonctionnalités à l'aide de l'outil d'ingestion, de Pub/Sub et/ou de Cloud Functions pendant l'ingestion ou à l'aide d'analyses régulières.

Déclaration et attribution de variables

Le tableau suivant présente les instructions DECLARE Oracle et leurs équivalents dans 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;`

Déclarations et opérations de curseurs

BigQuery n'étant pas compatible avec les curseurs, les instructions suivantes ne sont pas utilisées :

DECLARE cursor_name CURSOR [FOR | WITH] ...
OPEN CUR_VAR FOR sql_str;
OPEN cursor_name [USING var, ...];
FETCH cursor_name INTO var, ...;
CLOSE cursor_name;

Instructions SQL dynamiques

L'instruction SQL dynamique Oracle suivante et son équivalent BigQuery :

Oracle	BigQuery
`EXECUTE IMMEDIATE sql_str [USING IN OUT [, ...]];`	`EXECUTE IMMEDIATE sql_expression [INTO variable[, ...]] [USING identifier[, ...]]; ;`

Instructions de flux de contrôle

Le tableau suivant présente les instructions de flux de contrôle Oracle et leurs équivalents dans 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` n'est pas utilisé dans BigQuery. Utilisez d'autres instructions `LOOP`.
`BREAK`	`BREAK`
`CONTINUE`	`CONTINUE`
`CONTINUE/EXIT WHEN`	Utilisez `CONTINUE` avec une condition `IF`.
`GOTO`	L'instruction `GOTO` n'existe pas dans BigQuery. Utilisez la condition `IF`.

Instructions SQL de métadonnées et de transactions

Oracle	BigQuery
`GATHER_STATS_JOB`	Non utilisé dans BigQuery pour le moment.
`LOCK TABLE table_name IN [SHARE/EXCLUSIVE] MODE NOWAIT;`	Non utilisé dans BigQuery pour le moment.
`Alter session set isolation_level=serializable; /` `SET TRANSACTION ...`	BigQuery utilise toujours l'isolation d'instantané. Pour plus d'informations, consultez la section Garanties de cohérence et isolation de transaction dans ce document.
`EXPLAIN PLAN ...`	Non utilisé dans BigQuery. L'explication du plan de requête dans l'interface utilisateur Web de BigQuery et l'allocation d'emplacements, ainsi que la journalisation d'audit dans Stackdriver, sont des fonctionnalités similaires.
`SELECT * FROM DBA_[*];` (vues Oracle DBA_/ALL_/V$)	`SELECT * FROM mydataset.INFORMATION_SCHEMA.TABLES;` Pour en savoir plus, consultez la page Présentation d'INFORMATION_SCHEMA de BigQuery.
`SELECT * FROM GV$SESSION;` `SELECT * FROM V$ACTIVE_SESSION_HISTORY;`	BigQuery ne dispose pas du concept de session traditionnel. Vous pouvez afficher les tâches de requête dans l'interface utilisateur ou exporter les journaux d'audit Stackdriver vers BigQuery et analyser les journaux BigQuery pour les analyser. Pour en savoir plus, consultez Afficher les détails de la tâche.
`START TRANSACTION;` `LOCK TABLE table_A IN EXCLUSIVE MODE NOWAIT;` `DELETE FROM table_A;` `INSERT INTO table_A SELECT * FROM table_B;` `COMMIT;`	Le remplacement du contenu d'une table par un résultat de requête équivaut à une transaction. Pour ce faire, vous pouvez utiliser une opération de requête ou une opération de copie. Utiliser une requête : `bq query --replace --destination_table table_A 'SELECT * FROM table_B';` Utiliser une copie : `bq cp -f table_A table_B`

Instructions SQL multi-instructions et multilignes

Oracle et BigQuery acceptent les transactions (sessions) et donc les instructions séparées par un point-virgule qui sont systématiquement exécutées ensemble. Pour plus d'informations, consultez la section Transactions multi-instructions.

Codes et messages d'erreur

Les codes d'erreur Oracle et les codes d'erreur BigQuery sont différents. Si votre logique d'application détecte actuellement les erreurs, essayez d'éliminer la source de l'erreur, car BigQuery ne renvoie pas les mêmes codes d'erreur.

Garanties de cohérence et isolation de transaction

Oracle et BigQuery sont tous deux atomiques, c'est-à-dire conformes à la norme ACID au niveau de chaque mutation sur de nombreuses lignes. Par exemple, une opération MERGE est atomique, même avec plusieurs valeurs insérées et mises à jour.

Transactions

Oracle fournit des niveaux d'isolation des transactions Read Committed (lecture des données validées) ou Serializable (sérialisable). Les interblocages sont possibles. Les jobs d'insertion d'ajout Oracle s'exécutent indépendamment.

BigQuery est également compatible avec les transactions. BigQuery permet d'assurer un contrôle de simultanéité optimiste (le premier à effectuer un commit l'emporte) avec isolation d'instantané, où une requête lit les dernières données validées avant le démarrage de la requête. Cette approche garantit le même niveau de cohérence par ligne, par mutation et entre les lignes d'une même instruction LMD, tout en évitant les interblocages. Si plusieurs instructions UPDATE sont effectuées sur la même table, BigQuery bascule vers le contrôle de simultanéité pessimiste et met en file d'attente plusieurs instructions UPDATE, en effectuant automatiquement de nouvelles tentatives en cas de conflits. Les instructions LMD INSERT et les jobs de chargement peuvent s'exécuter simultanément et indépendamment pour ajouter des données aux tables.

Rollback

Oracle est compatible avec les rollbacks. Comme il n'existe pas de limite de transaction explicite dans BigQuery, il n'existe pas de concept de rollback explicite dans BigQuery. Les solutions de contournement sont des décorateurs de table ou l'utilisation de FOR SYSTEM_TIME AS OF.

Limites des bases de données

Vérifiez les derniers quotas et limites BigQuery. Les utilisateurs ayant un volume de requêtes important peuvent demander l'augmentation de nombreux quotas en contactant le Cloud Customer Care. Le tableau suivant présente une comparaison des limites de base de données pour Oracle et BigQuery.

Limite	Oracle	BigQuery
Tables par base de données	Pas de restriction	Pas de restriction
Colonnes par table	1000	10 000
Taille maximale des lignes	Illimité (dépend du type de colonne)	100 Mo
Longueur des noms de colonnes et de tables	Si v12.2>= 128 octets Sinon 30 octets	16 384 caractères Unicode
Nombre de lignes par table	Illimité	Illimité
Longueur maximale des requêtes SQL	Illimité	1 Mo (longueur maximale des requêtes GoogleSQL non résolues) 12 Mo (longueur maximale des requêtes résolues en ancien SQL et en GoogleSQL) Flux : 10 Mo (taille maximale des requêtes HTTP) 10 000 (nombre maximal de lignes par requête)
Taille maximale des requêtes et des réponses	Illimité	10 Mo (requête) et 10 Go (réponse), ou presque illimitée si vous utilisez la pagination ou l'API Cloud Storage
Nombre maximal de sessions simultanées	Limité par les paramètres de sessions ou de processus	100 requêtes simultanées (ce nombre peut être augmenté avec une réservation d'emplacement), 300 requêtes API simultanées par utilisateur
Nombre maximal de chargements (rapides) simultanés	Limité par les paramètres de sessions ou de processus	Aucune limite de simultanéité ; les tâches sont mises en file d'attente. 100 000 tâches de chargement par projet et par jour

D'autres limites de la base de données Oracle incluent les limites de types de données, les limites de bases de données physiques, les limites de bases de données logiques et les limites de processus et d'exécution.