# OceanBase运维避坑案例整理
> 整理自用户提供的《新炬运维避坑指南合集》41 篇离线文章。按案例涉及的主要技术归类，归纳原文中的现象、排查处置和建议；案例措施仅代表原文环境，执行前应按当前版本、拓扑和变更流程复核。
共整理 **78 个案例**。期数按专辑标题编号；来源链接取自离线文章元数据。
[查看或下载 Markdown 原稿](新炬运维避坑案例整理.md)
## 案例目录
- [第 40 期｜OceanBase 多次出现单台OBserver主机CPU打爆问题分析](#case-1)
- [第 39 期｜OceanBase DDL执行失败问题分析](#case-2)
- [第 39 期｜OceanBase 活跃内存超限问题分析](#case-3)
- [第 39 期｜oceanbase ocp无法正常使用问题分析](#case-4)
- [第 38 期｜OceanBase OMS迁移数据问题分析](#case-5)
- [第 38 期｜OceanBase clog增长异常问题分析](#case-6)
- [第 38 期｜OceanBase SYS租户CPU使用率高问题分析](#case-7)
- [第 38 期｜OceanBase 设置leader命令导致异常问题分析](#case-8)
- [第 38 期｜OceanBase 批量删除SQL导致租户ResultSet内存模块异常](#case-9)
- [第 37 期｜OceanBase OMS工具在做增量同步时存在丢数据的情况问题分析](#case-10)
- [第 35 期｜OceanBase 使用like查询结果异常](#case-11)
- [第 35 期｜OceanBase 查询结果不一致](#case-12)
- [第 34 期｜OceanBase 生僻字在gbk下规避问题](#case-13)
- [第 34 期｜OceanBase 租户CPU抖动问题](#case-14)
- [第 34 期｜OceanBase 程序启动异常](#case-15)
- [第 34 期｜OceanBase 合并超时问题](#case-16)
- [第 34 期｜OceanBase 黑屏删除集群导致OCP功能不可用](#case-17)
- [第 29 期｜OceanBaseCPU性能下降问题分析](#case-18)
- [第 29 期｜OceanBasers异常切主问题分析](#case-19)
- [第 29 期｜OceanBase高并发问题分析](#case-20)
- [第 29 期｜OceanBasecpu使用率问题分析](#case-21)
- [第 29 期｜OceanBaseSQL查询超时问题分析](#case-22)
- [第 29 期｜OceanBase存过执行超时问题分析](#case-23)
- [第 29 期｜OceanBasecpu使用率高问题分析](#case-24)
- [第 29 期｜OceanBaseXA事务打高observer cpu问题分析](#case-25)
- [第 29 期｜OceanBase数据库出现大量慢SQL问题分析](#case-26)
- [第 29 期｜OceanBasenvl函数无返回问题分析](#case-27)
- [第 25 期｜OceanBase数据库迁移后高耗SQL](#case-28)
- [第 25 期｜OceanBase数据库进程启动失败](#case-29)
- [第 25 期｜OceanBase数据库DtlIntermRes内存问题](#case-30)
- [第 25 期｜OceanBase数据库语句没有结果返回](#case-31)
- [第 25 期｜OceanBase数据库程序报错](#case-32)
- [第 25 期｜OceanBase数据库obproxy异常](#case-33)
- [第 25 期｜OceanBase数据库oms链路延迟](#case-34)
- [第 25 期｜OceanBase数据库提前转储](#case-35)
- [第 25 期｜OceanBase数据库登录慢](#case-36)
- [第 25 期｜OceanBase数据库至灾备集群后部分应用验证失败](#case-37)
- [第 24 期｜OceanBase数据库全备失败问题分析](#case-38)
- [第 24 期｜OceanBase数据库网络瞬断导致两套集群rs处于无主状态](#case-39)
- [第 24 期｜OceanBase数据库执行SQL报错分析](#case-40)
- [第 19 期｜OceanBase误操作删除表处置](#case-41)
- [第 19 期｜OceanBase集群执行脚本效率下降](#case-42)
- [第 19 期｜（OceanBase）proxy无法纳管集群处置](#case-43)
- [第 19 期｜OceanBase磁盘使用率忽然升高](#case-44)
- [第 19 期｜OceanBase某租户CPU 100%问题](#case-45)
- [第 19 期｜OceanBase oms全量迁移卡住](#case-46)
- [第 19 期｜OceanBase oms迁移数据中全量组件异常中断](#case-47)
- [第 19 期｜OceanBase 数据库主机宕机](#case-48)
- [第 17 期｜Oceanbase 备份恢复失败](#case-49)
- [第 16 期｜租户的占用内存大小超限分析](#case-50)
- [第 16 期｜迁移速度变慢分析](#case-51)
- [第 16 期｜OB集群从OCP中无法迁出](#case-52)
- [第 16 期｜OMS迁移ROWID类型数据](#case-53)
- [第 15 期｜OCP主机与OB主机检验时钟差过大问题分析](#case-54)
- [第 15 期｜正向链路仅同步表结构，反向回流报错](#case-55)
- [第 15 期｜回流导致OB节点CPU使用率超高](#case-56)
- [第 15 期｜回流链路报错处理](#case-57)
- [第 15 期｜集群状态检测异常分析](#case-58)
- [第 14 期｜Oceanbase OAT 报密码验证失败问题分析](#case-59)
- [第 14 期｜Oceanbase oms增量迁移延迟处理](#case-60)
- [第 13 期｜oceanbase sql执行计划变更，导致cpu使用率打满](#case-61)
- [第 13 期｜oceanbase主备延迟](#case-62)
- [第 13 期｜Oceanbase sql执行慢分析处置](#case-63)
- [第 12 期｜OceanBase OAT中添加主机报错处置](#case-64)
- [第 9 期｜OceanBase迁移过程中影响源生产库性能](#case-65)
- [第 9 期｜OceanBase备份失败](#case-66)
- [第 9 期｜OceanBase表存在clob字段，导致查询效率极低](#case-67)
- [第 7 期｜OceanBase误删除核心表处置](#case-68)
- [第 7 期｜OceanBase服务器资源紧张处置](#case-69)
- [第 7 期｜OceanBase SQL远程计划SPF变慢](#case-70)
- [第 6 期｜OBserver主机CPU 100%](#case-71)
- [第 5 期｜OCEANBASE集群合并超时](#case-72)
- [第 4 期｜OCEANBASE数据库批量入库报4002处置](#case-73)
- [第 4 期｜OCEANBASE归档日志延迟处置](#case-74)
- [第 2 期｜Oceanbase数据库突然hang死](#case-75)
- [第 2 期｜Oceanbase数据库表不大，但查询突然变慢](#case-76)
- [第 1 期｜ORACLE-OceanBase二阶段事务锁处理](#case-77)
- [第 1 期｜Oceanbase悬挂事务导致异常处置](#case-78)
## 第 40 期｜OceanBase 多次出现单台OBserver主机CPU打爆问题分析
- 专辑文件：`02.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247567656&idx=1&sn=48de376653bfb9065a300abe1d26e315&chksm=f85147bae7ff69ea5e36646df0abaa51bb9cac0106ec5f7eac5bba01ec65597665b3f4655238#rd)
- **现象：** 某日月结当晚，某OCEANBASE数据库多次出现单台OBserver主机CPU打爆的情况，影响业务资料刷速率。
- **处置过程：** 某日月结当晚，某场地接到一套OCEANBASE v3.2.4.5数据库CPU使用率超限的告警。；经确认为资料刷新P类数据量突增导致，高并发执行sql，瞬时采样高峰在200个并发左右，与出账业务侧人员沟通停止部分刷新进程后，OBSERVER主机CPU逐渐恢复正常。
- **运维建议：** 后续在资料刷新业务表上创建最佳联合索引，核查相关sql：substr('${SQL_PARAM}',0,instr('${SQL_PARAM}','|',1,1)-1)只有部分类的绑定变量可以走最优执行计划，其余还是硬解析；业务侧将字符串截取逻辑改到程序中处理，而不是在sql中处理，进一步减少数据库性能开销；最终月结高并发场景下未再出现CPU打爆情况，问题解决
## 第 39 期｜OceanBase DDL执行失败问题分析
- 专辑文件：`03.html`，第 5 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247567258&idx=1&sn=cb8acfe46934b2308d8a1d2fdffbd82d&chksm=f86bd7bd1375aa91592abd5c32a6a03bcf4bf5511b5019700146f1431f58d23e38d09f81e217#rd)
- **现象：** 测试集群执行DDL语句，报-4694内部错误，DDL执行失败。
- **处置过程：** 查询官网，DDL失败可能原因是集群合并未完成导致；定位合并异常Server；定位到具体合并失败 Zone
- **运维建议：** 根据错误编号，可以到官网搜索，确认故障定位方向；主机层面在集成阶段，要确保配置满足OB官方要求(时钟同步/BIOS配置/挂载参数要求等)，可减少后期维护问题
## 第 39 期｜OceanBase 活跃内存超限问题分析
- 专辑文件：`03.html`，第 6 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247567258&idx=1&sn=cb8acfe46934b2308d8a1d2fdffbd82d&chksm=f86bd7bd1375aa91592abd5c32a6a03bcf4bf5511b5019700146f1431f58d23e38d09f81e217#rd)
- **现象：** 活跃内存超限导致ddl和insert语句被限流。
- **处置过程：** 检查转储状态；oceanbase.__all_virtual_minor_freeze_info；where svr_ip=
- **运维建议：** 长事务会占用锁及内存资源，活跃内存紧张时，转储的表存在长事务未及时提交，会导致转储被卡住；集群存在长事务超1小时，应及时抓取sql，反馈给业务侧整改
## 第 39 期｜oceanbase ocp无法正常使用问题分析
- 专辑文件：`03.html`，第 10 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247567258&idx=1&sn=cb8acfe46934b2308d8a1d2fdffbd82d&chksm=f86bd7bd1375aa91592abd5c32a6a03bcf4bf5511b5019700146f1431f58d23e38d09f81e217#rd)
- **现象：** 测试环境OCP的docker容器丢失，导致ocp无法正常使用，后续得知为两清两固测试，限制的ssh等方式，导致整个OCP的observer跟ocp无法使用。
- **处置过程：** 首先让ssh等限制解除，尝试恢复，通过OAT平台跟主机上ps抓取服务发现observer服务恢复正常，查看ocp的docker是否恢复正常，检查发现docker容器配置文件损坏，无法恢复。；于是将原来损坏的docker容器卸载，通oat重新创建一个metadb和ocp容器，到原来已损坏的ocp环境中的主机上将agent卸载，通过新创的ocp接管，接管成功后恢复。；整理 OCP 容器故障应急处置手册，明确 “容器损坏、无法启动” 的（卸载 - 重建 - 接管），提升运维人员处置效率。
- **运维建议：** 测试前评估；任何系统级、安全类测试（如两清两固），必须提前梳理影响范围，明确是否涉及 OCP、observer 等核心组件，制定组件保护方案。；定期备份 OCP docker 容器镜像、配置文件、metadb 数据，确保容器损坏后可快速恢复，避免重新创建的繁琐操作。
## 第 38 期｜OceanBase OMS迁移数据问题分析
- 专辑文件：`04.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247566942&idx=1&sn=beb8d9dedea5fbd7b5f81620ec6c1ee9&chksm=f88cfa4e3c4c1978f4683d85661e69ba8b3c849532f6c72297a026479f161a1222e1a769f6c5#rd)
- **现象：** 迁移对象在DbCat 响应中不存在。
- **处置过程：** 查看oms的dbcat日志，可以定位到内部sql执行报-4258；/home/admin/logs/ghana/Ghana/dbcat.log；在源端业务租户执行日志中的sql同样报-4258
- **运维建议：** 迁移前必须做元数据质量检查；字段注释、表注释是 OMS 采集元数据的关键依赖，注释中存在乱码、特殊不可见字符会直接导致元数据查询失败，引发迁移中断 / 数据丢失。；迁移前必须检查
## 第 38 期｜OceanBase clog增长异常问题分析
- 专辑文件：`04.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247566942&idx=1&sn=beb8d9dedea5fbd7b5f81620ec6c1ee9&chksm=f88cfa4e3c4c1978f4683d85661e69ba8b3c849532f6c72297a026479f161a1222e1a769f6c5#rd)
- **现象：** 某套集群近半个月clog增长异常。
- **处置过程：** 解析1分钟的clog日志；发现主要的问题表为sp_workf_comm表，1分钟的clog产生量sp_workf_comm大概是270M。；查询ocp视图
- **运维建议：** 针对所有核心 SQL，设置执行频次、事务量阈值告警；偏离基线 20% 即触发提醒；；常态化监控核心表的 clog 产生量，建立 clog 增长基线
## 第 38 期｜OceanBase SYS租户CPU使用率高问题分析
- 专辑文件：`04.html`，第 3 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247566942&idx=1&sn=beb8d9dedea5fbd7b5f81620ec6c1ee9&chksm=f88cfa4e3c4c1978f4683d85661e69ba8b3c849532f6c72297a026479f161a1222e1a769f6c5#rd)
- **现象：** 某库SYS租户CPU使用率高。
- **处置过程：** 查看ocp的等待队列耗时；可以看到10:34~12:22期间SYS租户的处理性能较低数据库出现队列积压，同时RPC吞吐量入口流量在此期间也出现异常突增的情况，优先排查网络问题；查看sys主节点的网络情况
- **运维建议：** 建立 SYS 租户多维度联动监控面板；覆盖 CPU 使用率、RPC 吞吐量、网络丢包 / 延迟、SQL执行（时间、频次），设置基线告警，异常时自动关联相关指标，提升定位效率。；规范监控 SQL 管理
## 第 38 期｜OceanBase 设置leader命令导致异常问题分析
- 专辑文件：`04.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247566942&idx=1&sn=beb8d9dedea5fbd7b5f81620ec6c1ee9&chksm=f88cfa4e3c4c1978f4683d85661e69ba8b3c849532f6c72297a026479f161a1222e1a769f6c5#rd)
- **现象：** 搭建异地ocp备集群执行多次设置leader命令导致异常。
- **处置过程：** 因为是后接入备ocp，需要在搭建好备ocp后，生产端ocp在一开始搭建时没有开启多集群模式，所以在搭建备ocp需要开启多集群模式，在搭建好备ocp后先把主ocp激活为leader，备集群激活为follower节点 ，但在改造多集群模式激活leader节点时执行了一遍 enableMc 1 ocp1 LEADER但执行的ocp_id\ocp_cluster_name觉得有误，后又执行了一遍enableMc 1689942205 metadb LEADER，之后去执行备ocp激活为多集群模式为follower节点。之后去重启主备的ocp容器。；重启之后发现ocp白屏很久没有启动成功，在ocp启动日志中发现如下报错；BeanCreationException: Errorcreating bean with nameoc…
- **运维建议：** 规范关键命令操作；执行enableMc等多集群相关命令前，核对ocp_id、ocp_cluster_name参数；执行后查询mc_ob_cluster表，确认配置无误，严禁重复执行。；制定多集群改造标准流程
## 第 38 期｜OceanBase 批量删除SQL导致租户ResultSet内存模块异常
- 专辑文件：`04.html`，第 5 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247566942&idx=1&sn=beb8d9dedea5fbd7b5f81620ec6c1ee9&chksm=f88cfa4e3c4c1978f4683d85661e69ba8b3c849532f6c72297a026479f161a1222e1a769f6c5#rd)
- **现象：** 某集团成员批量删除SQL导致租户ResultSet内存模块异常，导致集群、业务报错异常。；测试环境复现该业务，和生产一致resultset模块持续升高，当时观察到该sql的SQL_ID是没有的，比较奇怪，；生产上不看文本直接抓sql_id的话也是对应不上该SQL，后面找研发确认为该sql一直处于SQL解析阶段，没有到执行阶段，索引plancache也无法找到，只能SQLaduit中通过query找，或者processlist里面的info字段看文本才能找到，后面研发也确认该SQL用了in and in的语法，因为in中的变量又比较多，数据库生成按主键/索引做范围扫描的计划时，每个「扫描范围」对应一段连续的主键区间。要精确只扫到这些点、不丢也不多扫，就必须知道每一个满足条件的组合，需要精确扫描就必须枚举这些组合，枚举…
- **处置过程：** 某库3月4号10:18~10:26时间的出现大范围业务不能办理和查询。；10:19:02分出现cpu达到100%告警，数据库出现大量慢SQL，期间发现其中一个节点的memstore内存被挤占，怀疑内存模块被打爆导致。；通过前面分析，根据部署的内存模块监控脚本进行检查，看是否有异常的内存模式使用率过高。
- **运维建议：** 后续就是业务整改不使用in and in这种语法进行大量的传参，就使用一个in ，in的传参变量在100以内。；禁止使用 IN AND IN 多层嵌套语法，统一改为单层 IN。；单条 SQL IN 参数数量控制在100 以内，超量必须分批执行。
## 第 37 期｜OceanBase OMS工具在做增量同步时存在丢数据的情况问题分析
- 专辑文件：`05.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247566533&idx=1&sn=11ecbd808f10f786c867e1e3ae953a0c&chksm=f8f446b9c87027cc675c1fe462ddc7e885a328c528ec75f48ef8589aead153daf70da9d74252#rd)
- **现象：** 使用OceanBase自带的数据迁移工具OMS从ORACLE库往OB库迁移数据，如果ORACLE数据库存在跨实例的XA事务，OMS工具在做增量同步时存在丢数据的情况。
- **处置过程：** 在Oracle数据库国产化改造中，使用OMS工具从ORACLE ADG库的数据增量同步至OB库的过程中，使用OMS工具对ORACLE和OB库数据进行一致性校验。发现ORACLE库与OB库部分表数据条目数存在较大的差异，均为源端比目标端多，存在部分数据未从ORACLE库迁移到OB库的情况。；随机抽查了未同步到OB库的数据，根据数据的rowid在OMS全量和增量同步日志中进行检索，未发现这些数据的抽取记录。；检查OMS同步链路的增量同步位点时间也没有延迟的情况，排除了OMS迁移链路延迟导致的数据差异。
- **运维建议：** 迁移前必须验证XA事务支持性，建立事务类型清单；对复杂事务引入单节点中间库解耦风险；部署全局事务ID追踪系统，实时检测同步缺口
## 第 35 期｜OceanBase 使用like查询结果异常
- 专辑文件：`07.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247565525&idx=1&sn=032fc04a0b8c59485c6a90c5bd16cbf4&chksm=f878079741ce6530b83f3b900fafebf674a8713591c424ca0988d4fabd291083581bbb8eada5#rd)
- **现象：** 使用like 123123%这种条件，如果走了索引，会导致结果异常，比如字段值为123 varchar2(3)，用了like 123123%，也会出来值，正常是不出来的。
- **运维建议：** OB数据库设计问题，索引扫描的判断机制有问题，后期会进行版本修复，计划4.2.1 bp11 hotfix2 修复。6月初，临时规避业务前端进行限制长度，或者扩容相关字段长度，或者走全表扫描。；OceanBase 4.2.1 BP11 hotfix2（2024年6月）已解决该缺陷；确认修复版本并评估升级风险，避免盲目依赖
## 第 35 期｜OceanBase 查询结果不一致
- 专辑文件：`07.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247565525&idx=1&sn=032fc04a0b8c59485c6a90c5bd16cbf4&chksm=f878079741ce6530b83f3b900fafebf674a8713591c424ca0988d4fabd291083581bbb8eada5#rd)
- **现象：** 根据RN做count查询v3和v4差1，结果不一致；select COUNT(1) FROM。；SELECT ROWNUM
- **排查与原因：** OB缺陷，当使用rownum，同时范围查询从0开始，会返回501条记录(1-501),正常应该返回500条，该问题属于OB数据库产品缺陷，ROWNUM做嵌套子查询时，底层优化器会改写SQL语句，参数输入0 AND 500时会改写，并取出501行数据。；需要SQL改写，不使用子查询或者从1开始。；未来修复版本4.2.1 BP11 hotfix2 版本， 425 bp3 hotfix2 版本。
- **处置过程：** 强制查询从行号 1 开始，符合 ROWNUM 规范；WHERE RN BETWEEN 1 AND 500; -- 返回 1~500 行（共 500 条）；确认修复版本并评估升级风险，避免盲目依赖
- **运维建议：** OceanBase 优化器在解析 RN BETWEEN 0 AND 500 时，将范围起点 0 视为有效行号，导致返回行号 1~501 的数据（共 501 行），而非预期的 500 行。；ROWNUM 机制中，行号始终从 1 开始，任何从 0 开始的查询均违反设计原则。
## 第 34 期｜OceanBase 生僻字在gbk下规避问题
- 专辑文件：`08.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247565290&idx=1&sn=2eb4aab29ad488b7725e5c6e405ba395&chksm=f811046cbfbaa3f59adfb44e20f36ead80b5ea06f11d7b5c428d3ff5cc0b33e6df6446c0b3c8#rd)
- **现象：** 业务反馈前台人员录入生僻字"䶮"，录入之后查询返回乱码。；生僻字在gbk下规避。
- **处置过程：** 通过排查发现该生僻字"䶮"，在gbk编码下并不存在。；通过系统函数select dump(name,16) from dual，发现对应字段返回的是乱码3F，虽然编码gbk中并不包含该生僻字，但是编码gb18030兼容。gbk编码和gb18030之间字符集不需要转换，直接获取编码。；了解到该特新后，解决办法如下
- **运维建议：** 需要手工插入编码到底层数据库；业务需要修改url连接串中的字符集编码，业务全部修改为gb18030；因为该编码和gbk是兼容的，中间不存在字符集转换
## 第 34 期｜OceanBase 租户CPU抖动问题
- 专辑文件：`08.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247565290&idx=1&sn=2eb4aab29ad488b7725e5c6e405ba395&chksm=f811046cbfbaa3f59adfb44e20f36ead80b5ea06f11d7b5c428d3ff5cc0b33e6df6446c0b3c8#rd)
- **现象：** 在月结场景下，业务数据量翻倍，租户CPU在短时间段被打爆，且影响返回时间较长。；租户CPU抖动：分区扫描。
- **处置过程：** 通过问题时间点业务分析；定位到具体的SQL语句，；临时解决办法
- **运维建议：** OceanBase对于多分区场景下，存在较多bug，业务尽量通过分区键限制访问分区，对改表分区进行调整
## 第 34 期｜OceanBase 程序启动异常
- 专辑文件：`08.html`，第 3 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247565290&idx=1&sn=2eb4aab29ad488b7725e5c6e405ba395&chksm=f811046cbfbaa3f59adfb44e20f36ead80b5ea06f11d7b5c428d3ff5cc0b33e6df6446c0b3c8#rd)
- **现象：** 版本后大量程序启动异常，业务测试报错；”ORA-01722 invalid number”
- **排查与原因：** 后续通过TCPDUMP工具对业务进行抓包定位到预处理协议在二次编码时触发了内核BUG导致返回结果集异常。；比较明确后，提前手动发起营业库的集群合并操作，该合并操作会同步更新全库执行计划缓存，在合并结束后业务开始测试测试过程中查看proxy_error日志通过（；grep "ORA-01722" obproxy_error.log |grep "COM_STMT_FETCH"|tail -10
- **处置过程：** 登录数据库集群进行快速健康检查未发现异常，通过proxy日志查看报错找到trace_id在sql_audit找到sql并未发现有隐式转换的错误，在sql_audit中的RET_CODE显示为0，并未有报错，手动验证问题SQL可以执行。；怀疑可能为应用版本变更导致传参格式变动，引发问题，反馈应用侧确认是否可以回退，待确认后回退操作，应用回退后依然有报错。；应用侧尝试编写demo复现问题，为避免demo和生产sql干扰，应用在demo中增加别名标识，便于匹配日志及sql_audit。但尝试后发现不再报错，此时怀疑可能和执行计划有关，因为改写后会变成新的sql_id，生成新SQL。
## 第 34 期｜OceanBase 合并超时问题
- 专辑文件：`08.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247565290&idx=1&sn=2eb4aab29ad488b7725e5c6e405ba395&chksm=f811046cbfbaa3f59adfb44e20f36ead80b5ea06f11d7b5c428d3ff5cc0b33e6df6446c0b3c8#rd)
- **现象：** 集群合并超时（三副本中出现一副本无主且版本未更新）。
- **处置过程：** 检查合并版本的情况；data_version,；oceanbase.__all_virtual_partition_table
- **运维建议：** 合并超时(-4024)的规避方法（3副本都未更新合并版本）。；查看合并状态；from __all_zone where name =
## 第 34 期｜OceanBase 黑屏删除集群导致OCP功能不可用
- 专辑文件：`08.html`，第 5 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247565290&idx=1&sn=2eb4aab29ad488b7725e5c6e405ba395&chksm=f811046cbfbaa3f59adfb44e20f36ead80b5ea06f11d7b5c428d3ff5cc0b33e6df6446c0b3c8#rd)
- **现象：** 集群在OCP停用删除不掉只能在黑屏执行删除集群操作。
- **处置过程：** 登录ocp的metadb库，进入ocp库，执行sql看下select *from ob_cluster；找到集群，看到status状态为STOPPED状态，导致白屏OCP不能删除集群，查看ocp_agent状态为正常状态，准备在在ocp库中执行；UPDATE ob_cluster SET status =
- **运维建议：** OCP页面点击“创建集群”，后台会先通过GET API获取软件安装包，但GET API的时候，又会去检查集群等信息，发现ID为2000028的集群找不到（猜测一定是某些地方的配置残留或者未彻底删除干净）。
## 第 29 期｜OceanBaseCPU性能下降问题分析
- 专辑文件：`13.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247562788&idx=1&sn=f6f3a65df1993a49ca4de3a490a973a2&chksm=f83732b8b44d729b646149692edee66e1af154ef415d3f306a4bb400d7870445819d2a3df4c9#rd)
- **现象：** OCP集群合并超时导致cpu性能下降。
- **处置过程：** 时常会收到OCP推送的多套ob集群获取集群信息失败告警，检查集群状态都是正常。；排查是由于ocp_meta 租户线程使用率几乎打满，查询超时导致数据匹配不一致，故而出现告警。需要对当前OCP集群1-1-1搭建模式扩容到2-2-2。版本期间，我们通过升级metadb版本到2.2.77，使用OAT接管metadb和OCP，最后扩容metadb和OCP，扩容完成后资源使用均衡，单节点压力减小明显。；扩容后集群的合并时间是7个小时较之前并未减少，合并带来的主机cpu压力依然存在。合并耗时长的表是
- **运维建议：** 当前ocp不再纳管新的ob集群，使用新搭建的ocp纳管新增ob集群；关闭账务库和营业非主zone节点的agent并行sql采集开关；monagent.pipeline.plan.monitor.status=inactive
## 第 29 期｜OceanBasers异常切主问题分析
- 专辑文件：`13.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247562788&idx=1&sn=f6f3a65df1993a49ca4de3a490a973a2&chksm=f83732b8b44d729b646149692edee66e1af154ef415d3f306a4bb400d7870445819d2a3df4c9#rd)
- **现象：** rs异常切主问题分析。
- **排查与原因：** 导致RS切主的原因主要有；主机时钟偏移；时钟同步不一致会导致租约过期。
- **处置过程：** 判断rs是否发生选举，根据RS启动原理当__all_core_table 1号表无主时，RS就会无主，查询；__all_virtual_election_event_history；表排查RS切主时间。
- **运维建议：** 时钟同步优化；使用NTP/Chrony确保时钟同步；；定期检查时钟同步状态。
## 第 29 期｜OceanBase高并发问题分析
- 专辑文件：`13.html`，第 3 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247562788&idx=1&sn=f6f3a65df1993a49ca4de3a490a973a2&chksm=f83732b8b44d729b646149692edee66e1af154ef415d3f306a4bb400d7870445819d2a3df4c9#rd)
- **现象：** SQL自动限流解决高并发SQL带来的数据库异常。
- **处置过程：** OCP平台检查租户CPU线程使用率，发现故障点的租户线程使用率出现突增且已经打满；；查看dbwait日志，发现故障时间点的XA事务并发累积超过500，因此活跃会话数超过告警阈值；；检查proxy日志发现连接数超限，业务连接数据库有报错。
- **运维建议：** 对高并发语句绑定限流 hint 是本次解决问题的关键措施。通过这种方式，能够在短时间内控制 SQL 的并发执行，减轻数据库的压力。；监控与分析
## 第 29 期｜OceanBasecpu使用率问题分析
- 专辑文件：`13.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247562788&idx=1&sn=f6f3a65df1993a49ca4de3a490a973a2&chksm=f83732b8b44d729b646149692edee66e1af154ef415d3f306a4bb400d7870445819d2a3df4c9#rd)
- **现象：** 接收到营业E库cpu使用率告警。
- **排查与原因：** 大事务导致回滚异常超时导致kill session会话长时间无法完成。属于产品缺陷。
- **处置过程：** 登录数据库通过检查；__all_virtual_processlist；查看并发情况，检查发现有大量的kill sessoin的会话，且session已经进入session_killed状态，但执行很长时间未完成，查看对应的要kill掉的会话是一个insert语句，是一个长事务，检查部署的杀长事务脚本，发现主机后台进程的确起着多个杀长事务脚本，都在杀同一个会话。
## 第 29 期｜OceanBaseSQL查询超时问题分析
- 专辑文件：`13.html`，第 5 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247562788&idx=1&sn=f6f3a65df1993a49ca4de3a490a973a2&chksm=f83732b8b44d729b646149692edee66e1af154ef415d3f306a4bb400d7870445819d2a3df4c9#rd)
- **现象：** 业务侧反馈某SQL查询超时，对应集群cpu有明显升高趋势，表访问报错4038。
- **排查与原因：** enable_rebalance打开之后白天有时会进行副本迁移的操作，迁移数据完成后local_cache信息未正常刷新导致无法正常访问leader分区数据导致报错分区无主。
- **处置过程：** 登录数据库检查；__all_virtual_processlist；检查并发情况，发现有异常sql执行并发较高，且执行时间过长，且与业务提供SQL相匹配。
## 第 29 期｜OceanBase存过执行超时问题分析
- 专辑文件：`13.html`，第 6 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247562788&idx=1&sn=f6f3a65df1993a49ca4de3a490a973a2&chksm=f83732b8b44d729b646149692edee66e1af154ef415d3f306a4bb400d7870445819d2a3df4c9#rd)
- **现象：** 存过执行超时判断和解决。
- **处置过程：** 业务反馈一个存过执行1h多后超时了。；配合进行问题复现，通过；__all_virtual_processlist
- **运维建议：** 避免存过书写过长，同时减少使用insert into select语句插入过多的数据。
## 第 29 期｜OceanBasecpu使用率高问题分析
- 专辑文件：`13.html`，第 7 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247562788&idx=1&sn=f6f3a65df1993a49ca4de3a490a973a2&chksm=f83732b8b44d729b646149692edee66e1af154ef415d3f306a4bb400d7870445819d2a3df4c9#rd)
- **现象：** 由于4.x版本ocp对xa事务的监控导致该ocp中xa事务量比较大的ob集群xa事务表leader所在节点cpu使用率很高且持续上升。
- **处置过程：** 3.x版本ob每个业务租户下都会有一张不可见的xa事务表；__all_tenant_global_transaction；，当业务用户调用DBMS_XA包执行XA事务相关逻辑时会触发对该表的增删改
- **运维建议：** XA事务表在3版本OB是非分区表，如果计划迁移至OB的原库有较大量的XA事务需要关注这一点，做好OB集群各节点CPU使用率监控。
## 第 29 期｜OceanBaseXA事务打高observer cpu问题分析
- 专辑文件：`13.html`，第 8 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247562788&idx=1&sn=f6f3a65df1993a49ca4de3a490a973a2&chksm=f83732b8b44d729b646149692edee66e1af154ef415d3f306a4bb400d7870445819d2a3df4c9#rd)
- **现象：** XA事务打高observer cpu如何确定XA事务的具体语句。
- **处置过程：** 通常OB运维中会定期采集processlist中状态为ACTIVE的会话或者通过ocp SQL诊断；（oceanbase.gv$sql_audit）；来定位导致observer 高CPU使用率的原因
- **运维建议：** 部署sqlauditstore持久化gv$sql_audit数据。；在XA事务量比较大的库需要做好对XA事务的监控。
## 第 29 期｜OceanBase数据库出现大量慢SQL问题分析
- 专辑文件：`13.html`，第 9 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247562788&idx=1&sn=f6f3a65df1993a49ca4de3a490a973a2&chksm=f83732b8b44d729b646149692edee66e1af154ef415d3f306a4bb400d7870445819d2a3df4c9#rd)
- **现象：** 运维批量更新100张表，每张表64个分区，造成租户线程使用率100%，队列积压，导致数据库出现大量慢SQL。
- **处置过程：** 通过分析故障时段observer日志，发现有日志同步慢；（errcode=-4389）；的情况出现，同时有出现req_queue队列积压的情况；
- **运维建议：** 在生产环境，对执行的SQL要预先了解排查表结构和表数据量，不盲目执行；不大批量的执行DML语句，可能存在性能风险；对长时间执行中的SQL要及时终止，避免影响整个数据库
## 第 29 期｜OceanBasenvl函数无返回问题分析
- 专辑文件：`13.html`，第 10 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247562788&idx=1&sn=f6f3a65df1993a49ca4de3a490a973a2&chksm=f83732b8b44d729b646149692edee66e1af154ef415d3f306a4bb400d7870445819d2a3df4c9#rd)
- **现象：** OB数据库中sql where条件中使用nvl函数，在oracle数据库中可以返回结果，而在OB数据库中总是返回空行。
- **处置过程：** 应用侧反馈有一条SQL where条件中使用了；where rownum
## 第 25 期｜OceanBase数据库迁移后高耗SQL
- 专辑文件：`17.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247561484&idx=1&sn=0254cc40ddaf78d19f4edcb1104c6d3b&chksm=f8d8b6f50c54e26356be5cb86631e024a39fa66a962adfdabe204000c4a70f29afe303e05c75#rd)
- **现象：** 某客户反馈有广播一直处理中，重发后处理成功，但第二次重发失败，导致1组生效广播回退，涉及多个号码。；检查携转应用主机和程序正常。因当晚Oracle库割接至OceanBase库，协调华为与OB工程师核查，发现OB库存在高耗SQL，执行耗时较长。OB工程师新建索引后，SQL性能恢复正常，广播恢复正常。
- **处置过程：** 经核查OB库中高耗SQL集中在访问携号转网广播表，通过对比高耗SQL在原Oracle库中的执行计划，发现该高耗SQL在Oracle库时可以走索引，但在服开OB库中执行计划为全表扫描。；经和OB原厂工程师确认，OceanBase中非前导列的索引不能提供匹配过滤，该组合索引的前导列(组合索引的第一列)不一致， OceanBase在处理SQL当where子句中不包含前导列时，OceanBase的执行计划只能是全表扫描。并且在4.x版本之前，没有index skip scan的扫描方式。也就意味着只要谓词条件是telnum=’xxx’都是无法走索引的，只能走全表扫描。
- **运维建议：** 迁移前的全面性能测试；数据库迁移前，所有高频或关键业务SQL必须经过严格的性能测试，验证在新数据库中的执行效率，并重点测试索引优化是否符合预期。；针对差异优化SQL或数据结构
## 第 25 期｜OceanBase数据库进程启动失败
- 专辑文件：`17.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247561484&idx=1&sn=0254cc40ddaf78d19f4edcb1104c6d3b&chksm=f8d8b6f50c54e26356be5cb86631e024a39fa66a962adfdabe204000c4a70f29afe303e05c75#rd)
- **现象：** 某Oracle库割接到OceanBase库后，应用重启过程中发现有个进程无法启动，报错：invaild number。；怀疑和进程有使用mod(b，N)对号码取模，实现进程的并行执行，后续通过取消mod函数后，进程正常启动。
- **处置过程：** 经核查，在OB库中报错invaild number的SQL语句为；select xxx from xx where；and mod
- **运维建议：** 全面测试迁移后的SQL兼容性；数据库割接过程中，尤其是涉及关键业务逻辑的SQL语句，需要全面测试其兼容性和性能表现，特别是函数调用和数据类型转换的细节处理。；优化数据设计以避免隐式转换问题
## 第 25 期｜OceanBase数据库DtlIntermRes内存问题
- 专辑文件：`17.html`，第 3 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247561484&idx=1&sn=0254cc40ddaf78d19f4edcb1104c6d3b&chksm=f8d8b6f50c54e26356be5cb86631e024a39fa66a962adfdabe204000c4a70f29afe303e05c75#rd)
- **现象：** 从oracle环境进行国产化替换到OB后第二天，大量业务报错4013。通过sql检查内存模块发现；DtlIntermRes内存模块异常增高。
- **处置过程：** 知识库有类似的记录，可以使用 hint /*+ parallel(2) */ 开启并行，并行度大于 1 时是流式执行，不会写中间结果。时刻注意dtl模块占用，如果到了危险值，及时与业务沟通手动切主，减少影响。；根据研发提供的一些触发条件对关键算子来进行匹配，找到一些怀疑sql；（等内存模块变化之后马上抓一部分sql），
- **运维建议：** 内存泄漏的根本原因，Batch Rescan优化问题；在batch rescan优化的过程中，如果上一个batch的数据没有读完；（例如上方有limit语句，或者nested semi/anti join操作）
## 第 25 期｜OceanBase数据库语句没有结果返回
- 专辑文件：`17.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247561484&idx=1&sn=0254cc40ddaf78d19f4edcb1104c6d3b&chksm=f8d8b6f50c54e26356be5cb86631e024a39fa66a962adfdabe204000c4a70f29afe303e05c75#rd)
- **现象：** 业务侧反馈程序中执行；select substr(?, 9, 6) uniid from dual ;；语句没有结果返回。
- **排查与原因：** 本次故障中，我们深刻认识到加强全链路优化分析能力的重要性。从业务侧反馈到问题定位、优化策略实施再到后续验证与监控，每一个环节都需要我们具备全面的知识和技能。因此，我们将继续加强团队建设，提高团队成员的全链路优化分析能力。同时，我们也将加强与业务侧的沟通协作，共同推动系统的持续优化和改进。；深入理解底层机制与差异；本次故障还提醒我们，深入理解不同数据库系统的底层机制和差异至关重要。Oracle与OB在处理getColumnDisplaySize函数时的差异，正是由于我们对底层机制了解不够深入所导致的。
- **处置过程：** 收到业务人员反馈报错，生产环境根据业务测试SQL语句(select substr(?, 9, 6) uniid from dual;)从数据库侧抓取相关信息(传入参数值)，根据业务侧抓取的参数值，通过在数据库gv$sql_audit视图中查询是否有值返回，但在数据库侧并未看出异常；是有数据返回的）；与华为同事反馈后，业务侧开debug日志发现发现正常的号码和不正常的号码dam收到的报文不太一样。java程序中使用getColumnDisplaySize函数来获取 select substr(?, 9, 6) uniid from dual; 该条语句的字段长度，发现在日志报文中有时会不输出getColumnDisplaySize的值，但是报文中substr是有结果值的 ，输出的size是没有的，之后华为同事确认这里…
- **运维建议：** 加强全链路优化分析能力
## 第 25 期｜OceanBase数据库程序报错
- 专辑文件：`17.html`，第 5 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247561484&idx=1&sn=0254cc40ddaf78d19f4edcb1104c6d3b&chksm=f8d8b6f50c54e26356be5cb86631e024a39fa66a962adfdabe204000c4a70f29afe303e05c75#rd)
- **现象：** 收到一线人员前台界面提示程序报错connection reset。
- **处置过程：** 与一线人员沟通操作流程；如果一次上传处理的数据量少于900条可以正常处理， 超过900条则报错。；根据业务侧提供的堆栈信息在obproxy日志中对应的cs_id所对应proxy trace_id进行过滤WARN,ERROR相关日志信息
- **运维建议：** 这边后续是业务改造处理。 ob研发是将proxy升级到4.3.1.0 BP1 hotfix1 来解决。；应用减少execute传的包大小；本次故障提醒我们，在应用层面，需要更加注意数据包的大小控制。尤其是在进行批量数据处理时，应该避免将过多的数据合并成一个数据包进行传输。
## 第 25 期｜OceanBase数据库obproxy异常
- 专辑文件：`17.html`，第 6 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247561484&idx=1&sn=0254cc40ddaf78d19f4edcb1104c6d3b&chksm=f8d8b6f50c54e26356be5cb86631e024a39fa66a962adfdabe204000c4a70f29afe303e05c75#rd)
- **现象：** 生产环境单点登录的odc使用的元数据库的连接串指向ocp依赖的metadb某节点的obproxy，该metadb docker中的文件系统异常，导致docker 中运行的observer和obproxy均异常，单点登录odc无法连接到元数据库，odc服务也异常需要修改odc的元数据库连接串，同时还需要重建单节点metadb。
- **处置过程：** 修改odc容器中记录的元数据库ip；docker exec -it obodc bash；view bin/start-odc. sh
- **运维建议：** 生产环境高可用架构设计的重要性
## 第 25 期｜OceanBase数据库oms链路延迟
- 专辑文件：`17.html`，第 7 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247561484&idx=1&sn=0254cc40ddaf78d19f4edcb1104c6d3b&chksm=f8d8b6f50c54e26356be5cb86631e024a39fa66a962adfdabe204000c4a70f29afe303e05c75#rd)
- **现象：** oms迁移过程中，发现反向增量延迟2小时以上，查看日志发现有deadlock日志输出，导致链路延迟。
- **处置过程：** 在plsql通过语句查询，确认是否存在死锁，查询出具体的信息，确认存在死锁。；通过修改 Incr-Sync 增量同步组件中的并发参数workerNum":int 1 修改成1，使之串行化运行。；等待当前事务提交后，将并发参数workerNum":int 64 修改成原先值。
- **运维建议：** 加强链路监控完善预警机制；本次故障暴露了我们在链路监控和预警机制方面的不足。未来，我们需要将加强对链路的监控关注，建立更为完善的预警机制。通过实时监控系统的运行状态、日志输出和性能指标，我们能够及时发现潜在的问题并采取有效的应对措施，从而最大限度地减少故障对业务的影响。；优化并发处理
## 第 25 期｜OceanBase数据库提前转储
- 专辑文件：`17.html`，第 8 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247561484&idx=1&sn=0254cc40ddaf78d19f4edcb1104c6d3b&chksm=f8d8b6f50c54e26356be5cb86631e024a39fa66a962adfdabe204000c4a70f29afe303e05c75#rd)
- **现象：** 慢SQL导致节点提前转储问题。
- **处置过程：** OCP分析故障时间段memstore使用情况；发现memstore可用内存被挤占，导致计算出来的阈值下降，触发了节点提前转储。；从sqlaudit中捞取的可疑SQL
- **运维建议：** 禁止未经测试的大结果集SQL生产上线；本次故障的发生，直接原因是某条SQL语句缺少筛选条件，导致生成了庞大的中间结果集。这提醒我们，在SQL语句上线之前，必须进行充分的测试，确保其执行计划合理、内存占用可控。对于可能产生大结果集的SQL语句，更要进行严格的审查和测试，避免其未经测试就直接在生产环境中使用。；业务侧严格遵守上线评审流程，未经评审通过的SQL不允许直接上线
## 第 25 期｜OceanBase数据库登录慢
- 专辑文件：`17.html`，第 9 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247561484&idx=1&sn=0254cc40ddaf78d19f4edcb1104c6d3b&chksm=f8d8b6f50c54e26356be5cb86631e024a39fa66a962adfdabe204000c4a70f29afe303e05c75#rd)
- **现象：** 用户反应登录很慢。
- **排查与原因：** 在中，可首先检查obproxy机器是否hang住或性能异常。obproxy作为请求转发的关键组件，其性能状态直接影响用户登录速度。；部分会话登录很快而部分卡住的情况，可考虑是否与会话管理或临时表使用有关；在OceanBase的某些版本中，会话ID复用机制可能导致临时表删除开销过大，进而影响登录速度。因此，在中应关注临时表的使用情况和会话管理策略。
- **处置过程：** 黑屏尝试重复登录；发现有一部分会话连接很快，一部分会话连接会卡住很久。初步分析可能是用户使用F5转发时，对应obproxy宕机，ocp查看obproxy正常。；查看登录时间段的observer.log
- **运维建议：** 登录均失败的排查方向一般与observer实例本身无关；为避免临时表过多导致的性能问题，用户在使用临时表时注意控制数量。不要在同一会话中创建过多的临时表，以免增加删除开销和影响登录速度。
## 第 25 期｜OceanBase数据库至灾备集群后部分应用验证失败
- 专辑文件：`17.html`，第 10 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247561484&idx=1&sn=0254cc40ddaf78d19f4edcb1104c6d3b&chksm=f8d8b6f50c54e26356be5cb86631e024a39fa66a962adfdabe204000c4a70f29afe303e05c75#rd)
- **现象：** OB灾备切换演练，灾备集群切换为主集群后，部分应用功能验证失败。
- **处置过程：** 分别进入主备集群查看主备角色已经切换成功。排查应用的数据库连接配置，数据库连接配置均为域名，域名解析也已切换至灾备机房IP。；ssh连接应用主机，netstat查看正在连接的会话，发现有很多会话还是访问的原主机房IP。ssh原主集群OB主机查看日志，发现仍有sql请求持续过来，但因为已切换为备集群只读模式，这些sql都执行失败了。；通知行方应用发现连接池存在长链接未关闭，持续提供数据库访问导致。咨询其他分行切换情况，也存在访问IP为原主机房，但应用任然可以正常入库至灾备集群。查看发现OBproxy的启动方式为RSlist，其他分行是configurl。
- **运维建议：** 接池配置和状态引以重视
## 第 24 期｜OceanBase数据库全备失败问题分析
- 专辑文件：`18.html`，第 8 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247560737&idx=1&sn=cb01276366d6818c6aec834908e03dd0&chksm=f89e5f449198f4a5d9fb69918f34a676ff26b704f61db98491107c4f2ddb8f019fb7c7e3af22#rd)
- **现象：** 某OB数据库全备失败，归档延迟较高，归档量大。
- **处置过程：** 该集群的clog比较大，导致初始搭建备集群时，延迟追不上，备集群搭建：调整rebuild_replica_data_lag_threshold参数，及时进行副本重建才勉强搭建起来备集群。；开启主库归档，会把日志盘io打满，导致归档延迟增大。无法进行全备。
- **运维建议：** 1）业务分区与日志膨胀；经过深入分析，我们发现业务分区数较多且存在频繁的update操作，但并未指定分区键。这一设计缺陷导致了CLOG的急剧膨胀。；由于CLOG中包含了redo log、prepare log、commit log和clear log等多种类型的日志，当某个分区被更新时，该分区会生成所有类型的日志。而未被更新的分区虽然缺少redo log，但其他类型的日志仍然会生成。
## 第 24 期｜OceanBase数据库网络瞬断导致两套集群rs处于无主状态
- 专辑文件：`18.html`，第 9 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247560737&idx=1&sn=cb01276366d6818c6aec834908e03dd0&chksm=f89e5f449198f4a5d9fb69918f34a676ff26b704f61db98491107c4f2ddb8f019fb7c7e3af22#rd)
- **现象：** 网络瞬断导致两套集群rs处于无主状态，一套通过调整_ob_max_thread_num参数恢复正常，另一套当天晚上21:00重启主zone45节点完成恢复。；归档也卡在了问题时间点，位点不再推进，这时候还发现一个，在__all_server视图中查询到的rs主是zone1的rs节点，但是从__all_virtual_clog_stat视图查到的leader是zone2的rs节点。；执行切主命令，报错"rootserver is not the master"。
- **处置过程：** 收到告警，observer进程不存在。赶紧检查集群，发现告警集群的三台server处于inactive的状态。业务的primary_zone是zone3，sys租户的primary_zone在zone1，inactive的是zone1的两台机器。zone2的一台机器，zone1是一个机房，zone2和zone3在另外的机房，万幸的是业务反馈告警时候断连了一批业务，重新拉起来就好了。；检查当时的网络有丢包，怀疑是网络问题触发的诱因。登录主机检查发现inactive的机器上observer进程还在，通过2881连接inactive的节点也可以登录。；分别对各个rs节点进行了队列积压的检查，并未发现异常。
- **运维建议：** 1）网络波动触发主从切换与observer bug
## 第 24 期｜OceanBase数据库执行SQL报错分析
- 专辑文件：`18.html`，第 10 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247560737&idx=1&sn=cb01276366d6818c6aec834908e03dd0&chksm=f89e5f449198f4a5d9fb69918f34a676ff26b704f61db98491107c4f2ddb8f019fb7c7e3af22#rd)
- **现象：** 执行SQL报错4013问题。
- **处置过程：** 根据sql 文本确认是sql中的一条update语句执行抛出的内存不足的报错。；根据报错的sql文本去sql_audit 视图中捞取对应的trace_id ，过滤日志观察具体是哪个模块内存写满；日志中打印有限，因此在sql中增加了/*+LOG_LEVEL(debug)*/ hint，增加日志的输出
- **运维建议：** 避免产生过多的中间结果数据；在处理此次故障的过程中，我们发现SQL执行时merge sort过程中的ob_dtl_interm_result_manager中间结果数据落盘过大，这是导致租户内存不足的主要原因。；因此，我们总结出的第一条经验教训是，在设计SQL语句和数据处理逻辑时，应尽量避免产生过多的中间结果数据。
## 第 19 期｜OceanBase误操作删除表处置
- 专辑文件：`23.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247558577&idx=1&sn=d36bb094e2c549a9c1163a84ccbfbbe7&chksm=f85079dff3faf4683b02ae1ae50fcbe84cfebfe5c270c27e3188ceff84e68e78ae828517e686#rd)
- **现象：** （OceanBase）业务误操作删除表。
- **处置过程：** 检查集群回收站是否设置
- **运维建议：** 确认备份和归档是否正常；依赖备份和归档进行单表恢复到一个新的临时租户（3.x）；通过obdump/datax/oms/outfile的方式把数据导回原库
## 第 19 期｜OceanBase集群执行脚本效率下降
- 专辑文件：`23.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247558577&idx=1&sn=d36bb094e2c549a9c1163a84ccbfbbe7&chksm=f85079dff3faf4683b02ae1ae50fcbe84cfebfe5c270c27e3188ceff84e68e78ae828517e686#rd)
- **现象：** 业务反馈其他数据量类似的集群一个脚本大概执行3/4分钟，这个集群执行要5/6分钟，因数据处理慢，导致业务当天处理不完数据。；检查了audit信息，该集群对于这个sql，每一条sql都生成了一个planid，这些plan_id在plan_stat视图里没有显示。后续检查了_enable_partition_level_acs 参数，出现问题的这个集群参数是打开的，关闭后，恢复正常。但是产生这么多非重复plan与_enable_partition_level_acs功能不相符。
- **排查与原因：** 确保系统日志和审计日志的详细记录，以便在问题发生时能够回溯操作历史、分析。对于性能问题，应特别关注SQL执行计划、锁等待情况、磁盘I/O等关键指标。
- **处置过程：** 业务反馈其他数据量类似的集群一个脚本大概执行3/4分钟，这个集群执行要5/6分钟，因数据处理慢，导致业务当天处理不完数据，手工介入处理。；从gv$plan_cache_plan_stat看到计划虽然比其他集群多几条，但是效率还算正常。；或参数配置时，应积极查阅官方文档、社区论坛及知识库，了解其他用户的经验和。这有助于快速定位问题根源，并找到最合适的。
- **运维建议：** 深入理解并合理配置系统参数；参数评估与测试；在处理此类性能问题时，应首先深入理解涉及的系统参数（如_enable_partition_level_acs）的作用、默认设置及潜在影响。在做出修改前，应在测试环境中评估参数变更的效果，确保变更不会对系统稳定性和性能产生负面影响。
## 第 19 期｜（OceanBase）proxy无法纳管集群处置
- 专辑文件：`23.html`，第 3 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247558577&idx=1&sn=d36bb094e2c549a9c1163a84ccbfbbe7&chksm=f85079dff3faf4683b02ae1ae50fcbe84cfebfe5c270c27e3188ceff84e68e78ae828517e686#rd)
- **现象：** 资源新增弱读proxy，现有一个计费的弱读proxy，计划添加可连接集群到资源。但是因为；ocp密码箱没有；资源集群的
- **处置过程：** 资源新增弱读proxy，现有一个计费的弱读proxy，计划添加可连接集群到资源。但是因为ocp密码箱缺失资源集群的proxyor用户密码，所以无法实施。；直接修改proxyor密码会造成proxy与ob集群无法连接，需要窗口操作，并同步更改root@proxysys的密码配置以及增加ocp的密码箱配置。；后来跟工单确认，ob4.x前版本有默认密码，proxyro@sys 默认密码是 xxx，测试可行。
- **运维建议：** 默认密码与版本兼容性；明确版本差异；在处理OceanBase（OB）或任何数据库系统的密码和权限问题时，首先要明确不同版本之间的兼容性和默认设置差异。特别是在升级或迁移过程中，应特别注意这些变化，以避免因默认密码或行为差异导致的意外问题。
## 第 19 期｜OceanBase磁盘使用率忽然升高
- 专辑文件：`23.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247558577&idx=1&sn=d36bb094e2c549a9c1163a84ccbfbbe7&chksm=f85079dff3faf4683b02ae1ae50fcbe84cfebfe5c270c27e3188ceff84e68e78ae828517e686#rd)
- **现象：** oceanbase数据库磁盘使用率忽然升高。
- **处置过程：** 查看磁盘空间使用情况；__all_virtual_disk_stat；查看临时空间的使用情况
- **运维建议：** 深入理解系统内部机制；掌握系统表与视图
## 第 19 期｜OceanBase某租户CPU 100%问题
- 专辑文件：`23.html`，第 5 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247558577&idx=1&sn=d36bb094e2c549a9c1163a84ccbfbbe7&chksm=f85079dff3faf4683b02ae1ae50fcbe84cfebfe5c270c27e3188ceff84e68e78ae828517e686#rd)
- **现象：** 某现场某租户出现CPU 100%问题。
- **处置过程：** 通过processlist抓取当时；sqlid（EE7641A6834AF923F447DF03A78C2B44）；发现当时时间点存在sql并发很高，而且执行时间长，影响了当时cpu使用率异常增长。
- **运维建议：** 1）SQL优化；避免全表扫描；全模糊匹配（如LIKE '%keyword%'）和函数转换（如UPPER）经常导致数据库无法利用索引，从而引发全表扫描。这极大地增加了数据库的负载，特别是在大数据集上。理解这一点并尽可能避免这些操作，或者通过其他方式（如文本搜索引擎）来实现类似的功能，是提升查询性能的关键。
## 第 19 期｜OceanBase oms全量迁移卡住
- 专辑文件：`23.html`，第 6 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247558577&idx=1&sn=d36bb094e2c549a9c1163a84ccbfbbe7&chksm=f85079dff3faf4683b02ae1ae50fcbe84cfebfe5c270c27e3188ceff84e68e78ae828517e686#rd)
- **现象：** oms迁移过程中，全量迁移卡住，链路没有报错但是实时流量为0KB/s。
- **处置过程：** 查看全量导入组件中的日志，显示查询sql超时；将执行超时的SQL语句拿到源端执行，显示超时；查看了这条语句的执行计划explain sql 中显示耗时
- **运维建议：** 1）深入理解SQL执行计划与优化器行为；执行计划的重要性；在处理数据库迁移或优化性能时，了解SQL的执行计划是至关重要的。执行计划展示了数据库如何执行查询，包括使用的索引、连接方法、排序操作等。通过EXPLAIN命令查看执行计划，可以清晰地看到哪些步骤可能成为性能瓶颈。
## 第 19 期｜OceanBase oms迁移数据中全量组件异常中断
- 专辑文件：`23.html`，第 7 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247558577&idx=1&sn=d36bb094e2c549a9c1163a84ccbfbbe7&chksm=f85079dff3faf4683b02ae1ae50fcbe84cfebfe5c270c27e3188ceff84e68e78ae828517e686#rd)
- **现象：** oms迁移数据中全量组件异常中断。
- **排查与原因：** 过滤日志中相关报错的涉及的用户及表信息，定位报错表；；在源端侧锁定迁移割接范围中包含的rowid字段的全部表，未发现；；确认是否oms版本bug,链路重新复制，在预检查阶段未发现rowid 的排除提示，说明割接对象中未包含rowid字段的表；
- **处置过程：** oms迁移全量业务表，单条链路表数量40张；；操作oms版本4.1.0；；涉及链路结构迁移+全量迁移+增量迁移+反向增量。
- **运维建议：** ）OMS版本与目标数据库结构的兼容性检查至关重要；在数据迁移前，应详细检查OMS工具与目标数据库中的特殊表结构是否兼容，尤其是针对OMS版本不支持的表类型；（如索引组织表IOT）
## 第 19 期｜OceanBase 数据库主机宕机
- 专辑文件：`23.html`，第 8 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247558577&idx=1&sn=d36bb094e2c549a9c1163a84ccbfbbe7&chksm=f85079dff3faf4683b02ae1ae50fcbe84cfebfe5c270c27e3188ceff84e68e78ae828517e686#rd)
- **现象：** 主机的raid卡驱动固件版本低，导致数据库主机宕机。；某日17:37分接到业务负责人反馈OB数据库报错。立即登录OCP平台检查集群状态发现显示41主机状态不可用，从后台登录主机发现只能ping通，但无法登录。跟4月7日一样。；17:45分检查表分区分布情况，发现集群leader节点没有自动切主。
- **排查与原因：** 在OB数据库故障处理中，需要补充相关的检查项目。例如，检查RAID卡驱动和固件版本是否与操作系统内核版本兼容，确保底层硬件和软件的兼容性，防止因固件版本不匹配导致的系统宕机问题。加强对数据库故障的检查和诊断项目，确保能够全面覆盖常见，提升故障排查的效率和准确性。；确保固件和驱动版本的匹配
- **处置过程：** 某日14:48分接到生产系统OB集群；（2-2-2架构）；41主机cpu load过高告警。立即登录OCP平台检查集群状态显示41节点离线，从后台登录主机发现只能ping通，但无法登录。
- **运维建议：** 固件版本的选择依据驱动版本，驱动版本高时固件版本也高，驱动版本低时适当降低固件版本；将已升级RAID卡固件驱动的主机操作系统当前内核版本2211降级至推荐版本2107。；组织真实的应急演练；针对网格通OB集群单节点CPU耗尽的混沌演练场景，以及OB集群主备切换场景，组织真实的应急演练。通过模拟实际故障场景进行演练，能够提高团队的应急处理能力和熟练度，确保在真实故障发生时能够迅速有效地应对，减少业务影响。
## 第 17 期｜Oceanbase 备份恢复失败
- 专辑文件：`25.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247557370&idx=1&sn=b513142a14c9bf833157a0b0d1736a5d&chksm=f85e55f18afb5b89609ef1e5a99b63d49dcb74ac4c8e311dd943e3d06250ad0c6008bade7a30#rd)
- **现象：** Oceanbase 备份恢复失败。
- **处置过程：** 通过命令查看恢复历史记录，恢复状态为失败。；发现备份环境与恢复环境的OB版本信息不一致，将恢复环境的版本升级后，再次执行恢复成功。
- **运维建议：** 在执行备份和恢复之前，确保所有环境中的软件版本完全一致。如果必须进行版本升级，同时更新备份环境和恢复环境，以避免兼容性问题。；自动化版本检查；在备份和恢复的流程中加入自动版本检查步骤，如果发现版本不一致，自动提示或阻止操作，减少人为错误。
## 第 16 期｜租户的占用内存大小超限分析
- 专辑文件：`26.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247556156&idx=1&sn=6b54be643f58f54bb692c56b304e7457&chksm=f85124e810a0278882f059e7df8f916171936d8d8ca0ac01e0331ba2b579d3c482ea95bc0589#rd)
- **现象：** OB500租户的占用内存大小超限，占用内存 100.08 GB。
- **处置过程：** 前期观察，后期进行重启observer进程，释放内存。；Ocean Base 3.2.3集群长时间不重启；（超过200天）
- **运维建议：** 重启集群或者升级3.2.3 bp9以后版本，目前为3.2.3 bp5版本。；计划定期重启；定期重启可以作为临时措施，以防止系统长时间运行后出现性能降低或资源泄漏。
## 第 16 期｜迁移速度变慢分析
- 专辑文件：`26.html`，第 5 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247556156&idx=1&sn=6b54be643f58f54bb692c56b304e7457&chksm=f85124e810a0278882f059e7df8f916171936d8d8ca0ac01e0331ba2b579d3c482ea95bc0589#rd)
- **现象：** OMS配置了反向增量的用户后，迁移速度变慢，由几百MB每秒降至几十KB每秒。
- **处置过程：** 版本4.1.0的OMS，配置了oms_drc用户后，迁移链路会自动设置；sink.enablePartitionBucket；参数为true。对于分区数特别多的表，就会迁移特别慢。
- **运维建议：** 参数文档化和理解；确保团队成员对OMS及其相关配置参数有充分的理解。这包括了解每个参数的作用、适用场景和潜在的副作用。；制定配置变更策略
## 第 16 期｜OB集群从OCP中无法迁出
- 专辑文件：`26.html`，第 7 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247556156&idx=1&sn=6b54be643f58f54bb692c56b304e7457&chksm=f85124e810a0278882f059e7df8f916171936d8d8ca0ac01e0331ba2b579d3c482ea95bc0589#rd)
- **现象：** 一备集群被其他OCP接管并解耦为主集群，原OCP无法管控进行迁出失败。
- **处置过程：** 通过连接ocp meta元数据库，删除集群信息；delete from ob_server where cluster id；delete from ob_zone where cluster_id
- **运维建议：** 增强集群监控；确保所有集群的状态和归属都被实时监控并记录，这有助于在类似情况下快速了解集群的当前管理状态。；集群管理策略
## 第 16 期｜OMS迁移ROWID类型数据
- 专辑文件：`26.html`，第 8 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247556156&idx=1&sn=6b54be643f58f54bb692c56b304e7457&chksm=f85124e810a0278882f059e7df8f916171936d8d8ca0ac01e0331ba2b579d3c482ea95bc0589#rd)
- **现象：** OMS标准情况无法迁移ROWID类型数据。
- **处置过程：** precheck.skippable_flags = {"DB_DATA_TYPE":true}；忽略类型检测。；通过dbcat导出表元数据，替换rowid类型为varchar2(18)，将DDL语句在目标租户执行创建表结构。
- **运维建议：** 数据类型映射验证；在迁移前彻底测试和验证数据类型映射的准确性，确保 ROWID 转换为 VARCHAR2(18) 后，所有数据都能正确表示且不会引起数据丢失或错误。；数据验证和审计
## 第 15 期｜OCP主机与OB主机检验时钟差过大问题分析
- 专辑文件：`27.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247554936&idx=1&sn=fe456980a70d40759890b2c0fefd336d&chksm=f82ff81260bc3efeaa8c83a3efea3a534c3a2da4dd7053074af1f18f8bb2e239597b835936ab#rd)
- **现象：** OCP添加OB主机，Pre check for create host环境校验步骤OCP主机与OB主机检验时钟差过大。
- **排查与原因：** 在三台OB主机执行clockdiff至OCP主机IP，得到评估值，看到delta值小于20ms，为正常范围内；；后在OCP主机使用clockdiff命令分别至三台OB主机，均提示目标主机主机is down；；从三台OB主机ping OCP主机，正常；
- **处置过程：** OCP添加OB服务器主机，用于后续集群搭建；；操作系统为统信OS V20。；[pool-manual-subtask
- **运维建议：** 预先确认网络策略；在部署和配置新主机之前，与网络团队沟通，确认网络安全策略，特别是关于ICMP协议的使用情况。确保所有必要的网络协议都已开通，以便各种系统工具能够正常运行。；实现自动化的环境检查
## 第 15 期｜正向链路仅同步表结构，反向回流报错
- 专辑文件：`27.html`，第 6 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247554936&idx=1&sn=fe456980a70d40759890b2c0fefd336d&chksm=f82ff81260bc3efeaa8c83a3efea3a534c3a2da4dd7053074af1f18f8bb2e239597b835936ab#rd)
- **现象：** OMS正向链路仅同步表结构，反向回流报错。
- **处置过程：** 修改增量同步组件参数；coordinator.allowRecordTypes = "；source.ignoreDdl = false
- **运维建议：** 允许所有记录类型；确保配置文件或同步参数中允许同步所有类型的数据库操作，包括DELETE、INSERT、UPDATE以及DDL。这有助于保证数据和结构的完整性都得到同步。；启用DDL同步
## 第 15 期｜回流导致OB节点CPU使用率超高
- 专辑文件：`27.html`，第 7 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247554936&idx=1&sn=fe456980a70d40759890b2c0fefd336d&chksm=f82ff81260bc3efeaa8c83a3efea3a534c3a2da4dd7053074af1f18f8bb2e239597b835936ab#rd)
- **现象：** OMS回流导致OB节点CPU使用率超高或创建ob-oracle全量、增量迁移链路。
- **处置过程：** 参数，减少数据字典访问；slik.isPreLoadAllTableSchema =
- **运维建议：** 调整批处理大小；减小每次同步的批处理大小，可以降低单次操作对CPU的压力，但可能会增加总体同步时间。需要根据具体情况调整以找到最佳平衡点。；如果可能，考虑采用异步处理数据的方法，这样可以平滑CPU使用率，避免高峰时段CPU使用率过高。
## 第 15 期｜回流链路报错处理
- 专辑文件：`27.html`，第 8 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247554936&idx=1&sn=fe456980a70d40759890b2c0fefd336d&chksm=f82ff81260bc3efeaa8c83a3efea3a534c3a2da4dd7053074af1f18f8bb2e239597b835936ab#rd)
- **现象：** OMS回流链路报错误；“ORA-00054：resource busy and acquire with NOWAIT specified or timeout expired errorDDL: drop index XXXX”
- **处置过程：** 修改其它链路增量同步组件参数；sink(无作用)；maxRetryTimes = 3000
- **运维建议：** 应用层同步；在应用层面实施同步控制，确保在执行DDL操作前数据库不处于高负载状态或减少并发操作。；DDL操作调度
## 第 15 期｜集群状态检测异常分析
- 专辑文件：`27.html`，第 10 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247554936&idx=1&sn=fe456980a70d40759890b2c0fefd336d&chksm=f82ff81260bc3efeaa8c83a3efea3a534c3a2da4dd7053074af1f18f8bb2e239597b835936ab#rd)
- **现象：** ocp告警，获取集群信息失败，集群状态检测异常,observer有4012执行超时和4019空间溢出报错，备份延迟告警，连接集群后执行命令异常，只能查询processlist，其他操作无法执行。
- **处置过程：** 查看rs日志，发现 sys 租户存在队列积压：req_queue:total_size = 17409。；重启rs节点obsever后正常。；增加sys租户资源，从1c8g改成8c16g。
- **运维建议：** 增强资源监控；确保有有效的监控系统来跟踪关键资源的使用情况，如CPU、内存、磁盘空间和网络。使用工具如Prometheus、Grafana等进行实时监控和可视化。；自动化资源管理
## 第 14 期｜Oceanbase OAT 报密码验证失败问题分析
- 专辑文件：`28.html`，第 9 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247554331&idx=1&sn=697888cd27e2fb9c0fee80820873bb4f&chksm=f852eb76eaf416609ad4b681576941463c7aefc068703fc8909d45068f5696f7e6edca6b22fc#rd)
- **现象：** 因生产环境OCP密码不符合客户安全管理规范，在更新密码后,部署新机器时OAT 报密码验证失败，无法通过OAT进行主机初始化推送。
- **处置过程：** 登录OAT 容器；docker exec；it oms bash
- **运维建议：** 配置管理工具；使用如 Ansible、Chef 或 Puppet 等配置管理工具，可以帮助自动化配置文件的更新和部署，确保所有相关的组件都使用最新的配置。；密钥和密码管理
## 第 14 期｜Oceanbase oms增量迁移延迟处理
- 专辑文件：`28.html`，第 10 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247554331&idx=1&sn=697888cd27e2fb9c0fee80820873bb4f&chksm=f852eb76eaf416609ad4b681576941463c7aefc068703fc8909d45068f5696f7e6edca6b22fc#rd)
- **现象：** 生产环境割接时，通过oms数据迁移mysql到obmysql,业务停止服务后，增量延迟一直增长无法正常进行正向切换，按照 Oracle 割接经验切换日志无效果。
- **处置过程：** 检查数据库是否还有连接在；information_scheam.processlsit;；SHOW MASTER STATUS
- **运维建议：** 限制大量的写入操作；在割接过程中，尽量避免执行大批量的写入操作，如 create table as select 可能会产生大量日志，增加迁移过程的复杂度和延迟。；逐步迁移数据
## 第 13 期｜oceanbase sql执行计划变更，导致cpu使用率打满
- 专辑文件：`29.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247553647&idx=1&sn=a4e3034acc8ffb27e39eeeba5ab3d053&chksm=f8ee8d04a3f80fd5f349f67890eef740ef2bd2e9c34b4805420d6d8fee25f6181b4f53cba4a5#rd)
- **现象：** 业务侧使用mybatis框架生成的SQL在每次有ddl操作后，sql的别名会改变，导致执行计划走选择性较差的索引，导致主机cpu打满。
- **处置过程：** 登录数据库后，通过__all_virtual_processlist来确认哪些sql占用的cpu线程较多；对问题SQL进行限流 ，并发设置为10；绑定执行计划，并指定正确的索引
- **运维建议：** 定期评估数据库索引的有效性和性能影响；确保索引设计与业务查询需求相匹配。避免过多无用索引或缺失必要索引，这两者都可能影响查询性能。；针对那些性能差的 SQL，尝试重写或优化这些查询，
## 第 13 期｜oceanbase主备延迟
- 专辑文件：`29.html`，第 3 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247553647&idx=1&sn=a4e3034acc8ffb27e39eeeba5ab3d053&chksm=f8ee8d04a3f80fd5f349f67890eef740ef2bd2e9c34b4805420d6d8fee25f6181b4f53cba4a5#rd)
- **现象：** 主备集群延迟大，cpu100%，导致应用侧弱读业务无法正常抽数。
- **处置过程：** 登录cpu高的主机使用top命令查看cpu被什么进程使用；发现是oceanbase数据库进程导致的CPU使用率过高且sys使用率很高，又通过top-Hpobpid发现大量的dag_minor_metge和replay进程占用；主备集群延时过大
- **运维建议：** 更换时钟源；尝试将系统时钟源切换到 tsc，如果 tsc 在 available_clocksource 中不可用，可能需要检查BIOS设置或更新系统内核。；确认系统的其他配置，如CPU调度策略和内存管理，都已优化，以减少任何可能的系统级性能瓶颈。
## 第 13 期｜Oceanbase sql执行慢分析处置
- 专辑文件：`29.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247553647&idx=1&sn=a4e3034acc8ffb27e39eeeba5ab3d053&chksm=f8ee8d04a3f80fd5f349f67890eef740ef2bd2e9c34b4805420d6d8fee25f6181b4f53cba4a5#rd)
- **现象：** 业务侧反馈业务中有慢sql，但从数据库中查看sql执行速度很快，之后通过proxy日志发现有大量DBMS_LOB包的调用 。
- **处置过程：** 查看gv$sql_audit中看sql的执行时间均在100ms以内，但应用侧client去查需要2秒钟左右；通过sqlaudit中的trace_id查看observer日志看时间也并无其他耗时；通过session_id去查看obproxy日志中用大量的call dbms_lob.open、read、close的调用
- **运维建议：** 使用更有效的数据类型转换；如果业务逻辑允许，考虑在数据库层面将 CLOB 字段转换为字符类型（如您测试中使用的 TO_CHAR），这样可以减少应用层的处理负担，加快数据检索速度。；优化应用数据库交互逻辑
## 第 12 期｜OceanBase OAT中添加主机报错处置
- 专辑文件：`30.html`，第 9 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247552823&idx=1&sn=9693ecf3a5d69404fc032c4793a7f490&chksm=f85b749fb8c5158e15da1fdec6ed0ca79c79038f8b7842455dec3e42fe349048f133597fcc9c#rd)
- **现象：** OB oat中添加主机，precheck环境校验步骤报错openfiles配置值太小。
- **处置过程：** oat上添加服务器主机，服务器用途配置为OBServer；；凭证使用root用户；；操作系统为统信OS V20；
- **运维建议：** OB数据库对资源限制相关配置要求比较严格，PAM参数会影响OpenSSH会话的资源限制。针对远程检测ulimit资源限制，注意Openssh的UsePAM配置。
## 第 9 期｜OceanBase迁移过程中影响源生产库性能
- 专辑文件：`33.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247550974&idx=1&sn=01795083e9452df817ff2b8ea37c2c06&chksm=f873f7423ffa7fbf6360f433598b5441d204ef2d0ac6b1344396b5694489fc4646ba0ee3b55c#rd)
- **现象：** 某国产化项目数据迁移阶段，在OMS配置数据源，其中Oracle侧数据库属性设置为主库+备库的模式；数据迁移过程中，抽数均从主库抽取，影响Oracle主库性能，影响生产业务。
- **处置过程：** 抽数过程中，实时监控主库.ADG库主机网络流量波动情况，发现ADG库主机网卡流量无变化，主库主机网卡流量增涨明显；；检查Oracle库连接会话及执行SQL，发现大量oms服务器主机的进程在连接oracle主库；；经ob研发分析，OMS主备模式下，从4.0.1版本引入的主优先的模式，全量是会自动去连主库导致。后来4.1修复了，优先选择备模式。
- **运维建议：** 迁移过程中要多角度全方位对Oracle数据库及主机进行监控，避免产生影响。
## 第 9 期｜OceanBase备份失败
- 专辑文件：`33.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247550974&idx=1&sn=01795083e9452df817ff2b8ea37c2c06&chksm=f873f7423ffa7fbf6360f433598b5441d204ef2d0ac6b1344396b5694489fc4646ba0ee3b55c#rd)
- **现象：** 某国产化项目功能验证阶段，ob数据库备份失败。；2.2 处置方案；检查日志里有current index file is empty的报错，这个报错一般都是nfs导致的；
- **运维建议：** 目前OceanBase数据库国产化项目很多都部署在集团一级云资源池环境中，一级云资源配置复杂，使用时需要进行完整的验证测试。
## 第 9 期｜OceanBase表存在clob字段，导致查询效率极低
- 专辑文件：`33.html`，第 3 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247550974&idx=1&sn=01795083e9452df817ff2b8ea37c2c06&chksm=f873f7423ffa7fbf6360f433598b5441d204ef2d0ac6b1344396b5694489fc4646ba0ee3b55c#rd)
- **现象：** 表存在clob字段，导致查询效率极低。；3.2 处置方案；执行select操作，在clob字段加了to_char，效率变快，不加to_char从业务侧看延迟在1.6秒 ，加了to_char延迟在100ms以内。
- **运维建议：** 提前对陌生字段的表做相应测试。；对查询时间差别大的sql要引起重视。
## 第 7 期｜OceanBase误删除核心表处置
- 专辑文件：`35.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247548418&idx=1&sn=26252ff7559fe5a415057991c65fb400&chksm=f8e206d71ca6c58cda2f9738f9c6135e14f34d93d75c26026f6f95b4243c7ee87399027622a0#rd)
- **现象：** 业务人员误清除CRM核心字典表，导致大量业务异常。
- **处置过程：** 业务反馈该表被清除后，尝试基于时间点没有历史数据，检查该表的DDL时间发现做过DDL；；通过flashback进行闪回，发现该数据库未开启truncate闪回，无法恢复删除时间点的数据；；业务反馈可以从其它地市库取数，通过OMS抽数过来进行恢复，2w行数据迁移10分钟未结束，检查表上存在trigger，与业务沟通停掉相关业务，关闭触发器后完成恢复。
- **运维建议：** 做好数据库备份很重要；；推动OB改进版本，开启回收站，提高误操作恢复效率。
## 第 7 期｜OceanBase服务器资源紧张处置
- 专辑文件：`35.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247548418&idx=1&sn=26252ff7559fe5a415057991c65fb400&chksm=f8e206d71ca6c58cda2f9738f9c6135e14f34d93d75c26026f6f95b4243c7ee87399027622a0#rd)
- **现象：** 核心库CPU打满，连接数暴增，导致大量业务异常。；2.2 处置方案；可视化运维平台监控到某核心系统数据库CPU异常增高，紧急介入处理抓取异常SQL，此时数据库连接数已满，抓取的SQL都比较慢，很难定位到具体SQL，与客户沟通后重启，重启proxy未能正常恢复，申请切主后仍然未能恢复；
- **运维建议：** 做好SQL性能突变监控，及时介入处理；；对OB统计信息优先级进行深入理解；；核心表尽量避免手工收集统计信息。
## 第 7 期｜OceanBase SQL远程计划SPF变慢
- 专辑文件：`35.html`，第 3 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247548418&idx=1&sn=26252ff7559fe5a415057991c65fb400&chksm=f8e206d71ca6c58cda2f9738f9c6135e14f34d93d75c26026f6f95b4243c7ee87399027622a0#rd)
- **现象：** OceanBase SQL远程计划SPF变慢被放大，效率低下。
- **处置过程：** 业务上线之后遇到一条sql超时，执行效率很低，反馈过来要求优化排查。对比其他库查询该sql的执行历史，发现并不慢，对比执行计划也一样，只是远程算子位置不一样，手工将该sql涉及的表副本leader切到同一台server上；；后续在测试环境复现分析，limit截断算子正常是流式执行，外层传参进入内层，匹配到一条数据后就会停止，继续下面的执行，但是慢的执行计划有个exchange的远程查询推入，会进行查询重写，相当于外层传参一次，b表会全表数据拿出来进行一次比对，这个过程进行160次，导致变慢被放大。
- **运维建议：** 如果有可能，对可能出现这类问题的业务整理，以使用table_group固定；；关闭rebalance参数，对表副本进行固定，但是时间长了会造成节点负载不均衡；；加强SQL性能监控，对少量这类执行计划进行转换优化。
## 第 6 期｜OBserver主机CPU 100%
- 专辑文件：`36.html`，第 10 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247547362&idx=1&sn=e81f89caa975c5168690b4aaa64a34e3&chksm=f8214034dc2cdac26f9fcee01a8c4389ddf22c0fdb982fb6b71d6397e4bb9a3a3d2fba160f78#rd)
- **现象：** OceanBase核心库租户的OBserver主机连续几天出现CPU冲高到100%的情况。推测是SQL执行导致CPU打高。
- **处置过程：** 2.1 问题分析；通过OCP平台的SQL诊断功能，发现主机CPU冲高时都跑了同一条SQL，该SQL响应时间超长，且占用CPU时间高。；查看其执行计划，发现该SQL当时的执行计划走的索引和正常时候不一样。正常时走的索引应该是SERVICE_NUMBER字段，但是当时走的是STATUS字段，走STATUS字段时的效率很低。
- **运维建议：** 加强业务SQL开发培训，业务必须遵循割接上线前开会讨论的规定，比如避免字段是字符类型而传参为非字符类型的隐式转换。；增加上线评审环节。；利用SQL审核工具，提供审核效率。
## 第 5 期｜OCEANBASE集群合并超时
- 专辑文件：`37.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247546419&idx=1&sn=166891468c4eeb9c37a0b109baf3be3e&chksm=f872028936151d568f95bde0da5bc82853ed177f355e7060d2cfa6d370493bd8004d94f21fd5#rd)
- **现象：** 集群合并超时。
- **处置过程：** 先临时调大转储内存参数，保证业务不受影响。；检查原因，显示zone3合并未完成，observer日志显示有表转储有问题，修改该表primary_zone,对表级切主后合并正常。；检查observer/rs日志尝试分析是否为表卡住导致合并延迟，尝试表级切主，应急可以尝试重启问题的zone，甚至集群（该类操作谨慎），mem'store使用低的情况下可以暂时先调大转储阈值，提工单帮助分析。
- **运维建议：** 目前该问题暂时无法规避，进行数据库升级或者协调OB原厂开发对应的补丁。
## 第 4 期｜OCEANBASE数据库批量入库报4002处置
- 专辑文件：`38.html`，第 5 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247545681&idx=1&sn=8aeb394823bc8a6be300364dc7faa8a6&chksm=f833e66cee5e5c651ecb8df3eab3acb1292e41d478c62576c0782b1789dd0cb51b78935f5a87#rd)
- **现象：** 生产批量入库SQL报错-4002。
- **处置过程：** 代码未经适配直接使用，ob确认为bug，代码中insert all使用受限，写入数据行数过多时报错。；应用侧更改程序为for循环insert。
- **运维建议：** 数据库国产化过程中，务必加强场景测试，严禁代码未经适配直接上线生产。；由OB原厂开发对应的补丁。
## 第 4 期｜OCEANBASE归档日志延迟处置
- 专辑文件：`38.html`，第 6 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247545681&idx=1&sn=8aeb394823bc8a6be300364dc7faa8a6&chksm=f833e66cee5e5c651ecb8df3eab3acb1292e41d478c62576c0782b1789dd0cb51b78935f5a87#rd)
- **现象：** oceanbase数据库归档日志存在延迟。；检查归档状态是中断状态，保存下日志，先恢复下，关闭归档重新开启，检查rs日志归档状态变更时间点，去库里查询rs_event历史视图有分区切主操作，该操作为正常rebalance操作，检查该时间点observer日志有找不到clog的报错，检查该日志存在，工单协助分析为日志断流导致，与backup_log_archive_option参数设置有关系，属于正常的偶发。；该参数设置备份优先，不会丢失日志，但是可能会影响集群性能，
- **处置过程：** 设置集群可用优先可能会存在日志；关闭归档重新开启。
- **运维建议：** 与备份机制有关系，保证集群的高可用的情况下可能会做出备份断流的牺牲，是一种极少遇到的情况。；alter system noarchivelog；alter system archivelog
## 第 2 期｜Oceanbase数据库突然hang死
- 专辑文件：`40.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247543426&idx=1&sn=287cc6eaa6e98153ec19c45ea5989f33&chksm=f8170fa7cd7203246038852d2d0dab5a1d82b83c11b76b2ba4dd0275f67a6a1d255f198ce891#rd)
- **现象：** 某核心业务系统数据库突然无法登陆，Observer core退出，业务SQL导致系统CPU耗尽，临时绑定outputline，最终通过补丁升级解决。
- **排查与原因：** oceanbase数据库相关机制不太完美，在OBProxy1.8.7版本中，主zone故障h后无法在第一时间内自动切换到正常zone。；但从OBProxy3.2.6版本开始，引入了新的参数enable_primary_zone，默认为true，需要将proxy_primary_zone_name以及proxy_idc_name设置为空，在上线前的高可用测试过程中经过多轮验证符合预期要求。
- **处置过程：** 某SQL(select * from dual)异常；，修改proxy固定路由参数proxy_primary_zone_name指向新主zone，默认主zone为zone3，并重启proxy，修改后业务立即恢复。
- **运维建议：** 对于紧急故障短时间无法快速恢复的，可以通过快速重启OBPROXY进程解决。
## 第 2 期｜Oceanbase数据库表不大，但查询突然变慢
- 专辑文件：`40.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247543426&idx=1&sn=287cc6eaa6e98153ec19c45ea5989f33&chksm=f8170fa7cd7203246038852d2d0dab5a1d82b83c11b76b2ba4dd0275f67a6a1d255f198ce891#rd)
- **现象：** 业务数据查询，更新突然缓慢，导致业务大量积压。；经分析该表上存在频繁的DML操作时，可能会遇到一种：虽然表中的数据行数并不大，但是查询和更新的性能出现明显下降。；这种在 OceanBase 中称为Queuing 表(业务上有时又称 buffer 表)效应。
- **运维建议：** 为避免此类情况再次发生，将DML操作频繁的表设置为buffer表，这样表的转储与系统的大版本转储时间就不再保持一致，而是根据自身的变化，自行判断转储的时间点。
## 第 1 期｜ORACLE-OceanBase二阶段事务锁处理
- 专辑文件：`41.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247541586&idx=1&sn=6679d801fbeb3b8917f7298aeb573457&chksm=f8a211250a8a15312f5b12a9a56492512a3162a433ea92855b359aae4f82acfe75f1121e4b3b#rd)
- **现象：** 国产化数据库有悬挂事务，期间通过杀ORACLE端2PC，国产化数据库悬挂事务，后发现CPU使用率较高，决定重启资源proxy释放资源。；重启后2pc恢复正常，悬挂恢复正常。但由于大量的跨区访问导致oracle有大量2pc未正常回滚，导致数据库再业务访问订单表期间一直报正在回滚，强制根据报错的事务ID回滚后业务恢复正常。
- **排查与原因：** 事务分成两个阶段进行提交，包括准备阶段与提交阶段。2阶段事务及易出现在跨库的DML操作，例如DBLINK ，异构跨库变更等。；因为是分成两个阶段提交，故在事务提交方面存在一些不足；1）数据不一致
- **处置过程：** 国产化数据库有悬挂，期间通过杀ORACLE端2PC，国产化数据库悬挂事务及重启proxy、server释放资源。；重启后2pc恢复正常，悬挂恢复正常。；数据库存在分布式事务锁，检查数据库并未发现有分布式，等待事件中有“undo segment recover”等待显示该表在回滚；
- **运维建议：** 针对异常2pc场景固化到平台，对异常判断后能自动或者白屏化处理。
## 第 1 期｜Oceanbase悬挂事务导致异常处置
- 专辑文件：`41.html`，第 5 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247541586&idx=1&sn=6679d801fbeb3b8917f7298aeb573457&chksm=f8a211250a8a15312f5b12a9a56492512a3162a433ea92855b359aae4f82acfe75f1121e4b3b#rd)
- **现象：** 某场地Oceanbase数据库主副本节点cpu飙高导致业务连接失败以及大量悬挂事务，其他库CPU和内存无异常，有悬挂事务。
- **处置过程：** 检查告警主机CPU使用情况，发现主节点飙高，有超过80%的情况；；利用obstack对cpu飙高的主机抓取堆栈信息，以便根因分析；；杀悬挂事务；
- **运维建议：** 加强各类包括OB在内的国产数据库应急方案制定，完善各类国产数据库监控体系，当出现问题后及时根据应急方案进行处置。；根据抓取的堆栈信息，后续定位为数据库BUG，Oceanbase的plan_Cache泄露导致paln_cache打满，