提供综合数据库运维服务与优化方案(不限Oracle MySQL PG GaussDB GoldenDB OceanBase等), 微信/Tel:(+86)134-365-60330
ob_query_timeout 是 OceanBase 数据库服务器的一个系统变量（System Variable）。它设置在数据库服务端，用于控制在该数据库连接上执行的所有 SQL 查询的最大执行时间。obdumper 是一个独立的客户端工具，它通过 OBDC 或 Java 驱动与数据库建立连接。理论来说也是一个客户端，应该是继承DB的变量设置，但是近期一客户obdumper一提示query timeou超时，且值并非DB级的参数，这是怎么回事？
今天在某个金融客户群看到客户咨询“在Oceanbase数据库中oracle租户，更新clob字段超过4000字符怎么弄？”，我们知道clob可以存储像Varchar类型的字符，如果不使用dbms_lob包处理，可以简单当varchar处理，而varchar的长度又有上限，在oracle和oceanbase中这个问题答案是不同的，下面我来演示。
最近一客户在使用obloader工具，做一个表的恢复时，遇到了下面的错误：
$obloader -h xx -P xx -u xxxx – p ‘xxxx’ -c XXX -t XX – D xx –csv –table xxxx -f xxxxx.csv –external-data
[ERROR] Invalid char between encapsulated token and delimiter. Token Content: ,\E,0,79,\E,\E,. Line[1,18]
近日一客户的oceanbase OCP告警ocp_monagent agent服务不可用，日志显示OOM kill
oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=ocp_monagent,mems_allowed=0-7,oom_memcg=/ocp_agent/ocp_monagent,task_memcg=/ocp_agent/ocp_monagent,task=ocp_monagent,pid=1948228,uid=0
Sep 28 14:00:01 anbob-2 kernel: [25155102.452094] Memory cgroup out of memory: Kill process 1948228 (ocp_monagent) score 1004 or sacrifice child
Oceanbase数据库中同Oracle一样存在一些以“_”开头的隐藏参数，用于功能的开关和微调等作用。目前v4.2.5.3 有491个参数，分为集群级和租户级。隐藏参数226个。
最近有个客户在Oceanbase数据库上有套多租户环境，其中某一个租主insert values失败，提示ORA-00600 internal error code , arguments: -4184: ChunkServer out of disk space 错误， 版本V3.2.3,在 OceanBase 中遇到错误 -4184: ChunkServer out of disk space 表示集群中的某个或多个 ChunkServer 节点磁盘空间不足，导致无法执行写入操作（如 INSERT）,简单记录排查方法。
前一篇记录了《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.
最近有个项目上oracle迁移到ocenabase，但是应用中使用Oracle的数据库内加密函数，数据库中存储的是加密数据，这里有两个注意事项，首先是对于加密函数是否兼容，其次是数据库内的加密数据，如何同步及同步到目标库后已加密码数据能否解密的问题。
Oceanbase中使用 XA 功能时，事务管理器将使用 XA 资源实例来准备和协调每个事务分支，然后适当地提交或回滚所有事务分支。XA 功能的关键组件包括 XA 数据源、XA 连接、XA 资源和事务 ID。概念参考分布式事务概述.
在早期的OB V3版本存在一些问题，如XA异常返回值未被应用捕捉，而影响了业务一致性逻辑；和连接未释放或事务未正常结束问题，尤其在使用oceanbase-client-2.4.7.1驱动时。
数据堪称企业的生命线，任何一次不经意的操作失误都可能引发千万级别的经济损失，甚至招致法律上的责任追究。在今天的分享中，我将从规章制度、技术保障以及人员管理三个维度出发，为大家详细解读——无论是面对从Oracle到国产数据库的运维转型，还是探索国产数据库特有的安全机制时，我们应当注意的关键事项。同时，我们也会探讨在利用大型模型进行知识问答过程中可能出现的风险及其防范措施，旨在帮助大家构建坚固的数据安全防线，确保企业数据资产的安全与稳定。
近期OceanBase发布了单机版 – 小规格/小规模部署安装包，对硬件资源进一步降低，之前我有安装分布式单节点版，Oceanbase V4.2 (企业版) OBD单机安装（CentOS 7.9 Linux VBOX虚拟机），这次单机版邀测, 记录一下安装过程，总体比较感觉比较流畅，安装介质700M左右，一键安装包，几分钟完成。
Oracle DBA都知道Oracle的回收站功能可以做drop table后的flashback操作，目前部分国产数据库在回收站功能上做了truncate table的支持，像GaussDB (ustore), GoldenDB, Oceanbase同样也支持回收站的功能，今天看到一篇文档， 是有人问Oceanbase支持truncate吗？利用deepseek回答的，答案也对，也不对，只是不够严谨，很容易产生错误的后果。
在有些开发习惯中，如查询分页或统计查询，有些开发是基于明细的查询而外层直接加1层汇聚查询，如select count(*) from (select ….)， 但子查询中可能有一些函数或主查询根本不需要的列， 在oracle中的查询转换中如select-project-join或select list pruning， 或VIEW merge SPJ,CVM 都是为了不影响SQL结果一致性，而优化低效的SQL. 但是从oracle迁移到其它数据库中，因为CBO的差异，导致SQL性能大量衰减，需要手动改写SQL， 最近从oracle迁移到pg系国产库，发现一个view中使用了function, 而外部查询根本不关系该列值，就是一个无效的查询列，无意义的函数调用， 需要注意。
最近有个客户在做迁移oracle到Oceanbase时，使用的是原厂的OMS数据迁移同步工具，在迁移或数据同步完数据库发现数据存在差异, 应该是一种基于logminer的log stream形式，发现一张表含有Lob字段在logminer的视图中对应的rowid只有update，没有insert， 经过事务xid的查找发现insert所对应的是ROW_ID为”AAAAAAAAAAAAAAAAAA”,显示这是一个无效的rowid, 如果是基于rowid那同步数据就可能丢失了。我发现oracle11g和23c这方面还有点差异，简单记录。
昨天Oceanbase V4.3发布会，因为工作忙原因无法现场参加学习，近几年国产数据库在快速迭代，无论是bug修复还是功能引进，OB的版本的迭代速度和客户发展速度是值得肯定，但是似乎在稳定性和知识库上还是存在一些问题，就在OB发布会的同一天，我们另一批人因为新上的Oceanbase在焦急的处理着故障，一个租户的内存耗尽，然后级联的活动会话增加,CPU耗尽到重启。SQL限流失败，提示ORA-00600: internal error code, arguments: -4013, No memory or reach tenant memory limit, 查看内存使用率。
在 OceanBase 数据库中，主备副本（Replica）的概念对于理解和优化查询性能非常重要。OceanBase 作为一个分布式数据库系统，通过多副本机制来保证数据的高可用性和容错性。每个数据分区（Partition）都有一个或多个副本，其中一个是主副本（Leader），其他为备副本（Follower）。本篇讨论如何确认某张表的leader 节点？如异常时无leader节点什么原因？
在 OceanBase 数据库中， “Queuing”表指在应用程序或特定业务场景中用于实现队列功能的表。因为OB是LSM Tree分级存储，默认设置下，一张表中删除的行在 OB 每日合并前并不是真的删除，而只是在内存里打了个删除标记，OB major freeze/merge期间才会真正处理为删除。而频繁的堆积”mark for delete”记录，之前的一些如全表扫描的执行计划会出现逐渐变慢问题。
在OceanBase数据库中，有多种维护操作用于确保数据的一致性和提高性能，其中包括冻结（Freeze）、转储（Dump）和合并（Merge）。这些操作对于数据库的健康运行至关重要。下面分别介绍如何查看这些操作的状态和相关信息。
事务按照执行的时间和状态可以分为其他事务、长事务、悬挂事务三种。其中长事务和悬挂事务会导致资源长时间不释放，等待会话长时间被阻塞，“悬挂事务”通常指的是那些未能正常结束的事务，已进入到提交阶段(事务阶段主要有包含初始化、prepare、SQL执行、Commit、Clear)，并且事务的提交时间超过一定阈值的事务, 即事务既没有被”完全”提交（COMMIT）/回滚（ROLLBACK）， 这类事务处于未完成状态，可能会占用数据库资源，并对后续的事务处理产生影响。需要重点关注这类异常的事务。