如何查找其他session级alter session set修改的参数? Oracle 和Kingbase/HighgoDB(PostgreSQL)

by

ALTER SESSION命令会更改运行时配置参数，仅影响当前会话使用的值，对其他会话或系统级没有影响，有时需要知道某个会话当前的session级参数，在oracle中比较方便，目前postgresql及基于postgresql的国产库如Kingbase、Highgodb中不太容易，这里我演示gdb的方法。

存储磁盘测试工具fio和dd常用场景

by

Linux 系统中有多种工具可用于测试存储设备的 I/O 性能，以下是主要是OS一般自带的dd或FIO (Flexible I/O Tester)，因为数据库是一个对I/O敏感的应用软件，对于云上或虚拟环境有时存储性能不理想，通常需要工具在上线前做基准测试，避免上线后出现数据库性能问题，最近有个客户咨询生产一套达梦DMDPC环境在某云环境IaSS上，业务反应慢的无法接受，怀疑I/O不是很理想， 这里记录几个常用的命令。

Oracle迁移到Oceanbase加密数据注意事项

by

最近有个项目上oracle迁移到ocenabase，但是应用中使用Oracle的数据库内加密函数，数据库中存储的是加密数据，这里有两个注意事项，首先是对于加密函数是否兼容，其次是数据库内的加密数据，如何同步及同步到目标库后已加密码数据能否解密的问题。

Oceanbase 分布事务XA注意事项

by

Oceanbase中使用 XA 功能时，事务管理器将使用 XA 资源实例来准备和协调每个事务分支，然后适当地提交或回滚所有事务分支。XA 功能的关键组件包括 XA 数据源、XA 连接、XA 资源和事务 ID。概念参考分布式事务概述.
在早期的OB V3版本存在一些问题，如XA异常返回值未被应用捕捉，而影响了业务一致性逻辑；和连接未释放或事务未正常结束问题，尤其在使用oceanbase-client-2.4.7.1驱动时。

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

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版本)用于学习，简单记录。