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快，相差很大的原因。简单演示。

oracle支持一些异构平台的dataguard，如Windows 到Linux, 在做了平台迁移后可能会出现一些PLSQL 对象执行报错的现象，如ora-7445 type: SIGsEGv, Address not mapped to object或ORA-600 [PL/SQL Native Code: Wrong Platform] Errors, 是因为plsql对象在Windows是可能已编译为NATIVE本地机器码，换平台后不认证，简单记录解决方法

今天一个客户的oracle 19c（19.17）环境显示top event中出现了一个比较稀奇的event ‘gc index operation’, 也可能是12cR2 RAC新特性”fast index split wait”引入的相同问题， 19c前已知bug常发生成 BASICFILE LOB 对象上，仅记录.

我们可以使用datapump进行 Oracle 的 AUDIT 审计记录导出到其它库，但是导出时有一些限制,使用expdp或exp可能会提示ORA-39166或EXP-00064错误， 如之前审计记录在sys.aud$，使用了统一审计后，记录在audsys.AUD$UNIFIED。导出方法一样，仅记录。

好久没有关注oracle database服务支持周期，最初还是到2025年结束，今年就要过期了吗？显然数据库发展已经进入了成熟期，或没有那么多的新功能需求，大版本的更新周期延长终止了过去每4年一个大版本的神话，oracle 19c发布已经6年了，最近才发现oracle一个重要更新，自 2024 年 11 月 19 日起, Oracle Database 19c 的支持时间表已进行调整。查看MOS 说明：742060.1 – 当前数据库版本的发布时间表，19c又延长了服务支持周期到2029-12-31, ES 到2032年