weejar zhang

oracle ACE, A DBA, blogger.

在数据库国产化改造后，为什么运维人员需要增加？

by

最近时常有些负责数据库运维客户或企业的IT管理者开始为国产化后的运维配置担忧，会咨询我们做的快的行业客户，他们现在运维几个人？已经察觉到国产化带来的运维复杂度提升，希望我们列几个“理由”，解释国产化改造后为什么需要增加运维人员，说服高层管理者，因为部分高层对国产的认识是来自原厂或标杆成功案例的宣传，继续逐年“降本”减少运维投入。

Oracle GoldenGate Parallel Replication

by

Serial apply =使用1个apply会话应用, 但是源数据库：有多个连接和多个并发事务， 这样会存在多个生产端一个消费端，这样串行应用因为无法扩展，当源库事务量大时，应用端会出现应用慢，同步延迟增加的现象。

OGG也一直在该方向创新，以提升速度，如抽取端可以使用集成抽取，可以拆成多个抽取任务，应用端可以手动拆成多个应用进程， 和Integrated Replicat、Parallel Nonintegrated Replicat、Parallel Integrated Replicat。

HighgoDB (PostgreSQL)利用pg_trgm的gin索引优化前后模糊查询

by

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

HighgoDB (PostgreSQL) %SYS CPU newfstatat() high 调优一例(终篇)

by

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

Troubleshooting Oracle RMAN duplicate Dataguard failed with ORA-17628 19505 ORA-27040

by

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

Troubleshooting Oracle 19c RAC DB crash after ora-600 [kjblpgorm:!antilock] and DB start fail with Ora-600 [kfmdPriRegRclient04]

by

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

HighgoDB (PostgreSQL) %SYS CPU newfstatat() high 调优一例

by

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

Alert: PostgreSQL JDBC 记得配置Fetch Size

by

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

PostgreSQL的事务回卷

by

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)

PostgreSQL Explain analyze命令输出的Execution Time不等于Response TIME

by

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

PL/SQL run error after Migrate Oracle from Windows To Linux using dataguard switchover

by

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 database Life Cycle Support 23ai, 19c,18c, 12cR2, 11g

by

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

GaussDB 单机版（505）ARM安装体验

by

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

PostgreSQL系(GaussDB、KingBase…) 在 SELECT 和 TRUNCATE之间lock冲突

by

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

改变操作系统时间对Oracle RAC的影响

by

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

How to release still “killed“ status session in v$session? (释放killed的session) (五)

by

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