ANBOB™

在数据库中文本的模糊查询是ES等数据库的强项，但在关系型数据库中也有一些手段，如后缀%普通索引就可以使用，前缀可以创建reverse反转索引，但是前后模糊的话，在oracle中可以创建索引使用index full scan+加回表查询，今天发现在PostgreSQL中还有pg_trgm扩展，配合GIN索引有不错的性能表现。

前不久整理了一《HighgoDB (PostgreSQL) %SYS CPU newfstatat() high 调优一例》， 这个问题还在持续，并且原因并不只是一个，从调了文件系统级atime，到调整wal size减少日志被动清理，还有在验证temp 文件，这里后来又发现了sysdate函数的timezone调用，简单记录。前面有提到是newfsatat()函数产生的system CPU, 用于文件验证…

最近有个客户在1个40多TB的AIX 平台Oracle国产化改造项目中，配合创建Oracle dataguard 时失败，当使用 RMAN 进行数据库复制(duplicate)操作时出现此错误，提示 ORA-17628 19505 ORA-27040错误，ORA-27040 错误是 Oracle 数据库在尝试访问文件时遇到的 I/O 相关错误，简单记录。

最近有个客户的oracle 19c 3nodes RAC 有一个节点意外crash ORA-600 kjblpgorm:!antilock, 启动时报ORA-600[kfmdPriRegRclient04]，并启动过程中重导致之前的幸存节点hang并且重启，Oracle 的基础版本bug 比较多，找我分析并临时解决了该问题，简单记录该问题。

Recently, for one of our customers’ XD system, a cell node automatically restarted. The reason was due to disk control. However, after the restart, it was discovered that there was an automatic operation to delete the ASM disk in the log, and this was not an intentional human action. Simply record this feature.

最这我们一个客户从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年

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 长事务时发生互相堵塞，简单记录.

在服务器运维中，由于未配置NTP服务或存在CPU时钟精度问题，操作系统时间常会逐渐产生偏差。当需要修正这类时间差异时，通常希望在不停库的前提下完成操作以避免影响业务。
对于采用本地文件系统的Oracle单实例数据库，时间修正主要风险在于业务逻辑中若直接调用SYSDATE函数，可能导致事务时间戳跳跃（如业务单据时间异常），但一般不会影响数据库可用性。然而在Oracle RAC（Real Application Clusters）环境中，时间同步问题可能引发更严重的后果——包括集群实例崩溃和强制重启。

继续oracle “killed” 状态的session无法释放的问题，持有的锁可能会堵塞业务，之前有几种情况可以尝试，也有需要要重启实例才能解决的，这里再记录一种oracle 19c RAC的case, “killed” session在操作系统层的进程已不存在。在数据库中尝试kill session也无法正常清理，后台清理进程无法自动清理。

Udev uses the inotify mechanism to watch for changes in the rules directory, in both the library and in the local configuration trees (typically located at /lib/udev/rules.d and /etc/udev/rules.d). So most of the time you don’t need to do anything when you change a rules file.

最近一个比较新鲜的案例，环境ORACLE 2-nodes RAC,有3个PDB 多租户架构，在节点2在仅做了某1个PDB级的PGA大小参数后,实例2 crash,并且，重启node2 db instance后，逐个open PDB, 仅当open 此PDB时，实例2会再次crash, 并提示错误:
2025-04-15T12:33:53.433625+08:00
Errors in file /u01/app/oracle/diag/rdbms/anbob/anbob1/trace/anbob1_lmon_50145.trc:
ORA-29740: evicted by instance number 2, group incarnation 121

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