你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
从 Oracle 迁移到 Azure Database for PostgreSQL 的最佳做法
适用于：
Azure Database for PostgreSQL 灵活服务器
以下方案概述了 Oracle 迁移到 Azure Postgres 期间遇到的一些潜在挑战。 在规划和执行自己的迁移时，建议的解决方案有助于克服这些挑战。
方案：两个单独的低延迟、高吞吐量、客户端应用程序在相同的数据库上独立操作。 每个应用程序无意中将其他人的缓存查询从缓冲区中挤出。 共享负载和合并资源争用创造了一种情况，即数据库共享缓冲区刷新得太频繁，导致两个系统的性能下降。
建议的解决方案：确保初始评估捕获数据库平台环境的各个方面，包括系统全局区域 (SGA) 和程序全局区域 (PGA) 内存结构的内存消耗和利用率模式。 选择符合资源要求的相应计算系列，并确保根据需要调整 Postgres 计划容量。
提示
pg_buffercache 扩展提供了检查利用率的方法，并允许实时观察共享缓冲区缓存中发生的情况。
Buffer Cache Hit Ratio
通过检查命中率，可以评估缓存有效性，并确定共享缓冲区大小是否合适。 良好的缓存命中率是大多数数据请求从内存（而不是磁盘）提供的标志，从而提供最佳性能：
SELECT COUNT(*) AS total
, SUM(CASE WHEN isdirty THEN 1 ELSE 0 END) AS dirty -- # of buffers out of sync with disk
, SUM(CASE WHEN isdirty THEN 0 ELSE 1 END) AS clean -- # of buffers in sync with data on disk
FROM pg_buffercache;
最常访问的表和索引
检查最常访问以及/或占用缓冲区缓存中空间最多的表和索引有助于识别内存中缓存的热点：
SELECT b.relfilenode, relname, relblocknumber
, relkind
--r = ordinary table, i = index, S = sequence, t = TOAST table
--, v = view, m = materialized view, c = composite type
--, f = foreign table, p = partitioned table, I = partitioned index
, COUNT(*) AS buffers
FROM pg_buffercache b
JOIN pg_class c ON c.oid = b.relfilenode
GROUP BY b.relfilenode, relname, relblocknumber, relkind
ORDER BY buffers DESC
LIMIT 10;
缓冲区缓存争用
缓冲区缓存中的大量争用表明，多个查询可能会争夺相同的缓冲区空间，从而导致性能瓶颈。 检查缓冲区访问的位置和频率有助于诊断此类问题：
SELECT c.relname, b.relblocknumber, COUNT(*) AS access_count
FROM pg_buffercache b
JOIN pg_class c ON c.relfilenode = b.relfilenode
GROUP BY c.relname, b.relblocknumber
ORDER BY access_count DESC
LIMIT 10;
方案：Postgres 平台发布周期之间和跨版本启动迁移工作。 尽管最新版本中提供了新功能和改进，但在迁移开始时选择的版本保持不变。 随后，在初始迁移后，随后增加了工作量、时间和费用，以升级 Postgres 数据库版本，从而实现最佳性能和新功能。
建议的解决方案：尽可能在迁移时优先采用最新版本的 Postgres。 Postgres 社区开发团队非常努力地将性能和稳定性的每一点提升都融入到每一个新版本中，有所保留本质上等同于将性能弃之不用。 此外，充分利用新的 Azure 功能。 新的 Azure Postgres 功能包括：SSDv2 存储、最新的服务器系列基础结构，以及自动索引优化和自治服务器参数优化功能。
方案：首次迁移到 Postgres 的组织在识别运行缓慢的查询时可能不熟悉最佳做法和方法。 在实施适当的新索引类型时，应特别小心和注意。 值得注意的是，Postgres 数据库引擎旨在优化查询性能，而无需指定查询提示。
推荐的解决方案：扩展是 Postgres 如此强大的一个不可或缺的部分。 有几个扩展可以提供重要功能，使你能够确保数据库在最佳性能下运行。 应考虑的一些关键扩展包括：
auto_explain：自动记录超出设定阈值的查询的执行计划。 允许数据库管理员诊断性能问题并优化查询性能，而无需在每次查询时手动运行 EXPLAIN。
pg_trgm：提供函数和运算符，用于通过三元语法匹配来确定基于文本的数据的相似性。 此扩展适用于涉及文本搜索、模糊匹配和基于相似性查询的任务。 结合文本列上的 GIN 或 GIST 索引，可提高 LIKE 查询和相似性搜索的性能。
pg_cron：允许直接在数据库中计划和管理周期性任务。 将类似 cron 的任务计划集成到 Postgres 中，使日常维护任务、数据处理和类似的重复操作自动化。
提示
如果数据库操作涉及大量重复创建和删除数据库对象，则较旧的 pg_catalog 系统表元组将增加，从而导致表“膨胀”。 由于 pg_catalog 是许多数据库操作中涉及的系统表，因此对此表的未减轻的维护可能会导致整个数据库的性能下降。 通过配置定期 pg_cron 计划，确保 pg_catalog 得到充分维护和适当清空。
- pg_hint_plan：Postgres 旨在提供一致且可靠的性能，而无需手动干预，从而造成设计决策有意不包括查询提示。 对于需要对查询计划设计进行特定和精确控制的情况，pg_hint_plan 提供了一种使用嵌入到 SQL 注释中的提示影响查询规划器决策的方法。 这些提示允许数据库管理员指导查询规划器选择特定计划，以便优化复杂的查询或解决规划器可能无法自行处理的性能问题。
注意
这些示例只是粗略介绍了 Postgres 数据库可用的大量扩展。 我们鼓励你充分探索这些扩展，以增强你的 Postgres 数据库。 此外，还可以考虑创作自己的扩展的可能性，在这些扩展中可以看到将 Postgres 扩展到当前功能之外的可能性。 强大的灵活扩展体系结构可确保 Postgres 始终能够根据平台要求适应和改进。
方案：在某些情况下，旧表分区策略会导致创建数千个分区。 虽然这在以前使用时可能有效，但这些策略在某些情况下可能会降低 Postgres 中的查询性能。 在非常具体的实例中，查询规划器在分析查询时可能无法确定适当的分区键。 由此产生的行为导致规划时间延长，并使查询计划花费的时间比实际查询执行时间长。
建议的解决方案：重新评估对生成过多分区的分区策略的需求。 Postgres 数据库引擎可能不再需要相同的数据分割，减少分区数可能会提高性能。 如果评估了旧分区方案并将其确定为必需，请考虑将查询重构为离散的操作，一边首先识别并提取动态分区键，然后在查询操作中使用这些分区键。
方案：有时，外部依赖项和环境条件可能需要混合数据库方案，其中 Oracle 和 Azure Postgres 数据库需要共存。 例如，有时可能需要分阶段迁移才能直接从 Azure Postgres 访问和查询 Oracle 数据，无需导入数据或修改复杂的 ETL 过程。 在其他实例中，通过同时比较 Oracle 和 Azure Postgres 环境中的等效数据集来执行并行数据验证有助于确保在迁移期间和/或之后的数据一致性和完整性。
建议的解决方案：PostgreSQL 外部数据封装器 (FDW) 扩展是一项关键的 Postgres 功能，使你能够访问和操作存储在外部系统中的数据，就好像该数据驻留在 Azure Postgres 数据库中一样。 FDW 使 Azure Postgres 能够充当联合数据库，从而允许与任意数量的外部数据源（包括 Oracle 数据库）集成。 FDW 在 Postgres 数据库中创建外部表定义，这些外部表充当定义的外部数据源的代理，允许用户使用常规 SQL 查询来查询这些外部表。 在内部，Postgres 引擎使用外部 FDW 定义从远程数据源按需通信和协调数据。
oracle_fdw：（适用于 Oracle 的外部数据封装器）是一个 Postgres 扩展，可用于从 Azure Postgres 中访问 Oracle 数据库。 从 Oracle 迁移到 Azure Postgres 时，oracle_fdw 可以发挥关键作用，提供数据访问、数据验证、增量迁移和实时数据同步。 使用 FDW 时请务必记住以下关键注意事项：
- 在处理数据并从远程 Oracle 服务器提取数据时，通过 oracle_fdw 运行查询将产生网络通信和身份验证协商形式的开销。
- 某些数据类型可能需要特殊处理或转换，以确保数据类型在系统之间正确映射。
有效地使用 oracle_fdw 可以帮助简化数据库转换，并通过在整个迁移过程中保持应用程序和数据的可访问性来确保数据可访问性。