ANBOB™

最这我们一个客户从oracle迁移到postgresql系的某国产数据库后，CPU一直接近100%, 但是再仔细分析，发现%system CPU占到60%左右，当然这是一种不正常的现象，之前我写过《如何在 Linux 上诊断高 %Sys CPU》， 使用pidstat 确认%sys cpu进程大部分为postgresql进程，pstack 查看发现call, PostgreSQL 的线程大部分时间都在调用 newfstatat()，这 不是正常现象，并且通常意味着数据库运行中存在 频繁的文件状态检查（stat）操作，严重时可能导致性能瓶颈。

在使用PostgreSQL JDBC处理大型结果集时，正确配置fetch size对于优化性能和内存使用至关重要。最近我们在国产化改造过程中总有一些差异导致应用性能问题，有时不只在数据库还可能在驱动中，如分页查询或其他OLTP场景，我们总希望尽快的返回结果，这里我分享一下Oracle和Postgresql JDBC 默认fetchsize 从服务向客户端发送数据的差异。

PostgreSQL 32位的事务ID，是个比较头疼的问题，如果事务ID耗尽回卷时，回影响数据库的可用行，近期一客户的postgresql数据库出现了事务回卷问题，导致所有业务无法执行， 早期可能日志中会有提示，后期数据库进入只读模式，需要人工干预，同时日志提示下面的错误：
2025-05-16 08:43:48.640 [5764] ERROR: database is not accepting commands to avoid wraparound data loss in database “postgres” (10182)

我们explain 增加analyze可以显示exection time实际执行所花的时间, 但是注意对于客户端执行SQL时的response time响应时间并不是这个exection time，这也是有时应用的人会反馈程序执行时间很慢，但我们在数据库端使用explain显示的exection time快，相差很大的原因。简单演示。

GaussDB是华为推出的企业级关系型数据库，这里GaussDB是指FOR OLTP的关系型数据库，该分支产品支持分布式和单机式，支持ARM架构和X86架构，目前也同样支持on-premises 本地部署, 来抢占线下的如oracle\MySQL的国产化替代市场，支持oracle与MySQL兼容模式，之前测试过《体验一下GaussDB集中式(本地部署)的Flashback/TIMECAPSULE 闪回功能》，这次在测试环境ARM平台上安装GaussDB单机版(505版本)用于学习，简单记录。

在从Oracle迁移到PostgreSQL后，SELECT和TRUNCATE操作互相阻塞是一个常见问题，这主要是由于两种数据库的锁机制不同导致的。目前一客户项目在我们迁移到postgresql系的国产数据库生产环境后,时常在一个存储过程中包含truncate又有select 长事务时发生互相堵塞，简单记录.

数据堪称企业的生命线，任何一次不经意的操作失误都可能引发千万级别的经济损失，甚至招致法律上的责任追究。在今天的分享中，我将从规章制度、技术保障以及人员管理三个维度出发，为大家详细解读——无论是面对从Oracle到国产数据库的运维转型，还是探索国产数据库特有的安全机制时，我们应当注意的关键事项。同时，我们也会探讨在利用大型模型进行知识问答过程中可能出现的风险及其防范措施，旨在帮助大家构建坚固的数据安全防线，确保企业数据资产的安全与稳定。

尽量在同一个模式下创建和查询表,避免跨模式操作导致的数据类型问题,当表中使用了Oracle兼容的NUMBER数据类型时，强烈建议统一使用Oracle模式进行数据库连接和操作,在PG模式下查询包含NUMBER类型列的表时，会发生隐式类型转换,这种转换会导致查询优化器无法有效利用列上的索引，特别是影响范围扫描等高效查询方式,对于不需要Oracle特殊功能的场景，可考虑使用PostgreSQL原生数据类型如INT、BIGINT或NUMERIC

在使用 PostgreSQL 数据库时,可能会看到过该错误消息，最近在highGoDB（postgresq）一个大的业务库做drop database时有遇到,也可能查询pgp_dump或查看表对象大小(如几千个分区)时，会提示提示错误” ERROR: out of shared memory
HINT: You might need to increase max_locks_per_transaction.

最近在做从Mogdb(openGauss)导入Highgo(PostgreSQL)的PG模式数据时，timestamp类型的数据库入库错误，使用的是MTK逻辑查询是insert的方式，错误内容如下：

anbob=# insert into test9(t) values (‘20240101 13:01:01Z’);
ERROR: datetime format picture ends before converting entire input string

在oracle多表关连中有SQL hint可以干预CBO产生的不合理的表join顺序，如ordered, leading等，但PostgreSQL和部分基于PG国产数据库如Highgo V9.5， 目前也还不支持SQL hint。当遇到SQL性能问题，明确某个join 顺序更好时，如何影响PG数据库优化器执行指定的执行计划呢？如果您真的需要SQL hint，在pg中可以安装 pg_hint_plan 扩展，但目前应该是因为highgo的oracle和pg的双兼容模式，如果实现pg_hint_plan在解析器上隔离上要复杂了些，所以暂未实现，又或者不想安装第三方扩展，在这种情况下，记录几个可以强制执行join ordered的替代方法。

在使用 PostgreSQL 时，分区表可以有效管理和优化大规模数据表的存储和查询性能。在一些国产库中兼容了oracle的创建语法格式，有些仅支持语法存储还是pg,有些是连语法都未支持，在PG中创建分区的方法让oracle DBA可能有些难以适应，在PG中的分区分为parent/partitioned 和 child/partition tables , PostgreSQL支持range, list, hash分区。这里记录一些PG系使用过程中的注意事项。

PostgreSQL 中有三种连接策略，它们的工作原理截然不同。如果 PostgreSQL 选择了错误的策略，查询性能可能会受到很大影响。本文介绍了连接策略、如何使用索引支持它们、它们可能出现的问题以及如何调整连接以获得更好的性能。

几年前整理过，在SQL使用 PBE(Parse Bind Execute) 时，如prepare statement, 如何生成gplan（通用执行计划）和cplan(定制执行计划)， 及解析共享在如数据倾斜时可能存在的执行计划错误，前几天在opengauss系数据库做了切换后，较多SQL产生了错误的执行计划，因为错误的cost估算，有hash join 改成了nl join同样也是PBE的错误场景，仅记录。

今天在客户一套库发现了个bug, select count(*) 与select *明细记录数不一致， 环境mogdb 508， 前者使用index only scan, 后者是index scan , 这种情况在oracle有时也能遇到，通常是索引条目与table条目不一致，如因为lost write导致，可以drop 并create index重建索引恢复，但是opengauss中还是第一次，在postgresql中控制记录的除了table, index还有可见性的vm，简单记录一下该问题。

日志是数据库用于诊断解决问题的途径，在生产环境中开启过多可能会导致性能问题，过少可能缺失日志，配置时有必要微调默认的日志配置参数，对应多个log_xxx参数，要达到理想的平衡，需要深入了解各种 PostgreSQL logging 指令是关键。定制日志记录设置以精确满足您的监控和故障排除需求。或何时可以动态的开启。

翰高数据库 Highgo是基于PostgreSQL的数据库，但是版本较多有基于postgresql 9 、12、14多个版本，同时在兼容模式上也并不统一，如支持pg, oracle和正在增加的MySQL兼容模式，如V9.5版本可以实现一份数据，两种解析引擎模式的支持，同时在V9版本登录时还有实例级用户和数据库用户级，简单整理总结以扫盲。

在PostgreSQL中的时间类型较多，如TIME, DATE, INTERVAL, TIMESTAMP,和Timestamp With Timezone(TIMESTAMPTZ) ， 而timestamp类型精确度非常高，如date类型是只有年月日，time又只有时间分秒，而timestamp是两者组合，同时可以带时区，如有在些基于postgresql国产数据库中为了兼容sysdate，注意函数的返回精确度，防止数据迁移丢失精度，但有时用户希望使用精度较低，如按日期检索和创建索引时有点有趣。为了说明这一点这里测试一下。

随着数字经济的快速发展和数据量的激增，高性能数据库系统成为企业业务的核心基础设施之一。在全栈国产化的背景下，如何构建高效、可靠的存储架构，实现 100 万 IOPS 的性能目标， 做为集中式数据库的基础设施提供支持，成为企业关注的重点。本文探讨通过 NVMe SSD 和硬件 RAID 卡组合，构建集中式数据库系统的技术路径。如利用 4 块NVMe SSD，在 RAID 0 下实际性能可超过 1,600,000 IOPS，完全满足高负载数据库的需求。

前两篇在《VIEW dependencies in Oracle、MySQL、PostGreSQL(数据库比较系列十一)》《Alert : PostgreSQL inline Subquery or View 包含volatile functions 阻止谓词推进(Predicate PushDown)》记录了因为view 包含Volatile Function导致的性能问题，通常，PostgreSQL 函数可以按如下方式标记：VOLATILE、STABLE、IMMUTABLE , 而这也是算最被广泛忽视的性能问题点，这篇文档整理个SQL列出所有包含”VOLATILE” Function 的View, 判断是否可以修改稳定性属性。