bigquery-migration-sql-translator

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

BigQuery Migration Service (BQMS) SQL Translator

The BigQuery Migration Service (BQMS) translates legacy database SQL scripts, queries, and schemas into GoogleSQL. This skill coordinates translation workflows, Cloud Storage staging, compiler error triage, and YAML configuration.

BigQuery Migration Service (BQMS) 将传统数据库的 SQL 脚本、查询和 schema 翻译为 GoogleSQL。该 skill 协调翻译工作流、Cloud Storage 暂存、编译错误排查和 YAML 配置。

Before you begin

开始之前

Before translating queries or schemas, verify the following prerequisites:

Google Cloud SDK & Project Setup: Ensure the Google Cloud SDK is installed, verify that your Google Cloud project has an active Cloud Billing account attached, and select the target project:
bash
```
gcloud config set project {project_id}
```

Enable the API: Enable the BigQuery Migration API (

bigquerymigration.googleapis.com

) in your Google Cloud project:

bash

gcloud services enable bigquerymigration.googleapis.com

Required IAM Roles: Verify that your identity or service account has:
- ```
roles/mcp.toolUser
```
  (MCP Tool User)
- ```
roles/bigquerymigration.editor
```
  (Migration Workflow Editor)
- For batch translation,
```
roles/storage.objectViewer
```
  and
```
roles/storage.objectCreator
```
  (or
```
roles/storage.objectAdmin
```
  ) on the Cloud Storage buckets that hold the input and output files.
MCP Server Connection: If BigQuery Migration Service (BQMS) tools (e.g.
```
translate_query
```
,
```
translate_batch_queries
```
) are not present in your active tool list, configure the remote BigQuery Migration Service (BQMS) MCP server. For setup instructions across clients (Claude, Cursor, Gemini CLI, VS Code), see mcp_config.md.
Cost & Cloud Storage Cleanup: Review Google Cloud Pricing for Cloud Storage and BigQuery usage details. After completing a batch migration, clean up temporary staged input and output folders in Cloud Storage:
bash
```
gcloud storage rm -r gs://{bucket}/{folder}
```
Translation Tracking: For batch translations, and for queries that need more than one translation iteration, keep a translation tracker (e.g.
```
translation_tracker.md
```
) to document goals, planned steps, and progress. After each translation, record one row with this template:
Iteration Status Total Errors Correctness Errors Completeness Errors Compatibility Errors Key Actions / Transformations

A single query that translates cleanly on the first attempt needs no tracker: report its translation ID and logs in your response.

在翻译查询或 schema 之前，请验证以下先决条件：

Google Cloud SDK 与项目设置：确保已安装 Google Cloud SDK，验证 Google Cloud project 已关联处于启用状态的 Cloud Billing account，并选择目标 project：
bash
```
gcloud config set project {project_id}
```

启用 API：在 Google Cloud project 中启用 BigQuery Migration API（

bigquerymigration.googleapis.com

）：

bash

gcloud services enable bigquerymigration.googleapis.com

必需的 IAM Roles：验证你的身份或 service account 是否拥有：
- ```
roles/mcp.toolUser
```
  （MCP Tool User）
- ```
roles/bigquerymigration.editor
```
  （Migration Workflow Editor）
- 对于 batch translation，需要对存放输入和输出文件的 Cloud Storage buckets 拥有
```
roles/storage.objectViewer
```
  和
```
roles/storage.objectCreator
```
  （或
```
roles/storage.objectAdmin
```
  ）。
MCP Server 连接：如果当前 tool 列表中没有 BigQuery Migration Service (BQMS) tools（例如
```
translate_query
```
、
```
translate_batch_queries
```
），请配置远程 BigQuery Migration Service (BQMS) MCP server。有关各客户端（Claude、Cursor、Gemini CLI、VS Code）的设置说明，请参阅 mcp_config.md。
成本与 Cloud Storage 清理：请查看 Google Cloud Pricing，了解 Cloud Storage 和 BigQuery 的使用详情。完成 batch migration 后，清理 Cloud Storage 中临时暂存的输入和输出文件夹：
bash
```
gcloud storage rm -r gs://{bucket}/{folder}
```
翻译跟踪：对于 batch translations，以及需要多次翻译迭代的 queries，请维护一个 translation tracker（例如
```
translation_tracker.md
```
），记录目标、计划步骤和进度。每次翻译后，使用以下模板记录一行：
Iteration Status Total Errors Correctness Errors Completeness Errors Compatibility Errors Key Actions / Transformations

如果单条查询首次翻译即顺利完成，则无需 tracker：在回复中报告其 translation ID 和 logs。

Workflow Selection

工作流选择

Choose the workflow based on your migration scope:

Interactive Translation (Single Query): Best for ad-hoc queries, exploratory testing, dialect syntax comparison, or quick error debugging.
Batch Translation (Multiple Files & Cloud Storage): Use for more than one file or a directory, including SQL embedded in application code (extract it into
```
.sql
```
files first). For multi-file Python codebases containing embedded SQL, use python_embedded_sql_migrator_template.py to extract queries into staged files and re-inject translated SQL. Batch translation is faster and cheaper than translating files one by one, and it resolves cross-file dependencies, so it usually gives better results. Run
```
translate_batch_queries
```
on the staged files first; use
```
translate_query
```
only afterwards if needed to debug a specific statement from
```
translation_report.csv
```
.

根据迁移范围选择工作流：

交互式翻译（单条查询）：最适合临时查询、探索性测试、dialect 语法比较或快速错误调试。
Batch Translation（多个文件与 Cloud Storage）：适用于多个文件或目录，包括嵌在应用程序代码中的 SQL（请先将其提取到
```
.sql
```
文件中）。对于包含嵌入式 SQL 的多文件 Python codebase，请使用 python_embedded_sql_migrator_template.py 将查询提取到暂存文件中，并重新注入翻译后的 SQL。Batch translation 比逐个翻译文件更快、更便宜，而且能够解决跨文件依赖，因此通常能获得更好的结果。首先对暂存文件运行
```
translate_batch_queries
```
；仅在之后需要调试
```
translation_report.csv
```
中的特定语句时，才使用
```
translate_query
```
。

1. Interactive Translation Workflow

1. 交互式翻译工作流

Use the interactive workflow to translate a single query string, inspect compiler logs, and iteratively resolve issues.

使用交互式工作流翻译单条 query string、检查编译器日志，并迭代解决问题。

Steps

步骤

Submit Query (
translate_query
): Call
```
translate_query
```
with
```
projectNumber
```
,
```
location
```
,
```
inputQuery
```
,
```
sourceDialect
```
, and
```
targetDialect
```
(
```
BigQuery
```
). Include optional parameters:
- ```
metadataFilePath
```
  : Cloud Storage URI to a metadata zip file (
```
gs://.../metadata.zip
```
  ) for schema resolution.
- ```
translationConfigs
```
  : Inline YAML configurations (e.g. object renaming, schema redirection, optimizer rules). Show the YAML you used in your response so the user can reuse it (e.g. in batch translation).
Poll Status (
get_translation
): If the returned
```
translation_state
```
is
```
RUNNING
```
or
```
PENDING
```
, poll
```
get_translation
```
using the
```
translation
```
ID,
```
projectNumber
```
, and
```
location
```
until
```
translation.state
```
is
```
SUCCEEDED
```
or
```
FAILED
```
, at the interval given in the BigQuery Migration Service (BQMS) MCP tool descriptions. While the job runs, do work that doesn't need the result (e.g. read the dialect gotchas reference).
Inspect Output & Logs:
- Examine
```
translated_query
```
  for the converted GoogleSQL.
- Review each entry in
```
translation_logs
```
  : inspect
```
severity
```
  (
```
ERROR
```
  ,
```
WARNING
```
  ),
```
category
```
  (e.g.
```
RelationNotFound
```
  ), and
```
effect
```
  (
```
CORRECTNESS
```
  ,
```
COMPLETENESS
```
  ,
```
COMPATIBILITY
```
  ).
- Check the SQL itself, not only the logs: BigQuery Migration Service (BQMS) emits
```
ERROR_TYPE(...)
```
  for types it cannot map, sometimes with no log entry. Treat any
```
ERROR_TYPE
```
  or inline error comment as an error, and when a BigQuery project is available, dry-run the result (
```
bq query --dry_run --use_legacy_sql=false
```
  ). A
```
Not found
```
  or
```
must be qualified with a dataset
```
  error still means the SQL is syntactically valid; the referenced objects just don't exist in BigQuery yet. Say so and move on, even if the error suggests a fix: don't stub tables or change the SQL or
```
bq
```
  flags to get past it.
- A
```
NoSuchFunction
```
  error means BigQuery Migration Service (BQMS) copied that call unchanged, sometimes with the function name in backticks. Treat it as untranslated even if BigQuery has a function with that name: a dry run that stops at missing tables doesn't check it.
- If the source dialect has a gotchas reference (see Dialect-Specific Gotchas), read it and check the output for the patterns it lists. Some semantic differences produce no log entry and still pass a dry run.
Iterate Until Clean: If the logs contain errors or warnings, the translated SQL contains
```
ERROR_TYPE
```
or inline error comments, the dry run fails, or the output matches a dialect gotcha, resolve the issues as described in Resolving Translation Issues and re-translate.
Explain & Compare Differences (
explain_translation
): When requested to explain a translation, compare syntax differences, or understand how specific query logic was converted, call
```
explain_translation
```
with
```
translation
```
(the translation ID),
```
projectNumber
```
, and
```
location
```
. This returns a structured explanation of the query's purpose and a detailed breakdown of syntax, function, and behavioral differences between the source query and the translated GoogleSQL. The explanation doesn't validate the output, so check the translation as in step 3 rather than relying on it.

提交查询（
translate_query
）：调用
```
translate_query
```
，传入
```
projectNumber
```
、
```
location
```
、
```
inputQuery
```
、
```
sourceDialect
```
和
```
targetDialect
```
（
```
BigQuery
```
）。可选择包含以下参数：
- ```
metadataFilePath
```
  ：metadata zip 文件的 Cloud Storage URI（
```
gs://.../metadata.zip
```
  ），用于解析 schema。
- ```
translationConfigs
```
  ：内联 YAML 配置（例如对象重命名、schema 重定向、optimizer rules）。在回复中展示你使用的 YAML，以便用户复用（例如用于 batch translation）。
轮询状态（
get_translation
）：如果返回的
```
translation_state
```
为
```
RUNNING
```
或
```
PENDING
```
，请使用 translation ID、
```
projectNumber
```
和
```
location
```
轮询
```
get_translation
```
，直至
```
translation.state
```
变为
```
SUCCEEDED
```
或
```
FAILED
```
；轮询间隔应遵循 BigQuery Migration Service (BQMS) MCP tool descriptions 中的规定。作业运行期间，可处理不需要结果的工作（例如阅读 dialect gotchas reference）。
检查输出与日志：
- 检查
```
translated_query
```
  中的转换后 GoogleSQL。
- 审查
```
translation_logs
```
  中的每一条记录：检查
```
severity
```
  （
```
ERROR
```
  、
```
WARNING
```
  ）、
```
category
```
  （例如
```
RelationNotFound
```
  ）和
```
effect
```
  （
```
CORRECTNESS
```
  、
```
COMPLETENESS
```
  、
```
COMPATIBILITY
```
  ）。
- 不仅要检查日志，还要检查 SQL 本身：BigQuery Migration Service (BQMS) 会为无法映射的类型输出
```
ERROR_TYPE(...)
```
  ，有时不会生成日志条目。将任何
```
ERROR_TYPE
```
  或内联错误注释都视为错误；如果有可用的 BigQuery project，请对结果执行 dry-run（
```
bq query --dry_run --use_legacy_sql=false
```
  ）。
```
Not found
```
  或
```
must be qualified with a dataset
```
  错误仍表示 SQL 在语法上有效，只是引用的对象尚不存在于 BigQuery 中。即使错误提示了修复方法，也要说明这一点并继续操作：不要创建 stub tables，也不要修改 SQL 或
```
bq
```
  flags 来绕过错误。
- ```
NoSuchFunction
```
  错误表示 BigQuery Migration Service (BQMS) 原样复制了该调用，有时函数名会带有反引号。即使 BigQuery 中存在同名函数，也应将其视为未转换：因缺少 tables 而停止的 dry-run 并不会检查该函数。
- 如果 source dialect 有 gotchas reference（参见 Dialect-Specific Gotchas），请阅读该文档并检查输出中是否出现其列出的模式。部分语义差异不会生成日志条目，但仍能通过 dry-run。
迭代直至无错误：如果 logs 中包含 errors 或 warnings、翻译后的 SQL 包含
```
ERROR_TYPE
```
或内联错误注释、dry-run 失败，或者输出与某个 dialect gotcha 匹配，请按照 Resolving Translation Issues 中所述的方法解决问题并重新翻译。
解释并比较差异（
explain_translation
）：当用户要求解释翻译结果、比较语法差异，或了解特定 query logic 的转换方式时，使用
```
translation
```
（translation ID）、
```
projectNumber
```
和
```
location
```
调用
```
explain_translation
```
。它会返回对查询用途的结构化说明，以及 source query 与翻译后 GoogleSQL 在语法、函数和行为方面的详细差异分解。该说明不会验证输出，因此仍需按照步骤 3 检查翻译结果，而不能依赖该说明。

2. Batch Translation Workflow

2. Batch Translation 工作流

Batch translation handles multiple files staged in Cloud Storage. It resolves cross-file dependencies and produces a consolidated translation summary report (

translation_report.csv

Batch translation 处理暂存在 Cloud Storage 中的多个文件。它能够解决跨文件依赖，并生成统一的翻译摘要报告（

translation_report.csv

）。

Steps

步骤

Stage Input Files to Cloud Storage: Upload the raw SQL files, configuration files (
```
*.config.yaml
```
), and any metadata file from the local workspace to a Cloud Storage input folder:
bash
```
gcloud storage cp input/*.sql gs://my-bucket/migration/input/
gcloud storage cp *.config.yaml gs://my-bucket/migration/input/
```
Note: Do not pass configuration file paths in tool parameters if those files are already located inside
sourceBaseUri
.
Use new, empty Cloud Storage input and output folders for each run (e.g. with a timestamp suffix). Stage only files from the local workspace or generated in this run. Never reuse or copy inputs, DDL, or outputs that are already in a bucket from earlier runs: they may come from different inputs or settings.
Initiate Batch Translation:
- Translating SQL Queries (
  translate_batch_queries
  ): Call
```
translate_batch_queries
```
  with
```
projectNumber
```
  ,
```
location
```
  ,
```
sourceDialect
```
  ,
```
targetDialect
```
  ,
```
sourceBaseUri
```
  , and
```
targetBaseUri
```
  .
- Translating Metadata Zip Files (
  translate_metadata
  ): To aid batch translation by generating target BigQuery DDL schema definitions from an extracted database metadata zip file (
```
metadata.zip
```
  from Teradata, Oracle, etc.), call
```
translate_metadata
```
  specifying
```
sourceBaseUri
```
  (Cloud Storage URI to
```
metadata.zip
```
  ) and
```
targetBaseUri
```
  (destination Cloud Storage folder).
Poll Completion (
fetch_batch_translation
): Poll using the returned workflow ID until
```
translation.state
```
is
```
SUCCEEDED
```
or
```
FAILED
```
, at the interval given in the BigQuery Migration Service (BQMS) MCP tool descriptions.
Retrieve & Inspect Outputs: Download the generated files from
```
translation.target_base_uri
```
:
bash
```
gcloud storage cp -r gs://my-bucket/migration/output/ ./local_output/
```
Locate and inspect
```
report/translation_report.csv
```
to review all warnings, errors, and line-level diagnostics. Then scan the generated
```
.sql
```
files for
```
ERROR_TYPE(...)
```
and inline error comments, which the report can miss, and dry-run the generated SQL when a BigQuery project is available (handle
```
Not found
```
errors as in the interactive workflow). Check the output for the patterns in the source dialect's gotchas reference, if one exists. Resolve or clearly report every remaining issue; do not describe the output as clean until this check passes.
Iterate Until Clean: Resolve the issues found in step 4 as described in Resolving Translation Issues, and re-run from step 1 with the changed inputs.
Post-processing (Final Step Only): Only after resolving every compiler error that re-translation can fix, execute any application-level post-processing (e.g. AST re-injection) to restore host source files. effect_correctness.md lists the errors that may remain when re-injecting embedded SQL.

将输入文件暂存到 Cloud Storage：将本地 workspace 中的原始 SQL 文件、配置文件（
```
*.config.yaml
```
）及任何 metadata 文件上传到 Cloud Storage 输入文件夹：
bash
```
gcloud storage cp input/*.sql gs://my-bucket/migration/input/
gcloud storage cp *.config.yaml gs://my-bucket/migration/input/
```
注意：如果配置文件已经位于
sourceBaseUri
中，请勿在 tool 参数中传递这些文件路径。
每次运行都应使用新的空 Cloud Storage 输入和输出文件夹（例如添加 timestamp 后缀）。只暂存来自本地 workspace 或在本次运行中生成的文件。切勿复用或复制 bucket 中早期运行留下的 inputs、DDL 或 outputs：它们可能来自不同的输入或设置。
启动 Batch Translation：
- 翻译 SQL Queries（
  translate_batch_queries
  ）：调用
```
translate_batch_queries
```
  ，传入
```
projectNumber
```
  、
```
location
```
  、
```
sourceDialect
```
  、
```
targetDialect
```
  、
```
sourceBaseUri
```
  和
```
targetBaseUri
```
  。
- 翻译 Metadata Zip Files（
  translate_metadata
  ）：若要通过从解压后的数据库 metadata zip 文件（来自 Teradata、Oracle 等的
```
metadata.zip
```
  ）生成目标 BigQuery DDL schema definitions 来辅助 batch translation，请调用
```
translate_metadata
```
  ，并指定
```
sourceBaseUri
```
  （
```
metadata.zip
```
  的 Cloud Storage URI）和
```
targetBaseUri
```
  （目标 Cloud Storage 文件夹）。
轮询完成状态（
fetch_batch_translation
）：使用返回的 workflow ID 轮询，直至
```
translation.state
```
变为
```
SUCCEEDED
```
或
```
FAILED
```
；轮询间隔应遵循 BigQuery Migration Service (BQMS) MCP tool descriptions 中的规定。
检索并检查输出：从
```
translation.target_base_uri
```
下载生成的文件：
bash
```
gcloud storage cp -r gs://my-bucket/migration/output/ ./local_output/
```
找到并检查
```
report/translation_report.csv
```
，以审查所有 warnings、errors 和行级诊断信息。然后扫描生成的
```
.sql
```
文件，查找
```
ERROR_TYPE(...)
```
和内联错误注释，这些问题可能会遗漏在报告之外；如果有可用的 BigQuery project，请对生成的 SQL 执行 dry-run（按照交互式工作流处理
```
Not found
```
错误）。如果 source dialect 有 gotchas reference，请检查输出中是否出现其中的模式。解决所有遗留问题，或明确报告这些问题；在检查通过之前，不要将输出描述为无错误。
迭代直至无错误：按照步骤 4 和 Resolving Translation Issues 中所述的方法解决发现的问题，并从步骤 1 开始，使用修改后的输入重新运行。
后处理（仅最后一步）：只有在解决所有可通过重新翻译修复的编译错误后，才能执行应用程序级后处理（例如 AST re-injection），以恢复宿主源文件。effect_correctness.md 列出了重新注入嵌入式 SQL 时可能遗留的错误。

Resolving Translation Issues

解决翻译问题

Both workflows resolve issues the same way:

Identify the Effect (
```
CORRECTNESS
```
,
```
COMPLETENESS
```
,
```
COMPATIBILITY
```
) of each issue, and resolve them in order of compiler phase dependencies:
```
CORRECTNESS
```
(parse errors) first, then
```
COMPLETENESS
```
(missing objects), then
```
COMPATIBILITY
```
(unsupported features).
MUST Read the Reference Guide for each effect in Troubleshooting by Error Effect BEFORE applying fixes, and follow its resolution workflow.
Fixes can preprocess the input (e.g. prepend DDL) or post-process the BigQuery Migration Service (BQMS) output (e.g. a rewrite that a dialect gotcha calls for). Run BigQuery Migration Service (BQMS) on the preprocessed input rather than translating it yourself.
Keep the source system's dialect for every re-translation. Another dialect may accept the same SQL but translate it with different semantics (e.g. return types, numeric types, or identifier case), so don't switch dialects to get cleaner output.
Rewrites of the BigQuery Migration Service (BQMS) output, including optimizations the user asks for, must return the same rows as the source query. For example, a filter that runs after a row limit (
```
TOP
```
,
```
LIMIT
```
) can't be merged into the query before the limit.
Wait for each re-translation to finish, record its translation ID, error counts, and any pre- or post-processing in the tracker, and compare the counts with the previous iteration. Repeat until no errors remain or all options are exhausted.
Report the final SQL from the tracked iteration, the pre- and post-processing you applied, and any errors that remain.

两种工作流使用相同的方法解决问题：

确定每个问题的 Effect（
```
CORRECTNESS
```
、
```
COMPLETENESS
```
、
```
COMPATIBILITY
```
），并按照编译器阶段的依赖顺序解决：先处理
```
CORRECTNESS
```
（解析错误），然后处理
```
COMPLETENESS
```
（缺失对象），最后处理
```
COMPATIBILITY
```
（不支持的功能）。
在应用修复之前，必须阅读 Troubleshooting by Error Effect 中每种 effect 对应的 Reference Guide，并遵循其中的解决工作流。
修复操作可以预处理输入（例如在开头添加 DDL），也可以后处理 BigQuery Migration Service (BQMS) 输出（例如按照 dialect gotcha 重写内容）。请让 BigQuery Migration Service (BQMS) 处理预处理后的输入，而不是自行翻译。
每次重新翻译时都应保留 source system 的 dialect。另一种 dialect 可能接受相同的 SQL，却以不同语义进行翻译（例如返回类型、数字类型或标识符大小写），因此不要为了让输出更简洁而切换 dialect。
对 BigQuery Migration Service (BQMS) 输出进行的重写，包括用户要求的 optimizations，必须返回与 source query 相同的行。例如，在行数限制（
```
TOP
```
、
```
LIMIT
```
）之后执行的 filter 不能在限制之前合并到查询中。
等待每次重新翻译完成，在 tracker 中记录其 translation ID、错误数量以及所有前处理或后处理操作，并将这些数量与上一次迭代进行比较。重复此过程，直至没有错误剩余或所有可行方案均已用尽。
报告最终追踪迭代生成的 SQL、所应用的前处理和后处理，以及仍然存在的任何错误。

Reference Lookup Index

Use these reference guides when troubleshooting errors or authoring configuration files:

排查错误或编写配置文件时，请使用以下 reference guides：

Troubleshooting by Error Effect

按错误影响排查问题

Effect	Common Causes	Reference Guide
`CORRECTNESS`	Syntax errors, unescaped literals, application script wrappers, `NoSuchFunction` .	effect_correctness.md
`COMPLETENESS`	Missing tables, views, columns ( `RelationNotFound` , `AttributeNotFound` ), DDL suggestions.	effect_completeness.md
`COMPATIBILITY`	Functions or features without direct GoogleSQL mapping.	effect_compatibility.md

Effect	常见原因	Reference Guide
`CORRECTNESS`	语法错误、未转义的字面量、应用程序脚本包装、 `NoSuchFunction` 。	effect_correctness.md
`COMPLETENESS`	缺失的 tables、views、columns（ `RelationNotFound` 、 `AttributeNotFound` ）、DDL 建议。	effect_completeness.md
`COMPATIBILITY`	没有直接 GoogleSQL 映射的 functions 或 features。	effect_compatibility.md

Configuration & Setup Guides

配置与设置指南

Task	Description	Reference Guide
YAML Configurations	Database/schema redirection, name mapping, table partitioning and clustering injection, optimizer transformations, statement rewriters, and environment settings. Schemas in `assets/translation_config_schemas/` and examples in `assets/translation_config_examples/` .	translation_yaml_config.md
MCP Server Setup	Configuring the remote BigQuery Migration Service (BQMS) MCP server, OAuth scopes, and IAM roles.	mcp_config.md

任务	说明	Reference Guide
YAML Configurations	Database/schema 重定向、名称映射、table partitioning 和 clustering 注入、optimizer transformations、statement rewriters 以及 environment settings。Schemas 位于 `assets/translation_config_schemas/` ，示例位于 `assets/translation_config_examples/` 。	translation_yaml_config.md
MCP Server Setup	配置远程 BigQuery Migration Service (BQMS) MCP server、OAuth scopes 和 IAM roles。	mcp_config.md

Dialect-Specific Gotchas

Dialect	Key Considerations	Reference Guide
Teradata	SET/MULTISET tables, `SAMPLE` clause, primary index mapping.	teradata_gotchas.md
Oracle	PL/SQL procedures, `ROWNUM` emulation, outer join `(+)` , sequences.	oracle_gotchas.md
Snowflake	Dynamic templates, `USE` statements, metadata merging, lateral joins.	snowflake_gotchas.md

Dialect	关键注意事项	Reference Guide
Teradata	SET/MULTISET tables、 `SAMPLE` clause、primary index mapping。	teradata_gotchas.md
Oracle	PL/SQL procedures、 `ROWNUM` emulation、outer join `(+)` 、sequences。	oracle_gotchas.md
Snowflake	Dynamic templates、 `USE` statements、metadata merging、lateral joins。	snowflake_gotchas.md