达梦数据库日志挖掘(Similar to Oracle logminer)
众所周知数据库的DML操作会记录在REDO日志中，如果开了归档REDO可以存储的更久，有时当闪回查询无法使用，或需要从日志中挖掘过去某操作时间或操作人信息，做恢复依据。在oracle提供数据库挖掘logminer使用dbms_logmnr, 在国产数据库达梦中同样支持，而且语法和oracle几乎一样。
weejar zhang
Oceanbase中的 Optimizer trace Event （Similar to Oracle 10053 event）
前一篇记录了《Oceanbase中的Session SQL Trace DBMS_MONITOR （Similar to Oracle 10046 event）》， 这里我简单记录Oracle 诊断SQL问题时的另一个常用event 10053在Oceanbase中的体验， 对应的是dbms_xplan.enable_opt_trace(); 使用SET_OPT_TRACE_PARAMETER 配置当前session。下面记录如果OCEANBASE 优化器没有产生预期的执行计划时，如何使用trace跟踪生成更多的诊断信息。
Oceanbase中的Session SQL Trace DBMS_MONITOR （Similar to Oracle 10046 event）
在oracle中诊断session级SQL执行跟踪是最常见的SQL Trace的方法有很多，如sql_trace、10046 event, DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION, DBMS_SUPPORT.START_TRACE, DBMS_MONITOR.SESSION_TRACE_ENABLE 还有Oracle 11g 后更加灵活的Events++ 语法， 甚至还有围绕trace file 解读的一堆工具，如trprof, TRCSESS , tvdxtat, 10046.pl, orasrp等工具。但在国产数据库中生态工具并不完善，之前记录过达梦的10053 event, 这里简单记录Oceanbase 数据库中配置 session SQL Trace使用DBMS_MONITOR的方法OB_SESSION_TRACE_ENABLE，功能基本雷同Oracle DBMS_MONITOR的 SESSION_TRACE_ENABLE.
如何查找其他session级alter session set修改的参数? Oracle 和Kingbase/HighgoDB(PostgreSQL)
ALTER SESSION命令会更改运行时配置参数，仅影响当前会话使用的值，对其他会话或系统级没有影响，有时需要知道某个会话当前的session级参数，在oracle中比较方便，目前postgresql及基于postgresql的国产库如Kingbase、Highgodb中不太容易，这里我演示gdb的方法。
存储磁盘测试工具fio和dd常用场景
Linux 系统中有多种工具可用于测试存储设备的 I/O 性能，以下是主要是OS一般自带的dd或FIO (Flexible I/O Tester)，因为数据库是一个对I/O敏感的应用软件，对于云上或虚拟环境有时存储性能不理想，通常需要工具在上线前做基准测试，避免上线后出现数据库性能问题，最近有个客户咨询生产一套达梦DMDPC环境在某云环境IaSS上，业务反应慢的无法接受，怀疑I/O不是很理想， 这里记录几个常用的命令。
Oracle迁移到Oceanbase加密数据注意事项
最近有个项目上oracle迁移到ocenabase，但是应用中使用Oracle的数据库内加密函数，数据库中存储的是加密数据，这里有两个注意事项，首先是对于加密函数是否兼容，其次是数据库内的加密数据，如何同步及同步到目标库后已加密码数据能否解密的问题。
Oceanbase 分布事务XA注意事项
Oceanbase中使用 XA 功能时，事务管理器将使用 XA 资源实例来准备和协调每个事务分支，然后适当地提交或回滚所有事务分支。XA 功能的关键组件包括 XA 数据源、XA 连接、XA 资源和事务 ID。概念参考分布式事务概述.
在早期的OB V3版本存在一些问题，如XA异常返回值未被应用捕捉，而影响了业务一致性逻辑；和连接未释放或事务未正常结束问题，尤其在使用oceanbase-client-2.4.7.1驱动时。
在数据库国产化改造后，为什么运维人员需要增加？
最近时常有些负责数据库运维客户或企业的IT管理者开始为国产化后的运维配置担忧，会咨询我们做的快的行业客户，他们现在运维几个人？已经察觉到国产化带来的运维复杂度提升，希望我们列几个“理由”，解释国产化改造后为什么需要增加运维人员，说服高层管理者，因为部分高层对国产的认识是来自原厂或标杆成功案例的宣传，继续逐年“降本”减少运维投入。
Oracle GoldenGate Parallel Replication
Serial apply =使用1个apply会话应用, 但是源数据库：有多个连接和多个并发事务， 这样会存在多个生产端一个消费端，这样串行应用因为无法扩展，当源库事务量大时，应用端会出现应用慢，同步延迟增加的现象。
OGG也一直在该方向创新，以提升速度，如抽取端可以使用集成抽取，可以拆成多个抽取任务，应用端可以手动拆成多个应用进程， 和Integrated Replicat、Parallel Nonintegrated Replicat、Parallel Integrated Replicat。
HighgoDB (PostgreSQL)利用pg_trgm的gin索引优化前后模糊查询
在数据库中文本的模糊查询是ES等数据库的强项，但在关系型数据库中也有一些手段，如后缀%普通索引就可以使用，前缀可以创建reverse反转索引，但是前后模糊的话，在oracle中可以创建索引使用index full scan+加回表查询，今天发现在PostgreSQL中还有pg_trgm扩展，配合GIN索引有不错的性能表现。
HighgoDB (PostgreSQL) %SYS CPU newfstatat() high 调优一例(终篇)
前不久整理了一《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
最近有个客户在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]
最近有个客户的oracle 19c 3nodes RAC 有一个节点意外crash ORA-600 kjblpgorm:!antilock, 启动时报ORA-600[kfmdPriRegRclient04]，并启动过程中重导致之前的幸存节点hang并且重启，Oracle 的基础版本bug 比较多，找我分析并临时解决了该问题，简单记录该问题。
Exadata （21.2.0） Automatic Recovery from Disk Controller Cache Failure
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.
HighgoDB (PostgreSQL) %SYS CPU newfstatat() high 调优一例
最这我们一个客户从oracle迁移到postgresql系的某国产数据库后，CPU一直接近100%, 但是再仔细分析，发现%system CPU占到60%左右，当然这是一种不正常的现象，之前我写过《如何在 Linux 上诊断高 %Sys CPU》， 使用pidstat 确认%sys cpu进程大部分为postgresql进程，pstack 查看发现call, PostgreSQL 的线程大部分时间都在调用 newfstatat()，这 不是正常现象，并且通常意味着数据库运行中存在 频繁的文件状态检查（stat）操作，严重时可能导致性能瓶颈。
Alert: PostgreSQL JDBC 记得配置Fetch Size
在使用PostgreSQL JDBC处理大型结果集时，正确配置fetch size对于优化性能和内存使用至关重要。最近我们在国产化改造过程中总有一些差异导致应用性能问题，有时不只在数据库还可能在驱动中，如分页查询或其他OLTP场景，我们总希望尽快的返回结果，这里我分享一下Oracle和Postgresql JDBC 默认fetchsize 从服务向客户端发送数据的差异。
PostgreSQL的事务回卷
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
我们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
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本地机器码，换平台后不认证，简单记录解决方法
Troubleshooting Oracle Top event ‘gc index operation’
今天一个客户的oracle 19c（19.17）环境显示top event中出现了一个比较稀奇的event ‘gc index operation’, 也可能是12cR2 RAC新特性”fast index split wait”引入的相同问题， 19c前已知bug常发生成 BASICFILE LOB 对象上，仅记录.