ANBOB™

昨天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）。这些操作对于数据库的健康运行至关重要。下面分别介绍如何查看这些操作的状态和相关信息。

在OceanBase数据库中， 数据库事务分为普通事务和分布式事务。长事务和悬挂事务会导致资源长时间不释放，等待会话长时间被阻塞，“悬挂事务”通常指的是那些未能正常结束的事务，即事务既没有被成功提交（COMMIT），也没有被回滚（ROLLBACK），如同oracle数据库中的dba_2pc_pending两阶段的分布式事务。 这类事务处于未完成状态，可能会占用数据库资源，并对后续的事务处理产生影响。需要重点关注这类异常的事务。

在Oceanbase数据库日常运维中，像oracle一样数据库的存储空间当到在上限时会在日志或ocp中提示预警，可能磁盘空间物理大小限制或DB参数限制， 分析空间不足的原因在分布式数据库OCEANBASE中相比ORACLE要复杂一些， 如何查看当前的使用大小？ 是哪一类文件占用较大？ 如果是temp文件是DDL 还是SQL 查询产生的？ 有没有可能temp文件泄露没有释放？如何定位temp使用高？ 本篇仅记录一些方法

在十年前简单测试过oracle 9i 的加密解密用法之dbms_obfuscation_toolkit(二)，其中有md5单向加密， 最近在oracle迁移到opengauss项目中用到了md5， 这里简单记录替换方案，在pg或og中直接就有md5 function. 在mysql及Mysql系的产品和ocenabse, 达梦一样存在该函数md5。

在ORACLE中，SQL Profile 是对 SQL 语句文本的数据库级匹配。由于相同的 SQL 文本在不同用户下可能会受到影响，因此需要一些方法来避免这种情况。OceanBase 提供了 outline 功能，可以用于固定执行计划。那么在 OceanBase 中是否存在与 ORACLE 类似的、影响不同用户的问题呢？多个用户的相同 SQL 语句和相同的表是否共享同一个 outline 呢？outline 是全库共享的还是用户级私有的？

在关系数据库性能优化技术中，有时存在数据库优化器评估问题，产生了错误的执行计划或执行计划改变，导致SQL执行效率变差，在无法或短时间内修改应用SQL代码时，需要从数据库端快速固定指定的执行计划，问题:
多个用户多个table(含索引)相同结构，对于相同的SQL文本，是否会互相影响？
多个用户相同的table， 对于相同的SQL文本，是否会互相影响？

数据是企业的重要生产要素，确保数据不丢失是大多数客户的核心目标。然而，要实现这一目标的高可用容灾方案不仅依赖于数据库产品的架构支持，还需要硬件成本的投入。同城双机房的配置在客户中较为普遍，如果追求RPO=0，无论是分布式数据库还是集中式数据库，个人了解到目前主流的数据库使用架构

在学习OceanBase时，测试环境是必不可少的。我在个人笔记本电脑（18核CPU，32GB内存）上的VBOX虚拟机中创建了一个配置为8核CPU、16GB内存和100GB磁盘空间的虚拟机，并在其上安装了OceanBase V4.2.1环境（Oracle租户），以便后续进行语法研究。以下是安装过程的简单记录。

OceanBase v4作为一款分布式关系型数据库，提供了与Oracle数据库相似的LOB（Large Object）类型支持，包括BLOB（Binary Large Object）、CLOB（Character Large Object）以及NCLOB（National Character Large Object）。这些数据类型主要用于存储大量文本、图像、JSON、地理信息等非结构化或半结构化数据。在从 Oracle 迁移到 OceanBase 时，需要关注LOB对象的存储类型和属性，确保它们在OceanBase中得到适当的处理。我们所说的兼容性不仅包括类型兼容，还包括语法语义和行为兼容。如果 OceanBase 的限制比 Oracle 更宽松，则迁移过程可以正常进行。但如果 OceanBase 的限制更严格，则可能会导致数据无法迁入目标数据库。

OceanBase Database也同oracle一样支持partition table，但存在一些注意事项，甚至和oracle存在一些差异。分布式数据库的数据打散方式并不相同， 分布数据基于组规则到不同的物理区，在Oceanbase中以 Partition粒度分布到不同的OB SERVER节点，Oracle mode 的OceanBase Database可以创建65536个分区partition，也可以创建subpartition, Table的分区列又叫分区键( partitioning key), 分区键必须是PK和UK的子集或者是说主键唯一键必须包含分区键。

在业务租户内存结构中有个内存区叫做memstore, 主要用于保存数据库增量数据,对应MemTable属性，众所周知OB是基于LSM-tree存储引擎，数据分为磁盘上的静态数据（SSTable）、内存的增量数据（MEMTable）、以及记录事务的日志. 内存中的数据需要制定一些策略，控制从内存刷到磁盘，如同oracle的checkpoint, 在OB中叫做转储, 转储可能会产生I/O的较大影响，当然不希望业务高峰期做转储操作，这样就需要对MEMSTOR使用做监控

昨天我有幸受邀去上海参加了的OceanBase开发者2024度大会，作为观察团其一我也想谈谈我的个人理解，收获与感触颇丰，对于一个写了十几年技术博客的技术男，通过一篇描述性短文总结难度不亚于路遥当时写《平凡的世界》那段经典的开头。思来想去，我准备从“看见的”、“看不见的”、“瞬间的”和“永恒的”四个层面简短总结.

事务隔离级别是数据库事务处理的基础，ACID 中的 “I”，即 Isolation，指的就是事务的隔离性。ANSI/ISO SQL 标准定义了4 种事务隔离级别，对于相同的事务，采用不同的隔离级别分别有不同的结果。这些隔离级别是根据3 个“现象”定义的，

众所周知，在MySQL中通常建议增加主键，如MySQL的innoDB存储引擎一种索引组织表（B+tree）的形式，如果未指定主键时？数据库会自动创建隐藏PK索引（6字节）做为CLUSTER PRIMARY KEY，像达梦数据库默认也是这种B+Tree组织形式。OceanBase企业租户目前有两种兼容模式，兼容 Oracle 或 MySQL。无论是Oracle租户还是MySQL租户，同样在创建表时如果未指定PK， 会自动创建一个隐藏的自增列PK。这里演示如何查询隐藏自增列值?

前几天看到有OB用户留言，提到OceanBase很可能是出于对他们需求的考虑，而应用中以前对ORACLE报错的依赖。这表明现在数据库厂家在满足各种甲方要求时也颇为无奈，在应用的兼容性上做了种种让步。就对于会话1事务中，会话2 select for update nowait相同的报错场景，我简单测试一下在其它国产库上是否还不如Oceanbase. 为了方便横向对比，这里我再简单的附上ORACLE 与OB的报错。

故事从一个客户正在将数据库平台从Oracle迁移到OceanBase的过程中说起。在并轨生产运行过程中，应用报告了ORA-54错误号，这让Oracle的数据库管理员感到震惊，并花费了大量时间来进行分析。然而，他们最终发现这个错误是由OceanBase的驱动程序报出的。在尤其有些客户一点儿问题全中心排查躁动，这类报错让Oracle DBA分析oracle数据库，确实会让人要想爆粗，浪费了甲方的付费的乙方资源，同时还不利于故障定位。 下面对比一下oracle和oceanbase的resource busy报错。

在关系数据库中两表关联在oracle中使用IN( subquery)的语法很常见， 但kevin发现在MySQL中subquery使用MAX聚合参数时，会导致主查询Full scan而无法使用索引范围扫描, 当遇到大表时可能性能下降明显 ，测试发现有的库使用子查询做为驱动表，有的是使用filter从主查询过滤。下面简单测试。