提供综合数据库运维服务与优化方案(不限Oracle MySQL PG GaussDB GoldenDB OceanBase等), 微信/Tel:(+86)134-365-60330
在达梦数据库中，虽然尚未提供完全对等的细粒度跟踪机制，但同样支持类似慢日志记录功能。通过开启相关库级日志，可将关键执行信息记录到日志文件中，包括：, 事务、执行时间、执行用户、客户端IP、SQL文本，客户端工具等会话信息。随后，可使用达梦提供的 dmlog 工具对日志进行分析（支持异地分析），并生成可视化图表。分析结果可按执行时间、逻辑读、物理读等维度排序，呈现类似 Oracle AWR 报告中的“Top SQL by XXX”视图，便于快速识别性能热点 SQL，辅助应用优化与问题排查。
在 PostgreSQL系数据库中(含GaussDB for OpenGauss)，pg_stat_database 视图中的 xact_rollback 计数器表示 事务回滚（rollback）的次数。当这个值增加时，意味着数据库中发生了事务回滚操作。今日有客户的数据库环境监控了该指标，提示回滚率过高，谈谈我的看法。
最近一个朋友在测试Oracle GoldenGate（V12）从oracle 19c到kafka同步时，extract, pump进程都正常，extract有抽取到，但是pump进程running无投递数据。在我修改pump进程从某文件的时间开始后，再次启动终于提示了错误信息：
ERROR OGG-02650 Source wildcard specification USER1.T1 does not include a catalog name, but the source table name PDB1.USER1.T1includes a catalog name.
众所周知数据库的DML操作会记录在REDO日志中，如果开了归档REDO可以存储的更久，有时当闪回查询无法使用，或需要从日志中挖掘过去某操作时间或操作人信息，做恢复依据。在oracle提供数据库挖掘logminer使用dbms_logmnr, 在国产数据库达梦中同样支持，而且语法和oracle几乎一样。
前一篇记录了《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跟踪生成更多的诊断信息。
在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.
ALTER SESSION命令会更改运行时配置参数，仅影响当前会话使用的值，对其他会话或系统级没有影响，有时需要知道某个会话当前的session级参数，在oracle中比较方便，目前postgresql及基于postgresql的国产库如Kingbase、Highgodb中不太容易，这里我演示gdb的方法。
Linux 系统中有多种工具可用于测试存储设备的 I/O 性能，以下是主要是OS一般自带的dd或FIO (Flexible I/O Tester)，因为数据库是一个对I/O敏感的应用软件，对于云上或虚拟环境有时存储性能不理想，通常需要工具在上线前做基准测试，避免上线后出现数据库性能问题，最近有个客户咨询生产一套达梦DMDPC环境在某云环境IaSS上，业务反应慢的无法接受，怀疑I/O不是很理想， 这里记录几个常用的命令。
最近有个项目上oracle迁移到ocenabase，但是应用中使用Oracle的数据库内加密函数，数据库中存储的是加密数据，这里有两个注意事项，首先是对于加密函数是否兼容，其次是数据库内的加密数据，如何同步及同步到目标库后已加密码数据能否解密的问题。
Oceanbase中使用 XA 功能时，事务管理器将使用 XA 资源实例来准备和协调每个事务分支，然后适当地提交或回滚所有事务分支。XA 功能的关键组件包括 XA 数据源、XA 连接、XA 资源和事务 ID。概念参考分布式事务概述.
在早期的OB V3版本存在一些问题，如XA异常返回值未被应用捕捉，而影响了业务一致性逻辑；和连接未释放或事务未正常结束问题，尤其在使用oceanbase-client-2.4.7.1驱动时。
最近时常有些负责数据库运维客户或企业的IT管理者开始为国产化后的运维配置担忧，会咨询我们做的快的行业客户，他们现在运维几个人？已经察觉到国产化带来的运维复杂度提升，希望我们列几个“理由”，解释国产化改造后为什么需要增加运维人员，说服高层管理者，因为部分高层对国产的认识是来自原厂或标杆成功案例的宣传，继续逐年“降本”减少运维投入。
Serial apply =使用1个apply会话应用, 但是源数据库：有多个连接和多个并发事务， 这样会存在多个生产端一个消费端，这样串行应用因为无法扩展，当源库事务量大时，应用端会出现应用慢，同步延迟增加的现象。
OGG也一直在该方向创新，以提升速度，如抽取端可以使用集成抽取，可以拆成多个抽取任务，应用端可以手动拆成多个应用进程， 和Integrated Replicat、Parallel Nonintegrated Replicat、Parallel Integrated Replicat。
在数据库中文本的模糊查询是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)