ANBOB™

数据堪称企业的生命线，任何一次不经意的操作失误都可能引发千万级别的经济损失，甚至招致法律上的责任追究。在今天的分享中，我将从规章制度、技术保障以及人员管理三个维度出发，为大家详细解读——无论是面对从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）。这些操作对于数据库的健康运行至关重要。下面分别介绍如何查看这些操作的状态和相关信息。

在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度大会，作为观察团其一我也想谈谈我的个人理解，收获与感触颇丰，对于一个写了十几年技术博客的技术男，通过一篇描述性短文总结难度不亚于路遥当时写《平凡的世界》那段经典的开头。思来想去，我准备从“看见的”、“看不见的”、“瞬间的”和“永恒的”四个层面简短总结.