Back to Details

reviewing-oracle-to-postgres-migration

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Oracle-to-PostgreSQL Database Migration

Oracle到PostgreSQL数据库迁移

Surfaces migration risks and validates migration work against known Oracle/PostgreSQL behavioral differences documented in the 
references/
folder.
根据
references/
文件夹中记录的Oracle与PostgreSQL已知行为差异，识别迁移风险并验证迁移工作的有效性。

When to use

适用场景

  1. Planning — Before starting migration work on a procedure, trigger, query, or refcursor client. Identify which reference insights apply so risks are addressed up front.
  2. Validating — After migration work is done, confirm every applicable insight was addressed and integration tests cover the new PostgreSQL semantics.
  1. 规划阶段 — 在开始存储过程、触发器、查询或refcursor客户端的迁移工作之前。确定哪些参考要点适用，以便提前应对风险。
  2. 验证阶段 — 迁移工作完成后，确认所有适用的参考要点均已处理，且集成测试覆盖了新的PostgreSQL语义。

Workflow

工作流程

Determine the task type:
Planning a migration? Follow the risk assessment workflow. Validating completed work? Follow the validation workflow.
确定任务类型：
规划迁移？ 遵循风险评估工作流程。 验证已完成的工作？ 遵循验证工作流程。

Risk assessment workflow (planning)

风险评估工作流程（规划阶段）

Risk Assessment:
- [ ] Step 1: Identify the migration scope
- [ ] Step 2: Screen each insight for applicability
- [ ] Step 3: Document risks and recommended actions
Step 1: Identify the migration scope
List the affected database objects (procedures, triggers, queries, views) and the application code that calls them.
Step 2: Screen each insight for applicability
Review the reference index in references/REFERENCE.md. For each entry, determine whether the migration scope contains patterns affected by that insight. Read the full reference file only when the insight is potentially relevant.
Step 3: Document risks and recommended actions
For each applicable insight, note the specific risk and the recommended fix pattern from the reference file. Flag any insight that requires a design decision (e.g., whether to preserve Oracle empty-string-as-NULL semantics or adopt PostgreSQL behavior).
Risk Assessment:
- [ ] Step 1: Identify the migration scope
- [ ] Step 2: Screen each insight for applicability
- [ ] Step 3: Document risks and recommended actions
步骤1：确定迁移范围
列出受影响的数据库对象（存储过程、触发器、查询、视图）以及调用它们的应用程序代码。
步骤2：筛选每个参考要点的适用性
查看references/REFERENCE.md中的参考索引。对于每个条目，判断迁移范围是否包含受该要点影响的模式。仅当该要点可能相关时，才阅读完整的参考文件。
步骤3：记录风险与建议措施
对于每个适用的参考要点，记录参考文件中提到的具体风险和建议的修复模式。标记任何需要做出设计决策的要点（例如，是保留Oracle将空字符串视为NULL的语义，还是采用PostgreSQL的行为）。

Validation workflow (post-migration)

验证工作流程（迁移后）

Validation:
- [ ] Step 1: Map the migration artifact
- [ ] Step 2: Cross-check applicable insights
- [ ] Step 3: Verify integration test coverage
- [ ] Step 4: Gate the result
Step 1: Map the migration artifact
Identify the migrated object and summarize the change set.
Step 2: Cross-check applicable insights
For each reference in references/REFERENCE.md, confirm the behavior or test requirement is acknowledged and addressed in the migration work.
Step 3: Verify integration test coverage
Confirm tests exercise both the happy path and the failure scenarios highlighted in applicable insights (exceptions, sorting, refcursor consumption, concurrent transactions, timestamps, etc.).
Step 4: Gate the result
Return a checklist asserting each applicable insight was addressed, migration scripts run, and integration tests pass.
Validation:
- [ ] Step 1: Map the migration artifact
- [ ] Step 2: Cross-check applicable insights
- [ ] Step 3: Verify integration test coverage
- [ ] Step 4: Gate the result
步骤1：梳理迁移成果
确定已迁移的对象并总结变更集。
步骤2：交叉核对适用的参考要点
对于references/REFERENCE.md中的每个参考内容，确认迁移工作中已考虑并处理了相关行为或测试要求。
步骤3：验证集成测试覆盖范围
确认测试既覆盖了正常流程，也覆盖了适用参考要点中强调的失败场景（异常、排序、refcursor消费、并发事务、时间戳等）。
步骤4：结果准入
返回一份检查清单，确认所有适用的参考要点均已处理、迁移脚本已运行且集成测试通过。